This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (2)
- # beginners (69)
- # boot (37)
- # cider (6)
- # clara (31)
- # cljs-dev (75)
- # cljsrn (5)
- # clojure (72)
- # clojure-dev (7)
- # clojure-italy (11)
- # clojure-nl (8)
- # clojure-russia (2)
- # clojure-spec (56)
- # clojure-uk (54)
- # clojure-za (1)
- # clojurescript (156)
- # cursive (2)
- # datomic (34)
- # emacs (1)
- # fulcro (227)
- # hoplon (74)
- # jobs (1)
- # jobs-discuss (16)
- # leiningen (5)
- # lumo (17)
- # off-topic (9)
- # om (3)
- # onyx (10)
- # other-languages (1)
- # portkey (2)
- # re-frame (2)
- # reagent (36)
- # reitit (1)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (85)
- # slack-help (2)
- # spacemacs (6)
- # specter (3)
- # sql (17)
- # test-check (15)
- # tools-deps (80)
Is this a bug?
clojure => (int \z) ;; 122 cljs => (int \z) ;; 0 (warning all arguments must be numbers)
It would be nice if
int were consistent, this appears to be a hosty difference in that, in Java,
char is easily treated as a numeric.
Yeah, I would chalk it up as a hosty difference that, if attempted to smooth over, would be at odds with perf.
This doesn't work in Clojure, which is related.
I think it is water under the bridge, but perhaps Clojure's
(subvec (into  (range 256)) \a)
intshould never have worked on character types.
(If you take a peek at ClojureScript's
subvec you would see that messing with
int would all of the sudden either make that code start working and/or slow it down.)
Agreed about overall perf impact. Not sure if this should be addressed via type hint?
defspec is only used twice in the cljs test suite, and I get the same behavior in chrome and safari, what the heck is
Canary detected an issue with Spector. I'm inclined to believe that Spector is making an unwarranted assumption about
vec and created an issue there https://github.com/nathanmarz/specter/issues/261
Please chime in if you think my view is misplaced.
Those unit tests aren't often executed directly from within a browser. So, unrelated completely to your test result display code.
It is hilarious that
js/print can either mean sense 2a "to make a copy of by impressing paper against an inked printing surface" or 2d: "to display on a surface (such as a computer screen) for viewing" (Merriam Webster)
The issue mentioned above regarding Specter has been fixed downstream https://github.com/nathanmarz/specter/commit/e7abb2b5384b0b64d871fb347be7c34a15473eb2 and Canary is passing again.
@mfikes any background info on why those change was needed? I’d have thought it is equivalent as far as correctness goes.
@U0LK1552A That particular bit of code is being used in a context which extends a protocol to
cljs.core/Subvec. A consequence of the optimization on master (for CLJS-2442) is that
vec directly returns any subvec passed to it. This causes the Specter code to dispatch back to the same extension for
cljs.core/Subvec, and thus leads to infinite recursion. The intent of the Specter code is to convert the subvec to a persistent vector instance (not a subvec of a persistent vector), so
into  suffices to achieve the intent.
TL;DR, types matter to that particular code—with the difference between
cljs.core/PersistentVector being important.
Ah ok. That makes sense. I know specter does a lot of digging at types to try to achieve high performance etc. so it makes sense that kind of edge case could creep in. Thanks for the details.
@mfikes could you help me understand what cljs code this test is compiling? https://github.com/clojure/clojurescript/blob/master/src/test/self/self_host/test.cljs#L141-L153