March 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Nicolai Hess

2016-03-25 9:45 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 25 Mar 2016, at 07:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Yeah this is very well-known. Note that here we are talking about the pi B > with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A > to open Nautilus on the stack vm while the Squeak UI was usable. > > The Pharo UI has been focusing on IDE features at the cost of performance, > such as auto-completion, better RB integration, Nautilus, new debugging > tools... None of the current tools (Nautilus, GTInspector, GTPlayground, > ...) are fast enough for slower devices, some of them are barely fast > enough for a laptop (for example at some point there was no auto-refresh on > GTInspector because of performance). It's not clear if it's due to the new > tools themselves as Morphic is drastically slower too on Pharo. > > The Squeak UI has been focusing on performance and stability. It is very > convenient for slow devices but also for slow VM like for example the debug > VM. > > The official answer to this problem is that Block/Brick will be faster so > it will solve all this problems. We will see. > > > yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally > it will solve some problems (the ones related to Morphic), but current lack > of performance on Pharo tools is not because of Morphic but because of some > non optimised choices. > For example, months ago I got pissed because our current list > implementation was not fast enough for our tools and thatâs why I made > FastTable: > But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ? > because it was evident we needed a better design for it. It speeded the > startup of Nautilus by an order of magnitude. This is a widget developed > with Morphic, but with a not-naive approach, so is fast. > As lists, some others widgets (notably tree) could be optimisedâ¦ > But this will not be the solution of the problem either: we need to spend > time on optimisation. Nautilus is not a good tool (we all know it has > design problems all around) but with the time had improve and not using it > is almost enjoyableâ¦ but for example, the new debugger (which Iâm not > criticising as a tool, I like it a lot) makes me hurtâ¦ is slower than > eclipse debugger and thatâs a lot to say. Also new inspector: is good, but > canât we optimise it? maybe we need to make some concession, but is the > moment of doing it. > Recently Iâm noticing a slowdown in Spotter: I believe is because one of > his categories is refreshing to the network but Iâm not sure: this slowdown > is not production acceptable, for me is a Show Stopper because it kills the > usability of the tool (of a tool who is great, but it HAS to be fast, > otherwise is useless). > > Mea culpa: more than once I have not protested even knowing than solution > X was â10% slower than the older one, but thatâs ok, we can live with itââ¦ > guess what? once you accumulate enough of those 10% penalties, you have a > barely usable system. > > We need to concentrate efforts on performance. There will not be magical > solution: if we do not spend time on enhance tools for performance, they > will be not good enough. > > Can I ask you guys to spend some time optimising tools, before we release > Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for > it in FogBugz). > > Esteban > > > > > > 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> >> > [Squeak 5 is] so *fast* (I have it running next to >> > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping >> > along at Windows desktop speeds on the Pi (Model B). >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com <http://nabble.com>. >> >> > >

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Nicolai Hess

2016-03-25 7:43 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Yeah this is very well-known. Note that here we are talking about the pi B > with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A > to open Nautilus on the stack vm while the Squeak UI was usable. > > The Pharo UI has been focusing on IDE features at the cost of performance, > such as auto-completion, better RB integration, Nautilus, new debugging > tools... None of the current tools (Nautilus, GTInspector, GTPlayground, > ...) are fast enough for slower devices, some of them are barely fast > enough for a laptop (for example at some point there was no auto-refresh on > GTInspector because of performance). It's not clear if it's due to the new > tools themselves as Morphic is drastically slower too on Pharo. > > Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? > The Squeak UI has been focusing on performance and stability. It is very > convenient for slow devices but also for slow VM like for example the debug > VM. > > The official answer to this problem is that Block/Brick will be faster so > it will solve all this problems. We will see. > > > 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> >> > [Squeak 5 is] so *fast* (I have it running next to >> > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping >> > along at Windows desktop speeds on the Pi (Model B). >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

March 25, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by phil＠highoctane.be

You made my day. It is true the Pharo feels slow, even of a powerful machine [Core i7 @ 4.4Ghz] (e.g. vs Visual Studio, PhpStorm, ... which aren't little beasts). It is particularly frustrating when having to work with BIG FONTS like I do and inside a Linux VM. Squeak is indeed super zippy by comparison. That's frustrating. Phil On Fri, Mar 25, 2016 at 10:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 25 Mar 2016, at 09:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > had improve and not using it is almost enjoyableâ¦ > > > I meant â.. had improve and NOW using it is almost enjoyableââ¦ Freud could > say a lot of things about that lapsus :P > >

March 25, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Esteban Lorenzano

> On 25 Mar 2016, at 09:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > had improve and not using it is almost enjoyableâ¦ I meant â.. had improve and NOW using it is almost enjoyableââ¦ Freud could say a lot of things about that lapsus :P

March 25, 2016

Re: [Pharo-dev] [Ann] New version of Ghost

by Christophe Demarey

Good job Denis! > Le 24 mars 2016 Ã 17:48, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > Hello. > > I finished new version of Ghost: > Abstract proxy classes uses Ghost name instead of Proxy: there are GHObjectGhost and GHClassGhost. > GHProxyHandler renamed to GHGhostBehaviour. Concrete ghosts should implement #ghostBehaviour instead of #proxyHandler. Why did you rename these classes? I find the new names obscure and they do not provide a clue of what is the purpose of the class. Old names were clear and easily understandable. > New kind of proxies: > GHObjectVirus. It is special kind of GHClassProxy. It infects real object to intercept it messages. From meta level infected object looks like healthy object which means that meta messages are executed by infected object itself. As class virus looks like real victim Same remark here. The name is fun but it does not give any clue on the purpose of the class. Why not use GHMessageInterceptor? Sorry to bother you but names are really important. Christophe

March 25, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Esteban Lorenzano

> On 25 Mar 2016, at 07:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable. > > The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo. > > The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM. > > The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see. yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimisedâ¦ But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyableâ¦ but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurtâ¦ is slower than eclipse debugger and thatâs a lot to say. Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it. Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless). Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itââ¦ guess what? once you accumulate enough of those 10% penalties, you have a barely usable system. We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough. Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz). Esteban > > > 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > > > [Squeak 5 is] so *fast* (I have it running next to > > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping > > along at Windows desktop speeds on the Pi (Model B). > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html <http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by ClÃ©ment Bera

Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable. The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo. The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM. The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see. 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > > [Squeak 5 is] so *fast* (I have it running next to > > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping > > along at Windows desktop speeds on the Pi (Model B). > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 25, 2016

Re: [Pharo-dev] [squeak-dev] [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue

by Holger Freyther

> On 25 Mar 2016, at 00:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Dear Eliot, > Fabulous, thank you! replace the self halts with e.g. self assert: (clientSocket dataAvailable = (clientSocket readSemaphore excessSignals > 0)), and we even have a test. I have work to do tomorrow but hope I should be able to debug this soon. I'll add kqueue and epoll support when I fix it. before going to kqueue, could you have a look at my hack to create a completely idle VM? Once the VM has moved to kqueue it seems one can not get a SIGIO for the "kqueue descriptor"[1] itself and I don't know if SIGIO remains working for the individual file descriptors. holger [1] https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_event.c#L1735

March 25, 2016

Re: [Pharo-dev] [Ann] New version of Ghost

by Mariano Martinez Peck

On Thu, Mar 24, 2016 at 4:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-24 19:22 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Good idea as well. Just as yet another useful example of this, I >> recommend watching the proxies I defined for Marea as you will have >> interesting proxies for classes and metaclasses. Basically, I defined quite >> some methods in those proxies so that to avoid intercepting and faulting my >> objects. See Marea code and watch for it's proxies! Let me know if you >> found the methods I am talking about. > > > And where is code? Of course I want to look > The code is in http://ss3.gemstone.com/ss/Marea BTW..note that last time I tried Marea was in Pharo 1.4 so.. not sure if it would load now. I have a one-click in either case that you can find here: https://www.dropbox.com/sh/xp8jzyypmz0898j/AACRdHno6V7UfhaJ1ofTPPXva?dl=0 And what you are looking is in category 'Marea-Proxies'. See for example MARClassProxy or MARMetaclassProxy as the examples were I added messages to the proxies to avoid being intercepted. Those methods allowed me the reduce the unncessary "swap in" when I had swapped out classes and instances and suddently a simple #do: over behaviors swapped everything in. In Marea you will find the IMPORTANT work for which I used Ghost approach. Cheers, -- Mariano http://marianopeck.wordpress.com

March 25, 2016

Re: [Pharo-dev] [Ann] New version of Ghost

by Mariano Martinez Peck

On Thu, Mar 24, 2016 at 4:33 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-24 19:15 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Awesome. Things are looking good. >> >> Now, just have to find time to use all of this :-) >> > > I just should say that I am not succeed to provide really safe ghosts. > If you will try to implement new kind of proxy (on top of Ghost) it is > possible to hang image. > Problem that when you make some mistake in implementation it usually lead > to infinite recursion and interrupt usually not helps because opened > debugger produces new messages to ghost which produces another recursion > due to original errors. And errors are not only exceptions but some > unexpected messages to proxies. For example if you will use Set to > implement proxy behaviour (for some reason) it will send #= and #hash to > proxy when you will try to add it. > Exactly. That's why Marea had to extend Fuel because otherwise, when I was serializing a graph that contained proxies, the Fuel message sends to the proxy would be intercepted and cause the swap in! hahahah. Therefore, in Marea I extend Fuel to use a custom dictionary and a custom cluster for proxies :) Ohh that's another interesting example that would be nice to be added to this new Ghost. > There are tools now to minimize such cases. For example standart meta > level will not intercept messages from debugger. But as soon as you start > experiment with empty meta level you will get such problems. > This week Guille Polito start to use Ghost for new proxies and he was not > happy due to this kind of problems. Maybe together we will find some > solution how to make ghosts safe. > > -- Mariano http://marianopeck.wordpress.com

March 25, 2016