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

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

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

by Michael Roberts

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 >

Dec. 25, 2009

Re: [Pharo-project] need hunter to kill the double paste bug.

by Mariano Martinez Peck

On Fri, Dec 25, 2009 at 8:20 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Christmas greetings everyone, as I await the cooking of the turkey and > observe the teenagers here plot the spending of > their Christmas money I see in my in-box Michael has sent me a rewrite of > the HostMenu system. > > I've sent back a few changes, and maybe in the next day or so when Michael > gets back to work and lets us know how to > load these changes could we get some folks who have experienced the > double-paste bug to spent a few moments attempting the > recreation of the bug. > > John: Cool to hear that you are trying to fix this bug. I can reproduce it very easy fortunately, so, let me know I can test as much as necessary. I would like to put a RFB or VNC but I am "unaccesible" from outside :( cheers, Mariano > Unfortunately Michael and I are unable to recreate the problem, which makes > it hard to debug. > > > > On 2009-12-20, at 1:14 AM, Michael Rueger wrote: > > > Lukas Renggli wrote: > >> Another thing, this is not something that is only related to the > >> clipboard. I've seen a similar thing happen when I use a keyboard > >> shortcut that opens a dialog. In some cases the initial selection of a > >> text-field is replaced by the keyboard shortcuts character, e.g. > >> pressing Ctrl+x to delete a method inserts sometimes the x into the > >> confirmation dialog. > > > > Hmm, so it seems to be a general problem with short cuts on the Mac? > > > > But, as much as I try on my MiniMac with SnowLeopard, I can't reproduce > > it. (in a core image) > > > > Michael > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > 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