grashalm01
Joined 10 years ago
Karma
71
Submissions
22
Member since
Dec 20
Recent submissions
Comment · 8 years ago
My rule of thumb: use checked exceptions if and only if your exceptions are not supposed to be rethrown and must be handled by the caller directly. These cases are very rare, but I recently had one them.
Comment · 8 years ago
Exapunks is to programming as piano tiles the mobile game is to playing a real piano.
Comment · 8 years ago
Graal can run in dynamic and aot compilation mode. If you feed profiles into aot from a test run you can get pretty close to dynamic compilation peak performance.
Comment · 8 years ago
Because Graal.python will be a lot faster. Just running cpython on GraalVm is possible but does not get you anything.
Comment · 8 years ago
You will like to hear that there is some rstudio integration in the works.
Here is the correct link: http://www.graalvm.org/docs/reference-manual/compatibility/
(Accidentally posted the internal link :D)
Comment · 8 years ago
Not yet. It's on our roadmap.
Comment · 8 years ago
We have lots of infrastructure depending on mx. Infrastructure that no other build tool provides as far as I can tell.
In the end every build tool sucks. Sometimes you just need to be pragmatic. Mx integrates with maven pretty well and it generates ide config for intellij, eclipse and netbeans. Moving to a different system is probably not worth the cost atm. And it's not complicated to use at all. E.g mx build builds and mx gate builds and tests. Mx unittest runs unit tests.
As written below. Graal.Python is not yet open source. But you will hear from us soon.
Comment · 8 years ago
I'm sure you will hear about us when we go open source with Python.
Comment · 8 years ago
When executing on Java we are dependent on hotspot to support it in the native bytecode interpreter. In truffle interpreters we made some successful experiments with tail calls emulated using exceptions. It's pretty slow in the interpreter but as soon as graal optimizes it, it just turns into a tailcall loop.
Here is some more info:
http://epub.jku.at/obvulihs/content/pageview/508465
You may find some blog posts about truffle and tailcalls as well.
Comment · 8 years ago
It started as fork of Zippy. It changed very much since then. You can download the binary as part of graalvm. It's not yet open source, but it will be. It's just not ready yet.
Comment · 8 years ago
Good idea. The name is not final.
Comment · 8 years ago
Graal dev here. We're testing on jdk 8,9,10 and 11. We are packing graalvm with jdk 8 atm to keep variability reasonable. Graal will be integrated into the JVM soon with project Metropolis: http://openjdk.java.net/projects/metropolis/
Graal is used for many more things than dynamically compiling Java. Besides others it's used for SubstrateVM (closed world AOT compilation) and Truffle languages like TruffleRuby, Graal.JS, FastR, Sulong(llvm integration) and our newest member Graal.Python.
Graal comes out of Oracle Labs. The build tool mx is short for Maxine, the spiritual predecessor of the Graal project. If you don't know mx it's quite intimidating and ugly. It's Python written by Java developers. But it does it's job coping with our not so standard building and testing requirements. No we don't run mx on Graal.Python yet, but we are working on it for full build tool metacircularity ;).
Comment · 9 years ago
Didn't they say in the end that c9.io will continue to work?