On Tue, Feb 9, 2016 at 11:53 PM, stepharo <[email protected]> wrote: > > > Le 9/2/16 09:58, Sven Van Caekenberghe a écrit : >> >> I can do the integration too, but I need some people to say go ahead. >> I vote for replacing everything, there is no need for a plugin. > > > me too. > Less plugin!
This is a good general philosophy, but we should benchmark in-image versus plugin so we can make an informed analytical decision on how much performance we are willing to trade for the convenience of it being all in-image, and whether we want to maintain a separate CI job for keeping the plugin tested. Overriding that is providing a quick fix so other development is not blocked, which however Guille's solution seems sufficient for the code freeze of Pharo 5. cheers -ben > > >> >>> On 09 Feb 2016, at 09:25, Guille Polito <[email protected]> >>> wrote: >>> >>> Sven, just to answer your last question. The UUID generation right now >>> generates the UUID fields like this: >>> >>> UUIDGenerator>>generateFieldsVersion4 >>> >>> timeLow := self generateRandomBitsOfLength: 32. >>> timeMid := self generateRandomBitsOfLength: 16. >>> timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: >>> 12). >>> clockSeqHiAndReserved := 16r80 bitOr: (self >>> generateRandomBitsOfLength: 6). >>> clockSeqLow := self generateRandomBitsOfLength: 8. >>> node := self generateRandomBitsOfLength: 48. >>> >>> So... It's basically completely random. There is no part of the UUID that >>> is actually based on the node, the clock or the time. It is actually a >>> random string of bits that are generated using a number from /dev/urandom as >>> seed (in linux). >>> >>> Does the mac VM include the plugin? (I do not have a mac any more to test >>> fast ^^) >>> >>> I'll work on the integration of NeoUUID now, I hope this is the kind of >>> issues that got integrated in code-freeze :) >>> >>> Guille >>> >>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >>>> >>>> Here is a new version, in preparation of possible integration in the >>>> main image: >>>> >>>> === >>>> Name: Neo-UUID-SvenVanCaekenberghe.2 >>>> Author: SvenVanCaekenberghe >>>> Time: 8 February 2016, 8:33:04.141334 pm >>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >>>> >>>> Streamline UUID generation >>>> >>>> Add a current, shared instance >>>> >>>> Added better class and method comments >>>> >>>> Add more tests >>>> >>>> As suggested by Henrik Johansen, change to a version 0 UUID to indicate >>>> that we follow a custom approach >>>> === >>>> >>>> The class comments now reads as follows: >>>> >>>> === >>>> I am NeoUUIDGenerator, I generate UUIDs. >>>> >>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit >>>> number that can be used for identification purposes. Concretely, a UUID is >>>> a >>>> 16 element byte array. >>>> >>>> The intent of UUIDs is to enable distributed systems to uniquely >>>> identify information without significant central coordination. In this >>>> context the word unique should be taken to mean "practically unique" rather >>>> than "guaranteed unique". >>>> I generate UUIDs similar, in spirit, to those defined in RFC4122, >>>> though I use version 0 to indicate that I follow none of the defined >>>> versions. This does not matter much, if at all, in practice. >>>> >>>> I try to conform to the following aspects: >>>> - each 'node' (machine, image, instance) should generate unique UUIDs >>>> - even when generating UUIDs at a very fast rate, they should remain >>>> unique >>>> - be fast and efficient >>>> >>>> To achieve this goal, I >>>> - take several aspects into account to generate a unique node ID >>>> - combine a clock, a counter and some random bits >>>> - hold a state, protected for multi user access >>>> >>>> I can generate about 500K UUIDs per second. >>>> >>>> Implementation: >>>> >>>> Although a UUID should be seen as totally opaque, here is the concrete >>>> way I generate one: >>>> - the first 8 bytes are the millisecond clock value with the smallest >>>> quantity first; this means that the later of these 8 bytes will be >>>> identical >>>> when generated with small(er) timespans; within the same millisecond, the >>>> full first 8 bytes will be identical >>>> - the next 2 bytes represent a counter with safe overflow, held as >>>> protected state inside me; after 2*16 this value will repeat; the counter >>>> initalizes with a random value >>>> - the next 2 bytes are simply random, based on the system PRNG, Random >>>> - the final 4 bytes represent the node ID; the node ID is unique per >>>> instance of me, across OS environments where the image might run; the node >>>> ID is the MD5 hash of a string that is the concatenation of several >>>> elements >>>> (see #computeNodeIdentifier) >>>> Some bits are set to some predefined value, to indicate the variant >>>> and version (see #setVariantAndVersion:) >>>> >>>> Usage: >>>> >>>> NeoUUIDGenerator next. >>>> NeoUUIDGenerator current next. >>>> NeoUUIDGenerator new next. >>>> >>>> Sharing an instance is more efficient and correct. >>>> Instances should be reset whenever the image comes up. >>>> >>>> See also: >>>> >>>> http://en.wikipedia.org/wiki/UUID >>>> https://tools.ietf.org/html/rfc4122 >>>> === >>>> >>>> If we integrate this, I think we should replace the old generator and >>>> the use of the primitive/plugin. But that requires at least some support >>>> apart from me. >>>> >>>> And although I think that we should integrate this generator and get rid >>>> of the plugin, I think there is probably an underlying problem here (why >>>> did >>>> the generator fail ?) that could be important to find. >>>> >>>> Sven >>>> >>>>> On 08 Feb 2016, at 10:38, Henrik Johansen >>>>> <[email protected]> wrote: >>>>> >>>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <[email protected]> wrote: >>>>>> >>>>>>> 2) Misrepresenting the way the UUID was generated (a combination of >>>>>>> node identifier + timestamp + random value, similar to type 3, but with >>>>>>> differently sized/ordered fields) by marking it as being of type 4, >>>>>>> which is >>>>>>> defined to be UUID consisting of random bytes. >>>>>>> IOW, I think it should be marked as type 0 instead of 4, so for the 1 >>>>>>> person in each country who might be found to assume something about the >>>>>>> implementation based on the type field, won't later feel he's been duped >>>>>>> when checking the generator. >>>>>> >>>>>> OK, I certainly want to change the type. Thing is, I cannot find a >>>>>> reference to type 0 anywhere that I am looking (I mostly used >>>>>> https://en.wikipedia.org/wiki/Universally_unique_identifier). Where did >>>>>> you >>>>>> find a definition of type 0 ? Or would that be a way to say 'no specific >>>>>> type' then ? >>>>> >>>>> My rationale was that it is currently unassigned, and the least likely >>>>> number to be chosen as identifier by new versions of the standard. >>>>> IOW, for those who care, it might raise a "hmm, this is strange, better >>>>> check the source", upon which they will discover it is generated in a >>>>> non-standard fashion (but can verify for themselves it is generated in a >>>>> way >>>>> still pretty much guaranteed to be unique), and the rest... well, they can >>>>> (most probably) keep on living happily without ever seeing a collision. >>>>> >>>>> Cheers, >>>>> Henry >> >> >> > >
