Re: Trying to install binary-0.4
Don Stewart wrote:
Since you're not using ghc 6.8, you should use binary 0.3 :)
That was PC for "sorry, GHC 6.6 is no longer supported and don't even ask about 6.4" The other day I tried to install the tar library on a GHC 6.4. It's nearly impossible. The old base library gets in the way of installing bytestring, binary 0.4 absolutely needs bytestring 0.9 and tar absolutely needs binary 0.4, but still won't compile because System.Posix is now called System.PosixCompat which actually makes it incompatible. Oh, and everything needs a new cabal, but the setup scripts still picks up the wrong one (apparently, since Distribution.Simple is supposed to be there but GHC doesn't find it). Wanna know the solution? - install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it, - install bytestring 0.9, - install binary 0.4, - edit the Setup.lhs of tar (it still won't run, even though it should), - edit the source of tar, changing System.PosixCompat to System.Posix, - install it. Should I mention that this is made even more difficult by not being root on the machine in question? All this happened with libraries that look as if they are supposed to be stable, but absolutely nothing works right out of the box. Oh, and Cabal Configurations will make it worse, not better. Here's what should be done, imho: - Rename 'base' ASAP and especially before GHC 6.8 comes out, call it 'foundation' or something else. If you want to keep the name 'base', make sure Cabal considers 'base-2.x' a different library than 'base-3.x'. - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. - Start fixing dependencies. - Refrain from renaming stuff. System.Posix is a fine name. - Refrain from always using the latest interface of everything. While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names. Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now. -Udo
On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote:
- Rename 'base' ASAP and especially before GHC 6.8 comes out, call it 'foundation' or something else. If you want to keep the name 'base', make sure Cabal considers 'base-2.x' a different library than 'base-3.x'. - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc.
+10 Stefan
Udo Stenzel wrote:
- install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it,
I forgot, I also tried tar-1.0 on GHC 6.6, and had the same problem there. Even after updating Cabal, there was no way to install 'bytestring' due to the conflict with 'base'. A modified package description for 'base' helped. The reason that tar absolutely wants new stuff is 'instance MonadFix Get', which is not in binary-0.3. If you absolutely want users of GHC 6.6 to stick with binary-0.3, then you should provide a maintenance release binary-0.3.1. And we're back to Eternal Compatibility in Theory... -Udo
Udo Stenzel <u.stenzel@web.de> writes: [incompatibilities between recent libraries/cabal/ghc] I'm installing a GHC-6.8 snapshot, and compiling a bunch of libraries I need in the process (HTTP, HXT, and binary). No show-stoppers, but a lot of rewriting of the dependencies. At least ghc will tell me which package to add, and after a bunch of iterations of this, things work nicely. +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) -k -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde wrote:
+1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.)
There's currently no (easy) way to make a package that just re-exports the contents of other packages. I've been thinking about ways to do this recently, but I'm now convinced that adding direct support to Cabal and the rest of the packaging infrastructure to do this is the wrong way. I'll try to write down my thoughts and post it sometime. Cheers, Simon
Simon Marlow <simonmarhaskell@gmail.com> writes:
+1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc
There's currently no (easy) way to make a package that just re-exports the contents of other packages.
Presumably the hard way would be to simply compile a 'base' consisting of all the modules from those packages? Would that be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants
Udo Stenzel wrote:
- Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4.
Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first.
- Start fixing dependencies.
In progress for the GHC 6.8.1 release, I believe (dcoutts is on the case).
- Refrain from renaming stuff. System.Posix is a fine name.
Who renamed it? It's still called System.Posix AFAIK.
- Refrain from always using the latest interface of everything.
While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names.
Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is.
Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now.
The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering? Cheers, Simon
Simon Marlow wrote:
- Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4.
Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first.
Can it be installed by a user? Because I think my GHC 6.4 always picks up Cabal-1.0, which is installed globally. tar-1.0 then fails through not finding Distribution.Simple.
- Refrain from renaming stuff. System.Posix is a fine name.
Who renamed it? It's still called System.Posix AFAIK.
tar references System.PosixCompat, which apparently comes from a library called unix-compat. I have no idea why the lib isn't just called unix and the modules not System.Posix.*, for tar works fine with System.Posix.*.
Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is.
Well, versioning of shared libraries belongs into the dynamic linker, where it currently is. My gut says, Cabal is more like ld than apt-get. Of course I don't care for the solution ultimately implemented, as long as it works. However, without guidelines for what can be changed between versions of packages, nothing will.
The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right?
Actually I'm more annoyed by the many small and unneccessary stumbling blocks right now. I mean, you could easily put an instruction into the INSTALL file that says "if you're on GHC 6.4 or 6.6, register this replacement configuration for base to sanitize it". You cannot write "if you're on 6.4, edit all references to System.PosixCompat, unless you already installed unix-compat, and you absolutely need binary 0.4, unless you're on 6.4, where you want binary 0.3 but need to patch it so it has instance MonadFix Get, etc. pp." there, since something like that just pisses off your users. But yes, base and bytestring not liking each other is the showstopper, since base can neither be hidden nor upgraded.
In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering?
First off, this should be documented. Having bytestring's Setup do the messy registering would be a good solution, I think. A better one than a gazillion Cabal configurations, I might add. -Udo
On Oct 13, 2007, at 20:35 , Udo Stenzel wrote:
Simon Marlow wrote:
- Refrain from renaming stuff. System.Posix is a fine name.
Who renamed it? It's still called System.Posix AFAIK.
tar references System.PosixCompat, which apparently comes from a library called unix-compat. I have no idea why the lib isn't just called unix and the modules not System.Posix.*, for tar works fine with System.Posix.*.
The tar package uses System.PosixCompat from the unix-compat package to also work under non-posix systems (read Windows). This dependency is listed in the tar.cabal file (see http://hackage.haskell.org/ packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed.
The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right?
Actually I'm more annoyed by the many small and unneccessary stumbling blocks right now. I mean, you could easily put an instruction into the INSTALL file that says "if you're on GHC 6.4 or 6.6, register this replacement configuration for base to sanitize it". You cannot write "if you're on 6.4, edit all references to System.PosixCompat, unless you already installed unix-compat, and you absolutely need binary 0.4, unless you're on 6.4, where you want binary 0.3 but need to patch it so it has instance MonadFix Get, etc. pp." there, since something like that just pisses off your users.
Why not just install unix-compat? It is listed as a dependency after all. I seem to be able to build the tar package against binary-0.3. What exactly is the error that you are getting? By the way, I don't think that users of open source software have a right to be pissed off, or at least authors don't have an obligation to care about them being pissed off. What users do have is a right to submit patches. That said, I agree that the constantly changing packages make it hard to keep dependencies up to date. I guess that this is price we pay for moving quickly. At some point, however, we will have to stop breaking things. /Björn
Bjorn Bringert wrote:
The tar package uses System.PosixCompat from the unix-compat package to also work under non-posix systems (read Windows). This dependency is listed in the tar.cabal file (see http://hackage.haskell.org/ packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed. [...] Why not just install unix-compat? It is listed as a dependency after all.
Actually Windows claims to be a Posix system, too (not that I really believe it or care much). Iirc, unix-compat blew up on GHC 6.4, too, again by picking up the wrong Cabal. I'll check this again tomorrow (don't have access to that machine right now). Anyway, I don't see why something that provides the same functionality as something else needs a different name. With the mechanism of something like apt (Provides, Conflicts, Replaces, ...) I'd have no problem, but Cabal doesn't do that stuff. Maybe it should, though.
I seem to be able to build the tar package against binary-0.3. What exactly is the error that you are getting?
No "instance MonadFix Get" (from memory, I can check this again once I calm down...)
By the way, I don't think that users of open source software have a right to be pissed off, or at least authors don't have an obligation to care about them being pissed off. What users do have is a right to submit patches.
No sir, I always have a right to be pissed off. What I don't have is a right to demand anything from you. The problem with patches is how do you patch something as thoroughly messed up as 'base-2.0' vs. 'base-2.1' vs. 'base-2.1.1'? If I saw a way to fix it, you'd already have a patch, but all I have right now is a GHC with an afroengineered package configuration and a mutilated tar package...
That said, I agree that the constantly changing packages make it hard to keep dependencies up to date.
Moreover, the conical place to find packages is Hackage, right? Tar is there, unix-compat is and binary is, too. But bytestring is missing. Which means you have to hunt down bytestring separately, and cabal-get will fail, too. It also means that some of these packages cannot work on any released version of GHC.
I guess that this is price we pay for moving quickly.
Is it impossible to move quickly on GHC 6.4? -Udo
Hi Udo, On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote:
- Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc.
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. Then link to it from appropriate places on the wikis, and everyone can benefit from it. Thanks Ian
Ian Lynagh wrote:
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc.
That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. -Udo
On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote:
Ian Lynagh wrote:
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc.
That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available.
Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future. Thanks Ian
On Oct 14, 2007, at 12:48 , Ian Lynagh wrote:
On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote:
Ian Lynagh wrote:
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc.
That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available.
Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package?
I think dons has said that the latest bytestring depends on some GHC 6.8 internals that can't reasonably be backported, so if you need the new bytestring API, you're kinda stuck. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
igloo:
On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote:
Ian Lynagh wrote:
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc.
That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available.
Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package?
Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future.
Yes, this was exactly the motivation for not back porting the binary library to 6.4 and earlier: it depends on representation details of ByteString that I'm not going to cpp into portability. If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? If that's the case, manually inserting that instance when using binary 0.3 seems easy enough. -- Don
Don Stewart wrote:
If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo?
No, the issue is that nothing works. It turns out that I actually wanted the MonadFix instance for something unrelated, only at about the same time (and using runGetState, I can even work around that if I want). Here's the story of how not to intall tar-1.0 on GHC 6.4: - I'm on a Ubuntu system, GHC 6.4 has been installen from .deb packages, my local GHC config is empty. - I unpack tar-1.0 and try to run "Setup configure" on it => module "Distribution.Simple" does not export "UserHooks(confHook)" - I need a more recent cabal, my choice is cabal-1.1.6.2, which install flawlessly. - back to tar-1.0 => base >= 2.0 is required, => unix-1.0 is used for unix-any This is already messed up, tar wants unix-compat, not unix-any. (Or is it? See below.) Apparently, it is a fatal error to have a dash in any package name. This explains why System.PosixCompat will never be found, no matter how often I install it. - Since binary is also needed, I'll now install binary-0.3 => could not find module "Data.ByteString" - So I need ByteString. It is not in Hackage. Googling around leads me to http://www.cse.unsw.edu.au/~dons/fps.html, where I download fps-0.7, since fps is what binary.cabal mentions in a comment. - fps-0.7 install flawlessly. - back to building binary => constructor LPS is not found - no newer fps is available, I get bytestring from darcs - bytestring wants a newer cabal. But my patience is already running out, so instead I edit the cabal file, and it installs. - back to building binary => module "Data.ByteString.Base" not found At this point I'm fed up, delete the whole setup and go back to the one I already hacked up to work with binary-0.4. Getting binary-0.4 and hammering it into shape to run on GHC 6.4 would have been the next step anyway, and after that, tar-1.0 needs to be edited to refer to System.Posix and then it would probably work. I dimply remember that it was also impossible to install unix-compat because the wrong cabal was picked up and I ended up throwing out unix-compat completely. Okay, summarizing, what did cabal do for me? Well, it helped me install a new version of cabal and an obsolete version of something else. Sorry, but this whole experience is a huge turnoff. With things going that smoothly, I'm better off using ghc --make and distributing the stuff I cannot rely on directly with my code. Now here's the story for GHC 6.6: - I'm on Debian testing, GHC 6.6.1 is installed, cabal is 1.1.6.2. I'm in a fresh user account without local additions to GHC. - download tar-1.0, unpack and configure. Binary is needed. - download binary-0.3, installs flawlessly. - back to tar-1.0. Now this is weird: => Dependency unix-any: using unix-2.1 => cannot satisfy dependency unix-compat>=0.1 Why does it want *both* unix and unix-compat? The .cabal file mentions only one of them, unix-compat. - download unix-compat, installs flawlessly. - tar works now So things look a lot better on GHC 6.6, but only because I used binary-0.3 instead of 0.4, and I did this only because Don recently mentioned it. Suppose I tried binary-0.4 (because I want 'instance MonadFix Get' or because I don't know better): - dependencies on split base cannot be fulfilled. I have to edit the cabal file. - bytestring needs to be updated - a new cabal is needed - the description of base has to be patched to remove the conflict with base - binary-0.4 installs now - try to configure tar-1.0 => Could not find module `Distribution.Setup' This is no fun at all. Not only do I have to work around the incompatible changes in base, the interface of Cabal also changed in an incompatible way. -Udo -- My teachers could easily have ridden with Jesse James for all the time they stole from me. -- Richard Brautigan
On Fri, 2007-10-19 at 01:00 +0200, Udo Stenzel wrote:
Don Stewart wrote:
If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo?
No, the issue is that nothing works.
I replied earlier to Udo but just for the benefit of everyone else... The current darcs versions of binary and tar work with ghc-6.4, 6.6 and 6.8.x. They do require Cabal-1.2.x, but that also works with ghc 6.4 to 6.8. The bytestring package also works with 6.4 and 6.8. The Data.ByteString code was included in base in ghc-6.6 so the bytestring package is not needed for ghc-6.6. New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar and others (zlib, bzlib, iconv) will appear on hackage in the next few days. The fps package is archaic and should be ignored. There is quite a bit of churn with ghc-6.8 because of the base package having been split up. This requires changes to the .cabal files of many packages to allow them to continue to build with old and new versions of ghc. So all will not be plain sailing for the first few weeks after ghc-6.8 comes out as maintainers update their packages. People will have to be patient and/or stick to ghc-6.6 for a bit. Duncan
Duncan Coutts wrote:
New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar and others (zlib, bzlib, iconv) will appear on hackage in the next few days.
I just tried one of them, iconv. First it wants a recent cabal; that's fine, I installed the darcs version. Then I get this: | Codec/Text/IConv.hs:64:17: | Could not find module `Data.ByteString': | it is a member of package bytestring-0.9, which is hidden Okay, it obviously tries to be smart, but doesn't know that I upgraded to a separate ByteString library. So I take out the gunk about 'flag(bytestring-in-base)' and try again: | Setup: At least the following dependencies are missing: | base <2.0||>=2.2 Of course that was to be expected, since I have base-2.0 hacked to not get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly anticipate this (or could you?). Now what am I supposed to do? Give my messed up base a new version number? (Which one?) Rewrite every single cabal file, hoping that they never become Turing complete turning the exercise into a reverse engineering fest rivaling the ICFP contest? Bite the bullet and install GHC from darcs? For the time being, I'll go with 'ghc --make'. And I think that cabal configurations are an exceptionally bad idea carried to perfection. They make things worse, not better. (And that's just GHC 6.6... I don't want to even think about what happens on Hugs, JHC and YHC.) What would it take to talk you into giving up on supporting the broken base-2.0 and incorporating a patch to unbreak it into the bytestring setup? Can I stop the insanity by simply writing that patch?
So all will not be plain sailing for the first few weeks after ghc-6.8 comes out as maintainers update their packages. People will have to be patient and/or stick to ghc-6.6 for a bit.
Okay, so now we have *three* almost-stable versions of GHC in wide circulation, all of them broken in different ways with respect to cabal packages. I feel tears welling up... -Udo
Duncan and I have started a wiki page to collect proposals for ways to avoid or alleviate the pain from future package reorganisations. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility It's been helpful for me to write all this down, the issues seem much clearer. However, I don't see an obviously best solution. For me proposal 4.2 (see the wiki page) looks the most promising, but it doesn't provide complete backwards compatibility, so I imagine there will be people who disagree. Please read the page. Fix problems, add rationale, add proposals if you have any that are substantially different from those already there. For general discussion just reply to this message (replies directed to libraries@haskell.org). Cheers, Simon
i've forwarded this message from libraries list because i think it's very important topic for Haskell growth. please answer only to libraries@haskell.org This is a forwarded message From: Simon Marlow <simonmarhaskell@gmail.com> ===8<==============Original message text=============== Duncan and I have started a wiki page to collect proposals for ways to avoid or alleviate the pain from future package reorganisations. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility It's been helpful for me to write all this down, the issues seem much clearer. However, I don't see an obviously best solution. For me proposal 4.2 (see the wiki page) looks the most promising, but it doesn't provide complete backwards compatibility, so I imagine there will be people who disagree. Please read the page. Fix problems, add rationale, add proposals if you have any that are substantially different from those already there. For general discussion just reply to this message (replies directed to libraries@haskell.org). Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries ===8<===========End of original message text=========== -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Udo Stenzel wrote: [an entertaining report on cabal/ghc problems]
=> module "Data.ByteString.Base" not found
I also got stuck there when trying to build zlib-0.3 (prerequisite for cabal-install-0.3.0) (with ghc-6.8.0.20070918) I don't even know whether cabal-install is what I want. It downloads a source package from hackage, builds and installs? Best regards, Johannes Waldmann. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGGiV3ZnXZuOVyMIRAoopAJ92RIOHVMX3LlTO2vGu5UTPCOAXkwCglcaf 3gSUPSneA27Mk0ytNiP9K/4= =H3zX -----END PGP SIGNATURE-----
- Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc.
People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc.
there are implicit assumptions in most package managers: - unless you ask for a specific package version, any version will do - if you need a minimum feature set, giving a *lower* bound for the package version will do unless you want to keep updating your package spec every time a new version of a dependency comes out, you really do not want to give *upper* bounds on package versions. haskell software frequently violates both assumptions, deprecating features for one or two a minor versions, then abandoning them in the next. but calling "split-base" "base" goes directly against all basic assumptions of all packages depending on "base". i don't know whether the first intel ai should really still be expected to run the original excel code without change, but suggesting that people keep going back to make old software compatible with continuosly changing new assumptions does not sound right at all. claus
On Fri, 2007-10-12 at 01:27 +0200, Udo Stenzel wrote:
Don Stewart wrote:
Since you're not using ghc 6.8, you should use binary 0.3 :)
That was PC for "sorry, GHC 6.6 is no longer supported and don't even ask about 6.4"
As far as I can see, there's no good reason why binary, tar, etc cannot work with ghc-6.4, 6.6 and 6.8. I've made it work for my zlib & iconv libs just fine without too much cpp'ery. So I'm going to try and fix binary, tar etc to work with all recent ghc. Stay tuned. Obviously it'll need the newest Cabal, but that works with all versions of ghc back to 6.2, and it can be installed as user. Duncan
participants (12)
-
Bjorn Bringert -
Brandon S. Allbery KF8NH -
Bulat Ziganshin -
Claus Reinke -
Don Stewart -
Duncan Coutts -
Ian Lynagh -
Johannes Waldmann -
Ketil Malde -
Simon Marlow -
Stefan O'Rear -
Udo Stenzel