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 [email protected] <[email protected]>: > On Wed, May 14, 2014 at 1:52 PM, Clément Bera <[email protected]>wrote: > >> >> 2014-05-14 12:27 GMT+02:00 askoh <[email protected]>: >> >>> 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. >>> >>> >> >
