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

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 07/20/2011 05:08 PM, Casimiro de Almeida Barreto wrote: > Em 20-07-2011 11:29, Philippe Marschall escreveu: >> On 07/20/2011 03:59 PM, Torsten Bergmann wrote: >>> (...) >> Did the bug eat your code? > Are you a professional developer? If so you must have got stuck in bugs > before. MS bugs, Linux bugs, Mac OS bugs, compiler bugs, jdk bugs, > library bugs... > > I have been stuck on bugs. And I can tell you for sure that pharo/squeak > communities are extremely responsive. You point a bug and solution comes > in hand. I can not tell the same about "commercial software > manufacturers" (just try "online support" from the major OS supplier in > the market... or file a bug and track how long it takes to be fixed). > And remember, contrary to pharo, you have to purchase "visual this or > that" in order to use such "marvelous development suite". Even in open > source communities: you have a trouble with Linux kernel you fill a > report in bugzilla and it takes sometimes years to be closed. So, I > can't understand: > > a) your over reaction It ate my code. > b) your insistence in a subject that has proved itself exhausted. > > By the way, the bug didn't "eat your code". Just put the primitive > expression inside double quotes and your code will work all right > (supposing it's correct). Yeah right. I already have an SCM repository (Seaside 3) with several versions with the same UUID. First I have to write a tool that asses the damage which means pulling all my open source code including the full Seaside 3 repository from SqueakSource and search for duplicate UUIDs. Then I have to hope and pray that the corruption doesn't go too far back. Then for all the broken packages I have to load the last correct code. Then for each of them I have to load the latest code without Monticello and commit it with a different version number. Then I have to remove all broken the versions with screws everybody who already used them as ancestors. Cheers Philippe

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Levente Uzonyi

On Wed, 20 Jul 2011, Igor Stasenko wrote: > I changed the MakeUUID in sqUnixUUID.c to look like following: This change is useless IMHO. Instead of stopping the compilation, either return 0 from the function, so the primitive will fail, or fix the included header files for Darwin, which has uuid_generate (http://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPa… ). But the best solution is using the Mac OS platform files instead of the Unix ones for Mac OS. Levente > > > > int MakeUUID(char *location) > { > uuid_t uuid; > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #else > #error "No uuid function provided" > #endif > > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > > and during compiling cocoa vms it fails with error. > And before change the code was looking like following: > > int MakeUUID(char *location) > { > uuid_t uuid; > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #endif > > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > which means that if none HAVE_UUIDGEN or HAVE_UUID_GENERATE is > defined, then there is nothing got called > and memcpy then returns a random values on stack, copied from uuid to locaiton. > > And first version of that file just contains : > > > int MakeUUID(char *location) > { > uuid_t uuid; > uuid_generate(uuid); > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > and then changed to: > > #if defined(__NetBSD__) > uuidgen(&uuid, 1); > #else > uuid_generate(uuid); > #endif > > and then changed to: > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #endif > > Blame: > Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in > heartbeat. Restore -O2 optimization for the interpreter. > > Author: eliot > Date: 5 months ago > Commit: 757297f62c32eaf2af7f26ce66aa6499df776749 > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Igor Stasenko

On 20 July 2011 17:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > he, we made same change... you are going to see a conflict in blessed sources :) > No. i didn't committed it. I just put an obvious missing code path to see what's wrong there. So your's will be fine :) > El 20/07/2011, a las 11:54a.m., Igor Stasenko escribiÃ³: > >> I changed the MakeUUID in sqUnixUUID.c to look like following: >> >> >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #else >> #error "No uuid function provided" >> #endif >> >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> >> and during compiling cocoa vms it fails with error. >> And before change the code was looking like following: >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #endif >> >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> which means that if none HAVE_UUIDGEN or HAVE_UUID_GENERATE is >> defined, then there is nothing got called >> and memcpy then returns a random values on stack, copied from uuid to locaiton. >> >> And first version of that file just contains : >> >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> Â uuid_generate(uuid); >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> and then changed to: >> >> #if defined(__NetBSD__) >> Â uuidgen(&uuid, 1); >> #else >> Â uuid_generate(uuid); >> #endif >> >> and then changed to: >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #endif >> >> Blame: >> Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in >> heartbeat. Restore -O2 optimization for the interpreter. >> >> Author: Â Â Â eliot >> Date: 5 months ago >> Commit: Â Â Â 757297f62c32eaf2af7f26ce66aa6499df776749 >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Esteban Lorenzano

no idea :) maybe because historical reasons. I'll see that, and change if needed. cheers, Esteban El 20/07/2011, a las 12:01p.m., Igor Stasenko escribiÃ³: > Btw, Esteban > i wonder why you using sqUnixUUID.c in cocoa configs, > while MacOS config using sqMacUUID.c which using mac-specific function > to generate uuid. > See > Mac OS/plugins/UUIDPlugin/sqMacUUID.c > > and apparently don't have the problem with defines. > > -- > Best regards, > Igor Stasenko AKA sig. >

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Esteban Lorenzano

