Fork me on GitHub
#boot
<
2015-07-31
>
martinklepsch11:07:52

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

martinklepsch11:07:34

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?

juhoteperi11:07:59

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

juhoteperi11:07:25

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

martinklepsch11:07:53

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

juhoteperi11:07:58

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

martinklepsch11:07:59

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

juhoteperi12:07:32

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

juhoteperi12:07:55

I would prefer keeping tasks separate as much as possible

martinklepsch14:07:23

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

aengelberg15:07:13

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.

martinklepsch15:07:20

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

aengelberg15:07:36

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

aengelberg15:07:48

And I am requiring it in build.boot.

aengelberg15:07:37

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

aengelberg15:07:41

Now it is working.

martinklepsch15:07:53

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

martinklepsch15:07:17

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

micha15:07:43

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

micha15:07:54

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

aengelberg15:07:30

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

aengelberg15:07:35

Is that not the case?

martinklepsch16:07:58

@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

aengelberg16:07:29

Thanks Martin and Micha

martinklepsch16:07:37

happy to help simple_smile

martinklepsch17:07:23

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

martinklepsch18:07:48

@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.

juhoteperi20:07:09

@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.

juhoteperi20:07:54

@martinklepsch: Hmph, 1.7.10 should contain required changes.

martinklepsch20:07:37

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

martinklepsch20:07:26

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

juhoteperi20:07:24

@martinklepsch: I see the same error

juhoteperi20:07:35

Strored-env is created using wrong call 😄

juhoteperi20:07:42

It's creating analysis env instead of compiler env

martinklepsch20:07:08

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.

juhoteperi20:07:12

Should be fixed now.

juhoteperi20:07:59

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

juhoteperi20:07:14

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

martinklepsch20:07:22

that is only in next right?

martinklepsch20:07:29

I haven’t ran next yet

martinklepsch20:07:31

but will try now

micha20:07:00

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

micha20:07:24

also great work!

micha20:07:35

we don't have the goodwork bot here

micha20:07:16

You're doing good work, @juhoteperi!

martinklepsch20:07:49

I corrected our coordination failure 😄

micha20:07:02

eventual consistency, yes simple_smile

micha20:07:36

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

juhoteperi20:07:52

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

micha20:07:01

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

juhoteperi20:07:08

Though isn't markdown-clj already one?

micha20:07:13

not really

micha20:07:20

i want something way more abstract

micha20:07:28

my thing won't even know about html at all

micha20:07:42

it will be a markdown parser generator

micha20:07:49

customizable from cljs

micha20:07:57

but as a macro

micha20:07:21

basically i want to have extensible "plugin" type things

micha20:07:28

where you can define abstract rules

micha20:07:35

or rather parameterized rules

aengelberg20:07:38

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

micha20:07:05

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

micha20:07:21

it's like driving a BMW M3

micha20:07:44

also the documentation is incredible

micha20:07:07

so much awesome there, no words

juhoteperi20:07:31

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

micha20:07:53

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

martinklepsch20:07:17

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

micha20:07:30

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

micha20:07:01

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

micha20:07:18

and have other macros that can mutate the instaparse configuration

micha20:07:29

like to add rules and so on

micha20:07:46

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

micha20:07:52

which can be hoplon!

juhoteperi20:07:03

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

juhoteperi20:07:11

Like endophile

micha20:07:20

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

micha20:07:32

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

martinklepsch20:07:45

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

micha20:07:49

i reimplemented endophile using a sort of deep-bean function

micha20:07:03

like a recursive kind of bean implementation

juhoteperi20:07:13

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

juhoteperi20:07:37

Cljs should itself do the mod time checking.

micha20:07:02

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

juhoteperi20:07:03

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

micha20:07:34

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

micha20:07:45

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

martinklepsch20:07:48

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

juhoteperi20:07:37

@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.

martinklepsch20:07:18

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

micha20:07:49

we could separate the optimization step, perhaps

micha20:07:56

call it explicitly

micha20:07:17

then you could decide whether to do it or not

juhoteperi20:07:03

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

martinklepsch21:07:14

hm. For that electron stuff this is really impractical.

martinklepsch21:07:51

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?

micha21:07:29

martinklepsch: why do you need :whitespace?

micha21:07:40

does electron not understand module loading?

martinklepsch21:07:02

It was the easiest I could get electron to work with

martinklepsch21:07:19

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

micha21:07:21

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

micha21:07:53

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

martinklepsch21:07:09

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

micha21:07:10

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

micha21:07:27

what about a separate boot process for that?

martinklepsch21:07:28

I need to restart Electron everytime it compiles

micha21:07:59

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

martinklepsch21:07:12

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

martinklepsch21:07:03

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

micha21:07:38

i mean boot watch build-electron in one shell

micha21:07:47

and boot watch build-other in another shell

martinklepsch21:07:20

that would work but it’s not pretty enough 😛