April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.4 with interpreted VM

by Esteban Lorenzano

5.7.4 for mac should be able to load a newer image. latest for linux should do it to I don't know about windows, but I think it should be capable too (anyway, to XO you need a linux vm) I don't know exactly which linux vm number is the indicated, but I'd try with latest for squeakvm.org best, Esteban On Apr 4, 2012, at 9:17 PM, StÃ©phane Ducasse wrote: > hilaire I checked and I downloaded the latest pharo and I could not open it with > a mac 4.2 old old vm but I could with 5.7 > > let me know if this helps. > > On Apr 4, 2012, at 8:22 PM, Hilaire Fernandes wrote: > >> Is there any way to get a 1.4 Pharo image saved with the interpreted VM >> binary format? I need that to produce a XO application, the stack VM is >> missing some part to work with Sugar launch system >> >> Hilaire >> >> >> -- >> Dr. Geo -- http://www.drgeo.eu >> >> > >

April 4, 2012

Re: [Pharo-project] Limit of the #become:

by Igor Stasenko

On 4 April 2012 23:25, <csrabak(a)bol.com.br> wrote: > Mariano, > > In fact, presently use of become is not considered good OOP so at first > my humble suggestion is you consider revising the whole architecture > in order to understand why you need such a thing and find a better > [design] pattern. > there is no other way to represent an object by proxy, which is not yet in memory, but loaded on demand. otherwise you will be forced to make an outer object (which refers to a proxy), to know it and replace a reference to it with another object. > HTH > > -- > Cesar Rabak > > > Em 04/04/2012 12:32, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > >> Hi guys. Â I noticed that there is Â a limit in the Â number of objects >> you can Â become. In Â my case, I Â am becoming 2312157 Â objects. So..I >> don't Â expect that Â the Â become works. Â I Â imagine that Â it was Â not >> designed for so many objects in mind ;) >> Â However, what I would really Â understand is where is the limitation >> Â and the Â reason. And of course, Â if someone already Â knows which is >> Â the real number limit. Otherwise, I will do a kind of binary search >> Â and discover it. >> Â If you want to reproduce it: >> | dict | >> dict := Dictionary new. >> 2312157 timesRepeat: [ dict at: Object new put: Object new ]. >> 3 timesRepeat: [Smalltalk garbageCollect]. >> dict keys elementsForwardIdentityTo: dict values. >> >> throws a #primitiveFailed. >> >> Thanks, > -- Best regards, Igor Stasenko.

April 4, 2012

Re: [Pharo-project] Limit of the #become:

by csrabak＠bol.com.br

Mariano, In fact, presently use of become is not considered good OOP so at first my humble suggestion is you consider revising the whole architecture in order to understand why you need such a thing and find a better [design] pattern. HTH -- Cesar Rabak Em 04/04/2012 12:32, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > Hi guys. I noticed that there is a limit in the number of objects > you can become. In my case, I am becoming 2312157 objects. So..I > don't expect that the become works. I imagine that it was not > designed for so many objects in mind ;) > However, what I would really understand is where is the limitation > and the reason. And of course, if someone already knows which is > the real number limit. Otherwise, I will do a kind of binary search > and discover it. > If you want to reproduce it: > | dict | > dict := Dictionary new. > 2312157 timesRepeat: [ dict at: Object new put: Object new ]. > 3 timesRepeat: [Smalltalk garbageCollect]. > dict keys elementsForwardIdentityTo: dict values. > > throws a #primitiveFailed.Â Â Â > > Thanks,

April 4, 2012

Re: [Pharo-project] Pharo 1.4 - browse slow??

by Schwab,Wilhelm K

I'm using Ubuntu Lucid, and the CogVM. I downloaded the most recent 1.4 and started looking at the new file list (interest in the grid), and ultimately MorphTreeMorph. It's not (reliably) reproducible, but something is causing delays in either asking for a new browser or (particularly) references to the currently selected class. The browser is the only one in the image, which is listed simply as Browser. Sorry I can't be more specific. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Bernardo Ezequiel Contreras [vonbecmann(a)gmail.com] Sent: Wednesday, April 04, 2012 1:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo 1.4 - browse slow?? which steps to reproduce? On Wed, Apr 4, 2012 at 1:43 PM, Camillo Bruni <camillobruni(a)gmail.com<mailto:camillobruni@gmail.com>> wrote: which vm? which browser? On 2012-04-04, at 18:32, Schwab,Wilhelm K wrote: > I'm seeing ~1-2 second delays on any attempt to browse a class. Anyone else?

