This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-30
Channels
- # admin-announcements (10)
- # beginners (7)
- # boot (216)
- # cider (10)
- # cljs-dev (3)
- # clojure (71)
- # clojure-denmark (2)
- # clojure-italy (3)
- # clojure-seattle (1)
- # clojurescript (124)
- # cloxp (1)
- # code-reviews (5)
- # core-matrix (2)
- # cursive (34)
- # datomic (3)
- # editors (1)
- # hoplon (201)
- # immutant (2)
- # jobs (3)
- # ldnclj (7)
- # off-topic (3)
- # re-frame (19)
- # reagent (76)
@micha: btw. there is work going on to decouple Cider from nREPL so that it can work with Clj 1.8 socket/network repl
There’s a character limit, didn’t read it as very rude myself
And let’s not assume bad intentions from those couple of words
I guess we could revert that change now
As it looks like it will be fixed on Cljs side
Though I don't know how long that will take
The issue is here: http://dev.clojure.org/jira/browse/CLJS-1437 recompile-dependents looks to be quite broken even with multiple directories
How about we push a version of that and ask him to try again/report back
Shouldn't affect advanced build?
Yeah that's what I mean
Not sure, I pushed -3 24th and tweet is from 25th
25s -> 21s :none build time after removing the other dirs from build call
I have try with larger project
ah lol no
I strill used old boot-cljs
well, 20s with proper version
the tweet mentioned cold build, e.g. cleaned target dir
so no cache
what’s the difference for incremental compiles?
Those times are quite useless without knowning how they are measured etc.
Passing only the one dir to build has no affect on incremental compile times
But I'll try with larger project
I also have lein setup for that project so I can see the differences
@micha: but where does it come from then?
Well in fact boot is faster for me... at least in one case
Though that's probably only because leiningen startup is really slow
No much dfferences other than for incremental recompile for me
And the difference there is probably mostly caused by measurement differences
vs lein
probably JVM parameters that are passed to boot and lein are something that should be listed in such comparisons
Luckily Cljs has :compiler-stats which can be used to display how long compilation takes, that should offer uniform measurement
I don't see differences in none compile times with or without additional directories
Probably no
it was definitely compiling things it shouldn't have been compiling when directories were being added
https://github.com/adzerk-oss/boot-cljs/issues/93 added compiler measurements to incremental compile logs, show there's no differenence in cljs compiler times between two
Well it's pretty close to 300ms for each recompile
To compare time taken only by cljs compiler, sum basic and add dependencies times
for boot basic sources takes only 5ms because our only file in input folders is the main ns and all others are compiled in dependencies step
And basic sources in lein includes all cljs files in source-paths
The difference between time used by cljs compiler and boot elapsed time is probably overhead from boot
only the main ns dir
But that didn't have difference in my case because my project doesn't have additional files
But looks like boot overhead for recompiles is relatively large
I wrapped build
in time
and it definitely shows it's not cljs compiler which is taking the time 😞
or maybe just provide option to disable target dir completely, no need when using watch and serving from classpath etc.
Or even doing that as default and then adding option to enable target dir
Because it looks like target dir is confusing many people
https://github.com/adzerk-oss/boot-cljs/tree/no-workaround here's boot-cljs without the workaround
separating target into a task, love this concept
Makes sense, the only time when target is needed is when build a jar
or debugging
right, it's like 'export'
Could target be a link to an existing tmp-dir?
@onetom: good morning!
@martinklepsch: There is no one tmp-dir which would contain all the files
because those temp dirs are now immutable, since there are no references to them in any tasks anymore
Removing target seems like a thing that might confuse new-comers that are used to this kind of thing
if someone wants to have the target populated each time, they can write a simple task for that
@martinklepsch: True but seems also that target being available confuses many new-comers as they try to serve files from target (or even include target in source-paths)
right. also true. Just want to make sure things stay approachable
for understanding what happens along the pipeline - as a newcomer - i was using (show -f)
quite a lot (but it didnt tell me which files will i see in target at the end)
like boot show -f cljs
will show you what would be send to target before the cljs task runs
eg i was not expecting the out/
dirs present in case of simple or advanced optimizations
cant remember. it was weeks ago. as i said, i used it to understand more, so at that time i was not very clear about the filesets
i thought that was the conclusion we arrived at in https://hoplon.hackpad.com/Project-structure-GgBekBLIaIA
having all the things in the same clojars group will make it easier to manage for admin
@alandipert: what do you think?
clojure.lang.Compiler$CompilerException: java.io.FileNotFoundException: Could not locate cljs/analyzer__init.class or cljs/analyzer.clj on classpath., compiling:(javelin/core.clj:1:1)
most useful will be aligning clojars/github groupid under hoplon
I added OS X results, overhead looks to be a bit larger.
has anyone tried to run clojure on http://c9.io? it would be super easy to peek into each other's projects there and see it for yourselves whats wrong and how long things take
I do have a Windows laptop also at hand but I doubt boot-cljs would work at all there…
@alandipert: not sure if that guest on the hackpad is you but we had this conclusion when thinking about the naming: > Not throwing javelin, castra and boot-hoplon under the hoplon/ artifact group id makes the dependency specifications very beginner friendly.
(My desk is pretty crowded at the moment, 32+24 displays and three laptops)
Where does the 80ms difference during incremental compiles (boot overhead subtracted)
@martinklepsch: How did you calculate that?
@juhoteperi: I compiled a small cljs file like 2 days ago on windows with boot-cljs
@xifi: There are still few hairy path/url manipulations going on. Could be they work or could be they break only in certain cases. But to my knowledge no-one is using boot-cljs on Windows actively?
@juhoteperi: well you can't call me active yet but I hope to become
@juhoteperi: took the time from Add dependencies, elapsed time: 256.398092 msecs
and the incremental times from cljsbuild
it’s closer to 150ms though, misread
if things break on win I'll just set up a vm. But my final artifacts should work on win
@martinklepsch: Compare basic sources + add dependencies times between boot and lein
oh, there boot-cljs is like crazy faster?
@martinklepsch: No. 5+294=300 and 120+203=320, they are nearly as fast
The difference in distribution between basic sources and dependencies is caused by different configuration
ah ok.
@onetom: what about not having hoplon/ makes things beginner friendly in your opinion?
there is less confusion between the github -> group id -> namespace structures hoplon/hoplon -> hoplon(/hoplon) -> hoplon.core hoplon/javelin -> javelin(/javelin) -> javelin.core hoplon/castra -> castra(/castra) -> castra.core hoplon/boot-hoplon -> boot-hoplon(/boot-hoplon) -> boot-hoplon.core
there is a higher chance of name collision on clojars of course but micha checked and everything was available...
Hm with that boot shouldn't write to target while watch is going on?
How do I make sure I'm using right version of boot?
ah one sec, target could have been from previous run
hmm no, still writing to target
I do have 2.2.0 on boot.properties and make install
should have been enough?
lol, I forgot to checkout the branch
I should be sleeping... but I'll just test this fast...
Okay, no target dir but no much difference in incremental compile times either.
Debugger or just adding loads of time
calls should tell what is taking the time
@juhoteperi: u r not using the https://github.com/ptaoussanis/timbre lib for such profiling?