- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 1692: MNU when tried to navigate pop up menus with the keyboard

by Francisco Ortiz PeÃ±aloza

Pharo image: Pharo-core Pharo core version: PharoCore1.1ALPHA Latest update: #11116 Virtual machine used: Squeak 4.2.2beta1U | Cocoa Squeak 5.0.0b9 64*32 Steps to reproduce: 1. Open a pop up using your mouse o pressing <esc> 2. Try to select an action using your keyboard. Enter text to narrow down your matching items or using the arrow keys, neither work anymore. Francisco

Dec. 25, 2009

[Pharo-project] 1694 ready to integrate

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=1694 SLICE-issue1694-newTestsToProtoObject-MarianoMartinezPeck.2 En PharoInbox. After this update you should have 10 tests in ProtoObjectTest and all green. (before only 2 tests). Cheers, Mariano

Dec. 25, 2009

Re: [Pharo-project] Need Levente Uzonyi license

by Nicolas Cellier

2009/12/25 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 25 Dec 2009, Mariano Martinez Peck wrote: > >> Hi Levente: I would like to integrate some of your code (most changes to >> squeak) but as you may know, any code commited to Pharo must be MIT license >> and we need the sign of the author (http://www.pharo-project.org/license) >> >> Would you mind to send it ? >> >> Thank you very much. >> >> Mariano >> > > Since you're about to take code from an MIT licensed repository this is > superfluous. > > > Levente > I second this. Please take the code from trunk without asking. If Levente ever had to sign an agreement, it should only apply to code commited by Levente to a Pharo repository... ...unless you request that each code commited by Levente anywhere anytime be MIT ;) Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 25, 2009

Re: [Pharo-project] Need Levente Uzonyi license

by Levente Uzonyi

On Fri, 25 Dec 2009, Mariano Martinez Peck wrote: > Hi Levente: I would like to integrate some of your code (most changes to > squeak) but as you may know, any code commited to Pharo must be MIT license > and we need the sign of the author (http://www.pharo-project.org/license) > > Would you mind to send it ? > > Thank you very much. > > Mariano > Since you're about to take code from an MIT licensed repository this is superfluous. Levente

Dec. 25, 2009

Re: [Pharo-project] Point name Point class name are not both symbol

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > I was wondering if it would make sense to have > Point name > Point class name > both returning a symbol and not in one case a symbol and the other a > string. To my understanding, the role of a symbol is to be a speed-optimized identifier (of either a class or method) and #'Point class' is not an identifier but an expression which does not evaluate faster when being a symbol. Also creating too many symbols might harm system performance. I learned that the hard way with Moose, it used to use symbols everywhere and eventually it would take 10 seconds to open autocompletion. So I am always reluctant to make too many symbols. --AA

Dec. 25, 2009

Re: [Pharo-project] about resetTo: in newFrom:

by Levente Uzonyi

On Fri, 25 Dec 2009, Henrik Sperre Johansen wrote: > In the changes I did to OrderedCollection back at ESUG (but never > finished :/), I simply removed resetTo:, and changed the default to do > reset to 1, for the same reasons Levente posted. IMO #resetTo: is useful and should not be private, it has senders too. #reset is less useful since it's just resetTo: (array size // 3 max: 1). OrderedCollection can be improved in the following two ways: 1. don't use #reset, but #resetTo: 1 in #setCollection: 2. Fix #makeRoomAtFirst and #makeRoomAtLast to leave free space on both sides, these to methods can probably be further improved. The first version doesn't support (with good performance) addition to both sides, the second does, but has some space overhead. So the question is: should OrderedCollection support additions to both ends with good performance? Levente > > Cheers, > Henry > > On 25.12.2009 22:05, StÃ©phane Ducasse wrote: >> ok thanks >> I see the implementation was smart. >> >> Stef >> On Dec 25, 2009, at 7:46 PM, Levente Uzonyi wrote: >> >> >>> On Fri, 25 Dec 2009, StÃ©phane Ducasse wrote: >>> >>> >>>> Hi levente >>>> >>>> Reading your changes I was wondering if resetTo: should not be moved into OrderedCollection class>> new: >>>> and why only have it for the default new? >>>> >>> The patch below had the purpose to speed up #asOrderedCollection in general. But I think #resetTo: can be moved to #new: or even to #setCollection: on the instance side, since I don't see any benefit for using array size // 3 for firstIndex. I guess the original idea was to leave enough space on both sides of the array, so adding to both sides has good performance, though in general this is not the case, because #makeRoomAtFirst and #makeRoomAtLast doesn't leave space on both sides. >>> >>> o := OrderedCollection new. >>> [ >>> 1 to: 10000 do: [ :each | >>> o >>> addFirst: each; >>> addFirst: each ] ] timeToRun ===> 4 >>> >>> o := OrderedCollection new. >>> [ >>> 1 to: 10000 do: [ :each | >>> o >>> addLast: each; >>> addLast: each ] ] timeToRun ===> 3 >>> >>> o := OrderedCollection new. >>> [ >>> 1 to: 10000 do: [ :each | >>> o >>> addFirst: each; >>> addLast: each ] ] timeToRun ===> 20067 >>> >>> >>> Levente >>> >>> >>>> OrderedCollection class>>newFrom: aCollection >>>> "Answer an instance of me containing the same elements as aCollection." >>>> >>>> + ^(self new: aCollection size) >>>> + resetTo: 1; >>>> + addAll: aCollection; >>>> + yourself >>>> - | newCollection | >>>> - newCollection := self new: aCollection size. >>>> - newCollection addAll: aCollection. >>>> - ^newCollection >>>> >>>> I did >>>> OrderedCollection new: 100. >>>> and contrary to what I expected firstIndex is not 1 but 33. >>>> Now when you add resetTo: 1 firstIndex get 1. >>>> >>>> new: anInteger >>>> "Create a collection with enough room allocated to contain up to anInteger elements. >>>> The new instance will be of size 0 (allocated room is not necessarily used)." >>>> ^self basicNew setCollection: (Array new: anInteger) >>>> >>>> setCollection: anArray >>>> array := anArray. >>>> self reset >>>> >>>> reset >>>> firstIndex := array size // 3 max: 1. >>>> lastIndex := firstIndex - 1 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 25, 2009

Re: [Pharo-project] about resetTo: in newFrom:

by Henrik Sperre Johansen

In the changes I did to OrderedCollection back at ESUG (but never finished :/), I simply removed resetTo:, and changed the default to do reset to 1, for the same reasons Levente posted. Cheers, Henry On 25.12.2009 22:05, StÃ©phane Ducasse wrote: > ok thanks > I see the implementation was smart. > > Stef > On Dec 25, 2009, at 7:46 PM, Levente Uzonyi wrote: > > >> On Fri, 25 Dec 2009, StÃ©phane Ducasse wrote: >> >> >>> Hi levente >>> >>> Reading your changes I was wondering if resetTo: should not be moved into OrderedCollection class>> new: >>> and why only have it for the default new? >>> >> The patch below had the purpose to speed up #asOrderedCollection in general. But I think #resetTo: can be moved to #new: or even to #setCollection: on the instance side, since I don't see any benefit for using array size // 3 for firstIndex. I guess the original idea was to leave enough space on both sides of the array, so adding to both sides has good performance, though in general this is not the case, because #makeRoomAtFirst and #makeRoomAtLast doesn't leave space on both sides. >> >> o := OrderedCollection new. >> [ >> 1 to: 10000 do: [ :each | >> o >> addFirst: each; >> addFirst: each ] ] timeToRun ===> 4 >> >> o := OrderedCollection new. >> [ >> 1 to: 10000 do: [ :each | >> o >> addLast: each; >> addLast: each ] ] timeToRun ===> 3 >> >> o := OrderedCollection new. >> [ >> 1 to: 10000 do: [ :each | >> o >> addFirst: each; >> addLast: each ] ] timeToRun ===> 20067 >> >> >> Levente >> >> >>> OrderedCollection class>>newFrom: aCollection >>> "Answer an instance of me containing the same elements as aCollection." >>> >>> + ^(self new: aCollection size) >>> + resetTo: 1; >>> + addAll: aCollection; >>> + yourself >>> - | newCollection | >>> - newCollection := self new: aCollection size. >>> - newCollection addAll: aCollection. >>> - ^newCollection >>> >>> I did >>> OrderedCollection new: 100. >>> and contrary to what I expected firstIndex is not 1 but 33. >>> Now when you add resetTo: 1 firstIndex get 1. >>> >>> new: anInteger >>> "Create a collection with enough room allocated to contain up to anInteger elements. >>> The new instance will be of size 0 (allocated room is not necessarily used)." >>> ^self basicNew setCollection: (Array new: anInteger) >>> >>> setCollection: anArray >>> array := anArray. >>> self reset >>> >>> reset >>> firstIndex := array size // 3 max: 1. >>> lastIndex := firstIndex - 1 >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Dec. 25, 2009

Re: [Pharo-project] [update 1.1] #11115

by StÃ©phane Ducasse

we can keep alpha for us and just have the name of the image tagged UNSTABLE because else we may have to change the update list and so on. So I would not do more than I did because we can spend good energy on something else. Stef On Dec 25, 2009, at 8:53 PM, Michael Roberts wrote: > re: #1624 > > you need to do this ;-) > > SystemVersion current suffix: 'UNSTABLE' > > thanks, > Mike > > On Fri, Dec 25, 2009 at 10:50 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> 11115 >> ----- >> >> Issue 1683: From The Trunk: minor improvement of MethodDictionary>>includesKey: >> N. Cellier and Traits :) >> Issue 1664: Long method can not be compiled using #compile: aString >> Issue 1158: System Browser vs Class Browser tx David R. >> Issue 1624: 1.1#alpha should be renamed to 1.1#unstable >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

Re: [Pharo-project] about resetTo: in newFrom:

by StÃ©phane Ducasse

ok thanks I see the implementation was smart. Stef On Dec 25, 2009, at 7:46 PM, Levente Uzonyi wrote: > On Fri, 25 Dec 2009, StÃ©phane Ducasse wrote: > >> Hi levente >> >> Reading your changes I was wondering if resetTo: should not be moved into OrderedCollection class >> new: >> and why only have it for the default new? > > The patch below had the purpose to speed up #asOrderedCollection in general. But I think #resetTo: can be moved to #new: or even to #setCollection: on the instance side, since I don't see any benefit for using array size // 3 for firstIndex. I guess the original idea was to leave enough space on both sides of the array, so adding to both sides has good performance, though in general this is not the case, because #makeRoomAtFirst and #makeRoomAtLast doesn't leave space on both sides. > > o := OrderedCollection new. > [ > 1 to: 10000 do: [ :each | > o > addFirst: each; > addFirst: each ] ] timeToRun ===> 4 > > o := OrderedCollection new. > [ > 1 to: 10000 do: [ :each | > o > addLast: each; > addLast: each ] ] timeToRun ===> 3 > > o := OrderedCollection new. > [ > 1 to: 10000 do: [ :each | > o > addFirst: each; > addLast: each ] ] timeToRun ===> 20067 > > > Levente > >> >> OrderedCollection class >>newFrom: aCollection >> "Answer an instance of me containing the same elements as aCollection." >> >> + ^(self new: aCollection size) >> + resetTo: 1; >> + addAll: aCollection; >> + yourself >> - | newCollection | >> - newCollection := self new: aCollection size. >> - newCollection addAll: aCollection. >> - ^newCollection >> >> I did >> OrderedCollection new: 100. >> and contrary to what I expected firstIndex is not 1 but 33. >> Now when you add resetTo: 1 firstIndex get 1. >> >> new: anInteger >> "Create a collection with enough room allocated to contain up to anInteger elements. >> The new instance will be of size 0 (allocated room is not necessarily used)." >> ^self basicNew setCollection: (Array new: anInteger) >> >> setCollection: anArray >> array := anArray. >> self reset >> >> reset >> firstIndex := array size // 3 max: 1. >> lastIndex := firstIndex - 1 >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

[Pharo-project] Need Levente Uzonyi license

by Mariano Martinez Peck

Hi Levente: I would like to integrate some of your code (most changes to squeak) but as you may know, any code commited to Pharo must be MIT license and we need the sign of the author (http://www.pharo-project.org/license) Would you mind to send it ? Thank you very much. Mariano

Dec. 25, 2009