April 4, 2012

Re: [Pharo-project] type-inference: it works!

by Francisco Garau

On 4 April 2012 13:29, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 4 April 2012 12:15, Francisco Garau <francisco.garau(a)gmail.com> wrote: > > Hi Frank - I'd appreciate if you can send me those mcz - I am trying to > > figure out how Monticello works and that would be helpful. > > Attached! fbs.1 is the result of my loading your two changesets into a > clean image and moving the -Support extensions to the *TypeInference > category. (So for example all the #mirrorIn: implementations were in > 'type inference' and are now in '*TypeInference' so that Monticello > can recognise they're in the TypeInference package.) > > I didn't keep all the method changes to Set: if Sets need their > behaviour adjusted, we should fix Set directly, rather than from this > package. > > fbs.2 just adds the change I described earlier: I replaced "key class > == Association" with "key isVariableBinding". > > One thing the package definitely needs is a large test suite :) That > would also let someone assess whether they've hit a known limitation > of the inference engine or a bug. For example, analysing 'n := 2. n > log' told me that "UndefinedObject would not understand #contextTag" > and I'm unsure why a MethodContext (the only implementor of > #contextTag) would be involved in calculating a log. I had a quick look at your example (2 log) and it seems that it seems a limitation to analise classVariableNames (Ln10 in this case). This can be seen in the "stack trace" left in the Transcript. (<SmallInteger> log in [Number | #log]) (<SmallInteger> asFloat in [SmallInteger | #asFloat]) (<Float> log in [Float | #log]) (<Float class ?> infinity in [Float class | #infinity]) (<DomainError class ?> signal: <ByteString> from: <SmallInteger> in [DomainError class | #signal:from:]) You might wonder why it starts analysing the #infinity method. By definition Concrete Type is the exact class of the object and the concrete type of each instance variable. This is a bit problematic when analysing class methods (as in this case). If I have to find the concrete type of each instance variable of a class, then would end up analysing the superclass, the method dictionaries and maybe the whole system... That's why you can the type <Float class ?>. The question mark means that I hold the reference to the class itself. But as Ln10 is referenced in the method #log, then the engine starts going through each class variable. That needs to be fixed/optimised somehow... Look a the class side method in TObject (from the TiTest changeset I've recently sent to you). There is a category called 'global variables' that shows some of the code is capable of analysing. No class variable names, unfortunately. - Francisco > > > As far as I remember one of the sources of imprecision in Squeak was the > > treatment of block variables or block arguments (can't remember exactly), > > which was in my to-do list that never got done. > > > > I know there has been work in the Compiler in Pharo and that block and > > Closures were a hot topic. Is that now fixed in Pharo? > > > > Sorry, if the above is a generic question. But I can't remember exactly > what > > was wrong with the blocks in Squeak. I did notice that the #isArg: method > > was removed in Pharo. > > > > Cheers, > > Francisco > > > > PS: I am thinking in giving the Type Inference project a name: Telar or > > Tilar. > > > > Telar means Loom in Spanish and it gives the idea of the interwoven data > and > > control flow of Smalltalk (or any other OO language). > > > > I also just learn that Loom in Arabic is pronounced Nul or ( Ø§ÙØµÙØ±Ø§) > > > > On 3 April 2012 21:56, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> > >> On 30 March 2012 22:19, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> > In case anyone's interested in the paper behind Francisco's work > >> > (thanks Francisco!), you can find "Concrete Type Inference: Delivering > >> > Object Oriented Applications" here: > >> > https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf > >> > > >> > Interestingly, typing 'Display boundBox' fails in Squeak trunk because > >> > "UndefinedObject won't understand #origin:corner:". Odd, since > >> > evaluating same will happily return a Rectangle. I'll look into it and > >> > see what I can find. > >> > >> It turns out that in Pharo we use Association and in Squeak we use > >> ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode > >> to > >> > >> isSharedVarNode > >> ^ self type = 4 and: [key isVariableBinding] > >> > >> TypeInference works in both! > >> > >> Now I have some mczs, but I don't have a place to publish them... > >> > >> frank > >> > >> > frank > >> > > >> > On 30 March 2012 14:33, Francisco Garau <francisco.garau(a)gmail.com> > >> > wrote: > >> >> No unit tests, sorry... > >> >> > >> >> Is not profiling, it's abstract intrepretation using types instead of > >> >> objects. > >> >> > >> >> - Francisco > >> >> > >> >> > >> >> On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel(a)me.com> > >> >> wrote: > >> >> > >> >> Hi Francisco, > >> >> > >> >> I've tried your implementation. It seems to work in Pharo 1.4. Do you > >> >> have > >> >> unit test somewhere? > >> >> How does your profiler work? From what you have said in your email, > it > >> >> seems > >> >> you are profiling the execution. Is that true? > >> >> > >> >> Cheers, > >> >> Alexandre > >> >> > >> >> > >> >> On 29 Mar 2012, at 18:47, Francisco Garau wrote: > >> >> > >> >> Load the attached ChangeSets: first Ti-Engine and then Ti-Support. > >> >> > >> >> You could then evaluate the below expressions -- watch the Transcript > >> >> to see > >> >> which methods are being analysed. > >> >> > >> >> TiSystem current reset. > >> >> string := '3 + 4'. > >> >> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: > >> >> [1]. > >> >> "=> return {<SmallInteger>} " > >> >> > >> >> TiSystem current reset. > >> >> string := 'Display boundingBox'. > >> >> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: > >> >> [1]. > >> >> "=> return {<Rectangle origin: <Point x: <SmallInteger> y: > >> >> <SmallInteger>> > >> >> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}" > >> >> > >> >> TiSystem current explore. > >> >> > >> >> > >> >> Analysing 'Display boundingBox' shows a couple of surprises: > >> >> > >> >> The code never goes through the #new method (it creates objects using > >> >> #basicNew and #@) > >> >> Object code goes through Object>>value but knowing that the > >> >> implementation > >> >> just answers self, it could be easily optimised. > >> >> > >> >> > >> >> I will try to package it more nicely under Monticello -- there are > >> >> still a > >> >> few rough edges that need to be polished before getting it to the > same > >> >> state > >> >> it was in 2001... > >> >> > >> >> Cheers, > >> >> Francisco > >> >> <Ti-Engine.2.cs><Ti-Support.2.cs> > >> >> > >> >> > >> >> -- > >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> >> Alexandre Bergel http://www.bergel.eu > >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> >> > >> >> > >> >> > >> >> > >> >> > >> > > >

