Fork me on GitHub
#cljs-dev
<
2022-06-30
>
dnolen14:06:18

hrm tools.reader cljs tests failing - something odd about date handling & regexes

bronsa15:06:38

let me know how to repro and I can have a look @dnolen

bronsa15:06:09

(if you need me to :) )

dnolen15:06:32

@bronsa in an hour I can push the CI bits - it will fail but you can look at the output - can also show you how to run locally of course

dnolen17:06:16

@bronsa interesting the date ones don't fail on this box - the problem is that Date interprets the zone of my machine from what I can tell

dnolen17:06:24

that might be what is wrong w/ the test? I don't know

dnolen17:06:34

but the regex one is definite failing

bronsa21:06:27

thanks, I'll check what's happening

bronsa21:06:10

weird, the output of read-string looks correct to me, it's the regex literal that seems to "lose" an escape char

bronsa21:06:16

this works in a cljs repl

(= (str #"\[\]?(\")\\")
         (str (cljs.tools.reader/read-string "#\"\\[\\]?(\\\")\\\\\"")))

bronsa21:06:59

so it must be an issue with advanced compilation? not tools.reader

bronsa21:06:42

or I guess str of a regex may not be stable between js environments? so in that case the test is too brittle

bronsa21:06:00

in the js file

try{var f=new q(null,mb.g(/\[\]?(")\\/),new q(null,mb.g(Uz('#"\\[\\]?(\\")\\\\"')),null,1,null),2,null)
I see this, and the regex literal looks ok to me (the " is not escaped since it's using /../ ), so I guess it's the str representation that's the problem

bronsa21:06:26

I don't know enough js to know what the proper way to deal with this is, but the test just needs to be fixed (or removed if it's not possible) to account for this

dnolen23:06:53

@bronsa what happens if you encode the UTC offset?

dnolen23:06:06

oh sorry bleh, you're talking about the regex problem

bronsa23:06:27

ah, yes, I haven't looked at the date one yet, I will have a look tomorrow

dnolen23:06:28

yeah it worked for me in the REPL, but any Closure processing appears to break it

dnolen23:06:31

@bronsa one problem is I think Java regex needs more escaping but JS does not?

bronsa23:06:00

I am not sure to be honest, but I don't think the reader should handle it any differently since in cljs land we use " as delimiter

bronsa23:06:49

what I think we need to confirm is that the runtime objects are correct in either case

bronsa23:06:54

which I think they are

dnolen23:06:09

ah right avoid the underlying string comparison

dnolen23:06:14

but detect equality of the operation

bronsa23:06:42

not sure what the best way to do that is in js

bronsa23:06:34

maybe we simply try to match on a common string and relax the test a bit