View mode: basic / threaded / horizontal-split · Log in · Help
August 22, 2012
Vote for the new std.hash (oops, std.digest)
The discussion around new unified API for digest hash functions 
has subdued, just in time as the review period has ended.

The voting for std.digest package starts today and ends on 29 
August.

Rules are simple: reply in this thread with definite "YES" or 
"NO" on whether this package should go into Phobos. Including 
descriptive short notes is appreciated (esp. the NO ones).


Latest locations of docs and source:

Code: (location changed!)
https://github.com/jpf91/phobos/tree/newHash/std/digest
https://github.com/jpf91/phobos/compare/master...newHash

Docs: (location changed!)
http://dl.dropbox.com/u/24218791/d/phobos/std_digest_digest.html
http://dl.dropbox.com/u/24218791/d/phobos/std_digest_md.html
http://dl.dropbox.com/u/24218791/d/phobos/std_digest_sha.html
http://dl.dropbox.com/u/24218791/d/phobos/std_digest_crc.html
August 23, 2012
Re: Vote for the new std.hash (oops, std.digest)
Dmitry Olshansky wrote:
> The discussion around new unified API for digest hash functions has
> subdued, just in time as the review period has ended.
> 
> The voting for std.digest package starts today and ends on 29
> August.
> 
> Rules are simple: reply in this thread with definite "YES" or "NO"
> on whether this package should go into Phobos. Including descriptive
> short notes is appreciated (esp. the NO ones).
> 
> 
> Latest locations of docs and source:
> 
> Code: (location changed!)
> https://github.com/jpf91/phobos/tree/newHash/std/digest
> https://github.com/jpf91/phobos/compare/master...newHash
> 
> Docs: (location changed!)
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_digest.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_md.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_sha.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_crc.html
> 

YES.
I like it. The API is solid and future-proof for more digesting.
Many thanks Johannes.

Jens
August 23, 2012
Re: Vote for the new std.hash (oops, std.digest)
On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky 
wrote:
> The discussion around new unified API for digest hash functions 
> has subdued, just in time as the review period has ended.
>
> The voting for std.digest package starts today and ends on 29 
> August.
>
> Rules are simple: reply in this thread with definite "YES" or 
> "NO" on whether this package should go into Phobos. Including 
> descriptive short notes is appreciated (esp. the NO ones).
>
>
> Latest locations of docs and source:
>
> Code: (location changed!)
> https://github.com/jpf91/phobos/tree/newHash/std/digest
> https://github.com/jpf91/phobos/compare/master...newHash
>
> Docs: (location changed!)
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_digest.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_md.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_sha.html
> http://dl.dropbox.com/u/24218791/d/phobos/std_digest_crc.html

Can all the algorithms work at compile time (given immutable 
constant data, e.g. a string) ? YES : NO.

Hope that's descriptive.
August 23, 2012
Re: Vote for the new std.hash (oops, std.digest)
On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky 
wrote:
> The discussion around new unified API for digest hash functions 
> has subdued, just in time as the review period has ended.

Yes.
August 23, 2012
Re: Vote for the new std.hash (oops, std.digest)
d_follower wrote:
> On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky
> wrote:
> >The discussion around new unified API for digest hash functions
> >has subdued, just in time as the review period has ended.
> >
> >The voting for std.digest package starts today and ends on 29
> >August.
> >
> >Rules are simple: reply in this thread with definite "YES" or "NO"
> >on whether this package should go into Phobos. Including
> >descriptive short notes is appreciated (esp. the NO ones).
> >
> >
> >Latest locations of docs and source:
> >
> >Code: (location changed!)
> >https://github.com/jpf91/phobos/tree/newHash/std/digest
> >https://github.com/jpf91/phobos/compare/master...newHash
> >
> >Docs: (location changed!)
> >http://dl.dropbox.com/u/24218791/d/phobos/std_digest_digest.html
> >http://dl.dropbox.com/u/24218791/d/phobos/std_digest_md.html
> >http://dl.dropbox.com/u/24218791/d/phobos/std_digest_sha.html
> >http://dl.dropbox.com/u/24218791/d/phobos/std_digest_crc.html
> 
> Can all the algorithms work at compile time (given immutable
> constant data, e.g. a string) ? YES : NO.

