Fork me on GitHub
#clojurescript
<
2016-09-03
>
stbgz00:09:31

@shaunlebron We could try to make pommergranite work with @rohit dep resolution code

shaunlebron00:09:34

yeah, I don’t know the correct way forward here

shaunlebron00:09:17

I definitely won’t be driving this effort, just want to facilitate information to whoever will

pesterhazy12:09:28

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?

anmonteiro13:09:55

@pesterhazy: not enabled by default, safe to enable with :parallel-build true

pesterhazy13:09:27

thinking of getting a multicore machine and wondering if it'll help with compilation times

pesterhazy13:09:52

to shorten the feedback loop

anmonteiro13:09:02

There are some issues open about that, but mostly around optimizing certain code paths that have coarse-grained locks

anmonteiro13:09:42

@pesterhazy: compilation times depend on the dependency index of your project

anmonteiro13:09:05

Some projects will see big improvements, others not so much

pesterhazy13:09:12

does it speed up incremental compilation as well?

pesterhazy13:09:18

that's what's most important to me

anmonteiro13:09:35

@mfikes did some experiments at the time

pesterhazy13:09:38

looks like it's worth the 1000 EUR for an old hexacore mac pro

anmonteiro13:09:18

There's also that one ^

mfikes13:09:57

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

pesterhazy13:09:53

thanks for the offer!

pesterhazy13:09:03

new mac pros are outrageously expensive

pesterhazy13:09:21

I was thinking of a used 2010 mac pro

pesterhazy13:09:46

should still be a massive improvement compared to my macbook air

mfikes13:09:34

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

mfikes13:09:26

TBH, I think modern iMacs are much faster than any Mac Pro you can currently buy.

anmonteiro13:09:32

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

pesterhazy13:09:10

@mfikes didn't know that iMacs were fast

anmonteiro13:09:16

Mine is approaching 3 years now and I don't have any complaints

pesterhazy13:09:01

@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

pesterhazy13:09:19

wow that's surprising. My assumption was that cpus had basically stopped getting faster in the last 5 years

pesterhazy13:09:31

almost every mac is over-the-top expensive though (except for the macbook air, which is a good value)

akiva14:09:05

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.

akiva14:09:05

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.

stbgz18:09:03

hey guys currently how does the boostrapped cljs compiler add dependencies to a classpath?

stbgz18:09:30

does having a classpath make any sense anymore in a jvm less compiler

stbgz18:09:31

I know the tools need a jvm

domgetter18:09:50

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))]

domgetter18:09:27

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

domgetter18:09:08

Nevermind, I think I know the reason now. Since state is defonced, the view was already created.

gowder18:09:33

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

domgetter19:09:08

@gowder you'll want to have the setTimeout wait 1000 * n

domgetter19:09:33

That way, the first one will happen after 1000 ms, the second after 2000 ms, etc

gowder19:09:08

huh. fascinating. thanks @domgetter --- that works like a charm, but I honestly have no freaking idea why

domgetter19:09:26

You're making 1000 different setTimeouts all at once

domgetter19:09:42

dotimes doesn't wait between calls, it makes them all as fast as possible

domgetter19:09:14

then the setTimeouts are placed on a separate thread and when their time is up, the callback is placed on the event queue

domgetter19:09:48

Here's a wonderful explanation of that topic: https://www.youtube.com/watch?v=8aGhZQkoFbQ

gowder19:09:14

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?

gowder19:09:25

thank you! javascript semantics always confuse me like mad

domgetter21:09:15

Anyone have success with having a RefreshControll :on-refresh put onto a channel?

val_waeselynck21:09:51

@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

val_waeselynck21:09:22

(defn lotsa-monty [strategy]
  (go
    (reset! win 0)
    (reset! loss 0)
    (dotimes [n 1000]
      (<! (timeout 1000)))))

gowder21:09:54

thanks @val_waeselynck --- I didn't realize core.async had a timeout function

shaunlebron23:09:01

@gowder: JS is single-threaded

shaunlebron23:09:06

you can think of functions executing on certain ticks. after each tick, the setTimeout/setInterval functions will execute according to when they’re scheduled

shaunlebron23:09:37

that’s why it’s important not to have long-running functions clog up the event loop