This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-30
Channels
- # announcements (40)
- # babashka (41)
- # beginners (32)
- # calva (15)
- # clara (8)
- # clj-kondo (14)
- # cljs-dev (30)
- # clojure (37)
- # clojure-dev (8)
- # clojure-europe (21)
- # clojure-norway (21)
- # clojure-uk (4)
- # clojured (3)
- # clojurescript (4)
- # community-development (10)
- # core-async (13)
- # cursive (23)
- # datomic (15)
- # emacs (9)
- # fulcro (3)
- # google-cloud (4)
- # graphql (24)
- # gratitude (2)
- # holy-lambda (4)
- # honeysql (5)
- # hyperfiddle (9)
- # keechma (1)
- # klipse (5)
- # lsp (23)
- # malli (4)
- # missionary (32)
- # pathom (28)
- # re-frame (2)
- # reagent (40)
- # reitit (17)
- # releases (2)
- # remote-jobs (1)
- # shadow-cljs (25)
- # specter (3)
- # vim (19)
- # xtdb (41)
@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
@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
weird, the output of read-string
looks correct to me, it's the regex literal that seems to "lose" an escape char
this works in a cljs repl
(= (str #"\[\]?(\")\\")
(str (cljs.tools.reader/read-string "#\"\\[\\]?(\\\")\\\\\"")))
or I guess str
of a regex may not be stable between js environments? so in that case the test is too brittle
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 problemI 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
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