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

[ann] pharo consortium membership matching campaign

by Tudor Girba

Hi, The Pharo Board is proud to announce a special campaign for attracting new Pharo Consortium members during 2016: http://consortium.pharo.org/web/Membership A new fund has been created from which the Consortium will receive the equivalent of one yearly membership fee for every new member, and the increment in yearly fees for every upgrading member. For example, if a new company joins the Consortium as a Silver member (2000 EUR / year), the fund will contribute a one-time amount of 2000 EUR to the Consortium. Similarly, if a company upgrades from Bronze (1000 EUR / year) to Gold (4000 EUR / year), the fund will contribute a one-time amount of 3000 EUR. This campaign will take place until the end of 2016, or until the fund is depleted. Currently, the fund totals 21000 EUR, a sum which is graciously supported by three companies: - LabWare Inc (http://labware.com) - ObjectProfile (http://objectprofile.com) - feenk gmbh (http://feenk.com) This is an exciting development that paves the way to attract more industrial interest around Pharo. Please help us by spreading the word about this campaign. Cheers, The Pharo Board

March 25, 2016

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

by Denis Kudriashov

2016-03-25 14:54 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Sorry to bother you but names are really important. >> > > Exactly!!! > Forgot to say. When I see words in class names like Abstract, Handler, Delegator... I remember many "good" years with java. Please lets make names better.

March 25, 2016

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

by Denis Kudriashov

2016-03-25 13:26 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I agree here. I originally called the tool Ghost mostly because I wanted > TRANSPARENT proxies for all kind of objects (included classes, methods, > etc), and LIGHTWEIGHT. So...I thought that Ghost were transparent and > lightweight hahahaha. But I realised real value of this metaphor (not just lightness). I answer to Christophe

March 25, 2016

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

by Denis Kudriashov

