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, [email protected] 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 <[email protected]
<mailto:[email protected]>> 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