April 4, 2012

Re: [Pharo-project] Pharo 1.4 with interpreted VM

by StÃ©phane Ducasse

hilaire I checked and I downloaded the latest pharo and I could not open it with a mac 4.2 old old vm but I could with 5.7 let me know if this helps. On Apr 4, 2012, at 8:22 PM, Hilaire Fernandes wrote: > Is there any way to get a 1.4 Pharo image saved with the interpreted VM > binary format? I need that to produce a XO application, the stack VM is > missing some part to work with Sugar launch system > > Hilaire > > > -- > Dr. Geo -- http://www.drgeo.eu > >

April 4, 2012

Re: [Pharo-project] Pharo 1.4 with interpreted VM

by Guillermo Polito

I was told not long ago that the latest interpreter vm from squeakvm.org is updated to work with latest image format. But haven't checked, sorry. Guille On Wed, Apr 4, 2012 at 8:22 PM, Hilaire Fernandes < hilaire.fernandes(a)edu.ge.ch> wrote: > Is there any way to get a 1.4 Pharo image saved with the interpreted VM > binary format? I need that to produce a XO application, the stack VM is > missing some part to work with Sugar launch system > > Hilaire > > > -- > Dr. Geo -- http://www.drgeo.eu > > >

April 4, 2012

Re: [Pharo-project] type-inference: it works!

by Francisco Garau

