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

[Pharo-project] UUIDs not so unique

by Philippe Marschall

Hi I have run into an issue where there wouldn't any unique UUIDs be produced any more. ((1 to: 100) collect: [ :i | UUID new asString ]) asSet size answers 2 or 3 in my image. My system: linux 64bit cog r2462 Pharo 1.3 latest updates (no changes to the UUID class) I found the issue because there are several versions of Seaside-Core in the WIP repository [1] with the same UUID. For example Seaside-Core-pmm.728 and Seaside-Core-pmm.729 or Seaside-Core-pmm.727 and Seaside-Core-pmm.726. Since this means I can't write any Seaside code anymore I'm obviously not happy. [1] http://www.squeaksource.com/SeasideWip Cheers Philippe

July 19, 2011

Re: [Pharo-project] Exception >> return:?

by Nicolas Cellier

2011/7/19 Eliot Miranda <eliot.miranda(a)gmail.com> > > > On Tue, Jul 19, 2011 at 8:19 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > >> Can anyone explain me why it would make sense to use #return: in the >> following method? >> >> TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent >> ^[aBlock value. >> false] >> on: anExceptionalEvent >> do: [:ex | ex return: true] >> >> I would instinctively replace [:ex | ex return: true] with the much >> simpler [:ex | ^ true].. >> Am I missing something here? >> > > Well, Lukas' answer makes sense to me. But on a style point I would > replace it by the even simpler > > TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent > ^[aBlock value. > false] > on: anExceptionalEvent > do: [:ex | true] > > the explicit non-local return ^true isn't necessary, sicne there's already > a method return for the whole on:do: form, and in some implementations the > [:ex| ^true] block could be significantly more expensive to create than > [:ex| true] (e.g. VisualWorks, but not current Squeak/Pharo with my closure > implementation). > > And the shortest Squeak form is TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent ^[aBlock value. false] on: anExceptionalEvent do: [ true ] > >> camillo >> >> > > > -- > best, > Eliot > >

July 19, 2011

Re: [Pharo-project] [update 1.4] #14050

by Pavel Krivanek

On Tue, Jul 19, 2011 at 7:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Pavel wrote: >>is there some paper about Ring? > > see http://goo.gl/7Er5O Thanks! -- Pavel > > Stef: would it be possible to add the URL's to the > update notes as we discussed in May in thread > "Linking Update Mails to issue tracker" > > Thx and Bye > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > >

July 19, 2011

Re: [Pharo-project] Exception >> return:?

by Eliot Miranda

On Tue, Jul 19, 2011 at 8:19 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > Can anyone explain me why it would make sense to use #return: in the > following method? > > TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent > ^[aBlock value. > false] > on: anExceptionalEvent > do: [:ex | ex return: true] > > I would instinctively replace [:ex | ex return: true] with the much simpler > [:ex | ^ true].. > Am I missing something here? > Well, Lukas' answer makes sense to me. But on a style point I would replace it by the even simpler TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent ^[aBlock value. false] on: anExceptionalEvent do: [:ex | true] the explicit non-local return ^true isn't necessary, sicne there's already a method return for the whole on:do: form, and in some implementations the [:ex| ^true] block could be significantly more expensive to create than [:ex| true] (e.g. VisualWorks, but not current Squeak/Pharo with my closure implementation). > camillo > > -- best, Eliot

July 19, 2011

[Pharo-project] [update 1.4] #14050

by Torsten Bergmann

Pavel wrote: >is there some paper about Ring? see http://goo.gl/7Er5O Stef: would it be possible to add the URL's to the update notes as we discussed in May in thread "Linking Update Mails to issue tracker" Thx and Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

July 19, 2011

Re: [Pharo-project] Exception >> return:?

by Camillo Bruni

