[Pharo-project] UUIDs not so unique
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
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
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
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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/
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration. To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk." Pro tip: if you want to be the obvious choice for professional development don't eat peoples code. Cheers Philippe
Pharo is not a few guys' project, it's everyone's who wants to join in :) Nevertheless, not everybody has enough time to do all the changes they wish to improve the system. So, you shouldn't be surprised if these things happen and they aren't fixed right away. Instead, if you really really want to collaborate with the project, don't get on your nerves and either submit an issue or help fixing it, I'm sure we'll all appreciate them both. Certainly there's a lot of work to do, but there's no magic in here, and this isn't the kind of thing you do from one day to another.... Cheers 2011/7/20 Philippe Marschall <philippe.marschall@netcetera.ch>
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration.
To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk."
Pro tip: if you want to be the obvious choice for professional development don't eat peoples code.
Cheers Philippe
Hi guys, If I might add, considering the fact that Pharo is putting **lots** of efforts into unit testing and automated builds using Hudson/Jenkins, we are getting closer to "as good as it gets" when you talk about stability of the image and serious testing and coverage. However, we can't trap every bug all the time, for every combination of image/VM/OS !!! If every time I caught a bug I would have used the argument "this is exactly the kind of shit that makes me want to never again use <whatever> in production", I would still work out of paper and pencil. No Oracle, no VisualAge, no VisualWorks, no Dolphin, no DB/2, no Windows, no Linux, no MS-Office, no OpenOffice, no MySQL, no Apache, no whateveryoucouldthinkabout... number of images * number of VMs * number of OSes = A LOT TO COVER AND TEST. Let's all keep that in mind... Besides, I still haven't found a single piece of software without a bug! Pharo ain't different. Gentlemen, back to your class browsers and let's make this thing even better! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
On 07/20/2011 03:09 PM, Benoit St-Jean wrote:
Hi guys,
If I might add, considering the fact that Pharo is putting **lots** of efforts into unit testing and automated builds using Hudson/Jenkins, we are getting closer to "as good as it gets" when you talk about stability of the image and serious testing and coverage. However, we can't trap every bug all the time, for every combination of image/VM/OS !!!
If every time I caught a bug I would have used the argument "this is exactly the kind of shit that makes me want to never again use <whatever> in production", I would still work out of paper and pencil. No Oracle, no VisualAge, no VisualWorks, no Dolphin, no DB/2, no Windows, no Linux, no MS-Office, no OpenOffice, no MySQL, no Apache, no whateveryoucouldthinkabout...
number of images * number of VMs * number of OSes = A LOT TO COVER AND TEST.
Let's all keep that in mind...
Besides, I still haven't found a single piece of software without a bug! Pharo ain't different.
Gentlemen, back to your class browsers and let's make this thing even better!
You realize the irony of asking people to write more code when they report that the SCM just broke on them? Cheers Philippe
I realize that counting all the time we all took to write all those emails filling up this thread, we surely would have had time to: 1) report the problem in the bug tracker 2) write a temporary fix 3) write unit tests to check for this bug 4) run the test suite 5) move on to something else (and wait for a "proper" fix) :) ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Philippe Marschall <philippe.marschall@netcetera.ch> To: pharo-project@lists.gforge.inria.fr Sent: Wed, July 20, 2011 10:00:23 AM Subject: Re: [Pharo-project] UUIDs not so unique On 07/20/2011 03:09 PM, Benoit St-Jean wrote:
Hi guys,
If I might add, considering the fact that Pharo is putting **lots** of efforts
into unit testing and automated builds using Hudson/Jenkins, we are getting closer to "as good as it gets" when you talk about stability of the image and serious testing and coverage. However, we can't trap every bug all the time, for every combination of image/VM/OS !!!
If every time I caught a bug I would have used the argument "this is exactly the
kind of shit that makes me want to never again use <whatever> in production", I
would still work out of paper and pencil. No Oracle, no VisualAge, no VisualWorks, no Dolphin, no DB/2, no Windows, no Linux, no MS-Office, no OpenOffice, no MySQL, no Apache, no whateveryoucouldthinkabout...
number of images * number of VMs * number of OSes = A LOT TO COVER AND TEST.
Let's all keep that in mind...
Besides, I still haven't found a single piece of software without a bug! Pharo
ain't different.
Gentlemen, back to your class browsers and let's make this thing even better!
You realize the irony of asking people to write more code when they report that the SCM just broke on them? Cheers Philippe
Philippe I can understand your frustration but been more negative than necessary does not help at all. first there is trust in what we are building. second there are humans = us. So when you forget that people are human beings you are losing something important. third there is positive energy. (how many times did we thanks esteban for his unpaied work on the vm we all use?) Thanks esteban for your great effort on the vm. fourth you can bash us if it makes you feel better, now I think that you have certainly better to do because I learned with time (getting wise probably) that it is better for my own soul to focus on good energy. Now consider that you can damage us more than useful or necessary. five let me repeat again: We are working hard, hard, hard and harder to deliver something good but shit can happen. We will improve the quality control of VM. Other people are right. My mac crash regularly on me. I lose regularly code, text, emails to the point that I thought that Pharo is quite more stable than my mac considering all the brain surgery I'm doing on it. Do you imagine that this bug is probably a vm bug due to a strange interaction with the OS version and some funky libraries? six we are aware that the more pharo will evolve the more people will have high expectations on it (no need to be sarcastic on that sentence) and the less we will have a chance to move it. But we will and we will make mistakes and learn from them. If we do not accept errors then better do nothing and watch TV. But I do not like watching TV so I will continue to be stupid and make mistakes. Sorry to not be smart enough. six
On 07/20/2011 08:31 PM, Stéphane Ducasse wrote:
Philippe
I can understand your frustration but been more negative than necessary does not help at all.
first there is trust in what we are building.
second there are humans = us. So when you forget that people are human beings you are losing something important.
third there is positive energy. (how many times did we thanks esteban for his unpaied work on the vm we all use?) Thanks esteban for your great effort on the vm.
fourth you can bash us if it makes you feel better, now I think that you have certainly better to do because I learned with time (getting wise probably) that it is better for my own soul to focus on good energy. Now consider that you can damage us more than useful or necessary.
Good energy is not going the fix the Seaside repository. Cheers Philippe
Good energy is not going the fix the Seaside repository.
Stop complaining. Let's build a Gofer script that resaves a series of versions. If we load each version from the last correct one and safe each over the existing one everything should be fine again. I can help, but I only have an iPhone available right now :-) Lukas -- Lukas Renggli www.lukas-renggli.ch
The attached *might* contain something of value - if so, help yourself to it. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Thursday, July 21, 2011 3:08 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] UUIDs not so unique
Good energy is not going the fix the Seaside repository.
Stop complaining. Let's build a Gofer script that resaves a series of versions. If we load each version from the last correct one and safe each over the existing one everything should be fine again. I can help, but I only have an iPhone available right now :-) Lukas -- Lukas Renggli www.lukas-renggli.ch
On 21.07.2011 09:08, Lukas Renggli wrote:
Good energy is not going the fix the Seaside repository.
Stop complaining.
Let's build a Gofer script that resaves a series of versions. If we load each version from the last correct one and safe each over the existing one everything should be fine again. I can help, but I only have an iPhone available right now :-)
Yeah, but we must not load the new versions using Monticello otherwise they'll be in the ancestry again. We must extract the source.st from the .mcz file and then file that in. However this will not work for removed/renamed methods or classes, they'll stay in the image. We could just unload the package but then we get undeclareds and we'd have to recompile all dependencies. Cheers Philippe
On 21.07.2011 21:03, Philippe Marschall wrote:
On 21.07.2011 09:08, Lukas Renggli wrote:
Good energy is not going the fix the Seaside repository.
Stop complaining.
Let's build a Gofer script that resaves a series of versions. If we load each version from the last correct one and safe each over the existing one everything should be fine again. I can help, but I only have an iPhone available right now :-)
Yeah, but we must not load the new versions using Monticello otherwise they'll be in the ancestry again. We must extract the source.st from the .mcz file and then file that in. However this will not work for removed/renamed methods or classes, they'll stay in the image. We could just unload the package but then we get undeclareds and we'd have to recompile all dependencies.
Also, you have to take care computing the ancestry because of the duplicate UUIDs. I guess for merges you could get away with following just one path. Cheers Philippe
On 20 July 2011 14:42, Philippe Marschall <philippe.marschall@netcetera.ch> wrote:
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration.
To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk."
Pro tip: if you want to be the obvious choice for professional development don't eat peoples code.
Philippe, you are using Cog VMs which are under development. Of course , we're all expecting that there is no regressions introduced. But sometimes this happens. This is normal for development process. So, you discovered a bug, which needs to be fixed. But blaming pharo for something, which we're not responsible for is a mistake. You should know better who to blame. Since you using "cog r2462", why you addressing your claims to Pharo instead of VM developers? Pharo images run on top of different VMs, and depending which one you using, you mileage could vary. Well, maybe it wasn't clear to you. But keep in mind, depending on what VM you using, you may have or not have bugs. At the end of this week (i hope) i will set up a test runners for VMs we're building, so we can automatically track regressions from change to change, including one you discovered. Feel free to submit an additional test for UUID to prevent this regression in a future. Something like: size := ((1 to: 100) collect: [ :i | UUID new asString ]) asSet size self assert: size = 100 and we will happily integrate it.
Cheers Philippe
-- Best regards, Igor Stasenko AKA sig.
On 07/20/2011 04:14 PM, Igor Stasenko wrote:
On 20 July 2011 14:42, Philippe Marschall <philippe.marschall@netcetera.ch> wrote:
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration.
To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk."
Pro tip: if you want to be the obvious choice for professional development don't eat peoples code.
Philippe, you are using Cog VMs which are under development. Of course , we're all expecting that there is no regressions introduced. But sometimes this happens. This is normal for development process. So, you discovered a bug, which needs to be fixed. But blaming pharo for something, which we're not responsible for is a mistake.
You should know better who to blame. Since you using "cog r2462", why you addressing your claims to Pharo instead of VM developers? Pharo images run on top of different VMs, and depending which one you using, you mileage could vary.
Well, maybe it wasn't clear to you. But keep in mind, depending on what VM you using, you may have or not have bugs.
So which WM do I have to use that when UUIDs don't work it's not my fault because I didn't fix the code? Cheers Philippe
On Wed, Jul 20, 2011 at 7:42 PM, Philippe Marschall <philippe.marschall@netcetera.ch> wrote:
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration.
To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk."
Pro tip: if you want to be the obvious choice for professional development don't eat peoples code.
Yes, you are right, this is a bit contradictory to ask for a high standard regarding the quality of the code and at the same time eating people (with different skills) code. But i guess, if you are too elitist, nobody will contribute to the project at the end. Most open-source software suffer from the same problem. The only solution is as a community enhance our knowledge in order to have better contributions. Having tools like Jenkins is quite important to have an immediate feedback and avoid regressions. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Some of us are happy using Pharo (1.4)... new product we are developing. Regards, Gary ----- Original Message ----- From: "Philippe Marschall" <philippe.marschall@netcetera.ch> To: <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, July 20, 2011 1:42 PM Subject: Re: [Pharo-project] UUIDs not so unique
On 07/20/2011 09:00 AM, Serge Stinckwich wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall <philippe.marschall@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.
And that is completely fine. But then you don't have to be surprised when people don't take you serious, you don't have more users and you don't have any enterprise penetration.
To quote from the project page: "We want Pharo to be the obvious choice for professional development in an open-source Smalltalk."
Pro tip: if you want to be the obvious choice for professional development don't eat peoples code.
Cheers Philippe
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
On Jul 20, 2011, at 6:54 AM, Camillo Bruni wrote:
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
Which is an adequate response unless it is also followed by another in wonder as to why people are not using Pharo more. :-) Scott
cami
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. 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
On 20 July 2011 14:29, Esteban Lorenzano <estebanlm@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.
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@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.
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.
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.
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.
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.
On 20 July 2011 17:15, Esteban Lorenzano <estebanlm@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.
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/ManPag... ). 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.
On 20 July 2011 17:31, Levente Uzonyi <leves@elte.hu> wrote:
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/ManPag... ). But the best solution is using the Mac OS platform files instead of the Unix ones for Mac OS.
Right, that's why i pointed Esteban to use mac-specific functions. Well, the problem was initially reported for unix builds. And why stopping compilation useless? It indicating the configuration error, while if we do as you proposing, then prim will always fail and UUID will work.. but then its a question, why we need uuid plugin at all, if it's not using any function for generating uuids? I prefer to have compilation error, than useless and malfunctioning plugin which does nothing.
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.
-- Best regards, Igor Stasenko AKA sig.
Le 19/07/2011 20:45, Philippe Marschall a écrit :
((1 to: 100) collect: [ :i | UUID new asString ]) asSet size
For me it produce a 100 size set. I am using Pharo 1.3 and a self compiled VM, the one I ship in DrGeo (VM version 4.0.3-2202). You may want to test with this VM https://gforge.inria.fr/frs/download.php/28574/DrGeo.app-11.06.zip Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire
participants (15)
-
Benoit St-Jean -
Camillo Bruni -
Clara Allende -
Esteban Lorenzano -
Gary Chambers -
Hilaire Fernandes -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Philippe Marschall -
Philippe Marschall -
Schwab,Wilhelm K -
Scott Gibson -
Serge Stinckwich -
Stéphane Ducasse