I am not sure we got the root cause of the UUID problem. Guille wrote:
AAAANNNDDD! It looks I found the real cause of this!
- I tested an image pre-new session manager, and an image post-new session manager. The issue only appeared in the latter.
- Checking, it seems that UUIDGenerator is not subscribed to the new startup list. This means that the UUIDGenerator is not being reinitialized on every startup. This means, moreover, that every person that is loading the latest Pharo image is using the same UUIDGenerator instance, with the same random seed => same generated UUIDs.
Yes, that is correct. But ... UUID new ends up calling UUID>>#primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4. On my machines/VMs/images the primitive works. Which means the UUIDGenerator is not needed, I can just as well throw it away. So it does not matter whether it is initialised correctly or not. So the next question is: why does the primitive not work for some people ? Was it like that forever ? I don't think we want that kind of platform difference. This really is misleading and confusion. Sven
The code is different for each platform... See screenshot. There is a CoCreateGuid thing in Windows... For unix, depends on what is on the platform. Can of worms in need of unification indeed. But as UUIDs are using underlying system things, hard to do. Phil On Wed, Feb 10, 2016 at 11:28 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not sure we got the root cause of the UUID problem.
Guille wrote:
AAAANNNDDD! It looks I found the real cause of this!
- I tested an image pre-new session manager, and an image post-new session manager. The issue only appeared in the latter.
- Checking, it seems that UUIDGenerator is not subscribed to the new startup list. This means that the UUIDGenerator is not being reinitialized on every startup. This means, moreover, that every person that is loading the latest Pharo image is using the same UUIDGenerator instance, with the same random seed => same generated UUIDs.
Yes, that is correct. But ...
UUID new
ends up calling
UUID>>#primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4.
On my machines/VMs/images the primitive works. Which means the UUIDGenerator is not needed, I can just as well throw it away. So it does not matter whether it is initialised correctly or not.
So the next question is: why does the primitive not work for some people ? Was it like that forever ? I don't think we want that kind of platform difference.
This really is misleading and confusion.
Sven
Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed. On 02/10/2016 12:25 PM, phil@highoctane.be wrote:
The code is different for each platform... See screenshot.
There is a CoCreateGuid thing in Windows...
For unix, depends on what is on the platform.
Can of worms in need of unification indeed. But as UUIDs are using underlying system things, hard to do.
Phil
On Wed, Feb 10, 2016 at 11:28 AM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
I am not sure we got the root cause of the UUID problem.
Guille wrote:
> AAAANNNDDD! It looks I found the real cause of this! > > - I tested an image pre-new session manager, and an image post-new session manager. The issue only appeared in the latter. > > - Checking, it seems that UUIDGenerator is not subscribed to the new startup list. This means that the UUIDGenerator is not being reinitialized on every startup. This means, moreover, that every person that is loading the latest Pharo image is using the same UUIDGenerator instance, with the same random seed => same generated UUIDs.
Yes, that is correct. But ...
UUID new
ends up calling
UUID>>#primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4.
On my machines/VMs/images the primitive works. Which means the UUIDGenerator is not needed, I can just as well throw it away. So it does not matter whether it is initialised correctly or not.
So the next question is: why does the primitive not work for some people ? Was it like that forever ? I don't think we want that kind of platform difference.
This really is misleading and confusion.
Sven
On Wed, Feb 10, 2016 at 02:46:23PM +0100, Guille Polito wrote:
Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed.
For background - the UUID plugin is trivially simple, but there were issues on certain Linux distributions that caused it to be a big pain for packaging and distribution. Nowadays the in-image UUID is so fast that the plugin is no longer worth the aggrivation. Dave
On 10 Feb 2016, at 15:07, David T. Lewis <lewis@mail.msen.com> wrote:
On Wed, Feb 10, 2016 at 02:46:23PM +0100, Guille Polito wrote:
Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed.
For background - the UUID plugin is trivially simple, but there were issues on certain Linux distributions that caused it to be a big pain for packaging and distribution. Nowadays the in-image UUID is so fast that the plugin is no longer worth the aggrivation.
Dave
Thanks for adding to the discussion, Dave. <Not meant for the messenger/> This whole f*ing mess makes me angry and sad. This happens when you don't clean up when you can.
On 10 Feb 2016, at 18:25, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Feb 2016, at 15:07, David T. Lewis <lewis@mail.msen.com> wrote:
On Wed, Feb 10, 2016 at 02:46:23PM +0100, Guille Polito wrote:
Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed.
For background - the UUID plugin is trivially simple, but there were issues on certain Linux distributions that caused it to be a big pain for packaging and distribution. Nowadays the in-image UUID is so fast that the plugin is no longer worth the aggrivation.
Dave
Thanks for adding to the discussion, Dave.
<Not meant for the messenger/>
This whole f*ing mess makes me angry and sad. This happens when you don't clean up when you can.
One thing that I still do not understand from back when I tried to contribute to Squeak was that âcleaningâ was not only discouraged but even *actively* made impossible. I still do not understand the reason. Cui Bono? It just destroyed having *any* form of future⦠the thing that we, allegedly, where trying to invent⦠Marcus
On 10 Feb 2016, at 23:11, Marcus Denker <marcus.denker@inria.fr> wrote:
On 10 Feb 2016, at 18:25, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Feb 2016, at 15:07, David T. Lewis <lewis@mail.msen.com> wrote:
On Wed, Feb 10, 2016 at 02:46:23PM +0100, Guille Polito wrote:
Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed.
For background - the UUID plugin is trivially simple, but there were issues on certain Linux distributions that caused it to be a big pain for packaging and distribution. Nowadays the in-image UUID is so fast that the plugin is no longer worth the aggrivation.
Dave
Thanks for adding to the discussion, Dave.
<Not meant for the messenger/>
This whole f*ing mess makes me angry and sad. This happens when you don't clean up when you can.
One thing that I still do not understand from back when I tried to contribute to Squeak was that âcleaningâ was not only discouraged but even *actively* made impossible.
I still do not understand the reason. Cui Bono? It just destroyed having *any* form of future⦠the thing that we, allegedly, where trying to inventâ¦
Ah, and, sorry, I normally never wanted to write emails like that. Please just ignore. Marcus
participants (5)
-
David T. Lewis -
Guille Polito -
Marcus Denker -
phil＠highoctane.be -
Sven Van Caekenberghe