Re: [Pharo-users] Is there any fundamental technical barrier to compiling to JVM byte codes?
<<<From: St?phane Ducasse <stephane.ducasse@inria.fr> The fun is important. What we want is well designed and powerful libraries that enabled people. For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. Now I do not understand why people develop their own vm instead of joining forces. Doing in the long term something and finishing a task are the most difficult things. Stef á§
Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all. I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk. I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes. Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off. I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier. Cheers Andy
On 27 Dec 2013, at 18:21, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
<<<From: St?phane Ducasse <stephane.ducasse@inria.fr>
The fun is important. What we want is well designed and powerful libraries that enabled people. For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. Now I do not understand why people develop their own vm instead of joining forces. Doing in the long term something and finishing a task are the most difficult things. Stef á§
Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all.
I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk.
I was not aware of that one :) So this means that we have gravel, redline and Rtalk. http://i.cmpnet.com/ddj/images/mediacenter/jvmlanguagesummit/2011_Roos_Rtalk... I understand the motivation behind Rtalk and this is cool that they succeeded. Now what people often forget is that behind the technical challenges you have the libraries and the boring but important work of building greta frameworks.
I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes.
Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off.
I do not know because the problem is that on such topics the devil are in the details. Now what is important is having a bootstrap and clean test covered code base because we could also see how to deploy a gemstone vm or other platform in the future.
I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier.
Cheers Andy
Main problems to compile Smalltalk to java bytecode: - there's no context in java. This means our implementation of continuations and exceptions is not valid anymore. This also means we cannot have a debugger with edit-and-continue as we have now. - there's no become:, which is used to keep the system live Basically you can find tricks to still have become: and a live environment/debugger but in this case the Smalltalk created would be super slow. So compiling smalltalk to java is not an easy problem. Now compiling Pharo to the gemstone VM should be possible and not as hard. The complexity depends mostly on how well the gemstome contexts are implemented. 2013/12/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
On 27 Dec 2013, at 18:21, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
<<<From: St?phane Ducasse <stephane.ducasse@inria.fr>
The fun is important. What we want is well designed and powerful libraries that enabled people. For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. Now I do not understand why people develop their own vm instead of joining forces. Doing in the long term something and finishing a task are the most difficult things. Stef á§
Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all.
I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk.
I was not aware of that one :) So this means that we have gravel, redline and Rtalk.
http://i.cmpnet.com/ddj/images/mediacenter/jvmlanguagesummit/2011_Roos_Rtalk... I understand the motivation behind Rtalk and this is cool that they succeeded.
Now what people often forget is that behind the technical challenges you have the libraries and the boring but important work of building greta frameworks.
I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes.
Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off.
I do not know because the problem is that on such topics the devil are in the details. Now what is important is having a bootstrap and clean test covered code base because we could also see how to deploy a gemstone vm or other platform in the future.
I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier.
Cheers Andy
My take on the issue: -> it is easy to take Smalltalk and make it âless Smalltalkâ and then compile that to JVM (no become, no thisContext, with all consequences). -> What the Smalltalk community should be doing (should have been doing): Make Smalltalk "more Smalltalkâ. Marcus On 28 Dec 2013, at 11:40, Clément Bera <bera.clement@gmail.com> wrote:
Main problems to compile Smalltalk to java bytecode: - there's no context in java. This means our implementation of continuations and exceptions is not valid anymore. This also means we cannot have a debugger with edit-and-continue as we have now. - there's no become:, which is used to keep the system live
Basically you can find tricks to still have become: and a live environment/debugger but in this case the Smalltalk created would be super slow.
So compiling smalltalk to java is not an easy problem.
Now compiling Pharo to the gemstone VM should be possible and not as hard. The complexity depends mostly on how well the gemstome contexts are implemented.
2013/12/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
On 27 Dec 2013, at 18:21, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
<<<From: St?phane Ducasse <stephane.ducasse@inria.fr>
The fun is important. What we want is well designed and powerful libraries that enabled people. For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. Now I do not understand why people develop their own vm instead of joining forces. Doing in the long term something and finishing a task are the most difficult things. Stef á§
Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all.
I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk.
I was not aware of that one :) So this means that we have gravel, redline and Rtalk.
http://i.cmpnet.com/ddj/images/mediacenter/jvmlanguagesummit/2011_Roos_Rtalk... I understand the motivation behind Rtalk and this is cool that they succeeded.
Now what people often forget is that behind the technical challenges you have the libraries and the boring but important work of building greta frameworks.
I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes.
Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off.
I do not know because the problem is that on such topics the devil are in the details. Now what is important is having a bootstrap and clean test covered code base because we could also see how to deploy a gemstone vm or other platform in the future.
I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier.
Cheers Andy
participants (4)
-
Andy Burnett -
Clément Bera -
Marcus Denker -
Stéphane Ducasse