This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-13
Channels
- # aleph (3)
- # announcements (2)
- # aws (48)
- # babashka (93)
- # beginners (101)
- # bristol-clojurians (1)
- # cider (3)
- # clj-kondo (17)
- # cljdoc (1)
- # cljsrn (3)
- # clojure (208)
- # clojure-dev (2)
- # clojure-europe (19)
- # clojure-italy (18)
- # clojure-losangeles (16)
- # clojure-nl (8)
- # clojure-spec (21)
- # clojure-sweden (8)
- # clojure-uk (57)
- # clojuredesign-podcast (6)
- # clojurescript (10)
- # code-reviews (6)
- # core-typed (1)
- # cryogen (7)
- # cursive (38)
- # datomic (34)
- # duct (13)
- # emacs (13)
- # fulcro (16)
- # funcool (2)
- # graalvm (1)
- # lambdaisland (5)
- # luminus (8)
- # lumo (1)
- # malli (2)
- # off-topic (12)
- # pathom (9)
- # re-frame (13)
- # reagent (11)
- # ring (3)
- # shadow-cljs (15)
- # sql (19)
- # tools-deps (61)
- # xtdb (23)
In case anyone was worried about the clojure.tools.reader.edn/read vs. clojure.edn/read differences I mentioned earlier today (my inbox is not full of people saying they were 🙂 ) it appears that it was 12 out of about 12,000 cases where if you used a http://java.io.PushbackReader with tools.reader, it could throw an exception because of a pushback buffer overflow, whereas for some reason if you instead use the custom class in the lib created by the push-back-reader function call, that never happened. I will probably file a ticket with some details about this difference, but looks like there is a reasonable workaround, at least (i.e using push-back-reader)