The Second Coming of Java article
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/ The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 24/11/13 21:19, askoh wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
Well, nothing atually:-) It's already done. Smalltalk/X virtual machine can run Java bytecode and thus all sort of JVM languages :-) Cheers, Jan [1] https://swing.fit.cvut.cz/projects/stx-libjava [2] Marcel Hlopko, Jan KurÅ¡, Jan Vraný, and Claus Gittinger. On the Integration of Smalltalk and Java Ì http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWST... , page 1 :-) [3] http://www.youtube.com/watch?v=p21z3bAt7b0&list=PLCGAAdUizzH027lLWKXh_44cGuE... [4] https://www.youtube.com/watch?v=p3J554BNEz8
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Bravo Jan and your collaborators. You have done it. Anything preventing STX:LIBJAVA from being used in production environments? Anything preventing Pharo and VisualWorks for using the technology also? Any plans to do the same for C# DotNET? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932p4725246.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
Any plans to do the same for C# DotNET?
No, unless we get substantial funding for yet another project :-) Now I thing it would be better to continue discussing STX:LIBJAVA in its mailing list [1] rather than here. So I encourage everyone who's interested to move and continue there. [1] https://groups.google.com/forum/#!forum/stxlibjava-dev
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932p4725246.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons. The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1]. The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-) Cheers, Jan [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
I downloaded ST/X this morning and looked around for a couple hours. Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant> What struck me was the speed. Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system). This is not linked to the VM, as the MVC projects in Squeak are uber fast. Is the Text rewrite going to have an impact on this? On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale. On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment. In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp Phil On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money.
The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
Try to switch back to bitmap DejaVu font and I'm sure you'll notice a difference. 2013/11/26 phil@highoctane.be <phil@highoctane.be>
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money.
The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
2013/11/26 phil@highoctane.be <phil@highoctane.be>:
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
It doesn't feel slow, it is slow. Perfectly usable, though. I even feel it was faster before. But I think the problem comes from the "rendering" side, and not because of "not UI" operations running in the main thread. Regards,
I also noticed that Sean does a replacement of the small size fonts with large size fonts in a specific way to speed up rendering of larger font (In his Configuration that does Preferences). I've got eyesight issues, so I am also using larger fonts. That doesn't help with speed indeed. But the Paragraph rendering code is also a culprit I think, as it endlessly recreates objects all the time. Morphs with step methods and a short stepping time are pretty fast. I've a educational game on the iPad that uses this and it is pretty nice in terms of rendering speed (dragging and dropping formula pieces around). --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Nov 26, 2013 at 8:27 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/11/26 phil@highoctane.be <phil@highoctane.be>:
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
It doesn't feel slow, it is slow. Perfectly usable, though. I even feel it was faster before.
But I think the problem comes from the "rendering" side, and not because of "not UI" operations running in the main thread.
Regards,
On Nov 26, 2013, at 9:53 PM, phil@highoctane.be wrote:
I also noticed that Sean does a replacement of the small size fonts with large size fonts in a specific way to speed up rendering of larger font (In his Configuration that does Preferences). I've got eyesight issues, so I am also using larger fonts. That doesn't help with speed indeed.
But the Paragraph rendering code is also a culprit I think, as it endlessly recreates objects all the time.
Igor was working on a new textEditor but he is down energy since a month. So we will see what will happen. Sadly he was working well with fernando. We will see if we can help him getting back to energy. Stef
Morphs with step methods and a short stepping time are pretty fast. I've a educational game on the iPad that uses this and it is pretty nice in terms of rendering speed (dragging and dropping formula pieces around).
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 8:27 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote: 2013/11/26 phil@highoctane.be <phil@highoctane.be>:
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
It doesn't feel slow, it is slow. Perfectly usable, though. I even feel it was faster before.
But I think the problem comes from the "rendering" side, and not because of "not UI" operations running in the main thread.
Regards,
That's the issue with such an immense amount of work to do and brainpower to use. Lots of rest, getting away from everything for while definitely helps. Just an advice from the burned-out anonymous... Phil On Tue, Nov 26, 2013 at 10:04 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Nov 26, 2013, at 9:53 PM, phil@highoctane.be wrote:
I also noticed that Sean does a replacement of the small size fonts with large size fonts in a specific way to speed up rendering of larger font (In his Configuration that does Preferences). I've got eyesight issues, so I am also using larger fonts. That doesn't help with speed indeed.
But the Paragraph rendering code is also a culprit I think, as it endlessly recreates objects all the time.
Igor was working on a new textEditor but he is down energy since a month. So we will see what will happen. Sadly he was working well with fernando. We will see if we can help him getting back to energy.
Stef
Morphs with step methods and a short stepping time are pretty fast. I've a educational game on the iPad that uses this and it is pretty nice in terms of rendering speed (dragging and dropping formula pieces around).
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 8:27 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/11/26 phil@highoctane.be <phil@highoctane.be>:
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
It doesn't feel slow, it is slow. Perfectly usable, though. I even feel it was faster before.
But I think the problem comes from the "rendering" side, and not because of "not UI" operations running in the main thread.
Regards,
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving. Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote: On 26/11/13 10:40, Serge Stinckwich wrote: On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote: On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me). I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on. Also read the Tour of the OE of Tim Rowledge and Porting the VM etc. Also looked at the VMMaker package (Interpreter and Object Memory) + Slang. Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter. Any plans? Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Nov 26, 2013 at 9:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving.
Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money.
The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
On Tue, Nov 26, 2013 at 12:49 PM, phil@highoctane.be <phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on.
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
Any plans?
David Lewis and I want to see the Cog branch and the VMMaker proper merged and I definitely want the standard Interpreter to be married to Spur. But I have no cycles to do this, and I don't think David has many either. Volunteers welcome.
Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 9:33 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving.
Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz>wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
-- best, Eliot
On Tue, Nov 26, 2013 at 01:30:40PM -0800, Eliot Miranda wrote:
On Tue, Nov 26, 2013 at 12:49 PM, phil@highoctane.be <phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on.
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
Any plans?
David Lewis and I want to see the Cog branch and the VMMaker proper merged and I definitely want the standard Interpreter to be married to Spur. But I have no cycles to do this, and I don't think David has many either. Volunteers welcome.
Fully agree :-) With respect to the interpreter simulator, the simulators tend to get bit rotted when not used, but I think that overall they are in reasonable shape. Granted that we currently have to fumble around with multiple code bases, but it's fair to say that if you want to run a Cog/StackInterpreter/Spur simulator, you can use the appropriate classes in the oscog branch (after all, that is what Eliot is using for his active development, and it's quite unlikely that he could do this without a working simulator). And if you want to run an image using the classic interpreter, you should use the interpreter simulator in the "trunk" VMMaker branch. I realize this may be a bit confusing, but as Eliot says there are only so may free cycles available, so if someone wants to help ... I just tried loading an image into the ("trunk") InterpreterSimulator and found a problem in loading an image that had been saved from Cog. This would be a problem if you wanted to load a Pharo image into the InterpreterSimulator to try running bytecodes using a simple interpreter. The fix is in VMMaker-dtl.330 in the source.squeak.org/VMMaker repository. Hopefully it works for you now, please give it a try. Dave
Hi Dave, Eliot, Dave, Yes, that is the problem I was running into. I'll check that out. I could get a bit further by hacking some version numbers if I remember well but then got stuck again. I do not remember why exactly. It felt a bit like crossing the desert with a single bottle of water :-) Eliot, Thanks for the pointers. Maybe would it be great to have a Google Hangout or two with the people doing the VM work (you both, Clement, Esteban, ...) and go through what matters in the process of dealing with the simulators. Phil On Wed, Nov 27, 2013 at 4:01 AM, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Nov 26, 2013 at 01:30:40PM -0800, Eliot Miranda wrote:
On Tue, Nov 26, 2013 at 12:49 PM, phil@highoctane.be <phil@highoctane.be wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on.
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
Any plans?
David Lewis and I want to see the Cog branch and the VMMaker proper merged and I definitely want the standard Interpreter to be married to Spur. But I have no cycles to do this, and I don't think David has many either. Volunteers welcome.
Fully agree :-)
With respect to the interpreter simulator, the simulators tend to get bit rotted when not used, but I think that overall they are in reasonable shape. Granted that we currently have to fumble around with multiple code bases, but it's fair to say that if you want to run a Cog/StackInterpreter/Spur simulator, you can use the appropriate classes in the oscog branch (after all, that is what Eliot is using for his active development, and it's quite unlikely that he could do this without a working simulator). And if you want to run an image using the classic interpreter, you should use the interpreter simulator in the "trunk" VMMaker branch.
I realize this may be a bit confusing, but as Eliot says there are only so may free cycles available, so if someone wants to help ...
I just tried loading an image into the ("trunk") InterpreterSimulator and found a problem in loading an image that had been saved from Cog. This would be a problem if you wanted to load a Pharo image into the InterpreterSimulator to try running bytecodes using a simple interpreter. The fix is in VMMaker-dtl.330 in the source.squeak.org/VMMaker repository. Hopefully it works for you now, please give it a try.
Dave
Hey, 2013/11/27 phil@highoctane.be <phil@highoctane.be>
Hi Dave, Eliot,
Dave,
Yes, that is the problem I was running into. I'll check that out. I could get a bit further by hacking some version numbers if I remember well but then got stuck again. I do not remember why exactly. It felt a bit like crossing the desert with a single bottle of water :-)
Eliot,
Thanks for the pointers.
Maybe would it be great to have a Google Hangout or two with the people doing the VM work (you both, Clement, Esteban, ...) and go through what matters in the process of dealing with the simulators.
There's no so much problems, someone just need to spend time making the simulator work on Pharo 2.0. Basically you need to fix usages of TranscriptStream, FileSystem and Morph to new APIs. I will do it at some point for Sista. But right now I focus on the in-image part so I will do it later (I hope in a month at most).
Phil
On Wed, Nov 27, 2013 at 4:01 AM, David T. Lewis <lewis@mail.msen.com>wrote:
On Tue, Nov 26, 2013 at 01:30:40PM -0800, Eliot Miranda wrote:
On Tue, Nov 26, 2013 at 12:49 PM, phil@highoctane.be < phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book, understand the primitives, can somewhat read bytecode but what is needed now is the ability to run/debug a VM inside Pharo itself. GDB'ing is okay but a pain in the ass to understand what's going on.
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
Any plans?
David Lewis and I want to see the Cog branch and the VMMaker proper merged and I definitely want the standard Interpreter to be married to Spur. But I have no cycles to do this, and I don't think David has many either. Volunteers welcome.
Fully agree :-)
With respect to the interpreter simulator, the simulators tend to get bit rotted when not used, but I think that overall they are in reasonable shape. Granted that we currently have to fumble around with multiple code bases, but it's fair to say that if you want to run a Cog/StackInterpreter/Spur simulator, you can use the appropriate classes in the oscog branch (after all, that is what Eliot is using for his active development, and it's quite unlikely that he could do this without a working simulator). And if you want to run an image using the classic interpreter, you should use the interpreter simulator in the "trunk" VMMaker branch.
I realize this may be a bit confusing, but as Eliot says there are only so may free cycles available, so if someone wants to help ...
I just tried loading an image into the ("trunk") InterpreterSimulator and found a problem in loading an image that had been saved from Cog. This would be a problem if you wanted to load a Pharo image into the InterpreterSimulator to try running bytecodes using a simple interpreter. The fix is in VMMaker-dtl.330 in the source.squeak.org/VMMakerrepository. Hopefully it works for you now, please give it a try.
Dave
On Tue, Nov 26, 2013 at 5:49 PM, phil@highoctane.be <phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book,
I been writing a lot about that, at least as much as I could.
understand the primitives,
http://marianopeck.wordpress.com/tag/primitives/
can somewhat read bytecode
http://marianopeck.wordpress.com/tag/bytecodes/
but what is needed now is the ability to run/debug a VM inside Pharo itself.
Yes, the simulator does not run these days.
GDB'ing is okay but a pain in the ass to understand what's going on.
Ok, for debugging the VM with gdb I have: http://marianopeck.wordpress.com/tag/gdb/
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
If you want to learn, besides all those mentioned books, you can start with http://marianopeck.wordpress.com/2011/03/31/journey-through-the-vm/ that is a sequence of a lots of posts related to the VM. Cheers,
Any plans?
Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 9:33 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving.
Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz>wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
-- Mariano http://marianopeck.wordpress.com
On Tue, Nov 26, 2013 at 5:20 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Nov 26, 2013 at 5:49 PM, phil@highoctane.be <phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book,
I been writing a lot about that, at least as much as I could.
understand the primitives,
http://marianopeck.wordpress.com/tag/primitives/
can somewhat read bytecode
http://marianopeck.wordpress.com/tag/bytecodes/
but what is needed now is the ability to run/debug a VM inside Pharo itself.
Yes, the simulator does not run these days.
That's simply not true. I use the simulator *every day*. It is vital for the development of Spur. Starting it up these days is as simple as (| vm | vm := StackInterpreterSimulator newWithOptions: #(). vm openOn: '/Users/eliot/Cog/startreader.image'. vm openAsMorph; run) something slightly more complex would be (| vm | vm := CogVMSimulator newWithOptions: #(ObjectMemory Spur32BitCoMemoryManager Cogit StackToRegisterMappingCogit). vm desiredNumStackPages: 8. vm objectMemory setCheckForLeaks: 1. vm openOn: '/Users/eliot/Cog/spurreader.image'. vm openAsMorph; toggleTranscript; halt; run) See the class comments in StackInterpreterSimulator and CogVMSimulator.
GDB'ing is okay but a pain in the ass to understand what's going on.
Ok, for debugging the VM with gdb I have:
http://marianopeck.wordpress.com/tag/gdb/
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
If you want to learn, besides all those mentioned books, you can start with http://marianopeck.wordpress.com/2011/03/31/journey-through-the-vm/ that is a sequence of a lots of posts related to the VM.
Cheers,
Any plans?
Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 9:33 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving.
Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz>wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
Thanks. I've read the all. Especially when I wanted to get the iPad version running and customized some things in there and ran into CMake bugs at the time. Thanks for writing them, they helped! Phil On Wed, Nov 27, 2013 at 2:20 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Nov 26, 2013 at 5:49 PM, phil@highoctane.be <phil@highoctane.be>wrote:
FWIW, I'd love to have a working Pharo bytecode interpreter that works. VMMaker currently doesn't have one it seems (earlier experiments didn't worked for me).
I am very interested with the VM, read the blue book,
I been writing a lot about that, at least as much as I could.
understand the primitives,
http://marianopeck.wordpress.com/tag/primitives/
can somewhat read bytecode
http://marianopeck.wordpress.com/tag/bytecodes/
but what is needed now is the ability to run/debug a VM inside Pharo itself.
Yes, the simulator does not run these days.
GDB'ing is okay but a pain in the ass to understand what's going on.
Ok, for debugging the VM with gdb I have: http://marianopeck.wordpress.com/tag/gdb/
Also read the Tour of the OE of Tim Rowledge and Porting the VM etc.
Also looked at the VMMaker package (Interpreter and Object Memory) + Slang.
Now, getting an working interpreter would help me reach the next step. I am not talking about the Stack interpreter, but the plain Interpreter.
If you want to learn, besides all those mentioned books, you can start with http://marianopeck.wordpress.com/2011/03/31/journey-through-the-vm/ that is a sequence of a lots of posts related to the VM.
Cheers,
Any plans?
Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Nov 26, 2013 at 9:33 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Nov 26, 2013, at 1:21 PM, phil@highoctane.be wrote:
I downloaded ST/X this morning and looked around for a couple hours.
Impressive system. And impressive clients list/activities etc. <rant> And wow, Claus is yet another individual with top notch computer chops... Seems that this community has the highest density of high perf brains. I feel humbled indeed. </rant>
What struck me was the speed.
15 years of working improving the VM pays off. This is why the work of Eliot on Spur are also important. What is also important is that more people can work on the VM for cleaning it so that we get a documented and good vehicule. And this will take time. We are working on a prototype to get forced to think about VM and learn. But this prototype will not replace Cog in the near future. So we should be happy that cog is there and improving.
Stef
Pharo really needs a huge speedup on the UI front. I am using a top of the line desktop system and still Pharo sometimes feels slow (some is due to algorithms - like the finder tool taking ages for a lot of things, but some is due to the UI system).
This is not linked to the VM, as the MVC projects in Squeak are uber fast.
Is the Text rewrite going to have an impact on this?
On the front of interoperability, I personally have chosen to go the RabbitMQ route, it allows me to wire all kinds of things together with some room for scale.
On the Java front itself, in the TCL community, we do have tclbend and also a package to do the same thing as STX:LIBJAVA. Truth be told, there hasn't been much traction in there. It works fine but that's it. http://www2.tcl.tk/1313 - usage sample http://www2.tcl.tk/14919 It also has fell behind in terms of keeping up with the latest versions of the environment.
In PHP, there is the Quercus and Caucho Resin Server that allows to run PHP on top of the JVM and invoke Java from there. Some people run very fast stuff on that, and benefiting from all JEE abilities (JMS, JTA, Clustering, JAAS...) is really nice. http://www.caucho.com/resin-3.1/doc/quercus.xtp
Phil
On Tue, Nov 26, 2013 at 12:26 PM, Jan Vrany <jan.vrany@fit.cvut.cz>wrote:
On 26/11/13 10:40, Serge Stinckwich wrote:
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 26/11/13 03:28, askoh wrote:
Bravo Jan and your collaborators. You have done it.
Thanks.
Anything preventing STX:LIBJAVA from being used in production environments?
Good question. STX:LIBJAVA is still a research phase. However, if everything goes fine, we might have first project using it for real in couple months.
What is important is also the licence. Do you use an open-source licence ?
Strictly speaking - no. For various, historical reasons.
The Smalltalk part STX:LIBJAVA support code is available under the same terms as Smalltalk/X itself [1].
The code of the VM is not publicly available for various reasons, though it is possible to get an access. Ask Claus Gittinger if you're interested in details.
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
Maybe I should. But frankly - how many people in this community are like "That would be great, I need this feature!" Raise hands. :-)
Cheers, Jan
[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup
-- Mariano http://marianopeck.wordpress.com
On 26 Nov 2013, at 11:41, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
I do not think that he talks about this kind of money. But MONEY. Marcus
On Tue, Nov 26, 2013 at 12:40 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Nov 2013, at 11:41, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
Anything preventing Pharo and VisualWorks for using the technology also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
I do not think that he talks about this kind of money. But MONEY.
Ok I understand ;-) BIG MONEY -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
To have Java running on top of Pharo (which means on top of Cog), you would need to have as they did in STX, a JIT compatible with java bytecode, an interpreter for java bytecode, runtime objects such as JavaContext, ... It is at least 1 year of work for an expert in virtual machines (I think there's mainly 1 expert in the Cog VM but there are several on java VM). Therefore this project requires several hundred thousands dollars (considering you can find a virtual machine expert willing to do it). A bit too much for ESUG in my opinion. 2013/11/26 Serge Stinckwich <serge.stinckwich@gmail.com>
On Tue, Nov 26, 2013 at 12:40 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Nov 2013, at 11:41, Serge Stinckwich <serge.stinckwich@gmail.com>
wrote:
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
I do not think that he talks about this kind of money. But MONEY.
Ok I understand ;-) BIG MONEY
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Here is the video of his Smalltalk 2013 talk for the ones interested: https://www.youtube.com/watch?v=p21z3bAt7b0&list=PLCGAAdUizzH027lLWKXh_44cGu... 2013/11/26 Clément Bera <bera.clement@gmail.com>
To have Java running on top of Pharo (which means on top of Cog), you would need to have as they did in STX, a JIT compatible with java bytecode, an interpreter for java bytecode, runtime objects such as JavaContext, ... It is at least 1 year of work for an expert in virtual machines (I think there's mainly 1 expert in the Cog VM but there are several on java VM). Therefore this project requires several hundred thousands dollars (considering you can find a virtual machine expert willing to do it). A bit too much for ESUG in my opinion.
2013/11/26 Serge Stinckwich <serge.stinckwich@gmail.com>
On Tue, Nov 26, 2013 at 12:40 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Nov 2013, at 11:41, Serge Stinckwich <serge.stinckwich@gmail.com>
wrote:
Anything preventing Pharo and VisualWorks for using the technology
also?
Short answer: Time and money. The way we did it requires significant changes to the virtual machine (as we believe this is the only way to get a decent performance). Indeed, if somebody going to pay for it, everything's possible ;-)
You should try to ask ESUG about financial support.
I do not think that he talks about this kind of money. But MONEY.
Ok I understand ;-) BIG MONEY
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Jan: Can you give us a bit of history of STX:LIBJAVA? Even if it was just for fun what was the rational? What killer app might there be? What business models are there to pursue? How much effort was used and who funded your group? Can you debug Java like all the power of Smalltalk debugger? Congratulations again. How about an easier name like StJ? or SXJ? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932p4725471.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 27/11/13 00:58, askoh wrote:
Jan:
Can you give us a bit of history of STX:LIBJAVA? Even if it was just for fun what was the rational? What killer app might there be? What business models are there to pursue? How much effort was used and who funded your group? Can you debug Java like all the power of Smalltalk debugger? Congratulations again.
How about an easier name like StJ? or SXJ?
I answered in STX:LIBJAVA mailing list: https://groups.google.com/forum/#!topic/stxlibjava-dev/DQRx2chB2p0 Jan
On Sun, Nov 24, 2013 at 1:19 PM, askoh <askoh@askoh.com> wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
Time and money.
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- best, Eliot
Its also way simpler and faster to just make java apps communicate with pharo via sockets. You dont need pharo to run JVM , all you need is a way to communicate with it. So why do it the hard way ? ΣÏÎ¹Ï 24 Îοε 2013 11:20 μ.μ., ο ÏÏήÏÏÎ·Ï "askoh" <askoh@askoh.com> ÎγÏαÏε:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM. I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. Plenty of options already. On Mon, Nov 25, 2013 at 9:54 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 25/11/13 19:17, kilon alios wrote:
Its also way simpler and faster to just make java apps communicate with pharo via sockets.
No, it's not simpler nor faster. Imagine you want to parse and validate XML using Xerces parser while having your SAX handler written in Smalltalk.
Jan
On 25 Nov 2013, at 21:13, kilon alios <kilon.alios@gmail.com> wrote:
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution.
Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM.
I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported.
Keep in mind that supporting syntax is one thing, semantics is the other⦠Ometa is just a (very nice) tool for making implementing a parser for syntax easier, very much like PetitParser. I once did a very, very naive demo of adding other *syntax* to Squeak⦠http://www.slideshare.net/MarcusDenker/a-programming-language-babel But the problem is that the *semantics* are still that of Smalltalk, and itâs completely not clear for the programmer where the similarity ends. If you want to have âI can type in examples from my ruby bookâ compatibility, you need to implement the real semantics, which in many cases means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to support those semantics. There has been more research recently about multi-language VMs⦠or frameworks to build VMs (PyPy, for example). Without this support, getting 100% correct semantic *and* be fast enough (not even fast) is very hard. Marcus
But the problem is that the *semantics* are still that of Smalltalk, and itâs completely not clear for the programmer where the similarity ends.
If you want to have âI can type in examples from my ruby bookâ compatibility, you need to implement the real semantics, which in many cases means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to support those semantics.
Just imagine things like that... https://www.destroyallsoftware.com/talks/wat :-) Marcus
ROFL thank you Marcus I needed a good laugh. I have watched this before, but as always completely forgot about it. I think its great when people don't take coding so seriously and have fun with it. I agree also that no pharoer would be against Java coming to pharo , the problem is who is going to do it. There so many great ideas out there, but actually doing the work is both hard and time consuming. On Mon, Nov 25, 2013 at 10:44 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
But the problem is that the *semantics* are still that of Smalltalk, and
itâs completely not clear for the programmer where the similarity ends.
If you want to have âI can type in examples from my ruby bookâ
compatibility, you need to implement the real semantics, which in many cases
means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to support those semantics.
Just imagine things like that...
https://www.destroyallsoftware.com/talks/wat
:-)
Marcus
I have actually used PyPy , the socket bridge I had created was to make PyPy communicate with cpython embeded in the open source 3d application Blender and vice versa. I wanted to use PyPy to speed up blender cpython. Very friendly community too. AFAIK they had a Smalltalk implementation on top of PyPy but I dont think its maintained anymore. On Mon, Nov 25, 2013 at 10:27 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 25 Nov 2013, at 21:13, kilon alios <kilon.alios@gmail.com> wrote:
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution.
Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM.
I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported.
Keep in mind that supporting syntax is one thing, semantics is the other⦠Ometa is just a (very nice) tool for making implementing a parser for syntax easier, very much like PetitParser. I once did a very, very naive demo of adding other *syntax* to Squeakâ¦
http://www.slideshare.net/MarcusDenker/a-programming-language-babel
But the problem is that the *semantics* are still that of Smalltalk, and itâs completely not clear for the programmer where the similarity ends.
If you want to have âI can type in examples from my ruby bookâ compatibility, you need to implement the real semantics, which in many cases means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to support those semantics.
There has been more research recently about multi-language VMs⦠or frameworks to build VMs (PyPy, for example). Without this support, getting 100% correct semantic *and* be fast enough (not even fast) is very hard.
Marcus
On 25/11/13 20:12, kilon alios wrote:
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution.
OK, let's make an experiment and we'll see :-) Here's the code that parses XML using Xerces on VM that runs both Smalltalk and Java: ======================= factory := JAVA javax xml parsers SAXParserFactory newInstance. parser := factory newSAXParser getXMLReader. parser setContentHandler: JavaExamples::CDDatabaseHandler2 new. [ parser parse: build_xml. ] on: JAVA java io IOException do:[:ioe| Transcript showCR: 'I/O error: ', ioe getMessage. ioe printStackTrace ] on: UserNotification do:[:un| Transcript showCR: un messageText. un proceed. ] ======================= The handler: https://bitbucket.org/janvrany/stx-libjava/src/e5fc3aaad7a2a9f06ba1f28e2144e... Now, you implement solution using sockets or any other kind of RPC. Then lets write a benchmark and check what's simpler and what's faster. I would be very interested in results. Anyway, we're getting bit offtopic I guess. If you want to do proposed experiment, drop me a private message (unless the list shows interest :-) Best, Jan P.S.: If you like the challenge, then consider small modification of the code above **without** `un proceed` at the end of handler of UserNotification.
Hi Jan, On 25 Nov 2013, at 22:47, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Here's the code that parses XML using Xerces on VM that runs both Smalltalk and Java:
======================= factory := JAVA javax xml parsers SAXParserFactory newInstance. parser := factory newSAXParser getXMLReader. parser setContentHandler: JavaExamples::CDDatabaseHandler2 new. [ parser parse: build_xml. ] on: JAVA java io IOException do:[:ioe| Transcript showCR: 'I/O error: ', ioe getMessage. ioe printStackTrace ] on: UserNotification do:[:un| Transcript showCR: un messageText. un proceed. ] =======================
This is really nice and beautiful code. Very well done ! Sven
I am not familiar with the libraries you referring to nor I have messed with XML (thank god). I dont care which is faster I only care which is fast enough. I have never benchmarked my sockets but they always have been fast enough for my needs. I have found a benchmark here http://www.opendmx.net/index.php/Pipe_vs_Unix_Socket_Performance . 10 seconds for 512 MB does not sound bad to me at all. But then if you want much higher speeds for even bigger data, then sockets are not for you. The data I have played with is in the range of kbs. Though I fear that smalltalk will be the bottleneck way before sockets will be. Unless you using a C library via nativeboost or another FFI. On Mon, Nov 25, 2013 at 11:47 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 25/11/13 20:12, kilon alios wrote:
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution.
OK, let's make an experiment and we'll see :-)
Here's the code that parses XML using Xerces on VM that runs both Smalltalk and Java:
======================= factory := JAVA javax xml parsers SAXParserFactory newInstance. parser := factory newSAXParser getXMLReader. parser setContentHandler: JavaExamples::CDDatabaseHandler2 new. [ parser parse: build_xml. ] on: JAVA java io IOException do:[:ioe| Transcript showCR: 'I/O error: ', ioe getMessage. ioe printStackTrace ] on: UserNotification do:[:un| Transcript showCR: un messageText. un proceed. ] =======================
The handler:
https://bitbucket.org/janvrany/stx-libjava/src/ e5fc3aaad7a2a9f06ba1f28e2144eb0acfb1ec13/examples/ CDDatabaseHandler2.st?at=development
Now, you implement solution using sockets or any other kind of RPC.
Then lets write a benchmark and check what's simpler and what's faster. I would be very interested in results.
Anyway, we're getting bit offtopic I guess. If you want to do proposed experiment, drop me a private message (unless the list shows interest :-)
Best, Jan
P.S.: If you like the challenge, then consider small modification of the code above **without** `un proceed` at the end of handler of UserNotification.
Actually, do I want to have Pharo running on Java? My answer was âyesâ a couple of years before. Today, I want to have Pharo (or at least most of it) running in a web browser. Distributing applications to clients is then so easy... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 24, 2013, at 6:19 PM, askoh <askoh@askoh.com> wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Speaking of which, I'd love to have a go at targeting Emscripten https://github.com/kripken/emscripten/wiki We can do this by using llvm-gcc producing bitcode. It may not be too hard to compile things, of course, the next challenge is with all the display and I/O. But if they can do Unreal3, MESS emulators, and Commodore Emulators, we should be able to do a PharoVM. Phil On Mon, Nov 25, 2013 at 8:18 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
Actually, do I want to have Pharo running on Java? My answer was âyesâ a couple of years before. Today, I want to have Pharo (or at least most of it) running in a web browser.
Distributing applications to clients is then so easy...
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2013, at 6:19 PM, askoh <askoh@askoh.com> wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes but need people to try. This was on my todo for a topics for students. On Nov 25, 2013, at 11:14 PM, phil@highoctane.be wrote:
Speaking of which, I'd love to have a go at targeting Emscripten
https://github.com/kripken/emscripten/wiki
We can do this by using llvm-gcc producing bitcode.
It may not be too hard to compile things, of course, the next challenge is with all the display and I/O.
But if they can do Unreal3, MESS emulators, and Commodore Emulators, we should be able to do a PharoVM.
Phil
On Mon, Nov 25, 2013 at 8:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Actually, do I want to have Pharo running on Java? My answer was âyesâ a couple of years before. Today, I want to have Pharo (or at least most of it) running in a web browser.
Distributing applications to clients is then so easy...
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2013, at 6:19 PM, askoh <askoh@askoh.com> wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi, I'm coming late to this. I don't fully share the vision of Java as a language having a renaissance, I think it is a mature language, strict by definition, but solid executionwise. So yes, it's a pain the a** to develop with it, particularly having programmed with Smalltalk during a decade. In the server side, you can do decent stuff with almost any language. The difference comes more from tooling and instrumentation (integration with servers, monitoring, etc.). And that comes with Time and Money as Elliot pointed. I can talk about what you can do with Java in Android, and it's pretty impressive. Android took both Java and Linux and shipped it to the masses (end users) as no java applet nor Linux distro ever did. However the use I see in having a Smalltalk running on top of a JVM is that because there are many chances that JVM will run in the "internet of things", sensors, appliances and other devices that will come with only one "platform" shipped from the vendor, and it will be either an open "HTTP based API", or a full fledged native SDK for the system running on top of the JVM. To use Smalltalk in JavaScript Amber is doing a great work, and having Pharo running in a Browser by means of emscripten or similar sounds more like an interesting proof of concept rather than a true advantage. Lively Kernel comes to my mind. So I'm more interested in having Smalltalk (or Pharo) in the forthcoming "internet of things" platform, that will be between us sooner than later. And because of many things (Hi Oracle lobbist!) I think it will run on top of the JVM. Regards! Esteban A. Maringolo 2013/11/24 askoh <askoh@askoh.com>:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (16)
-
Alexandre Bergel -
askoh -
Clément Bera -
David T. Lewis -
Eliot Miranda -
Esteban A. Maringolo -
Guido Chari -
Jan Vrany -
kilon alios -
Marcus Denker -
Mariano Martinez Peck -
Nicolas Cellier -
phil＠highoctane.be -
Serge Stinckwich -
Stéphane Ducasse -
Sven Van Caekenberghe