what is the idiomatic way to zip two channels? my google foo failed me so far 😕

async/map

https://clojuredocs.org/clojure.core.async/map

(async/map vector [ch1 ch2 ch3 ch4])

oh

thanks. that was um, much simpler than i imagined

too much rxjava for me i guess 😉

I’ve had two different people report to me that core.async doesn’t work correctly (see Wilker’s comment just above about losing a message) if asserts are elided in cljs advanced compilation. Just putting that out there in case others want to chime in.

@tony.kay that's a bit concerning. Eliding asserts is a default in many popular lein profiles, I wonder why that would break a core library

not sure, but I’ve had two users of Fulcro report that the core async queues “lose messages” if elide asserts is true when using advanced optimizations. One of them is trying to build a minimal case. It might be relatively easy to spot in the source. I mean: it has to be a spot where the value of the assert or a side-effect accidentally embedded within it is (accidentally) important.

https://github.com/fulcrologic/fulcro/blob/cca6721e87d2835310f977599696dbdc0253df11/src/main/fulcro/client/impl/om_plumbing.cljc#L81

searching fulcro using the github ui for 'async' that is in there, also lots of go loops created just to publish a single message (async/go (>! ch something))

I thought a key design goal of Om Next was to avoid use of core.async? According to a @dnolen talk

Does fulcro use core.async a lot as a requirement?

There are several test files in core.async's source, I wonder if they have ever run under cljs with assets elided

you have leaped over the most obvious conclusion

if fulcro users are reporting dropped messages, then the place to start looking for bugs is fulcro

@ajs @hiredman The front-end does eliminate the need for async. Om Next’s design is to isolate async, not eliminate it.

you’re in an async execution environment…

So, there are not “a lot of go loops”. There are exactly two channels for each network handler…usually just one networking. One is for sending the requests (a queue), and the other is to provide blocking so that only one goes at a time. Simple as that.

There’s about 12 lines of core async in the entire library isolated to the depths of the plumbing

about the elide assets, it doesn't need to be advanced compilation, just adding the elision is enough to trigger the problem

and there are no asserts in that code in Fulcro

which has been working fine in production apps for a couple of years

uh

the line I linked to is an assert around an offer

(slaps forehead)

Forgive my blindness….the snake just bit me

😊

Alex Miller just cut core.async 0.3.465, this includes @juhoteperi macro enhancement

should be less cumbersome to use now - please give it a spin

@tony.kay does that (async/offer! queue e) need to run, because if so it will obviously not run if asserts are elided

@ajs it is obviously the problem…I just didn’t see it. I had a team of people working on this part of the lib early on. Embedding logic in an assert is something I know better than to do, and I assumed I wrote that code…so, I was assuming it couldn’t have asserts. My bad

I guess it is even possible I did write it, and was not having a good day 😜

but I darn well know not to do it

no problem with having a bad day. i have quite a few of those

@tony.kay for what it's worth, i assert things using this, because if elided the value is passed through (and it allows me to litter my code with type assumptions without having to bind to let first, keeps the code succinct) : https://github.com/astoeckley/clojure-assistant/blob/master/src/assistant/asserts.cljc#L50

Yeah, I actually lean the other way and like that assert drops the processing altogether (in case it is high-overhead assertion, like a spec check)

i this case i'm wrapping things that need to be there anyway, but allowing tests with predicates in case asserts are turned on

I see

that is handy

it's one of the ways i avoid shooting myself in the foot with a language that has no type checking, but without adding all the code necessary in typed-checked languages (or the verbosity of clojure.spec)

@hiredman Thanks for digging into that. Even though it was a little embarrassing, I appreciate that you took the time to look at the code.