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?

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

what value does it return for 08 and 09?

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

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

Bootstrapped parses those as decimal 8 and 9

Probably a bug in the bootstrapped reader

http://dev.clojure.org/jira/browse/CLJS-1606

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

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)?”);

which is basically present in tools.reader as well

(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)?$”)

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

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

this is reflected in the tests

crap! @bronsa beat me to the patch

ah, sorry

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

will do!

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

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

but that was definitely unwanted behaviour

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

So, it depends on how hosted you are

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

@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

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

I think this is the problem

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

might be a weird optimization edge case

this might also not be the bug

changing it to env still produces the issue

diving deeper

@dnolen: this is the line generating the warnings https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L936

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

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

@anmonteiro: that would be helfpul

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

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

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

it's what Om uses

https://github.com/omcljs/om/blob/master/src/main/om/next.clj#L236

it came from there

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

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

yeah but without the warning

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

🙃

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

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

I will report it in the issue

I am using 1.8.34

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

thanks

k

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

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