View mode: basic / threaded / horizontal-split · Log in · Help
June 10, 2012
Re: std.uuid: Ranges as parser input
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
June 10, 2012
Re: Review: std.uuid
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
June 11, 2012
std.uuid: Update 2
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)
June 12, 2012
Re: std.uuid: Update 3
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.
June 12, 2012
Re: std.uuid: Update 3
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
June 12, 2012
Re: std.uuid: Update 3
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.
June 12, 2012
Re: std.uuid: Update 3
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?
June 12, 2012
Re: std.uuid: Update 3
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.
June 12, 2012
Re: std.uuid: Update 3
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
June 13, 2012
Re: Review: std.uuid
If we use all caps for abbreviations then the names should be 
SHA1UUID, MD5UUID and UUIDVersion?
1 2 3 4 5
Top | Discussion index | About this forum | D home