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

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?

yeah

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 https://github.com/EwenG/badigeon/blob/master/src/badigeon/compile.clj#L44-L90

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

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