core-async

2019-06-28T06:43:43.152200Z

someone seen such an error before?

error:  Exception in thread "clojure.core.async.timers/timeout-daemon"
error:  java.lang.ClassCastException: clojure.core.async.impl.timers.TimeoutQueueEntry cannot be cast to clojure.core.async.impl.timers.TimeoutQueueEntry

error:  Exception in thread "async-dispatch-3"
error:  java.lang.IllegalArgumentException: No implementation of method: :blockable? of protocol: #'clojure.core.async.impl.protocols/Handler found for class: clojure.core.async.impl.ioc_macros$fn_handler$reify__6400
I'm getting bunch of these errors, from Windows trough an uberjar, tried core.async 0.4x and few 0.3x versions, and two jdk versions. I guess something didn't get bundled in the jar or?

ghadi 2019-06-28T11:16:19.153Z

That's what happens when you start up then reload a namespace containing a protocol

mpenet 2019-06-28T11:24:27.153400Z

or redef a record with the same name I think, right?

ghadi 2019-06-28T11:26:20.153600Z

yeah

ghadi 2019-06-28T11:26:52.154200Z

Something must have reloaded the core async ns

2019-06-28T14:25:27.157900Z

after deleting all code that calls require outside of ns decleration, I'm still getting these. Nowhere in the project I define a protocol, maybe some of the libs could be doing it. Not sure how to debug this.

2019-06-28T14:26:23.158300Z

I am calling a macro when this happens, the error is only runtime

2019-06-28T15:56:11.164100Z

It isn't a core.async issue, it is a, I dunno, code hygiene issue? Something is causing you to have two different classes with the same name, which can happen a few different ways, the most common is loading code more them once (require and use have mechanisms to avoid this but they can be bypassed). Another possibility is aot weirdness (maybe you are using an aot compiled library)

2019-06-28T15:57:02.165Z

If you use any kind of code reloading dev tooling I would be suspicious of that

2019-06-28T16:02:15.165700Z

in fact if you search for that exception you actually get hits from people haing trouble because they used :reload-all with :require

2019-06-28T17:11:02.167800Z

This is aot code, created from badgieon, just compiled into target, resources gathered and zipped into a jar(single uberjar). This did work on linux and macos. I need to try again to confirm that since I made some changes since testing last time. Maybe I should skip aot on core.async? Don't know if I can skip specific libraries.

2019-06-28T17:11:52.168400Z

I require core async by both creating alias and refering to different functions. No reload-all, never added it.

2019-06-28T17:15:41.169300Z

since it works not in jar, I'm more suspicious of the aot and the packaging..

2019-06-28T17:15:49.169500Z

what kind of environment are you loading the code in?

2019-06-28T17:16:23.170300Z

you maybe aot compiling core.async twice

2019-06-28T17:16:58.170800Z

in the windows case, I run the main class from java from the uberjar directory root, I'm actually not running from the jar from windows, since the manifest is always malformed.

2019-06-28T17:17:08.171100Z

with java 8, clojure 1.10.0

2019-06-28T17:18:11.172100Z

it sounds like you have all kinds of broken problems, you could have all kinds of problems with the jar

2019-06-28T17:18:38.172800Z

badgieon might be junk, I've never heard of it

2019-06-28T17:18:46.173100Z

yes, I got main class not found, it's a seperate headache. I edited the manifest in all ways, but the class was never found.

2019-06-28T17:19:14.174Z

could be, but it's not doing anything enormous, just a wrapper for clojure compile and copying from classpath etc.

2019-06-28T17:19:17.174100Z

I wouldn't be surprised if some not commonly used library broke aot compilation

2019-06-28T17:20:19.174700Z

I could call clojure compile directly? This looks very thin too me https://github.com/EwenG/badigeon/blob/master/src/badigeon/compile.clj#L44-L90

2019-06-28T17:20:49.175700Z

maybe my experimentalism is my enemy here. I was hoping to leave leiningen.

2019-06-28T17:21:01.176100Z

I can try this with leiniingen, and compare...

2019-06-28T17:21:07.176400Z

easy experiment

2019-06-28T17:21:10.176500Z

I bet it is compiling core.async twice

2019-06-28T17:21:55.177600Z

nice 🙂 I will try leiningen, I bet you're right, not because I know about this, but because I know you know stuff

2019-06-28T17:22:32.178200Z

you could try compiling manually, but just call compile on your main namespace, nothing else

👍 1
2019-06-28T17:24:22.178800Z

in general I am not a fan of aot compilation, and usually advise not doing it