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

Re: [Pharo-project] Help with a WeakOrderedCollection and objects not being GCed

by StÃ©phane Ducasse

How can we test and make sure that in the future we know automatically if the weak is broken? Stef On Aug 3, 2011, at 1:01 PM, Nicolas Cellier wrote: > You replace Array with self arrayType, that's all. > But there is better, Pharo already has growAtFirst and growAtLast > which are correct. > Use them instead of grow. > See SLICE in inbox. > > Nicolas > > 2011/8/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> btw...how can I change OrderedCollection>>grow >> without shooting my foots? >> >> On Wed, Aug 3, 2011 at 12:51 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Wed, Aug 3, 2011 at 12:42 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> I'm pretty sure the array inst var of your WeakOrderedColleciton is no >>>> more a WeakArray but a simple Array. >>> >>> Yes, indeed, it is a normal Array and that cought my attention. But since >>> I have no idea about Weak stuff...I also noticed that WeakOrderedCollection >>> is declared as: >>> >>> OrderedCollection subclass: #WeakOrderedCollection >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Collections-Weak' >>> >>> instead of using the #weakSubclass: ... message: >>> >>> OrderedCollection weakSubclass: #WeakOrderedCollection >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Collections-Weak' >>> >>> >>>> >>>> This is because Pharo's WeakOrderedCollection is broken... >>>> >>> >>> Do you know a weak collection that is not broken in Pharo and let me do a >>> addLast: ? >>> >>>> >>>> Every reference to Array from within OrderedCollection should be >>>> replaced with message send (self arrayType). >>>> See for example, OrderedCollection>>#grow >>>> >>> >>> Thanks. I will check how many there are and try to fix them. >>> >>>> >>>> Nicolas >>>> >>>> 2011/8/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> Hi guys. I am since yesterday trying to find something and I cannot. So >>>>> at >>>>> this point I need external eyes :) >>>>> I have this little code: >>>>> >>>>> anObject := ClassWith2Var new. >>>>> sharedObject := ClassWith1Var new. >>>>> sharedObject var1: 'nose'. >>>>> anObject var1: Date today. >>>>> anObject var2: sharedObject. >>>>> >>>>> serializedObjects := FuelMareaSerializer new >>>>> serializeAndWriteObject: >>>>> anObject to: 'aFileName'. >>>>> anObject := nil. >>>>> sharedObject := nil. >>>>> >>>>> 3 timesRepeat: [Smalltalk garbageCollect]. >>>>> serializedObjects inspect. >>>>> >>>>> >>>>> >>>>> What is important here is that FuelMareaSerializer new >>>>> serializeAndWriteObject: anObject to: 'aFileName' answers a >>>>> WeakOrderedCollection with each object of the serialized graph (taking >>>>> anObject as the root) >>>>> Now, if I print the tempVar serializedObjects I see: >>>>> >>>>> a WeakOrderedCollection(ClassWith1Var ClassWith2Var Date DateAndTime >>>>> Duration a ClassWith1Var a ClassWith2Var 3 August 2011 >>>>> 2011-08-03T00:00:00+02:00 0:02:00:00 1:00:00:00 86400 2455777 'nose' 0 >>>>> 7200) >>>>> >>>>> WHYYYY?? why are all there if I put a nil to both, anObject and >>>>> sharedObejct. This WeakOrderedCollection should be with all nils >>>>> (except >>>>> classes). Why are not being garbage collected? >>>>> >>>>> If I explore, for example the tempVar sharedObejct, which is at >>>>> serializedObjects at: 6 and then I put explore pointers I ONLY see >>>>> the >>>>> array of the WeakOrderedCollection pointing to it. I don't understand. >>>>> >>>>> Any help is really appreaciated. >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Aug. 3, 2011

Re: [Pharo-project] Inspector limiting an object printString output

by StÃ©phane Ducasse

