Fork me on GitHub
#cljs-dev
<
2016-03-23
>
danielcompton04:03:54

Can anyone explain why the literal 08 and 09 causes ClojureScript compiling to fail? 07 is fine. I’m guessing it’s some kind of octal thing?

mfikes04:03:50

It is interesting that bootstrapped behaves differently (uses a different reader, and lets those pass).

danielcompton04:03:05

what value does it return for 08 and 09?

mfikes04:03:05

But, yes, that’s pretty common. For example:

$ perl -e 08
Illegal octal digit '8' at -e line 1, at end of line

mfikes04:03:31

Bootstrapped parses those as decimal 8 and 9

mfikes04:03:42

Probably a bug in the bootstrapped reader

slipset08:03:17

luckily, the numberreader in the clojure parser is using a somewhat complex regex to figure out how this is done:

slipset08:03:52

static Pattern intPat =
		Pattern.compile(
				"([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?”);

slipset08:03:30

which is basically present in tools.reader as well

slipset08:03:35

(def int-pattern #"^([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|(0[0-9]+))(N)?$”)

slipset08:03:11

The thing is that tools.reader matches on group 8, which is (0[0-9]+)

slipset09:03:00

seems like tools.reader is happy to accept invalid octal numbers as decimals...

slipset09:03:17

this is reflected in the tests

slipset09:03:40

crap! @bronsa beat me to the patch simple_smile

bronsa09:03:04

ah, sorry simple_smile

bronsa09:03:43

wasn't paying attention to this channel -- mention me or assign yourself to the ticket next time

slipset09:03:32

I got a bit worried by the tests, since they sort of documented that invalid octal numbers should be parsed as decimal

bronsa09:03:53

yeah, not really sure what that was about. I didn't author the original cljs port

bronsa09:03:05

but that was definitely unwanted behaviour

slipset09:03:36

of course it depends, parseInt(“09”) returns 9

slipset09:03:52

So, it depends on how hosted you are simple_smile

bronsa09:03:02

well, we want to be coherent with clojure, not js

anmonteiro15:03:14

@dnolen: I've opened the issue regarding specify!, but I couldn't stop myself from exploring it a bit further and I think I've found the bug

anmonteiro15:03:39

specify! defines a local variable in let but extend-type uses resolve-var (dissoc env :locals)

anmonteiro15:03:42

I think this is the problem

anmonteiro15:03:15

why this only happens in advanced compilation, I don't know

dnolen15:03:45

might be a weird optimization edge case

anmonteiro15:03:51

this might also not be the bug

anmonteiro15:03:05

changing it to env still produces the issue

anmonteiro15:03:14

diving deeper

anmonteiro18:03:07

it gets there in :advanced because *cljs-static-fns* is true

anmonteiro18:03:54

I'm not sure what the fix is, I suppose I could attach this information to the issue

dnolen18:03:35

@anmonteiro: that would be helfpul

thheller19:03:07

@anmonteiro: why are you using specify! (.-prototype MyBug) instead of extend-type MyBug?

thheller19:03:53

specify! is usually meant for instances of objects, not prototypes?

anmonteiro19:03:57

@thheller: it's how I managed to reproduce the bug

anmonteiro19:03:02

it's what Om uses

anmonteiro19:03:07

it came from there

thheller19:03:07

ah I see .. still curious why specify instead of extend-type 😛

anmonteiro19:03:25

well, specify! still calls extend-type under the hood

thheller19:03:49

yeah but without the warning

thheller19:03:48

still looks like a bug, so I'll shut up now

richiardiandrea21:03:11

Hello guys, I tried http://dev.clojure.org/jira/browse/CLJS-1585 and found a weird (but maybe expected) behavior:

cljs.user=> (ns alias-load.core (:require [foo.bar.baz :as b]))
nil
alias-load.core=> ::b/hey
Invalid token: ::b/hey
...
alias-load.core=> (ns alias-load.core (:require [foo.bar.baz :as foo]))
nil
alias-load.core=> ::foo/barta
:foo.bar.baz/barta

richiardiandrea21:03:56

basically only if the alias corresponds to the first segment this works

richiardiandrea21:03:06

I will report it in the issue

richiardiandrea21:03:15

I am using 1.8.34

dnolen22:03:52

@richiardiandrea: let’s make a new ticket for that please.

richiardiandrea22:03:38

done, I am trying to check if it's an easy patch 😉 http://dev.clojure.org/jira/browse/CLJS-1608

richiardiandrea22:03:32

so false alarm, on a second attempt, I see that it is working as expected, I tested it in with an actually test, I probably made a mistake in the example above, sorry for the noise