This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-02
Channels
- # aleph (6)
- # beginners (37)
- # boot (415)
- # cider (17)
- # cljs-dev (79)
- # cljsjs (3)
- # cljsrn (18)
- # clojars (3)
- # clojure (34)
- # clojure-france (6)
- # clojure-italy (1)
- # clojure-korea (1)
- # clojure-russia (22)
- # clojure-spec (64)
- # clojure-uk (47)
- # clojurebridge (6)
- # clojurescript (61)
- # clojurex (1)
- # cloverage (11)
- # component (6)
- # cursive (73)
- # data-science (6)
- # datascript (4)
- # datomic (38)
- # editors (1)
- # emacs (4)
- # events (16)
- # funcool (5)
- # garden (3)
- # hoplon (17)
- # jobs (2)
- # klipse (74)
- # off-topic (3)
- # om (81)
- # onyx (35)
- # parinfer (4)
- # pedestal (1)
- # perun (20)
- # planck (9)
- # proton (1)
- # re-frame (17)
- # reagent (3)
- # ring-swagger (1)
- # rum (7)
- # untangled (63)
- # vim (8)
@dnolen the biggest problem I found in my experiments were conditional require
calls, something closure doesn't support. did you run into this by any chance yet? maybe it has been solved somehow?
that and several non-closure patterns like process.env.NODE_ENV
React uses all over the place
@thheller this is about a new WIP implementation of the resolution algorithm. for context: https://github.com/google/closure-compiler/pull/2094
not sure if you saw this yet, but it seemed to me you didn't have this new information yet?
oh I get it
right, resolution or not, conditional requires were/are a problem in Closure
ah right
It's highlighted for me
yeah it still does, I think Juho pasted some examples
@thheller from the backlog: https://github.com/kriskowal/asap/blob/master/raw.js#L81
this was one of the problems
unfortunately the JS world doesn't have the strict rules Closure has, so there are quite a few ugly hacks arround
but when I tested it it still was node_module/foo/node_modules/bar/node_modules/baz
...
I think Yarn solves that problem with the lockfile
but I'm unsure
While npm2 installs all dependencies in a nested way, npm3 tries to mitigate the deep trees and redundancy that such nesting causes. npm3 attempts this by installing some secondary dependencies (dependencies of dependencies) in a flat way, in the same directory as the primary dependency that requires it.
@thheller right there’s no way around the conditional require problem - but I’m not really concerned about all that stuff - not our problem
Very weird behaviour of setTimeout: 0-msec timers are actually 4-msec timers
The same happens with core.async timeouts:
(go
(time (dotimes [i 100]
(<! (timeout 1)))))
It takes around 330 msec
@viebel yeah that's documented somewhere
I know:
you can use goog.async.nextTick
@anmonteiro I was expecting core.async to use goog.async.nextTick
for 0-msec timers
But there also queue-delay
that calls setTimeout and is used inside timeout
AFAIK core.async uses nextTick
to chain async ops, but it must interleave chained async ops with setTimeout
to prevent browser starvation in some edge cases
the smallest dispatch gap in browsers you can achieve that I’ve observed is something like 0.025ms
but it’s not possible to replicate that everywhere - thus goog.async.nextTick
- you get what you get
@darwin we don’t do anything specific - whatever dispatch mechanism you use will have enough latency to prevent starvation
in pure js, using postMessage, I was able to send/read 100 messages in ~20 msec in Chrome
Which one is the fastest for dispatch?
But anyway, why on Chrome core.async (timeout 0) is implemented with setTimeout(0) and not goog.async.nextTick?
Clojure(Script) core.async already uses timeout coalescing here for less than 10ms between timeout
calls - so there aren’t any interesting precision guarantees here as it is
You mean that we need time to run core.async
code before the timers code run
btw. just FYI, got bitten by core.async timeout
by not understanding its internal implementation once:
https://groups.google.com/forum/#!topic/clojure-dev/5uIH6iyvM6I