This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-09
Channels
- # announcements (5)
- # babashka (1)
- # beginners (116)
- # calva (139)
- # cider (11)
- # clara (2)
- # clj-kondo (13)
- # clojure (247)
- # clojure-dev (18)
- # clojure-europe (5)
- # clojure-france (2)
- # clojure-italy (2)
- # clojure-nl (7)
- # clojure-spec (24)
- # clojure-uk (34)
- # clojurescript (41)
- # cursive (11)
- # data-science (2)
- # datomic (33)
- # emacs (10)
- # events (3)
- # fulcro (134)
- # graphql (9)
- # jackdaw (3)
- # jobs (1)
- # joker (20)
- # kaocha (3)
- # leiningen (7)
- # luminus (2)
- # malli (3)
- # music (1)
- # pedestal (7)
- # re-frame (25)
- # remote-jobs (7)
- # ring (7)
- # shadow-cljs (85)
- # spacemacs (13)
- # testing (2)
- # tools-deps (60)
- # xtdb (11)
- # yada (7)
I have what appears to be a locals-clearing bug when using core.async thread
(let [close? (promise)
thread-ch (a/go-loop []
(when (not (realized? close?))
(try
(stuff))
(recur)))]
(closeable thread-ch (fn [thread-ch]
(deliver close? true)
(a/<!! thread-ch))))
this code works. Swapping the go-loop
for a/thread
reliably causes an NPE when attempting (realized? close?)
println debugging shows close? to be a promise in in the first iteration through the code, and nil
in the second
what version of clojure and core.async? a more minimal repeatable case would be great. I did the minimal to get that to compile with the core.async 0.4.500 and clojure 1.10.1 (basically just defining the free names) and it runs without errors here
it would be useful to isolate it without core.async, because thread doesn't do any code transforms so any behavior you get there should be repeatable elsewhere