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