This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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.
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
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
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
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.
It seems to stem from an issue with
(:import) statements for google closure modules.
🙂 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
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.