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

Re: [Pharo-project] Vote for Kernel test: (Array allSubclasses size) = 0 [ Was: Re: FixedIdentitySet ... ]

by Nicolas Cellier

2009/12/23 Igor Stasenko <siguctua(a)gmail.com>: > 2009/12/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/12/23 Martin McClure <martin(a)hand2mouse.com>: >>> Nicolas Cellier wrote: >>>> >>>> While looking at it, FixedIdentitySet asArray ^ self, is this really expected ? >>> >>> FixedIdentitySet is a very odd beast. I'm afraid I don't see the value >>> of it at all, but I haven't looked at the code that uses it. >>> >>> Regards, >>> >>> -Martin >>> >> >> Yes, very bad example, only used in traits implementation and should >> be considered as private, so who ever use it should learn to not send >> asArray, nor any other inherited message but a few. >> I suspect inheriting basicAt: basicAt:put: and basicSize: should be >> enough, which completely disqualify the choice of superclass, but I >> won't bother more. >> Anyway, I'm impressed by (Array allSubclasses size), I would expect >> zero as a good number. >> > +1 > why its subclassing Array, why not Collection? > > I propose to vote for putting SUnit test, in Kernel tests: > > self assert: Â [ Array allSubclasses size = 0 ]. > -3 (it's not my vote, it's the evolution of number of subclasses since you posted) Nicolas > > -- > 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. 24, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by StÃ©phane Ducasse

> You get 227 classes used (over 3332 in total) these ones are nice to know Now just open a Morph to see or an inspector. Or typing some code Stef

Dec. 24, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Mariano Martinez Peck

On Thu, Dec 24, 2009 at 12:33 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > Taking that explanation in mind, we can follow this three steps: > > > > \begin{enumerate} > > \item Send the message {\em ImageSegment>>discoverActiveClasses} which > forces a MethodDictionary fault in all classes. Yes! It sends the message > {\em induceMDFault} to all classes except classes like Array Object Class > Message MethodDictionary. After this, all classes but those ones, will have > the {\em methodDict} with {\em nil}. > > \item Do a few things, use the system for a while. Maybe even save and > resume the image. > > \item Now, it is easy. All classes that still have a nil in the {\em > mehodDict} is because they were not used, and those who have something > different from {\em nil} is because they were. With the message {\em > ImageSegment>>activeClasses} you can restore all remaining MethodDictionary > faults and return the active classes. And with the message {\em > ImageSegment>>swapOutInactiveClasses} you can make up segments by grouping > unused classes by system category and write them to disk. > > > > A very important thing is that if you send the message {\em > discoverActiveClasses} you must then have to send the message {\em > activeClasses} or {\em swapOutInactiveClasses} because otherwise you will > have a lot of classes with the {\em methodDict} in {\em nil}. > > > > \end{enumerate} > > > > > > is it clear ? > > Yes. > So may be you should create an ImageSegment package and put the > faultDescription as class extensions to this package. > > Did you try to see what are the inactive classes you get after a full > coding sesssion with loading and saving code? > Yes, as expected, it doesn't work. Just looking for implementors for example, puts all classes as active (which make sense). > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Mariano Martinez Peck

