Smalltalk › Pharo › Pharo Smalltalk Developers

UUID Plugin ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Sven Van Caekenberghe-2

UUID Plugin ?

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

philippeback

Re: UUID Plugin ?

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 <[hidden email]> 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

UUID10-02-16 12-22-38.png (369K) Download Attachment

Guillermo Polito

Re: UUID Plugin ?

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, [hidden email] 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 <[hidden email]> 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

David T. Lewis

Re: UUID Plugin ?

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

Sven Van Caekenberghe-2

Re: UUID Plugin ?

> On 10 Feb 2016, at 15:07, David T. Lewis <[hidden email]> 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.

Marcus Denker-4

Re: UUID Plugin ?

> On 10 Feb 2016, at 18:25, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 10 Feb 2016, at 15:07, David T. Lewis <[hidden email]> 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

Marcus Denker-4

Re: UUID Plugin ?

> On 10 Feb 2016, at 23:11, Marcus Denker <[hidden email]> wrote:
>
>
>> On 10 Feb 2016, at 18:25, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>
>>> On 10 Feb 2016, at 15:07, David T. Lewis <[hidden email]> 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