I have added UAProd-based Binary instances to my copy of the uvector
repo at http://patch-tag.com/publicrepos/pumpkin-uvector . I have some
extensive tests (added to the existing tests directory) of things in
there and they seem to be mostly sane.
The Binary code isn't at all pretty right now,
Daniel Peebles ha scritto:
I have added UAProd-based Binary instances to my copy of the uvector
repo at http://patch-tag.com/publicrepos/pumpkin-uvector . I have some
extensive tests (added to the existing tests directory) of things in
there and they seem to be mostly sane.
Thanks for the
Daniel Peebles ha scritto:
I have added UAProd-based Binary instances to my copy of the uvector
repo at http://patch-tag.com/publicrepos/pumpkin-uvector .
I can confirm that it works for me.
However I have now a memory problem with data decoding.
I need to serialize the Netflix Prize
The main issue seems to be that although the semantics of UIO may be
arbitrary, Wallace's patch actually broke deserialization for any
production-based UArr, and I'm not sure the benefits are worthwhile
(loading a file someone else sent you) given that endianness is
already not taken into account
I'm sorry, I didn't mean to imply otherwise.
I can see your point, but maybe it would be even more flexible in that
kind of situation to keep a separate UIO-like API that allows one to
explicitly request a particular size? For your large dataset, you
could specify the entire filesize (divided by
Hi.
I'm sure this is a know bug, but I can't find details with Google.
The offending code is here:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2362
When I execute the program I get:
uio: readChunkBU: can't read
What's the problem?
I'm using uvector from:
Am Freitag, 13. März 2009 21:18 schrieb Manlio Perillo:
Hi.
I'm sure this is a know bug, but I can't find details with Google.
The offending code is here:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2362
When I execute the program I get:
uio: readChunkBU: can't read
What's the
As far as I know, the reason for this is that the UIO instance for
productions writes the two rows out sequentially to file, but
doesn't include any means to determine the length of the two halves
when it's loading up again. When you try to read the production back
in, it tries to read in two
UIO's also only a truly alpha idea as a proxy for bytestring/Binary
support.
Patches welcome.
pumpkingod:
As far as I know, the reason for this is that the UIO instance for
productions writes the two rows out sequentially to file, but
doesn't include any means to determine the length of the
Daniel Peebles ha scritto:
As far as I know, the reason for this is that the UIO instance for
productions writes the two rows out sequentially to file, but
doesn't include any means to determine the length of the two halves
when it's loading up again. When you try to read the production back
in,
As far as I know, the reason for this is that the UIO instance for
productions writes the two rows out sequentially to file, but
doesn't include any means to determine the length of the two halves
when it's loading up again. When you try to read the production back
in, it tries to read in two
Daniel Fischer ha scritto:
[...]
Worked with uvector-0.1.0.1:
[...]
But not with uvector-0.2
[...]
The main difference is that in uvector 0.2, hPutBU does not write in the
file the length of the array; hGetBU simply use the file size.
let elemSize = sizeBU 1 (undefined :: e)
n -
manlio_perillo:
Daniel Fischer ha scritto:
[...]
Worked with uvector-0.1.0.1:
[...]
But not with uvector-0.2
[...]
The main difference is that in uvector 0.2, hPutBU does not write in the
file the length of the array; hGetBU simply use the file size.
let elemSize = sizeBU 1
Don Stewart ha scritto:
[...]
So, the patch is: just revert this change.
Or... use your own UIO instance. That's why it's a type class!
Why should I rewrite the UIO instance, if one already exists?
Anyway, for the background on this:
Tue Nov 18 08:44:46 PST 2008 Malcolm Wallace
Am Freitag, 13. März 2009 23:53 schrieb Don Stewart:
manlio_perillo:
Daniel Fischer ha scritto:
[...]
Worked with uvector-0.1.0.1:
[...]
But not with uvector-0.2
[...]
The main difference is that in uvector 0.2, hPutBU does not write in the
file the length of the array;
manlio_perillo:
Don Stewart ha scritto:
[...]
So, the patch is: just revert this change.
Or... use your own UIO instance. That's why it's a type class!
Why should I rewrite the UIO instance, if one already exists?
Oh, because you want different serialization semantics to the
(arbitrary)
The main issue seems to be that although the semantics of UIO may be
arbitrary, Wallace's patch actually broke deserialization for any
production-based UArr, and I'm not sure the benefits are worthwhile
(loading a file someone else sent you) given that endianness is
already not taken into account
I'd like to do away with UIO altogether though.
pumpkingod:
The main issue seems to be that although the semantics of UIO may be
arbitrary, Wallace's patch actually broke deserialization for any
production-based UArr, and I'm not sure the benefits are worthwhile
(loading a file someone else
18 matches
Mail list logo
