- Pharo-dev - lists.pharo.org

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

[Pharo-project] Issue with traits

by Igor Stasenko

Create a trait: Trait named: #ABBA uses: {} category: 'ABBA'. - add a method #foo to ABBA trait Then create 2 classes which using it: Object subclass: #ABBAB uses: ABBA instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ABBA'. Object subclass: #ABBAC uses: ABBA instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ABBA'. 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 :( I'm not sure if given issue could have a major impact somewhere... But i would just #clone the trait method before installing it.. Yes, it takes more space, but it makes each of such methods unrelated. And i strongly assume that these methods should be unrelated, and moreover, recompiled for each class separately, because global var in one class could be a class var in another one, so a trait method, like: foo ^ Bar will behave depending on class environment. -- Best regards, Igor Stasenko AKA sig.

Oct. 21, 2009

[Pharo-project] Issue 1282: a:=Array new: SmallInteger maxVal. returns methodContext versus memory allocation error (was: [Vm-dev] Array new: SmallInteger maxVal)

by Petr VÃ¡cha

FYI ----- PÅ®VODNÃ ZPRÃVA ----- Od: "David T. Lewis" <lewis(a)mail.msen.com> Komu: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> PÅedmÄt: Re: [Vm-dev] Array new: SmallInteger maxVal Datum: 21.10.2009 - 4:39:21 On Tue, Oct 06, 2009 at 06:58:30PM -0400, David T. Lewis wrote: > > On Tue, Oct 06, 2009 at 10:05:02PM +0200, Nicolas Cellier wrote: > > > > >From http://code.google.com/p/pharo/issues/detail?id=1282 > > Is this known? > > Thanks, it's known now :) > > Also added to Mantis at http://bugs.squeak.org/view.php?id=7405. > > Petr: Yes this is definitely a cool bug. A fix for this is on Mantis 7405 (http://bugs.squeak.org/view.php?id=7405) The VMMaker updates are in SqueakSource in VMMaker-dtl.142. A separate patch is needed for platforms/unix/vm/sqUnixMemory.c (see the Mantis report, patch also sent to Ian). I have not tested Windows or Mac OS, but the basic scenario now is that the VM will limit the size of memory increase requests to 31 bit integer so support code can check for overflows. The requests from the VM are guaranteed (I hope) be valid 31 bit integers. Allocation requests of > 950 MB seem to be possible, although I do not have enough memory on my PC to verify that it actually works. Limiting allocation requests to more reasonable limits would be the responsibility of the image. Dave

Oct. 21, 2009