It'd be great if you can also push the attached ChangeSet. They are not SUnits but contain some simple expressions that I've used while developing. It might not be very difficult to extract some simple test cases from them. The Challenger is a simple application to teach kids the times tables. It simply ask a question (how much is 3 x 4) and gives you some positive or negative feedback. At the moment it doesn't work as it is using the old FillInTheBlankMorph. - Francisco On 4 April 2012 16:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 4 April 2012 15:27, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > wrote: > > aaaa, ok, you're right, there are extension methods that i forget. right? > > Ill upload to ss3 later. Thanks :D. > > :) Just waiting for ss3 to recompute its indices or whatever, but I've > pushed my two mczs up to the repository. > > frank > > > 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> Santiago, it looks like you don't have any of the Support stuff: there > >> are no extensions to the parse nodes, so you can't use this out of the > >> box as per Francisco's earlier examples: > >> > >> TiSystem current reset. > >> string := '3 + 4'. > >> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. > >> "=> return {<SmallInteger>} " > >> > >> (You can with mine, because I folded in both changesets.) > >> > >> frank > >> > >> On 4 April 2012 14:00, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> > >> wrote: > >> > I already upload it to ss3. > >> > http://ss3.gemstone.com/ss/ConcreteTypeInference > >> > > >> > > >> > > >> > 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> > >> >> > >> >> On 4 April 2012 12:15, Francisco Garau <francisco.garau(a)gmail.com> > >> >> wrote: > >> >> > Hi Frank - I'd appreciate if you can send me those mcz - I am > trying > >> >> > to > >> >> > figure out how Monticello works and that would be helpful. > >> >> > >> >> Attached! fbs.1 is the result of my loading your two changesets into > a > >> >> clean image and moving the -Support extensions to the *TypeInference > >> >> category. (So for example all the #mirrorIn: implementations were in > >> >> 'type inference' and are now in '*TypeInference' so that Monticello > >> >> can recognise they're in the TypeInference package.) > >> >> > >> >> I didn't keep all the method changes to Set: if Sets need their > >> >> behaviour adjusted, we should fix Set directly, rather than from this > >> >> package. > >> >> > >> >> fbs.2 just adds the change I described earlier: I replaced "key class > >> >> == Association" with "key isVariableBinding". > >> >> > >> >> One thing the package definitely needs is a large test suite :) That > >> >> would also let someone assess whether they've hit a known limitation > >> >> of the inference engine or a bug. For example, analysing 'n := 2. n > >> >> log' told me that "UndefinedObject would not understand #contextTag" > >> >> and I'm unsure why a MethodContext (the only implementor of > >> >> #contextTag) would be involved in calculating a log. > >> >> > >> >> frank > >> >> > >> >> > As far as I remember one of the sources of imprecision in Squeak > was > >> >> > the > >> >> > treatment of block variables or block arguments (can't remember > >> >> > exactly), > >> >> > which was in my to-do list that never got done. > >> >> > > >> >> > I know there has been work in the Compiler in Pharo and that block > >> >> > and > >> >> > Closures were a hot topic. Is that now fixed in Pharo? > >> >> > > >> >> > Sorry, if the above is a generic question. But I can't remember > >> >> > exactly > >> >> > what > >> >> > was wrong with the blocks in Squeak. I did notice that the #isArg: > >> >> > method > >> >> > was removed in Pharo. > >> >> > > >> >> > Cheers, > >> >> > Francisco > >> >> > > >> >> > PS: I am thinking in giving the Type Inference project a name: > Telar > >> >> > or > >> >> > Tilar. > >> >> > > >> >> > Telar means Loom in Spanish and it gives the idea of the interwoven > >> >> > data > >> >> > and > >> >> > control flow of Smalltalk (or any other OO language). > >> >> > > >> >> > I also just learn that Loom in Arabic is pronounced Nul or > ( Ø§ÙØµÙØ±Ø§) > >> >> > > >> >> > On 3 April 2012 21:56, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >> >> >> > >> >> >> On 30 March 2012 22:19, Frank Shearar <frank.shearar(a)gmail.com> > >> >> >> wrote: > >> >> >> > In case anyone's interested in the paper behind Francisco's work > >> >> >> > (thanks Francisco!), you can find "Concrete Type Inference: > >> >> >> > Delivering > >> >> >> > Object Oriented Applications" here: > >> >> >> > > https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf > >> >> >> > > >> >> >> > Interestingly, typing 'Display boundBox' fails in Squeak trunk > >> >> >> > because > >> >> >> > "UndefinedObject won't understand #origin:corner:". Odd, since > >> >> >> > evaluating same will happily return a Rectangle. I'll look into > it > >> >> >> > and > >> >> >> > see what I can find. > >> >> >> > >> >> >> It turns out that in Pharo we use Association and in Squeak we use > >> >> >> ReadOnlyVariableBinding; by changing VariableNode >> > >> >> >> #isSharedVarNode > >> >> >> to > >> >> >> > >> >> >> isSharedVarNode > >> >> >> ^ self type = 4 and: [key isVariableBinding] > >> >> >> > >> >> >> TypeInference works in both! > >> >> >> > >> >> >> Now I have some mczs, but I don't have a place to publish them... > >> >> >> > >> >> >> frank > >> >> >> > >> >> >> > frank > >> >> >> > > >> >> >> > On 30 March 2012 14:33, Francisco Garau > >> >> >> > <francisco.garau(a)gmail.com> > >> >> >> > wrote: > >> >> >> >> No unit tests, sorry... > >> >> >> >> > >> >> >> >> Is not profiling, it's abstract intrepretation using types > >> >> >> >> instead > >> >> >> >> of > >> >> >> >> objects. > >> >> >> >> > >> >> >> >> - Francisco > >> >> >> >> > >> >> >> >> > >> >> >> >> On 30 Mar 2012, at 15:15, Alexandre Bergel > >> >> >> >> <alexandre.bergel(a)me.com> > >> >> >> >> wrote: > >> >> >> >> > >> >> >> >> Hi Francisco, > >> >> >> >> > >> >> >> >> I've tried your implementation. It seems to work in Pharo 1.4. > Do > >> >> >> >> you > >> >> >> >> have > >> >> >> >> unit test somewhere? > >> >> >> >> How does your profiler work? From what you have said in your > >> >> >> >> email, > >> >> >> >> it > >> >> >> >> seems > >> >> >> >> you are profiling the execution. Is that true? > >> >> >> >> > >> >> >> >> Cheers, > >> >> >> >> Alexandre > >> >> >> >> > >> >> >> >> > >> >> >> >> On 29 Mar 2012, at 18:47, Francisco Garau wrote: > >> >> >> >> > >> >> >> >> Load the attached ChangeSets: first Ti-Engine and then > >> >> >> >> Ti-Support. > >> >> >> >> > >> >> >> >> You could then evaluate the below expressions -- watch the > >> >> >> >> Transcript > >> >> >> >> to see > >> >> >> >> which methods are being analysed. > >> >> >> >> > >> >> >> >> TiSystem current reset. > >> >> >> >> string := '3 + 4'. > >> >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil > >> >> >> >> ifFail: > >> >> >> >> [1]. > >> >> >> >> "=> return {<SmallInteger>} " > >> >> >> >> > >> >> >> >> TiSystem current reset. > >> >> >> >> string := 'Display boundingBox'. > >> >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil > >> >> >> >> ifFail: > >> >> >> >> [1]. > >> >> >> >> "=> return {<Rectangle origin: <Point x: <SmallInteger> y: > >> >> >> >> <SmallInteger>> > >> >> >> >> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}" > >> >> >> >> > >> >> >> >> TiSystem current explore. > >> >> >> >> > >> >> >> >> > >> >> >> >> Analysing 'Display boundingBox' shows a couple of surprises: > >> >> >> >> > >> >> >> >> The code never goes through the #new method (it creates objects > >> >> >> >> using > >> >> >> >> #basicNew and #@) > >> >> >> >> Object code goes through Object>>value but knowing that the > >> >> >> >> implementation > >> >> >> >> just answers self, it could be easily optimised. > >> >> >> >> > >> >> >> >> > >> >> >> >> I will try to package it more nicely under Monticello -- there > >> >> >> >> are > >> >> >> >> still a > >> >> >> >> few rough edges that need to be polished before getting it to > the > >> >> >> >> same > >> >> >> >> state > >> >> >> >> it was in 2001... > >> >> >> >> > >> >> >> >> Cheers, > >> >> >> >> Francisco > >> >> >> >> <Ti-Engine.2.cs><Ti-Support.2.cs> > >> >> >> >> > >> >> >> >> > >> >> >> >> -- > >> >> >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> >> >> >> Alexandre Bergel http://www.bergel.eu > >> >> >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > > >> > > >> > > >> > > > >

April 4, 2012

[Pharo-project] Pharo 1.4 with interpreted VM

by Hilaire Fernandes

Is there any way to get a 1.4 Pharo image saved with the interpreted VM binary format? I need that to produce a XO application, the stack VM is missing some part to work with Sugar launch system Hilaire -- Dr. Geo -- http://www.drgeo.eu

April 4, 2012

Re: [Pharo-project] Pharo 1.4 - browse slow??

by Bernardo Ezequiel Contreras

which steps to reproduce? On Wed, Apr 4, 2012 at 1:43 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > which vm? which browser? > > > > On 2012-04-04, at 18:32, Schwab,Wilhelm K wrote: > > > I'm seeing ~1-2 second delays on any attempt to browse a class. Anyone > else? > >

April 4, 2012