- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.4 #14076 update failed.
by Laszlo Zsolt Kiss Aug. 4, 2011

Aug. 4, 2011

aloha pharoers! i don' know what is the problemMy image is clean 14.But I geted the attached message.Please help.Thx Best reagrdsÂ LAszlo Zsolt Kiss

1 0

[Pharo-project] [update 1.4] #14076
by Marcus Denker Aug. 4, 2011

Aug. 4, 2011

14076 ----- Issue 4596: WeakOrderedColllection array is replaced by an Array instead of a WeakArray (part 2) -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] ThreadSafeTranscript
by Pavel Krivanek Aug. 4, 2011

Aug. 4, 2011

Hi, why in the latest 1.4 image is ThreadSafeTranscript back? Wasn't it replaced by TranscriptModel? It breaks Pharo-Kernel CI job (it doesn't report fail but I will fix that). -- Pavel

2 2

[Pharo-project] [update 1.4] #14075
by Marcus Denker Aug. 4, 2011

Aug. 4, 2011

14075 ----- Issue 4596: WeakOrderedColllection array is replaced by an Array instead of a WeakArray (part 1) -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [ANN] SmalltalkHub demo online
by Torsten Bergmann Aug. 4, 2011

Aug. 4, 2011

>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. Great idead! +1000 Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

2 1

[Pharo-project] [update 1.4] #14074
by Marcus Denker Aug. 4, 2011

Aug. 4, 2011

14074 ----- Issue 4565: Monticello workflow broken http://code.google.com/p/pharo/issues/detail?id=4565 Issue 4597: StrikeFont aggressive cleanup should remove DejaVu source http://code.google.com/p/pharo/issues/detail?id=4597 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Small Seaside image
by Marcus Denker Aug. 3, 2011

Aug. 3, 2011

On Aug 3, 2011, at 10:17 AM, laurent laffont wrote: > Hi, > > actually using PharoCore 1.3, loading ConfigurationOfSeaside30 Core, then ScriptLoader>>cleanUpForProduction I have a 13MB image. Is it possible to have it smaller ? (I know a next step is to be able to use PharoKernel). cleanUpForProduction should result in a Core image that is just 6.5MB... so the ConfigurationOfSeaside30 seems to load *a lot* of stuff? Maybe be a bit selective? Marcus -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] Help with a WeakOrderedCollection and objects not being GCed
by Mariano Martinez Peck Aug. 3, 2011

Aug. 3, 2011

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

5 17

[Pharo-project] Inspector limiting an object printString output
by Igor Stasenko Aug. 3, 2011

Aug. 3, 2011

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.

3 2

[Pharo-project] Optimizing RunArray
by Nicolas Cellier Aug. 3, 2011

Aug. 3, 2011

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

3 7