On Thu, Dec 24, 2009 at 3:03 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2009/12/24 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Thu, Dec 24, 2009 at 12:33 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> > Taking that explanation in mind, we can follow this three steps: > >> > > >> > \begin{enumerate} > >> > \item Send the message {\em ImageSegment>>discoverActiveClasses} which > >> > forces a MethodDictionary fault in all classes. Yes! It sends the > message > >> > {\em induceMDFault} to all classes except classes like Array Object > Class > >> > Message MethodDictionary. After this, all classes but those ones, will > have > >> > the {\em methodDict} with {\em nil}. > >> > \item Do a few things, use the system for a while. Maybe even save and > >> > resume the image. > >> > \item Now, it is easy. All classes that still have a nil in the {\em > >> > mehodDict} is because they were not used, and those who have something > >> > different from {\em nil} is because they were. With the message {\em > >> > ImageSegment>>activeClasses} you can restore all remaining > MethodDictionary > >> > faults and return the active classes. And with the message {\em > >> > ImageSegment>>swapOutInactiveClasses} you can make up segments by > grouping > >> > unused classes by system category and write them to disk. > >> > > >> > A very important thing is that if you send the message {\em > >> > discoverActiveClasses} you must then have to send the message {\em > >> > activeClasses} or {\em swapOutInactiveClasses} because otherwise you > will > >> > have a lot of classes with the {\em methodDict} in {\em nil}. > >> > > >> > \end{enumerate} > >> > > >> > > >> > is it clear ? > >> > >> Yes. > >> So may be you should create an ImageSegment package and put the > >> faultDescription as class extensions to this package. > >> > >> Did you try to see what are the inactive classes you get after a full > >> coding sesssion with loading and saving code? > >> > > > > Yes, but the results is all classes are used, which of course is wrong. > > But...investigating a bit, the problem is here. Look this example: > > > > ByteString induceMDFault. > > self assert: (ByteString instVarNamed: 'methodDict') isNil > > > > That assert returns a failure!!! how is that posssible ? if the > > induceMDFault is setting methodDict nil . > > > > weird... > > > > > > Just a guess, I did not look at code, but couldn't it be that > instVarNamed: rely on String>>#= and thus resurrect the > methodDictionary ? > Maybe you should write: > self should: [ByteString instVarNamed: 'methodDict'] raise: MDFault > > Thanks Nicolas. Yes, something like that was happening. I don't know why I was so idiot and took ByteString as an example haha. Now I did some test. Just evaluating this (without any work on an image) ImageSegment discoverActiveClasses. ImageSegment activeClasses. You get 227 classes used (over 3332 in total) I will let this stuff running and work a couple of hours in a normal work and see how much classes do I use. Cheers, Mariano > > > > > >> > >> _______________________________________________ > >> 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. 24, 2009

Re: [Pharo-project] New pharo images

by Adrian Lienhard

We should just do the same as Marcus did in PharoCore 1.0. I guess it is StrikeFont installDejaVu. Adrian On Dec 24, 2009, at 13:15 , Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> Yes now we are just looking for the magic incanation to install >> them as title, code font.... >> > this is automatically done when you install them by pressing the > "Lauch" > button :) > If you want to launch it with a script: > StrikeFont installDejaVu > Alain > > >> Stef >> >> On Dec 24, 2009, at 11:44 AM, Alain Plantec wrote: >> >> >>> StÃ©phane Ducasse a Ã©crit : >>> >>>>> 2009/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>> >>>>>> Damien in 1.1 may be we should put the nice little font of Cuis >>>>>> on :) >>>>>> >>>>>> >>>>> Tell me what I should do. >>>>> >>>>> >>>> We should check the code of settings to see how the preferences >>>> is done >>>> when we press the launch button on the side of the install bitmap >>>> DejaVu fonts >>>> >>>> >>> I've checked, we have "bitmap dejavu sans" with sizes 7, 9 and 12. >>> Alain >>> >>> _______________________________________________ >>> 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. 24, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Nicolas Cellier

