Fork me on GitHub
#cljs-dev
<
2017-01-26
>
mfikes01:01:59

I’ve found the root cause of the self-hosted stuff. Will attach a patch to http://dev.clojure.org/jira/browse/CLJS-1906 shortly.

anmonteiro01:01:53

curious to try it out in Lumo

mfikes01:01:08

@anmonteiro I’ve attached it. Testing it some more

anmonteiro01:01:37

hrm. you just needed to rebind env/*compiler*?

anmonteiro01:01:41

how didn't we catch that before?

mfikes01:01:44

A nice aspect of the patch is that it follows a similar pattern of binding another var next to a place where we needed to earlier

mfikes01:01:08

I don’t think it can affect Planck because Planck uses sync callbacks, while script/test-self-parity uses Node’s async file reading capability to load namespaces. (My best guess at the moment.) The async aspect lets things go unbound with the async callback occurring later (sketchy theory)

mfikes01:01:18

Same thing for Lumo presumably?

mfikes01:01:28

My hunch is that Lumo’s AOT-macro-compilation hang is rooted in something else.

anmonteiro01:01:54

trying your patch in Lumo now

anmonteiro02:01:16

probably something else? it's just weird because 1.9.293 works

anmonteiro02:01:56

ah interesting. it seems it's not related to the require patch at all

mfikes02:01:30

Ahh. I smell a git bisect coming up 🙂

anmonteiro02:01:48

I think I know what it is actually

anmonteiro02:01:56

and it's my fault too 🙂

anmonteiro02:01:24

because of the data readers patch, I created cljs/reader.clj, which is needed when requiring cljs.reader

anmonteiro02:01:29

and I'm hiding it from the build

anmonteiro02:01:09

@mfikes it's blowing the stack now... IIRC you had the same problem, but I don't recall how you solved it

mfikes02:01:31

Ahh… digging that up for you...

anmonteiro02:01:36

weird.. maybe I can use a Node.js specific thing to better handle the asynchronicity?

anmonteiro02:01:11

checking now if that's the actual problem

anmonteiro02:01:38

still blows the stack

mfikes02:01:42

When I hit that issue, I tried to make Planck async. Planck’s code base was woefully unprepared for that.

anmonteiro02:01:00

probably related

mfikes02:01:02

Hrm. Perhaps it is difficult to monkey patch in early enough.

danielcompton04:01:59

I just tested latest CLJS against one of our apps. Compiles, passes tests, and a quick look around the app showed no obvious issues

dnolen16:01:42

@danielcompton thanks for the confirm!

dnolen17:01:44

hrm somehow I missed this but the latest released Closure Compiler already has Node resolution support for CommonJS

dnolen17:01:48

the pending PR is just about ES6

dnolen17:01:28

@juhoteperi maybe this is what you were saying before - we still need to figure out which things in node_modules to pass as inputs

richiardiandrea18:01:23

any interest in fixing http://dev.clojure.org/jira/browse/CLJS-1792 before the release by any chance (I understand it is not priority but pretty surprising for spec users in cljs)

mfikes18:01:06

@richiardiandrea: I'm curious how you'd use clojure.test.check explicitly. Would you use js/ constructs?

richiardiandrea18:01:49

@mfikes the thing that I don't see there is the actual use, so maybe I am missing something

richiardiandrea18:01:02

I see only a require and aliases

dnolen18:01:46

bumped Closure Compiler dep, might want to test on your projects again

dnolen18:01:14

@richiardiandrea why is that one important for the release?

richiardiandrea18:01:20

@dnolen no exactly, it is not super important, I just have some time to have a look at it and solve it 🙂

dnolen18:01:09

@richiardiandrea hrm, I think it just needs more thought

richiardiandrea18:01:01

k no problem, I was kind of missing some info, I'll wait for your answer on the ticket

dnolen18:01:27

@richiardiandrea the problem with js/clojure.spec… idea is load order

dnolen18:01:45

you have to know to load it yourself first

richiardiandrea18:01:32

yes I understand that part as it registers the specs for core I guess

dnolen18:01:44

we could special case the test.check nses

dnolen18:01:55

and allow those to get through

dnolen18:01:01

and depend on runtime errors to inform the user

dnolen18:01:08

but more problems (no spec cases)

dnolen18:01:17

so I don’t know

dnolen18:01:21

I don’t have any good ideas

dnolen18:01:34

one idea is just a warning

dnolen18:01:40

a special case for spec nses that need test.check

dnolen18:01:46

we can warn if test.check isn’t on the classpath

richiardiandrea18:01:03

I like the last idea...either that or we add test.check as transitive dep

richiardiandrea18:01:28

at the moment it is surprising to get a weird exception when you don't have it

richiardiandrea18:01:38

lol nice icon 😄

anmonteiro18:01:49

I don't like adding test.check as a transitive dep

dnolen18:01:12

I’m OK with the warning that checks classpath

richiardiandrea18:01:14

yeah I mean, warning is way better

dnolen18:01:51

having a chat with Chad Killingsworth about how he’s using the Node resolution stuff on the Closure Compiler mailing list

dnolen18:01:56

this came up - looks useful

anmonteiro22:01:27

@dnolen can you point us to the ML discussion?

dnolen22:01:06

I think module-deps looks really promising

dnolen22:01:18

it dumps a JSON file with paths to all the files

dnolen22:01:40

module-deps does seem specific to CommonJS though

dnolen22:01:30

but maybe that doesn’t matter

dnolen22:01:49

if you’re using anything from NPM it’s likely already gone through transpilation for distribution

anmonteiro22:01:37

AFAIK some libraries expect the end user to transpile these days

r0man22:01:21

Ah, and say we are only talking about optimization :none

dnolen23:01:58

@anmonteiro hrm I looked around and I had a hard time finding evidence of that

anmonteiro23:01:58

what I mean is people develop their libs with ES6 now

dnolen23:01:08

@r0man because we don’t know what changed and it’s simpler to just recompile all dependents

anmonteiro23:01:20

and they distribute it like that?

dnolen23:01:36

@anmonteiro what I meant is people don’t distribute ES6

anmonteiro23:01:39

and what you're saying is they do some kind of build step before uploading to NPM?

anmonteiro23:01:08

OK, I'm probably wrong then!

dnolen23:01:14

I mean I’m sure some small random libs do that

dnolen23:01:21

but I have a hard time believing popular ones do

anmonteiro23:01:55

so yeah, we're both right. just looking at different sides of the spectrum 🙂

anmonteiro23:01:18

I'm sure we'll have reports of ClojureScript users running into those problems

anmonteiro23:01:26

but it's something we don't need to tackle right away of course

r0man23:01:13

@dnolen just simpler or necessary? I'm asking because in one of my ClojureScript apps my Figwheel reload time goes up to 8s. A lot of files that aren't direct dependencies are getting recompiled. This adds up quite a bit. Looking for a way to speed this up.

dnolen23:01:35

@r0man :recompile-dependents is a compiler flag you can disable it

r0man23:01:32

ah, cool. totally forgot about this. thx!

r0man23:01:36

also tested the latest master. works fine so far

dnolen23:01:21

great! thanks