This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-08
Channels
- # alda (1)
- # announcements (18)
- # babashka (101)
- # beginners (110)
- # calva (17)
- # cider (53)
- # clara (18)
- # clj-kondo (26)
- # cljdoc (6)
- # clojure (152)
- # clojure-europe (9)
- # clojure-portugal (4)
- # clojure-spec (20)
- # clojure-survey (7)
- # clojure-sweden (10)
- # clojure-uk (10)
- # clojured (1)
- # clojurescript (29)
- # core-async (7)
- # cursive (4)
- # datomic (11)
- # defnpodcast (2)
- # dirac (1)
- # emacs (13)
- # events (2)
- # figwheel-main (1)
- # fulcro (1)
- # jobs (14)
- # jobs-discuss (17)
- # leiningen (2)
- # malli (1)
- # off-topic (74)
- # overtone (1)
- # pedestal (4)
- # planck (2)
- # re-frame (7)
- # reitit (4)
- # remote-jobs (4)
- # shadow-cljs (78)
- # slack-help (3)
- # spacemacs (56)
- # test-check (3)
- # tools-deps (6)
Hello, I believe I am neck deep in a "Jar hell" problem and need a deeper understanding of cljs internals to figure it out.
The problem manifests itself when I upgrade datomic and run cljs via the lein-cljsbuild plugin. Upgrading com.datomic/datomic-pro "0.9.5981"
to .6014
causes cljs to not be able to parse ##NaN
. The only jars this upgrade changes is datomic-pro
and datomic-client
so I don't see how it could even affect cljs, but nonetheless:
When I start a cljs repl with lein trampoline cljsbuild repl-rhino
and datomic .6014
in my project.clj
dependencies:
cljs.user=> *clojurescript-version*
"1.10.597"
cljs.user=> ##NaN
Syntax error reading source at (REPL:1).
Reader tag must be a symbol
But with datomic .5981
:
cljs.user=> *clojurescript-version*
"1.10.597"
cljs.user=> ##NaN
##NaN
On the JVM side, the deps trees and classpaths are identical except for the datomic jars.
On the cljs side you can see it reports the same cljs version. From splunking around with source
and doc
as near as I can tell the tools.reader
version is the same too.
How would I even go about debugging this problem further?That's interesting. Would it be possible to publish an example where I could check it out?
you can check complete dependency tree for difference between “before upgrade” and “after” to spot “real” difference after resolving
command lein deps :tree
should help if I remember correctly
lein deps :tree
shows that the only difference is datomic-pro
and datomic-client
. No other changes 😞
Unfortunately I can't post this project. This is a very large proprietary codebase. I'm going to work on a reproduction with minimal dependencies but I have a feeling it will work fine if I strip everything out, otherwise everyone would be having this problem.
> I have a feeling it will work fine if I strip everything out That's exactly why I usually ask for a minimal reproducible example. :) Often, when I just create it myself, it ends up working on my side.
If so, try to see what namespaces they declare. It may be that one of them has a higher priority than tools.reader
and overrides the clojure.tools.reader
namespace with some older version that doesn't support ##NaN
.
maybe you have a dep that is an uberjar including its deps? certainly that can happen, is bad, and is hard to discern.
if so, it's a matter of looking in each jar to see if it contains tools.reader code till you find it, but you might be able to make an educated guess as to where to start
oz was distributing uberjars, which included tools.reader, not sure if they still are
Thomas from what I can understand, the tools.reader in my clojure repl is fine. ##NaN
works there. It's clojurescript that is the problem. There's no equivalent for cljs, right? It'd be cljs.tools.reader
that is the problem?
@U064X3EF3 it looks like datomic-pro-0.9.6014.jar
and datomic-pro-0.9.6021.jar
include tools.reader
(and tools.analyzer
and core.async
for what it's worth)
hmm, might be a good question to take up in #datomic - I'm not too familiar with the design there
2272 02-13-2019 13:46 clojure/tools/reader$read_dispatch.class
1473 02-13-2019 13:46 clojure/tools/reader$unquote_splicing_QMARK_.class
3223 02-13-2019 13:46 clojure/tools/reader$read_string_STAR_.class
clojurescript has always included AOT compiled versions of tools.reader and data.json
ideally, they should probably shade those
@philip something else to consider is I don't really see why datomic and your cljs tooling needs to share a classpath
ClojureScript is build time only - it's quite common that it will never be involved with runtime ever
so sharing the classpath isn't meaningful and of course open you up to these kinds of time wasters
for the past year so when using deps, I have an alias just for ClojureScript and I keep all deps related to ClojureScript separate from stuff that will be actually deployed
(you might be doing some kind of embedded REPL based workflow then of course the other suggestions might be more relevant)
@dnolen (I work with @philip) we embed figwheel with our backend jvm for our dev workflow. This issue is exposed running cljs tests so we could have a separate classpath for that. We compile the cljs separately for our prod builds but historically it is compiled at service startup for dev builds (so we can turn on debug/change optimizations without redeploying) It turns out that the datomic jar is also now including AOT compiled tools.reader code which is what surfaced this issue.