August 22, 2012
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
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
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
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
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
Yes.

The API seems fairly solid to me, and the
need for these things is fairly wide reaching.
August 24, 2012
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
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
Yes
August 24, 2012
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