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

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

by John M McIntosh

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

Dec. 25, 2009

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

by Igor Stasenko

2009/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I'm just developing a real package class. > And I keep class names because the classBuilder can recreate class instances under my foot.... > So I can do > Â Â Â Â aPack addClassNamed: aName > > Â Â Â Â aPack addClass: aClass Â (my favorite solution) > i made own draft package classes, and my favorite is: add: object "Add object to receiver contents" (self includes: object) ifTrue: [ ^ object ]. (self canInclude: object) ifFalse: [ ^ self error: 'Given object can''t be included into package' ]. ^ contents add: object. ;) If you want , i can send you the code, maybe some of my ideas would be useful. > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 25, 2009

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

by Levente Uzonyi

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 >

Dec. 25, 2009

Re: [Pharo-project] #sortBlock:

by StÃ©phane Ducasse

> I'm pretty sure John was going to add #sort: at the level of > SequenceableCollection. As I mentioned, it is implemented in terms of > #at:put: and therefore errors reasonably on Interval. Ok Now Pharo has it :) But not yet sorted. > > We might require a special implementation for SortedCollection, > alright. I don't see why that would be a problem for them. > > Julian > > On Fri, Dec 25, 2009 at 1:08 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> ouf honor is safe :) >> So try to convince VA to do a better job than ANSI. >> because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution >> >> Stef >> >> >>>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>>>>> be implemented on non-sorted collections. >>>>>>>> >>>>>>>> Why? what would be the reason not to use sortBlock: for others? >>>>>>> >>>>>>> The intention is different. #sortBlock: tells a collection to maintain >>>>>>> itself as sorted even after additions and deletions. This message is not >>>>>>> appropriate for collections that do not have that ability. >>>>>>> >>>>>>> #sortBlock: is not the best name for this functionality, but I think >>>>>>> it's bad to use #sortBlock: with a different meaning. >>>>>> >>>>>> I agree :) >>>>>> Now SortedCollection should understand sort too which uses sortBlock: >>>>>> My main concern is polymorphism between collection which are nearly the same! >>>>> >>>>> #sortBlock: is an accessor for the sortBlock instance variable on >>>>> SortedCollection. It makes no sense for a collection that doesn't have >>>>> that instance variable to have that accessor. >>>> >>>> did I say that? I do not think so. I'm not that idiot. >>>> No I say that SortedCollection should understand sort: >>> >>> Ah, apologies - I misunderstood what you were saying (I was a little >>> surprised that you would be arguing what I thought you were arguing :) >>> ). >>> >>> Julian >>> >>> _______________________________________________ >>> 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] Point name Point class name are not both symbol

by StÃ©phane Ducasse

I'm just developing a real package class. And I keep class names because the classBuilder can recreate class instances under my foot.... So I can do aPack addClassNamed: aName aPack addClass: aClass (my favorite solution) Stef

Dec. 25, 2009

Re: [Pharo-project] #sortBlock:

by Levente Uzonyi

On Fri, 25 Dec 2009, Julian Fitzell wrote: > I'm pretty sure John was going to add #sort: at the level of > SequenceableCollection. As I mentioned, it is implemented in terms of > #at:put: and therefore errors reasonably on Interval. > Interval was just an example. Moving #sort: to SequenceableCollection requires some changes in it's subclasses: - ArrayedCollection (OK, nothing to do) - LinkedList (Link is too general, a sort algorithm has to make assumptions about the links, requires a new implementation of mergesort) - OrderedCollection (OK, easy to fix) - Interval (OK, can't be sorted. Some errors can be avioded though.) - SourceFileArray (who cares, it should be nuked anyway) - Heap (it raises an error in response to #at:put:, but it can be sorted...) - NSCollectionLimiter (?) So the question is: what to do with LinkedList and Heap? Levente > We might require a special implementation for SortedCollection, > alright. I don't see why that would be a problem for them. > > Julian > > On Fri, Dec 25, 2009 at 1:08 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> ouf honor is safe :) >> So try to convince VA to do a better job than ANSI. >> because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution >> >> Stef >> >> >>>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>>>>> be implemented on non-sorted collections. >>>>>>>> >>>>>>>> Why? what would be the reason not to use sortBlock: for others? >>>>>>> >>>>>>> The intention is different. #sortBlock: tells a collection to maintain >>>>>>> itself as sorted even after additions and deletions. This message is not >>>>>>> appropriate for collections that do not have that ability. >>>>>>> >>>>>>> #sortBlock: is not the best name for this functionality, but I think >>>>>>> it's bad to use #sortBlock: with a different meaning. >>>>>> >>>>>> I agree :) >>>>>> Now SortedCollection should understand sort too which uses sortBlock: >>>>>> My main concern is polymorphism between collection which are nearly the same! >>>>> >>>>> #sortBlock: is an accessor for the sortBlock instance variable on >>>>> SortedCollection. It makes no sense for a collection that doesn't have >>>>> that instance variable to have that accessor. >>>> >>>> did I say that? I do not think so. I'm not that idiot. >>>> No I say that SortedCollection should understand sort: >>> >>> Ah, apologies - I misunderstood what you were saying (I was a little >>> surprised that you would be arguing what I thought you were arguing :) >>> ). >>> >>> Julian >>> >>> _______________________________________________ >>> 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] #sortBlock:

