@juhoteperi: does boot-cljs/next still use the shim?

also I was just running into a problem where I wanted to add reload/repl to one build but not the other — that’s not currently possible is it?

master and next for similarly in that: boot-cljs creates a namespace it will use as cljs :main and which will require and run init-fns

Probably the problem with boot-reload and next is that boot-reload changes all .cljs.edn files?

I wasn’t using next but yeah I guess that’s the cause

It should probably take :id argument which could select specific .cljs.edn

yes

Probably still a good idea to combine all those tasks as they rely on boot-cljs being used anyways

Not sure if combining everything is the best solution but I don't know what would be better

I would prefer keeping tasks separate as much as possible

I basically agree but they seem to be pretty close to each other anyways

I'm writing a boot task (in a different namespace) but I can't get it to be visible by executing "boot xxx" in the project or subprojects that depend on it.

@aengelberg: did you require it in your build.boot and add the metadata to the ns form?

(ns ^{:boot/export-tasks true} cljsee.task

And I am requiring it in build.boot.

Oh, looks like I have to :refer the task in build.boot as well.

Now it is working.

is it listed in boot -h — maybe under a different symbol as you would expect?

@aengelberg: if you dont refer you need to do x/task just as in clojure

@aengelberg: the ^{:boot/export-tasks true} is for when you pull in the jar with the task in it via the boot -d ...

like where you don't have a build.boot file necessarily

I assumed that any namespace with export-tasks that is on the classpath would have their tasks automatically work.

Is that not the case?

@aengelberg: only what you explicitly require will be available if you have a build.boot file — if you don’t have a build.boot file what you said should be the case I think

I see.

Thanks Martin and Micha

happy to help

@juhoteperi: does boot-cljs/next depend on something that’s not in 1.7.10 yet?

@juhoteperi: maybe it’s an alternative to just combine the repos into one as this allows easier/better coordination? things can still be separate artifacts etc.

@martinklepsch: Might be, latest master should work. I plan on adding something like boot-cljs.cljs-api-compat which would use API calls if they are available and then fallback to copied implementation for older cljs versions.

@martinklepsch: Hmph, 1.7.10 should contain required changes.

Compiling app.js...
java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.IAtom
                    clojure.core/swap!            core.clj: 2231
                    cljs.closure/build         closure.clj: 1606
                  cljs.build.api/build             api.clj:  219
    adzerk.boot-cljs.impl/compile-cljs            impl.clj:   46
                                   ...
                    clojure.core/apply            core.clj:  630
                 boot.pod/eval-fn-call             pod.clj:  183
                     boot.pod/call-in*             pod.clj:  190
                                   ...
                     boot.pod/call-in*             pod.clj:  193
              adzerk.boot-cljs/compile       boot_cljs.clj:   49
     adzerk.boot-cljs/eval418/fn/fn/fn       boot_cljs.clj:  115
     adzerk.boot-cljs/eval390/fn/fn/fn       boot_cljs.clj:   61
        boot.task.built-in/fn/fn/fn/fn        built_in.clj:  145
   adzerk.boot-reload/eval591/fn/fn/fn     boot_reload.clj:   96
   adzerk.boot-reload/eval591/fn/fn/fn     boot_reload.clj:   89
adzerk.boot-cljs-repl/eval520/fn/fn/fn  boot_cljs_repl.clj:  175
        boot.task.built-in/fn/fn/fn/fn        built_in.clj:  277
        boot.task.built-in/fn/fn/fn/fn        built_in.clj:  274
  boot.task.built-in/fn/fn/fn/fn/fn/fn        built_in.clj:  226
     boot.task.built-in/fn/fn/fn/fn/fn        built_in.clj:  226
        boot.task.built-in/fn/fn/fn/fn        built_in.clj:  223
   pandeiro.boot-http/eval646/fn/fn/fn       boot_http.clj:   71
                   boot.core/run-tasks            core.clj:  688
                     boot.core/boot/fn            core.clj:  698
   clojure.core/binding-conveyor-fn/fn            core.clj: 1916
                                   ...
Elapsed time: 15.121 sec

@juhoteperi: that’s what I get with next and 1.7.10

@martinklepsch: I see the same error

Strored-env is created using wrong call 😄

It's creating analysis env instead of compiler env

I’m currently playing around with Electron (atom-shell) and I think it’s a good example for something that requires a more complex cljs setup. There are two builds required one for the main process and one for the renderer (= whats shown in the webview). Both require different optimization levels in development. Also when changing sources only relevant to the renderer the build for main should not be triggered.

Should be fixed now.

Have you noticed if the boot-cljs is slower now that it uses different output dirs for different outputs?

Though shared output dir probably wouldn't work if there are different optimizations

that is only in next right?

Yeah

I haven’t ran next yet

but will try now

yeah i don't think there are any guarantees about sharing output dirs for different builds at all

also great work!

we don't have the goodwork bot here

haha

!m @juhoteperi

You're doing good work, @juhoteperi!

😄

snap

I corrected our coordination failure 😄

eventual consistency, yes

deraen: i'm writing a markdown parser from scratch now, using instaparse

@micha: Nice. I was thinking that might be useful.

went the whole depth of pegdown and decided it will be less work to just doit()

Though isn't markdown-clj already one?

not really

i want something way more abstract

my thing won't even know about html at all

Right

it will be a markdown parser generator

customizable from cljs

but as a macro

basically i want to have extensible "plugin" type things

where you can define abstract rules

or rather parameterized rules

@micha good luck! 😄 (I have "instaparse" as one of my highlight words)

alex_engelberg: dude! instaparse is the most beautiful thing i've seen in so long

it's like driving a BMW M3

also the documentation is incredible

so much awesome there, no words

I also like it a lot (I wrote kind of natural language parser using it :D)

deraen: what i was thinking was to have parameterized rules, like the abstract "heading" rule, where you have the leading char (`#`), repeated multiple times for the :level attribute, for example

@micha: how does that work with cljs + instaparse is instaparse cljc?

so i'd want to be able to add an instance of that rule from my cljs application, like to add a heading type rule that looks like %%% some other kind of heading

martinklepsch: no, i would call instaparse from a macro i think

and have other macros that can mutate the instaparse configuration

like to add rules and so on

basically i want to get just an AST, which can be cljs forms of course

which can be hoplon!

Maybe AST should be using Records and then provide one formatter which converts that to hoplon and another to hiccup

Like endophile

deraen: that's what i have with pegdown now, so i'm thinking to do the same, yeah

i tried endophile, but it wasn't low level enough

@juhoteperi: regarding next — should all builds run every cycle or should it detect when no relevant files have changed?

i reimplemented endophile using a sort of deep-bean function

like a recursive kind of bean implementation

@martinklepsch: All builds. But if files interesting to build aren't changed the build should be very fast.

Cljs should itself do the mod time checking.

deraen: i think records vs maps are pretty much a wash

Though there could be something which causes cljs to do compilation each time.

i'm planning to use multimethods on the cljs side anyway

because some things you can't just dispatch on type for

@juhoteperi: the build that should not be run is :whitespace and makes for about 7 of 8s compilation time

@martinklepsch: Mhh could be that other than none build will always do the optimization step, I'm not sure if we can do anything about that.

… other than getting mod-time checking into the cljs compiler?

we could separate the optimization step, perhaps

call it explicitly

then you could decide whether to do it or not

Perhaps. But that's something which should probably be done by cljs.

true

hm. For that electron stuff this is really impractical.

Do I understand right that all the dependency tracking etc is now done by the cljs compiler directly and the compiler decides when to rebuild?

martinklepsch: why do you need :whitespace?

does electron not understand module loading?

It was the easiest I could get electron to work with

but you’re right I haven’t gone down that rabbit hole completely yet

i think that developing with :whitespace will tend to cause problems

why?

because you can't make it fast, so preventing it from compiling unnecessarily is only part of a solution

The thing is that it’s almost a one-off. I don’t see how changes could be picked up by electron.

you also want it to be fast when you do need to compile it

what about a separate boot process for that?

I need to restart Electron everytime it compiles

you can exclude files from the compiler with the sift task if you need to

but changes to the main process are rare so it’s ok I think

micha: I need to compile them once though + restarting boot when I change it is also non-ideal

i mean boot watch build-electron in one shell

and boot watch build-other in another shell

that would work but it’s not pretty enough 😛