Fork me on GitHub

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?


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


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


Something must have reloaded the core async ns


I'm not running reload-all anywhere, but I do have a require call in a macro. That could be the evil part. Can't there be some sort of defonce mechanism within core.async to prevent this?


I'm not running reload-all anywhere, but I do have a require call in a macro. That could be the evil part. Can't there be some sort of defonce mechanism within core.async to prevent this?


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.


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


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)


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


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


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.


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


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


what kind of environment are you loading the code in?


you maybe aot compiling core.async twice


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.


with java 8, clojure 1.10.0


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


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


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.


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


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


I could call clojure compile directly? This looks very thin too me


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


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


easy experiment


I bet it is compiling core.async twice


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


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

👍 4

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