Clojurians Log v2

I know I've used core.async in graalvm projects, but I don't quite remember if I had to do anything special.

You can look at how babashka integrates core.async, https://github.com/babashka/babashka/blob/master/src/babashka/impl/clojure/core/async.clj.

I would recommend creating a very simple project with just core async to see how it works with graalvm.

damn. it looks hard what babashka had to do.

thanks for pointing this

I'm not actually sure everything babashka does is necessary in the general case. I think most of it is so that core.async can be scripted at runtime. I don't think using core.async needs any special changes normally, but I recommend creating a simplified example to test and make sure. You need to make sure you're not accidentally spawning any threads or resources at compile time that should be delayed until runtime.

I assume you're following all the advice from https://github.com/clj-easy/graal-docs.

no, not really, i simply followed a tuto. to build a very simple cli command. it worked well, up until a add a "require" to the bosquet lib. it seems that, as this lib has a transitive dep on core.async, it breaks the native-image build

but i'll read this doc, i didnt know about it

ok i read it i think i'm using it properly

You also have to make sure bosquet is graalvm compatible. I'm not sure I would assume the problem is core.async. The problem may be with bosquet's usage of core.async (or something else in bosquet).

how can i check this? it' not referenced in clj-easy graalvm-clojure. they have a bb script to build a native-image version of the binary but it seems to be broken. At least, i have issues when i try to run the task

> they have a bb script to build a native-image version of the binary but it seems to be broken Who is they?

I would recommend creating a very simple project with just core async to see how it works with graalvm.

you seem right, i ve made a simple heelo world using core async and it builds. so i dont really undersantd why native image is complaining about core async when i try to use bosquet

My guess is that bosquet might be spawning threads or creating resources at runtime by using core.async in top level forms of some namespaces.

https://github.com/zmedelis/bosquet/blob/3f2c8f5f7ca732904fe2531373a0f4873e842103/src/bosquet/memory/long_term_memory.clj#L6 it's the only place they use core async. could the issue be located in the deftype?

Why do you think the issue is core.async?

because this seems to be what native-image reports in its logs when failing

but maybe i'm getting it wrong

note that babashka avoids using the real core.async macro and replaces it with virtual threads since the go macro is ... complicated and slow to get it running in SCI

do you perhaps have compilation logs of native-image to see what goes wrong? paste the whole thing in a gist

thanks a lot borkdude... i've switched to langchain4j instead of bosquet. and i dont have issues anymore. i'll probably log an issue in bosquet lib regarding native compilation