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

Re: [Pharo-project] [squeak-dev] Re: Issue with traits
by Adrian Lienhard Oct. 23, 2009

Oct. 23, 2009

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 > >

3 4

[Pharo-project] the we site does not point to the rc1 image/
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

can somebody fix it? Stef

6 12

Re: [Pharo-project] Bug in OCompletion
by Mariano Martinez Peck Oct. 22, 2009

Oct. 22, 2009

This bug has been closed but I can still reproduce it in 10479. Can someone please test it and tell me if I am not the only one. Thanks mariano On Wed, Sep 23, 2009 at 4:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Begin forwarded message: > > *From: *Mariano Martinez Peck <marianopeck(a)gmail.com> > *Date: *September 23, 2009 8:20:40 PM CEDT > *To: *Pharo Development <pharo-project(a)lists.gforge.inria.fr> > *Subject: **[Pharo-project] Bug in OCompletion* > *Reply-To: *Pharo-project(a)lists.gforge.inria.fr > > http://code.google.com/p/pharo/issues/detail?id=1236 > > Tested with OBSystemBrowserAdaptor in pharo1.0-10451-BETAdev09.09.3 on > Windows. > > To reproduce: > > 1) Open a System Browser > 2) Create a new class. When you do this, when you are changing > "#NameOfSubclass" to "#YourClass", after doing this press the down arrow > key > 3) An empty pop up will be brought and the keyboard won't respond. To fix > this, you must press "Esc" key. > > > Best, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

2 3

[Pharo-project] feedback about the "new inspector"
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

Hi guys we tried to use and force you to use the new inspector and it does not fly that well. I'm sure that frederick is open to suggestion so please send your remarks. Here were mine :) Stef Hello Stef, here what is really strange and annoying is that we cannot see the collection elements in the right pane Now it is fixed. on the left Elements is confusing. because this is not clear the relationship with array, firstInd.... It shows only elements of any kind of collection (it is simply a collect: [:o | o] on the collection). on the right this is also frustrating that we cannot modify, touch the elements. Ok... but you can expand the Elements, select the element you want to change, put the new value in the description pane and accept it. I'm not sure that we want to see the class (in an expandable manner). For the methods may be you want to stop and show the methods but expandabel may be by defualt you should not show the class and methods as expandable and have a menu entry doing that (expand) I'm not sure to understand what you want. For me the NewInspector it is a like an infinite inspector: if you want to go into an object, you can. So if you want to inspect a class or the methods, you should have the possibility to do it. FrÃ©d

8 11

[Pharo-project] release image 11011 for 1.1-alpha on the inria web site
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

Hi I released image 11011 for 1.1-alpha on the inria web site Stef

1 0

[Pharo-project] The package of ParagraphEditor
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

I never understood why a User Interface class was in the Kernel I'm curious to know what Pavel think about it ! Squeak/trunk put it to a better place: ParagraphEditor ( snip ) category: 'ST80-Controllers' Shouldn't Pharo follow this re-classification ? Nicolas

2 1

[Pharo-project] [update 1.1 ] #11011
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

11011 ----- - Issue 1357: use includesSelector: rather than selectors includes: Rationale for using #includesSelector: - a single message is better than two - an optimized method is better than a slow one The method is optimized because it directly ask methodDict includesKey: rather than creating an unecessary intermediate collection.

1 0

[Pharo-project] making #classVarNames answer a sorted Array
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

Proposal is logged at http://code.google.com/p/pharo/issues/detail?id=1354 Recently in trunk

2 2

Oct. 22, 2009

one of the pharo sprinter forgot his adaptor :) let me know that we ship it by post Stef

3 3

[Pharo-project] Question about PBE book by newbie, instance variables
by Gerben van de Wiel Oct. 22, 2009

Oct. 22, 2009

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

6 8