Fork me on GitHub
#boot
<
2017-01-14
>
williewillus00:01:02

I'm working through the modern-cljs tutorial series, currently at no. 4, and it seems like the reload task is unable to make my browser auto refresh when files change. I have to refresh manually, and upon doing that chromium spits out this error: Uncaught DOMException: Failed to construct 'WebSocket': The URL 'ws://:46709' is invalid. anyone know what's happening?

danielsz01:01:22

@alandipert @micha This new Ring vulnerability fix affects serving resources in Boot, have you noticed? I just bumped into it after upgrading.

martinklepsch02:01:04

@danielsz you mean via boot-serve ?

danielsz02:01:47

I haven't had time to investigate, but that sounds about right.

bhagany03:01:22

@williewillus are you setting that port manually?

williewillus03:01:48

no, it's automatically assigned (by the refresh task I'm guessing)

bhagany03:01:53

yeah, it does that - how about ws-host?

clojuregeek03:01:50

@williewillus: i am not sure, but I was working through modern-cljs .. I ended up having to use safari and not chrome

clojuregeek03:01:30

I am not sure why but I was mainly trying to learn boot so I didn't spends time on it

williewillus03:01:07

hmm trying on firefox (I'm on linux) gives a similar error SyntaxError: An invalid or illegal string was specified websocket.js:283

bhagany03:01:30

looking at the build.boot for that tutorial, I'm not seeing anything obvious

lxsameer10:01:05

hey guys, it takes about 70sec for boot to compile my cljs files on a corei5 cpu, is it normal ? how can I improve this ?

magomimmo10:01:55

@williewillus take into account that modern-cljs is still based on version 2.5.5 of boot. Hopefully in february 2017 I’ll find the time to port it to the newly released 2.7.1 release. That said, have you tried the following?

git clone 
cd modern-cljs
git checkout se-tutorial-04
and see if it works?

grounded_sage10:01:48

@lxsameer: I usually get 30-45 seconds. With the small website I am developing mostly in cljs atm

lxsameer10:01:13

hmmm that's a lot, it there any way to improve ?

grounded_sage10:01:16

I'm currently playing around with goof.style/installStyles atm. Is this something I need to put into an edn file or can I run it in my cljs?

grounded_sage10:01:29

Subsequent is 0 to ~2 seconds I played around with parallel build a while ago but didn't notice any significant improvement. (Might have been doing it wrong)

pesterhazy12:01:12

@lxsameer the question is, why does the initial compile step matter as much, if subsequent iterations are fast enough?

pesterhazy12:01:42

obviously use optimizations: none for development

pesterhazy12:01:51

(if you're not doing that already)

lxsameer12:01:44

@pesterhazy sometimes i have to restart the whole system, also parallel boot seems don't have any effect either

pesterhazy12:01:36

I mean I wish it was faster too but I usually can fill the time until the dev env is up with something useful 🙂

pesterhazy12:01:03

also a fast CPU really helps here (going from macbook air to macbook pro, for example)

lxsameer12:01:14

@pesterhazy i wish there was a solution to cache the result, for example my dependencies always compiles to the same thing, there's not need to compile them over and over again, but apparently it's against boot philosophy

pesterhazy12:01:04

hm not necessarily

rickmoynihan12:01:52

does anyone have any examples of boot doing what treelein is doing in this lein project? https://github.com/juxt/yada/blob/master/treelein

rickmoynihan12:01:02

specifically want a way to build sub dependency jars, but otherwise in dev mount them all onto the same source path… should be pretty straightforward in boot right?

dominicm12:01:40

Might be that cljsjs does that.

dominicm12:01:57

But you could also use sift to split stuff up too, and generate multiple jars

rickmoynihan13:01:25

any examples of sift?

micha14:01:27

@lxsameer if they always compile to the same thing you can just make a jar or a zip file with the compiled artifacts and have those separaetly

lxsameer14:01:01

that's a good idea. but what about clojurescript itself ?

micha14:01:10

how do you mean?

micha14:01:03

iirc cljs already ships core namespaces as precompiled js

micha14:01:59

boot has support for persistent cached filesets, but you need to be able to compute a cache key that will expire the cache correctly

micha14:01:37

with something like lisp that is very hard to do correctly, because there is no static way to determine that

micha14:01:57

my experience with eg. lein cljsbuild was that i constantly had to do the clean task to make sure i'm not using stale incorrect cached files

micha14:01:23

i've spent a lot of time chasing down bugs that turned out to be some weird cache state

micha14:01:42

so imho if you can't cache correctly it's better not to try

micha14:01:42

compiling C for example it's a much easier job to figure out when to expire a cache

micha14:01:00

because the relationships between source files is static

lxsameer14:01:17

@micha is there any way to find out what is the most expensive file to compile ?

micha14:01:31

is this cljs?

micha14:01:27

you can try (cljs :compiler-options {:verbose true})

lxsameer14:01:33

@micha also i need to know more about the persistent cached filesets, where can i find more info ?

micha14:01:22

you can look at the docstring for those in the repl with v 2.7.1

micha14:01:38

i need to regenerate docs for the new release

micha14:01:47

i'll do that in a few minutes

lxsameer14:01:43

cool, thanks @micha

micha14:01:07

you can also look at the source of the uber task for an example of how to use it

micha14:01:28

the uber task unzips jar files into the fileset

micha14:01:55

it uses the md5 hash of the jar file itself as the cache key

micha14:01:04

so it can cache 100% correctly

micha14:01:48

the first time the uber task sees a given jar file it unzips it and caches the unzipped fileset

micha14:01:09

after that it will use the cached version instead of needing to unzip the jar again

micha14:01:14

much faster

micha14:01:00

it just needs to make hard links into the cache storage rather than decompressing the jar and writing all the files

lxsameer15:01:14

@micha thanks for the info bro

micha15:01:38

@lxsameer any time 🙂

geoffs17:01:21

@micha I updated the visual notification code again with @martinklepsch ‘s suggestion to use dosh-timed again. I decided to stick with the policy of “never throw from notify”. So now errors in notification are swallowed silently and if anything goes wrong a text notification will be printed in the terminal.

geoffs17:01:32

I’m pretty happy with the general idea, but I guess I’m a little unsure about the “swallow all errors silently”. It seems like it might make it really hard to debug if there’s something weird with the options passed to notify that causes it to fail unexpectedly...

micha18:01:56

it cold have a debug option?

micha18:01:32

the watch task has a verbose option for debugging

micha18:01:38

@geoffs ^^

geoffs18:01:01

good call. i’ll add that

richiardiandrea18:01:57

@geoffs from what I have seen in the code base when boot.util/*verbosity* >= 2 you have debug stuff. Now we the PR for logs and macros you could also use that (when it gets merged in, ping @micha 😀)

micha18:01:19

ah yes will merge that shortly!

richiardiandrea18:01:10

Great! I think it solves a bunch of problems which I absolutely didn't expect it would solve

richiardiandrea18:01:13

I have worked on that during a polyglot meetup trying to show off Clojure macros to people 😄

geoffs18:01:30

haha, nice! yeah, that seems like a better solution to this. I’ll use the util/print-ex function to print the information about any thrown exceptions.

richiardiandrea18:01:45

Yeah there is a common function for exceptions that handles level, prolly that one ;)