Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 the UnsafeIO (which I'm thinking of renaming to UnsafeBinary, thoughts?) that comes with it is even uglier, but it'll be improving soon. When I clean it up, I'll submit a patch to the main uvector repo and we can see how it goes (maybe at that point we can pull out UIO). Also in that repo are changes that add safety checks to all the functions I know to be unsafe. Due to the fact that these functions would previously crash my tests, I'm currently only testing safe parameter combinations on them, so when I get the tests to check that errors are being thrown appropriately, I'll also submit a patch for that. Cheers, Dan On Fri, Mar 13, 2009 at 7:34 PM, Don Stewart d...@galois.com wrote: 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 sent you) given that endianness is already not taken into account when loading (so the chances of someone giving you a raw binary file that happens to contain values of the correct endianness is rather low, it seems). On a related note, having a (more) complete testsuite might help prevent patches like this from breaking existing functionality. Maybe a way to resolve the issue is to use the file size and break it according to the size of the two halves of the production? This avoids prefixing array length, but allows the productions to still work. Either way, I'm in the process of writing a Binary instance, so maybe we can get the best of both worlds eventually. Thanks, Dan On Fri, Mar 13, 2009 at 7:21 PM, Don Stewart d...@galois.com wrote: 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) defaults. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 a question, however. Isn't it possible to write binary serialization code for the generic Stream type? Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 training dataset. When I parse the data from original data set, memory usage is about 640 MB [1]. But when I load the data serialized and compressed, (as [UArr (Word32 *:* Word8)]), memory usage is about 840 MB... The culprit is probably the decoding of the list (17770 elements). [1] I have written a script in Python that parse the data, and it only takes 491 MB (using a list of a tuple with two compact arrays from numpy). So, GHC has memory problems here. Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 when loading (so the chances of someone giving you a raw binary file that happens to contain values of the correct endianness is rather low, it seems). In my experience, having written several libraries in Haskell for serialisation and deserialisation, it is highly problematic when a library writer decides that all data to be stored began its life in Haskell, and is only being serialised in order to be read back in again by the same Haskell library. I have already made that mistake myself in two different libraries now, eventually regretting it (and fixing it). The real utility of serialisation is when it is possible to read data from any arbitrary external source, and to write data according to external standards. A library that can only read and write data in its own idiosyncratic format is not production-ready at all. This is why I submitted the patch that enables the uvector library to read raw binary data that was not produced by itself. I had 300Gb of data from an external source that I needed to deal with efficiently, and uvector was the ideal candidate apart from this small design flaw. And yes, my code also had to deal with endianness conversion on this data. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 the size of your elements, maybe) while Manlio could take care of storing his array sizes in a different form if necessary. The semantics of UIO loading could then become I have a large chunk of data on a handle that I need to load verbatim; tell me how much to load, which would work on pipes, sockets, and other non-file sources, as well as still being useful in your case of having enormous amounts of data. Anyway, I'm clearly in no position to be deciding on significant API changes for uvector, but having more than one option in a high-performance library like this seems like a good thing. Cheers, Dan On Sat, Mar 14, 2009 at 1:20 PM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: 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 when loading (so the chances of someone giving you a raw binary file that happens to contain values of the correct endianness is rather low, it seems). In my experience, having written several libraries in Haskell for serialisation and deserialisation, it is highly problematic when a library writer decides that all data to be stored began its life in Haskell, and is only being serialised in order to be read back in again by the same Haskell library. I have already made that mistake myself in two different libraries now, eventually regretting it (and fixing it). The real utility of serialisation is when it is possible to read data from any arbitrary external source, and to write data according to external standards. A library that can only read and write data in its own idiosyncratic format is not production-ready at all. This is why I submitted the patch that enables the uvector library to read raw binary data that was not produced by itself. I had 300Gb of data from an external source that I needed to deal with efficiently, and uvector was the ideal candidate apart from this small design flaw. And yes, my code also had to deal with endianness conversion on this data. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] broken IO support in uvector package, when using non primitive types
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/code/uvector/ Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 problem? I'm using uvector from: http://code.haskell.org/~dons/code/uvector/ Thanks Manlio Perillo Worked with uvector-0.1.0.1: $ ghc --make readUArr.hs [1 of 1] Compiling Main ( readUArr.hs, readUArr.o ) Linking readUArr ... $ ./readUArr 2 But not with uvector-0.2 $ ./readUArr readUArr: readChunkBU: can't read ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 arrays, but the first array read consumes all the input leaving the second with nothing. Having said that, I'm not sure why it used to work. I remember testing this on the version in hackage and finding the same issue. Cheers, Dan On Fri, Mar 13, 2009 at 4:46 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: 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 problem? I'm using uvector from: http://code.haskell.org/~dons/code/uvector/ Thanks Manlio Perillo Worked with uvector-0.1.0.1: $ ghc --make readUArr.hs [1 of 1] Compiling Main ( readUArr.hs, readUArr.o ) Linking readUArr ... $ ./readUArr 2 But not with uvector-0.2 $ ./readUArr readUArr: readChunkBU: can't read ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 two halves when it's loading up again. When you try to read the production back in, it tries to read in two arrays, but the first array read consumes all the input leaving the second with nothing. Having said that, I'm not sure why it used to work. I remember testing this on the version in hackage and finding the same issue. Cheers, Dan On Fri, Mar 13, 2009 at 4:46 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: 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 problem? I'm using uvector from: http://code.haskell.org/~dons/code/uvector/ Thanks Manlio Perillo Worked with uvector-0.1.0.1: $ ghc --make readUArr.hs [1 of 1] Compiling Main ( readUArr.hs, readUArr.o ) Linking readUArr ... $ ./readUArr 2 But not with uvector-0.2 $ ./readUArr readUArr: readChunkBU: can't read ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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, it tries to read in two arrays, but the first array read consumes all the input leaving the second with nothing. Ok, thanks. For now, I think that the simple solution is to not use UArr (a:*:b), but (UArr a, UArr b). Or I should just switch to Data.Array.Unboxed. The operations I need with the array are only: - sum of elements - binary search - serialization/deserialization - sorting (but right now I sort the list before creating the array) with a very big data set. For my problem, is uvector the best solution? What about storablevector or cvector, instead? Regards Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 arrays, but the first array read consumes all the input leaving the second with nothing. Ok, thanks. For now, I think that the simple solution is to not use UArr (a:*:b), but (UArr a, UArr b). Just newtype your own UIO instance, if you need a different instance... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 - fmap ((`div`elemSize) . fromInteger) $ hFileSize h So, the problem seems to be here. This simply don't support having two arrays written in the same file, and sizeBU belongs to the UAE class, whose instances are only declared for builtin types. So, the patch is: just revert this change. Regards Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 (undefined :: e) n - fmap ((`div`elemSize) . fromInteger) $ hFileSize h So, the problem seems to be here. This simply don't support having two arrays written in the same file, and sizeBU belongs to the UAE class, whose instances are only declared for builtin types. So, the patch is: just revert this change. Or... use your own UIO instance. That's why it's a type class! Anyway, for the background on this: Tue Nov 18 08:44:46 PST 2008 Malcolm Wallace * Use hFileSize to determine arraysize, rather than encoding it in the file. Here is a patch to the uvector library that fixes hGetBU and hPutBU to use the filesize to determine arraysize, rather than encoding it within the file. I guess the disadvantages are that now only one array can live in a file, and the given Handle must indeed be a file, not a socket Handle. But the advantage is that one can read packed raw datafiles obtained externally. Still, again, I'd point out that uvector is alpha, APIs can and will change. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 * Use hFileSize to determine arraysize, rather than encoding it in the file. Here is a patch to the uvector library that fixes hGetBU and hPutBU to use the filesize to determine arraysize, rather than encoding it within the file. I guess the disadvantages are that now only one array can live in a file, and the given Handle must indeed be a file, not a socket Handle. But the advantage is that one can read packed raw datafiles obtained externally. Still, again, I'd point out that uvector is alpha, APIs can and will change. Ok, with API changes. But they *should not* break normal package usage. That patch simply introduced a bug in uvector. If you think that the patch is useful, then the patch should also include a modification to the UIO instance for a:*:b. Regards Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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; hGetBU simply use the file size.
let elemSize = sizeBU 1 (undefined :: e)
n - fmap ((`div`elemSize) . fromInteger) $ hFileSize h
So, the problem seems to be here.
This simply don't support having two arrays written in the same file,
and sizeBU belongs to the UAE class, whose instances are only declared
for builtin types.
So, the patch is: just revert this change.
Or... use your own UIO instance. That's why it's a type class!
Anyway, for the background on this:
Tue Nov 18 08:44:46 PST 2008 Malcolm Wallace
* Use hFileSize to determine arraysize, rather than encoding it in
the file.
Here is a patch to the uvector library that fixes hGetBU and hPutBU to
use the filesize to determine arraysize, rather than encoding it within
the file. I guess the disadvantages are that now only one array can
live in a file, and the given Handle must indeed be a file, not a
socket Handle. But the advantage is that one can read packed raw datafiles
obtained externally.
Still, again, I'd point out that uvector is alpha, APIs can and will
change.
-- Don
Though I don't really know whether what I did is sane, I can offer a few
patches which seem to work.
Check for sanity before applying :)
hunk ./Data/Array/Vector/Prim/BUArr.hs 85
- hPutBU, hGetBU
+ hPutBU, hGetBU, hGetLengthBU
hunk ./Data/Array/Vector/Prim/BUArr.hs 864
+hGetLengthBU :: forall e. UAE e = Int - Handle - IO (BUArr e)
+hGetLengthBU numEntries h =
+ do
+marr@(MBUArr _ marr#) - stToIO (newMBU numEntries)
+let bytes = sizeBU numEntries (undefined :: e)
+wantReadableHandle hGetBU h $
+\han...@handle__{ haFD=fd, haBuffer=ref, haIsStream=is_stream } - do
+ b...@buffer { bufBuf = raw, bufWPtr = w, bufRPtr = r } - readIORef ref
+ let copied= bytes `min` (w - r)
+ remaining = bytes - copied
+ newr = r + copied
+ newbuf | newr == w = buf{ bufRPtr = 0, bufWPtr = 0 }
+ | otherwise = buf{ bufRPtr = newr }
+ --memcpy_ba_baoff marr# raw (fromIntegral r) (fromIntegral copied)
+ memcpy_ba_baoff marr# raw (fromIntegral r) (fromIntegral copied)
+ writeIORef ref newbuf
+ readChunkBU fd is_stream marr# copied remaining
+ stToIO (unsafeFreezeAllMBU marr)
+
hunk ./Data/Array/Vector/UArr.hs 59
- BUArr, MBUArr, UAE,
- lengthBU, indexBU, sliceBU, hGetBU, hPutBU,
+ BUArr, MBUArr, UAE(..),
+ lengthBU, indexBU, sliceBU, hGetBU, hGetLengthBU, hPutBU,
hunk ./Data/Array/Vector/UArr.hs 867
+ hGetLengthU :: Int - Handle - IO (UArr a)
hunk ./Data/Array/Vector/UArr.hs 875
+primGetLengthU :: UPrim a = Int - Handle - IO (UArr a)
+primGetLengthU n = liftM mkUAPrim . hGetLengthBU n
+
hunk ./Data/Array/Vector/UArr.hs 880
-instance UIO Bool where hPutU = primPutU; hGetU = primGetU
-instance UIO Char where hPutU = primPutU; hGetU = primGetU
-instance UIO Intwhere hPutU = primPutU; hGetU = primGetU
-instance UIO Word where hPutU = primPutU; hGetU = primGetU
-instance UIO Float where hPutU = primPutU; hGetU = primGetU
-instance UIO Double where hPutU = primPutU; hGetU = primGetU
+instance UIO Bool where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Char where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Intwhere hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Word where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Float where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Double where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
hunk ./Data/Array/Vector/UArr.hs 887
-instance UIO Word8 where hPutU = primPutU; hGetU = primGetU
-instance UIO Word16 where hPutU = primPutU; hGetU = primGetU
-instance UIO Word32 where hPutU = primPutU; hGetU = primGetU
-instance UIO Word64 where hPutU = primPutU; hGetU = primGetU
+instance UIO Word8 where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Word16 where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Word32 where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
+instance UIO Word64 where hPutU = primPutU; hGetU = primGetU; hGetLengthU =
primGetLengthU
hunk ./Data/Array/Vector/UArr.hs 892
-instance UIO Int8 where hPutU = primPutU; hGetU = primGetU
-instance UIO Int16 where hPutU = primPutU; hGetU = primGetU
-instance UIO Int32 where hPutU = primPutU; hGetU = primGetU
-instance UIO Int64 where hPutU = primPutU; hGetU = primGetU
+instance UIO Int8 where hPutU = primPutU; hGetU = primGetU;
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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) defaults. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 when loading (so the chances of someone giving you a raw binary file that happens to contain values of the correct endianness is rather low, it seems). On a related note, having a (more) complete testsuite might help prevent patches like this from breaking existing functionality. Maybe a way to resolve the issue is to use the file size and break it according to the size of the two halves of the production? This avoids prefixing array length, but allows the productions to still work. Either way, I'm in the process of writing a Binary instance, so maybe we can get the best of both worlds eventually. Thanks, Dan On Fri, Mar 13, 2009 at 7:21 PM, Don Stewart d...@galois.com wrote: 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) defaults. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken IO support in uvector package, when using non primitive types
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 sent you) given that endianness is already not taken into account when loading (so the chances of someone giving you a raw binary file that happens to contain values of the correct endianness is rather low, it seems). On a related note, having a (more) complete testsuite might help prevent patches like this from breaking existing functionality. Maybe a way to resolve the issue is to use the file size and break it according to the size of the two halves of the production? This avoids prefixing array length, but allows the productions to still work. Either way, I'm in the process of writing a Binary instance, so maybe we can get the best of both worlds eventually. Thanks, Dan On Fri, Mar 13, 2009 at 7:21 PM, Don Stewart d...@galois.com wrote: 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) defaults. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
