Compile native version using graal, reducing startup time to almost 0

[russelldavis]

Without this, kscript --help takes 0.6 to 0.9 seconds.
With this, it takes 0.02 seconds 🎉

This still needs to be integrated into the release script, but for now you can use it by running ./gradlew nativeImage, then using the binary at ./build/graal/kscript-native.

[holgerbrandl]

That's pretty cool. Would kscript_native be a platform independent executable? Does it require some graalvm installatino on the user side?

[russelldavis]

It doesn't require any graalvm installation on the user side (it would, of course, if we extended it to make native versions of the user's scripts as well, but this doesn't do that).

It's not platform independent, and graal doesn't support cross-compiling, so figuring out releases for all the different platforms will be some extra work. I guess a script that compiles a version for each platform in separate docker containers might be the way to go. Until someone sets that up, I'd be happy to help with manual builds of the mac version for any releases.

[holgerbrandl]

I could certainly build it for linux via docker , but I'm not sure how to use docker to build windows or macos versions.

We'd also need to figure out how/if sdkman allows for platform specific builds.

[seanabraham]

I just tweeted at sdkman to see! https://twitter.com/SeanA208/status/1085304451101908992

However, looking at their documentation, it seems unlikely that they support platform specific releases. One idea is that you can keep distributing kscript like normal via sdkman but have another release script that creates a github release with different native images for download if anyone wants them.

[russelldavis]

I could certainly build it for linux via docker , but I'm not sure how to use docker to build windows or macos versions.

Ah, right. To automate it for macOS, you'd have to call out to something like https://www.macstadium.com. For Windows you could do it on AWS (I believe you could do it in Lambda using the free tier). Or, for now, you could just rely on volunteers to run a script for you for each new release.

[holgerbrandl]

Relying on volunteers is not really an option, since we must have a fully automatic release mechanism for easy deployment.

It seems that also travisCI has build integrations for various platforms, see https://docs.travis-ci.com/user/reference/osx/

The fine folks of sdkman pointed us to https://github.com/sdkman/sdkman-db-migrations for multiplatform deployments. It's seems more involved and I'm not sure about how to integrate their PR-our-release-config-repo is compatbile with an automatic release cycle. I've pinged them on twitter, lets wait for their opinion.

[holgerbrandl]

And indeed azure devops looks like another viable cross-platform build envrionment https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=vsts

[exaV]

This could be a really cool feature! The startup is blazingly fast, kscript-native --help prints the version and help and returns almost immediately. It feels native compared to the non-native kscript which has a noticable delay even for '--help'

However I ran into a couple of issues when I built kscript-native from source using the commit in this PR.

kscript-native test.kts yields kotlin -classpath "/Users/rick/.kscript/test1.1f25f65120e488c6.jar:/usr/local/Cellar/kotlin/1.3.21/libexec/lib/kotlin-script-runtime.jar" Main_Test1while kscript (installled with brew) correctly prints 'hello world'.
So I cannot actually execute scripts with this yet.

I needed to add the option option("--enable-url-protocols=https") to graal and subsequently have libsunsec.so on my PATH otherwise kscript-native --help would fail.

[holgerbrandl]

I think if we could figure out a multi-platform way to build it, I'd definitely in favour of using it.

[holgerbrandl]

Any news here, or should we defer this cool feature to a later date?

[russelldavis]

Nothing new on my end. I think someone just needs to set up the automated builds as discussed above. It's not something I would get to any time soon, so feel free to close (and/or create an issue with a Help Wanted tag).

[holgerbrandl]

Indeed I should use the help wanted tag more often.

[j30ng]

Hi folks! I could be wrong, but it seems gradle-graal does not support running nativeImage task on Windows.

https://github.com/palantir/gradle-graal/blob/0.2.0/src/main/java/com/palantir/gradle/graal/NativeImageTask.java#L115-L122

[holgerbrandl]

Good to know @j30ng. However, typically I build, test and deploy under linux anyway, so it would be rather necessary to allow building a native image for windows under linux/macos. Not sure if this would be supported by the gradle-graal task.

[holgerbrandl]

This PR is not yet ready and seems to be no longer maintained. So I'm closing this for now. Feel welcome to reopen it if needed.

[kenyee]

FYI, Github Actions supports OSX and Windows builds....probably wouldn't be that hard to set it up...

[NightMachinery]

@holgerbrandl I wonder if graalVM could be added as a dependency, so that users build their own versions on their own computer. The testing would still be a challenge though.

It would be specially awesome if the scripts themselves could also be compiled via graalVM. Perhaps similar projects (jbang for Java, tsk-tsk for Scala) can be an inspiration here.

[holgerbrandl]

@NightMachinary feel welcome to prepare a PR. Personally I know nothing of GraalVM so I would not know where to start.