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

Re: [Pharo-project] [ANN] new stable version of omnibrowser

by Fabrizio Perin

Hi Stef, I briefly tried nautilus sometime ago. I also sent a short feedback email with some first impressions. I should try to use it for some days and than I'll let you know. Cheers, Fabrizio 2012/4/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > fabrizio did you try nautilus ? > > Stef > > On Apr 4, 2012, at 2:24 PM, Fabrizio Perin wrote: > > > Thanks really a lot for this, > > I was trying to find sometime to do it myself. I'm finishing to setup a > local Jenkins build to load Moose together with OB. Manually it work. I > will report any unusual behaviour. > > > > Cheers, > > Fabrizio > > > > 2012/4/2 Guillermo Polito <guillermopolito(a)gmail.com> > > I fixed some usages of deprecated code, and now it loads and works at > first in the latest -hopefully and almost released- Pharo 1.4 > > > > Gofer it > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfOmniBrowser'; > > load. > > > > (ConfigurationOfOmniBrowser > > project version: #stable) load: #( 'Dev' 'Dev Tests'). > > > > This scripts installs OmniBrowser + OCompletion + Refactoring Browser > > > > Please test :) > > > > Guille > > > > >

April 5, 2012

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

by Mariano Martinez Peck

On Wed, Apr 4, 2012 at 11:51 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 4 April 2012 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > > 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. > > And this seems like precisely one of those times you really do want to > reach into the magic toolbox for #become:. Sometimes you really do > need it. > Thanks Carlos for the advice. Since Igor knows what I am doing, he answered for me ;) So yes....I am swappout graphs between primary and secondary memory and there are objects that I need to become to proxies and vice-versa. This is not an app what I am doing, but a kind of hacky stuff implemented at the object side. Cheers > > frank > > >> 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. > > > > -- Mariano http://marianopeck.wordpress.com

April 5, 2012

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

by Camillo Bruni

On 2012-04-05, at 01:16, Sean P. DeNigris wrote: > > Schwab,Wilhelm K wrote >> >> 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 > > Maybe related to > http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-td4173491.html ? > I was on Mac OS X (probably Lion at the time...) with the Cog VM (probably > carbon)... > > Sean that bug report is in vapor-mode as well... if you find the time tryout a nautilus image: https://ci.lille.inria.fr/pharo/job/Nautilus-Release/lastSuccessfulBuild/ar… cami

April 5, 2012

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

by StÃ©phane Ducasse

+ 1 >>> >>> 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. > > And this seems like precisely one of those times you really do want to > reach into the magic toolbox for #become:. Sometimes you really do > need it.

April 5, 2012

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

by Hilaire Fernandes

Thanks. it makes it. Hilaire Le 05/04/2012 04:19, David T. Lewis a Ã©crit : > All that you need to do is open the image with an interpreter VM and > save it. It will be saved in the format that can be used by an older > VM (i.e. format 6504) and can of course still be opened with Cog. > > If you are building image with Jenkins, just add a post-processing > step to re-save the final image using an interpreter VM. > -- Dr. Geo -- http://www.drgeo.eu

April 5, 2012

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

by David T. Lewis

On Wed, Apr 04, 2012 at 11:41:52PM +0200, Igor Stasenko wrote: > On 4 April 2012 21:17, St??phane Ducasse <stephane.ducasse(a)inria.fr> 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. > > > > it won't because Hilaire want to save an image of new format (used by > Cog VMs) to older pre-cog format. > What i can say: SystemTracer is your friend! :) > it probably doable , (not without some hassle) to trace current 1.4 > image using system tracer and save it in old image format. > All that you need to do is open the image with an interpreter VM and save it. It will be saved in the format that can be used by an older VM (i.e. format 6504) and can of course still be opened with Cog. If you are building image with Jenkins, just add a post-processing step to re-save the final image using an interpreter VM. Dave

April 5, 2012

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

by Sean P. DeNigris

Schwab,Wilhelm K wrote > > 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 Maybe related to http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-td4173491.html ? I was on Mac OS X (probably Lion at the time...) with the Cog VM (probably carbon)... Sean -- View this message in context: http://forum.world.st/Pharo-1-4-browse-slow-tp4532473p4533467.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 4, 2012

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

by Camillo Bruni

that is rather strange :/ we had some issues with the new Nautilus browser some time ago when opening certain classes (Object, Morph...) but otherwise I cannot remember that this happened to me :). On 2012-04-04, at 22:09, Schwab,Wilhelm K wrote: > 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> 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] Limit of the #become:

by Frank Shearar

On 4 April 2012 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. And this seems like precisely one of those times you really do want to reach into the magic toolbox for #become:. Sometimes you really do need it. frank >> 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] Pharo 1.4 with interpreted VM

by Igor Stasenko

On 4 April 2012 21:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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. > it won't because Hilaire want to save an image of new format (used by Cog VMs) to older pre-cog format. What i can say: SystemTracer is your friend! :) it probably doable , (not without some hassle) to trace current 1.4 image using system tracer and save it in old image format. > 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 >> >> > > -- Best regards, Igor Stasenko.

April 4, 2012