Am Sun, 10 Jun 2012 07:22:21 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 6/10/2012 2:05 AM, Johannes Pfau wrote:
> > Am Sat, 09 Jun 2012 23:06:25 -0700
> >> Great! My initial suggestion is that the parsing routines should accept input ranges, rather just arrays.
> >>
> >
> > That could be done, but I currently keep the complete input string in the ParserException. That wouldn't be possible if the parser has to operate on an InputRange. It could work with a ForwardRange, but converting the Range back to a string wouldn't be very efficient. This would work best with some kind of BufferedRange/Stream concept.
> >
> > I'm just wondering whether it really makes sense to use ranges in this case. The text representation of UUIDs is usually exactly 36 characters long (for the simple parser it must be exactly 36 characters), so when using some kind of range interface and std.uuid it should be easy enough to read the UUID string into a stack buffer, then pass it to std.uuid.
> >
> > But if it's really desired, I can sure add an implementation using ForwardRanges.
> 
> I can see it wouldn't make sense for the simple parser, but for the more general one it may. You can also specialize the more general parser for arrays, so there won't be the overhead of making a copy.

OK I'll do that

On Sunday, 10 June 2012 at 11:00:51 UTC, Johannes Pfau wrote:
> Am Sun, 10 Jun 2012 12:03:15 +0200
> schrieb "Jonas Drewsen" <jdrewsen@nospam.com>:
>
>> When looking at the associated RFC I noticed that a UUID can contain e.g. timestap, clock, node fields. What about providing properties that could return these fields?
>
> Why would you need those? A UUID only needs to be unique, which is
> guaranteed by those node, timestamp and clock fields. But the exact
> value of node, timestamp, clock is never important, as long as it's
> unique. std.uuid can't create version 1&2 uuids so we never have to set
> these fields either.

I do not know actually. If you believe that they are not usable anyway then please ignore my suggestion.

>> It would also be nice to have an index in the top of the page like std.algorithm has.
>
> OK, I'll have a look at that.

Great

/Jonas

Am Sun, 10 Jun 2012 18:49:03 +0200
schrieb Johannes Pfau <nospam@example.com>:

> Am Sat, 09 Jun 2012 21:30:57 +0400
> schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:
> > Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
> 
> I pushed these changes suggested by Dmitry Olshansky and Jonas Drewsen:
> 
> * Add documentation table
> * Rename UUID.isNil --> UUID.empty
> * Merge ParserException and IsufficientInputException into
>   UUIDParserException
> * Add note about std.variant.Variant
> * Rewrite example to avoid cast
> * Add non-working(commented out) variadic constructor
> * Rename extractRegex --> uuidRegex
> * Use std.algorithm.swap instead of swapRanges

* parseUUID now supports InputRanges with ElementType == dchar (all
  string types are still supported as well)

Am Mon, 11 Jun 2012 13:12:49 +0200
schrieb Johannes Pfau <nospam@example.com>:

> Am Sun, 10 Jun 2012 18:49:03 +0200
> schrieb Johannes Pfau <nospam@example.com>:
> 
> > Am Sat, 09 Jun 2012 21:30:57 +0400
> > schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:
> > > Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
> > 
> > I pushed these changes suggested by Dmitry Olshansky and Jonas Drewsen:
> > 
> > * Add documentation table
> > * Rename UUID.isNil --> UUID.empty
> > * Merge ParserException and IsufficientInputException into
> >   UUIDParserException
> > * Add note about std.variant.Variant
> > * Rewrite example to avoid cast
> > * Add non-working(commented out) variadic constructor
> > * Rename extractRegex --> uuidRegex
> > * Use std.algorithm.swap instead of swapRanges
> 
> * parseUUID now supports InputRanges with ElementType == dchar (all
>   string types are still supported as well)
> 
> 

* randomUUID now creates the RNG only once per thread.
* randomUUID lazily seeds the RNG once (per thread) on the first
  function call
