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

[Pharo-project] squeaksource down?

by Camillo Bruni

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

Aug. 1, 2011

Re: [Pharo-project] condenseChanges problem

by Pavel Krivanek

But condenseChanges on reduced image works. I'll try to find time to look at it. -- Pavel On Mon, Aug 1, 2011 at 2:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 1, 2011, at 2:02 PM, Pavel Krivanek wrote: > >> Hi, >> >> I created a special on the CI server and it seems that we are not able >> to condense changes. See >> https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console > > Yes, this is already broken since sime time... > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3923 > > (I think even in 1.2). > > Everything not tested will break... > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Aug. 1, 2011

Re: [Pharo-project] condenseChanges problem

by Marcus Denker

On Aug 1, 2011, at 2:02 PM, Pavel Krivanek wrote: > Hi, > > I created a special on the CI server and it seems that we are not able > to condense changes. See > https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console Yes, this is already broken since sime time... http://code.google.com/p/pharo/issues/detail?id=3923 (I think even in 1.2). Everything not tested will break... -- Marcus Denker -- http://marcusdenker.de

Aug. 1, 2011

[Pharo-project] condenseChanges problem

by Pavel Krivanek

Hi, I created a special on the CI server and it seems that we are not able to condense changes. See https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console -- Pavel

Aug. 1, 2011

Re: [Pharo-project] Coral and read-eval-loop ?

by StÃ©phane Ducasse

yes it does. Stef On Jul 31, 2011, at 10:58 PM, Alexandre Bergel wrote: > Hi! > > I often use ruby when I wish to realize some arithmetic operating without leaving my xterm. I haven't tried Coral, but does it offer a read-eval-loop? a bit like in scheme or shell script? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Aug. 1, 2011

[Pharo-project] [update 1.4] #14068

by Marcus Denker

14068 ----- Issue 4563: should not we remove deprecated 1.2 ? http://code.google.com/p/pharo/issues/detail?id=4563 -- Marcus Denker -- http://marcusdenker.de

Aug. 1, 2011

[Pharo-project] [update 1.4] #14067

by Marcus Denker

14067 ----- Issue 4566: SUnit: Fix for tagging expectedFailure using pragmas http://code.google.com/p/pharo/issues/detail?id=4566 Issue 4570: adding bitString to SmallInteger http://code.google.com/p/pharo/issues/detail?id=4570 Issue 4561: Monticello GUI is broken http://code.google.com/p/pharo/issues/detail?id=4561 -- Marcus Denker -- http://marcusdenker.de

Aug. 1, 2011

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

by Mariano Martinez Peck

Hi Igor. Does the same test work correctlly in a interpreter VM? because I can see: ObjectMemory >> newObjectHash "Answer a new 16-bit pseudo-random number for use as an identity hash." lastHash := 13849 + (27181 * lastHash) bitAnd: 65535. ^ lastHash In which case, it seems that every new hash will be different than the previous one. But NewObjectMemory >> newObjectHash "Derive the new object hash from the allocation pointer. This is less costly than using lastHash because it avoids the read-modify-write cycle to update lastHash. Since the size of eden is a power of two and larger than the hash range this provides a well-distributed and fairly random set of values." <inline: true> ^freeStart >> BytesPerWord so...I have no idea, but maybe for two consequently allocated objects, the instVar freeStart can remain with the same value ? On Mon, Aug 1, 2011 at 8:43 AM, Igor Stasenko <siguctua(a)gmail.com> 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. > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2011

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

by Igor Stasenko

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.

Aug. 1, 2011