I just compiled my app with advanced optimizations, and for some reason it won't work on another browser... I can access it in Chrome on Linux, Firefox on Linux, and on two different Android Browsers, but it won't work on my wife's Windows Chrome... The console says that it can't find <name of my app>. Any idea what's going on?

@mfikes: hi, that bug I thought I had the other day with seqs apparently mutating turned out to be my error in interpreting the debug output -- all is well, and lazy seqs really are immutable 😀

@josh.freckleton: check the active browser extensions, maybe there is something installed that is messing with things

As http2 is slowly rising. Are there possibilities to build packages, supporting the HTTP2 and the HTTP1 features?

@danielgrosse: what do you have in mind? http2 is mostly transparent on the application level, no difference on the client api level

Over http1 using a concatenated, minified file is best practice. But with http2 it will be better to use separate files. Can I compile nonconcatenated, minified modules with the closure compiler?

om/next question! I’m trying to get my head around normalization and thought I was making progress, but I’ve stumbled again and am not sure if I’m just not thinking correctly about the problem. How do I normalize the current user’s messages? See this gist for the details: https://gist.github.com/addywaddy/2b2ecf4ca389afb0d202

Sorry - rather new here Maybe my question is best suited to stack overflow.

@danielgrosse: :advanced compilation is just as valuable with http2 as it was before. if you want a smaller compilation unit use modules, but you still want to eliminate dead code. no use in being able to download 50 files separately if you only use 5% or each.

removing dead code and having a fully optimized build is still far superior to everything else

closure modules are the best option with http1 and http2. that doesn't change.

@addywaddy: there is an #C06DT2YSY channel, you might have more luck there

Ah, cheers @thheller!

http://blog.fikesfarm.com/posts/2016-02-22-trying-clojurescript-paches.html

interesting stuff http://facebook.github.io/draft-js/

Hi, suppose i have a vector of channels and I want to get a vector of results from taking one element from each channel. Is this possible? [I'd rather not have to resort to side-effecting doseq but given limitations of core.async mentioned here https://github.com/clojure/core.async/wiki/Go-Block-Best-Practices it may be the only way).

[That article doesn't mention any workarounds-- only limitations].

blocking or non blocking?

(map clojure.core.async/poll! [chs]) will do that nonblocking

Since this is CLJS, shouldn't everything be non-blocking

Oh, that won't quite work. The channels themselves are performing web requests to get the results posted back

So, it's likely that all nils will be returned at first.

[Oh, by 'blocking' you mean 'parking' ??]

Yes, parking/blocking ideally.

i.e., I wanted to use <! but you can't map over that per the "limitations" article above

try take! https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async.cljs#L90

How's that going to help me get a vector of results? I'd have to stitch together a bunch of results from each of the callbacks?

So, to give a little more context, let's say that I am swapping into an atom the vector of results and I want to do that all at once and not one by one.

Introducing yet another atom to accumulate the results seems less than "functional"

I usually see that implemented like so: (go [(<! ch1) (<! ch2) (<! ch3)])

hmm, that might work. but the length of the vector is dynamic

i.e., the result of a previous computation

okay something like this may work then

(go (<! (async/into [] (async/merge (map (partial async/take 1) chs)))))

the results will most likely be unordered

is that async/into?

ah yes forgot the ns

ahh, perfect! thx!

you would need to destructure the result of alts! though

@mihaelkonjevic: yea, I think that would work. Probably just call 'first' on the result rather than destructure

@mihaelkonjevic: it's a bit more "machinery-oriented" than "function-oriented" though (not to mention many more tokens) so I prefer the async/into + async/merge solution

absolutely, I'm saving that snippet for later reuse

Hello Everyone

welcome

hi!