Fork me on GitHub
#core-async
<
2018-03-30
>
hiredman00:03:32

∵ dallben ~ ∴ clj -R:async                                                                                         
Clojure 1.9.0
user=> (odd? 0)
false
user=> 

justinlee00:03:06

right, so it shouldn’t throw, right? am i losing it

hiredman00:03:48

sorry, I didn't look at the code, just read what you wrote, I think you meant "which isn't odd"

justinlee00:03:57

oh yea that’s confusing

hiredman00:03:00

no, there is no way to capture all the errors

hiredman00:03:25

most people end up capturing errors and passing them around on channels as values

hiredman00:03:12

some utility libraries even provide analogs to '<!' that re-throw and throwables they take off a channel

hiredman00:03:29

I am not a fan of that thing though

justinlee00:03:01

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

justinlee00:03:09

maybe this library should just compose the functions first instead of using async/map

hiredman00:03:09

async/map is deprecated even if I recall

hiredman00:03:00

async/map, filter, remove, etc are all deprecated in favor of using transducers

justinlee00:03:09

that would be a much better design

hiredman00:03:16

oh, sorry, no I am thinking of async/map>

justinlee00:03:04

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

Ho0man18:03:56

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)

Ho0man18:03:52

What is the problem ... what am I getting wrong?

hiredman18:03:49

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

Ho0man19:03:19

Thanks for the reply Yep, so what happens to the value? Since there's only one <!! from each drain

hiredman18:03:28

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

Ho0man19:03:46

Also when the tests are run, the value taken from the channel arbitrarily switches between the expected value and nil (when poll!ing instead of <!!ing) So there seems to be some king of race condition here

hiredman20:03:15

<!! is taking from a channel

hiredman20:03:44

put! is putting something on channel, so swapping one for the other makes no sense

Ho0man06:03:06

Sorry I meant poll!

hiredman20:03:22

<!! on a closed channel will return nil