- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14072
by StÃ©phane Ducasse Aug. 2, 2011

Aug. 2, 2011

14072 ----- - Issue 3433: Color improvement http://code.google.com/p/pharo/issues/detail?id=3433 - Better class comment for FlatListMessageBrowser

1 0

[Pharo-project] trait method tagging is not consistent
by StÃ©phane Ducasse Aug. 2, 2011

Aug. 2, 2011

(SourceFiles sourcedDataAt: (Point>>#dist:) sourcePointer) 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42''' SourceFiles sourcedDataAt: (ComposableMorph>>#newToolSpacer) sourcePointer 'Trait method' so protocol, stamp: .... got confused. http://code.google.com/p/pharo/issues/detail?id=4581 Stef

2 2

[Pharo-project] a.4 combox box bug
by StÃ©phane Ducasse Aug. 2, 2011

Aug. 2, 2011

Hi guys when I open the new recent message list in 14063 I do not get the list and it I click on the by... The combox box gets displayed but I cannot get rid of it. I do not see why we get this behavior. Stef

3 9

Re: [Pharo-project] [squeak-dev] Optimizing RunArray
by Nicolas Cellier Aug. 2, 2011

Aug. 2, 2011

No, I wanted to reuse RunArray for other purposes, that's why the methods weren't optimized. For Text, the major operation is ... Hmm wait, this is really hard to track by just reading code, and debugging it is not that easy ! Nicolas 2011/8/2 Bert Freudenberg <bert(a)freudenbergs.de>: > On 02.08.2011, at 10:17, Nicolas Cellier wrote: > >> 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 ? > > The RunArray selectors may in fact precede the more common ones. RunArray's purpose was to make Text operations efficient. I think that's still the only actual use of RunArrays. In any case, speeding up Text is a good idea, though you might want to check what methods it actually uses. > > - Bert - > >> 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 >> > > > >

1 1

[Pharo-project] SS down?
by Alexander LazareviÄ Aug. 2, 2011

Aug. 2, 2011

http://www.downforeveryoneorjustme.com/squeaksource.com Alex

3 2

[Pharo-project] [update 1.4] #14071
by Marcus Denker Aug. 2, 2011

Aug. 2, 2011

14071 ----- Issue 4582: Failing tests: CompiledMethodTest restReadField and testWriteField http://code.google.com/p/pharo/issues/detail?id=4582 Issue 4583: Undeclared in #allLocalCallsOn:ofClass: http://code.google.com/p/pharo/issues/detail?id=4583 Issue 4585: Failing Test: uncategorized methods in MethodReference http://code.google.com/p/pharo/issues/detail?id=4585 Issue 4584: Undeclared in #doTestDebuggerTempAccessWith:with: http://code.google.com/p/pharo/issues/detail?id=4584 Issue 4588: Failing test: #testSizeInMemoryNormalClasses http://code.google.com/p/pharo/issues/detail?id=4588 Issue 4590: Polymorph improvements http://code.google.com/p/pharo/issues/detail?id=4590 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] importing versions in squeaksource does not work anymore
by Marcus Denker Aug. 2, 2011

Aug. 2, 2011

On Aug 2, 2011, at 3:24 PM, Veronica Isabel Uquillas Gomez wrote: > Hi, > > This feature is broken. I am getting the following error: > > There was an error importing the file xxx.25.mcz. The file has to be in mcz format! > > It does not make sense. How can I publish files in a repository now? The reason is that there is already a file on disk with that name, but SqueakSource forgot the meta data that it's there. I can remove and and send it to you, than you can upload it again. -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] importing versions in squeaksource does not work anymore
by Veronica Isabel Uquillas Gomez Aug. 2, 2011

Aug. 2, 2011

Hi, This feature is broken. I am getting the following error: There was an error importing the file xxx.25.mcz. The file has to be in mcz format! It does not make sense. How can I publish files in a repository now? Regards, Veronica

1 0

[Pharo-project] updating the state of a state button
by Hilaire Fernandes Aug. 2, 2011

Aug. 2, 2011

In a dialog, I found the state of a button is not updated, even after self changed. See the code bellowm with methodes defnied in the dialog: newMySketchesButton ^ self newButtonFor: self getState: #isMySketches action: #sketches arguments: nil getEnabled: #beMySketches "alway return true" label: 'MySketches' translated help: 'View my sketches' translated sketches self isExamples: false. isExamples: boolean isExamples := boolean. self changed isMySketches ^self isExamples not There is no #update at the dialog level, how should the button state updated? (I know I can do it by-hand) Implementing myself an #update or do I miss something? Thanks Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

2 2

[Pharo-project] Hudson build is back to normal : Pharo 1.3 #248
by marcus.denker＠inria.fr Aug. 2, 2011

Aug. 2, 2011

See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/248/>

1 0