Fork me on GitHub
#core-async
<
2019-06-28
>
hlolli06:06:43

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?

ghadi11:06:19

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

mpenet11:06:27

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

ghadi11:06:52

Something must have reloaded the core async ns

hlolli11:06:45

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?

hlolli12:06:29

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?

hlolli14:06:27

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.

hlolli14:06:23

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

hiredman15:06:11

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)

hiredman15:06:02

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

hiredman16:06:15

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

hlolli17:06:02

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.

hlolli17:06:52

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

hlolli17:06:41

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

hiredman17:06:49

what kind of environment are you loading the code in?

hiredman17:06:23

you maybe aot compiling core.async twice

hlolli17:06:58

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.

hlolli17:06:08

with java 8, clojure 1.10.0

hiredman17:06:11

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

hiredman17:06:38

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

hlolli17:06:46

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.

hlolli17:06:14

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

hiredman17:06:17

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

hlolli17:06:19

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

hlolli17:06:49

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

hlolli17:06:01

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

hlolli17:06:07

easy experiment

hiredman17:06:10

I bet it is compiling core.async twice

hlolli17:06:55

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

hiredman17:06:32

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

👍 1
hiredman17:06:22

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