by Julian Fitzell

I'm pretty sure John was going to add #sort: at the level of SequenceableCollection. As I mentioned, it is implemented in terms of #at:put: and therefore errors reasonably on Interval. We might require a special implementation for SortedCollection, alright. I don't see why that would be a problem for them. Julian On Fri, Dec 25, 2009 at 1:08 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ouf honor is safe :) > So try to convince VA to do a better job than ANSI. > because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution > > Stef > > >>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>>>> be implemented on non-sorted collections. >>>>>>> >>>>>>> Why? what would be the reason not to use sortBlock: for others? >>>>>> >>>>>> The intention is different. #sortBlock: tells a collection to maintain >>>>>> itself as sorted even after additions and deletions. This message is not >>>>>> appropriate for collections that do not have that ability. >>>>>> >>>>>> #sortBlock: is not the best name for this functionality, but I think >>>>>> it's bad to use #sortBlock: with a different meaning. >>>>> >>>>> I agree :) >>>>> Now SortedCollection should understand sort too which uses sortBlock: >>>>> My main concern is polymorphism between collection which are nearly the same! >>>> >>>> #sortBlock: is an accessor for the sortBlock instance variable on >>>> SortedCollection. It makes no sense for a collection that doesn't have >>>> that instance variable to have that accessor. >>> >>> did I say that? I do not think so. I'm not that idiot. >>> No I say that SortedCollection should understand sort: >> >> Ah, apologies - I misunderstood what you were saying (I was a little >> surprised that you would be arguing what I thought you were arguing :) >> ). >> >> Julian >> >> _______________________________________________ >> 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] Point name Point class name are not both symbol

by Igor Stasenko

2009/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> The need to have class names comes from using the global namespace: >> >> (Smalltalk at: ConsistentClass name) == ConsistentClass >> >> metaclasses is not part of global namespace and therefore don't >> required to have some constraints in >> while answering #name message. >> >> Actually, it could answer 'ClassName metaclass' , or just 'a Metaclass' >> any form is acceptable. > > No what you are saying is dogmatic. Nope. Its anti-dogmatic. I'm not putting any expectations on what #name of metaclass should answer. > So far the metamodel of smalltalk is simple just class, packages does not even exist > but as soons as you want to have a way to manipulate classes, you can manipulate metaclass > and I do not know you but me I like when I want a class extension on a metaclass that it does > not end up on the instance side. > I don't see a straight correspondence of this with #name implementation. Sure thing, i am both hands for easy & flexible manipulation of classes & metaclasses. So, maybe let's duscuss, what problem you encountered, and try to pick best solution(s). As i understand you trying to build a class meta-model in memory, but don't want to expose it to system, until it will be ready for installing. >> I'd rather punish those, who in own code expecting that metaclasses >> should answer something which can be parsed for detecting a class >> name! -- Best regards, Igor Stasenko AKA sig.

Dec. 25, 2009

Re: [Pharo-project] Issue 1690: New method trailer format for Pharo

by StÃ©phane Ducasse

thanks. I must fix my house...... and I will try to get some time for them stef On Dec 25, 2009, at 5:30 PM, Igor Stasenko wrote: > I reviewed the trailers changesets and adopted them for Pharo.. > > Please, tell me how it goes. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] Point name Point class name are not both symbol

by StÃ©phane Ducasse

>> > Because the right form of accessing the name of class is: > > classOrMetaClass theClassSide name > > and right form of testing if behavior is metaclass is > > object isBehavior and: [ object isMeta ] > > but not: > > object name endsWith:'class' indeed now what do you do if you do not want to have to load a class in memory to manipulate a group of them like a package... you end up doing pseudoClass.... why not but there is nothing that is that dogmatic. Stef

Dec. 25, 2009