Clojurians Log v2

Worked for me, too! Amazing!

Could you try the instructions in https://github.com/dundalek/humble-graal to see if running uber jar with java works? Then we will know if it is something with graal or if the problem is somewhere else.

another suggestion would be re-running tracing for the JNI config: https://github.com/dundalek/humble-graal?tab=readme-ov-file#jni-config I ran it only on Linux, it might be possible there are additional classes involved on Mac.

Thanks. uber jar works. I recollect JNI config. Still native humble doesn't show the window. Don't know why.

the strange thing it does not print any errors, so it is hard to debug if you feel like diving a bit deeper you could try to compile the skija example which exercises the underlying libraries JWM+Skija. if that does not work then the problem is with one of these (likely JWM since it does not even shows a window). If it does work, then there is likely something going on in HumbleUI initialization code.

I got curious so I rented a mac machine for debugging. 🙂 I was able to run the graal-compiled skija example, which means the issue is likely not in native libs, but in the clojure code of humbleui, so I am hopeful I will be able to pinpoint it down.

I was able to figure it out, the ui/start-app! starts a new thread (using future) which does not seem to work in graal for some reason. When running the app on a main thread it works. I pushed an update, please give it a try. In practice one would probably want to run it in seprate thread in dev so that REPL is not blocked and then only run it on main thread for release.

Graal-compiled HumbleUI running on M1:

@kloud Thanks. It works.

What’s the problem with GraalVM and threads?

macOS requires UI stuff to happen on first thread. On normal JVM, we do a little bit of magic to make it happen https://github.com/HumbleUI/JWM/blob/a04867c5f45b126caafe9abccd9ecd00d3bc516f/macos/cc/App.mm#L48-L62 Maybe this trick doesn’s work in GraalVM? I haven’t looked into it, just one possible caveat

That explains a lot, so what seems to happen is that when humbleui is running on another thread it dispatches UI calls to run on the main thread via a queue. But for some reason these calls don't get executed on the other end when graal-compiled.

The remaining unknown is why graal does that, but that's getting pretty deep. If I had to guess perhaps given things happen in the native land then graal is unable to analyze and optimizes things away.

I’m not sure how it works in JVM, either. For some reason first thread is still free to be taken over after JVM starts?

Maybe native graalvm is more straightforward and just uses first thread for main program

Yeah, some mysteries are yet to be understood 🙂 In practice it seem to be good enough for now. It can run on other thread on JVM so that REPL is not blocked during development and for deployment it can be run on the main thread.

would be interesting to see if thread list and count are the same for a basic graal app and jvm app