May 2014 - Pharo-dev - lists.pharo.org

geometric framework

by Natalia Tymchuk

Hello. I want to do visualization on Roassal and I need the geometric shapes and their properties, for example: build circle on 3 points; find mid perpendicular. Can you tell me does some framework exist or no? Thank you. Best regards, Natalia.

May 14, 2014

Re: [Pharo-dev] Smalltalk Virtual Machine, StVM

by phil＠highoctane.be

On Wed, May 14, 2014 at 1:52 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > > > > 2014-05-14 12:27 GMT+02:00 askoh <askoh(a)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. >> >> >

May 14, 2014

Re: [Pharo-dev] Smalltalk Virtual Machine, StVM

by phil＠highoctane.be

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. > >

May 14, 2014

Re: [Pharo-dev] Smalltalk Virtual Machine, StVM

by ClÃ©ment Bera

2014-05-14 12:27 GMT+02:00 askoh <askoh(a)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. > >

May 14, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Marcus Denker

On 14 May 2014, at 13:27, Carlo <snoobabk(a)gmail.com> wrote: > Hi > > Obviously this all depends on context and what is trying to be achieved ;) > In certain cases all we want to do is ensure the container is not modifiable but donât mind access to the held objects within. if the internal data is immutable (e.g. a representation of an error) then we donât care if they have access to this data but we may care that they modify the collection that holds these objects. You then need to weigh in with a pro/con of using unmodifiable collections versus a copy; most of the time a copy is all you need as the collections will be small. > > If the context requires for some (odd) reason complete immutability and youâre happy to pay the price in terms of space/time or additional complexity then there are other solutions from deepCopy, to something like Worlds (http://www.vpri.org/pdf/tr2011001_final_worlds.pdf , http://www.vpri.org/pdf/m2013002_experiments.pdf ) or maybe some weird use of software transactional memory. > We did an experiment with read-only references some time ago: http://rmod.inria.fr/web/publications/bib?query=Arna10a&display=abstract The idea is that we hacked the VM to have references-as-objects that can override behaviour transparently. Marcus

May 14, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Carlo

Hi Obviously this all depends on context and what is trying to be achieved ;) In certain cases all we want to do is ensure the container is not modifiable but donât mind access to the held objects within. if the internal data is immutable (e.g. a representation of an error) then we donât care if they have access to this data but we may care that they modify the collection that holds these objects. You then need to weigh in with a pro/con of using unmodifiable collections versus a copy; most of the time a copy is all you need as the collections will be small. If the context requires for some (odd) reason complete immutability and youâre happy to pay the price in terms of space/time or additional complexity then there are other solutions from deepCopy, to something like Worlds (http://www.vpri.org/pdf/tr2011001_final_worlds.pdf , http://www.vpri.org/pdf/m2013002_experiments.pdf ) or maybe some weird use of software transactional memory. The point is though that there are valid cases where an immutable container is all you want; Java provides this as a library out of the box, if developers mis-use it then itâs not an issue with the language but rather an OO design flaw by the programmer as was previously mentioned. By the same token if Smalltalk developers only use #copy to achieve similar semantics then the Java solution is more elegant in terms of performance but potentially confusing with regards to the change in behaviour of the returned collection (canât mutate the collection now which could break contract of collection). Cheers Carlo On 14 May 2014, at 1:02 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: 2014-05-14 12:50 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: But how well "unmodifiable" collection is? Should it protect also from modifying the items themselves? Or any object(s) accessible through items? Or any objects accessible through all objects accessible through items? Because without propagating immutability how you cannot prove that you actually made things "safe"? There was a work by Jean-Baptiste exploring that direction, by introducing special kind of references (immutable references).. which is a special view on object that does not allows its modification and also has an option to propagate same kind of property on all references it may give away. This is done at VM level, sure thing.. and sure thing there is a performance cost.. but again, if you so desperately need "safety", just making immutable collections is not a solution. It is much more involved :) +1 Even a veryDeepCopy (sic...) would not be enough for safety. We are dynamic and the behavior can change at any moment. So you'd need to also duplicate the whole class hierarchy of each and every object in the graph. Or lock if you prefer lock to copy, but problem remains the same... -- Best regards, Igor Stasenko.

May 14, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Nicolas Cellier

2014-05-14 12:50 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > But how well "unmodifiable" collection is? > Should it protect also from modifying the items themselves? Or any > object(s) accessible through items? Or any objects accessible through all > objects accessible through items? > Because without propagating immutability how you cannot prove that you > actually made things "safe"? > There was a work by Jean-Baptiste exploring that direction, by introducing > special kind of references (immutable references).. which is a special view > on object that does not allows its modification and also has an option to > propagate same kind of property on all references it may give away. > This is done at VM level, sure thing.. and sure thing there is a > performance cost.. > but again, if you so desperately need "safety", just making immutable > collections is not a solution. It is much more involved :) > > > > +1 Even a veryDeepCopy (sic...) would not be enough for safety. We are dynamic and the behavior can change at any moment. So you'd need to also duplicate the whole class hierarchy of each and every object in the graph. Or lock if you prefer lock to copy, but problem remains the same... > -- > Best regards, > Igor Stasenko. >

May 14, 2014

Re: [Pharo-dev] Smalltalk Virtual Machine, StVM

by Pavel Krivanek

Jan did it: https://swing.fit.cvut.cz/projects/stx-libjava -- Pavel 2014-05-14 12:27 GMT+02:00 askoh <askoh(a)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. > >

May 14, 2014

Re: [Pharo-dev] Smalltalk Virtual Machine, StVM

by kilon alios

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(a)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. > >

May 14, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Igor Stasenko

But how well "unmodifiable" collection is? Should it protect also from modifying the items themselves? Or any object(s) accessible through items? Or any objects accessible through all objects accessible through items? Because without propagating immutability how you cannot prove that you actually made things "safe"? There was a work by Jean-Baptiste exploring that direction, by introducing special kind of references (immutable references).. which is a special view on object that does not allows its modification and also has an option to propagate same kind of property on all references it may give away. This is done at VM level, sure thing.. and sure thing there is a performance cost.. but again, if you so desperately need "safety", just making immutable collections is not a solution. It is much more involved :) -- Best regards, Igor Stasenko.

May 14, 2014