This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-26
Channels
- # aws-lambda (1)
- # beginners (71)
- # boot (70)
- # bristol-clojurians (1)
- # cider (2)
- # clara (13)
- # cljs-dev (96)
- # cljsjs (6)
- # cljsrn (5)
- # clojure (74)
- # clojure-android (3)
- # clojure-austin (4)
- # clojure-dev (10)
- # clojure-russia (6)
- # clojure-spec (28)
- # clojure-uk (128)
- # clojurescript (64)
- # cursive (2)
- # datascript (18)
- # datomic (116)
- # dirac (1)
- # emacs (12)
- # events (10)
- # hoplon (109)
- # jobs (1)
- # jobs-discuss (21)
- # leiningen (2)
- # luminus (6)
- # off-topic (19)
- # om (21)
- # om-next (5)
- # onyx (4)
- # parinfer (29)
- # perun (20)
- # re-frame (53)
- # reagent (21)
- # remote-jobs (5)
- # ring-swagger (2)
- # spacemacs (6)
- # untangled (42)
- # vim (5)
I’m surprised this hasn’t been an issue for anyone before? https://github.com/clojure/clojurescript/commit/cdaeff298e0f1d410aa5a7b6860232270d287084
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.
curious to try it out in Lumo
@anmonteiro I’ve attached it. Testing it some more
hrm. you just needed to rebind env/*compiler*
?
how didn't we catch that before?
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
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)
trying your patch in Lumo now
@mfikes still red
probably something else? it's just weird because 1.9.293 works
ah interesting. it seems it's not related to the require patch at all
I think I know what it is actually
and it's my fault too 🙂
because of the data readers patch, I created cljs/reader.clj
, which is needed when requiring cljs.reader
and I'm hiding it from the build
@mfikes it's blowing the stack now... IIRC you had the same problem, but I don't recall how you solved it
@anmonteiro Here you go: https://github.com/mfikes/planck/blob/a9bc9c925d668c7d65211440440e8d7ded53f638/planck-cljs/src/planck/repl.cljs#L1097-L1113
weird.. maybe I can use a Node.js specific thing to better handle the asynchronicity?
checking now if that's the actual problem
still blows the stack
When I hit that issue, I tried to make Planck async. Planck’s code base was woefully unprepared for that.
probably related
I just tested latest CLJS against one of our apps. Compiles, passes tests, and a quick look around the app showed no obvious issues
@danielcompton thanks for the confirm!
hrm somehow I missed this but the latest released Closure Compiler already has Node resolution support for CommonJS
@juhoteperi maybe this is what you were saying before - we still need to figure out which things in node_modules
to pass as inputs
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)
@richiardiandrea: I'm curious how you'd use clojure.test.check
explicitly. Would you use js/
constructs?
@mfikes the thing that I don't see there is the actual use, so maybe I am missing something
I see only a require and aliases
@richiardiandrea why is that one important for the release?
@dnolen no exactly, it is not super important, I just have some time to have a look at it and solve it 🙂
@richiardiandrea hrm, I think it just needs more thought
k no problem, I was kind of missing some info, I'll wait for your answer on the ticket
@richiardiandrea the problem with js/clojure.spec…
idea is load order
yes I understand that part as it registers the specs for core I guess
I like the last idea...either that or we add test.check
as transitive dep
at the moment it is surprising to get a weird exception when you don't have it
lol nice icon 😄
I don't like adding test.check
as a transitive dep
yeah I mean, warning is way better
having a chat with Chad Killingsworth about how he’s using the Node resolution stuff on the Closure Compiler mailing list
another useful piece of information from that discussion: https://github.com/google/closure-compiler/wiki/Managing-Dependencies#using---dependency_mode-to-drop-unreferenced-files
@dnolen can you point us to the ML discussion?
https://groups.google.com/forum/#!msg/closure-compiler-discuss/fr4UFQYM4dk/qHyyvXNwCwAJ
thanks
if you’re using anything from NPM it’s likely already gone through transpilation for distribution
AFAIK some libraries expect the end user to transpile these days
@anmonteiro hrm I looked around and I had a hard time finding evidence of that
what I mean is people develop their libs with ES6 now
@r0man because we don’t know what changed and it’s simpler to just recompile all dependents
and they distribute it like that?
@anmonteiro what I meant is people don’t distribute ES6
and what you're saying is they do some kind of build step before uploading to NPM?
OK, I'm probably wrong then!
oh right
so yeah, we're both right. just looking at different sides of the spectrum 🙂
I'm sure we'll have reports of ClojureScript users running into those problems
but it's something we don't need to tackle right away of course