• Ben Hinkle (13/13) Aug 28 2004 hi,
• Sean Kelly (6/17) Aug 28 2004 Definately. Calling these functions on a stream should really not retur...
• Ben Hinkle (15/39) Aug 28 2004 The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in
• Regan Heath (13/60) Aug 29 2004 But the API shown above is more like the sort of API used for md4, md5,
• Ben Hinkle (8/76) Aug 29 2004 The difference is that the crc algorithm doesn't need any state (I think...
• Regan Heath (11/96) Aug 29 2004 The state is the CRC itself. It's similar to md5, md5's state is an arra...
• J C Calvarese (16/30) Aug 28 2004 I think I agree, but it's far enough above my head that I probably

Ben Hinkle <bhinkle4 juno.com> writes:

hi,
I'd like to change the behavior of std.stream.Stream's toString and toHash.
Right now toString gets all the stream contents into a char[] and returns
that. I think it should keep Object's toString. Similarly toHash right now
gets all the content and calls crc32 and I think it should just use
Object's toHash. The current behavior of reading the entire stream contents
into a char[] doesn't need a special function. Such behavior is rare enough
and simple enough (and wierd enough) that users can do that themselves.

On a related note I'd like to propose removing the module src/phobos/crc32.d
since the same functionality is in std.zlib in the function crc32. The only
place in std that the top-level crc32 is used is in Stream's toHash.

thoughts?
-Ben

Sean Kelly <sean f4.ca> writes:

In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
hi,
I'd like to change the behavior of std.stream.Stream's toString and toHash.
Right now toString gets all the stream contents into a char[] and returns
that. I think it should keep Object's toString. Similarly toHash right now
gets all the content and calls crc32 and I think it should just use
Object's toHash. The current behavior of reading the entire stream contents
into a char[] doesn't need a special function. Such behavior is rare enough
and simple enough (and wierd enough) that users can do that themselves.

Definately.  Calling these functions on a stream should really not return stream
data by default.

On a related note I'd like to propose removing the module src/phobos/crc32.d
since the same functionality is in std.zlib in the function crc32. The only
place in std that the top-level crc32 is used is in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone
function.  I don't suppose it would make sense to have zlib import std.crc32?


Sean

Ben Hinkle <bhinkle4 juno.com> writes:

Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
hi,
I'd like to change the behavior of std.stream.Stream's toString and
toHash. Right now toString gets all the stream contents into a char[] and
returns that. I think it should keep Object's toString. Similarly toHash
right now gets all the content and calls crc32 and I think it should just
use Object's toHash. The current behavior of reading the entire stream
contents into a char[] doesn't need a special function. Such behavior is
rare enough and simple enough (and wierd enough) that users can do that
themselves.

 
 Definately.  Calling these functions on a stream should really not return
 stream data by default.
 
On a related note I'd like to propose removing the module
src/phobos/crc32.d since the same functionality is in std.zlib in the
function crc32. The only place in std that the top-level crc32 is used is
in Stream's toHash.

 
 Duplication of code seems silly, but I do like having crc32 as a
 standalone
 function.  I don't suppose it would make sense to have zlib import
 std.crc32?

The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in
std.zlib is standalone in the sense that it you can just call it with a
bufer eithout worrying about anything else. The signature is uint
crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't even
called std.crc32 - the module name is just plain old crc32) involves
several functions:
 uint init_crc32();
 uint update_crc32(ubyte val, uint crc);
 uint update_crc32(char val, uint crc);
 uint strcrc32(char[] s);