2009/12/24 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Dec 24, 2009 at 12:33 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> > Taking that explanation in mind, we can follow this three steps: >> > >> > \begin{enumerate} >> > \item Send the message {\em ImageSegment>>discoverActiveClasses} which >> > forces a MethodDictionary fault in all classes. Yes! It sends the message >> > {\em induceMDFault} to all classes except classes like Array Object Class >> > Message MethodDictionary. After this, all classes but those ones, will have >> > the {\em methodDict} with {\em nil}. >> > \item Do a few things, use the system for a while. Maybe even save and >> > resume the image. >> > \item Now, it is easy. All classes that still have a nil in the {\em >> > mehodDict} is because they were not used, and those who have something >> > different from {\em nil} is because they were. With the message {\em >> > ImageSegment>>activeClasses} you can restore all remaining MethodDictionary >> > faults and return the active classes. And with the message {\em >> > ImageSegment>>swapOutInactiveClasses} Â you can make up segments by grouping >> > unused classes by system category and write them to disk. >> > >> > A very important thing is that if you send the message {\em >> > discoverActiveClasses} Â you must then have to send the message {\em >> > activeClasses} or {\em swapOutInactiveClasses} Â because otherwise you will >> > have a lot of classes with the {\em methodDict} in {\em nil}. >> > >> > \end{enumerate} >> > >> > >> > is it clear ? >> >> Yes. >> So may be you should create an ImageSegment package and put the >> faultDescription as class extensions to this package. >> >> Did you try to see what are the inactive classes you get after a full >> coding sesssion with loading and saving code? >> > > Yes, but the results is all classes are used, which of course is wrong. > But...investigating a bit, the problem is here. Look this example: > > ByteString induceMDFault. > self assert: (ByteString instVarNamed: 'methodDict') isNil > > That assert returns a failure!!! how is that posssible ? if the > induceMDFaultÂ is setting methodDict nil . > > weird... > > Just a guess, I did not look at code, but couldn't it be that instVarNamed: rely on String>>#= and thus resurrect the methodDictionary ? Maybe you should write: self should: [ByteString instVarNamed: 'methodDict'] raise: MDFault > > >> >> _______________________________________________ >> 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. 24, 2009

[Pharo-project] Should re-post as top level (was Re: getting started with sound)

by Adrian Kuhn

Cameron Sanders <camsanders01@...> writes: > Not that I have finished any of the other projects that are of importance to > me... but I am wondering how/where to get started with sound. I have no idea > what capabilities already exist even though there is a long list of related > classes. Can I record from a mic and get the list of notes? etc. Guess your message ended up in the wrong thread. Try repost as top level message, ie create a fresh email and manually enter the address of the mailing list (if you reply to any mail from the list, your mail is included in the running thread and only few folks will notice it). --AA

Dec. 24, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by Mariano Martinez Peck

On Thu, Dec 24, 2009 at 12:33 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > Taking that explanation in mind, we can follow this three steps: > > > > \begin{enumerate} > > \item Send the message {\em ImageSegment>>discoverActiveClasses} which > forces a MethodDictionary fault in all classes. Yes! It sends the message > {\em induceMDFault} to all classes except classes like Array Object Class > Message MethodDictionary. After this, all classes but those ones, will have > the {\em methodDict} with {\em nil}. > > \item Do a few things, use the system for a while. Maybe even save and > resume the image. > > \item Now, it is easy. All classes that still have a nil in the {\em > mehodDict} is because they were not used, and those who have something > different from {\em nil} is because they were. With the message {\em > ImageSegment>>activeClasses} you can restore all remaining MethodDictionary > faults and return the active classes. And with the message {\em > ImageSegment>>swapOutInactiveClasses} you can make up segments by grouping > unused classes by system category and write them to disk. > > > > A very important thing is that if you send the message {\em > discoverActiveClasses} you must then have to send the message {\em > activeClasses} or {\em swapOutInactiveClasses} because otherwise you will > have a lot of classes with the {\em methodDict} in {\em nil}. > > > > \end{enumerate} > > > > > > is it clear ? > > Yes. > So may be you should create an ImageSegment package and put the > faultDescription as class extensions to this package. > > Did you try to see what are the inactive classes you get after a full > coding sesssion with loading and saving code? > > Yes, but the results is all classes are used, which of course is wrong. But...investigating a bit, the problem is here. Look this example: ByteString induceMDFault. self assert: (ByteString instVarNamed: 'methodDict') isNil That assert returns a failure!!! how is that posssible ? if the induceMDFault is setting methodDict nil . weird... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Traits-nice.248.mcz

by Adrian Lienhard

