This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-01
Channels
- # 100-days-of-code (5)
- # adventofcode (234)
- # aleph (13)
- # announcements (2)
- # architecture (3)
- # bangalore-clj (1)
- # beginners (312)
- # calva (7)
- # cider (6)
- # cljdoc (3)
- # cljs-dev (30)
- # cljsrn (2)
- # clojure (40)
- # clojure-austin (2)
- # clojure-dev (65)
- # clojure-greece (1)
- # clojure-italy (29)
- # clojure-kc (1)
- # clojure-russia (2)
- # clojure-uk (26)
- # clojurebridge (1)
- # clojurescript (4)
- # cursive (11)
- # data-science (1)
- # datomic (43)
- # docker (1)
- # duct (7)
- # emacs (3)
- # figwheel-main (7)
- # fulcro (8)
- # garden (3)
- # graphql (8)
- # hyperfiddle (4)
- # off-topic (10)
- # other-languages (12)
- # pathom (4)
- # portkey (1)
- # remote-jobs (3)
- # rum (8)
- # shadow-cljs (40)
- # tools-deps (68)
- # unrepl (2)
- # vim (5)
The "improvements to exception messages and printing" work has progressed to the point where you can see the light at the end of the tunnel. It is probably just a matter of use and banging out rough edges now. See https://gist.github.com/mfikes/cca647f962f38edb599596f8e7bffc43
In the end, it might help if tools.reader
had some mild updates (with respect to what is put in its exception message strings), but it appears we can pull this off without strictly needing a change in tools.reader
.
since Clojure 1.10 is around the corner I think we should focus our efforts on fixing up spec and aligning changes
Cool. the only thing I saw so far @bronsa is for example that the reader error for 08
includes line and column number info in the message string. Perhaps we can get things working in ClojureScript and we can then determine if tools.reader
changes to messages might improve the experience, without breaking anything or making a hard dependency.
FWIW, unit tests on master are currently broken. I may take a look at them later on today. https://github.com/mfikes/clojurescript/commits/master
Cool, https://dev.clojure.org/jira/browse/CLJS-2997 ^, marked as Blocker.
@dnolen damn, I already thought I missed this case, but since the tests worked I wasn’t sure about that one: https://github.com/clojure/clojurescript/commit/ad07bbd3ed5c9108e156983ce4a1d289a0f768dc
it seems before the recent patch in that area by me and David, that case wasn’t spec-checked either: https://github.com/clojure/clojurescript/blob/6353a9b381144d6d0caa621322af9587922e7c07/src/main/cljs/cljs/spec/test/alpha.cljs#L127 that’s why I was unsure about it..
if there are all these special cases for arities, in what case will the “normal” ret
fn body be called?
and when it’s not pure-variadic but has a variadic case (so one or more fixed + varargs arguments) it ends up here: https://github.com/clojure/clojurescript/blob/6353a9b381144d6d0caa621322af9587922e7c07/src/main/cljs/cljs/spec/test/alpha.cljs#L127
If you have a max fixed arity of say, 3, args will come in as a sequence like [1 2 3 [4 5 6]]
I encountered this problem in CLJ spec which probably also affects CLJS spec: https://dev.clojure.org/jira/browse/CLJ-2443 But it’s still being triaged.