thanks ;) On 2011-07-19, at 17:23, Lukas Renggli wrote: > Some Smalltalks required it (i.e. VA), that's probably also the reason > why SUnit uses it. Likely has to do with how they implement exception > handlers. > > Lukas > > On Tuesday, 19 July 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: >> Can anyone explain me why it would make sense to use #return: in the following method? >> >> TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent >> ^[aBlock value. >> false] >> on: anExceptionalEvent >> do: [:ex | ex return: true] >> >> I would instinctively replace [:ex | ex return: true] with the much simpler [:ex | ^ true].. >> Am I missing something here? >> >> camillo >> >> > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 19, 2011

Re: [Pharo-project] Why does CompiledMethod>>hasLiteral: use ==

by Eliot Miranda

On Mon, Jul 18, 2011 at 2:40 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I tried: > > aMethod hasLiteral: #DateAndTime->DateAndTime > > and got false, even though an "=" literal is indeed there. > > Why doesn't #hasLiteral: use #=? > Well, the tricky thing with literals is that 0.0 = 0 and 'one' = #one but these are all different literals. That said, it looks like a bug to me. It should surely be !CompiledMethod methodsFor: 'literals' stamp: 'eem 7/19/2011 09:19'! hasLiteral: literal | litClass lit | "Answer whether the receiver references the argument, literal." litClass := literal class. 2 to: self numLiterals - 1 do: "exclude superclass + selector/properties" [:index | lit := self objectAt: index. (litClass == lit class and: [literal = lit]) ifTrue: [^true]]. ^false! ! !Array methodsFor: 'private' stamp: 'eem 7/19/2011 09:20'! hasLiteral: literal "Answer true if literal is identical to any literal in this array, even if imbedded in further array structure. This method is only intended for private use by CompiledMethod hasLiteralSymbol:" | litClass lit | litClass := literal class. 1 to: self size do: [:index | (litClass == (lit := self at: index) class and: [literal = lit]) ifTrue: [^true]. (Array == lit class and: [lit hasLiteral: literal]) ifTrue: [^true]]. ^false! ! I've run all the tests in a trunk 4.2 before and after and making the above change makes no difference. So I think I'll go ahead and commit the change to Squeak trunk. I'll leave the Pharo folks to apply it there-in. Files attached. > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Why-does-CompiledMethod-hasLiteral-use-tp3676573p3676… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

July 19, 2011

Re: [Pharo-project] Stubbing class-side methods

by Sean P. DeNigris

Denis Kudriashov wrote: > > I think not. > This way is substitution of method literal. > > But "self sends" stubbing required anonimous subclass creation with > required > methods overrides. > That sounds right. The bytecodes would be different if a self send was rerouted to another object (pushLit: instead of self). Sean -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3678562.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 19, 2011

Re: [Pharo-project] Stubbing class-side methods

by Sean P. DeNigris

Denis Kudriashov wrote: > > I should add it to Mocketry. > Feel free. It's MIT. I'm still marinading over a TestCase method that loops through it's own literals and makes the swap for each. Then instead of #usingDouble:, it would be something like #testXxx self usingDouble: ... which would call #usingDouble: on each class referenced in the test, creating a simulated environment for the test. -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3678530.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 19, 2011

Re: [Pharo-project] Exception >> return:?

by Lukas Renggli

Some Smalltalks required it (i.e. VA), that's probably also the reason why SUnit uses it. Likely has to do with how they implement exception handlers. Lukas On Tuesday, 19 July 2011, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > Can anyone explain me why it would make sense to use #return: in the following method? > > TestCase >> executeShould: aBlock inScopeOf: anExceptionalEvent > Â Â Â Â ^[aBlock value. > Â Â Â Â Â false] > Â Â Â Â Â Â Â Â on: anExceptionalEvent > Â Â Â Â Â Â Â Â do: [:ex | ex return: true] > > I would instinctively replace [:ex | ex return: true] with the much simpler [:ex | ^ true].. > Am I missing something here? > > camillo > > -- Lukas Renggli www.lukas-renggli.ch

July 19, 2011