September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.4] #14146

by StÃ©phane Ducasse

good I was planning to do them :) So I will check some other issues. Stef On Sep 17, 2011, at 11:05 AM, Marcus Denker wrote: > 14146 > ----- > > Issue 4810: Fix in PluggableListMorph selection on drag > http://code.google.com/p/pharo/issues/detail?id=4810 > Issue 4803: MNU: receiver of on:list:primarySelection:changePrimarySelection:listSelection:changeListSelection:menu: is nil > http://code.google.com/p/pharo/issues/detail?id=4803 > Issue 4573: Should deprecate TimeProfileBrowser > http://code.google.com/p/pharo/issues/detail?id=4573 > -- > Marcus Denker -- http://marcusdenker.de > >

Sept. 17, 2011

Re: [Pharo-project] default window menu

by StÃ©phane Ducasse

yes do you have code :) Stef On Sep 17, 2011, at 10:58 AM, Tudor Girba wrote: > Hi, > > Every window comes with a default menu. Most actions are useless or they can be found in the halo anyway. > > But, the window menu is not harmless: even if a window does have a specific set of actions (not just the default ones), the user is not informed because the same triangle appears in all windows. As an example, look at the Transcript and at the Workspace. The Transcript menu is useless, while the Workspace one is not. > > Glamour no longer offers this by default. Only if you have a window specific menu, you get it there. Like that when you see the triangle, you know it has a meaningful set of actions for you. > > I would suggest making this a default behavior for all windows. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > >

Sept. 17, 2011

[Pharo-project] [update 1.4] #14146

by Marcus Denker

14146 ----- Issue 4810: Fix in PluggableListMorph selection on drag http://code.google.com/p/pharo/issues/detail?id=4810 Issue 4803: MNU: receiver of on:list:primarySelection:changePrimarySelection:listSelection:changeListSelection:menu: is nil http://code.google.com/p/pharo/issues/detail?id=4803 Issue 4573: Should deprecate TimeProfileBrowser http://code.google.com/p/pharo/issues/detail?id=4573 -- Marcus Denker -- http://marcusdenker.de

Sept. 17, 2011

[Pharo-project] default window menu

by Tudor Girba

Hi, Every window comes with a default menu. Most actions are useless or they can be found in the halo anyway. But, the window menu is not harmless: even if a window does have a specific set of actions (not just the default ones), the user is not informed because the same triangle appears in all windows. As an example, look at the Transcript and at the Workspace. The Transcript menu is useless, while the Workspace one is not. Glamour no longer offers this by default. Only if you have a window specific menu, you get it there. Like that when you see the triangle, you know it has a meaningful set of actions for you. I would suggest making this a default behavior for all windows. Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Sept. 17, 2011

[Pharo-project] [update 1.4] #14145

by Marcus Denker

14145 ----- Issue 2986: DemoMode should not change Fonts only sizes http://code.google.com/p/pharo/issues/detail?id=2986 -- Marcus Denker -- http://marcusdenker.de

Sept. 17, 2011

[Pharo-project] MethodWrappers for Squeak 4.2

by Eliot Miranda

Hi All, I've completed porting MethodWrappers to Squeak 4.2. You'll need to update your image to at least Compiler-eem.215 & Kernel-eem.623. You can find MethodWrappers4.2-eem.17 at http://www.squeaksource.com/MethodWrappers. Enjoy. P.S. Anyone in VW land interested in updating the codee? The class comments in VW are obsolete (valueNowOrOnUnwindDo: is mentioned instead of ensure: etc). If you do update the code you might want to add the tweak I did to MwBlockMethodWrapper>valueWithReceiver:arguments: to make both before and after blocks optional. i.e. MwBlockMethodWrapper methods for evaluating valueWithReceiver: anObject arguments: anArrayOfObjects "Optionally evaluate beforeBlock before evaluating clientMethod if beforeBlock is non-nil. Optionally evaluate afterBlock afterwards if afterBlock is non-nil." self wasActive: true. self beforeBlock ifNotNil: [:beforeBlock| beforeBlock value: anObject value: anArrayOfObjects]. ^self afterBlock ifNil: [self clientMethod valueWithReceiver: anObject arguments: anArrayOfObjects] ifNotNil: [:afterBlock| [self clientMethod valueWithReceiver: anObject arguments: anArrayOfObjects] ensure: [afterBlock value: anObject value: anArrayOfObjects]] On Tue, Sep 13, 2011 at 2:42 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > the most up-to-date MethodWrappers I can find is for Squeak 3.9, > pre-closures. Anyone have anything compatible with Squeak 4.1/4.2/Pharo > 1.1/1.2/1.3? > > -- > best, > Eliot > > -- best, Eliot

