January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Question on recursive structures

by StÃ©phane Ducasse

Thanks viktor we will fix that. There was a dicussion on removing deepCopy and cleaning the copy mess :) Stef On Jan 20, 2010, at 1:44 AM, Viktor Kerkez wrote: > Hi, > > Since this is my first post on the list, first I want to thank you all for the great job you're doing on Pharo :) It was a real revelation when I discovered it :) > > Now to the question: > > I'm reading the Pharo by Example, and came to this part: > > The problem with deepCopy is that it will not terminate when applied to a mutually recursive structure: > a1 := { 'harry' }. > a2 := { a1 }. > a1 at: 1 put: a2. > a1 deepCopy â! ... does not terminate! > > (Pharo actually get stuck at the step: a1 at: 1 put: a2. but that's not the question :) ) > > 1. Isn't this behaviour (the complete environment get stuck and there is no way to unfreeze it) considered a bug? I mean the environment shouldn't let you shoot yourself in the foot (at least not so easily). Actually the same behaviour can be created just doing: [true] whileTrue: []... > > 2. Shouldn't Pharo recognize recursive structures in some way? > > > I'm asking because I'm coming from a Python world, which is very similar to smalltalk in some manners and I'm trying to make a big picture comparison in my head. > > 1. I know that this doesn't really compares to Pharo which is a graphical environment, but in python you can always hit Ctrl-C and break the statements that block... > > >>> while True: > ... pass > ... > ^CTraceback (most recent call last): > File "<stdin>", line 1, in <module> > KeyboardInterrupt > >>> > > Shouldn't the UI thread always be responsive? > > 2. And Python recognizes recursive structures: > > >>> a = [] > >>> a > [] > >>> a.append(5 > ... > KeyboardInterrupt > >>> a = [] > >>> a > [] > >>> a.append(5) > >>> a > [5] > >>> a.append(a) > >>> a > [5, [...]] > >>> a[0] > 5 > >>> a[1] > [5, [...]] > >>> a[1][1][1][1][0] > 5 > >>> > > > Don't get me wrong, I'm not trying to start a language war :) I wouldn't got to page 171 if I'm not really interested in Smalltalk :-D I'm just trying to get a clearer vision if these are some things that are there for some reason (design decision), or they are just not yet implemented, or they cannot be implemented for some other reasons? > > Thank you in advance for your time :), > Viktor > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Beta Testing

by StÃ©phane Ducasse

Yes thanks! This is really important. Stef On Jan 20, 2010, at 2:38 AM, Michael Litchard wrote: > Hi, I'm running NetBSD-current on AMD 64 bit. If that's useful to you > I'd like to be a beta tester. > > > > > Michael Litchard > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Denis Kudriashov

In parrot site languages section there is "chitchat<https://trac.parrot.org/languages/browser/chitchat/trunk>â An implementation of Smalltalk" <http://en.wikipedia.org/wiki/Smalltalk> Anybody know what is it?

Jan. 20, 2010

Re: [Pharo-project] testing the linux vm of pharo-project

by John McIntosh

So what do you mean by better? On 1/19/10, Sean Allen <sean(a)monkeysnatchbanana.com> wrote: > We are using the exupery exclusively and find that it works for out > needs better than the squeak. > > On Tue, Jan 19, 2010 at 12:46 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I would not put the stexupery as first vm because the squeak one should be >> more tested. >> >> Stef >> >> On Jan 19, 2010, at 2:40 PM, Mariano Martinez Peck wrote: >> >>> Ok...so: pharo exupery vm as FTPlugin compiled and 3.11. doesn't. And >>> both are closure-enable. >>> >>> Does someone have a compiled squeak-unix-vm Â with FTPlugin ? because >>> otherwise, I think I would rather to put again Exupery as the default >>> one. >>> >>> Opinions? >>> >>> 2010/1/19 George Herolyants <george.herolyants(a)gmail.com> >>> So, here are the results (see attachments). On the background of each >>> pharo screenshot you can see the version number of the vm, and command >>> line I used to run pharo image with this vm. >>> As you can see results are far better for the pharo-exupery-linux-vm >>> (which means 0.15.2f), because it has FTPlugin compiled, and >>> squeak-unix-vm (which means 3.11.3-2135) hasn't. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Eliot Miranda