So to use crc32.d you have to loop over the buffer yourself and call
update_crc32 and to use std.zlib.crc32 you just pass it an initial value (0
for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is
better IMO.

Regan Heath <regan netwin.co.nz> writes:

On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[] 
 and
 returns that. I think it should keep Object's toString. Similarly 
 toHash
 right now gets all the content and calls crc32 and I think it should 
 just
 use Object's toHash. The current behavior of reading the entire stream
 contents into a char[] doesn't need a special function. Such behavior 
 is
 rare enough and simple enough (and wierd enough) that users can do that
 themselves.

 Definately.  Calling these functions on a stream should really not 
 return
 stream data by default.

 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is used 
 is
 in Stream's toHash.

 Duplication of code seems silly, but I do like having crc32 as a
 standalone
 function.  I don't suppose it would make sense to have zlib import
 std.crc32?

 The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in
 std.zlib is standalone in the sense that it you can just call it with a
 bufer eithout worrying about anything else. The signature is uint
 crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't 
 even
 called std.crc32 - the module name is just plain old crc32) involves
 several functions:
  uint init_crc32();
  uint update_crc32(ubyte val, uint crc);
  uint update_crc32(char val, uint crc);
  uint strcrc32(char[] s);
 So to use crc32.d you have to loop over the buffer yourself and call
 update_crc32 and to use std.zlib.crc32 you just pass it an initial value 
 (0
 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is
 better IMO.

But the API shown above is more like the sort of API used for md4, md5, 
sha0, sha1, etc..

I would ideally like to see:

crc32_start();  <- starts the caclulation.
crc32_update(); <- updates the crc with more data.
crc32_finish(); <- concludes the crc.

to allow piece by piece calculation, and one function i.e.

crc32();        <- calls the 3 methods above.

to do it all in one step.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Ben Hinkle <bhinkle4 juno.com> writes:

Regan Heath wrote:

 On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[]
 and
 returns that. I think it should keep Object's toString. Similarly
 toHash
 right now gets all the content and calls crc32 and I think it should
 just
 use Object's toHash. The current behavior of reading the entire stream
 contents into a char[] doesn't need a special function. Such behavior
 is
 rare enough and simple enough (and wierd enough) that users can do that
 themselves.

 Definately.  Calling these functions on a stream should really not
 return
 stream data by default.

 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is used
 is
 in Stream's toHash.

 Duplication of code seems silly, but I do like having crc32 as a
 standalone
 function.  I don't suppose it would make sense to have zlib import
 std.crc32?

 The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in
 std.zlib is standalone in the sense that it you can just call it with a
 bufer eithout worrying about anything else. The signature is uint
 crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't
 even
 called std.crc32 - the module name is just plain old crc32) involves
 several functions:
  uint init_crc32();
  uint update_crc32(ubyte val, uint crc);
  uint update_crc32(char val, uint crc);
  uint strcrc32(char[] s);
 So to use crc32.d you have to loop over the buffer yourself and call
 update_crc32 and to use std.zlib.crc32 you just pass it an initial value
 (0
 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is
 better IMO.

 
 But the API shown above is more like the sort of API used for md4, md5,
 sha0, sha1, etc..
 
 I would ideally like to see:
 
 crc32_start();  <- starts the caclulation.
 crc32_update(); <- updates the crc with more data.
 crc32_finish(); <- concludes the crc.
 
 to allow piece by piece calculation, and one function i.e.
 
 crc32();        <- calls the 3 methods above.
 
 to do it all in one step.
 
 Regan
 

The difference is that the crc algorithm doesn't need any state (I think).
So crc_start just returns some initial value like 0 or -1 (which could be
the default value of an update function in case people don't want to think
about it) and finish is a no-op. The only non-trivial function is the
update. The md5 algorithms have non-trivial start and finish. But then I
haven't used crc or md5 so I'm not going to push any particular API - I'm
just stating my position as an outsider to the whole thing.

Regan Heath <regan netwin.co.nz> writes:

On Sun, 29 Aug 2004 21:57:17 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Regan Heath wrote:

 On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> 
 wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[]
 and
 returns that. I think it should keep Object's toString. Similarly
 toHash
 right now gets all the content and calls crc32 and I think it should
 just
 use Object's toHash. The current behavior of reading the entire 
 stream
 contents into a char[] doesn't need a special function. Such behavior
 is
 rare enough and simple enough (and wierd enough) that users can do 
 that
 themselves.

 Definately.  Calling these functions on a stream should really not
 return
 stream data by default.

 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is 
 used
 is
 in Stream's toHash.

 Duplication of code seems silly, but I do like having crc32 as a
 standalone
 function.  I don't suppose it would make sense to have zlib import
 std.crc32?

 The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in
 std.zlib is standalone in the sense that it you can just call it with a
 bufer eithout worrying about anything else. The signature is uint
 crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't
 even
 called std.crc32 - the module name is just plain old crc32) involves
 several functions:
  uint init_crc32();
  uint update_crc32(ubyte val, uint crc);
  uint update_crc32(char val, uint crc);
  uint strcrc32(char[] s);
 So to use crc32.d you have to loop over the buffer yourself and call
 update_crc32 and to use std.zlib.crc32 you just pass it an initial 
 value
 (0
 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 
 is
 better IMO.

 But the API shown above is more like the sort of API used for md4, md5,
 sha0, sha1, etc..

 I would ideally like to see:

 crc32_start();  <- starts the caclulation.
 crc32_update(); <- updates the crc with more data.
 crc32_finish(); <- concludes the crc.

 to allow piece by piece calculation, and one function i.e.

 crc32();        <- calls the 3 methods above.

 to do it all in one step.

 Regan

 The difference is that the crc algorithm doesn't need any state (I 
 think).

The state is the CRC itself. It's similar to md5, md5's state is an array 
of ubytes and a length the state array is represented as characters to 
give the fingerprint.

 So crc_start just returns some initial value like 0 or -1 (which could be
 the default value of an update function in case people don't want to 
 think about it) and finish is a no-op. The only non-trivial function is 
 the
 update.

 The md5 algorithms have non-trivial start and finish. But then I
 haven't used crc or md5 so I'm not going to push any particular API - I'm
 just stating my position as an outsider to the whole thing.

My position is that it would be consistent if similar operations had 
similar interfaces, I think a CRC is a simple type of data fingerprint, so 
it belongs in the same family as md5 etc and should therefore have a 
similar interface.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

J C Calvarese <jcc7 cox.net> writes:

Ben Hinkle wrote:
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and toHash.
 Right now toString gets all the stream contents into a char[] and returns
 that. I think it should keep Object's toString. Similarly toHash right now
 gets all the content and calls crc32 and I think it should just use
 Object's toHash. The current behavior of reading the entire stream contents
 into a char[] doesn't need a special function. Such behavior is rare enough
 and simple enough (and wierd enough) that users can do that themselves.

I think I agree, but it's far enough above my head that I probably 
shouldn't comment. ;)

 On a related note I'd like to propose removing the module src/phobos/crc32.d
 since the same functionality is in std.zlib in the function crc32. The only
 place in std that the top-level crc32 is used is in Stream's toHash.

I definitely can't understand why it has to be in the root of phobos 
(and why is object.d in the root, too?)

And why are there multiple crc32 functions? I can't explain that either.

Also, (and now I'm off-topic) I don't think phobos should depend on 
anything in "etc". If it's needed by phobos, it should be moved it to an 
obscure corner of "std".

 
 thoughts?

You bring up some good points. There some many things in phobos that are 
messy and don't seem to make sense. That's why we're finding plenty of 
things to discuss in the "Phobos Rising" forum 
(http://www.dsource.org/forums/viewforum.php?f=31)

 -Ben


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/