View mode: basic / threaded / horizontal-split · Log in · Help
August 09, 2012
Re: The review of std.hash package
On 2012-08-09 15:02, Johannes Pfau wrote:

> What annoys me is that as long the function only supported arrays, it
> didn't need templates _at all_. So template bloat for arrays = 0. But
> adding range support means the version dealing with arrays now has to
> be a template as well(which is probably a bug, can't overload template
> and non template function) and will produce extra code for every array
> type. I just think adding range support shouldn't cause the array code
> to change in any way.

A workaround is to make the non-template function to a template, with no 
arguments. This should only cause one instantiation:

void foo (T) (T t) if (/* some constraint making it not match "int" */);
void foo () (int x);

-- 
/Jacob Carlborg
August 09, 2012
Re: The review of std.hash package
On 09-Aug-12 14:15, Regan Heath wrote:
> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at>

> If the range/hash object stores the current state and returns this as
> the result of hashreduce, it would be chainable.  If it also had a
> "Digest" property/method which performed finish on a /temporary copy/ of
> the state it would almost be as automatic as reduce.  There would still
> be a manual step to get the result, but it would be analogous to calling
> toString on any range object to output it's "value".  The Digest
> property/method would not modify the internal state, and could be called
> at any time between (not sure there is a point to this) or after chained
> hashreduce operations.

struct ShaState
{
	...
	alias ubyte[16] getDidgest();
}

Problem is: too much magic, spoils auto x = reduce(...); idiom.

To be brutally honest I don't see what in std.hash doesn't fit "range 
component" model:
	- it works on input ranges via convenient adaptor (or would work soon)
	- it has output _ranges_.

What's not to like about it? That it doesn't fit general reduce 
algorithm? I'm not convinced it's important. In the same vane you may 
try to shoehorn symmetric cyphers to follow map interface because 
conceptually it does 1:1 conversion.

Now important thing: just look at other output ranges.
They either require extra call (see Appender .data) or horrendously slow 
and ugly see lockingTextWriter/Reader.

-- 
Dmitry Olshansky
August 09, 2012
Re: The review of std.hash package
On 09-Aug-12 20:32, Dmitry Olshansky wrote:
> On 09-Aug-12 14:15, Regan Heath wrote:
>> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at>
>
>> If the range/hash object stores the current state and returns this as
>> the result of hashreduce, it would be chainable.  If it also had a
>> "Digest" property/method which performed finish on a /temporary copy/ of
>> the state it would almost be as automatic as reduce.  There would still
>> be a manual step to get the result, but it would be analogous to calling
>> toString on any range object to output it's "value".  The Digest
>> property/method would not modify the internal state, and could be called
>> at any time between (not sure there is a point to this) or after chained
>> hashreduce operations.
>
> struct ShaState
> {
>      ...
>      alias ubyte[16] getDidgest();
> }

Too fast.. should have been:
	ubyte[16] getDidgest();
	alias getDigest this;

-- 
Dmitry Olshansky
August 09, 2012
Re: The review of std.hash package
On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky 
wrote:
> Too fast.. should have been:
> 	ubyte[16] getDidgest();
> 	alias getDigest this;

I have been thinking about using AliasThis as well, but the 
problem is that precisely the use case this is meant to enable 
(i.e. »snapping together components«, like Walter said) tends 
to get broken in subtle ways due to the use of template 
functions/type inference.

David
August 09, 2012
Re: The review of std.hash package
On Thursday, August 09, 2012 18:46:59 David Nadlinger wrote:
> On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky
> 
> wrote:
> > Too fast.. should have been:
> > ubyte[16] getDidgest();
> > alias getDigest this;
> 
> I have been thinking about using AliasThis as well, but the
> problem is that precisely the use case this is meant to enable
> (i.e. »snapping together components«, like Walter said) tends
> to get broken in subtle ways due to the use of template
> functions/type inference.

Yeah. alias this can be very useful, but it's very dangerous when it comes to 
templated functions, because it's very easy to make assumptions when writing 
those functions which hold great when using the actual type but do funny 
things when alias this comes into play. And unfortunately, I don't think that 
it's something that's at all well understood. It's probably one of those 
things that we as a community need to get a better grip on. Just imagine how 
bad it would be though if D allowed as many implicit conversions as C++ 
does...

- Jonathan M Davis
August 10, 2012
std.hash review: Update 1
I implemented some of the suggestions, here's the list of changes:

Changelog:
* Add a new overload to the 'digest' function which accepts an
 InputRange
* Add a new convenience function 'hexDigest' which works just like
 'digest', but returns a string (also works with InputRanges)

 An open question is whether md5StringOf/md5HexOf aliases should be
 added (similar to md5Of)?
* Add a new convenience function 'startDigest' which returns an
 initialized digest
* New example for file hashing in idiomatic D
* Documented that Digests are always OutputRanges
* Added new examples using std.algorithm.copy & OutputRange interface
* Small optimization in toHexString & hexDigest: do not allocate if
 possible

TODO:
* move the package to std.digest (unless there are objections):
   std.hash.hash --> std.digest.digest
   std.hash.md   --> std.digest.md
   std.hash.sha  --> std.digest.sha
   std.hash.crc  --> std.digest.crc

* make sure the docs are consistent regarding names (digest vs. hash)


Code:
https://github.com/jpf91/phobos/tree/newHash/std/hash
https://github.com/jpf91/phobos/compare/master...newHash

Docs:
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_hash.html
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_md.html
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_sha.html
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_crc.html
August 12, 2012
Re: The review of std.hash package
See the new thread Andrei started entitled "finish function for output ranges". 
I think this discussion has clearly discovered a shortcoming in the current 
range design, and Andrei has a proposed solution.
August 15, 2012
Re: The review of std.hash package
On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote:
>> In this case, it needs to work like a reduce algorithm, 
>> because it is a reduce algorithm. Need to find a way to make 
>> this work.
>
> Hash functions are _not_ analogous to reduce(), because the 
> operation performed by reduce() is stateless, whereas hash 
> functions generally have some internal state.

An example of stateless hash in .net:
http://msdn.microsoft.com/en-us/library/xa627k19.aspx
August 15, 2012
Re: The review of std.hash package
On 15-Aug-12 11:41, Kagamin wrote:
> On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote:
>>> In this case, it needs to work like a reduce algorithm, because it is
>>> a reduce algorithm. Need to find a way to make this work.
>>
>> Hash functions are _not_ analogous to reduce(), because the operation
>> performed by reduce() is stateless, whereas hash functions generally
>> have some internal state.
>
> An example of stateless hash in .net:
> http://msdn.microsoft.com/en-us/library/xa627k19.aspx

AFAIK it'a method of HashAlgorithm Object.

http://msdn.microsoft.com/en-us/library/c06s9c55

It also includes TransformBlock & TransformFinalBlock. It does contain 
state of course.
August 15, 2012
Re: The review of std.hash package
On Wednesday, 15 August 2012 at 07:41:20 UTC, Kagamin wrote:
> On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger 
> wrote:
>> Hash functions are _not_ analogous to reduce(), because the 
>> operation performed by reduce() is stateless, whereas hash 
>> functions generally have some internal state.
>
> An example of stateless hash in .net:
> http://msdn.microsoft.com/en-us/library/xa627k19.aspx

http://msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.state

David
5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home