add a new entry :) Stef On Aug 3, 2011, at 6:10 AM, Igor Stasenko wrote: > In > > Inspector>>selectionPrintString it uses: > > text := [self selection printStringLimitedTo: 5000] > > which sometimes not quite adequate (sometimes i need to display more). > > I think it would be nicer if inspector would ask object, if it desires > to limit itself (when printing in big inspection pane) > and what concrete limit it desires, instead of hardcoding the number > in inspector. > > Something like: > > Object>>printStringLimited > ^ self printLimit ifNotNil: [:limit | > self printStringLimitedTo: limit ] > ifNil: [ > self printString ]. > > so, then #printLimit could be overridden by choice of developer, to > set (or not) the limits > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 3, 2011

Re: [Pharo-project] [squeak-dev] Re: Optimizing RunArray

by StÃ©phane Ducasse

Yes! Since some months, I'm slowly learning the events and rewriting them. I'm writing test and I hope that one of these days I will be able to have a nice event structure. If you want to join or have a look EventModel/EventModel on squeaksource. The text stuff should benefit from that. Stef On Aug 3, 2011, at 1:01 AM, Nicolas Cellier wrote: > One thing that super upset me is that TextEditor is still using the > old selectors #readKeyboard #keyboard #keyboardPeek instead of using > events. > Look #handleInteraction:fromEvent: > It still has this hackish code to transform event driven Morph into > st-80-polling-ParagraphEditor-friendly-Sensor-like > self editor sensor: (KeyboardBuffer new startingEvent: evt). > IMO, > self handleInteraction: [ editor readKeyboard ] fromEvent: evt. > should be replaced with > self handleInteraction: [ editor keyStroke: evt ]. > and the hack should be delegated to the TextMorphEditor (ParagraphEditor) > keyStrocke: anEvent > "Pass the event to a polling friendly sensor like so that old st-80 > code shall still work" > self sensor: (KeyboardBuffer new startingEvent: evt). > self readKeyboard. > Then TextEditor>>keyStrocke: should dispatchKeyboardEvent: anEvent > with: typeAhead and stop querying a pseudo sensor. > Of course, that means changing a lot of methods in TextEditor (any > method with 'sensor' in source). > But if TextEditor is just a place holder for copying the st-80 > ParagraphEditor code and the early Morphic hacks, I just don't see the > point of making such a copy ;) > > Nicolas > > 2011/8/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I have tried again with huge text (my 45 MByte change log). >> Main contributor seems to be Text composition. >> A marginal gain (2 to 3% when resizing the window) is to remove the >> indirection in TextStopConditions, and replace instance variable stops >> with direct integer slots (variableSubclass) >> >> No guaranty the fileIn of attachment will work, modifying Text >> processing is dangerous... >> >> Nicolas >> >> 2011/8/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Yes I was wondering about the same (for athens too :)) >>> >>> Stef >>> >>> On Aug 2, 2011, at 2:16 PM, Igor Stasenko wrote: >>> >>>> Does it impacts the text rendering/processing speed? >>>> >>>> >>>> On 2 August 2011 12:11, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> To complete myself, the fast #collect: already exists and is named >>>>> #mapValues: except that it modifies the RunArray in place and also >>>>> won't coalesce... >>>>> >>>>> I also gain a huge factor for #collect:as: be defining this method: >>>>> >>>>> RunArray>>fillFrom: aCollection with: aBlock >>>>> "Evaluate aBlock with each of aCollections's elements as the argument. >>>>> Collect the resulting values into self. Answer self." >>>>> | newRuns newValues lastLength lastValue | >>>>> newRuns := (Array new: aCollection size) writeStream. >>>>> newValues := (Array new: aCollection size) writeStream. >>>>> lastLength := 0. >>>>> lastValue := Object new. >>>>> aCollection do: [:each | >>>>> | value | >>>>> value := aBlock value: each. >>>>> lastValue = value >>>>> ifTrue: [lastLength := lastLength + 1] >>>>> ifFalse: >>>>> [lastLength > 0 >>>>> ifTrue: >>>>> [newRuns nextPut: lastLength. >>>>> newValues nextPut: lastValue]. >>>>> lastLength := 1. >>>>> lastValue := value]]. >>>>> lastLength > 0 >>>>> ifTrue: >>>>> [newRuns nextPut: lastLength. >>>>> newValues nextPut: lastValue]. >>>>> self setRuns: newRuns contents setValues: newValues contents >>>>> >>>>> [ (Array new: 1000) collect: [:e | 4 atRandom] as: RunArray] bench. >>>>> BEFORE: '25.1 per second.' >>>>> AFTER: '1,080 per second.' >>>>> >>>>> It's worth a few lines of code. >>>>> >>>>> Nicolas >>>>> >>>>> 2011/8/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>> I played a bit with RunArray, and found some un-optimized features. >>>>>> First, I don't know why RunArray is an ArrayedCollection. It cannot >>>>>> #add: but it can #addFirst: and #addLast:. >>>>>> It cannot #add:withOccurrences: but it can #addLast:times:. Why >>>>>> inventing new selectors for old behaviours ? >>>>>> These operations will cost a realloc it the last value is different, >>>>>> so the underlying runs/values could better be an OrderedCollection if >>>>>> these operations are used often. >>>>>> A RunArray cannot remove at all. >>>>>> Very weird collection species, I don't like the implementation too much. >>>>>> >>>>>> Then, #do: loops could be far faster. They rely on ArrayedCollection >>>>>> which inlines do: loops with #to:do: and #at: >>>>>> But #at: is not that fast. Scanning the runs and counting elements >>>>>> would result in a n^2 cost. >>>>>> Fortunately there is a cache lastIndex,lastRun,lastOffset to keep a cost n. >>>>>> Nonetheless, all the tests cost, and the loop is suboptimal. >>>>>> Let use see: >>>>>> >>>>>> version 1: >>>>>> RunArray>>fastDo: aBlock >>>>>> runs with: values do: [:r :v | >>>>>> r timesRepeat: [aBlock value: v]]. >>>>>> >>>>>> | tmp | >>>>>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>>>>> { >>>>>> [ tmp do: [:e |]] bench. >>>>>> [ tmp fastDo: [:e |]] bench. >>>>>> } >>>>>> #('3,220 per second.' '6,290 per second.') >>>>>> >>>>>> But timesRepeat: is slow, it is unoptimized by the compiler and costs >>>>>> a message send. >>>>>> I think we should implement BlockClosure>>repeat: and optimize that >>>>>> call in Compiler. >>>>>> But let's not do it, and rather inline by ourself: >>>>>> >>>>>> version 2: >>>>>> runs with: values do: [:r :v | >>>>>> 1 to: r do: [:i | aBlock value: v]]. >>>>>> >>>>>> | tmp | >>>>>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>>>>> { >>>>>> [ tmp do: [:e |]] bench. >>>>>> [ tmp do2: [:e |]] bench. >>>>>> } >>>>>> #('3,070 per second.' '25,500 per second.') >>>>>> >>>>>> We can even inline the with:do: loop itself: >>>>>> version 3: >>>>>> 1 to: runs size do: [:i | >>>>>> | r v | >>>>>> v := values at: i. >>>>>> r := runs at: i. >>>>>> [( r := r - 1) >= 0] >>>>>> whileTrue: [aBlock value: v]]. >>>>>> >>>>>> | tmp | >>>>>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>>>>> { >>>>>> [ tmp do: [:e |]] bench. >>>>>> [ tmp do2: [:e |]] bench. >>>>>> } >>>>>> #('3,370 per second.' '32,200 per second.') >>>>>> >>>>>> Now the operation I wanted to use was reverseDo: so I implemented: >>>>>> RunArray>>fastReverseDo: aBlock >>>>>> | i | >>>>>> i := runs size. >>>>>> [i > 0] >>>>>> whileTrue: >>>>>> [ | r v | >>>>>> v := values at: i. >>>>>> r := runs at: i. >>>>>> i := i - 1. >>>>>> [( r := r - 1) >= 0] >>>>>> whileTrue: [aBlock value: v]]. >>>>>> | tmp | >>>>>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>>>>> { >>>>>> [ tmp reverseDo: [:e |]] bench. >>>>>> [ tmp reverseDo2: [:e |]] bench. >>>>>> } >>>>>> #('83.9 per second.' '32,600 per second.') >>>>>> >>>>>> Ouch! The cache is missing a lot of indices, and our loop turns into a n^2 cost. >>>>>> I know, premature optimization bla bla bla, but a factor x400 is worth >>>>>> some inlining no? >>>>>> >>>>>> I guess these features are never used. >>>>>> By now RunArray is kind of private utility for Text implementation. >>>>>> But it could / should be generic. >>>>>> >>>>>> I also have proposals for count: / select: / collect:. etc... >>>>>> It would be to evaluate the block only once per group of values. >>>>>> For example >>>>>> RunArray>>collect: aBlock >>>>>> "Beware, the block will be evaluated only once per group of values." >>>>>> ^(self class runs: (runs collect: aBlock) contents values: values >>>>>> copy) coalesce >>>>>> But that's controversial, it would make the RunArray behave >>>>>> differently if the block has side effects... >>>>>> >>>>>> | i tmp tmp2 tmp3 | >>>>>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]). >>>>>> i := 0. >>>>>> tmp2 := tmp collect: [:e | i := i + 1]. >>>>>> i := 0. >>>>>> tmp3 := (tmp as: RunArray) collect: [:e | i := i + 1]. >>>>>> tmp2 = tmp3 asArray >>>>>> ==> false >>>>>> >>>>>> Nicolas >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >> >

