May 2013 - Pharo-dev - lists.pharo.org

Web with Pharo Conference 6 June 2013 @ Lille

by stephane ducasse

Please distribute widely We are organizing a conference around the web and pharo the 6 June 2013 at http://www.euratechnologies.com https://www.inria.fr/centre/lille/agenda/web-3.0-avec-pharo Great speakers (J. Brichau from Yesplan, N. Petton from Amber and objectfusion, N Hartl from 2Denker,...) will present their business and products as well as some of the technology they use. Do not miss this key event. Please help us to make some buzz. https://www.facebook.com/events/534073843317751/ register at: http://bit.ly/16ahf7f Stef

May 15, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Esteban Lorenzano

On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > How did you loaded NBOpenGL? > For 2.0/3.0 pharo image use > (ConfigurationOfNBOpenGL project version: '2.0') load I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make ConfigurationOfNBOpenGL load. work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. Esteban

May 15, 2013

Re: [Pharo-dev] Killing respondsTo:

by StÃ©phane Ducasse

>> > > Yes, absolutely, but that is totally independent of whether reflective > capabilities still exist in the system. > > Hey, maybe after #respondsTo: is removed, one of the kids will fix that method: > > self allMorphs do: [:p | > ((p class methodDictionary includesKey: #accept) and: [ > (p class methodDictionary includesKey: > #hasUnacceptedEdits) and: [ > p hasUnacceptedEdits]]) ifTrue: [p accept]] What we see here is the fact that we use submorphs as a general container and query it we avoid bookkeeping of dedicated containers pointing for example to textMorphs. So we trade bookkeeping for runtime checks and on top of that we also get complex Morph API (but that part can be ok I'm not convinced that all the morphs should understand accept). We do not do that when we build seaside application. We use instance variable to point to the right set of objects. I would really like to know what is the real cost of having this extra list of morph that can understand the accept messages. How many times in the same morph you may have multiple containers for dedicated morphs in addition to the submorphs ones. Stef

May 15, 2013

About Announcements

by roberto.minelli＠usi.ch

Hi, I was trying to use Announcements. In a nutshell I've a spec window which displays a collection of objects that are stored by a manager. By reading the collaborActive book, and the Help menu that comes with Pharo, I managed to have it working but I've a couple of question. Initially I modeled the thing as two separated announcers, one that sends events (i.e., the manager when new objects are added/removed) and another (i.e., the window which sends the on:do: message with the right Announcement subclass to perform something on the window itself). Unfortunately, this procedure did not work since the two announcers did not communicate between themselves. The solution I adopted is that the window (i.e., consumer of events) sends the on:do: message to the announcer of the manager. Is this the desired pattern to follow? Thanks in advance, Roby

May 15, 2013

Re: [Pharo-dev] Killing respondsTo:

by Frank Shearar

On 14 May 2013 21:27, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > why do we want to introduce a bad slow type system on certain single place? I just realised. You realise of course that reifying the set of messages you expect something to implement - a protocol - is exactly as slow a type system as isCollection, isMorph, ...? Only reifying such a protocol would tell you what a stream actually _is_, what its minimal interface is, without you having to guess that you need next:, atEnd, and whatever else. So it's not as bad a type system! frank > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> > >

May 15, 2013

[update 3.0] #30129

by Marcus Denker

30129 ----- 7550 Unload keychain https://pharo.fogbugz.com/f/cases/7550 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1120.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-MarcusDenker.70.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/StartupPreferences-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-MarcusDenker.1433.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.38.diff

May 15, 2013

Old Malinglists: delivering slowly

by Marcus Denker

Hi, So the old lists started to deliver the mails send over the last week slowly. I have put them on emergency moderation, so please use the new list to answer. Marcus

May 15, 2013

Re: [Pharo-dev] Killing respondsTo:

by Otto Behrens

+1 On Tuesday, 14 May 2013, stephane ducasse wrote: > why do we want to introduce a bad slow type system on certain single place? > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message > enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an > object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and > color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > > > On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<javascript:;>> > wrote: > >> Hi > >> > >> I'm in favor killing all the respondsTo: > >> > >> acceptTextMorphs > >> "Accept any text morphs except for those that have no edits." > >> > >> self allMorphs do: [:p | > >> ((p respondsTo: #accept) and: [ > >> (p respondsTo: #hasUnacceptedEdits) and: [ > >> p hasUnacceptedEdits]]) ifTrue: [p > accept]] > > > > They're a step up from #isKindOf:. It looks like you need is something > > that says "does this object respond to a particular set of messages > > (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! > > :) ) > > > > But in this particular case the solution looks like making a > > #insertADecentNameHere that particular classes of things can implement > > as "^ self hasUnacceptedEdits ifTrue: [self accept]" > > > > frank > > > > > -- www.FinWorks.biz +27 82 809 2375

May 15, 2013

Re: [Pharo-dev] Killing respondsTo:

by Otto Behrens

+1 On Tuesday, 14 May 2013, stephane ducasse wrote: > why do we want to introduce a bad slow type system on certain single place? > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message > enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an > object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and > color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > > > On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<javascript:;>> > wrote: > >> Hi > >> > >> I'm in favor killing all the respondsTo: > >> > >> acceptTextMorphs > >> "Accept any text morphs except for those that have no edits." > >> > >> self allMorphs do: [:p | > >> ((p respondsTo: #accept) and: [ > >> (p respondsTo: #hasUnacceptedEdits) and: [ > >> p hasUnacceptedEdits]]) ifTrue: [p > accept]] > > > > They're a step up from #isKindOf:. It looks like you need is something > > that says "does this object respond to a particular set of messages > > (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! > > :) ) > > > > But in this particular case the solution looks like making a > > #insertADecentNameHere that particular classes of things can implement > > as "^ self hasUnacceptedEdits ifTrue: [self accept]" > > > > frank > > > > > -- www.FinWorks.biz +27 82 809 2375

May 15, 2013

Re: [Pharo-dev] Killing respondsTo:

by Chris Muller

> ... snip > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). Yes, absolutely, but that is totally independent of whether reflective capabilities still exist in the system. Hey, maybe after #respondsTo: is removed, one of the kids will fix that method: self allMorphs do: [:p | ((p class methodDictionary includesKey: #accept) and: [ (p class methodDictionary includesKey: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]] ;-)

May 15, 2013