151–160 of 218 posts
Earlier quoted context omitted.
Doesn't OSX ship with more GPL code than BSD? It has a BSD kernel at it's core but it also has GNU tools and safari (forked from KHTML).
Yeah, but Apple doesn't mind sharing the source for those, if they make modifications. These licenses prevent Graal VM from being used inside e.g. OSes and browsers with a more liberal license.
Earlier quoted context omitted.
Like Google, Microsoft, Apple dropping tech, or replacing it with something else, just because. Oracle has done lots of nice things for Java, some of them with uncertain future or even tabu at Sun, like Graal's percusor MaximeVM or AOT compilation. It might not be a company loved by FOSS, but other than IBM there wasn't anyone else caring that much for Java's fate, Google specially did not even bothered. So I appreci…
Your point being ? We are all aware of the danger of using techs from those companies.
Earlier quoted context omitted.
Like Google, Microsoft, Apple dropping tech, or replacing it with something else, just because. Oracle has done lots of nice things for Java, some of them with uncertain future or even tabu at Sun, like Graal's percusor MaximeVM or AOT compilation. It might not be a company loved by FOSS, but other than IBM there wasn't anyone else caring that much for Java's fate, Google specially did not even bothered. So I appreci…
Comparing Oracle to Google is like comparing China gov to US gov. They both do bad things, but they are not remotely the same, the difference is well over 10x. Recent story about Oracle exercising copyright over the word "javascript": https://news.ycombinator.com/item?id=16862949 Remember when Oracle sued Google for re-implementing the Java standard library. Remember the OpenOffice -> LibreOffice thing. Remember the…
Ask that to the civil victims of drone attacks and Apache pilots having fun with civil convoys, as proven by many available video footage.
> Recent story about Oracle exercising copyright over the word "javascript": https://news.ycombinator.com/item?id=16862949
It was a decision done by Apple, Oracle did not move a finger.
"As you are likely aware, Oracle owns US Trademark Registration No. 2416017 for JAVASCRIPT. The seller of this iTunes app prominently displays JAVASCRIPT without authorization from our client. The unauthorized display of our client's intellectual property is likely to cause consumers encountering this app to mistakenly believe that it emanates from, or is provided under a license from, Oracle. Use of our client's trademark in such a manner constitutes trademark infringement in violation of the Lanham Act. 15 U.S.C. § 1125(a)(1)(A). In order to prevent further consumer confusion and infringement of our client's intellectual property rights, we request that you immediately disable access to this app. We look forward to your confirmation that you have complied with this request."
> Remember when Oracle sued Google for re-implementing the Java standard library.
Not only do I remember, I stand by it.
"James Gosling: Oracle vs Google"
https://www.youtube.com/watch?v=JQ7xVO9lqD0
> Remember the OpenOffice -> LibreOffice thing. Remember the Hudson -> Jenkins thing.
I do, other companies did similar things without getting the half the hate Oracle does.
Many people here even would probably like to work for those companies.
Earlier quoted context omitted.
Yeah, but Apple doesn't mind sharing the source for those, if they make modifications. These licenses prevent Graal VM from being used inside e.g. OSes and browsers with a more liberal license.
And how many of those changes have actually benefited FreeBSD?
The fact that some people will use the code without giving back is secondary to that.
That is not just my opinion, because if a more liberal library comes into existence (inevitable), it will prevail.
Earlier quoted context omitted.
Your point being ? We are all aware of the danger of using techs from those companies.
And yet, we use techs from those companies on a daily basis. JVM especially. GraalVM is the next step in JVM's evolution. It's not hard to imagine that this will motivate other JVM vendors to add serious support for other languages.
Earlier quoted context omitted.
And how many of those changes have actually benefited FreeBSD?
None, but that is not the point. The point is: can we use the code without hindrance in whatever plans we have now or in the future? Or is building upon the code like going into a long one-way street? The fact that some people will use the code without giving back is secondary to that. That is not just my opinion, because if a more liberal library comes into existence (inevitable), it will prevail.
And on that day you will miss when GNU/Linux mattered.
But hey, we will always have freeware and public domain.
Earlier quoted context omitted.
We are getting there, lots of things work right out of the box just fine. C extensions are still being actively worked on as they often need some amount of patching because of assumptions they make about types and so forth. I think we can reduce that, but I doubt it can will disappear entirely, but in the end I hope extension authors will test on TruffleRuby themselves and patch the code themselves.
I know that you are using Rails as a reference point so is there any ETA when will be most of the features usable ? (openssl,activerecord,nokogiri..etc) ?
I’m working on Discourse at the moment and can run the dB create and migrate tasks and I’m working on the asset compilation pipeline, but it’s all pretty rough and won’t be our final solution.
Earlier quoted context omitted.
And yet, we use techs from those companies on a daily basis. JVM especially. GraalVM is the next step in JVM's evolution. It's not hard to imagine that this will motivate other JVM vendors to add serious support for other languages.
Very few people make conscious choices to build their life or society.
I have been paying some scant attention to GraalVM for some time, having been excited by "universal VMs" for decades now (including setups like LLVM, which most people forget was designed as a JIT-compiled VM, despite that being in the name), and I develop Cycript (which is somewhat the "opposite" technology, binding together existing virtual machines all into the same process space and doing crazy interop; though I…
Is there an existing embedding for node.js That's what their "node" program actually is. It's regular node but using GraalVM instead of V8. The semantic difference you're getting at doesn't seem to exist. I guess I was expecting a C/C++ API to be documented somewhere, not a Java API SubstrateVM has a C API that can be used to start it up that's not the same as JNI, however, bear in mind Graal can be used as a plugin…
No, because what I'm trying to accomplish is "I'm inside of a node.js program and I want to instantiate a GraalVM virtual machine instance context, load a random Java class (or whatever), and run a function on that class". Even if I'm running my node.js code on top of GraalVM, the semantic difference fundamentally exists. Like, you are trying to tell me that somehow running my node.js program on top of GraalVM is the same thing as being able to run GraalVM from inside of my program (which just so happens to be written in node.js, but that's arbitrary and meaningless in a way: I just want good bindings for the language I happened to write it in) on arbitrary code, but that clearly doesn't make any sense. I mean, it certainly isn't true for their Java embedding API, why/how would it somehow be true for their node.js API?
> SubstrateVM has a C API that can be used to start it up that's not the same as JNI... So you can just embed the JVM the usual way and ship the Graal compiler with it...
But SubstrateVM is the offline VM for AOT use, not the runtime VM for JIT use, so I really am not that interested in the SubstrateVM API... it isn't at all relevant for the use case I'm describing for embedding GraalVM; and the Graal compiler in this context is also for AOT use, which again isn't relevant for the use case of embedding the GraalVM.
What makes GraalVM interesting here is that it is a JIT. Just take a step back for a second and imagine you have a C program, and you want to boot that JIT and use it, as a library, loaded into your process. That's the use case here. You seem to be confusing that with either running the C program inside of the VM (which doesn't even change the problem) and then later with pre-compiling the thing we want to load and bringing the compiled code into the process (which bypasses the wonderful goal of working with the JIT).
The way you do this using their Java embedding API is clearly documented, and it is absolutely not the same thing as running a Java application in the GraalVM: it is a set of APIs that let you instantiate Graal Context objects, eval() code in various languages, and then work with the proxy Value objects. I am asking if that API has been exposed to any languages other than Java yet. It seems (from the answer from someone who actually works on Graal from 8 hours before your comment) that the answer is "yes" for C/C++, but I'm still guessing the answer is "no" for node.js.
1. Community Edition (CE)
> GraalVM CE is available for free for development and production use. It is built from the GraalVM sources available on GitHub
2. Enterprise Edition (EE)
> GraalVM EE provides additional performance, security, and scalability relevant for running critical applications in production. It is free for evaluation uses and available for download from the Oracle Technology Network.
"performance, security, and scalability" words don't present in p1. Is it just me or...?