Am Wed, 29 Aug 2012 04:57:32 +0200
schrieb Jesse Phillips jessekphillip...@gmail.com:
All this discussion on the use of auto in the docs made me notice
something else about the docs I missed.
I like how ranges are documented and think digest could do the
same. Instead of an ExampleDigest,
All this discussion on the use of auto in the docs made me notice
something else about the docs I missed.
I like how ranges are documented and think digest could do the
same. Instead of an ExampleDigest, just write the details under
isDigest.
I don't see a need for template the constraint
On Thu, 16 Aug 2012 21:25:55 +0100, deadalnix deadal...@gmail.com wrote:
Le 09/08/2012 11:48, Johannes Pfau a écrit :
Am Wed, 08 Aug 2012 12:31:29 -0700
schrieb Walter Brightnewshou...@digitalmars.com:
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming
Le 09/08/2012 11:48, Johannes Pfau a écrit :
Am Wed, 08 Aug 2012 12:31:29 -0700
schrieb Walter Brightnewshou...@digitalmars.com:
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming without using
coroutines. It's the classical inversion-of-control dilemma of
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
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
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.
On Wednesday, 15 August 2012 at 08:13:27 UTC, Dmitry Olshansky
wrote:
AFAIK it'a method of HashAlgorithm Object.
It's a minor design detail, see the example: the method is called
on each file without any explicit preparations and without calls
to methods like TransformBlock. That's how
On Wednesday, 15 August 2012 at 08:17:01 UTC, David Nadlinger
wrote:
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
On 15-Aug-12 12:17, Kagamin wrote:
On Wednesday, 15 August 2012 at 08:13:27 UTC, Dmitry Olshansky wrote:
AFAIK it'a method of HashAlgorithm Object.
It's a minor design detail, see the example: the method is called on
each file without any explicit preparations and without calls to methods
On Wednesday, 15 August 2012 at 08:25:51 UTC, Dmitry Olshansky
wrote:
Brrr. It's how convenience wrapper works :)
And I totally expect this to call the same code and keep the
same state during the work.
E.g. see std.digest.digest functions digest or hexDigest you
could call it stateless in
On Wednesday, 15 August 2012 at 08:45:35 UTC, Kagamin wrote:
I just pointed out, that possibly stateful implementation
doesn't prevent stateless interface. Can one even say that the
implementation is stateful given just a stateless interface?
And our point is that such an interface is trivial
On Wednesday, 8 August 2012 at 16:47:35 UTC, Johannes Pfau wrote:
std.hash.digest doesn't sound too bad. We could have
std.hash.func (or
a better named module ;-) for general hash functions later.
Three basic types of hash functions are:
1) Hash - for fast searching and indexing in data
On Wednesday, 15 August 2012 at 08:49:26 UTC, RivenTheMage wrote:
Three basic types of hash functions are:
1) Hash - for fast searching and indexing in data structures
2) Checksum - detects the accidental errors in files, archives,
streams
3) Message digest code - prevents the intentional
On Wednesday, 15 August 2012 at 08:55:30 UTC, David Nadlinger
wrote:
Why? 1) might have a different interface than the others, but
2) and 3) only differ in their cryptological properties, the
interface will likely be just the same – or what are you
thinking about?
David
The only
Another example is a systematic error-correcting codes. The
only difference between them and checksums is the ability to
correct errors, not just detect them. CRC or MD5 can be viewed as
systematic code with zero error-correcting ability.
Should we mix Reed-Solomon codes and MD5 in one module? I
On Wed, Aug 15, 2012 at 2:40 AM, RivenTheMage riven-m...@id.ru wrote:
Another example is a systematic error-correcting codes. The
only difference between them and checksums is the ability to
correct errors, not just detect them. CRC or MD5 can be viewed as
systematic code with zero
On Wednesday, 15 August 2012 at 14:36:00 UTC, José Armando
García Sancio wrote:
Some people's point is that MD5 was consider a cryptographic
digest
function 16 years ago. It is not consider cryptographically
secure
today. So why make any design assumption today on how the
landscape
will look
On 15-Aug-12 12:45, Kagamin wrote:
On Wednesday, 15 August 2012 at 08:25:51 UTC, Dmitry Olshansky wrote:
Brrr. It's how convenience wrapper works :)
And I totally expect this to call the same code and keep the same
state during the work.
E.g. see std.digest.digest functions digest or
On Wed, Aug 15, 2012 at 8:11 AM, ReneSac renedu...@yahoo.com.br wrote:
Note that in the Python passlib, there is no mention to CRC, FNV, ROT13,
etc. Their place is different.
Thats because it is a password module and nobody or a small
percentage of the population uses CRC for password digest.
On Wednesday, 15 August 2012 at 19:38:34 UTC, José Armando
García Sancio wrote:
Thats because it is a password module and nobody or a small
percentage of the population uses CRC for password digest.
In turn, that's because CRC is not not a crytographic hash and
not suited for password hashing
On Thursday, 16 August 2012 at 03:02:59 UTC, RivenTheMage wrote:
ushort num = 1234;
auto hash1 = hash!((a 20) ^ (a 12) ^ (a 7) ^ (a
4) ^ a)(str); // indexing hash
I forgot that this case is already covered by reduce!(...)
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.
Am Wed, 08 Aug 2012 16:44:03 -0400
schrieb Jonathan M Davis jmdavisp...@gmx.com:
in CTFE?
http://dpaste.dzfl.pl/0503b8af
According to Don reinterpret casts (even if done through unions)
won't be supported in CTFE. So you can't convert from
uint--ubyte[4]
No. It wouldn't work in
Am Wed, 08 Aug 2012 12:30:31 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2012 12:05 PM, Johannes Pfau wrote:
So the post in D.learn for a detailed description. Yes the code I
posted takes a range, but digest (as it is now) takes void[][] to
accept all kind of types
On 8/9/2012 2:05 AM, Johannes Pfau wrote:
I guess a second function digestRange is not acceptable?
It's more the user API that matters, not how it works under the hood.
On 8/9/2012 2:05 AM, Johannes Pfau wrote:
http://dpaste.dzfl.pl/f86717f7
The Range argument - is it an InputRange, an OutputRange? While it's just a type
name, the name should reflect what kind of range it is from the menagerie of
ranges in std.range.
On Tuesday, 7 August 2012 at 17:39:50 UTC, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an uniform
interface for hashes and checksums. It also provides some
useful helper functions to deal with this new API.
Is it too late to ask to include MurmurHash 2 and/or 3?
Am Wed, 08 Aug 2012 12:27:39 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2012 12:08 PM, Johannes Pfau wrote:
No where's the difference, except that for hashes the context
('hash') has to be setup and finished manually?
The idea is to have hash act like a component -
Am Wed, 08 Aug 2012 12:31:29 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming without using
coroutines. It's the classical inversion-of-control dilemma of
event based programming that forces you
Am Thu, 09 Aug 2012 02:13:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/9/2012 2:05 AM, Johannes Pfau wrote:
http://dpaste.dzfl.pl/f86717f7
The Range argument - is it an InputRange, an OutputRange? While it's
just a type name, the name should reflect what kind of range it
Am Thu, 09 Aug 2012 11:32:34 +0200
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Tuesday, 7 August 2012 at 17:39:50 UTC, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an uniform
interface for hashes and checksums. It also provides some
useful
On Wednesday, 8 August 2012 at 19:27:54 UTC, Walter Bright wrote:
The idea is to have hash act like a component - not with
special added code the user has to write.
Sorry, but I think this is a meaningless statement without
specifying what kind of interface the component should adhere to.
In
On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger s...@klickverbot.at
wrote:
On Wednesday, 8 August 2012 at 19:27:54 UTC, Walter Bright wrote:
The idea is to have hash act like a component - not with special added
code the user has to write.
Sorry, but I think this is a meaningless
On Thu, 09 Aug 2012 10:58:10 +0100, Johannes Pfau nos...@example.com
wrote:
Am Thu, 09 Aug 2012 11:32:34 +0200
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Tuesday, 7 August 2012 at 17:39:50 UTC, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an
On 8/9/2012 2:59 AM, David Nadlinger wrote:
On Wednesday, 8 August 2012 at 19:27:54 UTC, Walter Bright wrote:
The idea is to have hash act like a component - not with special added code
the user has to write.
Sorry, but I think this is a meaningless statement without specifying what kind
of
On 8/9/2012 2:48 AM, Johannes Pfau wrote:
Am Wed, 08 Aug 2012 12:31:29 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming without using
coroutines. It's the classical inversion-of-control dilemma of
If a has is a range, it's an output range, because it's something you
fee data to. Output range have only one method: put. Johannes used this
method. But it's not sufficient, you need something to start and to
finish the hash.
To bring consistency in the library, we should not remove this
On 8/9/12 5:05 AM, Johannes Pfau wrote:
Well that's possible, but I don't like the template bloat it causes.
What have you measured, and what is your dislike based upon?
The library function must be generic. Then users worried about bloating
may use it with a limited number of types.
A
Am Thu, 09 Aug 2012 08:48:37 -0400
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 8/9/12 5:05 AM, Johannes Pfau wrote:
Well that's possible, but I don't like the template bloat it causes.
What have you measured, and what is your dislike based upon?
What annoys me is that as
Am Thu, 09 Aug 2012 11:16:36 +0100
schrieb Regan Heath re...@netmail.co.nz:
Once the API is formalised I can contribute the hashes I have also :)
great! with all those contributions we'll probably have a rather
complete set of digests soon.
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
On 09-Aug-12 14:15, Regan Heath wrote:
On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger s...@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 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 s...@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
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.
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
The question about module names.
Is it supposed that e.g. std.hash.crc module will contain many CRC
implementations, not only one CRC-32? If not, it will be better to call
it std.hash.crc32 because other CRC variants are also in use. Or even
std.hash.crc.crc32.
Same with std.hash.sha and
Am Wed, 08 Aug 2012 00:55:47 +0200
schrieb David d...@dav1d.de:
Am 07.08.2012 21:53, schrieb Johannes Pfau:
Am Tue, 07 Aug 2012 20:07:07 +0200
schrieb David d...@dav1d.de:
start is here as structs can't have default constructors. For all
current hashes it's really mostly useless
Am Tue, 07 Aug 2012 17:39:15 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/7/2012 10:39 AM, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an uniform
interface for hashes and checksums. It also provides some useful
helper functions to deal with
Am Wed, 08 Aug 2012 01:27:45 +0200
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
Johannes Pfau wrote:
As I had some free time and nobody else stepped up I implemented it,
I tried it before but I wanted to create whole crypto package at
once,
I'm sorry, I didn't want to conceal your work.
Am Wed, 08 Aug 2012 11:48:54 +0400
schrieb Denis Shelomovskij verylonglogin@gmail.com:
The question about module names.
Is it supposed that e.g. std.hash.crc module will contain many CRC
implementations, not only one CRC-32? If not, it will be better to
call it std.hash.crc32 because
Johannes Pfau wrote:
Am Wed, 08 Aug 2012 01:27:45 +0200
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
Johannes Pfau wrote:
As I had some free time and nobody else stepped up I implemented it,
I tried it before but I wanted to create whole crypto package at
once,
I'm sorry, I didn't want to
On 8/8/2012 1:44 AM, Johannes Pfau wrote:
Am Tue, 07 Aug 2012 17:39:15 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/7/2012 10:39 AM, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an uniform
interface for hashes and checksums. It also provides some
Walter Bright wrote:
auto result = file.byChunk(4096 * 1025).joiner.hash();
The magic is that any input range that produces bytes could be used, and
that byte producing input range can be hooked up to the input of any
reducing function.
Suppose you have a callback that will give you
On Tue, 07 Aug 2012 19:41:12 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Tuesday, August 07, 2012 15:31:57 Ary Manzana wrote:
The std.hash package also includes:
I think std.crypto is a better name for the package. At first I
thought it contained an implementation of a Hash table.
Le 08/08/2012 11:49, Walter Bright a écrit :
On 8/8/2012 1:44 AM, Johannes Pfau wrote:
Am Tue, 07 Aug 2012 17:39:15 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/7/2012 10:39 AM, Dmitry Olshansky wrote:
std.hash.hash is a new module for Phobos defining an uniform
interface for
I'm not familiar with hash functions in general.
I think the core of std.hash is the digest function:
digestType!Hash digest(Hash)(scope const(void[])[] data...)
if(isDigest!Hash)
{
Hash hash;
hash.start();
foreach(datum; data)
hash.put(cast(const(ubyte[]))datum);
return
On Wed, Aug 08, 2012 at 11:37:35AM +0100, Regan Heath wrote:
On Tue, 07 Aug 2012 19:41:12 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Tuesday, August 07, 2012 15:31:57 Ary Manzana wrote:
I think std.crypto is a better name for the package. At first I
thought it contained an
On Wednesday, 8 August 2012 at 12:00:42 UTC, H. S. Teoh wrote:
On Wed, Aug 08, 2012 at 11:37:35AM +0100, Regan Heath wrote:
On Tue, 07 Aug 2012 19:41:12 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Tuesday, August 07, 2012 15:31:57 Ary Manzana wrote:
I think std.crypto is a better
It should accept an input range. But using an Output Range confuses me.
A hash function is a reduce algorithm - it accepts a sequence of input
values, and produces a single value. You should be able to write code
like:
ubyte[] data;
...
auto crc = data.crc32();
For example, the
On Wed, 08 Aug 2012 13:11:43 +0100, Tobias Pankrath tob...@pankrath.net
wrote:
On Wednesday, 8 August 2012 at 12:00:42 UTC, H. S. Teoh wrote:
On Wed, Aug 08, 2012 at 11:37:35AM +0100, Regan Heath wrote:
On Tue, 07 Aug 2012 19:41:12 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On
On Wednesday, 8 August 2012 at 12:55:04 UTC, Regan Heath wrote:
Like it or not, Digest is the correct term:
http://en.wikipedia.org/wiki/MD5
The MD5 Message-Digest Algorithm ..
You could have cited the hole sentence
The MD5 Message-Digest Algorithm is a widely used cryptographic
hash
On Wed, 08 Aug 2012 14:03:32 +0100, Tobias Pankrath tob...@pankrath.net
wrote:
On Wednesday, 8 August 2012 at 12:55:04 UTC, Regan Heath wrote:
Like it or not, Digest is the correct term:
http://en.wikipedia.org/wiki/MD5
The MD5 Message-Digest Algorithm ..
You could have cited the hole
Regan Heath , dans le message (digitalmars.D:174462), a écrit :
Message-Digest Algorithm is the proper term, hash is another, correct,
more general term.
hash has other meanings, Message-Digest Algorithm does not.
I think the question is: is std.hash going to contain only
message-digest
On 8/8/12 8:54 AM, Regan Heath wrote:
Hash has too many meanings, we should avoid it.
Yes please.
Andrei
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest algorithm, or could it also contain other hash
functions?
I think there is enough room in a package to have both
On Wed, 08 Aug 2012 14:50:22 +0100, Chris Cain clc...@uncg.edu wrote:
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest algorithm, or could it also contain other hash
Chris Cain , dans le message (digitalmars.D:174466), a écrit :
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest algorithm, or could it also contain other hash
Am Wed, 08 Aug 2012 02:49:00 -0700
schrieb Walter Bright newshou...@digitalmars.com:
It should accept an input range. But using an Output Range confuses
me. A hash function is a reduce algorithm - it accepts a sequence of
input values, and produces a single value. You should be able to
Am Wed, 08 Aug 2012 11:27:49 +0200
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
BTW: How does it work in CTFE? Don't you have to do endianness
conversions at some time? According to Don that's not really
supported.
std.bitmanip.swapEndian() works for me
Great! I always tried the
On Wednesday, 8 August 2012 at 14:14:29 UTC, Regan Heath wrote:
I don't think there is any reason to separate them. People
should know which digest algorithm they want, they're not going
to pick one at random and assume it's super secure!(tm). And
if they do, well tough, they deserve what
Am Wed, 8 Aug 2012 17:50:33 +0200
schrieb Johannes Pfau nos...@example.com:
However, I do agree digest!Hash, md5Of, sha1Of should have an
additional overload which takes a InputRange. It would be implemented
with copy and be a nice convenience function.
I implemented the function, it's
Am Wed, 8 Aug 2012 14:16:40 + (UTC)
schrieb trav...@phare.normalesup.org (Christophe Travert):
If it where me, I would have the presently reviewed module
std.hash.hash be called std.hash.digest, and leave room here for
regular hash functions. In any case, I think regular hash HAVE to be
On 08-Aug-12 18:16, Christophe Travert wrote:
Chris Cain , dans le message (digitalmars.D:174466), a écrit :
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest
On 08-Aug-12 21:00, Dmitry Olshansky wrote:
On 08-Aug-12 18:16, Christophe Travert wrote:
They should not be categorized the same. I don't expect a regular hash
function to pass the isDigest predicate. But they have many
similarities, which explains they are all called hash functions. There
Chris Cain , dans le message (digitalmars.D:174477), a écrit :
I think you misunderstood me (and it's probably my fault, since I don't
know much of hash functions), I was wanted to compare two kind of
concepts:
1/ message digest functions, like md5, or sha1, used on large files,
which is what
Johannes Pfau , dans le message (digitalmars.D:174478), a écrit :
but I don't know how make it an overload. See thread overloading a
function taking a void[][] in D.learn for details.
Don't overload the function taking a void[][]. Remplace it. void[][] is
a range of void[].
On Wed, 08 Aug 2012 18:33:01 +0100, Christophe Travert
trav...@phare.normalesup.org wrote:
Chris Cain , dans le message (digitalmars.D:174477), a écrit :
I think you misunderstood me (and it's probably my fault, since I don't
know much of hash functions), I was wanted to compare two kind of
On Wednesday, 8 August 2012 at 17:33:01 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think you misunderstood me (and it's probably my fault, since
I don't
know much of hash functions), I was wanted to compare two kind
of
concepts:
1/ message digest functions, like md5, or
On 8/8/2012 3:12 AM, Piotr Szturmaj wrote:
Walter Bright wrote:
auto result = file.byChunk(4096 * 1025).joiner.hash();
The magic is that any input range that produces bytes could be used, and
that byte producing input range can be hooked up to the input of any
reducing function.
Suppose
On Wednesday, August 08, 2012 18:12:23 Johannes Pfau wrote:
Am Wed, 08 Aug 2012 11:27:49 +0200
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
BTW: How does it work in CTFE? Don't you have to do endianness
conversions at some time? According to Don that's not really
supported.
On 8/8/2012 5:13 AM, Martin Nowak wrote:
It should accept an input range. But using an Output Range confuses me. A hash
function is a reduce algorithm - it accepts a sequence of input values, and
produces a single value. You should be able to write code like:
ubyte[] data;
...
auto crc
On 8/8/2012 9:47 AM, Johannes Pfau wrote:
Am Wed, 8 Aug 2012 17:50:33 +0200
schrieb Johannes Pfau nos...@example.com:
However, I do agree digest!Hash, md5Of, sha1Of should have an
additional overload which takes a InputRange. It would be implemented
with copy and be a nice convenience
Am Wed, 08 Aug 2012 14:36:32 -0400
schrieb Jonathan M Davis jmdavisp...@gmx.com:
What's wrong with the *endianToNative and nativeTo*Endian functions?
They work just fine as far as I know. swapEndian works too if you
want it to use that, but there should be nothing wrong with the
Am Wed, 08 Aug 2012 11:40:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
Take a look at the reduce function in
http://dlang.org/phobos/std_algorithm.html#reduce
It has provision for an initial state that can be the current running
total.
This can only work if the final
Am Wed, 08 Aug 2012 11:47:38 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2012 9:47 AM, Johannes Pfau wrote:
Am Wed, 8 Aug 2012 17:50:33 +0200
schrieb Johannes Pfau nos...@example.com:
However, I do agree digest!Hash, md5Of, sha1Of should have an
additional overload
Hash hash;
void onData(void[] data)
{
hash.put(data);
}
void main()
{
hash.start();
auto stream = new EventTcpStream(localhost, 80);
stream.onData = onData;
hash.finish();
}
Have the callback supply a range interface to call the hash with.
That hardly
On 8/8/2012 12:08 PM, Johannes Pfau wrote:
No where's the difference, except that for hashes the context ('hash')
has to be setup and finished manually?
The idea is to have hash act like a component - not with special added code the
user has to write.
In this case, it needs to work like a
On 8/8/2012 12:05 PM, Johannes Pfau wrote:
So the post in D.learn for a detailed description. Yes the code I
posted takes a range, but digest (as it is now) takes void[][] to
accept all kind of types _without_ template bloat. The difficulty is to
combine those two overloads without causing
On 8/8/2012 12:14 PM, Martin Nowak wrote:
That hardly works for event based programming without using coroutines.
It's the classical inversion-of-control dilemma of event based programming that
forces you to save/restore your state with every event.
See the discussion on using reduce().
On Wednesday, August 08, 2012 18:47:34 Johannes Pfau wrote:
Am Wed, 8 Aug 2012 14:16:40 + (UTC)
schrieb trav...@phare.normalesup.org (Christophe Travert):
If it where me, I would have the presently reviewed module
std.hash.hash be called std.hash.digest, and leave room here for
On Wednesday, August 08, 2012 20:55:19 Johannes Pfau wrote:
Am Wed, 08 Aug 2012 14:36:32 -0400
schrieb Jonathan M Davis jmdavisp...@gmx.com:
What's wrong with the *endianToNative and nativeTo*Endian functions?
They work just fine as far as I know. swapEndian works too if you
want it to
On 8/8/12 4:34 PM, Jonathan M Davis wrote:
I say just keep at simple and leave it at std.hash. It's plenty clear IMHO.
Not clear to quite a few of us. IMHO it just makes us seem (to the
larger community) clever about a petty point. There's plenty of other
better names, and std.digest is very
On Wednesday, August 08, 2012 18:47:04 Andrei Alexandrescu wrote:
On 8/8/12 4:34 PM, Jonathan M Davis wrote:
I say just keep at simple and leave it at std.hash. It's plenty clear
IMHO.
Not clear to quite a few of us. IMHO it just makes us seem (to the
larger community) clever about a
Since the review queue has been mostly silent again I've decided to
jump in and manage the one that's ready to go :)
Today starts the the review of std.hash package by Johannes Pfau. We go
with the usual cycle of two weeks for review and one week for voting.
Thus review ends on 22th
Is the API already set in stone?
Using .start and .finish, feels like the use of OpenSSL. Why not making
a Hash object not restartable (since e.g. MD5.start() sets `this` just
to MD5.init) and making finish private and implementing a digest and
hexdigest property which calls finish and
Also I am not sure if we want to use `hash.put` instead of `hash.update`
(which is used by python and openssl). But that's just a minor point
(e.g. perl uses .add)
Well, it's there to implement the Range interface, but still, put
doesn't make too much sense for me (maybe personal preference).
On 8/7/12 14:39 , Dmitry Olshansky wrote:
Since the review queue has been mostly silent again I've decided to jump
in and manage the one that's ready to go :)
Today starts the the review of std.hash package by Johannes Pfau. We go
with the usual cycle of two weeks for review and one week
On Tuesday, August 07, 2012 20:07:07 David wrote:
Is the API already set in stone?
No. That's the main point of the review process. The API needs to be reviewed
and revised as appropriate (as does the implementation, but the API is much
harder to fix later, since that tends to cause breakin
Le 07/08/2012 20:31, Ary Manzana a écrit :
On 8/7/12 14:39 , Dmitry Olshansky wrote:
Since the review queue has been mostly silent again I've decided to jump
in and manage the one that's ready to go :)
Today starts the the review of std.hash package by Johannes Pfau. We go
with the usual cycle
1 - 100 of 107 matches
Mail list logo
