This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-03
Channels
- # admin-announcements (1)
- # beginners (4)
- # boot (1)
- # chestnut (2)
- # clara (1)
- # cljs-dev (8)
- # cljsjs (50)
- # clojure (40)
- # clojure-austin (3)
- # clojure-brasil (3)
- # clojure-canada (1)
- # clojure-gamedev (2)
- # clojure-italy (3)
- # clojure-russia (19)
- # clojure-spec (14)
- # clojure-uk (1)
- # clojurescript (60)
- # core-async (4)
- # cursive (4)
- # datomic (3)
- # editors-rus (2)
- # emacs (4)
- # events (1)
- # figwheel (2)
- # flambo (4)
- # hoplon (94)
- # jobs (4)
- # leiningen (3)
- # om (9)
- # onyx (64)
- # re-frame (86)
- # reagent (52)
- # spacemacs (4)
- # test-check (1)
- # yada (31)
@shaunlebron We could try to make pommergranite work with @rohit dep resolution code
yeah, I don’t know the correct way forward here
I definitely won’t be driving this effort, just want to facilitate information to whoever will
what's the status of parallel compilation in recent versions of cljs? is it enabled by default? if not, is it safe to enable or does it have any adverse effects?
@pesterhazy: not enabled by default, safe to enable with :parallel-build true
thinking of getting a multicore machine and wondering if it'll help with compilation times
to shorten the feedback loop
There are some issues open about that, but mostly around optimizing certain code paths that have coarse-grained locks
@pesterhazy: compilation times depend on the dependency index of your project
Some projects will see big improvements, others not so much
does it speed up incremental compilation as well?
that's what's most important to me
@mfikes did some experiments at the time
jinx!
looks like it's worth the 1000 EUR for an old hexacore mac pro
http://blog.fikesfarm.com/posts/2015-11-14-try-clojurescript-parallel-compilation.html
There's also that one ^
@pesterhazy My thinking: Go for 6 or 8 cores, but not 12 (because those cores are slower). If you end up thinking about a new one, wait a month or so, because Apple may announce a new Mac Pro that might be competitive compared to iMacs. If you have a project you’d like me to try with the dual-hexacore I have, I’d be happy to try it with parallel off and on to illustrate what the difference might be.
thanks for the offer!
new mac pros are outrageously expensive
I was thinking of a used 2010 mac pro
should still be a massive improvement compared to my macbook air
Also (you’d have to read up on it with respect to the particular model), but with the 12-core it ends up being faster if it only has 24 GB of RAM instead of 32 GB (owing to there being 3 memory bus channels or somesuch that have to be shared if you max out the RAM).
@pesterhazy: well if you don't want to give up portability, a Macbook Pro (15) is already a big step up from a macbook air 😛
@mfikes didn't know that iMacs were fast
Mine is approaching 3 years now and I don't have any complaints
@anmonteiro yes I've seen that with people using (oder) macbooks pro, and they're more than twice as fast in doing an involved cljs => react native packager => ios simulator pipeline
@pesterhazy Definitely take a gander at https://browser.primatelabs.com/mac-benchmarks
wow that's surprising. My assumption was that cpus had basically stopped getting faster in the last 5 years
almost every mac is over-the-top expensive though (except for the macbook air, which is a good value)
I have one of the older octocore Mac Pros with, and I still have no clue how, 17 GB of RAM. It’s absurdly fast in all ways (I don’t do video processing but I do audio processing). I added an ATI Radeon video card as well as a SoundBlaster card for Windows gaming and there wasn’t a game I couldn’t throw at it and get maximum resolution and great framerates.
I don’t know if the 12-core is worth it over the others, I just happened to have money to blow so I went all out. It’s still a beast of a machine.
hey guys currently how does the boostrapped cljs compiler add dependencies to a classpath?
I'm using figwheel with React Native, and some changes are being shown, but others are not. I have a list of views in my state, and in app-root, I'm showing the first view in that list: [view {:style {:flex 1}} (first (:views @state))]
If I add stuff to that view with flex 1, I can see changes, but if I make changes to the view in (first (:views @state)), it doesn't update
Nevermind, I think I know the reason now. Since state is defonced, the view was already created.
Silly question: does someone know how to call a function at an interval in cljs? I have the following:
(defn lotsa-monty [strategy]
(do
(reset! win 0)
(reset! loss 0)
(dotimes [n 1000]
(js/setTimeout #(play-monty strategy) 1000))))
where play-monty
is a simulation (of a monty hall problem) that calculates an outcome, updates a reagent atom and then some SVG.
I would have expected that calling lotsa-monty
would wait for one second between each call to play-monty
. But instead, what it seems to do is wait for one second, then call play-monty
1000 times with no delay between them.
Replacing setTimeout
with setInterval
just creates an infinite loop where lotsa-monty
waits for 1 second, calls play-monty
1000 times, waits for a second, 1000 more calls, etc...huh. fascinating. thanks @domgetter --- that works like a charm, but I honestly have no freaking idea why
then the setTimeouts are placed on a separate thread and when their time is up, the callback is placed on the event queue
Here's a wonderful explanation of that topic: https://www.youtube.com/watch?v=8aGhZQkoFbQ
the setTimeouts are placed on a separate thread? that's the part I think was confusing me. interesting. So it's like setTimeout has an implicit piece of state indicating the time of their first call... I guess?
@gowder a recursive function is also a common way to tackle this problem; also note that core.async's go block let you write code which looks like your first attempt
(defn lotsa-monty [strategy]
(go
(reset! win 0)
(reset! loss 0)
(dotimes [n 1000]
(<! (timeout 1000)))))
thanks @val_waeselynck --- I didn't realize core.async had a timeout function
@gowder: JS is single-threaded
you can think of functions executing on certain ticks. after each tick, the setTimeout/setInterval functions will execute according to when they’re scheduled
that’s why it’s important not to have long-running functions clog up the event loop