This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-19
Channels
- # bangalore-clj (2)
- # beginners (217)
- # boot (3)
- # cider (130)
- # cljs-dev (117)
- # cljsrn (11)
- # clojure (99)
- # clojure-china (1)
- # clojure-denver (1)
- # clojure-dev (22)
- # clojure-italy (30)
- # clojure-norway (5)
- # clojure-russia (13)
- # clojure-sanfrancisco (3)
- # clojure-spec (74)
- # clojure-uk (107)
- # clojurescript (40)
- # clr (6)
- # core-async (25)
- # core-logic (4)
- # cursive (1)
- # data-science (1)
- # datomic (62)
- # duct (11)
- # editors (14)
- # figwheel (3)
- # fulcro (12)
- # funcool (1)
- # garden (12)
- # graphql (19)
- # jobs (4)
- # jobs-rus (1)
- # lein-figwheel (1)
- # leiningen (12)
- # luminus (5)
- # off-topic (45)
- # onyx (12)
- # other-languages (1)
- # parinfer (5)
- # programming-beginners (3)
- # re-frame (113)
- # reagent (63)
- # remote-jobs (10)
- # ring-swagger (1)
- # shadow-cljs (31)
- # slack-help (3)
- # spacemacs (27)
- # specter (1)
- # unrepl (44)
- # yada (16)
geez, once wasm swallows the jvm, project detroit will give us v8 inside of the jvm inside of wasm inside of v8....
So we'll also be able to .postMessage
Clojure code from ClojureScript into a wasm v8 for execution, which can also call into an internal v8 instance. Sort of loopy.
@dnolen
Alright, I think I've finally found my issue. When dependency requires closure modules in a split, they're added to the split, however they're also in :cljs-base
, which results in it being loaded once by the script tag for cljs_base.js
and again for the global eval of cljs.loader/load
.
I've created a simple repo to demonstrate it: https://github.com/Jumblemuddle/cljs-code-split-bug
It's just the code-split test with an added dependency (kibu/pushy, though it also happens with a few other dependencies I've tested: cljs-http, etc.).
Should I create a Jira ticket for this, or am I just doing something wrong? I may have missed a required step when importing dependencies.
@ghopper I have seen the errors you are describing. however, this was before https://github.com/clojure/clojurescript/commit/78b2395960767ea44b68ddd632d1dfe9a4957853 I don't see them now anymore
fixes a lot of long outstanding issues - the most important being non-determinism around printing & evaluation result order
tried to copy your implementation and it connects. Trying to nc localhost 5555
again from a third terminal though throws BindException
I put a lock-free (CAS-based) atom implementation in https://github.com/mfikes/mt-cljs, exploring what it might mean if ClojureScript were to ever support multithreading in JavaScript engines. There has to be tons of corner cases, but, surprisingly the use case exercised there appears to work fine. In other words, it seems to indicate that if multithreading ever became a thing, ClojureScript would be within reach of leveraging it.
I think it will be hard to make Nashorn really work - you still need something like final fields for deftype
@r0man Hmm, this was with a recent build of master. Has anything changed with that in the past month?
This was tested with master, so perhaps it was somehow broken again.
I still need to take a look at that change you linked @r0man and see what was changed exactly.
In terms of release, the documentation suite seems to be fairly close. https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490
@ghopper When I had those problems, some namespaces were missing and the google module loader tried to load those namespaces
This seems to be a different issue then. cljs.loader
is trying to evaluate module code that is already on the page from cljs_base.js
.
Possibly doing something wrong, but when I run the above snippet for a Socket REPL on latest master I get an unable to resolve symbol PrintWriter-on
error
You need the latest clojure 10, alpha 4, iirc
@tmulvaney Clojure 1.10.0-alpha4 is a requirement for the Socket REPL stuff
Ops sorry didn't read the answer there :)
@dnolen Done. I wasn't sure how to use external libraries with just the uberjar. I've removed them and added a deps.edn
now, though I'm not sure how to get the uberjar to use it.
Ok, good to know. :thumbsup: Thanks
It's just an example of a cljs library which required google closure modules. The same occurs with e.g. cljs-time
and others.
@ghopper so you can’t reproduce if the closure modules don’t come via transitive deps in JARs?
Actually, that's a good test case I haven't done yet... Sorry I'll try pulling the code from both libraries into the project directly.
It could very well be the way those two libraries are including the modules that's the problem. I'll get back to you.
@dnolen Good call; that definitely wasn't minimal.
https://github.com/Jumblemuddle/cljs-code-split-bug
It seems to stem from an issue with (:import)
statements for google closure modules.
Awesome!
🙂 Thanks Let me know if there's anything else I can do.
@jannis we could but I don’t think so, for you it just worked w/o explicit configuration
I’d like to be conservative about explaining all these NPM knobs until a lot more stuff is working
This provides a nice way to have config in your :main-opts
prior to https://dev.clojure.org/jira/browse/TDEPS-56 being fixed 🙂
I never got to the bottom of https://clojurians.slack.com/archives/C07UQ678E/p1520888811000578
and it will stay that way - there are hooks present if you want to reuse the architecture
I'm pretty sure @bhauman had an example deps.edn config up somewhere that did something like this, I just can't find it
@dnolen that is awesome!
(I surely would need to find other adjectives)
I know we discussed about this approach but I think folks would expect :main
to work there as well...basically a better solution to this https://dev.clojure.org/jira/browse/CLJS-2612
@richiardiandrea fixing that
@dnolen If you call :package-json-resolution :nodejs
“w/o explicit configuration” then yes. The default is still a mode that doesn’t work with e.g. graphql-js.
@dnolen It's not just goog.History
though, it also happens when importing others. I don't know what exactly at the moment though.
Give me a minute to get my context again.
from what I’m seeing right now, there’s just some kinds of Closure namespaces we can’t handle
Putting a breakpoint (in Chrome Devtools) on line 222 of goog/module/moduleloader.js shows what the error was when evaluating.
The issue is that it's trying to load an already loaded module (`goog.dom.InputType` in this case). This module isn't actually loaded at all if the import of goog.History
is removed, it seems like it should be a dependency of :b
, but it ends up also being loaded on the page by :cljs-base
.
Closure namespaces with multiple provides certainly seems to be the source of the issue.
Fair enough. I'm definitely unfamiliar with a lot of this. Thanks
it’s a good catch, surprised it wasn’t reported before, but maybe particular to :none
is why
I believe this is only for :none
, though I haven't really A/B tested it.