This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-30
Channels
- # aws (4)
- # beginners (143)
- # boot (37)
- # cider (31)
- # cljs-dev (53)
- # clojure (303)
- # clojure-conj (5)
- # clojure-dev (106)
- # clojure-dusseldorf (2)
- # clojure-greece (3)
- # clojure-italy (23)
- # clojure-spec (83)
- # clojure-uk (7)
- # clojurescript (328)
- # core-async (25)
- # cursive (2)
- # datascript (2)
- # datomic (3)
- # emacs (10)
- # hoplon (1)
- # jobs (2)
- # lein-figwheel (1)
- # leiningen (13)
- # luminus (6)
- # off-topic (38)
- # onyx (2)
- # parinfer (13)
- # pedestal (2)
- # portkey (5)
- # re-frame (11)
- # reagent (2)
- # shadow-cljs (61)
- # specter (6)
- # unrepl (60)
- # vim (4)
sorry, I didn't look at the code, just read what you wrote, I think you meant "which isn't odd"
some utility libraries even provide analogs to '<!' that re-throw and throwables they take off a channel
yea errors-as-values is a concept I get, and is exactly what I was hoping to do. but when you have a big library, i was hoping to guarantee a failsafe so that if something throws unexpectedly, the diagnostics are a bit better
maybe this library should just compose the functions first instead of using async/map
i was trying to fix a bug in cljs-http fwiw. it uses map to attach each piece of middleware, which sucks, because if anything throws, it will throw an uncaught exception with a useless stacktrace and of course the consuming go block never returns
Hi, I'm generative-testing part of my system which is in core.async, this part boils down to this check :
(>!! source test-payload)
(every? true? (fmap #(= (spy :info (<!! %)) test-payload) drain))
Which makes the test hault. (or produce nils arbitrarily when I change <!!
to async/put!
.
source and drains are (chan (sliding-buffer ,,,))
source is connected to drain in this way :
source[s]-->mix-(chan)-mult-->drain[s]
The middle channel both mixes in sources and is multiplied out to drains (which are all channels of sliding-buffers of varying sizes)if I had to guess, you never close your channel after you finish producing values in to it, so your test is blocked pulling from a channel that nothing is put in to
Thanks for the reply
Yep, so what happens to the value? Since there's only one <!!
from each drain
test.check and core.async are both complicated things, if you can remove one or the other from the equation it will make it easier for you to figure out what is happening