* randomUUID now uses the new seed overload (requires
  https://github.com/D-Programming-Language/phobos/pull/627 )
* the unsafe randomUUID overload taking only a type has been removed.

On 12.06.2012 15:46, Johannes Pfau wrote:
> Am Mon, 11 Jun 2012 13:12:49 +0200
> schrieb Johannes Pfau<nospam@example.com>:
>
>> Am Sun, 10 Jun 2012 18:49:03 +0200
>> schrieb Johannes Pfau<nospam@example.com>:
>>
>>> Am Sat, 09 Jun 2012 21:30:57 +0400
>>> schrieb Dmitry Olshansky<dmitry.olsh@gmail.com>:
>>>> Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
>>>> API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
>>>
>>> I pushed these changes suggested by Dmitry Olshansky and Jonas
>>> Drewsen:
>>>
>>> * Add documentation table
>>> * Rename UUID.isNil -->  UUID.empty
>>> * Merge ParserException and IsufficientInputException into
>>>    UUIDParserException
>>> * Add note about std.variant.Variant
>>> * Rewrite example to avoid cast
>>> * Add non-working(commented out) variadic constructor
>>> * Rename extractRegex -->  uuidRegex
>>> * Use std.algorithm.swap instead of swapRanges
>>
>> * parseUUID now supports InputRanges with ElementType == dchar (all
>>    string types are still supported as well)
>>
>>
>
> * randomUUID now creates the RNG only once per thread.
> * randomUUID lazily seeds the RNG once (per thread) on the first
>    function call
> * randomUUID now uses the new seed overload (requires
>    https://github.com/D-Programming-Language/phobos/pull/627 )
> * the unsafe randomUUID overload taking only a type has been removed.
>

Judging by the swift rate of fixes and keeping in mind that it's only ~1.5 KLOC with abundance of unit tests I'm tempted to suggest the following.

Let's trim the review time span a bit, so that review ends at 18-19 June and voting ends at 25-26 June. That's, of course, given that you and others don't mind it.

How does it sound?

-- 
Dmitry Olshansky

There are some references to a nilUUID left and the intro says, that UUIDs default to nil. I'd recommend not to use nil at all and instead talk about an empty UUID or UUID.init. The intro should state that an UUID is empty iff it eqauls UUID.init and that UUID.init is an UUID with all bytes zero.

Am Tue, 12 Jun 2012 14:24:15 +0200
schrieb "Tobias Pankrath" <tobias@pankrath.net>:

> There are some references to a nilUUID left and the intro says, that UUIDs default to nil. I'd recommend not to use nil at all and instead talk about an empty UUID or UUID.init. The intro should state that an UUID is empty iff it eqauls UUID.init and that UUID.init is an UUID with all bytes zero.

oops. The references to nil definitely have to go. Thanks for letting me know.

Do you mean I should also drop nilUUID completely and use UUID.init instead everywhere in the module?

Am Tue, 12 Jun 2012 16:15:48 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> 
> Judging by the swift rate of fixes and keeping in mind that it's only ~1.5 KLOC with abundance of unit tests I'm tempted to suggest the following.
> 
> Let's trim the review time span a bit, so that review ends at 18-19 June and voting ends at 25-26 June. That's, of course, given that you and others don't mind it.
> 
> How does it sound?
> 

Sure, sounds good to me.

On 12.06.2012 18:18, Johannes Pfau wrote:
> Am Tue, 12 Jun 2012 16:15:48 +0400
> schrieb Dmitry Olshansky<dmitry.olsh@gmail.com>:
>
>>
>> Judging by the swift rate of fixes and keeping in mind that it's only
>> ~1.5 KLOC with abundance of unit tests I'm tempted to suggest the
>> following.
>>
>> Let's trim the review time span a bit, so that review ends at 18-19
>> June and voting ends at 25-26 June. That's, of course, given that you
>> and others don't mind it.
>>
>> How does it sound?
>>
>
> Sure, sounds good to me.

Great! I'll wait a day or two just to make sure there is no opposition among reviewers :)

-- 
Dmitry Olshansky

If we use all caps for abbreviations then the names should be SHA1UUID, MD5UUID and UUIDVersion?