On Dec 24, 2009, at 11:53 , Nicolas Cellier wrote: > For Trait experts only. Actually, this is not related to Traits... For historical reasons the requires/provided algorithm by Nathanael (and Andrew Black and Daniel Vainsencher?) was added together with Traits to 3.9 and hence it ended up in the category 'Traits-Requires' and in the Traits package. I think we should fix this and move FixedIdentitySet into the collection hierarchy and the classes RequiredSelectors etal. to their own package. Are there any tools that use this data? Do we want to keep this in the image at all? Cheers, Adrian > > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/12/24 > Subject: [squeak-dev] The Trunk: Traits-nice.248.mcz > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > > > Nicolas Cellier uploaded a new version of Traits to project The Trunk: > http://source.squeak.org/trunk/Traits-nice.248.mcz > > ==================== Summary ==================== > > Name: Traits-nice.248 > Author: nice > Time: 24 December 2009, 11:49:10 am > UUID: 557593d7-1db7-2347-bf40-2d40e3b91f55 > Ancestors: Traits-nice.247 > > Move FixedIdentitySet off the Array hierarchy. > Provide a fast implementation using MethodDictionary tricks > - handles collisions (instead of blindly ignoring the entry) > - eventually grow. > > I did not understand previous design decision... > The conflict just did happen (I put a halt: and caught one in > Object...) > According to my own scale, make it work > make it fast. > > Rationale about the new design: > #grow costs, but I think it is user responsibility to fix a > reasonnable capacity. > collisions handling should not cost much (except above 4096 entries) > > If any expert knowing the reasons for this class and knowing how to > fire the profiling tests could have a look, thanks... > > =============== Diff against Traits-nice.247 =============== > > Item was changed: > + Collection variableSubclass: #FixedIdentitySet > + instanceVariableNames: 'tally capacity hashShift' > - Array variableSubclass: #FixedIdentitySet > - instanceVariableNames: 'tally capacity' > classVariableNames: '' > poolDictionaries: '' > category: 'Traits-Requires'! > > + !FixedIdentitySet commentStamp: 'nice 12/24/2009 11:46' prior: 0! > + This is a fast implementation of fixed size identity sets. > + Same algorithm as MethodDictionary are used, and thus > FixedIdentitySet is to IdentitySet what MethodDictionary is to > IdentityDictionary. > + The main features are: > + 1) do not use an array instance variable so as to fast-up creation > and every access > + 2) due to the fixed allocated size, growing costs an expensive > #become: operation. Preallocate me with care. > + 3) my size is a power of two so the the hashing algorithm be most > efficient. > + 4) for maximum random access efficiency, at least half the storage > area is always kept empty > - !FixedIdentitySet commentStamp: 'NS 5/26/2005 13:00' prior: 0! > - This is a fast but lazy implementation of fixed size identity sets. > The two main difference to regular identity sets are: > - > - 1) These identity sets have a fixed size. If they are full, adding > another element doesn't have any effect. > - 2) No rehashing. If two elements were to be stored on the same > position in the underlying array, one of them is simply discarded. > > + Unlike MethodDictionary, this class will scale a bit better over the > 4096 basicSize limit inherent to identityHash, thanks to a proper > bitShift.! > - As a consequence of (1) and (2), these identity sets are very fast!! > Note that this class inherits form Array. This is not clean but > reduces memory overhead when instances are created.! > > Item was added: > + ----- Method: FixedIdentitySet>>removeAll (in category 'removing') > ----- > + removeAll > + tally = 0 ifTrue: [^self]. > + 1 to: self basicSize do: [:i | self basicAt: i put: nil]. > + tally := 0! > > Item was changed: > + ----- Method: FixedIdentitySet>>add: (in category 'adding') ----- > - ----- Method: FixedIdentitySet>>add: (in category 'accessing') ----- > add: anObject > + | index | > + index := self scanFor: anObject. > + (self basicAt: index) > + ifNil: [ > + self basicAt: index put: anObject. > + tally := tally + 1. > + self isFull ifTrue: [ self grow ]] > + "ifNotNil: [] already inside". > + ^anObject! > - | index old | > - self isFull ifTrue: [^ false]. > - index := self indexOf: anObject. > - old := self basicAt: index. > - old == anObject ifTrue: [^ true]. > - old ifNotNil: [^ false]. > - self basicAt: index put: anObject. > - tally := tally + 1. > - ^ true! > > Item was changed: > + ----- Method: FixedIdentitySet>>addAll:notIn: (in category > 'adding') ----- > - ----- Method: FixedIdentitySet>>addAll:notIn: (in category > 'accessing') ----- > addAll: aCollection notIn: notCollection > aCollection do: [:each | > - self isFull ifTrue: [^ self]. > (notCollection includes: each) ifFalse: [self add: > each]. > ].! > > Item was changed: > ----- Method: FixedIdentitySet class>>with:with:with:with:with: (in > category 'instance creation') ----- > with: firstObject with: secondObject with: thirdObject with: > fourthObject with: fifthObject > "Answer an instance of me, containing the five arguments as the > elements." > > + ^ (self new: 5) > - ^ self new > add: firstObject; > add: secondObject; > add: thirdObject; > add: fourthObject; > add: fifthObject; > yourself! > > Item was changed: > ----- Method: FixedIdentitySet class>>with:with:with:with:with:with: > (in category 'instance creation') ----- > with: firstObject with: secondObject with: thirdObject with: > fourthObject with: fifthObject with: sixthObject > "Answer an instance of me, containing the six arguments as > the elements." > > + ^ (self new: 6) > - ^ self new > add: firstObject; > add: secondObject; > add: thirdObject; > add: fourthObject; > add: fifthObject; > add: sixthObject; > yourself! > > Item was changed: > + ----- Method: FixedIdentitySet class>>new (in category 'instance > creation') ----- > - ----- Method: FixedIdentitySet class>>new (in category > 'constants') ----- > new > ^ self new: self defaultSize! > > Item was added: > + ----- Method: FixedIdentitySet>>grow (in category 'private') ----- > + grow > + | newSelf | > + newSelf := self species new: capacity * 2. "This will double > the capacity" > + self do: [ :anObject | newSelf add: anObject ]. > + self become: newSelf! > > Item was changed: > + ----- Method: FixedIdentitySet>>includes: (in category 'testing') > ----- > + includes: aSymbol > + "This override assumes that pointsTo is a fast primitive" > + > + aSymbol ifNil: [^ false]. > + ^ self pointsTo: aSymbol! > - ----- Method: FixedIdentitySet>>includes: (in category > 'accessing') ----- > - includes: anObject > - ^ (self basicAt: (self indexOf: anObject)) == anObject! > > Item was added: > + ----- Method: FixedIdentitySet>>fixCollisionsFrom: (in category > 'private') ----- > + fixCollisionsFrom: start > + "The element at start has been removed and replaced by nil. > + This method moves forward from there, relocating any entries > + that had been placed below due to collisions with this one." > + > + | key index mask | > + index := start. > + mask := self basicSize - 1. > + [ (key := self basicAt: (index := (index bitAnd: mask) + 1)) > == nil ] whileFalse: [ > + | newIndex | > + (newIndex := self scanFor: key) = index ifFalse: [ > + | element | > + element := self basicAt: index. > + self basicAt: index put: (self basicAt: > newIndex). > + self basicAt: newIndex put: element.] ]! > > Item was changed: > + ----- Method: FixedIdentitySet class>>new: (in category 'instance > creation') ----- > - ----- Method: FixedIdentitySet class>>new: (in category > 'constants') ----- > new: anInteger > + ^ (self basicNew: (self arraySizeForCapacity: anInteger)) > initializeCapacity: anInteger! > - ^ (super new: (self arraySizeForCapacity: anInteger)) > initializeCapacity: anInteger! > > Item was changed: > + ----- Method: FixedIdentitySet>>remove:ifAbsent: (in category > 'removing') ----- > - ----- Method: FixedIdentitySet>>remove:ifAbsent: (in category > 'accessing') ----- > remove: anObject ifAbsent: aBlock > + | index element | > + index := self scanFor: anObject. > + (element := self basicAt: index) ifNil: [ ^aBlock value ]. > + self basicAt: index put: nil. > + tally := tally - 1. > + self fixCollisionsFrom: index. > + ^element! > - | index | > - index := self indexOf: anObject. > - ^ (self basicAt: index) == anObject > - ifTrue: [self basicAt: index put: nil. tally := tally > - 1. anObject] > - ifFalse: [aBlock value].! > > Item was added: > + ----- Method: FixedIdentitySet>>rehash (in category 'private') ----- > + rehash > + | newSelf | > + newSelf := self species new: self size. > + self do: [ :anObject | newSelf add: anObject ]. > + ^newSelf! > > Item was changed: > ----- Method: FixedIdentitySet>>initializeCapacity: (in category > 'initialize-release') ----- > initializeCapacity: anInteger > tally := 0. > + capacity := anInteger. > + hashShift := self basicSize highBit - 4096 highBit max: 0! > - capacity := anInteger.! > > Item was changed: > + ----- Method: FixedIdentitySet class>>arraySizeForCapacity: (in > category 'private') ----- > - ----- Method: FixedIdentitySet class>>arraySizeForCapacity: (in > category 'constants') ----- > arraySizeForCapacity: anInteger > "Because of the hash performance, the array size is always a > power of 2 > and at least twice as big as the capacity anInteger" > > ^ anInteger <= 0 > ifTrue: [0] > ifFalse: [1 << (anInteger << 1 - 1) highBit].! > > Item was added: > + ----- Method: FixedIdentitySet>>scanFor: (in category 'private') > ----- > + scanFor: anObject > + "Scan the key array for the first slot containing either a nil > (indicating an empty slot) or an element that matches anObject. Answer > the index of that slot or raise an error if no slot is found. This > method will be overridden in various subclasses that have different > interpretations for matching elements." > + > + | index start mask | > + anObject ifNil: [self error: 'This class collection cannot > handle nil as an element']. > + mask := self basicSize - 1. > + index := start := ((anObject identityHash bitShift: hashShift) > bitAnd: mask) + 1. > + [ > + | element | > + ((element := self basicAt: index) == nil or: [ element > == anObject ]) > + ifTrue: [ ^index ]. > + (index := (index bitAnd: mask) + 1) = start ] > whileFalse. > + self errorNoFreeSpace! > > Item was removed: > - ----- Method: FixedIdentitySet>>destructiveAdd: (in category > 'accessing') ----- > - destructiveAdd: anObject > - | index old | > - self isFull ifTrue: [^ false]. > - index := self indexOf: anObject. > - old := self basicAt: index. > - self basicAt: index put: anObject. > - old ifNil: [tally := tally + 1]. > - ^ true! > > Item was removed: > - ----- Method: FixedIdentitySet>>notFull (in category 'testing') > ----- > - notFull > - ^ tally < capacity! > > Item was removed: > - ----- Method: FixedIdentitySet>>addAll: (in category 'accessing') > ----- > - addAll: aCollection > - aCollection do: [:each | > - self isFull ifTrue: [^ self]. > - self add: each. > - ].! > > Item was removed: > - ----- Method: FixedIdentitySet>>indexOf: (in category 'private') > ----- > - indexOf: anObject > - anObject isNil ifTrue: [self error: 'This class collection > cannot handle nil as an element']. > - ^ (anObject identityHash bitAnd: self basicSize - 1) + 1! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 24, 2009

Re: [Pharo-project] New pharo images

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Yes now we are just looking for the magic incanation to install them as title, code font.... > this is automatically done when you install them by pressing the "Lauch" button :) If you want to launch it with a script: StrikeFont installDejaVu Alain > Stef > > On Dec 24, 2009, at 11:44 AM, Alain Plantec wrote: > > >> StÃ©phane Ducasse a Ã©crit : >> >>>> 2009/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> >>>>> Damien in 1.1 may be we should put the nice little font of Cuis on :) >>>>> >>>>> >>>> Tell me what I should do. >>>> >>>> >>> We should check the code of settings to see how the preferences is done >>> when we press the launch button on the side of the install bitmap DejaVu fonts >>> >>> >> I've checked, we have "bitmap dejavu sans" with sizes 7, 9 and 12. >> Alain >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >

Dec. 24, 2009