Chris Nuernberger
Chris Nuernberger
ffi/unlock-gil takes the return value of ffi/lock-gil.
The crash that lock-gil must be necessary. That is really confusing -- does the code in clojurebridge unlock the gil?
It also means our exception handling is poor as exceptions escaping the context are quietly swallowed.
Right - we need to fix that but that is separate issue. It escapes the clojurebridge context somehow and isn't reported.
I don't think statically linking will ever work - you still have python-path issues and then you would potentially be out of sync with numpy and any other c-based extension...
It is really tough to debug this as we don't know which specific require is causing the drama. It is happening during the scan-metadata phase of require-python so there must...
So JDK-18, 19 aren't at this time supported as they both have incompatible changes to the pathway from an integer to a direct buffer.
Specifically 16, 17, 18, 19 all contain incompatible changes there so I have been avoiding upgrading dtype-next to those versions. At this time only JDK-17 is supported beyond JDK-11.
Of course. Its just work - scanning the api changes and fixing dtype-next.
One thing I want to note is that to my knowledge `:jvm-opts` only works in an alias. A top-level `:jvm-opts` is silently ignored. So I think the example deps.edn needs...