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

Re: [Pharo-project] importing versions in squeaksource does not work anymore

by Veronica Isabel Uquillas Gomez

On 02 Aug 2011, at 15:33, Marcus Denker wrote: > > 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. > In the repository Ring: Ring-History-Definitions-AndyKellens.25.mcz Ring-History-Importer-AndyKellens.25.mcz Thank you :) Veronica > > -- > Marcus Denker -- http://marcusdenker.de > >

Aug. 2, 2011

Re: [Pharo-project] trait method tagging is not consistent

by Veronica Isabel Uquillas Gomez

On 01 Aug 2011, at 21:30, StÃ©phane Ducasse wrote: > (SourceFiles sourcedDataAt: (Point>>#dist:) sourcePointer) > 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42''' > > > SourceFiles sourcedDataAt: (ComposableMorph>>#newToolSpacer) sourcePointer > 'Trait method' > Stef, for this example I am getting: 'ComposableMorph methodsFor: ''controls''' Only the stamp is missing. I tried in Pharo 1.3 and Pharo 1.4 > > so protocol, stamp: .... got confused. > > http://code.google.com/p/pharo/issues/detail?id=4581 > > Stef > >

Aug. 2, 2011

Re: [Pharo-project] importing versions in squeaksource does not work anymore

by Marcus Denker

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

Aug. 2, 2011

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

by Henrik Johansen

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. Cheers, Henry

Aug. 2, 2011

[Pharo-project] importing versions in squeaksource does not work anymore

by Veronica Isabel Uquillas Gomez

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

Aug. 2, 2011

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

by Igor Stasenko

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.

Aug. 2, 2011

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

by Henrik Johansen

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). Cheers, Henry

Aug. 2, 2011

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

by Igor Stasenko

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. 2, 2011

Re: [Pharo-project] updating the state of a state button

by Hilaire Fernandes

Yeah, I just figure out Thanks Hilaire Le 02/08/2011 13:36, Gary Chambers a Ã©crit : > Need to send > > self changed: #isMySketches > > Regards, Gary > > ----- Original Message ----- From: "Hilaire Fernandes" > <hilaire.fernandes(a)edu.ge.ch> > To: <pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, August 02, 2011 12:11 PM > Subject: [Pharo-project] updating the state of a state button > > >> 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 >> >> > > -- Education 0.2 -- http://blog.ofset.org/hilaire

Aug. 2, 2011

Re: [Pharo-project] a.4 combox box bug

by Henrik Johansen

On Jul 29, 2011, at 10:52 47AM, StÃ©phane Ducasse wrote: > :) > > delete or delete => remove delete :) > Disregard my last mail. That's what I get for not read mail for couple of days, then briefly scan list for replies, and miss one :) Cheers, Henry

Aug. 2, 2011