2010/1/19 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > Parrot has just been released: > http://www.parrot.org/news/2010/Parrot-2.0.0 > > I would like to know, from the VM experts from the community, if this VM > can be used to run Smalltalk. > The site says that > > "Parrot is a virtual machine aimed at running all dynamic languages.". > > but I don't know anything about VM so this sounds to me a bit like black > magic. > > Is there something in the squeak vm that is specific to the way > smalltalk works or a generic virtual machine (maybe with a upper layer > understanding Smalltalk specifics) can be used. > The four things that most distinguish Smalltalk VMs from most others are the bytecode and primitives set, contexts, immediate objects and the class hierarchy with each class having a method dictionary. The method lookup mechanism that searches the class hierarchy has traditionally been part of the VM but in a well-modularised VM one could imagine adding it on as an extra (*1). Immediate objects are of course SmallInteger (a.k.a. fixnums) and in some implementations Character and SmallDouble. They're the implementation encoding value objects within a pointer so that these values can be synthesized without object allocation. To be a Smalltalk these must be objects to whose classes you can add methods, and pragmatically they need to be space and time efficient. You can implement them as boxed objects but performance will be poor. You can't implement them as e.g. Java integers without a lot of difficulty; they need to be objects. A well-factored VM may well allow one to implement some immediate types; I would be surprised if Parrot didn't have support for fixnums. Contexts are the most distinctive features of Smalltalk implementations. Few languages have a reification of method/function activation. I doubt very much that Parrot supports anything like contexts. One can attempt to do without them, but then lots of the exception system is in the VM and there are major restrictions (Seaside's continuations must be implemented differently, the debugger needs to be reimplemented, persisting processes is difficult, etc, etc). All this is possible (VisualAge doesn't have contexts) but for Squeak and VisualWorks eliminating contexts is a lot of work. Finally the bytecode and primitive set, encapsulated in methods, are pretty distinctive. These are the target of the compiler and known to the image indirectly by the debugger, by the browsing functions (senders scans methods bytecode, inst var refs scans bytecode, etc), and so on. So if a VM specifies the bytecode set, rather than allows one to specify one's own there is a lot of work involved in targeting that VM. In practice none of these four features is fixed. One wants to be able to evolve the implementation. My closures implementation adds a few bytecodes, a few primitives and changes how MethodContext works (to support block activations; BlockContext is history). But these are small changes from Squeak and, clearly, support existing Squeak semantics with relatively little work. Targetting Parrot is likely to require much more effort. primitives are a can of worms. For example, does the VM allow one to enumerate all instances of a class? This is great for doing instance mutation when a class definition changes, but many VMs will disallow this kind of thing on security grounds. You can always try and do without but at what stage does it no longer remain Smalltalk? Smalltalk is more than syntax. And of course a different VM may be perfectly acceptable for certain kinds of deployed applications. One may live with the restrictions involved in compiling Smalltalk to JavaScript in return for browser ubiquity. So you've asked an interesting question that overs a large space of implementation approaches and levels of effort. In my experience you never know how hard or easy something really is until you try doing it. *1 and some VMs such as the Mushroom Smalltalk VM and Ian's Cola have virtualized method lookup, so it doesn't have to be part of the core and so is the least distinctive of the three features. > Thanks for the answers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by merlyn＠stonehenge.com

>>>>> "Randal" == Randal L Schwartz <merlyn(a)stonehenge.com> writes: Randal> Parrot's GC suffers from having many different kinds of mixed objects. Randal> http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html And worse, having untyped data blobs on a stack... that's probably the worst thing there. If you can't tell what live pointers you have for sure, you can't GC, and if you can't GC reliably, you lose. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Jan. 20, 2010

Re: [Pharo-project] testing the linux vm of pharo-project

by Sean Allen

We are using the exupery exclusively and find that it works for out needs better than the squeak. On Tue, Jan 19, 2010 at 12:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would not put the stexupery as first vm because the squeak one should be more tested. > > Stef > > On Jan 19, 2010, at 2:40 PM, Mariano Martinez Peck wrote: > >> Ok...so: pharo exupery vm as FTPlugin compiled and 3.11. doesn't. And both are closure-enable. >> >> Does someone have a compiled squeak-unix-vm Â with FTPlugin ? because otherwise, I think I would rather to put again Exupery as the default one. >> >> Opinions? >> >> 2010/1/19 George Herolyants <george.herolyants(a)gmail.com> >> So, here are the results (see attachments). On the background of each >> pharo screenshot you can see the version number of the vm, and command >> line I used to run pharo image with this vm. >> As you can see results are far better for the pharo-exupery-linux-vm >> (which means 0.15.2f), because it has FTPlugin compiled, and >> squeak-unix-vm (which means 3.11.3-2135) hasn't. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Martin McClure

Stephen Taylor wrote: > Randal L. Schwartz wrote: > >> Parrot's GC suffers from having many different kinds of mixed objects. > > Could you explain (or give a pointer) to what you mean by "mixed objects"? Basically, an object with both pointer and non-pointer contents. -Martin

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Stephen Taylor

Randal L. Schwartz wrote: > Parrot's GC suffers from having many different kinds of mixed objects. Could you explain (or give a pointer) to what you mean by "mixed objects"? Steve

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by merlyn＠stonehenge.com

>>>>> "Miguel" == Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> writes: Miguel> "Parrot is a virtual machine aimed at running all dynamic languages.". Parrot's GC suffers from having many different kinds of mixed objects. http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html They apparently didn't learn from the mistake of ST80 having a mixed object for CompiledMethod. They made more of them. It's more likely that Perl6 can target Squeak's VM in the long run, except that Perl6 wants a VM with prototype inheritance, not class inheritance. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Jan. 20, 2010