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

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

by Sven Van Caekenberghe

On 13 Feb 2012, at 18:09, Guido Stepken wrote: > Yes! http://httpd.apache.org/docs/1.3/mod/mod_proxy.html > > Even dynamically growing cache memory. No! This page http://zn.stfx.eu/zn/index.html#livedemo clearly refers/links to http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html which refers/links to http://httpd.apache.org/docs/current/mod/mod_proxy.html Where it is clearly stated that mod_cache is needed to add caching functionality (Apache 1.3 is different, old). > Tnx 4 your comments. When you put *real* and *direct* load on Pharo (no tricks, no apache, no nginx in front), and you can see, what i mean: Memory pumping, eating up vasts mounts of memory at even low load (use ab -n 10000 -c 1000) â¦ I would be very surprised to learn that you have written and/or operated a dynamic website that was hit like that ! > Ok, facts are unwanted here. Away again! :-) Bye.

Feb. 13, 2012

[Pharo-project] New implementation of MultiColumnList

by Benjamin

Hi, I have done a new version of this morph. Since the basic list morph can now render all kind morphs, I wanted to try with a new approach consisting of wrap each element with a designated morph. For the default behavior, speed is a bit better MessageTally spyOn: [ SystemNavigation default browseAllCallsOn: #+] old version: - 3829 tallies, 3843 msec. new version: - 2824 tallies, 2824 msec. I use the same approach for a new sender implementation using spec and since I already know the column widths, the speed is really better - 835 tallies, 840 msec. (and it does a hierarchy sort) I am currently working on this aspect (if the model specify the widths, is it really faster ?) Code is available here: Gofer new repository: 'http://ss3.gemstone.com/ss/DirtyExperiments'; package: 'MultiColumnList'; load This code is depending of issues 5283 and 5181 Ben

Feb. 13, 2012

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

by Igor Stasenko

On 13 February 2012 18:09, Guido Stepken <gstepken(a)googlemail.com> wrote: > Am 13.02.2012 17:53 schrieb "Sven Van Caekenberghe" <sven(a)beta9.be>: > > >> >> >> On 13 Feb 2012, at 17:25, Guido Stepken wrote: >> >> > Hahaha! You are running Apache Server in Front, caching all I/O, leaving >> > no load for Pharo at all, serving static webpages even. >> >> Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it >> is only load balancing, but to know that you have to be able to read. > > Yes! http://httpd.apache.org/docs/1.3/mod/mod_proxy.html > > Even dynamically growing cache memory. > > Tnx 4 your comments. When you put *real* and *direct* load on Pharo (no > tricks, no apache, no nginx in front), and you can see, what i mean: Memory > pumping, eating up vasts mounts of memory at even low load (use ab -n 10000 > -c 1000) ... > How about *real* and *direct* load on a sport car? Ever tried to haul fuel cistern with it? How fast it goes? The answer to your issue is just one: use proper tools for solving your problems. > Ok, facts are unwanted here. Away again! :-) > > Happy hacking! > > Guido Stepken > >> Furthermore, Apache serving static files is way faster than that, >> something most people know, you apparently not. >> >> And just for the record: I am comparing Pharo with other dynamic languages >> for dynamically generated content. >> >> Anyway, do you have anything useful to contribute ? -- Best regards, Igor Stasenko.

Feb. 13, 2012

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

by Guido Stepken

Am 13.02.2012 17:53 schrieb "Sven Van Caekenberghe" <sven(a)beta9.be>: > > > On 13 Feb 2012, at 17:25, Guido Stepken wrote: > > > Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even. > > Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it is only load balancing, but to know that you have to be able to read. Yes! http://httpd.apache.org/docs/1.3/mod/mod_proxy.html Even dynamically growing cache memory. Tnx 4 your comments. When you put *real* and *direct* load on Pharo (no tricks, no apache, no nginx in front), and you can see, what i mean: Memory pumping, eating up vasts mounts of memory at even low load (use ab -n 10000 -c 1000) ... Ok, facts are unwanted here. Away again! :-) Happy hacking! Guido Stepken > Furthermore, Apache serving static files is way faster than that, something most people know, you apparently not. > > And just for the record: I am comparing Pharo with other dynamic languages for dynamically generated content. > > Anyway, do you have anything useful to contribute ?

Feb. 13, 2012

Re: [Pharo-project] Debugging with Toggle breakpoint

by Igor Stasenko

On 13 February 2012 16:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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 can only say, that if you put a breakpoint at wrong place somewhere in morphic code, you may endup with broken system, when rendering/event handling code always goes to that method and always halts there, causing restarting UI process on every system event. Debugging UI while UI is running is not an easy task. Mostly done manually with tricks like haltOnce: or invoking doits which lead to parts of code under question. So, it would be good to know first, where exactly you put breakpoints. >> >> 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. >> > > -- Best regards, Igor Stasenko.

Feb. 13, 2012

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

by Igor Stasenko

On 13 February 2012 17:53, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 13 Feb 2012, at 17:25, Guido Stepken wrote: > >> Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even. > > Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it is only load balancing, but to know that you have to be able to read. > > Furthermore, Apache serving static files is way faster than that, something most people know, you apparently not. > > And just for the record: I am comparing Pharo with other dynamic languages for dynamically generated content. > > Anyway, do you have anything useful to contribute ? Course, trolls always have something extra to say :) -- Best regards, Igor Stasenko.

Feb. 13, 2012

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

by Sven Van Caekenberghe

On 13 Feb 2012, at 17:25, Guido Stepken wrote: > Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even. Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it is only load balancing, but to know that you have to be able to read. Furthermore, Apache serving static files is way faster than that, something most people know, you apparently not. And just for the record: I am comparing Pharo with other dynamic languages for dynamically generated content. Anyway, do you have anything useful to contribute ?

Feb. 13, 2012

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

by Alain Fischer

The code is available here: http://www.hpi.uni-potsdam.de/hirschfeld/projects/nxtalk/ Alain On 13 fÃ©vr. 12, at 17:12, Nick Ager wrote: > 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 Peter Hugosson-Miller

Hey Guido, I thought you said you were leaving us! Just too hard to stay away, eh? :-) -- Cheers, Peter On Mon, Feb 13, 2012 at 5:25 PM, Guido Stepken <gstepken(a)googlemail.com>wrote: > Hahaha! You are running Apache Server in Front, caching all I/O, leaving > no load for Pharo at all, serving static webpages even. > > Tnx 4 your funny comment! > > Have fun, Guido Stepken > Am 13.02.2012 17:08 schrieb "Sven Van Caekenberghe" <sven(a)beta9.be>: > > >> 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] Are Objects really hard?

by Guido Stepken

Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even. Tnx 4 your funny comment! Have fun, Guido Stepken Am 13.02.2012 17:08 schrieb "Sven Van Caekenberghe" <sven(a)beta9.be>: > > 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