October 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 1351: OCompletion doesn't guess instVar in debugger context

by CÃ©drick BÃ©ler

When coding in the debugger, and accessing directly an instvar, writing code after the instvar raises a Message not understood as the debugger map is nil. http://code.google.com/p/pharo/issues/detail?id=1351 -- CÃ©drick

Oct. 21, 2009

[Pharo-project] Question about PBE book by newbie, instance variables

by Gerben van de Wiel

Hi, I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of. bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree). regards, Gerben van de Wiel

Oct. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Re: Issue with traits

by CÃ©drick BÃ©ler

done 2009/10/21 Marcus Denker <denker(a)acm.org> > maybe someone should forward this to squeak-dev, I am not subscribed. > > Begin forwarded message: > > > From: Marcus Denker <denker(a)acm.org> > > Date: 21. Oktober 2009 11:13:01 GMT+02:00 > > To: Pharo-project(a)lists.gforge.inria.fr > > Cc: The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org > > > > > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits > > > > > > On 21.10.2009, at 09:41, Adrian Lienhard wrote: > > > >> I've fixed this issue in Pharo a couple of months ago. > >> CompiledMethods > >> are not shared anymore, so methodClass returns the expected class. At > >> the time I implemented traits (2004?), there were no method > >> properties > >> and hence sharing compiled methods worked -- of course except for > >> super sends in which case the method was always recompiled (so the > >> answer to Andreas' question below is b)). > >> > > > > We did a small paper for this years ESUG that describes the changes. > > It will be online at esug.org soon with all the other papers. > > > > If somebody wants a copy, I can send it. > > > > Marcus > > > > -- > > Marcus Denker -- marcus(a)2denker.de > > http://www.2denker.de > > > > 2denker UG (haftungsbeschrÃ¤nkt) > > Sitz KÃ¶ln > > Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 > > GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Oct. 21, 2009

[Pharo-project] Fwd: [squeak-dev] Re: Issue with traits

by Marcus Denker

maybe someone should forward this to squeak-dev, I am not subscribed. Begin forwarded message: > From: Marcus Denker <denker(a)acm.org> > Date: 21. Oktober 2009 11:13:01 GMT+02:00 > To: Pharo-project(a)lists.gforge.inria.fr > Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits > > > On 21.10.2009, at 09:41, Adrian Lienhard wrote: > >> I've fixed this issue in Pharo a couple of months ago. >> CompiledMethods >> are not shared anymore, so methodClass returns the expected class. At >> the time I implemented traits (2004?), there were no method >> properties >> and hence sharing compiled methods worked -- of course except for >> super sends in which case the method was always recompiled (so the >> answer to Andreas' question below is b)). >> > > We did a small paper for this years ESUG that describes the changes. > It will be online at esug.org soon with all the other papers. > > If somebody wants a copy, I can send it. > > Marcus > > -- > Marcus Denker -- marcus(a)2denker.de > http://www.2denker.de > > 2denker UG (haftungsbeschrÃ¤nkt) > Sitz KÃ¶ln > Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 > GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker > > > >

Oct. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Issue with traits

by Marcus Denker

On 21.10.2009, at 09:41, Adrian Lienhard wrote: > I've fixed this issue in Pharo a couple of months ago. CompiledMethods > are not shared anymore, so methodClass returns the expected class. At > the time I implemented traits (2004?), there were no method properties > and hence sharing compiled methods worked -- of course except for > super sends in which case the method was always recompiled (so the > answer to Andreas' question below is b)). > We did a small paper for this years ESUG that describes the changes. It will be online at esug.org soon with all the other papers. If somebody wants a copy, I can send it. Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

Oct. 21, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz

by CÃ©drick BÃ©ler

Useful ? There are other related commits. Cheers ---------- Forwarded message ---------- From: <commits(a)source.squeak.org> Date: 2009/10/21 Subject: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz To: squeak-dev(a)lists.squeakfoundation.org Joshua Gargus uploaded a new version of Exceptions to project The Trunk: http://source.squeak.org/trunk/Exceptions-jcg.14.mcz ==================== Summary ==================== Name: Exceptions-jcg.14 Author: jcg Time: 21 October 2009, 12:59:37 pm UUID: 6fba13f2-81a8-4949-8b9e-d5c10aa58da6 Ancestors: Exceptions-nice.13 Add NotYetImplemented exception class. =============== Diff against Exceptions-nice.13 =============== Item was added: + ----- Method: NotYetImplemented>>receiverClass:selector: (in category 'initialize') ----- + receiverClass: cls selector: sel + receiverClass := cls. + selector := sel.! Item was added: + ----- Method: NotYetImplemented>>selector (in category 'accessing') ----- + selector + ^selector! Item was added: + Error subclass: #NotYetImplemented + instanceVariableNames: 'receiverClass selector context' + classVariableNames: '' + poolDictionaries: '' + category: 'Exceptions-Kernel'! + + !NotYetImplemented commentStamp: 'jcg 10/21/2009 00:58' prior: 0! + Sent by #notYetImplemented. Better than the age-old behavior of opening a notifier window, because this can be caught and handled + + Perhaps there should be a Morphic backstop to open a notifier if no-one else handles the exception, but this doesn't seem too important. + ! Item was added: + ----- Method: NotYetImplemented>>receiverClass (in category 'accessing') ----- + receiverClass + ^receiverClass! Item was added: + ----- Method: NotYetImplemented class>>signal (in category 'signaling') ----- + signal + "Call only from #notYetImplemented. Find the context that sent #nYI... this is the method that needs to be implemented." + | ctxt ex | + ctxt := thisContext sender sender. + ex := self new. + ex receiverClass: ctxt receiver class selector: ctxt selector. + ex messageText: ctxt printString. + ex signal. + ! -- CÃ©drick

