Clojurians Log v2

https://clojure.atlassian.net/browse/ASYNC-227

A new release of Clojure core.async is available: Release 0.4.500 on 2019.06.11 * https://clojure.atlassian.net/browse/ASYNC-227 cljs alts! isn't non-deterministic * https://clojure.atlassian.net/browse/ASYNC-224 Fix bad putter unwrapping in channel abort * https://clojure.atlassian.net/browse/ASYNC-226 Fix bad cljs test code {org.clojure/core.async {:mvn/version "0.4.500"}}

@pmooser ^

@ghadi Woohoo! Thank you for getting that out quickly.

I wish I understood core.async internals better. I should dedicate more time.

@ghadi As long as I am bugging you about core.async issues, are you guys aware that "case" is unsafe to use in core.async in certain circumstances (which I can't precisely describe) ?

If you are unaware of it, I can try to find some sort of breaking example later today.

https://clojure.atlassian.net/browse/ASYNC-79

@hiredman Thank you !

I’m trying to run the client code from https://github.com/fullcontact/full.http from the repl and I keep getting

Exception in thread "async-dispatch-1" java.lang.IllegalStateException: Attempting to call unbound fn: #'clojure.core.async.impl.ioc-macros/process-exception
	at clojure.lang.Var$Unbound.throwArity(Var.java:45)
	at clojure.lang.AFn.invoke(AFn.java:32)
	at full.http.client$process_response$fn__253$state_machine__4512__auto____254$fn__256.invoke(client.clj:72)
	at full.http.client$process_response$fn__253$state_machine__4512__auto____254.invoke(client.clj:72)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:972)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:977)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:975)
	at full.http.client$process_response$fn__253.invoke(client.clj:72)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

any ideas on what I may be doing wrong?

check your dependency manager for version conflicts - sounds like something is trying to use functions from a different version of core.async than the one you have pulled in

with leiningen you can check this with lein deps :tree

thanks!

it looks like something was aot compiled against a different version of core.async

yeah, this is a bug in full.async https://github.com/fullcontact/full.http/blob/master/project.clj#L18

to have that many deps as a lib, then aot, is pathological

the process-exception function is part of the old broken the go macro processed exceptions, so macros expanded against the old version (aot compiled) reference it, but newer versions of core.async's go macro have a new exception handling mechanism (and also broken but maybe slightly less so, and I have patches in jira but they never get merged) and process-exception doesn't exist

sorry about the never merging part btw. it's not for lack of desire, only for lack of time and focus.

some day I will get around to those...

I did look at some of them today but I found it a little difficult to assess which ones were ready to go, which were speculative, which definitely were not ready, etc. I don't know what I need exactly, other than maybe a prioritized list of what to look at.

a complication at this point is someone opened a bug for an issue (async-198) which has a patch to fix, and then someone found another issue (async-220) which the patch for async-198 didn't fix, so the async-220 patch depends on the async-198 patch, and then someone else ran in to the async-220 issue and commented on the async-198 issue that the patch there doesn't fix it (I haven't actually verified that the async-220 fixes the issue in the comments on async-198)

oh, and then the cljs side of things is a whole other thing because the original fix to exception handling there hasn't been merged yet, so that ticket/patch got updated to include the async-198 fixes, but hasn't been updated in light of async-220 (I also lack time and focus)

Thanks y’all. Didn’t mean to cause a ruckus. :)

so, yes - exactly this kind of stuff is why I never get far enough into it to feel comfortable merging anything

and not feeling like there is enough test coverage in general to ensure that the changes don't break something

not saying either of these is your fault!

it just is what it is

no worries :)