On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito@gmail.com> wrote:

Good news, so far, installing NeoUUID and replacing UUID class >> new by:

UUID class >> new
^NeoUUIDGenerator new next

seems to work. At it looks that I can trust again my commits.

Thanks Sven :)

OK.

Now, the idea is that one instance of the generator is kept around, this is way more efficient, but also more correct, as the random generator should not be created anew each time.

Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine...

I seriously doubt the plugin is better (more random, more unique) then anything that we can do in Pharo itself. I like Pharo code way better, because we all see what it does.

Anyone else with an opinion ?

More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin.

More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc).

A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes)

As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least):

<primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'>

(which, iirc, resolves to the same platform primitives as UUID lib)

Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous.