duncan.coutts:

In message <20071009150558.GC31961@scytale.galois.com> Don Stewart writes:

...

ketil:

...

Don Stewart writes:

...

The main thing is porting to ghc 6.8 -- which means the new (*faster*) lazy bytestring representation, and the smp parallel quickcheck driver for the testsuite (it'll use N cores, watch the jobs migrate around).

Binary 0.4 seems to require bytestring 0.9, the library formerly known as fps. I just want to mention it, as most network resources (as found by Google) only have discoverd fps 0.7, which is not going to work.

(Oh, and yes, it's at darcs.haskell.org/bytestring/ )

It'd be nice - since I know you're at it anyway :-) - if hackage/cabal would have some support for backwards compatibility. I know GHC 6.8 is the thing to get, but some of us still install what comes with our distribution, so I hope 6.6.1 still will be supported.

Normally this is farily easy to do, with cabal configurations. (See bytestring's .cabal file for example). However, the binary internals changed in such a way that it wasn't worth preserving backwards buildability. Instead, you should use binary 0.3 with ghc 6.6 libs

I'm not convinced that it's not possible. I made my zlib, bzlib and iconv libs work with ghc-6.4, 6.6, and 6.8 which all reply on the internals of Data.ByteString.

So just as soon as I get my ADSL working I'll have a look at making binary work with ghc-6.6 too (and getting the newer faster code integrated as well).

So much to do...

The issue is explicit access to the LPS constructors, which afaik requires cpp to be backward compatible. Maybe that's ok, maybe its not important. -- Don