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

Re: [Pharo-project] Are Objects really hard?

by Nick Ager

Hi Michael, pah. 1 MB. Sheer luxury. 64 kB RAM, 256 kB Flash: Smalltalk running on > Lego Mindstorms NXT. Questions? Is this still being developed? Is the code available? Nick

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Sven Van Caekenberghe

On 13 Feb 2012, at 16:32, Guido Stepken wrote: > Its quite difficult not to say *impossible* to run Pharo even for simple tasks within a small vserver account with 256 or 512 MB reserved or dynamically assigned memory space. This is ridiculous: a current stock Pharo server image (i.e. non-stripped) compares favorably with any other dynamic language. http://zn.stfx.eu/zn/index.html#livedemo I am currently running 5 VM's on an AWS EC2 micro instance (613MB RAM, up to 2 ECU (1 ECU = the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor)). Setup can also be quite simple: http://forum.world.st/Pharo-Core-HTTP-Server-OneCommandLine-Demo-td3702218.… Sven

Feb. 13, 2012

Re: [Pharo-project] bug? Lazy Class creation via method saving not stored in recent changes log

by StÃ©phane Ducasse

thanks Max Yes this is probably a problem with the notification of class definition. Do you have a step by step reproduce able case for 1.4. Stef On Feb 13, 2012, at 4:34 PM, Max Bareis wrote: > Hi, > > I have encountered the issue, that the class creation is not stored in recent changes log when I process the following steps (ClassB does not exist): > > > ClassA>>methodA > > ClassB methodB. > > save. > > Now a popup appears and offers the creation of the ClassB. After accepting the class is created and visible in the System Browser, but there is no trace of the class creation in recent changes log. The method change is stored in the log. This affects Pharo 1.3 13315 OneClick > > Regards > > Max >

Feb. 13, 2012

Re: [Pharo-project] bug? #setPageSize: called in MorphThreeMorph but not defined

by StÃ©phane Ducasse

On Feb 13, 2012, at 4:08 PM, Esteban Lorenzano wrote: > Hi, > > MorphThreeModel>>#pageSize: and MorphThreeModel>>#chunkSize: both sends #setPageSize:, but that message is not defined there or in parents. Unique definition is on PaginatedMorphThreeModel. > > is that a bug? probably > > best, > Esteban

Feb. 13, 2012

Re: [Pharo-project] Debugging with Toggle breakpoint

by StÃ©phane Ducasse

On Feb 13, 2012, at 3:49 AM, S Krish wrote: > Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly.. > > I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo. I never use such functionality so I cannot comment. > > I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation: > > ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!) > > On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest : > > * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window . > * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully.. > * Mouse inputs become sluggish... > * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window > > * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code.. > > Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also.. > > Will dig in deeper and come back. >

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Michael Haupt

Hi, On 13 February 2012 16:32, Guido Stepken <gstepken(a)googlemail.com> wrote: > Ok. Then it must have been the ghost, that causes heavy "memory pumping", even under zero load, see CPU monitor. ... so far for the "analysis". :-) > But i agree, that Smalltalk *can* be designed to run well within 1MB of RAM pah. 1 MB. Sheer luxury. 64 kB RAM, 256 kB Flash: Smalltalk running on Lego Mindstorms NXT. Questions? Michael ;-)

Feb. 13, 2012

[Pharo-project] bug? Lazy Class creation via method saving not stored in recent changes log

by Max Bareis

Hi, I have encountered the issue, that the class creation is not stored in recent changes log when I process the following steps (ClassB does not exist): ClassA>>methodA ClassB methodB. save. Now a popup appears and offers the creation of the ClassB. After accepting the class is created and visible in the System Browser, but there is no trace of the class creation in recent changes log. The method change is stored in the log. This affects Pharo 1.3 13315 OneClick Regards Max

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Guido Stepken

Ok. Then it must have been the ghost, that causes heavy "memory pumping", even under zero load, see CPU monitor. Its quite difficult not to say *impossible* to run Pharo even for simple tasks within a small vserver account with 256 or 512 MB reserved or dynamically assigned memory space. But i agree, that Smalltalk *can* be designed to run well within 1MB of RAM :-) have fun, Guido Stepken Am 13.02.2012 15:04 schrieb "Marcus Denker" <marcus.denker(a)inria.fr>: > > On Feb 13, 2012, at 2:47 PM, Guido Stepken wrote: > > > I did analyse some of these "memory pumping effects" in Pharo. Come from > overuse of "inheritance", that causes big objects with hundreds of methods > to be created and garbaged, just for short tasks. > > > > The number of methods do not influence *at all* the size on an object. > Methods are on the class, the object point to its class, no need to > allocate *any* > memory. The only thing that costs memory is *state*. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > >

Feb. 13, 2012

[Pharo-project] bug? #setPageSize: called in MorphThreeMorph but not defined

by Esteban Lorenzano

Hi, MorphThreeModel>>#pageSize: and MorphThreeModel>>#chunkSize: both sends #setPageSize:, but that message is not defined there or in parents. Unique definition is on PaginatedMorphThreeModel. is that a bug? best, Esteban

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Marcus Denker

On Feb 13, 2012, at 2:47 PM, Guido Stepken wrote: > I did analyse some of these "memory pumping effects" in Pharo. Come from overuse of "inheritance", that causes big objects with hundreds of methods to be created and garbaged, just for short tasks. > The number of methods do not influence *at all* the size on an object. Methods are on the class, the object point to its class, no need to allocate *any* memory. The only thing that costs memory is *state*. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 13, 2012