Aug. 3, 2011

Re: [Pharo-project] [ANN] SmalltalkHub demo online

by Nicolas Petton

Yes, sorry. But we'll put it back online very soon now. Cheers, Nico Le mercredi 03 aoÃ»t 2011 Ã 19:03 +0200, Igor Stasenko a Ã©crit : > seems like i'm too late on the party :( > > Service Temporarily Unavailable > > The server is temporarily unable to service your request due to > maintenance downtime or capacity problems. Please try again later. > Apache/2.2.12 (Ubuntu) Server at smalltalkhub.objectfusion.fr Port 80 > > -- Nicolas Petton http://www.nicolas-petton.fr

Aug. 3, 2011

Re: [Pharo-project] [ANN] SmalltalkHub demo online

by Igor Stasenko

seems like i'm too late on the party :( Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.2.12 (Ubuntu) Server at smalltalkhub.objectfusion.fr Port 80 -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2011

Re: [Pharo-project] [Vm-dev] Re: identityHash bits not incremented for new objects?

by David T. Lewis

On Wed, Aug 03, 2011 at 04:54:09PM +0200, Henrik Johansen wrote: > > On Aug 2, 2011, at 5:09 51PM, David T. Lewis wrote: > > > On Tue, Aug 02, 2011 at 03:31:30PM +0200, Henrik Johansen wrote: > >> > >> Please include a comment with that. :) > >> Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. > > > > Henry, FYI Igor has found a small but important bug in the VM. There is > > some additional follow up discussion on the vm-dev list that you can read > > starting here: > > > > <http://lists.squeakfoundation.org/pipermail/vm-dev/2011-August/009006.html> > > > > Dave > > I saw, and it does eliminate the common case where two small objects get the same identityHash. > Though, it doesn't really _ensure_ that two subsequently allocated objects will have different identityHashes, does it? > IE. if an object is allocated with size which increases (freeStart >> someInt) by 4096, won't you still see the next object getting the same identityHash? > > Not to mention power-of-two sized objects will have a _really_ low number of different hashes. (though none subsequently equal) > Hence my question if this is really an important property to require of the VM. > Considering the amount of times I've seen complaints of Set performance due to bad hashing under Cog (in other words, 0), I don't think so. > > Like Nicolas, I am rather skeptic to the comment saying the values are "well-distributed and fairly random" (which is both true and false, depending on how you interpret "distributed" and "random") though, and would like it if it additionally pointed out edge-cases like above. > I can't comment on that, I just wanted to give credit to Igor for a good bug catch :) > Cheers, > Henry > > PS. > What's the state of NewObjectMemory usage in VMMaker? > When I loaded it, I couldn't find definition/initialization of HashMaskUnshifted, in > VMMaker.oscog those were in VMSqueakV3ObjectRepresentationConstants/ObjectMemory respectively. For NewObjectMemory, StackInterpreter, etc you should use only the oscog VMMaker branch blessed by Eliot (or the related development updates from Igor or others). I have made a preliminary effort to bring some of this into VMMaker trunk, primarily updating it to work with the 64bit/32bit object memory support in VMMaker trunk (e.g. using 'self bytesPerWord' rather than BytesPerWord). But this is not suitable for general use and you definitely cannot yet produce a working interpreter with it, so please use Eliot's oscog branch if you are building a StackInterpreter or Cog. As always, VMMaker trunk uses the Interpreter and ObjectMemory classes to produce a standard interpreter VM compatible with the Subversion trunk platform sources, and with generated code suitable for 32bit and 64bit images. Dave