Hi 2016-03-25 9:47 GMT+01:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > > - 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. > Nice you ask. It can raise interesting discussion. In previous version we have three classes to support basic object proxy: GHInterceptionDelegator GHProxyTrap GHAbstractProxy And now due to DNU approach it just one: GHObjectGhost And I guess you would call it GHObjectProxy or GHAbstractProxy. Lets look at wikipedia: > A *proxy*, in its most general form, is a class functioning as an > interface to something else. The proxy could interface to anything: a > network connection, a large object in memory, a file, or some other > resource that is expensive or impossible to duplicate. In short, a proxy is > a wrapper or agent object that is being called by the client to access the > real serving object behind the scenes So proxy is supposed to substitute some other object. But in many cases we not have other object. In many cases we construct special kind of objects which perform messages in not smalltalk way. For example imaging that we want to implement javascript prototypes (there was related post https://clementbera.wordpress.com/2016/02/17/mind-twister-toying-with-objec…) Prototype is definitely not kind of proxy. Or think about Mock object. It is not proxy too. So generally Ghost is not about proxies. It is exactly about supernatural objects. With Ghost we construct special objects which behave in not natural smalltalk way. And in that perspective classic proxy is most primitive example of it. It just delegates all messages to another object (with little bit of logic). Maybe you would suggest another name: GHInterceptionDelegator (what the name for GHGhostClass in that case?). But why we not call Object same way too (InterceptionDelegator)? Natural smalltalk objects just delegate message processing to methods from class methodDictionary (which is hidden by VM). So for me ObjectGhost reflects perfectly real intention of it. It is base class to construct unnatural smalltalk objects. And ClassGhost is unnatural object which can play role of natural object classes. Now lets look at ProxyHandler vs GhostBehaviour. ProxyHandler play role of Behavior (Class) but for proxies. It defines how proxies will handle messages. But why we not call smalltalk Behaviour as ObjectHandler? I hope now you see logic behind my names and ghost metaphor. Ghost models special objects with similar terms from natural objects: Object -> ObjectGhost and Behavior -> GhostBehaviour. I changed title of Ghost project to: Ghost is framework to implement unnatural smalltalk objects like proxies and prototypes., > - 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? > And following such approach we will have GHInterceptionDelegator (for objects) and GHMessageInterceptor (for classes). Is it good? I will describe virus more detailed soon. But maybe you remember there was very old advice from famous books: don't create classes which ends with -ER or -OR. (I not found original source but google shows many followers http://www.yegor256.com/2015/03/09/objects-end-with-er.html http://objology.blogspot.fr/2011/09/one-of-best-bits-of-programming-advice.… ) > Sorry to bother you but names are really important. > Exactly!!!

March 25, 2016

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

by Esteban Lorenzano

Hi, > On 25 Mar 2016, at 12:52, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> 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. > > That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help. > >> 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. > > The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this? actually there is a tree implementation based on fast table, but Iâm not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will âopenâ attribute in next panel), I do agree, strongly :) > >> 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). > > Could you be more specific about the Spotter problem that you see? not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but Iâm not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all). > > Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something. > > >> 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). > > It would indeed be useful to get more eyes spent on this. yes! if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5â¦ feel the incremental slowdown 3. cry :â( Esteban > > Cheers, > Doru > >> >> 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. > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "Not knowing how to do something is not an argument for how it cannot be done."

March 25, 2016

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

by Mariano Martinez Peck

On Fri, Mar 25, 2016 at 5:47 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > 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. > I agree here. I originally called the tool Ghost mostly because I wanted TRANSPARENT proxies for all kind of objects (included classes, methods, etc), and LIGHTWEIGHT. So...I thought that Ghost were transparent and lightweight hahahaha. But... one thing is the project name and the other is class names. Here I agree with Christophe that I prefer the old names. Same as for the virus stuff. I would not go that deep into the metaphor. -- Mariano http://marianopeck.wordpress.com

March 25, 2016

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

by Nicolai Hess

2016-03-25 12:52 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > >> > >> 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. > > That is a good one :). There is an open issue with the blinking problem > when you accept code which makes it appear slower than it actually is, but > we are stuck with it and we could benefit from help. > "appear slower than it actually is" Really? Aliaksei comment was: "Each code accept triggers a lot of glamour inner stuff and in the end refreshes the almost whole debugger interface. (Panes, Tabulator, LazyTable and so on)" So, is it slow, or does it just look slow? > > > 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. > > The optimization we should do now is to replace the appearances of > MorphTreeMorph with FastTable. This would imply that the Raw presentation > would not longer have a tree (because it is not supported in FastTable). I > would be very happy if we could do that. Do we agree on this? > > > 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). > > Could you be more specific about the Spotter problem that you see? > > Also, in the last couple of days Alex Syrel improved the speed of Spotter > significantly. It is not yet integrated. It would be useful to get feedback > on this because maybe we missed something. > > > > 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). > > It would indeed be useful to get more eyes spent on this. > > Cheers, > Doru > > > > > 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. > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > >

March 25, 2016

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

by Tudor Girba

Hi, > On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> 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. That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help. > 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. The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this? > 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). Could you be more specific about the Spotter problem that you see? Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something. > 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). It would indeed be useful to get more eyes spent on this. Cheers, Doru > > 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. -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

March 25, 2016

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

by Stephan Eggermont

On 25-03-16 11:49, Nicolai Hess wrote: > 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? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening. Stephan

March 25, 2016

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

by Esteban Lorenzano

> On 25 Mar 2016, at 11:50, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ? yes, but we use it very differently :) we add tons and tons of functionality on top of it, so we made, Nautilus for example, slower. Is not a problem of the list: is that we are/were using it differently, and in a very different way of his first intention (take a pluggable list, add 1k strings: worksâ¦ add 1k iconsâ¦ works worst, but worksâ¦ add 1k buttons instead those iconsâ¦ and sufferâ¦ :P). Esteban

March 25, 2016