This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-26
Channels
- # admin-announcements (2)
- # aws (1)
- # beginners (21)
- # boot (61)
- # cider (5)
- # cljs-dev (94)
- # cljsrn (35)
- # clojure (106)
- # clojure-austin (3)
- # clojure-belgium (1)
- # clojure-dev (4)
- # clojure-dusseldorf (9)
- # clojure-greece (2)
- # clojure-mexico (1)
- # clojure-russia (40)
- # clojure-spec (61)
- # clojure-uk (17)
- # clojurescript (151)
- # code-art (1)
- # component (7)
- # core-async (4)
- # cursive (1)
- # datomic (9)
- # dirac (55)
- # funcool (12)
- # hoplon (118)
- # incanter (12)
- # jobs (8)
- # juxt (1)
- # lein-figwheel (6)
- # mount (2)
- # off-topic (2)
- # om (76)
- # onyx (28)
- # other-lisps (1)
- # planck (7)
- # re-frame (9)
- # reagent (13)
- # ring-swagger (2)
- # specter (1)
- # yada (22)
file an issue in JIRA with the minimal ClojureScript source needed to reproduce the issue
@dnolen: I can create an example with just a cljs file and no other dependencies. But the variables will be there as its that particular alignment of things which is triggering the issue. Thank you!
@dnolen: I’ve filed the issue: http://dev.clojure.org/jira/browse/CLJS-1649
@dnolen: the real doozy (atleast for me) is when you get the expected behaviour by doing any of the things listed in How to get the expected behaviour
they seem to be completely orthogonal to the problem in my eyes. but they address the issue.
@rohit I seem to remember a similar issue where embedding large strings in code caused problems
have you tried loading the edn string via some other mechanism? instead of embedding in code?
@thheller: i’ve tried loading file from the filesystem using node.js and i get the same behaviour.
here’s that work: https://github.com/ducky427/cljs-bug
even weirder: if your remove lines 3166-3181 in a custom cljs build, things work again. https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/pprint.cljs#L3166-L3181
@dnolen: In the unlikely event that it matters for ClojureScript spec
, just a heads up that there is a patch pending that would extend test.check
to self-hosted ClojureScript: http://dev.clojure.org/jira/browse/TCHECK-105
@rohit just verified that the bug you are seeing is related to hashing. we have seen things like that before, added comment in JIRA
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/reader.cljs#L352
hi, I have a headaches reading a serialized clojuer map from clojurescript, the problem is a map key-value :pprint-fn #function[cider.nrepl.middleware.pprint/wrap-pprint-fn/fn--24400/fn—24402]
, it gets produced by https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/pprint.clj#L50
@rohit nah it is just the caching. the compiler precomputes the hash (in clojure) when compiling
I tried to use cljs.reader/read, cljs.tools.reader/read and cljs.tools.reader.edn/read
all of them are failing to read that “symbol" cider.nrepl.middleware.pprint/wrap-pprint-fn/fn--24400/fn—24402
I will probably have to monkey-patch parse-symbol
😞
https://github.com/clojure/tools.reader/blob/master/src/main/cljs/cljs/tools/reader/impl/commons.cljs#L96
people who wrote cider middleware didn’t expect those messages to be parsed by anything outside clojure (their own nrepl process) https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/pprint.clj#L50
@thheller: for hashing a keyword, it seems that the following are needed: m3-hash-unencoded-chars
of the name of the keyword and hash-string
of its ns.
i’ve found that m3-hash-unencoded-chars
is the same for the reader and normal :version
but the hash-string
is different for both
looking at the code of hash-string
, there seems to be some sort of global cache: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L849
@rohit this just sounds like a simple hashing bug - we want the actual fix - not using the cache is not the answer
@dnolen: i’ve proposed a fix which addresses this issue in the jira issue page: http://dev.clojure.org/jira/browse/CLJS-1649
@dnolen: essentially we shouldn’t be putting nil
as a key in the cache as it gets converted to ”null”
my name is there on this list: http://clojure.org/community/contributors
FAIL in (test-nil-hashing-cljs-1649) (J_@builds/out-adv/core-advanced-test.js:1021:83) expected: (pos? (hash-string nil)) actual: (not (pos? 0))
good job @rohit
@richiardiandrea: thanks! 😊