Smalltalk Virtual Machine, StVM
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal? How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc? Thanks in advanced for all you thoughts. Aik-Siong Koh -- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Well to be sincere , languages on JVM have been a dream that did not gain the popularity that some expected. Sure some of these languages got popular, but they never become that popular. Latest popular example being Clojure. I think there are 2 reasons why porting a language to a very popular VM is not a very popular idea a) Porting code sucks, a tedious process b) People want to be in control I have seen that with python, cpython is the most popular and oldest implementation. Compared to cpython , jython that runs on the JVM and ironpython that runs on .NET/Mono are hardly used. Even pypy that is mainly pure python that introduces the JIT VM to python , has been met with a lot of resistance. By the way pypy is not just python with a JIT VM its a whole platform very much like JVM that allows the implementation of languages. PyPy for example has a smalltalk language. But the JIT VM is very complex subject that cpython developers do not want to touch even with a ten meters pole. Its a lot of hard work to convince developers to port to your side when they are happy with millions of lines of code they have already wrote for their own platform. Even when you are all mighty Java. I can talk about python and would say its a lot of work. Over 50% of cpython is in C and most of python libraries are same too. So unless you are willing to port those libraries directly to your smalltalk VM there will be very little interest in your VM. This has been a big problem for PyPy. I think Ruby is in a similar situation. Probably most languages are like this. This also has been a big problem for jython , which is python on JVM. You could assume that python coders would be all excited to run python on JVM and use Java libraries out of the box. Actually no. Python developers are too much in love with cpython libraries and do not blame them. Cpython has created a culture of "there should be one way of doing it" and it has drawn a crowd commited to that mentality, Java aint it. So its more like Java developer that also happen to like python that are drawn to jython that python developers. Another reason is that is not that hard to make software using two different languages and make those two sides communicate. Its not a bad idea though, there will be a crowd that would be interested in running python code inside pharo for example. Afterall some people do use jython and PyPy. So its far from useless. But I would not get my hope high that developers would die for this feature. On Wed, May 14, 2014 at 1:27 PM, askoh <askoh@askoh.com> wrote:
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal?
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Jan did it: https://swing.fit.cvut.cz/projects/stx-libjava -- Pavel 2014-05-14 12:27 GMT+02:00 askoh <askoh@askoh.com>:
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal?
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014-05-14 12:27 GMT+02:00 askoh <askoh@askoh.com>:
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal?
Always the same dream... To have Smalltalk running on the JVM, the main issues is that you do not have a stack reification as contexts and you do not have become: in java. These two features are used to keep the system live: the fancy debugger, editing classes and migrating their instances at runtime. There's a few other details such as having the literal array per method or per class, the second implementation, per class, for java, makes it hard to add a method to a class at runtime. Another detail is that not all smalltalk can bootstrap from sources (for example it is the same heap that we have used and edited in Pharo for the last 3 decades, the unique instance of True may even have been instantiated by Dan Ingalls in 1980 and we are still using it). So basically it is either you have smalltalk running on the jvm wihtout the live smalltalk abilities, or you have a full smalltalk but it is slow.
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
This is somehow done in Smalltalk/X and in Visual Age. I think they both support the Java 1.5 byte code. Now this is a huge pain because you have to implement the java byte code verifier and all these boring stuff. The OpenQuack image, a fork of squeak used by the company 3DICC, has a plugin to run python on the smalltalk VM. Then it depends on your use cases, but usually people prefers to do bindings (like in Pharo you can bind C libraries, including the python/ruby interpreter) instead of adding a full backend for another language, because then you need to maintain the other language and we have very few people working on smalltalk VMs that can maintain that nowadays.
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Wed, May 14, 2014 at 1:52 PM, Clément Bera <bera.clement@gmail.com>wrote:
2014-05-14 12:27 GMT+02:00 askoh <askoh@askoh.com>:
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal?
Always the same dream...
To have Smalltalk running on the JVM, the main issues is that you do not have a stack reification as contexts and you do not have become: in java. These two features are used to keep the system live: the fancy debugger, editing classes and migrating their instances at runtime.
Ah yes, this stack reification and contexts thing. How awesome! I was looking at the WADynamicVariable implementation in Seaside, and obviously, doing just that very cleanly in JVM, well... I guess not, at least not without so little code.
There's a few other details such as having the literal array per method or per class, the second implementation, per class, for java, makes it hard to add a method to a class at runtime.
Interesting. Now, how is all this stuff with Obsolete references working? That's something one nevers encounter in Java I guess.
Another detail is that not all smalltalk can bootstrap from sources (for example it is the same heap that we have used and edited in Pharo for the last 3 decades, the unique instance of True may even have been instantiated by Dan Ingalls in 1980 and we are still using it).
So basically it is either you have smalltalk running on the jvm wihtout the live smalltalk abilities, or you have a full smalltalk but it is slow.
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
This is somehow done in Smalltalk/X and in Visual Age. I think they both support the Java 1.5 byte code. Now this is a huge pain because you have to implement the java byte code verifier and all these boring stuff.
The OpenQuack image, a fork of squeak used by the company 3DICC, has a plugin to run python on the smalltalk VM.
Then it depends on your use cases, but usually people prefers to do bindings (like in Pharo you can bind C libraries, including the python/ruby interpreter) instead of adding a full backend for another language, because then you need to maintain the other language and we have very few people working on smalltalk VMs that can maintain that nowadays.
Where is that billionaire that would shower us with millions ??? Phil
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yeah you are right Goran. The way I write it is incorrect. My bad. It embeds the python runtime it does not reimplement it. 2014-05-14 14:00 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Wed, May 14, 2014 at 1:52 PM, Clément Bera <bera.clement@gmail.com>wrote:
2014-05-14 12:27 GMT+02:00 askoh <askoh@askoh.com>:
There is a trend of making languages to run on Java Virtual Machine. But it still cannot run Smalltalk like Smalltalk on Smalltalk VM. Is it a possible goal?
Always the same dream...
To have Smalltalk running on the JVM, the main issues is that you do not have a stack reification as contexts and you do not have become: in java. These two features are used to keep the system live: the fancy debugger, editing classes and migrating their instances at runtime.
Ah yes, this stack reification and contexts thing. How awesome! I was looking at the WADynamicVariable implementation in Seaside, and obviously, doing just that very cleanly in JVM, well... I guess not, at least not without so little code.
There's a few other details such as having the literal array per method or per class, the second implementation, per class, for java, makes it hard to add a method to a class at runtime.
Interesting. Now, how is all this stuff with Obsolete references working? That's something one nevers encounter in Java I guess.
Regular java classes are in a perm space which is an object space that the GC ignores. They always exist and do not move in memory. They cannot become obsolete whatever you do. Now you can also create classes at runtime in java (I think with something called java.lang.Class). In this case, it is a regular object in the heap, and the class may be garbage collected. There are specific API to add methods to those classes and I don't know how it works. It may be that you have a literal array per method but I don't know. Obsolete classes are created by the Pharo IDE when we manually delete a class. I'm not sure you can do that in java, and if so, the obsolete problem depends on the implementation of the dynamic class library you are using (as java.lang.Class).
Another detail is that not all smalltalk can bootstrap from sources (for example it is the same heap that we have used and edited in Pharo for the last 3 decades, the unique instance of True may even have been instantiated by Dan Ingalls in 1980 and we are still using it).
So basically it is either you have smalltalk running on the jvm wihtout the live smalltalk abilities, or you have a full smalltalk but it is slow.
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
This is somehow done in Smalltalk/X and in Visual Age. I think they both support the Java 1.5 byte code. Now this is a huge pain because you have to implement the java byte code verifier and all these boring stuff.
The OpenQuack image, a fork of squeak used by the company 3DICC, has a plugin to run python on the smalltalk VM.
Then it depends on your use cases, but usually people prefers to do bindings (like in Pharo you can bind C libraries, including the python/ruby interpreter) instead of adding a full backend for another language, because then you need to maintain the other language and we have very few people working on smalltalk VMs that can maintain that nowadays.
Where is that billionaire that would shower us with millions ???
Phil
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 05/14/2014 01:52 PM, Clément Bera wrote:
The OpenQuack image, a fork of squeak used by the company 3DICC, has a plugin to run python on the smalltalk VM.
Ehm, no... its a plugin that includes the CPython runtime. So it embeds Python. And then has lots of nice stuff to talk between. regards, Göran
Java/JVM doesn't have become: which is something that helps a lot in Smalltalk being Smalltalk. Object>>become: otherObject "Primitive. Swap the object pointers of the receiver and the argument. All variables in the entire system that used to point to the receiver now point to the argument, and vice-versa. Fails if either object is a SmallInteger" (Array with: self) elementsExchangeIdentityWith: (Array with: otherObject) You can't do that in Java/JVM it seems. That is also what is used (well, there is another primitive (72) when one changes all fo the code around in the Browser. Check SlotClassBuilder>>migrateClasses PharoClassInstaller>>migrateClasses:to:using: and Array>>elementsForwardIdentityTo: elementsForwardIdentityTo: otherArray "This primitive performs a bulk mutation, causing all pointers to the elements of this array to be replaced by pointers to the corresponding elements of otherArray. The identityHashes remain with the pointers rather than with the objects so that the objects in this array should still be properly indexed in any existing hashed structures after the mutation." <primitive: 72> self primitiveFailed As become: and elementsForwardIdentityTo: are doing all of this in the VM, which apparently the JVM doesn't do. That's why a Smalltalk on the JVM will not "really" be a Smalltalk if this characteristic isn't there. Yes, there will be bytecode, yes, there will be syntax. But there will be no magic. HTH Phil
How about running Java on the StVM so that Java can have the live environment and debugging capabilities like in full blown Smalltalk? How about doing the same for Python, Ruby, Lisp, ObjC, C#, etc?
Thanks in advanced for all you thoughts.
Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Virtual-Machine-StVM-tp4758961.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
askoh -
Clément Bera -
Göran Krampe -
kilon alios -
Pavel Krivanek -
phil＠highoctane.be