Fork me on GitHub
#cljs-dev
<
2016-11-02
>
thheller09:11:13

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

thheller09:11:34

that and several non-closure patterns like process.env.NODE_ENV React uses all over the place

thheller09:11:44

but it has been a while, maybe it all changed

anmonteiro10:11:43

@thheller this is about a new WIP implementation of the resolution algorithm. for context: https://github.com/google/closure-compiler/pull/2094

anmonteiro10:11:03

not sure if you saw this yet, but it seemed to me you didn't have this new information yet?

thheller10:11:13

that doesn't matter

anmonteiro10:11:40

right, resolution or not, conditional requires were/are a problem in Closure

thheller10:11:01

juhoteperi seems to have run into it, IIRC object-assign was one of the bad ones

thheller10:11:09

or any polyfill really

thheller10:11:30

Object.assign = Object.assign || require('object-assign'); things like that

thheller10:11:02

why doesn't that highlight 😛

anmonteiro10:11:10

It's highlighted for me

thheller10:11:19

hehe not for me

thheller10:11:32

anyways ... React used to have some of those

thheller10:11:43

that closure can't do conditional require

anmonteiro10:11:49

yeah it still does, I think Juho pasted some examples

anmonteiro10:11:48

this was one of the problems

thheller10:11:04

yeah things like that

thheller10:11:00

unfortunately the JS world doesn't have the strict rules Closure has, so there are quite a few ugly hacks arround

thheller10:11:31

pre-bundled things like React can work since they eliminate some of the hacks

thheller10:11:46

but React via npm is probably way off

thheller10:11:54

another things was the way npm structured dependencies

thheller10:11:14

I think npm at some point went for a flat structure

thheller10:11:45

but when I tested it it still was node_module/foo/node_modules/bar/node_modules/baz ...

thheller10:11:58

where each dependency was nested

thheller10:11:15

and multiple versions of the same lib where used

thheller10:11:31

I still have nightmares 😛

anmonteiro10:11:01

I think Yarn solves that problem with the lockfile

anmonteiro10:11:04

but I'm unsure

thheller10:11:59

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.

thheller10:11:09

keyword is some though

dnolen12:11:51

@thheller right there’s no way around the conditional require problem - but I’m not really concerned about all that stuff - not our problem

Yehonathan Sharvit13:11:04

Very weird behaviour of setTimeout: 0-msec timers are actually 4-msec timers

Yehonathan Sharvit13:11:38

The same happens with core.async timeouts:

(go
  (time (dotimes [i 100]
        (<! (timeout 1)))))

Yehonathan Sharvit13:11:47

It takes around 330 msec

anmonteiro13:11:53

@viebel yeah that's documented somewhere

anmonteiro13:11:04

you can use goog.async.nextTick

Yehonathan Sharvit13:11:24

@anmonteiro I was expecting core.async to use goog.async.nextTick

Yehonathan Sharvit13:11:09

But there also queue-delay that calls setTimeout and is used inside timeout

darwin13:11:36

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

darwin13:11:07

see TASK_BATCH_SIZE

darwin13:11:20

or maybe not 🙂

dnolen13:11:30

the smallest dispatch gap in browsers you can achieve that I’ve observed is something like 0.025ms

dnolen13:11:56

but it’s not possible to replicate that everywhere - thus goog.async.nextTick - you get what you get

dnolen13:11:40

@darwin we don’t do anything specific - whatever dispatch mechanism you use will have enough latency to prevent starvation

dnolen13:11:04

the batch size is so that we can get more work done inbetween these gaps

Yehonathan Sharvit13:11:37

in pure js, using postMessage, I was able to send/read 100 messages in ~20 msec in Chrome

dnolen13:11:55

right, but that’s just Chrome

dnolen13:11:00

there’s lots of JS environments

Yehonathan Sharvit13:11:11

Which one is the fastest for dispatch?

dnolen13:11:26

postMessage was - but it wasn’t consistent across browsers

dnolen13:11:47

implementation / performance stuff we cannot deliver in any consistent way

Yehonathan Sharvit13:11:19

But anyway, why on Chrome core.async (timeout 0) is implemented with setTimeout(0) and not goog.async.nextTick?

dnolen13:11:54

@viebel because nextTick doesn’t give you a time to dispatch

dnolen13:11:58

it’s that simple

dnolen13:11:12

we don’t care that timeout < 4 ms is meaningless

dnolen13:11:37

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

Yehonathan Sharvit13:11:15

You mean that we need time to run core.async code before the timers code run

dnolen13:11:32

no, I meant exactly what I said above

dnolen13:11:12

nextTick doesn’t take a delay argument

darwin13:11:25

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

dnolen13:11:47

yes people have complained here an there about timeout

dnolen13:11:58

take it up elsewhere

dnolen13:11:04

it’s not that relevant for #cljs-dev 🙂