- Pharo-dev - lists.pharo.org

[Pharo-project] Alien-Core-kdt.59
by Ken Treis Oct. 21, 2009

Oct. 21, 2009

AlienWeakTable sends #copyGrownBy: to both of its internal arrays, but it looks like neither Squeak nor Pharo implement it in the collection hierarchy. Pharo has #grownBy:, but Squeak doesn't. So in Alien-Core- kdt.59, I implemented SequenceableCollection>>copyGrownBy: by copying in the Pharo implementation of #grownBy:. This should solve some nastiness that could happen when the table hit its initial maximum (1024 objects). -- Ken Treis Miriam Technologies, Inc.

1 0

[Pharo-project] Stack re-implemented
by Niko Schwarz Oct. 21, 2009

Oct. 21, 2009

Hi list, issue 1336 proposes re-implementing Stack using the new LinkedList which can take arbitrary objects. I committed the code and it was really straightforward to do. Now stack is implemented in 3 one-line methods, removing about 10 methods, and removing one class (StackLink). Please see http://code.google.com/p/pharo/issues/detail?id=1336 or SLICE-issue-1336-StackReimplemented-NikoSchwarz.2. in the inbox. Cheers, Niko

1 0

[Pharo-project] Issue 1351: OCompletion doesn't guess instVar in debugger context
by CÃ©drick BÃ©ler Oct. 21, 2009

Oct. 21, 2009

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

2 2

[Pharo-project] thanks to all the sprinters
by StÃ©phane Ducasse Oct. 21, 2009

Oct. 21, 2009

Hi I want to thank you all for the three or four last days. It was good energy. Stef PS: for the others, adrian took some notes for the next iteration http://code.google.com/p/pharo/wiki/Milestones The idea is to have some focused tasks beside the normal continuous improvement and also have previous items. stef

2 2

[Pharo-project] Fwd: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz
by CÃ©drick BÃ©ler Oct. 21, 2009

Oct. 21, 2009

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

2 1

[Pharo-project] Class and Metaclass explanation in PBE
by Mariano Martinez Peck Oct. 21, 2009

Oct. 21, 2009

Hi folks. I was reading chapter 13 of PBE and there is something I don't understand. In page 283 it says: "Every metaclass is-a class, hence inherits from Class. Class in turn inherits from its superclasses, ClassDescription and Behavior." page 278, rule 8, it says: "Every metaclass inherits from Class and Behavior." However, if I open a class browser, I see that Metaclass inherits from ClassDescription, not Class. So, I don't understand :( Can anyone clarify me this? Thanks Mariano

3 3

[Pharo-project] scriptloader>>loadComanche
by Johan Brichau Oct. 21, 2009

Oct. 21, 2009

Hi there, Scriptloader has lost its #loadComanche method, which means that #loadSeaside30 does not work anymore. What happened? ;-) ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

5 11

[Pharo-project] bug with "Extended Search" of low panel of new inspector
by Mariano Martinez Peck Oct. 21, 2009

Oct. 21, 2009

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"

3 2

Re: [Pharo-project] [squeak-dev] Re: Issue with traits
by Igor Stasenko Oct. 21, 2009

Oct. 21, 2009

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.

1 0

[Pharo-project] Issue with traits
by Igor Stasenko Oct. 21, 2009

Oct. 21, 2009

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.

1 0