Package Details: graal-bin 19.2.0.1-1

Git Clone URL: https://aur.archlinux.org/graal-bin.git (read-only)
Package Base: graal-bin
Description: Universal virtual machine for running applications written in a variety of languages (JVM-based, LLVM-based, or other)
Upstream URL: https://www.graalvm.org/
Licenses: custom
Conflicts: graal
Provides: graal, java-environment=8, java-runtime=8
Submitter: lucaswerkmeister
Maintainer: lucaswerkmeister
Last Packager: lucaswerkmeister
Votes: 18
Popularity: 1.185421
First Submitted: 2018-05-02 22:30
Last Updated: 2019-09-13 19:10

Dependencies (3)

Required by (1000)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

sogaiu commented on 2019-05-30 07:13

May be this has been done already, but FWIW, I took a look at the mentioned extra native-image jars. One of them is at:

https://github.com/oracle/graal/releases/download/vm-19.0.0/native-image-installable-svm-linux-amd64-19.0.0.jar

Unzipping the .jar file yields 2 directories: META-INF and jre.

It appears that jre is a directory tree of files necessary for native-image operation.

META-INF appears to contain at least information about the permissions for the native-image-related files that live under jre, but also information about symlinks (to be created?) for those files. These files are named "permissions" and "symlinks", respectively.

The formats seem straight-forward enough. For permissions, it appears each line represents one file path, a typical one being:

bin/native-image = rwxrwxrwx

For symlinks, it's also one line per symlink, e.g.:

bin/native-image = ../jre/bin/native-image

where what's on the left of = is a symlink to be created, and what's on the right of = is where it should point.

For both permissions and symlinks, the paths on the left of the = all appear to be relative to where graal would get installed (i.e. /usr/lib/jvm/java-8-graal)

Didn't succeed in turning up whether there are existing tools to process these files, apart from gu.

Brief examination of the output for gu --help / gu install -h didn't suggest that the tool could be told where the results should go. However, I noticed the existence of the GRAALVM_HOME environment variable elsewhere. Perhaps setting this to an appropriate value in the PKGBUILD and then invoking "gu install native-image" will yield the native-image files in an appropriate location for package building purposes.

Any thoughts?

sogaiu commented on 2019-05-28 01:46

@lucaswerkmeister: Did you decide on an approach?

I'd very much like to use the native-image for Graal 19 as there was a breaking change introduced (https://github.com/oracle/graal/issues/1265#issuecomment-491534547) that doesn't work with the native-image from Graal 1.0.0 rc16's native-image, and it happens that something I'm working on needs this.

Not sure how much help I could be, but I'm at least motivated to participate, so please let me know if there is anything that needs doing.

sogaiu commented on 2019-05-14 21:22

I tried to locate some information on where the upstream folks are going with this gu thing and their rationale for splitting out native-image, but I haven't found anything relevant so far.

No strong opinion, but FWIW, if it's easier, perhaps starting with including native-image and if necessary create a separate package later? Don't know how many folks are using native-image already, but it seems less surprising to not change so suddenly and without warning. May be the upstream folks hinted at this somewhere before this release?

lucaswerkmeister commented on 2019-05-14 18:12

Ah, so that’s why there are extra native-image JARs in the release – I should’ve paid attention to those :)

I guess I can either update this package to include native-image, or have it in a separate package (like upstream), presumably recommended by this package. Any thoughts on what’s better?

sogaiu commented on 2019-05-14 15:53

From graal 19, native-image doesn't appear to be bundled any more:

https://www.graalvm.org/docs/reference-manual/aot-compilation/#install-native-image

Any thoughts on this?

jdc commented on 2019-05-12 03:22

Thanks for the speedy update! :)

lucaswerkmeister commented on 2018-12-07 22:50

graaljs RC10 requires function expressions to be parenthesized 1, so the test script now becomes:

#!/usr/lib/jvm/java-8-graal/jre/languages/R/bin/Rscript --polyglot
jsPlus = eval.polyglot('js', '(function(s1, s2) { return s1 + s2; })')
pythonPlus = eval.polyglot('python', 'lambda s1, s2: s1 + s2')
rubyOne = eval.polyglot('ruby', '1')
pythonOne = eval.polyglot('python', '1')
rOne = 1
print(pythonPlus(jsPlus(rubyOne, pythonOne), rOne))

lucaswerkmeister commented on 2018-10-22 10:32

By the way, if anyone wants to take over this package in the future – here’s the script I use to test new package versions after building and locally installing them, before pushing them to AUR:

#!/usr/lib/jvm/java-8-graal/jre/languages/R/bin/Rscript --polyglot
jsPlus = eval.polyglot('js', 'function(s1, s2) { return s1 + s2; }')
pythonPlus = eval.polyglot('python', 'lambda s1, s2: s1 + s2')
rubyOne = eval.polyglot('ruby', '1')
pythonOne = eval.polyglot('python', '1')
rOne = 1
print(pythonPlus(jsPlus(rubyOne, pythonOne), rOne))

If all the packages still work, this should print:

[1] 3

lucaswerkmeister commented on 2018-09-10 20:14

@arb12: I know. The package had already been flagged out-of-date hours earlier. There’s really no need to comment on it as well. (It’s updated now, along with fastr-bin, truffleruby-bin and graalpython-bin, of course.)

arp12 commented on 2018-09-10 17:37

RC6 is available