he, we made same change... you are going to see a conflict in blessed sources :) El 20/07/2011, a las 11:54a.m., Igor Stasenko escribiÃ³: > I changed the MakeUUID in sqUnixUUID.c to look like following: > > > > int MakeUUID(char *location) > { > uuid_t uuid; > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #else > #error "No uuid function provided" > #endif > > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > > and during compiling cocoa vms it fails with error. > And before change the code was looking like following: > > int MakeUUID(char *location) > { > uuid_t uuid; > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #endif > > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > which means that if none HAVE_UUIDGEN or HAVE_UUID_GENERATE is > defined, then there is nothing got called > and memcpy then returns a random values on stack, copied from uuid to locaiton. > > And first version of that file just contains : > > > int MakeUUID(char *location) > { > uuid_t uuid; > uuid_generate(uuid); > memcpy((void *)location, (void *)&uuid, sizeof(uuid)); > return 1; > } > > and then changed to: > > #if defined(__NetBSD__) > uuidgen(&uuid, 1); > #else > uuid_generate(uuid); > #endif > > and then changed to: > > #if defined(HAVE_UUIDGEN) > uuidgen(&uuid, 1); > #elif defined(HAVE_UUID_GENERATE) > uuid_generate(uuid); > #endif > > Blame: > Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in > heartbeat. Restore -O2 optimization for the interpreter. > > Author: eliot > Date: 5 months ago > Commit: 757297f62c32eaf2af7f26ce66aa6499df776749 > > > > -- > Best regards, > Igor Stasenko AKA sig. >

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Casimiro de Almeida Barreto

Em 20-07-2011 11:29, Philippe Marschall escreveu: > On 07/20/2011 03:59 PM, Torsten Bergmann wrote: >> (...) > Did the bug eat your code? Are you a professional developer? If so you must have got stuck in bugs before. MS bugs, Linux bugs, Mac OS bugs, compiler bugs, jdk bugs, library bugs... I have been stuck on bugs. And I can tell you for sure that pharo/squeak communities are extremely responsive. You point a bug and solution comes in hand. I can not tell the same about "commercial software manufacturers" (just try "online support" from the major OS supplier in the market... or file a bug and track how long it takes to be fixed). And remember, contrary to pharo, you have to purchase "visual this or that" in order to use such "marvelous development suite". Even in open source communities: you have a trouble with Linux kernel you fill a report in bugzilla and it takes sometimes years to be closed. So, I can't understand: a) your over reaction b) your insistence in a subject that has proved itself exhausted. By the way, the bug didn't "eat your code". Just put the primitive expression inside double quotes and your code will work all right (supposing it's correct). Regards, CdAB > Cheers > Philippe > > > >

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Igor Stasenko

Btw, Esteban i wonder why you using sqUnixUUID.c in cocoa configs, while MacOS config using sqMacUUID.c which using mac-specific function to generate uuid. See Mac OS/plugins/UUIDPlugin/sqMacUUID.c and apparently don't have the problem with defines. -- Best regards, Igor Stasenko AKA sig.

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Igor Stasenko

I changed the MakeUUID in sqUnixUUID.c to look like following: int MakeUUID(char *location) { uuid_t uuid; #if defined(HAVE_UUIDGEN) uuidgen(&uuid, 1); #elif defined(HAVE_UUID_GENERATE) uuid_generate(uuid); #else #error "No uuid function provided" #endif memcpy((void *)location, (void *)&uuid, sizeof(uuid)); return 1; } and during compiling cocoa vms it fails with error. And before change the code was looking like following: int MakeUUID(char *location) { uuid_t uuid; #if defined(HAVE_UUIDGEN) uuidgen(&uuid, 1); #elif defined(HAVE_UUID_GENERATE) uuid_generate(uuid); #endif memcpy((void *)location, (void *)&uuid, sizeof(uuid)); return 1; } which means that if none HAVE_UUIDGEN or HAVE_UUID_GENERATE is defined, then there is nothing got called and memcpy then returns a random values on stack, copied from uuid to locaiton. And first version of that file just contains : int MakeUUID(char *location) { uuid_t uuid; uuid_generate(uuid); memcpy((void *)location, (void *)&uuid, sizeof(uuid)); return 1; } and then changed to: #if defined(__NetBSD__) uuidgen(&uuid, 1); #else uuid_generate(uuid); #endif and then changed to: #if defined(HAVE_UUIDGEN) uuidgen(&uuid, 1); #elif defined(HAVE_UUID_GENERATE) uuid_generate(uuid); #endif Blame: Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in heartbeat. Restore -O2 optimization for the interpreter. Author: eliot Date: 5 months ago Commit: 757297f62c32eaf2af7f26ce66aa6499df776749 -- Best regards, Igor Stasenko AKA sig.

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Esteban Lorenzano

Hi, I already fixed this bug, on cocoa vm's (5 minutes ago). I hope igor will check my changes and propagate them to unix/windows (it was, at least, present too on unix machines, but as I don't know which uuid library is correct for unix machines, I can not fix it myself) Philippe... I know it is lame... but if you want to recover your packages, all I can think is to re-save packages with new vm (or with primitive call removed) as I previous suggested. I'm sorry for the mess, I hope this is not drawing back the good energy all of us are putting in our projects. cheers, Esteban El 20/07/2011, a las 11:20a.m., Igor Stasenko escribiÃ³: > On 20 July 2011 14:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi Philippe, >> There is no need to be so dramatic :) >> it was not a *known* issue. >> Better: *I* knew it, because I found same problem last week. I thought it was a problem with my virtual machines, which is still not production released, just collecting issues -like this-, that's why I didn't ran to solve it. When you described the problem, I thought it was same bug... and that's why I started think it was a general UUID plugin bug... >> we are collecting this problems, and solving them as soon as we can... >> >> please, be a little patient, your feedback is very important to us. >> > > Esteban, i think this bug is introduced after merging the plugin > codebase by Andreas (cog-->squeak trunk) > >> cheers, >> Esteban >> >> El 20/07/2011, a las 3:36a.m., Philippe Marschall escribiÃ³: >> >>> 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 >>> >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 07/20/2011 03:59 PM, Torsten Bergmann wrote: > Hi Phillipe, > > software changes and (new) bugs can appear - thats life > and happens independent from Pharo or other technology. > > There is a simple rule: "If it is broken we should fix it" > and I would add "and make sure it wont bug us anymore again". > At least we should in minimum find such bugs before a release. > > Therefore attached is a simple test case that is green on my VM and > should be red on your VM. > > Let's integrate it into Pharo, you already know the usual procedure > to open an issue and I'm sure the Pharo team and VM maintainers will > take care. > > Simple as that ... > > Side note about recommending technologies and bug fixing: > > I once found a bug in Swing, others already reported it and > it is still after years(!) not fixed: > http://astares.blogspot.com/2007/01/disappointing-swing.html > So I have to wait and wait since I cant fix Swing myself... > > If this error would be in Smalltalk I would easily be able to change > it until it is officially fixed. So in Smalltalk I can easily move on > and it gives me the good feeling of beeing in control. > > Still Java is more recomended than Smalltalk. Why? Because > in the hopefully rare case a project really fails or is late > it could not have been the problem of choosing an exotic technology > since others use and recommend Java too (sometimes known as > the herd instinct) ;) Did the bug eat your code? Cheers Philippe

July 20, 2011