Oct. 21, 2009

Re: [Pharo-project] bug with "Extended Search" of low panel of new inspector

by Frederic Pluquet

The bug is fixed in the last version. For the name: I changed NewInspector to Inspector. The window name is now composed of the label of the element (defined by the niLabel method) followed by "on Inspector". FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Wed, Oct 21, 2009 at 9:32 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Should the window title not be > a String > a Dictionary > etc? > > Cheers > mike > > On Wednesday, October 21, 2009, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi folks (Romain?) There is a bug with the NewInspector. To reproduce: > > > > 1) just inspect something. > > 2) now, in the inspector go to the lower panel and write something. > > 3) Select it, right button, and click on "Extended Search" > > > > I won't bring the extended search, but it will open again the context > menu (as when you right click). > > > > Bug ticket: http://code.google.com/p/pharo/issues/detail?id=1350 > > > > BTW, can we please rename NewInspector to Inspector ??? Or at least the > title of the windows. > > > > I think that names like "New Inspector" or "Shout Workspace" are > difficult to understand for newcomers. So, I would change, at least, the > windows title of them to "Inspector" and "Workspace" > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Issue with traits

by Adrian Lienhard

I've fixed this issue in Pharo a couple of months ago. CompiledMethods are not shared anymore, so methodClass returns the expected class. At the time I implemented traits (2004?), there were no method properties and hence sharing compiled methods worked -- of course except for super sends in which case the method was always recompiled (so the answer to Andreas' question below is b)). Cheers, Adrian On Oct 21, 2009, at 08:42 , Andreas Raab wrote: > Igor Stasenko wrote: >> now what i found interesting: >> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo) >> but as side effect, we got this one: >> (ABBAB methodDict at: #foo) methodClass ==> ABBAC >> which i find a bit disturbing :( > > Yes, seems wrong. VERY wrong. Try this: > > Object subclass: #BaseA > > BaseA>>foo > ^42 > > Object subclass: #BaseB > > BaseB>>foo > ^13 > > And then create subclasses of BaseA and BaseB which use your trait > and have the trait implementation use "^super foo". One of two > things should happen: > > a) They both return the same (incorrect) value (which would be > expected if methodClass is the same). In this case it's just plain > broken. > > b) They both return different values, in which case there is code > that handles super sends specifically and the sharing is simply an > unnecessary optimization. > > I hope it's the latter case which would mean you only need to throw > out the test for super sends and do whatever that code was doing to > begin with ;-) > > Cheers, > - Andreas > >

Oct. 21, 2009

Re: [Pharo-project] bug with "Extended Search" of low panel of new inspector

by Michael Roberts

Should the window title not be a String a Dictionary etc? Cheers mike On Wednesday, October 21, 2009, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi folks (Romain?)Â Â There is a bug with the NewInspector. To reproduce: > > 1) just inspect something. > 2) now, in the inspector go to the lower panel and write something. > 3) Select it, right button, and click on "Extended Search" > > I won't bring the extended search, but it will open again the context menu (as when you right click). > > Bug ticket: http://code.google.com/p/pharo/issues/detail?id=1350 > > BTW, can we please rename NewInspector to Inspector ??? Or at least the title of the windows. > > I think that names like "New Inspector" or "Shout Workspace" are difficult to understand for newcomers. So, I would change, at least, the windows title of them to "Inspector" and "Workspace" > > >

Oct. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Issue with traits

by Igor Stasenko

2009/10/21 Andreas Raab <andreas.raab(a)gmx.de>: > Igor Stasenko wrote: >> >> now what i found interesting: >> >> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo) >> >> but as side effect, we got this one: >> >> (ABBAB methodDict at: #foo) methodClass Â ==> ABBAC >> >> which i find a bit disturbing :( > > Yes, seems wrong. VERY wrong. Try this: > > Object subclass: #BaseA > > BaseA>>foo > Â ^42 > > Object subclass: #BaseB > > BaseB>>foo > Â ^13 > > And then create subclasses of BaseA and BaseB which use your trait and have > the trait implementation use "^super foo". One of two things should happen: > > a) They both return the same (incorrect) value (which would be expected if > methodClass is the same). In this case it's just plain broken. > > b) They both return different values, in which case there is code that > handles super sends specifically and the sharing is simply an unnecessary > optimization. > > I hope it's the latter case which would mean you only need to throw out the > test for super sends and do whatever that code was doing to begin with ;-) > Ouch... so VM behavior depends on correct methodClass slot. Thanks for reminding! I remember that methodClass plays important role (and its important to have method and its methodClass being in sync with class where the method installed), but forgot the details :) That could lead to even worse results, if you use super sends, and then in base class , accessing the instance variables in base method. It could corrupt the memory & crash the VM. I hope this is already fixed, because the image where i checked it is quite old one - 3.10.2 > Cheers, > Â - Andreas -- Best regards, Igor Stasenko AKA sig.

Oct. 21, 2009