Fork me on GitHub
#cljs-dev
<
2018-06-26
>
roman01la09:06:43

Is this a bug?

clojure => (int \z) ;; 122
cljs => (int \z) ;; 0 (warning all arguments must be numbers)

roman01la09:06:22

for this to work in cljs int should do .charCodeAt on a string

mfikes11:06:52

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.

pesterhazy11:06:25

I noticed this today as well. Trouble is that Javascript doesn't distinguish between char and string

mfikes11:06:36

Yeah, I would chalk it up as a hosty difference that, if attempted to smooth over, would be at odds with perf.

pesterhazy11:06:38

Plus, what would (int "aa") return?

pesterhazy11:06:03

(Given that "aa" and \a have the same type)

mfikes11:06:48

This doesn't work in Clojure, which is related.

(subvec (into [] (range 256)) \a)
I think it is water under the bridge, but perhaps Clojure's int should never have worked on character types.

alexmiller12:06:32

That is one of its primary uses, so disagree

mfikes11:06:44

(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.)

roman01la11:06:01

Agreed about overall perf impact. Not sure if this should be addressed via type hint?

bhauman11:06:29

@mfikes I'm tracking down the printing behavior during the ClojureScript test run

bhauman11:06:57

it seems to be a side effect of calling prop/for-all in two different tests

bhauman11:06:04

which is strange

mfikes11:06:37

Odd. At least it didn't cause a dancing frog to jump out of a cigar box 🙂

1
bhauman12:06:17

actually its two different defspecs I commented them out and then it ran no problem

bhauman12:06:36

and defspec is only used twice in the cljs test suite, and I get the same behavior in chrome and safari, what the heck is defspec doing

mfikes12:06:20

You get the print dialog opening in Chrome as well. WTF?

bhauman12:06:12

yes two different times, exactly when defspec is called

mfikes12:06:00

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.

bhauman12:06:45

@mfikes (set-print-fn! js/print) in the test runner

bhauman12:06:07

that's the cause

mfikes12:06:13

Those unit tests aren't often executed directly from within a browser. So, unrelated completely to your test result display code.

bhauman12:06:43

and they run fast now

bhauman12:06:51

so very cool

mfikes12:06:00

Nice. The attempt to print also explained the lag?

bhauman12:06:23

I think the initial lag is all the loading involved

bhauman12:06:38

This was a good reminder that I need renderers for test.check output though

mfikes12:06:38

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)

mfikes13:06:00

The issue mentioned above regarding Specter has been fixed downstream https://github.com/nathanmarz/specter/commit/e7abb2b5384b0b64d871fb347be7c34a15473eb2 and Canary is passing again.

👍 2
mikerod00:06:16

@mfikes any background info on why those change was needed? I’d have thought it is equivalent as far as correctness goes.

mfikes00:06:35

@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.

mfikes00:06:10

TL;DR, types matter to that particular code—with the difference between cljs.core/Subvec and cljs.core/PersistentVector being important.

mikerod00:06:16

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.