Aug. 3, 2011

Re: [Pharo-project] [ANN] SmalltalkHub demo online

by Sean P. DeNigris

Request: please include a way to store contributions from the public (like maybe per-project inboxes). Motivation: With SqS, it seems great fixes and enhancements often get lost on old hard drives or the mailing list because the authors don't have write access to the repo, and it's often hard to contact the admins. Result: every contribution will be preserved and easily findable from the project's repo, while admins maintain control over their codebase if desired. Thanks. Sean -- View this message in context: http://forum.world.st/ANN-SmalltalkHub-demo-online-tp3460871p3715827.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 3, 2011

Re: [Pharo-project] identityHash bits not incremented for new objects?

by Henrik Johansen

On Aug 2, 2011, at 5:09 51PM, David T. Lewis wrote: > On Tue, Aug 02, 2011 at 03:31:30PM +0200, Henrik Johansen wrote: >> >> On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote: >> >>> On 2 August 2011 14:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>> On Aug 1, 2011, at 8:43 53AM, Igor Stasenko wrote: >>>> >>>>> I found that #testBecomeIdentityHash sometimes failing, sometimes not. >>>>> >>>>> It seems like VM 'forgets' to produce different identityHash bits for >>>>> two consequently allocated objects, >>>>> while test assumes that they are always different. >>>>> >>>>> If i insert a statement (see the code), test no longer fails. >>>>> >>>>> testBecomeIdentityHash >>>>> "Note. The identity hash of both objects seems to change after the become:" >>>>> >>>>> | a b c d | >>>>> >>>>> a := 'ab' copy. >>>>> b := 'cd' copy. >>>>> >>>>>>>> [ b identityHash = a identityHash ] whileTrue: [ b := b copy ]. >>>>> >>>>> c := a. >>>>> d := b. >>>>> >>>>> a become: b. >>>>> >>>>> self >>>>> assert: a identityHash = c identityHash; >>>>> assert: b identityHash = d identityHash; >>>>> deny: a identityHash = b identityHash. >>>>> >>>>> A simple piece of code reveals the problem: >>>>> >>>>> (1 to: 20) collect: [:i | >>>>> 'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958 >>>>> 958 959 959 960 960 961 961 962 962 963 963) >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>> >>>> What is the point of this test in the first place? >>>> To me it seems to test whether a VM's implementation of become: adheres to some properties. >>>> At least, VM bugs in traversal of references during become is the only way I could see the two first asserts EVER being false. >>>> >>>> As for the last assert (well, deny actually), in the context of what it's supposed to test as established above, it seems to me to say a VM should never give the same identityHash to subsequently copied objects. Which means >>>> a) It has nothing to do with become and identityHash, thus is in the test. >>>> b) Is this a property any code actually rely on? >>>> >>>> If not, why would we assert such a restriction on the VM implementation, or is it harmless? >>>> >>>> Either way, modifying the test to iterate till they ARE different, would make it meaningless in either case (and possible infinite loop in case of a really bad VM). >>>> >>> >>> There is strong reason to test identityHashes, because VM should >>> preserve an identity hash for oops. >>> >>> But of course test is wrong , because to test that , it should be like >>> following: >>> >>> | a b hash1 hash2 | >>> >>> a := 'ab' copy. >>> b := 'cd' copy. >>> hash1 := a identityHash. >>> hash2 := b identityHash. >>> >>> a become: b. >>> >>> self >>> assert: a identityHash = hash1; >>> assert: b identityHash = hash2. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> Please include a comment with that. :) >> Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. > > Henry, FYI Igor has found a small but important bug in the VM. There is > some additional follow up discussion on the vm-dev list that you can read > starting here: > > <http://lists.squeakfoundation.org/pipermail/vm-dev/2011-August/009006.html> > > Dave I saw, and it does eliminate the common case where two small objects get the same identityHash. Though, it doesn't really _ensure_ that two subsequently allocated objects will have different identityHashes, does it? IE. if an object is allocated with size which increases (freeStart >> someInt) by 4096, won't you still see the next object getting the same identityHash? Not to mention power-of-two sized objects will have a _really_ low number of different hashes. (though none subsequently equal) Hence my question if this is really an important property to require of the VM. Considering the amount of times I've seen complaints of Set performance due to bad hashing under Cog (in other words, 0), I don't think so. Like Nicolas, I am rather skeptic to the comment saying the values are "well-distributed and fairly random" (which is both true and false, depending on how you interpret "distributed" and "random") though, and would like it if it additionally pointed out edge-cases like above. Cheers, Henry PS. What's the state of NewObjectMemory usage in VMMaker? When I loaded it, I couldn't find definition/initialization of HashMaskUnshifted, in VMMaker.oscog those were in VMSqueakV3ObjectRepresentationConstants/ObjectMemory respectively.