It says "Digests do not work in CTFE".
Just checked it for MD5.
I do not know but I think this is just a current limitation of the CTFE
implementation.

Jens
August 23, 2012
Re: Vote for the new std.hash (oops, std.digest)
Yes.

The API seems fairly solid to me, and the
need for these things is fairly wide reaching.
August 24, 2012
Re: Vote for the new std.hash (oops, std.digest)
Am Thu, 23 Aug 2012 22:46:35 +0200
schrieb Jens Mueller <jens.k.mueller@gmx.de>:

> 
> It says "Digests do not work in CTFE".
> Just checked it for MD5.
> I do not know but I think this is just a current limitation of the
> CTFE implementation.

It's possible to support CTFE, Piotr Szturmaj has some digests which
work in CTFE. But it's difficult as everything which depends on
endianness isn't supported in CTFE.

https://github.com/pszturmaj/phobos/commit/d06c258b442c5b59ab3a66125c9aea8a4c00a0b7

take for example the setByte function:
a[offset / E.sizeof] |= value << ((offset % E.sizeof) * 8);
This is necessary because you can't cast from uint to ubyte[4] in CTFE.
August 24, 2012
Re: Vote for the new std.hash (oops, std.digest)
Johannes Pfau wrote:
> Am Thu, 23 Aug 2012 22:46:35 +0200
> schrieb Jens Mueller <jens.k.mueller@gmx.de>:
> 
> > 
> > It says "Digests do not work in CTFE".
> > Just checked it for MD5.
> > I do not know but I think this is just a current limitation of the
> > CTFE implementation.
> 
> It's possible to support CTFE, Piotr Szturmaj has some digests which
> work in CTFE. But it's difficult as everything which depends on
> endianness isn't supported in CTFE.
> 
> https://github.com/pszturmaj/phobos/commit/d06c258b442c5b59ab3a66125c9aea8a4c00a0b7
> 
> take for example the setByte function:
> a[offset / E.sizeof] |= value << ((offset % E.sizeof) * 8);
> This is necessary because you can't cast from uint to ubyte[4] in CTFE.

I see.
Though I do not understand that limitation of CTFE. Since D has
version(LittleEndian) and version(BigEndian) and CTFE should follow
versioning I see no reason why casts that depend on endianness should
not be supported. When writing a function you have to care about
endianness anyway.

Jens
August 24, 2012
Re: Vote for the new std.hash (oops, std.digest)
Yes
August 24, 2012
Re: Vote for the new std.hash (oops, std.digest)
On Friday, 24 August 2012 at 08:18:07 UTC, Johannes Pfau wrote:
> Am Thu, 23 Aug 2012 22:46:35 +0200
> schrieb Jens Mueller <jens.k.mueller@gmx.de>:
>
>> 
>> It says "Digests do not work in CTFE".
>> Just checked it for MD5.
>> I do not know but I think this is just a current limitation of 
>> the
>> CTFE implementation.
>
> It's possible to support CTFE, Piotr Szturmaj has some digests 
> which
> work in CTFE. But it's difficult as everything which depends on
> endianness isn't supported in CTFE.
>

Writing a library which is good enough to belong to std IS 
difficult.
With D's incredibly powerful compile-time capabilities, I'm 100% 
many people will wonder why such a pure functionality as digest 
doesn't work with CTFE.

As long as the interface itself allows future CTFE support, and 
the work is planned that's a YES from me.

But I'd like to see at least one algorithm being implemented 
(e.g. CRC32 which currently works with CTFE) as a proof of 
concept (and a unit-test).
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home