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 t
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
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 traini
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 work
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, and
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 els
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 w
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 t
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
> > fil
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
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 elemSiz
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 <- f
>> 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
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
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 t
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 arr
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'
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:
http://code.haskell.org/~dons/cod
18 matches
Mail list logo