- Pharo-dev - lists.pharo.org

Re: [Pharo-project] UUIDs not so unique

by Camillo Bruni

On 2011-07-20, at 08:36, Philippe Marschall wrote: > On 07/19/2011 09:41 PM, Esteban Lorenzano wrote: >> yes... there is a problem in latest vm's and UUID generation (I don't know if it is present at any vm or just mines, but well...). For the moment, faster solution is by deactivating uuid primitive, at: >> >> UUID>>#primMakeUUID >> <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> >> UUIDGenerator default generateBytes: self forVersion: 4. >> >> just comment the primitive call. > > Guys, srsly? Is this some kind of practical joke? You have been shipping > with a known bug that has a trivial fix and eats peoples code? You are > wondering why nobody takes you seriously and you don't have more users? > You teach software engineering? > > This is exactly the kind of shit that makes me want to never again use > Pharo in production. This is the reason why I don't recommend Pharo to > other people. If you don't like don't use it, otherwise help improving it! ;) simple as that :D cami

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Serge Stinckwich

On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 07/19/2011 09:41 PM, Esteban Lorenzano wrote: >> yes... there is a problem in latest vm's and UUID generation (I don't know if it is present at any vm or just mines, but well...). For the moment, faster solution is by deactivating uuid primitive, at: >> >> UUID>>#primMakeUUID >> Â Â Â <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> >> Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. >> >> just comment the primitive call. > > Guys, srsly? Is this some kind of practical joke? You have been shipping > with a known bug that has a trivial fix and eats peoples code? You are > wondering why nobody takes you seriously and you don't have more users? > You teach software engineering? Hum, you know like in most open-source software project, nothing happens by magic, unfortunately. Human ressources are very scarce as Pharo is a part-time project for most of us. Maybe your problem will required some interactions between VM guys and Pharoers. Not something that could be done in 5 minutes. Did you submit an issue in the bug tracker just to keep track of it ? Did you package some patch that could be used more easily by people who do the release ? > This is exactly the kind of shit that makes me want to never again use > Pharo in production. This is the reason why I don't recommend Pharo to > other people. If you use Pharo in production did you give money to support the project ? Pharo is not supported by a company (not yet), so no commitments could be done on the speed of the adoption of patches. People are just doing their best to enhance the system. And if you help them (by packaging patches that solve some problems), everyone will win in the long term. Best regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 07/19/2011 09:41 PM, Esteban Lorenzano wrote: > yes... there is a problem in latest vm's and UUID generation (I don't know if it is present at any vm or just mines, but well...). For the moment, faster solution is by deactivating uuid primitive, at: > > UUID>>#primMakeUUID > <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > UUIDGenerator default generateBytes: self forVersion: 4. > > just comment the primitive call. Guys, srsly? Is this some kind of practical joke? You have been shipping with a known bug that has a trivial fix and eats peoples code? You are wondering why nobody takes you seriously and you don't have more users? You teach software engineering? This is exactly the kind of shit that makes me want to never again use Pharo in production. This is the reason why I don't recommend Pharo to other people. Cheers Philippe

July 20, 2011

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

by Denis Kudriashov

Ð²ÑÐ¾ÑÐ½Ð¸Ðº, 19 Ð¸ÑÐ»Ñ 2011Â Ð³. Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ Sean P. DeNigris <sean(a)clipperadams.com> Ð¿Ð¸ÑÐ°Ð»: > > #testXxx > Â Â self usingDouble: ... > > which would call #usingDouble: on each class referenced in the test, > creating a simulated environment for the test. > Good idea

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Esteban Lorenzano

yes... there is a problem in latest vm's and UUID generation (I don't know if it is present at any vm or just mines, but well...). For the moment, faster solution is by deactivating uuid primitive, at: UUID>>#primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4. just comment the primitive call. cheers, Esteban El 19/07/2011, a las 3:45p.m., Philippe Marschall escribiÃ³: > 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] Why does CompiledMethod>>hasLiteral: use ==

by Sean P. DeNigris

Eliot Miranda-2 wrote: > > 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. > I created Pharo issue #4538 and attached the file. SD -- View this message in context: http://forum.world.st/Why-does-CompiledMethod-hasLiteral-use-tp3676573p3679… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 19, 2011

[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