Aug. 3, 2011

[Pharo-project] writing a test method

by Alexandre Bergel

Hi! When I write a test method, I always need to open a new window with the definition of the setUp. It would be really cool to have a better support in the browser for this. Maybe having a split of the text pane or something. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 3, 2011

Re: [Pharo-project] Small Seaside image

by Henrik Johansen

On Aug 3, 2011, at 2:36 17PM, Hilaire Fernandes wrote: > Le 03/08/2011 13:45, Henrik Johansen a Ã©crit : >> >> On Aug 3, 2011, at 1:16 07PM, Hilaire Fernandes wrote: >> >>> I have found a difference of about 5Mb whether I install or not some >>> DejaVu fonts: >>> >>> ----------------------- >>> Gofer new >>> url: 'http://www.squeaksource.com/DejaVu'; >>> package: 'DejaVuBitmapFonts'; >>> load. >>> >>> ScriptLoader new cleanUpForProduction. >>> >>> DejaVuHolder installSizes: #(10 12). >>> StandardFonts setDefaultFonts: #( >>> (codeFont: 'Bitmap DejaVu Sans Regular' 12) >>> (listFont: 'Bitmap DejaVu Sans Regular' 12) >>> (menuFont: 'Bitmap DejaVu Sans Regular' 12) >>> (windowTitleFont: 'Bitmap DejaVu Sans Regular' 12) >>> (balloonFont: 'Bitmap DejaVu Sans Regular' 10) >>> (haloFont: 'Bitmap DejaVu Sans Regular' 10) >>> (buttonFont: 'Bitmap DejaVu Sans Regular' 12) >>> (defaultFont: 'Bitmap DejaVu Sans Regular' 12)). >>> ----------------------- >>> >>> 5Mb seems a lot for two sizes font, even if it comes with Bitmaps. Is it >>> correct or are there some clean up I can do in the fonts? >>> >>> Hilaire >>> >> The package holds source bitmaps for ALL sizes. >> Cean up after you have installed the ones you want by unloading >> DejaVuBitmapFonts again. > > Ah, yes understood how it works. > >> >> You can also save more space by removing StrikeFont dejaVuSans... > > Is it "StrikeFont cleanUp" enought? > It saves about 4 MB, with a final image below 10MB, nice. > > Thanks > > Hilaire StrikeFont cleanUp is called anyways as part of cleanUpForProduction. Doing the removal only shaved off 900KB or so in my test though, see http://code.google.com/p/pharo/issues/detail?id=4597 Cheers, Henry

Aug. 3, 2011