Okx 3 days ago

> You can use GraalPy with GraalVM JDK, Oracle JDK, or OpenJDK

https://www.graalvm.org/latest/reference-manual/python/

theanonymousone 2 days ago

Update. I actually managed to run the quick example with Temurin Java 22: java.vm.name=OpenJDK 64-Bit Server VM, java.vendor.version=Temurin-22.0.2+9

  • mike_hearn 2 days ago

    It won't JIT compile on anything other than GraalVM however. So it'll run, but slowly.

    • ackfoobar 2 days ago

      The documentation says "Optimized if enabled via experimental VM option". (I linked in another thread.)

jryan49 3 days ago

Graal let's you compile native binaries

  • ackfoobar 3 days ago

    Graal is many things (a marketing nightmare). The guest language part is orthogonal to the native packager AFAIK.

    • w10-1 3 days ago

      Yes, but I was under the impression that graal-level inter-op was limited to packages the graal toolchain could compile.

      Thus, while swift and graal both depend on llvm, they use different variants and there's no real way to make inter-op between swift and graal (even using the llvm it which graal is said to be able to consume).

      e.g., I believe this announcement represents the work to compile a python (3.11) and some proof-of-concept python packages using graal toolchain, to spur other packages to support the same.

      So I'd really love to be wrong, but I believe building under the graal llvm is the common factor.

      • kaba0 2 days ago

        I don’t really see how swift comes into the picture, besides SuLong being a thing (running LLVM bitcode). Native binary was meant as a compile target in the previous comment, I believe, not as an input. Graal can do both, but as a target it has no dependency on LLVM.

        So yeah, graalvm should be able to produce a native binary for python code (though depending on the specifics it might actually be more like a native binary interpreter running python scripts, it can’t optimize in every circumstance but I’m hazy on the details).