On 02/07/10 22:41, Gregory Crosswhite wrote:
On 7/2/10 5:16 AM, Vincent Hanquez wrote:
It's necessary in my case since i receive chunks of data to be hashed
from the
network, and I don't want to carry a buffer of data (with potential
security
issues), until i can hash everything.
As an
On Fri, Jul 02, 2010 at 11:01:17AM -0400, Brandon S Allbery KF8NH wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/2/10 07:23 , Vincent Hanquez wrote:
I'm not sure exactly what the API would looks like, but I think basically
you
would enter/leave the state monad quite
Hi,
Am Freitag, den 02.07.2010, 12:55 +1000 schrieb Ivan Miljenovic:
This can be resolved by putting the build-depends line in the if
statement (and should maybe put up the top of the executable section
to make it more obvious):
the latter was not possible last time I checked.
Greetings,
On 2 July 2010 16:57, Joachim Breitner m...@joachim-breitner.de wrote:
Am Freitag, den 02.07.2010, 12:55 +1000 schrieb Ivan Miljenovic:
This can be resolved by putting the build-depends line in the if
statement (and should maybe put up the top of the executable section
to make it more
Hi,
Am Freitag, den 02.07.2010, 17:14 +1000 schrieb Ivan Miljenovic:
On 2 July 2010 16:57, Joachim Breitner m...@joachim-breitner.de wrote:
Am Freitag, den 02.07.2010, 12:55 +1000 schrieb Ivan Miljenovic:
This can be resolved by putting the build-depends line in the if
statement (and
On Fri, Jul 02, 2010 at 12:55:03PM +1000, Ivan Miljenovic wrote:
On 1 July 2010 17:25, Vincent Hanquez t...@snarc.org wrote:
The main reason for this library is the lack of incremental api exposed by
current digest libraries, and filling the void about some missing digest
algorithms; Also
Vincent Hanquez t...@snarc.org writes:
On Fri, Jul 02, 2010 at 12:55:03PM +1000, Ivan Miljenovic wrote:
On 1 July 2010 17:25, Vincent Hanquez t...@snarc.org wrote:
The main reason for this library is the lack of incremental api exposed by
current digest libraries, and filling the void about
On Fri, Jul 02, 2010 at 08:10:19PM +1000, Ivan Lazar Miljenovic wrote:
i.e.
update : ctx - bytestring - IO ()
becomes:
update : ctx - bytestring - ctx
So you're using explicit state parsing? Any particular reason for not
using the State monad or something like that?
hm, I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/2/10 07:23 , Vincent Hanquez wrote:
I'm not sure exactly what the API would looks like, but I think basically you
would enter/leave the state monad quite frequently in incremental mode,
since the whole point of the incremental api is having
On Fri, Jul 02, 2010 at 08:10:19PM +1000, Ivan Lazar Miljenovic wrote:
The few existing packages that exposes the incremental API, usually do it
in the IO monad; cryptohash do it purely, creating a new context as it get
updated.
(this has a cost but remains fast globally with the C
On 7/2/10 11:01 AM, Brandon S Allbery KF8NH wrote:
Although now that I think about it, if we're just appending to the state,
this should possibly be a Writer instead of a State; the interface is simpler.
The problem with this approach is that the hash context isn't a monoid;
you can
On 7/2/10 5:16 AM, Vincent Hanquez wrote:
It's necessary in my case since i receive chunks of data to be hashed from the
network, and I don't want to carry a buffer of data (with potential security
issues), until i can hash everything.
As an aside, this kind of pattern where you are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/2/10 17:24 , Gregory Crosswhite wrote:
The problem with this approach is that the hash context isn't a monoid; you
can absorb data into the context, but you can't combine two hash contexts to
form a new one. Thus, the Writer monad won't work
On Fri, Jul 02, 2010 at 08:48:07PM -0400, Brandon S Allbery KF8NH wrote:
On 7/2/10 17:24 , Gregory Crosswhite wrote:
The problem with this approach is that the hash context isn't a monoid; you
can absorb data into the context, but you can't combine two hash contexts to
form a new one.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/2/10 20:51 , John Meacham wrote:
On Fri, Jul 02, 2010 at 08:48:07PM -0400, Brandon S Allbery KF8NH wrote:
On 7/2/10 17:24 , Gregory Crosswhite wrote:
The problem with this approach is that the hash context isn't a monoid; you
can absorb data
On 7/2/10 9:13 PM, Brandon S Allbery KF8NH wrote:
If you read the example code I posted, the point was how to turn the current
monolithic hash function into a cumulative one by using Writer. As such,
there's no opaque hash state inside the Writer. (see `hash . runWriter').
You can do
On 1 July 2010 17:25, Vincent Hanquez t...@snarc.org wrote:
The main reason for this library is the lack of incremental api exposed by
current digest libraries, and filling the void about some missing digest
algorithms; Also the speed comes as a nice bonus.
Can you explain what you mean by
17 matches
Mail list logo