Sept. 16, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Eliot Miranda

On Fri, Sep 16, 2011 at 12:32 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I dream to rewrite from scratch the classBuilder. But first we should close > some pending open work. > So going slowler but in a stable manner. > +1000. this is a platform and platforms remain in one place even as they get better and better facilities :) > Stef > > > > > > > On Fri, Sep 16, 2011 at 12:08 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2011/9/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > 2011/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > >> I don't really know. I have implemented what Eliot say in the first > option > > >> and it is working for me. > > >> Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution > and > > >> then improve it if necessary ? > > >> > > >> thanks > > >> > > > > > > I agree on Mariano/Eliot solution. It is a good pragmatic short term > workaround. > > > In the long term, I wish I can say goodbye to my new super power, it's > > > a too dangerous power. > > > So I wish the VM would change (along with ClassBuilder and Tools). > > > > Yes, I agree. It just takes time to get there. > > > > > > > > Nicolas > > > > > > > Or maybe after reading: > > > > literal1 := self literalAt: numLits. > > literal2 := method literalAt: numLits. > > ^ (literal1 == literal2) or: [literal1 key isNil == literal2 key > > isNil and: [literal1 value == literal2 value]]. > > > > I we are sure that the last literal is always an Association > > > > If it's not then one is playing fast and loose with the system. But if > the method doesn't contain a super send then as far as the VM is concerned > it doesn't need an association, and that might be the case with, for > example, shared inst var accessors in Newspeak. So instead of assuming its > an association write it something like > > > > ^literal1 class == literal2 class > > and: [literal1 isVariableBinding > > ifTrue: [literal1 key = literal2 key and: [literal1 value > = literal2 value]] > > ifFalse: [literal1 = literal2]] > > > > > > Nicolas > > > > >> On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse > > >> <stephane.ducasse(a)inria.fr> wrote: > > >>> > > >>> Mariano > > >>> > > >>> So should we intgerate a fix? > > >>> > > >>> Stef > > >>> > > >>> On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: > > >>> > > >>> > > > >>> > > > >>> > > > >>> > BUT, it doesn't mean that Association is always used for globals. > > >>> > CompiledMethod equality is failing because of the last literal, the > one that > > >>> > maps class name (symbol) and point to the real class. So...when I > > >>> > materialize, both CMs have non-identical associations for the last > literal, > > >>> > but equal. > > >>> > > > >>> > As Henrik says the last literals are ideally #== to each other. > > >>> > However, no Squeak dialect makes any attempt to keep the > class0side > > >>> > associations equal. Look at a class-side method and you'll see it's > last > > >>> > literal is nil->SomeClass class. Now since this association > doesn't exist > > >>> > in Smalltalk (unlike last literals on the instance side) the > compiler merely > > >>> > creates distinct ones for each class-side method. > > >>> > > > >>> > > > >>> > Thanks Eliot for that point. In fact, I have just checked and you > are > > >>> > right. The tests that are failing for me is those where class side > methods > > >>> > are involded. In this case, the last literal of the original CM and > the > > >>> > materialized, gives false in #literalEqual: hence, originalCM = > > >>> > materializedCM is false :( > > >>> > > > >>> > > > >>> > > > >>> > Personally I don't think one can defend the position where method > > >>> > equality is different for instance-side or class-side methods so > there must > > >>> > be some solutions: > > >>> > > > >>> > 1. special case comparison of the last literal (the methodClass > > >>> > literal), comparing keys and insisting that the keys be #== and the > values > > >>> > be #== (can't just define it as keys #== since all similar > class-side > > >>> > methods will be equal irrespective of their actual class). > > >>> > > > >>> > > > >>> > This one seems the easier and fixes my problem :) > > >>> > > > >>> > sameLiteralsAs: method > > >>> > "Compare my literals to those of method. This is needed to > compare > > >>> > compiled methods." > > >>> > > > >>> > | numLits literal1 literal2 | > > >>> > (numLits := self numLiterals) ~= method numLiterals > > >>> > ifTrue: [ ^ false ]. > > >>> > "The last literal requires special checking instead of using > > >>> > #literalEqual:" > > >>> > 1 to: numLits - 1 do: [ :index | > > >>> > literal1 := self literalAt: index. > > >>> > literal2 := method literalAt: index. > > >>> > (literal1 == literal2 or: [ literal1 literalEqual: literal2 > ]) > > >>> > ifFalse: [ > > >>> > (index = 1 and: [ #(117 120) includes: self > primitive ]) > > >>> > ifTrue: [ > > >>> > literal1 isArray > > >>> > ifTrue: [ > > >>> > (literal2 isArray and: [ literal1 > > >>> > allButLast = literal2 allButLast ]) > > >>> > ifFalse: [ self halt. ^ false ] > ] > > >>> > ifFalse: [ > > >>> > "ExternalLibraryFunction" > > >>> > (literal1 analogousCodeTo: > literal2) > > >>> > ifFalse: [ self halt. ^ false ] > ] ] > > >>> > ifFalse: [ > > >>> > index = (numLits - 1) > > >>> > ifTrue: [ > > >>> > "properties" > > >>> > (self properties analogousCodeTo: > method > > >>> > properties) > > >>> > ifFalse: [ self halt. ^ false ] > ] > > >>> > ifFalse: [ self halt. ^ false ] ] ] ]. > > >>> > literal1 := self literalAt: numLits. > > >>> > literal2 := method literalAt: numLits. > > >>> > ^ ((literal1 key == literal2 key) and: [literal1 value == > literal2 > > >>> > value]). > > >>> > > > >>> > > > >>> > > > >>> > 2. special case comparison of the last literal (the methodClass > > >>> > literal), insisting only that the class of the literal be the same > if it > > >>> > isVariableBinding. > > >>> > > > >>> > 3. make the compile unique class-side methodClass literals. i.e. > if a > > >>> > class already has a class-side method then the compiler or method > dictionary > > >>> > insertion code must find that existing association and reuse it > > >>> > > > >>> > Other ideas? > > >>> > > > >>> > >From my point of view, that literal, the last one does not need to > be > > >>> > identical to assume 2 CMs are equal. They just need to be equal. > > >>> > > > >>> > > > >>> > -- > > >>> > Mariano > > >>> > http://marianopeck.wordpress.com > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > -- > > >>> > best, > > >>> > Eliot > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > -- > > >>> > Mariano > > >>> > http://marianopeck.wordpress.com > > >>> > > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> Mariano > > >> http://marianopeck.wordpress.com > > >> > > >> > > > > > > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Sept. 16, 2011

Re: [Pharo-project] Zodiac Alpha - September 13, 2011

by StÃ©phane Ducasse

don't worry I'm slow :) But it would help to get a lot of class comments and examples :) Stef On Sep 16, 2011, at 9:21 PM, Sven Van Caekenberghe wrote: >> On 13 Sep 2011, at 22:41, StÃ©phane Ducasse wrote: >> >>> BTW we will start to write a chapter on zinc with olivier auverlot :) > > OK, more documentation is always better. If you have any questions, don't hesitate to mail me. > > But please don't rush to it: I am in the process of merging all Zn clients into one. It would be better to wait until then. > > On the other hand, if you just think of ZnNeoClient as being named ZnClient, you could already start. > > Sven > >

Sept. 16, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by StÃ©phane Ducasse

I dream to rewrite from scratch the classBuilder. But first we should close some pending open work. So going slowler but in a stable manner. Stef > > > On Fri, Sep 16, 2011 at 12:08 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > 2011/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> I don't really know. I have implemented what Eliot say in the first option > >> and it is working for me. > >> Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution and > >> then improve it if necessary ? > >> > >> thanks > >> > > > > I agree on Mariano/Eliot solution. It is a good pragmatic short term workaround. > > In the long term, I wish I can say goodbye to my new super power, it's > > a too dangerous power. > > So I wish the VM would change (along with ClassBuilder and Tools). > > Yes, I agree. It just takes time to get there. > > > > > Nicolas > > > > Or maybe after reading: > > literal1 := self literalAt: numLits. > literal2 := method literalAt: numLits. > ^ (literal1 == literal2) or: [literal1 key isNil == literal2 key > isNil and: [literal1 value == literal2 value]]. > > I we are sure that the last literal is always an Association > > If it's not then one is playing fast and loose with the system. But if the method doesn't contain a super send then as far as the VM is concerned it doesn't need an association, and that might be the case with, for example, shared inst var accessors in Newspeak. So instead of assuming its an association write it something like > > ^literal1 class == literal2 class > and: [literal1 isVariableBinding > ifTrue: [literal1 key = literal2 key and: [literal1 value = literal2 value]] > ifFalse: [literal1 = literal2]] > > > Nicolas > > >> On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> > >>> Mariano > >>> > >>> So should we intgerate a fix? > >>> > >>> Stef > >>> > >>> On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: > >>> > >>> > > >>> > > >>> > > >>> > BUT, it doesn't mean that Association is always used for globals. > >>> > CompiledMethod equality is failing because of the last literal, the one that > >>> > maps class name (symbol) and point to the real class. So...when I > >>> > materialize, both CMs have non-identical associations for the last literal, > >>> > but equal. > >>> > > >>> > As Henrik says the last literals are ideally #== to each other. > >>> > However, no Squeak dialect makes any attempt to keep the class0side > >>> > associations equal. Look at a class-side method and you'll see it's last > >>> > literal is nil->SomeClass class. Now since this association doesn't exist > >>> > in Smalltalk (unlike last literals on the instance side) the compiler merely > >>> > creates distinct ones for each class-side method. > >>> > > >>> > > >>> > Thanks Eliot for that point. In fact, I have just checked and you are > >>> > right. The tests that are failing for me is those where class side methods > >>> > are involded. In this case, the last literal of the original CM and the > >>> > materialized, gives false in #literalEqual: hence, originalCM = > >>> > materializedCM is false :( > >>> > > >>> > > >>> > > >>> > Personally I don't think one can defend the position where method > >>> > equality is different for instance-side or class-side methods so there must > >>> > be some solutions: > >>> > > >>> > 1. special case comparison of the last literal (the methodClass > >>> > literal), comparing keys and insisting that the keys be #== and the values > >>> > be #== (can't just define it as keys #== since all similar class-side > >>> > methods will be equal irrespective of their actual class). > >>> > > >>> > > >>> > This one seems the easier and fixes my problem :) > >>> > > >>> > sameLiteralsAs: method > >>> > "Compare my literals to those of method. This is needed to compare > >>> > compiled methods." > >>> > > >>> > | numLits literal1 literal2 | > >>> > (numLits := self numLiterals) ~= method numLiterals > >>> > ifTrue: [ ^ false ]. > >>> > "The last literal requires special checking instead of using > >>> > #literalEqual:" > >>> > 1 to: numLits - 1 do: [ :index | > >>> > literal1 := self literalAt: index. > >>> > literal2 := method literalAt: index. > >>> > (literal1 == literal2 or: [ literal1 literalEqual: literal2 ]) > >>> > ifFalse: [ > >>> > (index = 1 and: [ #(117 120) includes: self primitive ]) > >>> > ifTrue: [ > >>> > literal1 isArray > >>> > ifTrue: [ > >>> > (literal2 isArray and: [ literal1 > >>> > allButLast = literal2 allButLast ]) > >>> > ifFalse: [ self halt. ^ false ] ] > >>> > ifFalse: [ > >>> > "ExternalLibraryFunction" > >>> > (literal1 analogousCodeTo: literal2) > >>> > ifFalse: [ self halt. ^ false ] ] ] > >>> > ifFalse: [ > >>> > index = (numLits - 1) > >>> > ifTrue: [ > >>> > "properties" > >>> > (self properties analogousCodeTo: method > >>> > properties) > >>> > ifFalse: [ self halt. ^ false ] ] > >>> > ifFalse: [ self halt. ^ false ] ] ] ]. > >>> > literal1 := self literalAt: numLits. > >>> > literal2 := method literalAt: numLits. > >>> > ^ ((literal1 key == literal2 key) and: [literal1 value == literal2 > >>> > value]). > >>> > > >>> > > >>> > > >>> > 2. special case comparison of the last literal (the methodClass > >>> > literal), insisting only that the class of the literal be the same if it > >>> > isVariableBinding. > >>> > > >>> > 3. make the compile unique class-side methodClass literals. i.e. if a > >>> > class already has a class-side method then the compiler or method dictionary > >>> > insertion code must find that existing association and reuse it > >>> > > >>> > Other ideas? > >>> > > >>> > >From my point of view, that literal, the last one does not need to be > >>> > identical to assume 2 CMs are equal. They just need to be equal. > >>> > > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > best, > >>> > Eliot > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > >> > > > > > > > -- > best, > Eliot >

Sept. 16, 2011

Re: [Pharo-project] Zodiac Alpha - September 13, 2011

by Sven Van Caekenberghe

> On 13 Sep 2011, at 22:41, StÃ©phane Ducasse wrote: > >> BTW we will start to write a chapter on zinc with olivier auverlot :) OK, more documentation is always better. If you have any questions, don't hesitate to mail me. But please don't rush to it: I am in the process of merging all Zn clients into one. It would be better to wait until then. On the other hand, if you just think of ZnNeoClient as being named ZnClient, you could already start. Sven

Sept. 16, 2011