From elliottslaughter at gmail.com Wed Oct 1 01:49:23 2008 From: elliottslaughter at gmail.com (Elliott Slaughter) Date: Wed Oct 1 01:46:06 2008 Subject: GHC on Solaris/SPARC? In-Reply-To: <48E1D6D9.8020107@dfki.de> References: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> <48E1D6D9.8020107@dfki.de> Message-ID: <42c0ab790809302249o5d014701xc16781cefcacc68c@mail.gmail.com> On Tue, Sep 30, 2008 at 12:35 AM, Christian Maeder wrote: > There seems to be a problem with ncurses 5.6 > > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-July/015044.html > > We have Version 5.0.3. > > You may try (originally for > SunOS leo 5.10 Generic_137111-02 sun4u sparc SUNW,Sun-Fire-280R) from > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/libncurses.so.5.0.3 > Thanks. Actually, could you (or do you know anyone who could) compile a binary of darcs 2 for SPARC/Solaris? That's actually why I've been trying to install GHC, because the only binary available on darcs.net is for version 1. Thanks again. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080930/60c83bdb/attachment.htm From g9ks157k at acme.softbase.org Wed Oct 1 08:05:37 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Oct 1 08:02:23 2008 Subject: could not find link destinations Message-ID: <200810011405.38175.g9ks157k@acme.softbase.org> Hello, I built GHC 6.10.0.20080927 on Debian GNU/Linux for i386. At the end of the build process I got numerous warnings of the form ?could not find link destinations for: [?]?. Is this intensional? Best wishes, Wolfgang From karel.gardas at centrum.cz Wed Oct 1 08:56:26 2008 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Oct 1 08:53:11 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) Message-ID: <48E3737A.2070609@centrum.cz> Hello, month or so ago I've noticed that one compiler instance is hanging around and spending 100% of CPU for nothing after a build of head (I'm not sure if it also happens on stable) on my Solaris/x86 buildbot. I've thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated the compiler now to 6.8.3, but the hangup happens again and now I've noted that in fact it's the stage2 compiler: -bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar -bash-3.2$ my question is: is it just me who is affected by this or is it a well known issue in GHC build framework? Thanks, Karel From karel.gardas at centrum.cz Wed Oct 1 12:17:40 2008 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Oct 1 12:14:21 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <48E3737A.2070609@centrum.cz> References: <48E3737A.2070609@centrum.cz> Message-ID: <48E3A2A4.9010907@centrum.cz> Hello, just verified that this also happens while building stable. Thanks! Karel Karel Gardas wrote: > Hello, > > month or so ago I've noticed that one compiler instance is hanging > around and spending 100% of CPU for nothing after a build of head (I'm > not sure if it also happens on stable) on my Solaris/x86 buildbot. I've > thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated > the compiler now to 6.8.3, but the hangup happens again and now I've > noted that in fact it's the stage2 compiler: > > -bash-3.2$ ps -fU buildbot|grep 4380 > buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 > buildbot 4380 641 25 12:38:14 ? 130:33 > /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > -B/buildbot/ghc/kgar > -bash-3.2$ > > my question is: is it just me who is affected by this or is it a well > known issue in GHC build framework? > > Thanks, > Karel > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From igloo at earth.li Wed Oct 1 12:32:07 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 1 12:28:48 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <48E3737A.2070609@centrum.cz> References: <48E3737A.2070609@centrum.cz> Message-ID: <20081001163207.GA27730@matrix.chaos.earth.li> On Wed, Oct 01, 2008 at 02:56:26PM +0200, Karel Gardas wrote: > > -bash-3.2$ ps -fU buildbot|grep 4380 > buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 > buildbot 4380 641 25 12:38:14 ? 130:33 > /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > -B/buildbot/ghc/kgar > > my question is: is it just me who is affected by this or is it a well > known issue in GHC build framework? I don't see it. Can you find out the full commandline please? Thanks Ian From Christian.Maeder at dfki.de Wed Oct 1 13:14:01 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Oct 1 13:10:48 2008 Subject: GHC on Solaris/SPARC? In-Reply-To: <42c0ab790809302249o5d014701xc16781cefcacc68c@mail.gmail.com> References: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> <48E1D6D9.8020107@dfki.de> <42c0ab790809302249o5d014701xc16781cefcacc68c@mail.gmail.com> Message-ID: <48E3AFD9.4070408@dfki.de> On SunOS leo 5.10 Generic_137111-02 sun4u sparc SUNW,Sun-Fire-280R I've created a darcs binary http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/darcs without libcurl from the sources of darcs-2.1.0pre2 I haven't tested it much. So try if it works for you. Cheers Christian Elliott Slaughter wrote: > On Tue, Sep 30, 2008 at 12:35 AM, Christian Maeder > > wrote: > > There seems to be a problem with ncurses 5.6 > http://www.haskell.org/pipermail/glasgow-haskell-users/2008-July/015044.html > > We have Version 5.0.3. > > You may try (originally for > SunOS leo 5.10 Generic_137111-02 sun4u sparc SUNW,Sun-Fire-280R) from > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/libncurses.so.5.0.3 > > > Thanks. > > Actually, could you (or do you know anyone who could) compile a binary > of darcs 2 for SPARC/Solaris? That's actually why I've been trying to > install GHC, because the only binary available on darcs.net > is for version 1. > > Thanks again. > > -- > Elliott Slaughter > > "Any road followed precisely to its end leads precisely nowhere." - > Frank Herbert From elliottslaughter at gmail.com Wed Oct 1 14:07:21 2008 From: elliottslaughter at gmail.com (Elliott Slaughter) Date: Wed Oct 1 14:04:12 2008 Subject: GHC on Solaris/SPARC? In-Reply-To: <48E3AFD9.4070408@dfki.de> References: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> <48E1D6D9.8020107@dfki.de> <42c0ab790809302249o5d014701xc16781cefcacc68c@mail.gmail.com> <48E3AFD9.4070408@dfki.de> Message-ID: <42c0ab790810011107le36614cn61b85b68f1c5e652@mail.gmail.com> On Wed, Oct 1, 2008 at 10:14 AM, Christian Maeder wrote: > On SunOS leo 5.10 Generic_137111-02 sun4u sparc SUNW,Sun-Fire-280R > I've created a darcs binary > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/darcs > without libcurl from the sources of darcs-2.1.0pre2 > > I haven't tested it much. So try if it works for you. It works great, thanks! -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081001/e0b745da/attachment.htm From karel.gardas at centrum.cz Wed Oct 1 14:57:17 2008 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Oct 1 14:53:59 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <20081001163207.GA27730@matrix.chaos.earth.li> References: <48E3737A.2070609@centrum.cz> <20081001163207.GA27730@matrix.chaos.earth.li> Message-ID: <48E3C80D.6060906@centrum.cz> Ian Lynagh wrote: > On Wed, Oct 01, 2008 at 02:56:26PM +0200, Karel Gardas wrote: >> -bash-3.2$ ps -fU buildbot|grep 4380 >> buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 >> buildbot 4380 641 25 12:38:14 ? 130:33 >> /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc >> -B/buildbot/ghc/kgar >> >> my question is: is it just me who is affected by this or is it a well >> known issue in GHC build framework? > > I don't see it. Can you find out the full commandline please? Does this help? # pargs 4380 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci # Thanks, Karel From igloo at earth.li Wed Oct 1 15:12:05 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 1 15:08:45 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <48E3C80D.6060906@centrum.cz> References: <48E3737A.2070609@centrum.cz> <20081001163207.GA27730@matrix.chaos.earth.li> <48E3C80D.6060906@centrum.cz> Message-ID: <20081001191205.GA13677@matrix.chaos.earth.li> On Wed, Oct 01, 2008 at 08:57:17PM +0200, Karel Gardas wrote: > > Does this help? > > # pargs 4380 > 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > -B/buildbot/ghc/kgar > argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. > argv[2]: -dynload > argv[3]: wrapped > argv[4]: --interactive > argv[5]: -v0 > argv[6]: -ignore-dot-ghci > # Hmm, sounds like it's from one of the tests. Can you find out the working directory of the process? Or which files it has open, if any? Thanks Ian From karel.gardas at centrum.cz Wed Oct 1 15:16:12 2008 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Oct 1 15:12:54 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <20081001191205.GA13677@matrix.chaos.earth.li> References: <48E3737A.2070609@centrum.cz> <20081001163207.GA27730@matrix.chaos.earth.li> <48E3C80D.6060906@centrum.cz> <20081001191205.GA13677@matrix.chaos.earth.li> Message-ID: <48E3CC7C.30008@centrum.cz> Ian Lynagh wrote: > On Wed, Oct 01, 2008 at 08:57:17PM +0200, Karel Gardas wrote: >> Does this help? >> >> # pargs 4380 >> 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc >> -B/buildbot/ghc/kgar >> argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc >> argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. >> argv[2]: -dynload >> argv[3]: wrapped >> argv[4]: --interactive >> argv[5]: -v0 >> argv[6]: -ignore-dot-ghci >> # > > Hmm, sounds like it's from one of the tests. Can you find out the > working directory of the process? Or which files it has open, if any? For this one it's no longer possible, since the dir went away when I've forced another head build. Here is the dir from the processes hanging from the last head build (its command line is the same): # pwdx 23414 23414: /export/zone/buildbot/root/buildbot/ghc/kgardas/build/testsuite/tests/ghc-regress/ghci/scripts # pargs 23414 23414: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci # Thanks, Karel From duncan.coutts at worc.ox.ac.uk Wed Oct 1 19:36:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 1 19:33:25 2008 Subject: planning for ghc-6.10.1 and hackage Message-ID: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> Hi, We're getting pretty close to a final ghc-6.10.1 release. We would like of course for the transition this time to be less painful than last time. We all got a lot of flack last time for having no plan in place and making everyone change all their .cabal files etc. This time we can do a lot better. We have already decided to ship two versions of base, version 3 and version 4. Version 4 is the even more stripped down one, and with changes to exception handling etc. The version 3.1 of base depends on base 4 and re-exports most of it with a few differences so that it provides essentially the same api as base 3.0 did (which was included in ghc-6.8.x). However we are not all the way there yet. If we released ghc-6.10.1 today everything would still break. By everything I mean everyone's private projects and all the packages on hackage. The only packages that would build would be trivial ones, or the ones that come with ghc. There are two primary causes of this breakage: * cabal-installs dependency resolver does not work with base 3 & 4 * Cabal will still build packages using base-4 rather than 3 because most packages say "build-depends: base >= 2" rather than "build-depends: base ==3.*" The current cabal-install dependency resolver is based around the idea of picking at most one version of each package. This is because typically using two versions of any package is a mistake. For base we now have the situation that version 3 depends on version 4. So the current resolver will find a conflict as soon as anything needs base 3. The other problem is that packages currently typically specify an optimistic upwardly open range rather than a pessimistic closed range. Cabal uses the heuristic of picking the highest version of each package that satisfies the version constraints. I propose two solutions: * Fix the dependency resolver * Add support in Cabal and Hackage for suggested version constraints The second is considerably easier than the first. The second involves adjusting the dependency resolver to accept a per-package version constraint, like "base < 4", "QuickCheck < 2" or "parsec < 3". It would be a soft constraint that is used only when there is still a free choice between multiple package versions. This should help the situation with upward open version ranges like "build-depends: base". I have done this first part but not tested it yet. Then we would add this list of suggestions as an extra file in the 00-index.tar.gz file on hackage and make cabal-install use it. Hopefully doing this would allow us to not have to change every .cabal file on hackage, at least not immediately. In tandem we should encourage (using automatic warnings) people to use closed version ranges. The first problem is quite hard. I could really do with some help on it. The current dep resolver is a very simple constraint solving algorithm. It's only as clever as was needed to make things work in most cases. It is not a full general solver. It it based on being able to collect version constraints per-package and end up with exactly one version of a package. The obvious adaptation is to say that we can have multiple slots for a single package, one for base 3 and one for base 4. However it is not clear when we would decide to use two slots. Even if we just hack it and hard code there being two for base, we do not know which slot to put constraints into, probably both. My concern here obviously is that if we release a ghc-6.10.1 and tell everyone to start using it immediately for everything then we'll have chaos and take yet more flack for breaking everything. It would also be a great shame since Simon and Ian have already put a not-insignificant amount of effort into the underlying mechanisms to allow us to provide a compatibility base-3 package. Remember we do have the ability to set up an extra hackage server with everything and test how much builds or breaks with ghc-6.10. I'd like the time to do a test run with that before the release so that we can tell people what the expected level of breakage is and how to fix it. I'm not doing that immediately because I already know nothing will work atm without the two above issues being fixed. So I'll aim to work on both issues this week and report back on how things are going. Duncan From dagit at codersbase.com Thu Oct 2 00:28:34 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Oct 2 00:25:17 2008 Subject: Inferred type is less polymorphic than expected, depends on order Message-ID: I was wondering if someone could help me understand why reording the case statements changes the type inference for this code. 1) I find the error message a bit confusing. 2) I don't understand why it's a problem in one order and not the other. I've tried to send this as literate haskell in hopes that you can just copy and paste to a file and run the example. This happens with or without GADTs, this version doesn't have them but they don't turn out to make any difference. \begin{code} {-# LANGUAGE ExistentialQuantification, RankNTypes #-} module Main where data Sealed a = forall x. Sealed (a x) -- Or equivalently: -- data Sealed a where -- Sealed :: a x -> Sealed a \end{code} Originally, I noticed this in a monad context...The original was much more complicated. But, we can simplify it even more, so keep reading. goodOrder :: Monad m => (forall y z. p x y -> q y z -> q x z) -> m (Sealed (p x)) -> (forall b. m (Sealed (q b))) -> m (Sealed (q x)) goodOrder f mx my = do Sealed x <- mx Sealed y <- my return (Sealed (f x y)) badOrder :: Monad m => (forall y z. p x y -> q y z -> q x z) -> m (Sealed (p x)) -> (forall b. m (Sealed (q b))) -> m (Sealed (q x)) badOrder f mx my = do Sealed y <- my Sealed x <- mx return (Sealed (f x y)) Several helpful people in #haskell helped me converge on this greatly simplified version below. \begin{code} f :: p x y -> q y z -> q x z f = undefined \end{code} \begin{code} badOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q x)) badOrder sx sy = case sy of Sealed y -> case sx of Sealed x -> Sealed (f x y) \end{code} \begin{code} goodOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q x)) goodOrder sx sy = case sx of Sealed x -> case sy of Sealed y -> Sealed (f x y) \end{code} \begin{code} main = return () \end{code} This gives the error: $ ghc --make Reorder.lhs [1 of 1] Compiling Main ( Reorder.lhs, Reorder.o ) Reorder.lhs:52:29: Inferred type is less polymorphic than expected Quantified type variable `x' is mentioned in the environment: y :: q x x1 (bound at Reorder.lhs:51:24) When checking an existential match that binds x :: p x2 x The pattern(s) have type(s): Sealed (p x2) The body has type: Sealed (q x2) In a case alternative: Sealed x -> Sealed (f x y) In the expression: case sx of Sealed x -> Sealed (f x y) After discussing this a bit, I think what may be happening in the badOrder case is that the existentially bound type of x is bound after the type `b' in the type of y, leading to the error message. I would appreciate help understanding this, even if the help is, "Go read paper X, Y, and Z." Thanks! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081001/ec2e4262/attachment-0001.htm From dons at galois.com Thu Oct 2 03:58:09 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 2 03:54:38 2008 Subject: planning for ghc-6.10.1 and hackage [or: combining packages to yield new type correct programs] In-Reply-To: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> Message-ID: <20081002075809.GA2564@scytale.galois.com> duncan.coutts: > Hi, > > We're getting pretty close to a final ghc-6.10.1 release. We would like > of course for the transition this time to be less painful than last > time. We all got a lot of flack last time for having no plan in place > and making everyone change all their .cabal files etc. > > This time we can do a lot better. We have already decided to ship two > versions of base, version 3 and version 4. Version 4 is the even more > stripped down one, and with changes to exception handling etc. The > version 3.1 of base depends on base 4 and re-exports most of it with a > few differences so that it provides essentially the same api as base 3.0 > did (which was included in ghc-6.8.x). > > However we are not all the way there yet. If we released ghc-6.10.1 > today everything would still break. By everything I mean everyone's > private projects and all the packages on hackage. The only packages that > would build would be trivial ones, or the ones that come with ghc. Here are my notes on why this is so hard, and so scary, and what we can do. So Duncan and I spent about 6 hours tonight working out how to make the cabal-install constraint solver, and the Cabal configure invariants, work when programs attempt to use base-3 and base-4 on the same system. Here's a summary of why this is non-trivial, * We're trying to compose packages on the users machine to yield new type correct programs. * We're using cabal dependencies to decide when it is safe to do this. Hopefully we don't rule in any type incorrect combinations, nor rule out to many type correct combinations. * This is scary - in fact, we think the package system admits type incorrect programs (based on Typeable, or initialised global state), as it is similar to the runtime linking problem for modules. * We use constraint solving determine when composition is safe, by looking at "package >= 3 && < 4" style constraints. That is, we try to guess when the composition would yield a type correct program. * Again, we're using constraint solving on this language to determine when composition of Haskell module sets (aka packages) would yield type correct Haskell programs All without attempting to do type checking of the interfaces between packages -- the very thing that says whether this is sound! * This previously relied on a strong invariant: + There was only to be one package-version assignment in a program + People didn't change APIs too much, and tried to follow the versioning spec, and wrote .cabal deps that followed the spec. * But now we allow multiple package-version assignments, as long as one depends on the other, and doesn't redefine types. (You'll notice by now we're in deep scary-land, trying, after compile time, to compose type correct modules into sets of modules (packages), and then composing those sets with each other to yield type correct programs, some of which redefine parts of the module hierarchy, and doing all this without implementing a type checking story for when to combine these sets safely). * So, the solver for cabal-install has to be updated to allow the same package to have multiple, conflicting versions, as long as version X depends on version Y, and then not reject programs that produce this constraint. * This is non trivial, but think this refactoring is possible, but it is hard. ultimately we're still making optimistic assumptions about when module sets can be combined to produce type correct programs, and conservative assumptions, at the same time. What we need is a semantics for packages, that in turn uses a semantics for modules, that explains interfaces in terms of types. Packages of functors, containing modules, which we can truly compose to yield type correct programs. * But we think the cabal-install solver will be refactorable to let a good number of programs work, but it'll take a few days of constraint solver hacking. * The end result is that cabal-install should be able to find automated install plans for packages that ask for base-3, even when base-4 is on the system as well, and it uses pieces of base-3 libraries and base-4 libraries. Some more programs will work than if we didn't ship base-3. * The two other ways of combining packages into Haskell programs, + ghc --make + runhaskell Setup.hs configure will always pick base-4 now, so you won't be able to build programs against the base-3 without manually overriding. This means things that need the old exception API, for example, or syb, will break without manual hiding (--package base-3.0.0.0). * We're missing hard stats on what number of things break under which scheme. -- Don From claus.reinke at talk21.com Thu Oct 2 07:13:32 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Oct 2 07:10:21 2008 Subject: planning for ghc-6.10.1 and hackage References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> Message-ID: <637110E9D3FA45C6B6D2A359AC6352A7@cr3lt> > We're getting pretty close to a final ghc-6.10.1 release. We would like > of course for the transition this time to be less painful than last > time. We all got a lot of flack last time for having no plan in place > and making everyone change all their .cabal files etc. Thanks to everyone looking into making the transition less of an event this time! While you've got everyone's attention: there are beta releases (a kind of pre-release-candidate?-) of ghc-6.10.1: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-September/015539.html and there will be release candidates, so package authors can actually try and check whether their package can depend on base4 or should limit itself to base3 (either way, it should still specify exactly the range of versions that is known to work), and whether there are other issues. Two things at least that spring to mind, which authors might want to check: - ghc-6.10.1 comes with haddock 2 (are there hickups in the generated docs?) - ghc-6.10.1 comes with a restructured ghc api (all ghc api clients will break; the fixes are likely to be minor, but fixing will be necessary) > The other problem is that packages currently typically specify an > optimistic upwardly open range rather than a pessimistic closed range. > Cabal uses the heuristic of picking the highest version of each package > that satisfies the version constraints. One could try to use the Ghc Api to run Ghc in typecheck-only mode, trying the highest versions of dependencies, as given by Cabal's heuristic, and suggesting to add upper bounds on any dependencies with which compilation would give errors but for which lower versions are available within the erroneously specified ranges. Being optimistic, if typechecking succeeds, one might want to continue into compilation without further ado, so one might use Ghc directly, just watching for type-errors relating to packages with open ranges, so that Cabal could suggest to add upper bounds and to try again. Not a solution, but perhaps helpful, until Cabal does its own type-checking of interfaces. Claus PS. Is there a hackage administration mailing list, to which your message could have been copied to reach all package authors? From marlowsd at gmail.com Thu Oct 2 07:41:38 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 2 07:38:22 2008 Subject: planning for ghc-6.10.1 and hackage [or: combining packages to yield new type correct programs] In-Reply-To: <20081002075809.GA2564@scytale.galois.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <20081002075809.GA2564@scytale.galois.com> Message-ID: <48E4B372.4080306@gmail.com> Don Stewart wrote: > Here's a summary of why this is non-trivial, > > * We're trying to compose packages on the users machine to yield new > type correct programs. > > * We're using cabal dependencies to decide when it is safe to do this. > Hopefully we don't rule in any type incorrect combinations, nor rule > out to many type correct combinations. > > * This is scary - in fact, we think the package system admits type > incorrect programs (based on Typeable, or initialised global state), > as it is similar to the runtime linking problem for modules. I think what you're referring to is the problem that occurs if the program links in more than one copy of Data.Typeable, which would then invalidate the assumptions that make Data.Typeable's use of unsafeCoerce safe. I wouldn't call this "type-incorrect" - it's a violation of assumptions made by Data.Typeable, not type-incorrectness in the Haskell sense. But you'll be glad to know this doesn't happen anyway, because Data.Typeable's state is held by the RTS these days, for exactly this reason. However, there are libraries which do have private state (e.g. System.Random). We'd prefer not to have more than one copy of the state, but it's not usually fatal: in the case of System.Random, different clients might get streams of random numbers initialised from different seeds, but that's indistinguishable from sharing a single stream of random numbers. Often this global-state stuff is for caching, which works just fine when multiple clients use different versions of the library - it's just a bit less efficient. > * We use constraint solving determine when composition is safe, by looking at > "package >= 3 && < 4" > style constraints. That is, we try to guess when the composition > would yield a type correct program. The way to make this completely safe is to ensure that the resulting program only has one of each module, rather than one of each package version - that's an approximation, because the package name might have changed too. Now, we want to relax this in various ways. One way is the base-3/base-4 situation, where base-3 has a lot of the same modules as base-4, but all they do is re-export stuff from other packages. How do we know this is safe? Well, we don't - the only way is to check whether the resulting program typechecks. Another way we want to relax is it when a dependency is "private" to a package; that is, the package API is completely independent of the dependency, and hence changing the dependency cannot cause compilation failure elsewhere. We've talked in the past about how it would be nice to distinguish private from non-private dependencies. Let's be clear: there are only two ways that something could "go wrong" when composing packages: 1. the composition is not type-correct; you get a compile-time error 2. some top-level state is duplicated; if the programmer has been careful in their use of unsafePerformIO, then typically this won't lead to a run-time error. So it's highly unlikely you end up with a program that goes wrong at runtime, and in those cases arguably the library developer has made incorrect assumptions about unsafePerformIO. > * Again, we're using constraint solving on this language to > determine when composition of Haskell module sets (aka packages) would > yield type correct Haskell programs > > All without attempting to do type checking of the interfaces between > packages -- the very thing that says whether this is sound! True - but we already know that package/version pairs are a proxy for interfaces, and subject to user failure. If the package says that it compiles against a given package/version pair, there's no guarantee that it actually does, that's up to the package author to ensure. Now obviously we'd like something more robust here, but that's a separate problem - not an unimportant one, but separate from the issue of how to make cabal-install work with GHC 6.10.1. cabal-install has to start from the assumption that all the dependencies are correct. Then it can safely construct a complete program by combining all the constraints, and additionally ensuring that the combination has no more than one of each module (and possibly relaxing this restriction when we know it is safe to do so). > * So, the solver for cabal-install has to be updated to allow the same > package to have multiple, conflicting versions, as long as version X > depends on version Y, and then not reject programs that produce this > constraint. Right. > * This is non trivial, but think this refactoring is possible, but it is > hard. ultimately we're still making optimistic assumptions about > when module sets can be combined to produce type correct programs, > and conservative assumptions, at the same time. > > What we need is a semantics for packages, that in turn uses a > semantics for modules, that explains interfaces in terms of types. The semantics is quite straightforward: a module is identified by the pair (package-id, module name), and then you just use the Haskell module system semantics. That is, replace all module names in the program with (package-id, module name) pairs according to which packages are in scope in the context of each module, and then proceed to interpret the program as in Haskell 98. The main problem with looking at things this way is that you need to see the whole program - which is what I've been arguing against in the context of instances. So I agree that looking for a semantics for packages that lets you treat them as an abstract entity would be useful. Still, the above interpretation of packages is a good starting point, because it tells you whether a higher-level semantics is really equivalent. > * The end result is that cabal-install should be able to find automated > install plans for packages that ask for base-3, even when base-4 is on > the system as well, and it uses pieces of base-3 libraries and base-4 > libraries. Some more programs will work than if we didn't ship base-3. So I'm not sure exactly how cabal-install works now, but I imagine you could search for a solution with a backtracking algorithm, and prune solutions that involve multiple versions of the same package, unless those two versions are allowed to co-exist (e.g. base-3/base-4). If backtracking turns out to be too expensive, then maybe more heavyweight constraint-solving would be needed, but I'd try the simple way first. What happens with automatic flag assignments? Presumably we can decide what the flag assignment for each package is up-front? Cheers, Simon From marlowsd at gmail.com Thu Oct 2 09:08:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 2 09:05:43 2008 Subject: planning for ghc-6.10.1 and hackage [or: combining packages to yield new type correct programs] In-Reply-To: <48E4B372.4080306@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <20081002075809.GA2564@scytale.galois.com> <48E4B372.4080306@gmail.com> Message-ID: <48E4C7EB.3090006@gmail.com> Simon Marlow wrote: > So I'm not sure exactly how cabal-install works now, but I imagine you > could search for a solution with a backtracking algorithm, and prune > solutions that involve multiple versions of the same package, unless > those two versions are allowed to co-exist (e.g. base-3/base-4). If > backtracking turns out to be too expensive, then maybe more heavyweight > constraint-solving would be needed, but I'd try the simple way first. Attached is a simple backtracking solver. It doesn't do everything you want, e.g. it doesn't distinguish between installed and uninstalled packages, and it doesn't figure out for itself which versions are allowed together (you have to tell it), but I think it's a good start. It would be interetsing to populate the database with a more realistic collection of packages and try out some complicated install plans. Cheers, Simon -------------- next part -------------- module Main(main) where import Data.List import Data.Function import Prelude hiding (EQ) type Package = String type Version = Int type PackageId = (Package,Version) data Constraint = EQ Version | GE Version | LE Version deriving (Eq,Ord,Show) satisfies :: Version -> Constraint -> Bool satisfies v (EQ v') = v == v' satisfies v (GE v') = v >= v' satisfies v (LE v') = v <= v' allowedWith :: PackageId -> PackageId -> Bool allowedWith (p,v1) (q,v2) = p /= q || v1 == v2 || multipleVersionsAllowed p type Dep = (Package, Constraint) depsOf :: PackageId -> [Dep] depsOf pid = head [ deps | (pid',deps) <- packageDB, pid == pid' ] packageIds :: Package -> [PackageId] packageIds pkg = [ pid | (pid@(n,v),_) <- packageDB, n == pkg ] satisfy :: Dep -> [PackageId] satisfy (target,constraint) = [ pid | pid@(_,v) <- packageIds target, v `satisfies` constraint ] -- | solve takes a list of dependencies to resolve, and a list of -- packages we have decided on already, and returns a list of -- solutions. -- solve :: [Dep] -> [PackageId] -> [[PackageId]] solve [] sofar = [sofar] -- no more deps: we win solve (dep:deps) sofar = [ solution | pid <- satisfy dep, pid `consistentWith` sofar, solution <- solve (depsOf pid ++ deps) (pid:sofar) ] consistentWith :: PackageId -> [PackageId] -> Bool consistentWith pid = all (pid `allowedWith`) plan :: Package -> [[PackageId]] plan p = pretty $ solve [(p,GE 0)] [] pretty = nub . map (nub.sort) main = do print $ plan "p" print $ plan "yi" -- ----------------------------------------------------------------------------- -- Data packageDB :: [(PackageId, [Dep])] packageDB = [ (("base",3), []), (("base",4), []), (("p", 1), [("base", LE 4), ("base", GE 3), ("q", GE 1)]), (("q", 1), [("base", LE 3)]), (("bytestring",1), [("base", EQ 4)]), -- installed (("bytestring",2), [("base", EQ 4)]), -- installed (("ghc", 1), [("bytestring", EQ 1)]), -- installed (("ghc", 2), [("bytestring", GE 2)]), (("yi", 1), [("ghc", GE 1), ("bytestring", GE 2)]) ] multipleVersionsAllowed :: Package -> Bool multipleVersionsAllowed "base" = True -- approximation, of course multipleVersionsAllowed _ = False From claus.reinke at talk21.com Thu Oct 2 12:05:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Oct 2 12:02:25 2008 Subject: planning for ghc-6.10.1 and hackage References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <637110E9D3FA45C6B6D2A359AC6352A7@cr3lt> Message-ID: <0F3DCE7885DA451A8B99BFA3A0C2CF30@cr3lt> >> The other problem is that packages currently typically specify an >> optimistic upwardly open range rather than a pessimistic closed range. >> Cabal uses the heuristic of picking the highest version of each package >> that satisfies the version constraints. > > One could try to use the Ghc Api to run Ghc in typecheck-only mode, > trying the highest versions of dependencies, as given by Cabal's heuristic, > and suggesting to add upper bounds on any dependencies with which > compilation would give errors but for which lower versions are available > within the erroneously specified ranges. You might not even need to code your own Ghc Api client - it seems that using something like this might do for just checking buildability without generating files, running code, or displaying prompts: ghc -ignore-dot-ghci -e '"works"' Consider these example "projects" which are somewhat picky about their package versions: -- WhichBase.hs, needs base 3, or base 4 + syb import X import Data.Generics main = putStrLn x -- WhichGhc.hs, needs ghc < 6.9(whenever the api was changed) import X import GHC main = do newSession Nothing putStrLn x -- X.hs, just to check that we're doing import chasing module X where x = "hi" Then we can find out whether open-ended dependencies like just "ghc" or just "base" will do: $ /cygdrive/c/ghc/ghc-6.8.3/bin/ghc -ignore-dot-ghci -hide-all-packages -package base -package ghc -e '"works"' WhichBase.hs "works" $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc -ignore-dot-ghci -hide-all-packages -package base -e '"works"' WhichBase.hs *** Exception: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc -ignore-dot-ghci -hide-all-packages -package base-3.0.3.0 -e '"works"' WhichBase.hs "works" $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc -ignore-dot-ghci -hide-all-packages -package base -package syb -e '"works"' WhichBase.hs "works" $ /cygdrive/c/ghc/ghc-6.8.3/bin/ghc -ignore-dot-ghci -hide-all-packages -package base -package ghc -e '"works"' WhichGhc.hs "works" $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc -ignore-dot-ghci -hide-all-packages -package base -package ghc -e '"works"' WhichGhc.hs WhichGhc.hs:4:2: Not in scope: `newSession' Does that help? Claus From duncan.coutts at worc.ox.ac.uk Thu Oct 2 04:29:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 2 16:37:23 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <8b02d2150810012235v146223fcp1168324bf3d5e082@mail.gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <8b02d2150810012235v146223fcp1168324bf3d5e082@mail.gmail.com> Message-ID: <1222936172.14163.303.camel@dell.linuxdev.us.dell.com> On Wed, 2008-10-01 at 23:35 -0600, humasect wrote: > Duncan, > > > Since nothing (relatively) is dependant on base 4, why not call it > 'base-4' ? Or hide it like 'ghc' and some other packages are hidden > from inclusion when not explicitly referenced. It is called base-4, it's name is base and the version number is 4. I think what you're asking is why we do not call it "base4-0" or something and the reason is because that looses the connection between versions of packages. Though on the plus side it'd force everyone to specify a major api version, but the right way to do that is to require closed version ranges on base in .cabal files (and other packages that follow the package versioning policy) > Or.. in theory if someone or something can go through all cabal and > add "&& base < 4" through a Hackage filter? <- my apologies I am not > that knowledgeable, but this is what I did for example with my project > that uses storablevector. Yes, that would work if every package on hackage were updated or if we could adjust the .cabal file for every package. Well, it would work for runghc Setup configure, the automatic dependency resolver in cabal-install would still need fixing if we want to continue using that. Don and I have spent the last 6 hours discussing the problem and we are now at the stage where we think it might be solvable. I'm going to work on it all day tomorrow and we'll see where we can get. Duncan From duncan.coutts at worc.ox.ac.uk Thu Oct 2 16:28:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 2 16:37:29 2008 Subject: planning for ghc-6.10.1 and hackage [or: combining packages to yield new type correct programs] In-Reply-To: <48E4C7EB.3090006@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <20081002075809.GA2564@scytale.galois.com> <48E4B372.4080306@gmail.com> <48E4C7EB.3090006@gmail.com> Message-ID: <1222979308.14163.341.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-02 at 14:08 +0100, Simon Marlow wrote: > Simon Marlow wrote: > > > So I'm not sure exactly how cabal-install works now, but I imagine you > > could search for a solution with a backtracking algorithm, and prune > > solutions that involve multiple versions of the same package, unless > > those two versions are allowed to co-exist (e.g. base-3/base-4). If > > backtracking turns out to be too expensive, then maybe more heavyweight > > constraint-solving would be needed, but I'd try the simple way first. > > Attached is a simple backtracking solver. It doesn't do everything you > want, e.g. it doesn't distinguish between installed and uninstalled > packages, and it doesn't figure out for itself which versions are allowed > together (you have to tell it), but I think it's a good start. It would be > interetsing to populate the database with a more realistic collection of > packages and try out some complicated install plans. I've not tried it yet, but the main danger with simple backtracking solvers is that they try too many solutions and take too long. It is afterall an NP-complete problem and the complete search space is exponential. We do need to find solutions for installing all of hackage simultaneously and consistently. The current solver does this in a few tens of seconds (but it does no backtracking). My intuition is that I would not go for a complete solver unless it was a good deal more heavyweight. There is a good paper in this area[1] and is the basis of the solver for the debian packages that the Linspire guys wrote. [1] Modular Lazy Search for Constraint Satisfaction Problems http://citeseer.ist.psu.edu/nordin01modular.html So when we have more time we should look at using a more sophisticated solver along these lines. Duncan From marlowsd at gmail.com Fri Oct 3 04:55:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 3 04:52:18 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> Message-ID: <48E5DE06.4070706@gmail.com> Duncan Coutts wrote: > I propose two solutions: > > * Fix the dependency resolver > * Add support in Cabal and Hackage for suggested version > constraints Simon PJ just came up with a suggestion for the second part. The idea is this: If we see a dependency like "base >= 3" with no upper limit, we should satisfy it with base-3 in preference to base-4, on the grounds that the package is much more likely to build with base-3. This seems to be a solution that works without any magic shims or "preference files" or anything else. Perhaps we could even go as far as saying "base >= 3.0" is equivalent to "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give you a conservative one. I wonder how much stuff would break if we did that. Cheers, Simon From marlowsd at gmail.com Fri Oct 3 05:02:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 3 04:59:37 2008 Subject: could not find link destinations In-Reply-To: <200810011405.38175.g9ks157k@acme.softbase.org> References: <200810011405.38175.g9ks157k@acme.softbase.org> Message-ID: <48E5DFC1.4080103@gmail.com> Wolfgang Jeltsch wrote: > Hello, > > I built GHC 6.10.0.20080927 on Debian GNU/Linux for i386. At the end of the > build process I got numerous warnings of the form ?could not find link > destinations for: [?]?. Is this intensional? These warnings are from Haddock, and are emitted when it can't decide how to hyperlink a particular identifier. Sometimes they are cause for concern, and we should really take a look through them before the release. Cheers, Simon From claus.reinke at talk21.com Fri Oct 3 09:27:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Oct 3 09:24:22 2008 Subject: planning for ghc-6.10.1 and hackage References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> Message-ID: > If we see a dependency like "base >= 3" with no upper limit, we should > satisfy it with base-3 in preference to base-4, on the grounds that the > package is much more likely to build with base-3. This seems to be a > solution that works without any magic shims or "preference files" or > anything else. That sounds reasonable. > Perhaps we could even go as far as saying "base >= 3.0" is equivalent to > "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give > you a conservative one. I wonder how much stuff would break if we did that. All open-ended dependencies are lies.. Well, actually they are optimistic approximations (some programs will work with base 3 or base 4), and closed dependency ranges are pessimistic approximations (few programs need all of base 3). The problem is that there is no definite interface spec. At the moment, precise package versions are the only thing that Cabal knows about, on the understanding that package+version names (but not details) an API, and that the real API is some unidentified subset of the named API. In light of this, I've been wondering whether the complete list of precise package versions should really be part of the .cabal file: - they are little more than hints: I guess that a specific list of package+version names identifies a superset of the API my package needs, and if that guess turns out to be correct, I leave it in the .cabal file as the closest thing to an import API spec that Cabal allows me to write. - they can be inaccurate both upwards and downwards: my package rarely needs all of the import API named by the build-depends, and I'd often be happy if the import API for my package would be supplied by some other combination of packages (eg, base-4 + syb instead of base-3). - having precise build-depends means augmenting the package tarballs again and again, after testing with newer dependency versions. Wouldn't it make sense to keep only the initial hint in the .cabal file ("this is the precise combination of packages+versions that my package did build with"), and to let Cabal or Ghc or other tools figure out additional combinations that also allow the package to build successfully? These combinations could be tool-generated into a .cabal-configurations file, which could be stored outside the package tarball, and augmented whenever new dependency versions come out. Downloading the package and its successful configuration record would allow cabal-install to pick a combination that best matches locally installed packages. If a package doesn't have a successful configuration record, cabal-install can either try to generate one from the local packages, or insist on downloading the original configuration. If the former, cabal-install ought to report that back to hackage, to save itself work on the next installation. In any case, you wouldn't need to update all hackage package tarballs to add new dependency version numbers (just their .cabal-configurations records), and you could do that incrementally, when new dependency versions come out, and only once per package (instead of everytime someone tries to install it). Does that sound plausible? Claus From bulat.ziganshin at gmail.com Fri Oct 3 11:44:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Oct 3 11:47:12 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <48E5DE06.4070706@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> Message-ID: <1682226319.20081003194425@gmail.com> Hello Simon, Friday, October 3, 2008, 12:55:34 PM, you wrote: > Perhaps we could even go as far as saying "base >= 3.0" is equivalent to > "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give > you a conservative one. I wonder how much stuff would break if we did that. this looks reasonable for any package yjat follows versioning policy since changing major number means that anything in api may change you may use this as "theoretical" foundation for such trick :) of course in the future it will be great if people will start to use intervals with both high and low bounds -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Fri Oct 3 12:12:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 3 12:38:48 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <48E5DE06.4070706@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> Message-ID: <1223050331.14163.394.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-03 at 09:55 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > > I propose two solutions: > > > > * Fix the dependency resolver > > * Add support in Cabal and Hackage for suggested version > > constraints > > Simon PJ just came up with a suggestion for the second part. The idea is this: > > If we see a dependency like "base >= 3" with no upper limit, we should > satisfy it with base-3 in preference to base-4, on the grounds that the > package is much more likely to build with base-3. This seems to be a > solution that works without any magic shims or "preference files" or > anything else. The suggested version thing really turns out to be the same as saying we should satisfy base >= 3 using base-3 rather than base-4. We want that general mechanism anyway. So I think it's actually more general. We don't need to tell the resolver about base specially, it just extends an already existing notion of soft version preferences. The current resolver allows for soft preferences on the installed state, this just extends that to a general version preference. We want it anyway to better manage transitions like QC1 -> 2 or Parsec 2 -> 3. > Perhaps we could even go as far as saying "base >= 3.0" is equivalent to > "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give > you a conservative one. I wonder how much stuff would break if we did that. The biggest problem is really just that the resolver has to deal with two instances of the same package in its solution. It was designed from the beginning with the assumption that it was accumulating version constraints per-package name (and that all constraints on a package version should be simultaneously satisfiable). We should however have packages declare if they have opted into the package versioning policy. Base would be one of them. We could then warn users when they are using bad version ranges in dependencies on such packages. It'd have to be a field in the .cabal file. Any suggestions for a good name? package-version-policy: Yarr! Duncan From allbery at ece.cmu.edu Fri Oct 3 12:53:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Oct 3 12:49:47 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <48E5DE06.4070706@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> Message-ID: <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> On Oct 3, 2008, at 04:55 , Simon Marlow wrote: > Duncan Coutts wrote: >> I propose two solutions: >> * Fix the dependency resolver >> * Add support in Cabal and Hackage for suggested version >> constraints > > Simon PJ just came up with a suggestion for the second part. The > idea is this: > > If we see a dependency like "base >= 3" with no upper limit, we > should satisfy it with base-3 in preference to base-4, on the > grounds that the package is much more likely to build with base-3. > This seems to be a solution that works without any magic shims or > "preference files" or anything else. Choose the lowest available version that satisfies all of the constraints? -- 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 From duncan.coutts at worc.ox.ac.uk Fri Oct 3 12:54:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 3 12:50:49 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> Message-ID: <1223052852.14163.406.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-03 at 14:27 +0100, Claus Reinke wrote: > > Perhaps we could even go as far as saying "base >= 3.0" is equivalent to > > "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give > > you a conservative one. I wonder how much stuff would break if we did that. > > All open-ended dependencies are lies.. Yes! > Well, actually they are optimistic approximations (some programs will > work with base 3 or base 4), and closed dependency ranges are > pessimistic approximations (few programs need all of base 3). The > problem is that there is no definite interface spec. Yes. Don and I are rather of the opinion that we need to look much more carefully at the package system. We're basically operating without the reassuring assistance of the type checker. There are some practical things we can do to make the current system work considerably better though. If we get the platform packages to opt into the package versioning policy and get cabal/hackage to warn about upwardly open version ranges then that'd go a long way to making things better. We should also write a tool using the ghc-api to compare apis of different versions of packages to inform people of changes and enforce the versioning policy for packages that have opted in. Having those interface specs around might also help a more robust package composition consistency checker or solver. Duncan From duncan.coutts at worc.ox.ac.uk Fri Oct 3 12:56:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 3 12:52:37 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> Message-ID: <1223052960.14163.409.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-03 at 12:53 -0400, Brandon S. Allbery KF8NH wrote: > > If we see a dependency like "base >= 3" with no upper limit, we > > should satisfy it with base-3 in preference to base-4, on the > > grounds that the package is much more likely to build with base-3. > > This seems to be a solution that works without any magic shims or > > "preference files" or anything else. > > > Choose the lowest available version that satisfies all of the > constraints? Unfortunately this is the opposite of people normal (mostly reasonable) expectations. Perhaps you mean the highest revision of the lowest major version. Again this requires giving a semantics to the version numbers, which is just what the versioning policy does (for packages that have opted in). Duncan From jcab.lists at JCABs-Rumblings.com Fri Oct 3 13:17:55 2008 From: jcab.lists at JCABs-Rumblings.com (Juan Carlos Arevalo Baeza) Date: Fri Oct 3 13:14:32 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1682226319.20081003194425@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> <1682226319.20081003194425@gmail.com> Message-ID: <48E653C3.2090609@JCABs-Rumblings.com> How can you _reasonably_ put in a high bound if future versions of a library (which might, or even most likely, work with yours) aren't know at the time the limit is put in place? Basically, if you want certainty, >= must be deprecated or eliminated altogether, and the only reasonable thing is (maybe multi-choice) ==, so you can communicate which _discrete_ versions you've tested with it. After all, even minor revisions contain bug fixes, and it is all-too-possible that you might rely on buggy behavior inadvertently. It would be awesome if packages could somehow advertise which older versions they _should_ backwards-compatible with. Cabal/GHC should still pick the closest available match to a version explicitly mentioned by your library (rather than the newest one), and report all risky (non-identical) choices in case of build failure. Reports like: "Possible reasons for failure: base package version requested was 3.2 but the closest match found was 4.1, which didn't advertise backwards compatibility; stm package version required was 2.1, but the closest match found was 2.3 which does advertise backwards compatibility but might be in error". That way people with their own library mixes can hope for the best, brace for the worst and get actionable "go install those requested versions, you dummy" info in case of failure. It would also be awesome if hackage could be a conduit for peer verification of library version compatibility. It would be awesome if cabal could be used to communicate to hackage a successful build with a previously-presumed-risky combination of libraries, so that hackage could update the script appropriately. I suppose you'd want more than a single report (say, three reports) before updating the package to claim compatibility with each specific library version, but that's in the realm of the details. And don't forget platform compatibility. A particular library could work with package X version 3 or 4 on Windows, but require version 4 on Linux. Maybe in version 4 of the package they substituted hardcoded ++ "\\" ++ with portable or something silly-but-deadly like that. I guess my point is that, if you want cabal to make a dependable determination of whether a package mix will work well together, then you need sufficiently rich info, and simple version comparisons just won't cut it. JCAB Bulat Ziganshin wrote: > Hello Simon, > > Friday, October 3, 2008, 12:55:34 PM, you wrote: > > >> Perhaps we could even go as far as saying "base >= 3.0" is equivalent to >> "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give >> you a conservative one. I wonder how much stuff would break if we did that. >> > > this looks reasonable for any package yjat follows versioning policy > since changing major number means that anything in api may change > > you may use this as "theoretical" foundation for such trick :) of > course in the future it will be great if people will start to use > intervals with both high and low bounds > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081003/06ef1cfd/attachment.htm From igloo at earth.li Fri Oct 3 13:24:42 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Oct 3 13:21:16 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1223052852.14163.406.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> <1223052852.14163.406.camel@dell.linuxdev.us.dell.com> Message-ID: <20081003172442.GA2382@matrix.chaos.earth.li> On Fri, Oct 03, 2008 at 09:54:12AM -0700, Duncan Coutts wrote: > > better. We should also write a tool using the ghc-api to compare apis of > different versions of packages to inform people of changes and enforce > the versioning policy for packages that have opted in. We should also use such a tool to check/generate "this was added in version n" to the haddock docs. Thanks Ian From bulat.ziganshin at gmail.com Fri Oct 3 18:09:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Oct 3 18:06:25 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> Message-ID: <376597718.20081004020917@gmail.com> Hello Brandon, Friday, October 3, 2008, 8:53:05 PM, you wrote: > Choose the lowest available version that satisfies all of the > constraints? and bugfixed versions will be never used :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Fri Oct 3 19:44:31 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Oct 3 19:41:07 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <376597718.20081004020917@gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <48E5DE06.4070706@gmail.com> <4C34521C-2794-4DF4-AF06-9C50058A3C2A@ece.cmu.edu> <376597718.20081004020917@gmail.com> Message-ID: On 2008 Oct 3, at 18:09, Bulat Ziganshin wrote: > Friday, October 3, 2008, 8:53:05 PM, you wrote: >> Choose the lowest available version that satisfies all of the >> constraints? > > and bugfixed versions will be never used :) As Duncan said, I misspoke slightly. I was actually assuming something like the rules used for shared libraries: given a version X.Y.Z, X changes with API changes, Y with large non-API changes, Z with minor patches, and the resolution algorithm chooses the latest version with the same X (and, on some systems, tries to match Y as well), and older versions are never accepted. -- 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 From mechvel at botik.ru Sun Oct 5 04:55:22 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Oct 5 04:52:11 2008 Subject: isTypeId, isValueId Message-ID: <20081005085522.GA25260@scico.botik.ru> People, I need to implement the functions isTypeId, isValueId :: String -> Bool which check whether the argument fits respectively the syntax of a type identifier and of a value identifier -- in the Haskell-98 syntax for a program. The argument is produced by lexLots. For example, my program applies lexLots "ab-(f_21 -- I expect: ["ab", "-", "(", "f_21", "<", "Ab", ":", "c"] -- 1 2 3 4 Then, I think, only (1), (2), (3) and (4) are type or value identifiers ... What is the most regular expression for isTypeId, isValueId ? I presume to consider first the Standard library, and if fail, then the GHC library. Thank you in advance for your advice. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Sun Oct 5 10:14:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 5 10:11:05 2008 Subject: One stage2 compiler hanging around after head build (Solaris/x86 buildbot) In-Reply-To: <48E3CC7C.30008@centrum.cz> References: <48E3737A.2070609@centrum.cz> <20081001163207.GA27730@matrix.chaos.earth.li> <48E3C80D.6060906@centrum.cz> <20081001191205.GA13677@matrix.chaos.earth.li> <48E3CC7C.30008@centrum.cz> Message-ID: <20081005141436.GA19788@matrix.chaos.earth.li> On Wed, Oct 01, 2008 at 09:16:12PM +0200, Karel Gardas wrote: > > # pwdx 23414 > 23414: > /export/zone/buildbot/root/buildbot/ghc/kgardas/build/testsuite/tests/ghc-regress/ghci/scripts > > # pargs 23414 > 23414: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > -B/buildbot/ghc/kgar > argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc > argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. > argv[2]: -dynload > argv[3]: wrapped > argv[4]: --interactive > argv[5]: -v0 > argv[6]: -ignore-dot-ghci > # Can you try to work out which test is causing the problem, please? e.g. in testsuite/tests/ghc-regress/ghci/scripts run make fast CLEANUP=1 TEST=ghci001 replacing "ghci001" with each of the first arguments to test in all.T. Or alternatively, remove stanzas in all.T using binary search and running make fast CLEANUP=1 until you narrow down which one causes the problem. Thanks Ian From leledumbo_cool at yahoo.co.id Sun Oct 5 23:02:24 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sun Oct 5 22:58:52 2008 Subject: Is -fvia-C still needed? In-Reply-To: <03325F35F37E4F408F528B72D14EE592@cr3lt> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> <48DB8188.9070105@gmail.com> <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> <19682498.post@talk.nabble.com> <48DCF451.1030409@gmail.com> <03325F35F37E4F408F528B72D14EE592@cr3lt> Message-ID: <19831381.post@talk.nabble.com> > We could theoretically ship a cut-down GHC bundle with no gcc ... What about shipping two versions? One with bundled MinGW and other without > Having fully-functional-out-of-the-box GHC installers is very useful ... Good idea. -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19831381.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From duncan.coutts at worc.ox.ac.uk Mon Oct 6 03:16:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 6 03:13:40 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> Message-ID: <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> On Wed, 2008-10-01 at 16:36 -0700, Duncan Coutts wrote: > I propose two solutions: > > * Fix the dependency resolver > * Add support in Cabal and Hackage for suggested version > constraints > So I'll aim to work on both issues this week and report back on how > things are going. Done! Four days and 15 patches later I can construct install plans for 710 packages from hackage using the darcs cabal-install and last nights ghc-6.10. (It would be more like 730 but I've not got gtk2hs built for 6.10, for ghc-6.8 it's 743 packages) The next step is to actually build everything and compare. We'll do this tomorrow and report results. There are three combinations we are interested in: * baseline: ghc-6.8 and Cabal-1.4 * new Cabal: ghc-6.8 and Cabal-1.6 * new ghc: ghc-6.10 and Cabal-1.6 So we'll try building all 700+ packages all three ways and compare the build reports. We'll report anything interesting that might indicate new ghc bugs. If all looks ok I'll also release Cabal-1.6. Duncan From waldmann at imn.htwk-leipzig.de Mon Oct 6 10:13:04 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Oct 6 10:12:19 2008 Subject: System.Process.runInteractiveCommand, exit_group () Message-ID: <48EA1CF0.6040704@imn.htwk-leipzig.de> Dear all, I have a Haskell program (compiled with -threaded) that calls an external executable via System.Process.runInteractiveCommand (and then I do waitForProcess). The external program finishes with exit_group () (I don't have source, but I see it from strace). Then, my Haskell program dies immediately. Is exit_group () the reason? How can I prevent this? Thanks - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081006/d75ae287/signature.bin From waldmann at imn.htwk-leipzig.de Mon Oct 6 11:03:06 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Oct 6 11:02:19 2008 Subject: System.Process.runInteractiveCommand, exit_group () Message-ID: <48EA28AA.8090105@imn.htwk-leipzig.de> Solved - exit_group() wasn't the problem. My wrapper program silently died from SIGPIPE. Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081006/3d97ba77/signature.bin From waldmann at imn.htwk-leipzig.de Tue Oct 7 06:55:39 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 7 06:54:55 2008 Subject: ghc-6.10.0.20081005 binary refers to (non existent?) libedit.so.0 Message-ID: <48EB402B.6070809@imn.htwk-leipzig.de> Dear all, I tried to install the binary snapshot on Debian (etch) x86_64 and got: /usr/local/lib/ghc-6.10.0.20081005/ghc: error while loading shared libraries: libedit.so.0: cannot open shared object file: No such file or directory I do have libedit (I think): lrwxrwxrwx 1 root root 14 2007-11-30 16:01 /usr/lib/libedit.so.2 -> libedit.so.2.9 -rw-r--r-- 1 root root 140640 2006-03-19 15:26 /usr/lib/libedit.so.2.9 This is the right package? dpkg -l "libedit*" ... ii libedit2 2.9.cvs.20050518 BSD editline and history libraries Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081007/b924bd0d/signature.bin From marlowsd at gmail.com Tue Oct 7 08:20:52 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 7 08:17:22 2008 Subject: System.Process.runInteractiveCommand, exit_group () In-Reply-To: <48EA28AA.8090105@imn.htwk-leipzig.de> References: <48EA28AA.8090105@imn.htwk-leipzig.de> Message-ID: <48EB5424.5020603@gmail.com> Johannes Waldmann wrote: > Solved - exit_group() wasn't the problem. > My wrapper program silently died from SIGPIPE. This is something we changed in GHC 6.10.1, incedentally. Now SIGPIPE doesn't silently exit the program, and it will get an exception instead. Cheers, Simon From marlowsd at gmail.com Tue Oct 7 08:22:45 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 7 08:19:12 2008 Subject: ghc-6.10.0.20081005 binary refers to (non existent?) libedit.so.0 In-Reply-To: <48EB402B.6070809@imn.htwk-leipzig.de> References: <48EB402B.6070809@imn.htwk-leipzig.de> Message-ID: <48EB5495.3080009@gmail.com> Johannes Waldmann wrote: > Dear all, > > I tried to install the binary snapshot on Debian (etch) x86_64 and got: > > /usr/local/lib/ghc-6.10.0.20081005/ghc: error while loading shared > libraries: libedit.so.0: cannot open shared object file: No such file or > directory > > I do have libedit (I think): > > lrwxrwxrwx 1 root root 14 2007-11-30 16:01 /usr/lib/libedit.so.2 -> > libedit.so.2.9 > -rw-r--r-- 1 root root 140640 2006-03-19 15:26 /usr/lib/libedit.so.2.9 > > This is the right package? > > dpkg -l "libedit*" > ... > ii libedit2 2.9.cvs.20050518 BSD editline and history libraries For some reason it seems that Fedora and Debian are using different versions of the libedit shared library. Our binary installers are build on Fedora. For the release we'll probably have two binary distributions, one for Fedora and one for Debian(-based) systems. You might be able to get away with symlinking libedit.so.0 to libedit.so.2 in the meantime. Cheers, Simon From waldmann at imn.htwk-leipzig.de Tue Oct 7 08:59:13 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 7 08:58:23 2008 Subject: Control.Exception Message-ID: <48EB5D21.6040408@imn.htwk-leipzig.de> with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ -> return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? I found some references (in list emails) to catchAny, ignoreExceptions but these don't seem to have made it? Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081007/cb0805b3/signature.bin From nominolo at googlemail.com Tue Oct 7 10:25:50 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Oct 7 10:22:13 2008 Subject: Control.Exception In-Reply-To: <48EB5D21.6040408@imn.htwk-leipzig.de> References: <48EB5D21.6040408@imn.htwk-leipzig.de> Message-ID: <916b84820810070725s32132e08odd5883d1a288705e@mail.gmail.com> 2008/10/7 Johannes Waldmann : > with 6.10, the following does not typecheck: > > foo `Control.Exception.catch` \ _ -> return bar > > Ambiguous type variable `e' in the constraint: > `Control.Exception.Exception e' catch \(e :: SomeException) -> ... This requires language ScopedTypeVariables (and perhaps PatternSignatures). Of cause, you should try to be more specific about which exceptions you want to catch as e.g., Ctrl-C and many other things are also reported as exceptions. > > It is probably bad programming style anyway but what is the workaround? > I found some references (in list emails) to catchAny, ignoreExceptions > but these don't seem to have made it? > > Best regards, J.W. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From waldmann at imn.htwk-leipzig.de Tue Oct 7 14:50:03 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 7 14:46:29 2008 Subject: Control.Exception Message-ID: <48EBAF5B.9010002@imn.htwk-leipzig.de> > catch \(e :: SomeException) -> ... So, this changes the API (from 6.8 to 6.10)? I see there is Control.OldException (providing the "old catch") but that still does not help me if I want my code compile with both 6.8 and 6.10. Is there some version of catch that works both ways? best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081007/29566385/signature.bin From duncan.coutts at worc.ox.ac.uk Tue Oct 7 15:54:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 7 15:52:24 2008 Subject: Control.Exception In-Reply-To: <48EBAF5B.9010002@imn.htwk-leipzig.de> References: <48EBAF5B.9010002@imn.htwk-leipzig.de> Message-ID: <1223409295.14163.566.camel@dell.linuxdev.us.dell.com> On Tue, 2008-10-07 at 20:50 +0200, Johannes Waldmann wrote: > > catch \(e :: SomeException) -> ... > > So, this changes the API (from 6.8 to 6.10)? > > I see there is Control.OldException (providing the "old catch") > but that still does not help me if I want my code compile > with both 6.8 and 6.10. Is there some version of catch that works both ways? Build your package using base-3 rather than base-4. Duncan From igloo at earth.li Tue Oct 7 16:02:30 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 7 15:58:52 2008 Subject: Control.Exception In-Reply-To: <1223409295.14163.566.camel@dell.linuxdev.us.dell.com> References: <48EBAF5B.9010002@imn.htwk-leipzig.de> <1223409295.14163.566.camel@dell.linuxdev.us.dell.com> Message-ID: <20081007200230.GA4724@matrix.chaos.earth.li> On Tue, Oct 07, 2008 at 12:54:55PM -0700, Duncan Coutts wrote: > On Tue, 2008-10-07 at 20:50 +0200, Johannes Waldmann wrote: > > > catch \(e :: SomeException) -> ... > > > > So, this changes the API (from 6.8 to 6.10)? > > > > I see there is Control.OldException (providing the "old catch") > > but that still does not help me if I want my code compile > > with both 6.8 and 6.10. Is there some version of catch that works both ways? > > Build your package using base-3 rather than base-4. Another option would be for someone to fill out http://darcs.haskell.org/packages/extensible-exceptions/ so that it becomes a complete replacement. Currently it only has what we needed in GHC. Thanks Ian From mad.one at gmail.com Tue Oct 7 21:18:06 2008 From: mad.one at gmail.com (Austin Seipp) Date: Tue Oct 7 21:14:29 2008 Subject: More DPH Message-ID: <1223428072-sup-7032@existential.local> Hi, I've been playing with DPH more; this time I've taken the Parallel Strategies binary-trees benchmark and converted it to use DPH. The results are here: http://haskell.org/haskellwiki/Shootout/Parallel/BinaryTreesDPH I haven't yet got anybody to test it on a 4/8 core machine, but on my core2duo it performs reasonably well, although as you can see from the test results, parallel strategies win every time (although some not by very much.) Is there any way to improve this code? I've noted at the bottom something that might be a potential bottleneck, or does U.toList fuse to make it as fast as possible? Austin P.S. I'm thinking of perhaps spending a few days and parallelising some of the other benchmarks; I'll keep people updated if they want to hear about it. From marlowsd at gmail.com Wed Oct 8 04:19:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Oct 8 04:15:59 2008 Subject: Control.Exception In-Reply-To: <48EB5D21.6040408@imn.htwk-leipzig.de> References: <48EB5D21.6040408@imn.htwk-leipzig.de> Message-ID: <48EC6D16.3090308@gmail.com> Johannes Waldmann wrote: > with 6.10, the following does not typecheck: > > foo `Control.Exception.catch` \ _ -> return bar > > Ambiguous type variable `e' in the constraint: > `Control.Exception.Exception e' > > It is probably bad programming style anyway but what is the workaround? As long as you're aware that it is bad programming style. We deliberately didn't include an easy way to do this, because we want people to think about why they need to catch *all* exceptions (most of the time it's a bug). Cheers, Simon From igloo at earth.li Wed Oct 8 16:09:39 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 8 16:05:57 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 Message-ID: <20081008200939.GA5675@matrix.chaos.earth.li> We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team From kolmodin at dtek.chalmers.se Wed Oct 8 16:56:45 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Wed Oct 8 16:53:04 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081008200939.GA5675@matrix.chaos.earth.li> References: <20081008200939.GA5675@matrix.chaos.earth.li> Message-ID: <48ED1E8D.6060701@dtek.chalmers.se> Ian Lynagh wrote: > We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the > first release candidate for GHC 6.10.1. > > You can download the release candidate from here: > http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html > This page includes: > * a Windows installer > * an OS X installer > * bindists for amd64/Linux and ix86/Linux > * the sources > It's also available in Gentoo Linux, hard masked. If you're not already familiar with the Gentoo Haskell overlay, use layman[1] to get the haskell overlay and unmask[2] the packages dev-lang/ghc and dev-haskell/cabal. Then, simply: $ emerge ghc Cheers, Lennart Kolmodin [1] http://www.gentoo.org/proj/en/overlays/userguide.xml [2] http://gentoo-wiki.com/Masked#Hard_Masked From prj at po.cwru.edu Wed Oct 8 18:04:31 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Wed Oct 8 18:00:51 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081008200939.GA5675@matrix.chaos.earth.li> (Ian Lynagh's message of "Wed\, 8 Oct 2008 21\:09\:39 +0100") References: <20081008200939.GA5675@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the > first release candidate for GHC 6.10.1. The build problems I reported about the 20080921 beta are still present: I ran into some problems due to having gmp installed in an unusual place. I passed --with-gmp-{includes,libraries} to ./configure, set $CPPFLAGS and $LDFLAGS for ./configure, and set the corresponding -optl, etc., flags in SRC_HC_OPTS and GHC_CC_OPTS in mk/build.mk. With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime. pwd is compiled and linked without problems; it just can't run. So it seems the bootstrap compiler knows where its gmp is, and is providing the necessary -L flags, but not -Xlinker -R. I got past this by editing ./configure to add the necessary flags to the build command, but I wonder if turning pwd into a C program would be less troublesome. The next problem was with cabal-bin. The command to build it didn't use SRC_HC_OPTS, so that binary also couldn't find libgmp.so when it ran. I used this patch: --- libraries/Makefile~ 2008-09-21 13:06:31.000000000 -0400 +++ libraries/Makefile 2008-09-23 01:58:29.000000000 -0400 @@ -131,7 +131,7 @@ cabal-bin: cabal-bin.hs -mkdir bootstrapping - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin bootstrapping.conf: cabal-bin echo "[]" > $@.tmp @@ -154,9 +154,9 @@ mkdir ifBuildable $(CP) ifBuildable.hs ifBuildable/ ifeq "$(stage)" "2" - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable else - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable endif .PHONY: all build configure That gets me to this point: Preprocessing library hpc-0.5.0.2... dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.10.0.20080921+spf+0/compile/src/ghc-6.10.0.20080921/libraries' make: *** [stage1] Error 2 I'm not sure how to fix this. I assume there's some way to pass SRC_HC_OPTS to cabal-bin, but I don't know how. paul From garious at gmail.com Wed Oct 8 20:10:53 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Oct 8 20:07:11 2008 Subject: Parsec in 6.10 RC 1 Message-ID: <1f3dc80d0810081710w3f35bf8vd0ccb7939580e18e@mail.gmail.com> The instance for "Functor (Either ParserError)" disappeared. Is that intentional? Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081008/3c3b9405/attachment.htm From bernardy at chalmers.se Thu Oct 9 04:20:50 2008 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Thu Oct 9 04:17:08 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> Message-ID: <953e0d250810090120k3f498d15jd24afc5927fa393a@mail.gmail.com> On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts wrote: > Done! > > Four days and 15 patches later I can construct install plans for 710 > packages from hackage using the darcs cabal-install and last nights > ghc-6.10. (It would be more like 730 but I've not got gtk2hs built for > 6.10, for ghc-6.8 it's 743 packages) Is this included in the ghc 6.10 rc1? I tried: $ cabal install Diff Resolving dependencies... but it seems to remain stuck there. Thanks, JP. From mechvel at botik.ru Thu Oct 9 04:28:50 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Oct 9 04:25:31 2008 Subject: Backspace in ghci-6.10.1-candidate Message-ID: <20081009082849.GA5167@scico.botik.ru> This is about testing 6.10.0.20081007. 1. DoCon works with it. 2. The question is how to `install' Backspace and UpArrow in ghci. I make it from source by 6.10-candidate and also by itself -- on Debian Linux. And ghci does not process Backspace and UpArrow. ./configure reported configure:2303: checking whether ghc has editline package configure:2314: result: no And the Debian system area shows the files /usr/lib/libedit.so.2 /usr/lib/iceape/components/libeditor.so /usr/lib/libedit.so.2.9 Please, what is wrong here? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Thu Oct 9 06:19:16 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Oct 9 06:15:53 2008 Subject: space in making 6.10.1-candidate Message-ID: <20081009101916.GA5239@scico.botik.ru> Another point in testing ghc-6.10.0.20081007: I make it from source on Debian Linux. On 1 Gb - 2 GHz machine, it builds in 1400 sec. On 512 Mb machine, it seems to overfill RAM, it becomes slow, and this `make' creates difficulties for other processes (like emacs editor): they start to hang, a bit, and the `top' command shows 85% RAM used by this `make', now and then (and probably it takes more, sometimes). This effect is in making ghc-6.10.0.20081007 from source by ghc-6.10.0.20080921 on Debian Linux, on 512 Mb RAM i386-like machine. This was not so in earlier GHC versions. Can this be improved? Because 512 Mb is much enough. The last messages (after which I interruptred it) is ------------------------ make -C compiler doc stage=2 make[2]: Entering directory `/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/compiler' /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/libraries/cabal-bin /home/mechvel/ghc/6.10cand/inst0/bin/ghc /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ libraries/bootstrapping.conf haddock --distpref dist-stage2 --haddock-option=--optghc=-DSTAGE=2 --with-haddock=/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ utils/haddock/install-inplace/bin/haddock Preprocessing library ghc-6.10.0.20081007... Running Haddock for ghc-6.10.0.20081007... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library ghc-6.10.0.20081007... make[2]: *** [doc.stage.2] .. make[1]: *** [stage2] Interruption make: *** [bootstrap2] Interruption ---------------------------------------------- Regards, ----------------- Serge Mechveliani mechvel@botik.ru From nominolo at googlemail.com Thu Oct 9 07:43:36 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Oct 9 07:39:52 2008 Subject: space in making 6.10.1-candidate In-Reply-To: <20081009101916.GA5239@scico.botik.ru> References: <20081009101916.GA5239@scico.botik.ru> Message-ID: <916b84820810090443r32fda3dco83394a1569e0bb46@mail.gmail.com> Yes, the problem is a space leak in Haddock. On a 32 bit system it takes up to 700MB of RAM. You should probably disable haddock for now. David Waern is working on a fix, but I don't know how long it'll take him. 2008/10/9 Serge D. Mechveliani : > Another point in testing ghc-6.10.0.20081007: > > I make it from source on Debian Linux. > On 1 Gb - 2 GHz machine, it builds in 1400 sec. > On 512 Mb machine, it seems to overfill RAM, it becomes slow, and > this `make' creates difficulties for other processes (like emacs editor): > they start to hang, a bit, and the `top' command shows 85% RAM used by > this `make', now and then (and probably it takes more, sometimes). > > This effect is in making ghc-6.10.0.20081007 from source by > ghc-6.10.0.20080921 on Debian Linux, on 512 Mb RAM i386-like machine. > > This was not so in earlier GHC versions. > Can this be improved? > Because 512 Mb is much enough. > > The last messages (after which I interruptred it) is > ------------------------ > make -C compiler doc stage=2 > make[2]: Entering directory > `/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/compiler' > /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/libraries/cabal-bin > /home/mechvel/ghc/6.10cand/inst0/bin/ghc > /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ > libraries/bootstrapping.conf haddock --distpref dist-stage2 > --haddock-option=--optghc=-DSTAGE=2 > --with-haddock=/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ > utils/haddock/install-inplace/bin/haddock > Preprocessing library ghc-6.10.0.20081007... > Running Haddock for ghc-6.10.0.20081007... > Warning: The documentation for the following packages are not installed. > No links will be generated to these packages: rts-1.0 > Preprocessing library ghc-6.10.0.20081007... > make[2]: *** [doc.stage.2] .. > make[1]: *** [stage2] Interruption > make: *** [bootstrap2] Interruption > ---------------------------------------------- > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From Christian.Maeder at dfki.de Thu Oct 9 08:30:57 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 9 08:27:13 2008 Subject: libedit Message-ID: <48EDF981.7000001@dfki.de> Hi Judah, after installing rpm packages libedit0-2.10.snap20070831-5 libedit-devel-2.10.snap20070831-5 I get the error below for "cabal install editline" Cheers Christian checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking for sign of read_history result on error... positive configure: creating ./config.status config.status: creating editline.buildinfo config.status: creating include/HsEditlineConfig.h Preprocessing library editline-0.2... In file included from Editline.hsc:52:0: include/HsEditline.h:11:0: error: conflicting types for 'el_get' /usr/include/histedit.h:112:0: error: previous declaration of 'el_get' was here compiling dist/build/System/Console/Editline_hsc_make.c failed command was: /home/linux-bkb/ghc/ghc-6.8.3/bin/ghc -c -package base-3.0.2.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o cabal: Error: some packages failed to install: editline-0.2 failed during the building phase. The exception was: exit: ExitFailure 1 From Christian.Maeder at dfki.de Thu Oct 9 09:37:32 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 9 09:33:48 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081008200939.GA5675@matrix.chaos.earth.li> References: <20081008200939.GA5675@matrix.chaos.earth.li> Message-ID: <48EE091C.10803@dfki.de> Ian Lynagh wrote: > Please test as much as possible; bugs are much cheaper if we find them > before the release! How about a test-suite? Cheers Christian P.S. "make binary-dist" creates a big unnecessary ".tar" file together with the final ".tar.bz2" file. Also a (disturbing) link "ghc-6.10.0.20081007 -> ." is created. ("make install" no longer reports which path to add) From Christian.Maeder at dfki.de Thu Oct 9 11:01:03 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 9 10:57:20 2008 Subject: libedit In-Reply-To: <48EDF981.7000001@dfki.de> References: <48EDF981.7000001@dfki.de> Message-ID: <48EE1CAF.80603@dfki.de> Christian Maeder wrote: > Hi Judah, > > after installing rpm packages > > libedit0-2.10.snap20070831-5 > libedit-devel-2.10.snap20070831-5 I just noticed that this libedit version works for editline-0.2.0.0 within 6.10.0.20081007 Cheers C. From Christian.Maeder at dfki.de Thu Oct 9 12:03:22 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 9 11:59:37 2008 Subject: libedit-20080712-2.11 under x86 Solaris Message-ID: <48EE2B4A.9070405@dfki.de> Hi, I've installed libedit-20080712-2.11 (from sources) for ghc-6.10.0.20081007 under x86 Solaris. However, ghci comes up with: GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. No entry for terminal type "xterm"; using dumb terminal settings. Prelude> The keys work, but how do I get rid of No entry for terminal type "xterm"; using dumb terminal settings. ? I have a file /usr/local/share/terminfo/x/xterm (but no terminfo under /usr/share/) Any ideas? Thanks Christian From duncan.coutts at worc.ox.ac.uk Thu Oct 9 11:28:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 9 13:21:30 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <953e0d250810090120k3f498d15jd24afc5927fa393a@mail.gmail.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> <953e0d250810090120k3f498d15jd24afc5927fa393a@mail.gmail.com> Message-ID: <1223566105.6878.15.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-09 at 10:20 +0200, Jean-Philippe Bernardy wrote: > On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts > wrote: > > > Done! > > > > Four days and 15 patches later I can construct install plans for 710 > > packages from hackage using the darcs cabal-install and last nights > > ghc-6.10. (It would be more like 730 but I've not got gtk2hs built for > > 6.10, for ghc-6.8 it's 743 packages) > > Is this included in the ghc 6.10 rc1? I tried: The cabal-install program is not included ghc at all. (ghc comes with the Cabal library.) > $ cabal install Diff > Resolving dependencies... > > but it seems to remain stuck there. Right, you need the darcs version of cabal-install. Duncan From duncan.coutts at worc.ox.ac.uk Thu Oct 9 14:35:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 9 14:32:01 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> <953e0d250810090120k3f498d15jd24afc5927fa393a@mail.gmail.com> <1223566105.6878.15.camel@dell.linuxdev.us.dell.com> Message-ID: <1223577343.6878.52.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-09 at 12:47 -0500, Paulo Tanimoto wrote: > Hi Duncan, > > On Thu, Oct 9, 2008 at 10:28 AM, Duncan Coutts > wrote: > > On Thu, 2008-10-09 at 10:20 +0200, Jean-Philippe Bernardy wrote: > >> On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts > >> wrote: > > > Right, you need the darcs version of cabal-install. > > > Just to be clear, what about the other dependencies? > > 1. zlib: the package from hackage seems to work flawlessly. > > 2. http: the one in hackage doesn't build [1], I'm using: > > $ darcs get --partial http://code.haskell.org/http/ > > Is that what I should be doing? I get those warnings about base [2]. This will be fixed by both a new point release of HTTP, but more generally this will be fixed by using the soft preferences which we'll include in the hackage index and which will be used by the upcomming cabal-install release. > 3. Cabal: should I use the one that comes with GHC or upgrade to the > darcs version? They're currently more or less the same. Duncan From dons at galois.com Thu Oct 9 14:41:14 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 9 14:37:29 2008 Subject: planning for ghc-6.10.1 and hackage In-Reply-To: <1223577343.6878.52.camel@dell.linuxdev.us.dell.com> References: <1222904185.14163.289.camel@dell.linuxdev.us.dell.com> <1223277400.14163.521.camel@dell.linuxdev.us.dell.com> <953e0d250810090120k3f498d15jd24afc5927fa393a@mail.gmail.com> <1223566105.6878.15.camel@dell.linuxdev.us.dell.com> <1223577343.6878.52.camel@dell.linuxdev.us.dell.com> Message-ID: <20081009184114.GG27019@scytale.galois.com> duncan.coutts: > On Thu, 2008-10-09 at 12:47 -0500, Paulo Tanimoto wrote: > > Hi Duncan, > > > > On Thu, Oct 9, 2008 at 10:28 AM, Duncan Coutts > > wrote: > > > On Thu, 2008-10-09 at 10:20 +0200, Jean-Philippe Bernardy wrote: > > >> On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts > > >> wrote: > > > > > Right, you need the darcs version of cabal-install. > > > > > > Just to be clear, what about the other dependencies? > > > > 1. zlib: the package from hackage seems to work flawlessly. > > > > 2. http: the one in hackage doesn't build [1], I'm using: > > > > $ darcs get --partial http://code.haskell.org/http/ > > > > Is that what I should be doing? I get those warnings about base [2]. > > This will be fixed by both a new point release of HTTP, but more > generally this will be fixed by using the soft preferences which we'll > include in the hackage index and which will be used by the upcomming > cabal-install release. And indeed, the new HTTP is out, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP-3001.1.3 From jeff.polakow at db.com Thu Oct 9 14:53:18 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Thu Oct 9 14:49:35 2008 Subject: thread/socket behvior Message-ID: We have a server that accepts messages over a socket, spawning threads to process them. Processing these messages may cause other, outgoing connections, to be spawned. Under sufficient load, the main server loop (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. A smaller distilled testcase reveals that when sufficient socket activity is occurring, an incoming connection may not be responded to until other connections have been cleared out of the way, despite the fact that these other connections are being handled by separate threads. One issue that we?ve been trying to figure out is where this behavior arises from-- the GHC rts, the Network library, the underlying C libraries. Have other GHC users doing applications with large amounts of socket usage observed similar behavior and managed to trace back where it originates from? Are there any particular architectural solutions that people have found to work well for these situations? thanks, Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081009/39d204b5/attachment.htm From duncan.coutts at worc.ox.ac.uk Thu Oct 9 14:55:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 9 14:52:03 2008 Subject: breakage with Cabal-1.6 Message-ID: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> All, I'm trying to do a Cabal-1.6 release, in time for ghc-6.10. Here's an interim update. There are 7 packages on hackage where the latest version has a Setup.hs script that works with Cabal-1.4 but does not compile with Cabal-1.6. That's actually not too bad. It's been a lot worse in the past, and we have many more packages now. Here's the list and explanations: * ForSyDe-3.0 Uses the copyDest field from CopyFlags. These record types now use an equivalent of Maybe so they can be empty rather than always containing a default value. It's useful, but also kind of annoying in places. It's an easy fix. * MissingPy-0.10.0 * Takusen-0.8.3 * HDBC-postgresql-1.1.4.0 Imports writeHookedBuildInfo from Distribution.PackageDescription This one is a bit annoying. I tried to split up the Distribution.PackageDescription module a bit, because it was something like 1,700 lines long. I moved the parsing out into Distribution.PackageDescription.Parse. Some packages of course sill expect to get writeHookedBuildInfo from the previous location. I could make it still work by using recursive modules, but I worry what that would do to the process of bootstrapping Cabal (especially with hugs or nhc). Or I could re-merge the modules into one massive module again. Or I could say, it's only three packages broken, it's all ok. While the fix for these three packages' Setup scripts is trivial, there is not fix that will make them compile with old and new versions of the lib. Suggestions welcome. * alex-2.2 * happy-1.17 Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) however the flag has been renamed to buildVerbosity and with a different type. I would export a compat function but it would not help here since the Setup script expects it to be a record selector from BuildFlags. Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm not doing that again. If I added a compat function then we could at least make it work with both ghc/cabal versions with a single implementation. So I might do that and do point releases of these packages, if Simon thinks that's ok. Really of course both packages should stop calling an external perl and other similar madness. * hsql-odbc-1.7 Imports Distribution.Setup which has been deprecated since at least Cabal-1.2. This package is unmaintained so it's not so surprising. Duncan From dons at galois.com Thu Oct 9 14:56:02 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 9 14:52:08 2008 Subject: thread/socket behvior In-Reply-To: References: Message-ID: <20081009185602.GI27019@scytale.galois.com> jeff.polakow: > We have a server that accepts messages over a socket, spawning threads to > process them. Processing these messages may cause other, outgoing > connections, to be spawned. Under sufficient load, the main server loop > (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. > > A smaller distilled testcase reveals that when sufficient socket activity > is occurring, an incoming connection may not be responded to until other > connections have been cleared out of the way, despite the fact that these > other connections are being handled by separate threads. One issue that > we've been trying to figure out is where this behavior arises from-- the > GHC rts, the Network library, the underlying C libraries. > > Have other GHC users doing applications with large amounts of socket usage > observed similar behavior and managed to trace back where it originates > from? Are there any particular architectural solutions that people have > found to work well for these situations? Hey Jeff, Can you say which GHC you used, and whether you used the threaded runtime or non-threaded runtime? -- Don From jeff.polakow at db.com Thu Oct 9 15:04:26 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Thu Oct 9 15:00:42 2008 Subject: thread/socket behvior In-Reply-To: <20081009185602.GI27019@scytale.galois.com> Message-ID: Don Stewart wrote on 10/09/2008 02:56:02 PM: > jeff.polakow: > > We have a server that accepts messages over a socket, spawning threads to > > process them. Processing these messages may cause other, outgoing > > connections, to be spawned. Under sufficient load, the main server loop > > (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. > > > > A smaller distilled testcase reveals that when sufficient socket activity > > is occurring, an incoming connection may not be responded to until other > > connections have been cleared out of the way, despite the fact that these > > other connections are being handled by separate threads. One issue that > > we've been trying to figure out is where this behavior arises from-- the > > GHC rts, the Network library, the underlying C libraries. > > > > Have other GHC users doing applications with large amounts of > socket usage > > observed similar behavior and managed to trace back where it originates > > from? Are there any particular architectural solutions that people have > > found to work well for these situations? > > Hey Jeff, > > Can you say which GHC you used, and whether you used the threaded > runtime or non-threaded runtime? > Oops, forgot about that... We used both ghc-6.8.3 and ghc-6.10.rc1 and we used the threaded runtime. We are running on a 64 bit linux machine using openSUSE 10. thanks, Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081009/c8d8ad8b/attachment.htm From claus.reinke at talk21.com Thu Oct 9 15:33:27 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Oct 9 15:45:03 2008 Subject: breakage with Cabal-1.6 References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> Message-ID: > I could say, it's only three packages broken, it's all ok. While the fix > for these three packages' Setup scripts is trivial, there is no fix > that will make them compile with old and new versions of the lib. > > Suggestions welcome. Cabal-version-dependent Setup.hs?-) http://hackage.haskell.org/trac/hackage/ticket/326 One can hack something up without Cabal support (have a simple Setup.hs that checks the Cabal version and runs one of the actual Cabal-version-specific Setup-.hs that do the work)- see the comments on that ticket. But wouldn't it be nice if Cabal would start supporting that directly, to sort this once and for all?-) Should also help with the other issues, Claus From alfonso.acosta at gmail.com Thu Oct 9 19:26:29 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Oct 9 19:22:43 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> Message-ID: <6a7c66fc0810091626k66a58e38p469f1904cd5e046d@mail.gmail.com> On Thu, Oct 9, 2008 at 8:55 PM, Duncan Coutts wrote: > * ForSyDe-3.0 > > Uses the copyDest field from CopyFlags. These record types now use an > equivalent of Maybe so they can be empty rather than always containing a > default value. It's useful, but also kind of annoying in places. It's an > easy fix. If possible at all, what would be the best way to make it compatible with both versions of CopyFlags? Thanks From duncan.coutts at worc.ox.ac.uk Thu Oct 9 19:38:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 9 19:35:31 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <6a7c66fc0810091626k66a58e38p469f1904cd5e046d@mail.gmail.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> <6a7c66fc0810091626k66a58e38p469f1904cd5e046d@mail.gmail.com> Message-ID: <1223595530.6878.111.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-10 at 01:26 +0200, Alfonso Acosta wrote: > On Thu, Oct 9, 2008 at 8:55 PM, Duncan Coutts > wrote: > > * ForSyDe-3.0 > > > > Uses the copyDest field from CopyFlags. These record types now use an > > equivalent of Maybe so they can be empty rather than always containing a > > default value. It's useful, but also kind of annoying in places. It's an > > easy fix. > > If possible at all, what would be the best way to make it compatible > with both versions of CopyFlags? I don't think there's a way to make it work with Cabal-1.2, 1.4 and 1.6. If you make it work with 1.6 it'll not work with 1.2. But it can work with 1.4 and 1.6 at the same time, or with 1.2 and 1.4 at the same time. Just not all three simultaneously. Duncan From duncan.coutts at worc.ox.ac.uk Thu Oct 9 21:06:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 9 21:02:40 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> Message-ID: <1223600774.6878.144.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-09 at 11:55 -0700, Duncan Coutts wrote: > All, > > I'm trying to do a Cabal-1.6 release, in time for ghc-6.10. > > Here's an interim update. > > There are 7 packages on hackage where the latest version has a Setup.hs > script that works with Cabal-1.4 but does not compile with Cabal-1.6. Actually it's 8. For some reason I missed lhs2tex. Cabal-1.4 had several compat hacks added to enable lhs2tex to be made to work. Those hacks are gone in Cabal-1.6. > That's actually not too bad. It's been a lot worse in the past, and we > have many more packages now. Further details. I tried to build 685 packages from hackage with ghc-6.8 using Cabal-1.4.0.2 and Cabal-1.6.0.0. Here are the numbers: * Cabal-1.4.0.2: 547 built ok * Cabal-1.6.0.0: 541 built ok So there are (at least) 6 packages that worked with Cabal-1.4.0.2 and now fail with Cabal-1.6. I say "at least" because some failed for me with Cabal-1.4 but only because I'm missing C libs. I don't have an accurate count of that subset. But I don't think it's that large. If we assume it's about 12 newly failing packages then that's under 2%. If I remember correctly we had 8-10% breakage due to Cabal from the 1.1.6 to 1.2 transition with ghc-6.6 to 6.8. So it's rather better this time. This set of course overlaps with the 8 for which the Setup.hs fails to compile. The reason it's not simply an addition to the earlier 7 is because some of those failed to configure with Cabal-1.4 even though the Setup.hs compiled. In a couple cases that was due to C libs. So here's a breakdown of the 6 that are new failures and a couple that definitely fail with Cabal-1.6 and probably would have worked with Cabal-1.4 if I'd had the C libs installed. Failed due to Setup.hs not compiling: * ForSyDe-3.0 * MissingPy-0.10.0 * Takusen-0.8.3 * alex-2.2 * happy-1.17 * lhs2tex-1.13 These two also have Setup.hs scripts that no longer compile * hsql-odbc-1.7 * HDBC-postgresql-1.1.4.0 hsql-odbc never built anyway because hsql does not compile with ghc-6.8. HDBC-postgresql probably would have built for me with Cabal-1.4 if I'd had the postegresql C libs installed. So it's part of the "at least" category which failed with 1.4 only because I didn't have the C libs. Other failures: * HsPerl5 HsPerl5 fails with: Reading parameters from ./HsPerl5.buildinfo setup: HsPerl5.buildinfo:4: Parse of field 'ld-options' failed. The problem here is parsing "-Wl,-E". It is a Cabal parsing bug. It worked in old versions of Cabal but only because they incorrectly interpreted "," as a separator. By luck this worked. Apparently passing -Wl -E to gcc rather than -Wl,-E was not enough to cause visible breakage. The current cabal parser for ld-options only looks for spaces as separators but currently does not allow ',' inside tokens. I'll fix this before the release. Duncan From judah.jacobson at gmail.com Fri Oct 10 02:06:43 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Oct 10 02:02:57 2008 Subject: libedit-20080712-2.11 under x86 Solaris In-Reply-To: <48EE2B4A.9070405@dfki.de> References: <48EE2B4A.9070405@dfki.de> Message-ID: <6d74b0d20810092306p5f5cd5cdm26b0a4c5bc1cb200@mail.gmail.com> On Thu, Oct 9, 2008 at 9:03 AM, Christian Maeder wrote: > Hi, > > I've installed libedit-20080712-2.11 (from sources) for > ghc-6.10.0.20081007 under x86 Solaris. > > However, ghci comes up with: > > GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > No entry for terminal type "xterm"; > using dumb terminal settings. > Prelude> > > The keys work, but how do I get rid of > > No entry for terminal type "xterm"; > using dumb terminal settings. > > ? > > I have a file > /usr/local/share/terminfo/x/xterm > (but no terminfo under /usr/share/) > > Any ideas? > Thanks Christian > Strange; it seems like terminfo isn't looking in the right location for the xterm files. Incidentally, the "dumb" terminal settings may be deficient when you type a line longer than the terminal width. What OS is this? Did you download and install (n)curses manually? Can you use some program to monitor the filesystem (for example, fs_usage on OS X) and see where the program is looking for the terminfo databases? -Judah From judah.jacobson at gmail.com Fri Oct 10 02:27:40 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Oct 10 02:23:54 2008 Subject: libedit In-Reply-To: <48EDF981.7000001@dfki.de> References: <48EDF981.7000001@dfki.de> Message-ID: <6d74b0d20810092327j57c9367ey34ca9b6fe2e30e44@mail.gmail.com> On Thu, Oct 9, 2008 at 5:30 AM, Christian Maeder wrote: > Hi Judah, > > after installing rpm packages > > libedit0-2.10.snap20070831-5 > libedit-devel-2.10.snap20070831-5 > > I get the error below for "cabal install editline" > > Cheers Christian > > checking editline/readline.h usability... yes > checking editline/readline.h presence... yes > checking for editline/readline.h... yes > checking for sign of read_history result on error... positive > configure: creating ./config.status > config.status: creating editline.buildinfo > config.status: creating include/HsEditlineConfig.h > Preprocessing library editline-0.2... > > In file included from Editline.hsc:52:0: > > include/HsEditline.h:11:0: error: conflicting types for 'el_get' > > /usr/include/histedit.h:112:0: > error: previous declaration of 'el_get' was here > compiling dist/build/System/Console/Editline_hsc_make.c failed > command was: /home/linux-bkb/ghc/ghc-6.8.3/bin/ghc -c -package > base-3.0.2.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o > dist/build/System/Console/Editline_hsc_make.o > cabal: Error: some packages failed to install: > editline-0.2 failed during the building phase. The exception was: > exit: ExitFailure 1 > Hi Christian, I think this is fixed in darcs (http://code.haskell.org/editline); can you try seeing if that works for you? I'll work on getting the updated editline package onto hackage as well. Thanks, -Judah From duncan.coutts at worc.ox.ac.uk Fri Oct 10 03:10:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 03:11:53 2008 Subject: cabal-1.6.0.0 Message-ID: <1223622616.6878.157.camel@dell.linuxdev.us.dell.com> I've tagged Cabal-1.6.0.0 and the tarball is on the cabal website. http://haskell.org/cabal/download.html Tomorrow I'll update the version of Cabal that hackage is using and upload Cabal-1.6.0.0 to hackage. We're also planning to bump and upload the extralib packages tomorrow. I also hope to release cabal-install-0.6.0 in the next couple days. In the mean time please use the darcs version and report any issues. Duncan From Alistair.Bayley at invesco.com Fri Oct 10 04:17:47 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Fri Oct 10 04:14:02 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9611@GBLONXMB02.corp.amvescap.net> > * Takusen-0.8.3 > > Imports writeHookedBuildInfo from Distribution.PackageDescription > > While the fix > for these three packages' Setup scripts is trivial, there is not fix > that will make them compile with old and new versions of the lib. For Takusen I'd be happy to fix the Setup and require the latest Cabal in order to build. That's what we've done in the past. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From judah.jacobson at gmail.com Fri Oct 10 04:42:12 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Oct 10 04:38:25 2008 Subject: Backspace in ghci-6.10.1-candidate In-Reply-To: <20081009082849.GA5167@scico.botik.ru> References: <20081009082849.GA5167@scico.botik.ru> Message-ID: <6d74b0d20810100142x51beeeabl5115321888a36957@mail.gmail.com> On Thu, Oct 9, 2008 at 1:28 AM, Serge D. Mechveliani wrote: > This is about testing 6.10.0.20081007. > > 1. DoCon works with it. > > 2. The question is how to `install' Backspace and UpArrow in ghci. > > I make it from source by 6.10-candidate and also by itself > -- on Debian Linux. > And ghci does not process Backspace and UpArrow. > ./configure reported > configure:2303: checking whether ghc has editline package > configure:2314: result: no > > And the Debian system area shows the files > /usr/lib/libedit.so.2 > /usr/lib/iceape/components/libeditor.so > /usr/lib/libedit.so.2.9 > The editline package requires the header files, not just the .so libraries. You can get those by installing the editline-dev package. (After which you'll need to rebuild ghc.) Best, -Judah From judah.jacobson at gmail.com Fri Oct 10 04:42:51 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Oct 10 04:39:04 2008 Subject: Backspace in ghci-6.10.1-candidate In-Reply-To: <6d74b0d20810100142x51beeeabl5115321888a36957@mail.gmail.com> References: <20081009082849.GA5167@scico.botik.ru> <6d74b0d20810100142x51beeeabl5115321888a36957@mail.gmail.com> Message-ID: <6d74b0d20810100142h3fc4b2e9u8f5a57d31bfc6bf1@mail.gmail.com> On Fri, Oct 10, 2008 at 1:42 AM, Judah Jacobson wrote: > On Thu, Oct 9, 2008 at 1:28 AM, Serge D. Mechveliani wrote: >> This is about testing 6.10.0.20081007. >> >> 1. DoCon works with it. >> >> 2. The question is how to `install' Backspace and UpArrow in ghci. >> >> I make it from source by 6.10-candidate and also by itself >> -- on Debian Linux. >> And ghci does not process Backspace and UpArrow. >> ./configure reported >> configure:2303: checking whether ghc has editline package >> configure:2314: result: no >> >> And the Debian system area shows the files >> /usr/lib/libedit.so.2 >> /usr/lib/iceape/components/libeditor.so >> /usr/lib/libedit.so.2.9 >> > > The editline package requires the header files, not just the .so > libraries. You can get those by installing the editline-dev package. > (After which you'll need to rebuild ghc.) > Correction: you probably want the Debian libedit-dev package. -Judah From judah.jacobson at gmail.com Fri Oct 10 05:03:19 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Oct 10 04:59:32 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081008200939.GA5675@matrix.chaos.earth.li> References: <20081008200939.GA5675@matrix.chaos.earth.li> Message-ID: <6d74b0d20810100203n38582fffo2227e166514c3a81@mail.gmail.com> On Wed, Oct 8, 2008 at 1:09 PM, Ian Lynagh wrote: > > We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the > first release candidate for GHC 6.10.1. > > You can download the release candidate from here: > http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html > This page includes: > * a Windows installer > * an OS X installer > * bindists for amd64/Linux and ix86/Linux > * the sources > > There is also a status page here: > http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 > where we will keep track of where the RC works, and where it is known to > have problems. This is a wiki page, so please feel free to update it if > you are able to add or update the information on a particular platform. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > We hope that we will be able to make the final release in around one > weeks time, but of course that may slip if problems are uncovered. > > > Thanks > Ian, on behalf of the GHC team > Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers: Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt -> putStrLn "Caught!") (threadDelay 2000000) ^CInterrupted. For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend. Thanks, -Judah From Christian.Maeder at dfki.de Fri Oct 10 06:15:06 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Oct 10 06:11:29 2008 Subject: libedit-20080712-2.11 under x86 Solaris In-Reply-To: <6d74b0d20810092306p5f5cd5cdm26b0a4c5bc1cb200@mail.gmail.com> References: <48EE2B4A.9070405@dfki.de> <6d74b0d20810092306p5f5cd5cdm26b0a4c5bc1cb200@mail.gmail.com> Message-ID: <48EF2B2A.5060009@dfki.de> Judah Jacobson wrote: > Strange; it seems like terminfo isn't looking in the right location > for the xterm files. Incidentally, the "dumb" terminal settings may > be deficient when you type a line longer than the terminal width. > > What OS is this? Did you download and install (n)curses manually? SunOS 5.10 Generic_137112-07 i86pc i386 i86pc In fact ncurses was the problem. My LD_LIBRARY_PATH pointed to a copied version of libncurses.so.5 (pointing to libncurses.so.5.6) that was later replaced by our admins (maybe they've noticed such a problem, too). Now it works. Thanks and sorry for the trouble. > Can you use some program to monitor the filesystem (for example, > fs_usage on OS X) and see where the program is looking for the > terminfo databases? (I didn't find something) Cheers Christian From marlowsd at gmail.com Fri Oct 10 09:23:31 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 10 09:19:49 2008 Subject: thread/socket behvior In-Reply-To: References: Message-ID: <48EF5753.2050707@gmail.com> Jeff Polakow wrote: > Don Stewart wrote on 10/09/2008 02:56:02 PM: > > > jeff.polakow: > > > We have a server that accepts messages over a socket, spawning > threads to > > > process them. Processing these messages may cause other, outgoing > > > connections, to be spawned. Under sufficient load, the main > server loop > > > (i.e. the call to accept, followed by a forkIO), becomes > nonresponsive. > > > > > > A smaller distilled testcase reveals that when sufficient socket > activity > > > is occurring, an incoming connection may not be responded to > until other > > > connections have been cleared out of the way, despite the fact > that these > > > other connections are being handled by separate threads. One > issue that > > > we've been trying to figure out is where this behavior arises > from-- the > > > GHC rts, the Network library, the underlying C libraries. > > > > > > Have other GHC users doing applications with large amounts of > > socket usage > > > observed similar behavior and managed to trace back where it > originates > > > from? Are there any particular architectural solutions that > people have > > > found to work well for these situations? > > > > Hey Jeff, > > > > Can you say which GHC you used, and whether you used the threaded > > runtime or non-threaded runtime? > > > Oops, forgot about that... > > We used both ghc-6.8.3 and ghc-6.10.rc1 and we used the threaded > runtime. We are running on a 64 bit linux machine using openSUSE 10. The scheduler doesn't have a concept of priorities, so the accepting thread will get the same share of the CPU as the other threads. Another issue is that the accepting thread has to be woken up by the IO manager thread when a new connection is available, so we might have to wait for the IO manager thread to run too. But I wouldn't expect to see overly long delays. Maybe you could try network-alt which does its own IO multiplexing. If you have multiple cores, you might want to try fixing the thread affinity - e.g. put all the worker threads on one core, and the accepting thread on the other core. You can do this using GHC.Conc.forkOnIO, with the +RTS -qm -qw options. Other than that, I'm not sure what to try right now. We're hoping to get some better profiling for parallel/concurrent programs in the future, but it's not ready yet. Cheers, Simon From marlowsd at gmail.com Fri Oct 10 09:46:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 10 09:42:49 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <6d74b0d20810100203n38582fffo2227e166514c3a81@mail.gmail.com> References: <20081008200939.GA5675@matrix.chaos.earth.li> <6d74b0d20810100203n38582fffo2227e166514c3a81@mail.gmail.com> Message-ID: <48EF5CB8.902@gmail.com> Judah Jacobson wrote: > Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are > not thrown in ghci, probably because it installs its own signal > handlers: > > Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt > -> putStrLn "Caught!") (threadDelay 2000000) > ^CInterrupted. > > For consistency between the compiled and interpreted environments, it > would be nice if the above could catch the ctrl-c. But maybe there's > a reason not to do this? If this change sounds OK, I can take a look > at this and try to put together a patch over the weekend. Hmm, tricky one. I agree with the argument for consistency, but on the other hand you might also want a way to interrupt a computation regardless, and that almost works - as long as the program isn't discarding exceptions it knows nothing about. Cheers, Simon From Christian.Maeder at dfki.de Fri Oct 10 10:33:25 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Oct 10 10:29:39 2008 Subject: MacPorts will use _only_ a ghc built with "port install ghc", no other In-Reply-To: <48EF6360.40301@t-online.de> References: <48EF6360.40301@t-online.de> Message-ID: <48EF67B5.3080807@dfki.de> Hi, Denis wanted to install pandoc form MacPorts and got problems (below), because he has installed my ghc-6.8.3-powerpc binary. If my binary works you could download http://hackage.haskell.org/packages/archive/pandoc/1.0.0.1/pandoc-1.0.0.1.tar.gz unpack and do the runhaskell Setup configure runhaskell Setup build sudo runhaskell Setup install business (http://www.haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package) also for all missing dependencies, i.e. http://hackage.haskell.org/packages/archive/zip-archive/0.1.1/zip-archive-0.1.1.tar.gz I don't know if or how this interferes with MacPorts. Cheers Christian port deps pandoc => pandoc has build dependencies on: ghc haddock pandoc has library dependencies on: gmp denis wrote: > Thanks Greg, > > fair enough. > Could you or Christian suggest to the owners of > http://haskell.org/ghc/download_ghc_683.html > something along the lines of > > MacPorts users note: > MacPorts will use /only/ a ghc built with "port install ghc", no other. > > so the next guy doesn't run into the same wall ? > > Hi, > > MacPorts uses a known good binary ghc bootstrap compiler to > build ghc from source. We won't support building using another > bootstrap compiler, which seems to be what you want to do. (ghc > is hard enough to build with a known good compiler, and we don't > have the resources to debug unsupported configurations.) > > Best Wishes, > Greg > > > From marlowsd at gmail.com Fri Oct 10 11:13:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 10 11:10:18 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> Message-ID: <48EF7137.9000903@gmail.com> Duncan Coutts wrote: > * alex-2.2 > * happy-1.17 > > Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) > however the flag has been renamed to buildVerbosity and with a different > type. I would export a compat function but it would not help here since > the Setup script expects it to be a record selector from BuildFlags. > Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm > not doing that again. > > If I added a compat function then we could at least make it work with > both ghc/cabal versions with a single implementation. So I might do that > and do point releases of these packages, if Simon thinks that's ok. > > Really of course both packages should stop calling an external perl and > other similar madness. I can stop calling Perl, but I still need to run CPP, so I still need the runProgram stuff, which means I still need buildVerbose/buildVerbosity. As far as I can see, you could export a compatibility shim called buildVerbose without any difficulty, all I have to do is remove the explicit import list. Or is there a better fix you had in mind? Cheers, Simon From Christian.Maeder at dfki.de Fri Oct 10 11:40:24 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Oct 10 11:36:38 2008 Subject: readEither in ghc-6.10. ? Message-ID: <48EF7768.7070101@dfki.de> Hi, I've got errors when compiling with ghc-6.10.0.20081007 Not in scope: `readEither' It is imported via: import GHC.Read (readEither) and used to work with ghc-6.8. What should I use as replacement? Cheers Christian P.S. It is also not mentioned in the changes: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-1.html From duncan.coutts at worc.ox.ac.uk Fri Oct 10 12:08:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 12:04:59 2008 Subject: Breakage with ghc-6.10 Message-ID: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> This is a quick summary of the results of building most of hackage using three combinations of ghc and Cabal. I reported the breakage due to Cabal-1.6 previously. This is a brief look at breakage introduced with ghc-6.10 and the associated library changes. I have build summary logs and individual package build logs. I will post those later. Anyway, here's the summary of the summary: ghc-6.8.2 & Cabal-1.4.0.2 1 UnpackFailed 3 InstallFailed 20 ConfigureFailed 27 DependencyFailed 87 BuildFailed 547 InstallOk ghc-6.8.2 & Cabal-1.5.6 1 UnpackFailed 3 InstallFailed 26 ConfigureFailed 27 DependencyFailed 87 BuildFailed 541 InstallOk ghc-6.10.0 (5th Oct version) & Cabal-1.6.0.0 1 InstallFailed 21 ConfigureFailed 121 DependencyFailed 126 BuildFailed 422 InstallOk If we look at a breakdown of the builds that caused three or more knock-on failures (ie the causes of the 121 DependencyFailed above): 3 hxt-8.1.0 4 hsql-1.7 4 hsx-0.4.4 4 plugins-1.3 4 TypeCompose-0.5 6 arrows-0.4 24 hslogger-1.0.5 46 time-1.1.2.1 Hmm, time and hslogger are big ones there. Let's look at the individual package build logs. First time: Data/Time/Clock/CTimeval.hs:1:11: Warning: -ffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface#-} instead : Failing due to -Werror. NOOOOooooooooooooooooooo!!!!!! This is the reason that hackage now rejects the use of -Werror in released packages. It causes unnecessary breakage when new compilers add new warnings. Ok, lets look at hslogger: src/System/Log/Logger.hs:333:20: Couldn't match expected type `Maybe Logger' against inferred type `IO Logger' In a stmt of a 'do' expression: result <- Map.lookup lname newlt Ah ok, so that's the change in Map.lookup to return Maybe rather than in any monad. So that's an easy source code fix: result <- maybe (fail "Arrgh!") return (Map.lookup lname newlt) Note of course this will also work with the previous implementation of lookup. Duncan From ashley at semantic.org Fri Oct 10 14:08:34 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Oct 10 14:04:53 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> Message-ID: <1223662114.19606.6.camel@glastonbury> On Fri, 2008-10-10 at 09:08 -0700, Duncan Coutts wrote: > Data/Time/Clock/CTimeval.hs:1:11: > Warning: -ffi is deprecated: use -XForeignFunctionInterface or > pragma {-# LANGUAGE ForeignFunctionInterface#-} instead > > : > Failing due to -Werror. > > NOOOOooooooooooooooooooo!!!!!! > > This is the reason that hackage now rejects the use of -Werror in > released packages. It causes unnecessary breakage when new compilers > add new warnings. Warnings in a build process should be fixed, not ignored (and, I would say, fixed by whoever introduced the warning or otherwise broke the build). Hackage, on the other hand, is right to reject -Werror in .cabal files, as there the build is really part of the install process and should be as lenient as possible. I pass --ghc-options="-Wall -Werror" to cabal in a Makefile in most of my projects, so that my development build process is strict. -- Ashley Yakeley From jgoerzen at complete.org Fri Oct 10 14:29:08 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Oct 10 14:25:30 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> Message-ID: <48EF9EF4.3090700@complete.org> Duncan Coutts wrote: > Ok, lets look at hslogger: > > src/System/Log/Logger.hs:333:20: > Couldn't match expected type `Maybe Logger' > against inferred type `IO Logger' > In a stmt of a 'do' expression: result <- Map.lookup lname newlt > > Ah ok, so that's the change in Map.lookup to return Maybe rather than in > any monad. So that's an easy source code fix: > > result <- maybe (fail "Arrgh!") return (Map.lookup lname newlt) There are actually more instances than this in the code, but I already have fixed it in my git tree. I guess it's time to make a release. -- John > > Note of course this will also work with the previous implementation of > lookup. > > > Duncan > > From duncan.coutts at worc.ox.ac.uk Fri Oct 10 14:41:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 15:00:23 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <1223662114.19606.6.camel@glastonbury> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> <1223662114.19606.6.camel@glastonbury> Message-ID: <1223664066.6878.203.camel@dell.linuxdev.us.dell.com> Sorry Ashley, I hope you didn't feel I was picking on you in particular. I realise it might have looked that way. On Fri, 2008-10-10 at 11:08 -0700, Ashley Yakeley wrote: > On Fri, 2008-10-10 at 09:08 -0700, Duncan Coutts wrote: > > Failing due to -Werror. > > > > NOOOOooooooooooooooooooo!!!!!! > > > > This is the reason that hackage now rejects the use of -Werror in > > released packages. It causes unnecessary breakage when new compilers > > add new warnings. > > Warnings in a build process should be fixed, not ignored (and, I would > say, fixed by whoever introduced the warning or otherwise broke the > build). Yes indeed. So it's appropriate for development builds. > Hackage, on the other hand, is right to reject -Werror in .cabal files, > as there the build is really part of the install process and should be > as lenient as possible. I pass --ghc-options="-Wall -Werror" to cabal in > a Makefile in most of my projects, so that my development build process > is strict. Right. Putting -Wall in the ghc-options in the .cabal file is fine too of course. Lots of packages do that. Duncan From duncan.coutts at worc.ox.ac.uk Fri Oct 10 14:42:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 15:00:24 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <48EF9EF4.3090700@complete.org> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> <48EF9EF4.3090700@complete.org> Message-ID: <1223664139.6878.206.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-10 at 13:29 -0500, John Goerzen wrote: > Duncan Coutts wrote: > > Ok, lets look at hslogger: > > > > src/System/Log/Logger.hs:333:20: > > Couldn't match expected type `Maybe Logger' > > against inferred type `IO Logger' > > In a stmt of a 'do' expression: result <- Map.lookup lname newlt > > > > Ah ok, so that's the change in Map.lookup to return Maybe rather than in > > any monad. So that's an easy source code fix: > > > > result <- maybe (fail "Arrgh!") return (Map.lookup lname newlt) > > There are actually more instances than this in the code, but I already > have fixed it in my git tree. I guess it's time to make a release. Yay! Between that and a bump for the time lib we'll probably have another ~50 packages building with 6.10. Duncan From jgoerzen at complete.org Fri Oct 10 15:35:24 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Oct 10 15:31:37 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <1223664139.6878.206.camel@dell.linuxdev.us.dell.com> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> <48EF9EF4.3090700@complete.org> <1223664139.6878.206.camel@dell.linuxdev.us.dell.com> Message-ID: <48EFAE7C.3050703@complete.org> Duncan Coutts wrote: >> There are actually more instances than this in the code, but I already >> have fixed it in my git tree. I guess it's time to make a release. > > Yay! > > Between that and a bump for the time lib we'll probably have another ~50 > packages building with 6.10. And on that note, hslogger 1.0.6 is now in Hackage. -- John From dons at galois.com Fri Oct 10 15:39:46 2008 From: dons at galois.com (Don Stewart) Date: Fri Oct 10 15:35:57 2008 Subject: Breakage with ghc-6.10 In-Reply-To: <48EFAE7C.3050703@complete.org> References: <1223654895.6878.182.camel@dell.linuxdev.us.dell.com> <48EF9EF4.3090700@complete.org> <1223664139.6878.206.camel@dell.linuxdev.us.dell.com> <48EFAE7C.3050703@complete.org> Message-ID: <20081010193946.GG6102@scytale.galois.com> jgoerzen: > Duncan Coutts wrote: > >> There are actually more instances than this in the code, but I already > >> have fixed it in my git tree. I guess it's time to make a release. > > > > Yay! > > > > Between that and a bump for the time lib we'll probably have another ~50 > > packages building with 6.10. > > And on that note, hslogger 1.0.6 is now in Hackage. Great! I'll do a new hackage build test. -- Don From dons at galois.com Fri Oct 10 18:34:21 2008 From: dons at galois.com (Don Stewart) Date: Fri Oct 10 18:30:20 2008 Subject: Breakage with 6.10 Message-ID: <20081010223421.GP6102@scytale.galois.com> Quick summary of the latest hackage state, now hslogger has been amended. x86_64/linux/ghc-6.10/cabal-install 0.6/Cabal 1.6 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 71 DependencyFailed 138 BuildFailed 447 InstallOk So you can see that DependencyFailed is down 30, thanks to hslogger now working. InstallOk is up about 23. A breakdown of the remaing causes for DependencyFailed, 2 Win32-2.1.0.0 2 Yampa-0.9.2.2 2 hint-0.2.4.1 2 hsdns-1.3 2 plugins-1.3 3 pandoc-1.0.0.1 3 stringtable-atom-0.0.4 4 TypeCompose-0.5 4 hsql-1.7 4 hsx-0.4.4 5 hxt-8.1.0 6 HAppS-Data-0.9.2.1 6 arrows-0.4 6 wxcore-0.10.3 The main thing to fix there is 'arrows', an extra lib, we'll bump that. arrows fails due to: [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' Even though cabal-install decided to use base-3.0.3.0 So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? -- Don From duncan.coutts at worc.ox.ac.uk Fri Oct 10 18:54:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 18:50:44 2008 Subject: Breakage with 6.10 In-Reply-To: <20081010223421.GP6102@scytale.galois.com> References: <20081010223421.GP6102@scytale.galois.com> Message-ID: <1223679247.6878.241.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: > arrows fails due to: > > [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) > > Control/Arrow/Transformer/CoState.hs:24:29: > Module `Control.Arrow' does not export `pure' > > Even though cabal-install decided to use base-3.0.3.0 > > So that means base-3 is *not* exporting quite the same interface as last time. > Were we aware of this? Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting the versioning policy so we need to follow it ourselves in our base libs. On this issue, we've discussed before that packages should be able to opt-into the versioning policy and that if they do we can have our tools suggest that dependencies on such packages should take a particular form. For example depending on and api version ==1.1.* and not upward open ranges, or mistakes like parsec <= 2.1.0.0. There's not time to implement these suggestions in the tools for 6.10 however we do have the opportunity to annotate the packages that we believe do follow the versioning policy. We can then get our tools make use of this information in the coming months. So my suggestion is that in time for 6.10.1 we add something like the following to the .cabal files for all the core and extra packages: x-follows-version-policy: This is free. It doesn't involve any api changes in Cabal or anything else. All such "x-" extension fields are allowed by cabal and collected into a name/value pair list. If it seems to work out then we can make it a proper field (and at that time we can argue what colour we should paint it). Sound sensible? We can send patches to add this to the core + extra packages. I think it'd be good to do this now because while the base 3 - 4 thing has gone fairly well this time, future changes would be much easier if we were using more sensible dependency constraints. I think the best way to communicate that to developers is through warnings generated by their tools. Yes that's right, cabal-install is a channel for package QA propaganda. Duncan From niklas.broberg at gmail.com Fri Oct 10 20:40:40 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Oct 10 20:36:51 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) Message-ID: dons: > A breakdown of the remaing causes for DependencyFailed, > [...] > 4 hsx-0.4.4 --------------- src/hsx$ runhaskell Setup build [snip warnings] src\HSX\XMLGenerator.hs:71:0 Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)? --------------- Could someone help me point out the problem here? The relevant code is: instance XMLGen m => EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m => EmbedAsChild m c where asChild :: c -> GenChildList m class Monad m => XMLGen m where type XML m .... This works fine with 6.8.3, so what's new in 6.10, and what would I do to solve it? Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10? Thanks, /Niklas From niklas.broberg at gmail.com Fri Oct 10 20:45:08 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Oct 10 20:41:19 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: References: Message-ID: > Could someone help me point out the problem here? The relevant code is: > > instance XMLGen m => EmbedAsChild m (XML m) where > asChild = return . return . xmlToChild > > class XMLGen m => EmbedAsChild m c where > asChild :: c -> GenChildList m > > class Monad m => XMLGen m where > type XML m > .... Eh, reading that again I realize there's a bit code needed to understand the above. So here's *really* the relevant code: ---------------- class Monad m => XMLGen m where type XML m data Child m xmlToChild :: XML m -> Child m [....] class XMLGen m => EmbedAsChild m c where asChild :: c -> GenChildList m instance XMLGen m => EmbedAsChild m (XML m) where asChild = return . return . xmlToChild ---------------- ... and just a note that GenChildList is a type synonym for a certain monad returning a list, hence the double returns. :-) Cheers, /Niklas From duncan.coutts at worc.ox.ac.uk Fri Oct 10 21:30:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 21:28:00 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: References: Message-ID: <1223688659.6878.266.camel@dell.linuxdev.us.dell.com> On Sat, 2008-10-11 at 02:40 +0200, Niklas Broberg wrote: > Btw, I also have problems with the haskell-src-exts that imports > Data.Generics.Instances (to generate Data and Typeable instances). > Where would these have moved to in the new base? And how would I make > the code work with both 6.8.3 and 6.10? By having it use base-3 rather than 4. Duncan From niklas.broberg at gmail.com Fri Oct 10 21:52:34 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Oct 10 21:48:47 2008 Subject: base-3 vs base-4 (Was: Breakage with 6.10) Message-ID: > > Btw, I also have problems with the haskell-src-exts that imports > > Data.Generics.Instances (to generate Data and Typeable instances). > > Where would these have moved to in the new base? And how would I make > > the code work with both 6.8.3 and 6.10? > > By having it use base-3 rather than 4. Right, and that's how I quickly fixed it up for now. But this doesn't sound like a long-term solution to me, I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such? Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?) Cheers, /Niklas From dave at zednenem.com Fri Oct 10 21:53:03 2008 From: dave at zednenem.com (David Menendez) Date: Fri Oct 10 21:49:15 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: References: Message-ID: <49a77b7a0810101853j79b1ac3dh5c4e4b316b9dbcbb@mail.gmail.com> On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg wrote: > src\HSX\XMLGenerator.hs:71:0 > Illegal type synonym family application in instance: XML m > In the instance declaration for `EmbedAsChild m (XML m)? > --------------- > > Could someone help me point out the problem here? The relevant code is: > > instance XMLGen m => EmbedAsChild m (XML m) where > asChild = return . return . xmlToChild > > class XMLGen m => EmbedAsChild m c where > asChild :: c -> GenChildList m > > class Monad m => XMLGen m where > type XML m > .... > > This works fine with 6.8.3, so what's new in 6.10, and what would I do > to solve it? I'm guessing there was a bug in 6.8.3 that allowed this. (The implementation of type families is present but not supported in 6.8, presumably because of problems like this.) I don't have 6.10, so I can't test anything, but you might try rewriting the EmbedAsChild instances like so: instance (XMLGen m, XML m ~ x) => EmbedAsChild m x where ... Alternatively, you can make separate instances for every type in the range of XML. -- Dave Menendez From niklas.broberg at gmail.com Fri Oct 10 22:03:36 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Oct 10 21:59:49 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: <49a77b7a0810101853j79b1ac3dh5c4e4b316b9dbcbb@mail.gmail.com> References: <49a77b7a0810101853j79b1ac3dh5c4e4b316b9dbcbb@mail.gmail.com> Message-ID: On 10/11/08, David Menendez wrote: > On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg > wrote: > > src\HSX\XMLGenerator.hs:71:0 > > Illegal type synonym family application in instance: XML m > > In the instance declaration for `EmbedAsChild m (XML m)? > > --------------- > > > > Could someone help me point out the problem here? The relevant code is: > > > > instance XMLGen m => EmbedAsChild m (XML m) where > > asChild = return . return . xmlToChild > > > > class XMLGen m => EmbedAsChild m c where > > asChild :: c -> GenChildList m > > > > class Monad m => XMLGen m where > > type XML m > > .... > > > > This works fine with 6.8.3, so what's new in 6.10, and what would I do > > to solve it? > > > I'm guessing there was a bug in 6.8.3 that allowed this. (The > implementation of type families is present but not supported in 6.8, > presumably because of problems like this.) > > I don't have 6.10, so I can't test anything, but you might try > rewriting the EmbedAsChild instances like so: > > instance (XMLGen m, XML m ~ x) => EmbedAsChild m x where ... Thanks a lot David, that's indeed what I needed. I'm not sure I see why the style I used previously was illegal though, it seemed perfectly natural to me. And it works that way for `EmbedAsChild m (Child m)?, where `Child m? is a data type family and not a synonym, so why not for a synonym too? But hey, as long as there's a way to do what I want. :-) Cheers, /Niklas From duncan.coutts at worc.ox.ac.uk Fri Oct 10 22:42:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 22:39:01 2008 Subject: Releasing extralibs Message-ID: <1223692940.6878.286.camel@dell.linuxdev.us.dell.com> All, Don and I have looked through the "extralibs" set that came with ghc-6.8.3 and the set that will be associated with 6.10.1. I've attached a csv spreadsheet with the summary. For each package we looked at the difference between the last released version (whether that was in the 6.8.3 extralibs tarball or on hackage) and determined the extent of the changes. We assessed the changes against the package version policy to work out the new version (if necessary). These are the actions we need to take: * HUnit: bump version from 1.2.0.0 to 1.2.0.1 and release * QuickCheck: release 1.2.0.0 * haskell-src: bump version from 1.0.1.2 to 1.0.1.3 and release * html: bump version from 1.0.1.1 to 1.0.1.2 and release * mtl: bump version from 1.1.0.1 to 1.1.0.2 and release * network: bump version from 2.2.0.0 to 2.2.0.1 and release * parsec: nothing to do - no changes * parallel: nothing to do - no changes * regex-base: bump version from 0.72.0.1 to 0.72.0.2 and release * regex-compat: nothing to do - no changes * regex-posix: bump version from 0.72.0.2 to 0.72.0.3 and release * stm: bump version from 2.1.1.1 to 2.1.2.0 and release * time: bump version from 1.1.2.1 to 1.1.2.2 and release * xhtml: nothing to do - no changes By release we mean release on hackage. There's no need to wait until 6.10.1 is released to do this. Indeed we can get better testing done if we release now. Duncan -------------- next part -------------- A non-text attachment was scrubbed... Name: extralibs.csv Type: text/csv Size: 1120 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081010/0f4f0fb0/extralibs.bin From duncan.coutts at worc.ox.ac.uk Fri Oct 10 23:50:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 10 23:47:18 2008 Subject: Releasing extralibs In-Reply-To: <1223692940.6878.286.camel@dell.linuxdev.us.dell.com> References: <1223692940.6878.286.camel@dell.linuxdev.us.dell.com> Message-ID: <1223697048.6878.293.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-10 at 19:42 -0700, Duncan Coutts wrote: > These are the actions we need to take: Note that the changes to the exception handling in this package means the following packages no longer build with ghc-6.8.x: * HUnit * network * stm (also imports a new function from GHC.*) All the others still work with 6.8.2. >From the network.cabal file it looks like someone intended it to work with both. STM is not fixable due to the new function it needs from the GHC.* modules. We should decide if we want to fix HUnit and network or just adjust the dependencies to specify base 4. Duncan From duncan.coutts at worc.ox.ac.uk Sat Oct 11 03:36:22 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Oct 11 03:32:55 2008 Subject: More detail on breakage with ghc-6.10 Message-ID: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> All, We've been using the cabal-install build reporting stuff to get more detailed info on build failures with ghc-6.10 vs 6.8. cabal-install generates these build-reports.log files and individual log files for each build. Below is a list of packages that worked with 6.8 and fail with 6.10. If your package is on this list then you might like to take a look at the actual failure. I've posted the logs here: http://haskell.org/~duncan/ghc/hackage-failures-ghc-6.10/ There's one set for ghc-6.8 and one for 6.10. We can get quite a bit of info from these build-reports.log files just using grep, sort, uniq etc. However we also have a parser for it so we can write more interesting queries. For example, we're interested in regressions: reports68 <- fmap parseList (readFile "ghc-6.8/build-reports.log") reports610 <- fmap parseList (readFile "ghc-6.10/build-reports.log") let merged = mergeBy (comparing package) (sortBy (comparing package) reports68) (sortBy (comparing package) reports610) worked InstallOk = True worked _ = False failed InstallOk = False failed (DependencyFailed _) = False failed _ = True regressions = [ new | InBoth old new <- merged , worked (installOutcome old) && failed (installOutcome new) ] print (length regressions) mapM_ (putStrLn . display . package) regressions There are 58 in this list. Though some have been since fixed and it doesn't count packages that fail due to dependencies failing. Here's our current list. I've pruned a couple that I know have been fixed. ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HTF-0.1 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 OpenAFP-1.1 PArrows-0.1 TypeCompose-0.5 Vec-0.9.2 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 frag-1.1.1 harpy-0.4 hasim-0.1 hask-home-2007.12.6 heap-0.4.0 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hsx-0.4.4 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 parameterized-data-0.1.3 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 stream-fusion-0.1.1 streamproc-1.1 stringtable-atom-0.0.4 time-1.1.2.1 typalyze-0.1.1 unicode-prelude-0.1 utf8-light-0.3 xmonad-contrib-0.8 xmonad-utils-0.1 yhccore-0.9 Duncan From dons at galois.com Sat Oct 11 04:03:14 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 03:59:13 2008 Subject: Analysis of new packages breakages with ghc-6.10 Message-ID: <20081011080314.GB10239@scytale.galois.com> OK, so we have *56* packages total that no longer compile with GHC 6.10, but did with 6.8.3. We can now see exactly what broke and why. I think these potential breakage issues, and how to solve them canonically , should be documented on the wiki. Most should have standard solutions, some might be GHC bugs (which I've reported for the obvious ones, but Ian, better have a look at the 'unknown' ones). The following events broke the following packages, * 7 Changes to Arrow class definition TypeCompose, Yampa, arrows, chp, hxt, quantum-arrow, streamproc * 6 Changes to Map monadic types EdisonCore, HPDF, WebBits, libgeni, regex-tdfa, stringtable-atom * 5 Cabal changes cabal-setup, hask-home, hinstaller, hslackbuilder, plugins * 5 Changes to ghc-api HTF, Hashell, hint, typalyze, xmonad-utils * 5 GHC panics/bugs, reported xmonad-contrib, stream-fusion, harpy, OpenAFP, Vec * 4 Unknown error, needs investigation. ArrayRef, YamlReference, parameterized-data, unicode-prelude * 3 Changes to when 'forall' is parsed MemoTrie, heap, hexpat * 3 GHC.Prim was moved, PArrow, logfloat, utf8-light * 3 Changes to -fvia-C and headers? cmath, hetris, mage * 2 GADT changes, CLASE, hasim * 2 pragma warnings tightened numeric-prelude, yhccore * 2 Integer constructors have moved NewBinary, bytestring-show * 2 New warnings and used -Werror fixpoint, list-extras * 1 Addition of permutations to List library HaLeX * 1 Illegal type synonym family application hsx * 1 Exception's moved around? iException ------------------------------------------------------------------------ Below are the precise warnings: ** ArrayRef, ?? Data/ArrayBZ/Internals/Unboxed.hs:60:0: Duplicate type signature: Data/ArrayBZ/Internals/Unboxed.hs:60:0-18: stUArrayTc :: TyCon Data/ArrayBZ/Internals/Unboxed.hs:59:0-18: stUArrayTc :: TyCon CLASE, Data/Cursor/CLASE/Persistence.hs:124:11: GADT pattern match with non-rigid result type `GenParser Char st a' Solution: add a type signature EdisonCore, src/Data/Edison/Assoc/StandardMap.hs:204:21: Couldn't match expected type `m' against inferred type `Maybe' `m' is a rigid type variable bound by HPDF, Graphics/PDF/Data/Trie.hs:39:34: Couldn't match expected type `[a]' against inferred type `Maybe (MapString v)' HTF, Test/Framework.hs:40:21: Not in scope: `currentModule' HaLeX, HaLeX_lib/Language/HaLex/Util.hs:48:13: Ambiguous occurrence `permutations' It could refer to either `Language.HaLex.Util.permutations', defined at HaLeX_lib/Language/HaLex/Util.hs:46:0 or `Data.List.permutations', imported from Data.List at HaLeX_lib/Language/HaLex/Util.hs:24:0-15 Hashell, Hashell/Eval.hs:45:19: Not in scope: `GHC.newSession' Hipmunk, Physics/Hipmunk/Space.hsc:531:2: Couldn't match expected type `Maybe (Either (ForeignPtr ()) Shape)' against inferred type `IO (Either (ForeignPtr ()) Shape)' MemoTrie, src/Data/MemoTrie.hs:36:16: Not in scope: `forall' NewBinary, NewBinary/Binary.hs:693:13: Not in scope: data constructor `S#' PArrow, src/Text/ParserCombinators/PArrow/MD.hs:7:0: Failed to load interface for `GHC.Prim': it is a member of package ghc-prim, which is hidden TypeCompose, src/Data/Bijection.hs:52:11: `>>>' is not a (visible) method of class `Arrow' Vec, timeout WebBits, src/WebBits/JavaScript/Environment.hs:216:2: Couldn't match expected type `Maybe Int' against inferred type `StateT (Z.Location Env) (State Int) Int' YamlReference, Text/Yaml/Reference.hs:1482:19: No instance for (Match a14 ()) arising from a use of `pat' at Text/Yaml/Reference.hs:1482:19-59 yampa, src/FRP/Yampa.hs:650:4: `>>>' is not a (visible) method of class `Arrow' arrows, Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' bytestring-show Text/Show/ByteString/Integer.hs:31:14: Not in scope: data constructor `S#' cabal-setup, CabalSetup.hs:14:7: Could not find module `Distribution.Simple.SetupWrapper': Use -v to see a list of the files searched for. chp, Control/Concurrent/CHP/Arrow.hs:107:22: `>>>' is not a (visible) method of class `Arrow' fixpoint, Data/Fixpoint/Instances.hs:24:9: Warning: orphan instance: instance Foldable (Pre [a]) : Failing due to -Werror. hasim, src/Control/Hasim/SimRun.hs:291:13: GADT pattern match with non-rigid result type `t' Solution: add a type signature hask-home, hask-home.hs:101:15: Not in scope: `showPackageId' heap, Data/Heap.hs:297:18: Not in scope: `forall' hetris, /home/dons/.cabal/lib/hscurses-1.3/ghc-6.10.0.20081007/libHShscurses-1.3.a(Curses.o): In function `s93V_info': ghc26356_0.hc:(.text+0x20282): undefined reference to `hs_curses_color_pair' collect2: ld returned 1 exit status hexpat, C2HS.hs:198:30: Not in scope: `forall' hinstaller src/System/Installer/Foreign.hs:131:18: Not in scope: `buildVerbose' hint src/Hint/Parsers.hs:7:21: Module `GHC' does not export `Session' hslackbuilder Distribution/Slackware/SlackBuild.hs:215:24: Not in scope: `showVersionRange' hsx: src/HSX/XMLGenerator.hs:71:0: Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)' hxt: src/Text/XML/HXT/RelaxNG/DataTypeLibUtils.hs:67:7: `>>>' is not a (visible) method of class `Arrow' iException: Control/Monad/Trans/InterleavableIO/Control/Exception.hs:131:26: Ambiguous occurrence `Exception' It could refer to either `Control.Exception.Exception', imported from Control.Exception at Control/Monad/Trans/InterleavableIO/Control/Exception.hs:(31,0)-(52,2) or `GHC.IOBase.Exception', imported from GHC.IOBase at Control/Monad/Trans/InterleavableIO/Control/Exception.hs:(58,0)-(62,2) libgeni: libgeni/NLP/GenI/CkyEarley/CkyBuilder.lhs:559:4: Couldn't match expected type `Maybe ([String], [String], GNode)' against inferred type `[([String], [String], GNode)]' list-extras: Data.List.Extras.LazyLength:1:0: Orphan rule: "lengthCompare/compare" ALWAYS forall @ a @ a1 $dOrd :: Ord Int xs :: [a] ys :: [a1] compare @ Int $dOrd (length @ a xs) (length @ a1 ys) = lengthCompare @ a @ a1 xs ys (Uses -Werror !) logfloat: Data/Number/Transfinite.hs:58:0: Failed to load interface for `GHC.Prim': it is a member of package ghc-prim, which is hidden mage Linking dist/build/mage/mage ... dist/build/mage/mage-tmp/Curses.o: In function `r8zq_info': numeric-prelude src/Number/Complex.hs:3:12: cannot parse LANGUAGE pragma: comma-separated list expected parameterized-data src/Data/Param/FSVec.hs:103:22: Couldn't match expected type `t -> ExpQ' against inferred type `FSVec s a1' plugins: cabal changes quantum-arrow: Control/Arrow/Quantum.hs:64:11: `>>>' is not a (visible) method of class `Arrow' regex-tdfa: Data/IntMap/CharMap.hs:49:23: Couldn't match expected type `m' against inferred type `Maybe' `m' is a rigid type variable bound by the type signature for `Data.IntMap.CharMap.lookup' streamproc Control/Arrow/SP.hs:40:12: `>>>' is not a (visible) method of class `Arrow' stringtable-atom src/StringTable/AtomSet.hs:122:65: Couldn't match expected type `m' against inferred type `Maybe' `m' is a rigid type variable bound by the type signature for `maxView' at src/StringTable/AtomSet.hs:121:18 typalyze src/Main.hs:82:15: Not in scope: `checkModule' src/Main.hs:145:13: Not in scope: `newSession' unicode-prelude Prelude/Unicode.hs:68:7: lexical error at character '\183' utf8-light src/Codec/Binary/UTF8/Light.hs:69:0: Failed to load interface for `GHC.Prim': it is a member of package ghc-prim, which is hidden * xmonad-utils-0.1 src/Heval.hs:64:18: Not in scope: type constructor or class `Session' * yhccore-0.9 unknown flag in {-# OPTIONS #-} pragma: _DERIVE ------------------------------------------------------------------------ Panics, bug reports already made: Looks like a GHC bug: ** OpenAFP http://hackage.haskell.org/trac/ghc/ticket/2686 [219 of 230] Compiling OpenAFP.Prelude.InstanceAFP.C ( src/OpenAFP/Prelude/InstanceAFP/C.hs, dist/build/OpenAFP/Prelude/InstanceAFP/C.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for x86_64-unknown-linux): applyTypeToArgs OpenAFP-1.1:OpenAFP.Types.Chunk.:DRecData{v rm2C} [gid] @ OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH} @ OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv} $dRec{v a2fWO} [lid] $dRec{v a2fWP} [lid] @ (ghc-prim:GHC.Prim.trans{(w) tc 34y} (ghc-prim:GHC.Prim.trans{(w) tc 34y} (OpenAFP-1.1:OpenAFP.Types.Chunk.DataOf{tc rlUo} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH}) (ghc-prim:GHC.Prim.trans{(w) tc 34y} OpenAFP-1.1:OpenAFP.Prelude.InstanceAFP.C.:CoF:R10DataOf{tc r2fJV} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv})) OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}) @ (ghc-prim:GHC.Prim.trans{(w) tc 34y} (ghc-prim:GHC.Prim.trans{(w) tc 34y} (OpenAFP-1.1:OpenAFP.Types.Chunk.RecOf{tc rlUq} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}) (ghc-prim:GHC.Prim.trans{(w) tc 34y} OpenAFP-1.1:OpenAFP.Prelude.InstanceAFP.C.:CoF:R9RecOf{tc r2fJU} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH})) OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH}) (OpenAFP-1.1:OpenAFP.Types.Chunk.DataOf{tc rlUo} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH} ~ OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}, OpenAFP-1.1:OpenAFP.Types.Chunk.RecOf{tc rlUq} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv} ~ OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH}, OpenAFP-1.1:OpenAFP.Types.Record.Rec{tc rl5e} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH}, OpenAFP-1.1:OpenAFP.Types.Record.Rec{tc rl5e} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}) => (OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH} -> [OpenAFP-1.1:OpenAFP.Types.Record.Record{tc rl5q} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}]) -> (OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH} -> [OpenAFP-1.1:OpenAFP.Types.Record.Record{tc rl5q} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv}] -> OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH}) -> OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI{tc rPQH} OpenAFP-1.1:OpenAFP.Types.Chunk.:TRecData{tc rm2B} OpenAFP-1.1:OpenAFP.Records.AFP.CFI.CFI_Data{tc rPQv} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ** harpy http://hackage.haskell.org/trac/ghc/ticket/2685 ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for x86_64-unknown-linux): mkUsage harpy-0.4:Harpy.CodeGenMonad CodeGen{d} [(01T, base:GHC.Base.return{v 01T}), (32I, base:GHC.IOBase.IO{tc 32I}), (333, base:GHC.Word.Word32{tc 333}), (33A, base:GHC.Ptr.Ptr{tc 33A}), (33D, base:GHC.Ptr.FunPtr{tc 33D}), (40, ghc-prim:GHC.Unit.(){(w) tc 40}), (6Q, base:Data.Either.Right{d 6Q}), (r7, base:GHC.Base.${v r7}), (r4E, mtl-1.1.0.1:Control.Monad.Trans.liftIO{v r4E}), (r8S, base:GHC.Ptr.castPtrToFunPtr{v r8S}), (rO69, harpy-0.4:Harpy.CodeGenMonad.firstBuffer{v rO69}), (rO6z, harpy-0.4:Harpy.CodeGenMonad.CodeGen{d rO6z}), (rO7P, harpy-0.4:Harpy.CodeGenMonad.callDecl{v rO7P}), (rVBT, harpy-0.4:Harpy.Call.conv[aVBL]{v rVBT}), (rVDx, harpy-0.4:Harpy.Call.conv[aVDo]{v rVDx}), (rVJc, harpy-0.4:Harpy.Call.conv[aVIX]{v rVJc})] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ** stream-fusion Data/Stream.hs:575:4: Warning: Pattern match(es) are non-exhaustive In the definition of `next': Patterns not matched: (_ :!: (Just (L _))) :!: S2 [2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, dist/build/Data/List/Stream.o ) stack overflow: use +RTS -K to increase it http://hackage.haskell.org/trac/ghc/ticket/2684 ** xmonad-contrib-0.8 ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcUnify.lhs line 1000 a{tv aAeS} [box] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug http://hackage.haskell.org/trac/ghc/ticket/2683 From gwright at comcast.net Sat Oct 11 04:37:50 2008 From: gwright at comcast.net (Gregory Wright) Date: Sat Oct 11 04:34:06 2008 Subject: has anyone built pandoc with MacPorts ? In-Reply-To: <48EFBF02.8090204@t-online.de> References: <48EF6360.40301@t-online.de> <48EF67B5.3080807@dfki.de> <48EFBF02.8090204@t-online.de> Message-ID: <83F255A6-0E73-4E58-9E08-E370946783E7@comcast.net> Hi Denis, I haven't built pandoc yet --- I didn't do the port --- but I'll have a go at it tonight and let you know what I find. BTW, did you run $ sudo port selfupdate before starting to make sure you had the latest Portfiles for everything? Best Wishes, Greg On Oct 10, 2008, at 4:45 PM, denis wrote: > Greg, folks, > > port install ghc worked after 7 hours or so, but then > > sudo port -v install hs-ghc-paths (on which pandoc apparently depends) > => > # from: sudo port -v install hs-ghc-paths > # run: 10 Oct 2008 22:35 in /opt/local Denis.local mac 10.4.11 ppc > > ---> Configuring hs-ghc-paths > > Setup.hs:7:7: > Could not find module `Distribution.Simple.PackageIndex': > Use -v to see a list of the files searched for. > Error: Target org.macports.configure returned: shell command "cd / > opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_devel_hs-ghc-paths/work/ghc- > paths-0.1.0.5 && runhaskell Setup configure --ghc --prefix=/opt/ > local" returned error 1 > Command output: > Setup.hs:7:7: > Could not find module `Distribution.Simple.PackageIndex': > Use -v to see a list of the files searched for. > > Warning: the following items did not execute (for hs-ghc-paths): > org.macports.activate org.macports.configure org.macports.build > org.macports.destroot org.macports.install > Error: Status 1 encountered during processing. > > > Has anyone ever built pandoc with MacPorts ? Would appreciate your > help. > > cheers > -- denis From jpm at cs.uu.nl Sat Oct 11 05:41:27 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Sat Oct 11 05:37:39 2008 Subject: base-3 vs base-4 (Was: Breakage with 6.10) In-Reply-To: References: Message-ID: <52f14b210810110241v2a0a34ele4c034faec93ce02@mail.gmail.com> Hello, On Sat, Oct 11, 2008 at 03:52, Niklas Broberg wrote: > > > Though obviously this would only work if the module > Data.Generics.Instances was preserved under that name somewhere else. > If it was renamed or changed (which I suspect), then the hassle of > keeping up to date with older versions will probably be too much, and > I will want to update to the new agenda as soon as 6.10 is released > for real. So what happened to this module? (Is there a migration > quicksheet somewhere?) The new syb package has basically all the Data.Generics.* modules. In base4, no Data.Generics.* modules were kept. Instead, a new module, Data.Data, contains all that was in Data.Generics.Basics and most of Data.Generics.Instances. Therefore, in the syb package, Data.Generics.Basics only re-exports module Data.Data from base4, and Data.Generics.Instances defines the instances missing from Data.Data and re-exports the instances from Data.Data. Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081011/ea3e1a2a/attachment.htm From claus.reinke at talk21.com Sat Oct 11 06:16:34 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Oct 11 06:12:50 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) References: Message-ID: >> > Btw, I also have problems with the haskell-src-exts that imports >> > Data.Generics.Instances (to generate Data and Typeable instances). >> > Where would these have moved to in the new base? ghc-pkg provides general help for finding packages for modules: $ ghc-pkg find-module Data.Generics.Instances c:/ghc/ghc-6.11.20081004\package.conf: base-3.0.3.0, syb-0.1.0.0 So there is a compatibility module in the new syb. Unfortunately, that won't tell you about the moves and rationale. Most of the time, you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the Haddock pages, or google for "syb" in the libraries@ archives): $ ghc-pkg find-module Data.Data c:/ghc/ghc-6.11.20081004\package.conf: base-4.0.0.0 $ ghc -ignore-dot-ghci -e ':browse Data.Data' | grep class class (Typeable a) => Data a where class Typeable a where typeOf :: a -> TypeRep class Typeable1 t where typeOf1 :: t a -> TypeRep class Typeable2 t where typeOf2 :: t a b -> TypeRep class Typeable3 t where typeOf3 :: t a b c -> TypeRep class Typeable4 t where typeOf4 :: t a b c d -> TypeRep class Typeable5 t where typeOf5 :: t a b c d e -> TypeRep class Typeable6 t where typeOf6 :: t a b c d e f -> TypeRep class Typeable7 t where typeOf7 :: t a b c d e f g -> TypeRep $ ghc -ignore-dot-ghci -e ':info Data.Data.Data' class .. instance .. > .. I would prefer to use the new > base-4 when possible. The cabal file already includes a conditional > "if flag(splitBase)" to handle really old versions, I guess what I'm > asking for is something similar for this case. Is there a splitSyb > flag or some such? I was wondering whether there is a way to set user-defined flags depending on whether some package is available. Then I recalled that flags don't work the way I expected - instead Cabal will try all flag settings to find a buildable configuration (a fact I only became aware of when a different kind of flag was added recently that does behave the way I expected;-). Which might be what you want in this case. Duncan: is this correct, and are these subtleties documented somewhere? > Though obviously this would only work if the module > Data.Generics.Instances was preserved under that name somewhere else. > If it was renamed or changed (which I suspect), then the hassle of > keeping up to date with older versions will probably be too much, and > I will want to update to the new agenda as soon as 6.10 is released > for real. So what happened to this module? (Is there a migration > quicksheet somewhere?) Pedro: it might be helpful if the haddock pages for the old and new syb modules were to point to a syb wiki page (which could then link to the relevant threads on libraries@)? Or is that information already in the documentation patch for the latest builds? Claus From claus.reinke at talk21.com Sat Oct 11 06:19:41 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Oct 11 06:15:56 2008 Subject: More detail on breakage with ghc-6.10 References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> Message-ID: > We've been using the cabal-install build reporting stuff to get more > detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > generates these build-reports.log files and individual log files for > each build. Since you do have the infrastructure set up: haddock is also changing with ghc-6.10. Are the no (visible) issues resulting from that (which would be great!), or didn't your tests include haddocking? Claus From jpm at cs.uu.nl Sat Oct 11 06:25:21 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Sat Oct 11 06:21:31 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: References: Message-ID: <52f14b210810110325p52dc2109nee7ba1846d46e87a@mail.gmail.com> Hello, On Sat, Oct 11, 2008 at 12:16, Claus Reinke wrote: > > Pedro: it might be helpful if the haddock pages for the old and new syb > modules were to point to a syb wiki page (which could then link > to the relevant threads on libraries@)? Or is that information already in > the documentation patch for the latest builds? > That's a good idea. I will set that up and push patches to the haddock documentation of both base and syb to link there. Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081011/8d70eff7/attachment.htm From niklas.broberg at gmail.com Sat Oct 11 07:04:56 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Oct 11 07:01:06 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: References: Message-ID: > So there is a compatibility module in the new syb. Unfortunately, > that won't tell you about the moves and rationale. Most of the time, > you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the > Haddock pages, or google for "syb" in the libraries@ archives): > > $ ghc-pkg find-module Data.Data > c:/ghc/ghc-6.11.20081004\package.conf: > base-4.0.0.0 Thanks a lot Claus and Jos? for the info. Since all I use is the Data and Typeable classes (presumably like so many others, which I guess was the reason to keep these in base), it would obviously be better for me to avoid linking to the new syb package when I don't have to. > $ ghc -ignore-dot-ghci -e ':info Data.Data.Data' Somehow I find this name hilarious. :-) > > .. I would prefer to use the new > > base-4 when possible. The cabal file already includes a conditional > > "if flag(splitBase)" to handle really old versions, I guess what I'm > > asking for is something similar for this case. Is there a splitSyb > > flag or some such? > > > > I was wondering whether there is a way to set user-defined flags > depending on whether some package is available. Then I recalled > that flags don't work the way I expected - instead Cabal will try > all flag settings to find a buildable configuration (a fact I only became > aware of when a different kind of flag was added recently that does > behave the way I expected;-). Which might be what you want in this case. > Duncan: is this correct, and are these subtleties documented somewhere? While these things would be good to know in general, it seems this is not what I want in this case, since I don't want to use the syb package after all. It seems instead what I want is to simply make a conditional import of either Data.Generics or Data.Data based on which version of base is available. I guess that means more CPP heresy, sigh. Thanks, /Niklas From igloo at earth.li Sat Oct 11 08:23:31 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Oct 11 08:19:46 2008 Subject: Breakage with 6.10 In-Reply-To: <1223679247.6878.241.camel@dell.linuxdev.us.dell.com> References: <20081010223421.GP6102@scytale.galois.com> <1223679247.6878.241.camel@dell.linuxdev.us.dell.com> Message-ID: <20081011122330.GA8345@matrix.chaos.earth.li> On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts wrote: > On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: > > arrows fails due to: > > > > [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) > > > > Control/Arrow/Transformer/CoState.hs:24:29: > > Module `Control.Arrow' does not export `pure' > > > > Even though cabal-install decided to use base-3.0.3.0 > > > > So that means base-3 is *not* exporting quite the same interface as last time. > > Were we aware of this? > > Note that this means that base-3 should have the version number 3.1.x.y > because there is at least one incompatible api change. We're promoting > the versioning policy so we need to follow it ourselves in our base > libs. I don't think that that really helps. If you're going to depend on base 3.1, you might as well just depend on base 4 and be more future-proof. The base-compat package needs to claim to have the same API as the old base, because the point is that things just keep on working (except in the few cases, like the Arrow split, where that isn't possible). Thanks Ian From igloo at earth.li Sat Oct 11 10:37:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Oct 11 10:33:47 2008 Subject: readEither in ghc-6.10. ? In-Reply-To: <48EF7768.7070101@dfki.de> References: <48EF7768.7070101@dfki.de> Message-ID: <20081011143736.GA18263@matrix.chaos.earth.li> Hi Christian, On Fri, Oct 10, 2008 at 05:40:24PM +0200, Christian Maeder wrote: > > Not in scope: `readEither' > > import GHC.Read (readEither) > > and used to work with ghc-6.8. > > What should I use as replacement? > > P.S. It is also not mentioned in the changes: We don't guarantee anything about functions in GHC.* modules (with the half-exceptions of GHC.Exts and GHC.Prim). I'd recommend wrapping reads instead. Thanks Ian From dave at zednenem.com Sat Oct 11 12:41:04 2008 From: dave at zednenem.com (David Menendez) Date: Sat Oct 11 12:37:13 2008 Subject: base-3 vs base-4 (Was: Breakage with 6.10) In-Reply-To: <52f14b210810110241v2a0a34ele4c034faec93ce02@mail.gmail.com> References: <52f14b210810110241v2a0a34ele4c034faec93ce02@mail.gmail.com> Message-ID: <49a77b7a0810110941l112c24f1md02b72f8f0860bde@mail.gmail.com> 2008/10/11 Jos? Pedro Magalh?es : > In base4, no Data.Generics.* modules were kept. Instead, a new module, > Data.Data, contains all that was in Data.Generics.Basics and most of > Data.Generics.Instances. Data.Data? Surely we can come up with something better than that. -- Dave Menendez From dons at galois.com Sat Oct 11 12:52:24 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 12:48:22 2008 Subject: More detail on breakage with ghc-6.10 In-Reply-To: References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> Message-ID: <20081011165224.GC11641@scytale.galois.com> claus.reinke: > >We've been using the cabal-install build reporting stuff to get more > >detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > >generates these build-reports.log files and individual log files for > >each build. > > Since you do have the infrastructure set up: haddock is also changing > with ghc-6.10. Are the no (visible) issues resulting from that (which > would be great!), or didn't your tests include haddocking? No haddock tests yet, but we can start doing that. Good idea. From jpm at cs.uu.nl Sat Oct 11 13:02:42 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Sat Oct 11 12:58:52 2008 Subject: base-3 vs base-4 (Was: Breakage with 6.10) In-Reply-To: <49a77b7a0810110941l112c24f1md02b72f8f0860bde@mail.gmail.com> References: <52f14b210810110241v2a0a34ele4c034faec93ce02@mail.gmail.com> <49a77b7a0810110941l112c24f1md02b72f8f0860bde@mail.gmail.com> Message-ID: <52f14b210810111002s3b517986w3ce21e4c4a339156@mail.gmail.com> On Sat, Oct 11, 2008 at 18:41, David Menendez wrote: > 2008/10/11 Jos? Pedro Magalh?es : > > In base4, no Data.Generics.* modules were kept. Instead, a new module, > > Data.Data, contains all that was in Data.Generics.Basics and most of > > Data.Generics.Instances. > > Data.Data? Surely we can come up with something better than that. > Please do. That's the only name that came up in [1]. I think I'd still like Generics.SYB, but that might be too big of a change... Thanks, Pedro [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929/focus=9947 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081011/6b0f7b06/attachment.htm From dons at galois.com Sat Oct 11 13:21:47 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 13:17:45 2008 Subject: A wiki page for managing the 6.10 handover Message-ID: <20081011172147.GD11641@scytale.galois.com> http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10 It collects the 7 or so known issues that break code with GHC 6.10. Please feel free to clean up, and especially *add techniques for handling each change*. If we do this right, with cabal-install being smart, clear summaries of what is broken and how to fix it, this might be the smoothest major release yet. -- Don From dons at galois.com Sat Oct 11 13:42:53 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 13:38:50 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: References: Message-ID: <20081011174253.GE11641@scytale.galois.com> niklas.broberg: > > So there is a compatibility module in the new syb. Unfortunately, > > that won't tell you about the moves and rationale. Most of the time, > > you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the > > Haddock pages, or google for "syb" in the libraries@ archives): > > > > $ ghc-pkg find-module Data.Data > > c:/ghc/ghc-6.11.20081004\package.conf: > > base-4.0.0.0 > > Thanks a lot Claus and Jos? for the info. Since all I use is the Data > and Typeable classes (presumably like so many others, which I guess > was the reason to keep these in base), it would obviously be better > for me to avoid linking to the new syb package when I don't have to. Perhaps people could add details about managing the syb handover to the 'upgrading' wiki page, http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10 From bulat.ziganshin at gmail.com Sat Oct 11 13:47:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Oct 11 13:45:23 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <20081011172147.GD11641@scytale.galois.com> References: <20081011172147.GD11641@scytale.galois.com> Message-ID: <25706211.20081011214736@gmail.com> Hello Don, Saturday, October 11, 2008, 9:21:47 PM, you wrote: > It collects the 7 or so known issues that break code with GHC 6.10. i've quickly tried to compile my app with 6.10 (using base4). all the problems i got was due to exception handling. catch, finally, throwIO doesn't work added to wiki -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Sat Oct 11 13:54:10 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 13:50:07 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <25706211.20081011214736@gmail.com> References: <20081011172147.GD11641@scytale.galois.com> <25706211.20081011214736@gmail.com> Message-ID: <20081011175410.GF11641@scytale.galois.com> bulat.ziganshin: > Hello Don, > > Saturday, October 11, 2008, 9:21:47 PM, you wrote: > > It collects the 7 or so known issues that break code with GHC 6.10. > > i've quickly tried to compile my app with 6.10 (using base4). all the > problems i got was due to exception handling. catch, finally, throwIO > doesn't work > > added to wiki The fix for exception handling and friends is to add a dependency on base-3, http://haskell.org/haskellwiki/Upgrading_packages#Adding_base-3_constraints If you build your app with cabal-install, it will work this out for you, otherwise, you need to add something like --constraint="base<4" if you use runhaskell, or --package base-3.0.3.0 if you use ghc --make. -- Don From bulat.ziganshin at gmail.com Sat Oct 11 14:02:20 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Oct 11 14:09:04 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <20081011175410.GF11641@scytale.galois.com> References: <20081011172147.GD11641@scytale.galois.com> <25706211.20081011214736@gmail.com> <20081011175410.GF11641@scytale.galois.com> Message-ID: <1705811808.20081011220220@gmail.com> Hello Don, Saturday, October 11, 2008, 9:54:10 PM, you wrote: seems that i misunderstood it: i thought it's a list of base4 vs base3 changes, but actually it seems like a base30 vs base31? base3 -> base4 upgrade hints are not documented anywhere? > bulat.ziganshin: >> Hello Don, >> >> Saturday, October 11, 2008, 9:21:47 PM, you wrote: >> > It collects the 7 or so known issues that break code with GHC 6.10. >> >> i've quickly tried to compile my app with 6.10 (using base4). all the >> problems i got was due to exception handling. catch, finally, throwIO >> doesn't work >> >> added to wiki > The fix for exception handling and friends is to add a dependency on > base-3, > > http://haskell.org/haskellwiki/Upgrading_packages#Adding_base-3_constraints > If you build your app with cabal-install, it will work this out for you, > otherwise, you need to add something like > --constraint="base<4" > if you use runhaskell, or > --package base-3.0.3.0 > if you use ghc --make. > -- Don -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Sat Oct 11 14:23:24 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 14:19:22 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <1705811808.20081011220220@gmail.com> References: <20081011172147.GD11641@scytale.galois.com> <25706211.20081011214736@gmail.com> <20081011175410.GF11641@scytale.galois.com> <1705811808.20081011220220@gmail.com> Message-ID: <20081011182324.GG11641@scytale.galois.com> bulat.ziganshin: > Hello Don, > > Saturday, October 11, 2008, 9:54:10 PM, you wrote: > > seems that i misunderstood it: i thought it's a list of base4 vs base3 > changes, but actually it seems like a base30 vs base31? > > base3 -> base4 upgrade hints are not documented anywhere? > It's a list of how to upgrade your code to GHC 6.10 and keep it working. If you want to describe how to migrate from base3 to base4, that is also useful, but not criical yet, since it won't break things. -- Don From duncan.coutts at worc.ox.ac.uk Sat Oct 11 14:19:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Oct 11 14:37:22 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <48EF7137.9000903@gmail.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> <48EF7137.9000903@gmail.com> Message-ID: <1223749192.6878.325.camel@dell.linuxdev.us.dell.com> On Fri, 2008-10-10 at 16:13 +0100, Simon Marlow wrote: > As far as I can see, you could export a compatibility shim called > buildVerbose without any difficulty, Done. > all I have to do is remove the explicit import list. Or is there a > better fix you had in mind? Patches for alex and happy attached. Their Setup.lhs now works with 1.2, 1.4 and 1.6 (1.6.0.1). Duncan -------------- next part -------------- New patches: [Fix to make Setup.lhs compile with Cabal-1.2, 1.4 and 1.6 Duncan Coutts **20081011181133] { hunk ./Setup.lhs 7 -import Distribution.Simple.Setup ( BuildFlags(..) ) +import Distribution.Simple.Setup ( BuildFlags(..), buildVerbose ) } Context: [monadUserState alcremi@pobox.com**20080902075531 add the monadUserState wrapper, and its variant monadUserState-bytestring, allowing to define a custom state monad in the lex specification ] [Add support for efficient lexing of strict bytestrings Don Stewart **20080718224320] [Untabify Don Stewart **20080718224243] [doc fix Simon Marlow **20080218092857] [fix small doc bug, pointed out by Ben Challenor [bdc25@cam.ac.uk] Simon Marlow **20071219085223] [add release instructions Simon Marlow **20071114150257] [TAG 2.2 release Simon Marlow **20071101141613] Patch bundle hash: 24ca734b06b45071f760f601001ac1e5587d90f6 -------------- next part -------------- A non-text attachment was scrubbed... Name: happy-cabal-compat.dpatch Type: application/octet-stream Size: 1790 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081011/cc54dbe8/happy-cabal-compat.obj From niklas.broberg at gmail.com Sat Oct 11 15:02:11 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Oct 11 14:58:20 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: References: Message-ID: On 10/11/08, Niklas Broberg wrote: > dons: > > A breakdown of the remaing causes for DependencyFailed, > > [...] > > 4 hsx-0.4.4 New version uploaded that works with both 6.8.3 and 6.10 rc1 (through dark cpp magic). I doubt I need to show this trick to anyone else since I seem to have been the only one brave/foolish enough to depend on this quirk of type families in 6.8. I'm proud to say I'm off the list now anyway. :-) Cheers, /Niklas From gwright at comcast.net Sat Oct 11 15:04:17 2008 From: gwright at comcast.net (Gregory Wright) Date: Sat Oct 11 15:00:30 2008 Subject: has anyone built pandoc with MacPorts ? In-Reply-To: <48EFBF02.8090204@t-online.de> References: <48EF6360.40301@t-online.de> <48EF67B5.3080807@dfki.de> <48EFBF02.8090204@t-online.de> Message-ID: <9197A232-E1EC-4C0F-B46F-A428E56C65A6@comcast.net> Hi, On Oct 10, 2008, at 4:45 PM, denis wrote: > Greg, folks, > > port install ghc worked after 7 hours or so, but then > > sudo port -v install hs-ghc-paths (on which pandoc apparently depends) > => > # from: sudo port -v install hs-ghc-paths > # run: 10 Oct 2008 22:35 in /opt/local Denis.local mac 10.4.11 ppc > > ---> Configuring hs-ghc-paths > > Setup.hs:7:7: > Could not find module `Distribution.Simple.PackageIndex': > Use -v to see a list of the files searched for. > Error: Target org.macports.configure returned: shell command "cd / > opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_devel_hs-ghc-paths/work/ghc- > paths-0.1.0.5 && runhaskell Setup configure --ghc --prefix=/opt/ > local" returned error 1 > Command output: > Setup.hs:7:7: > Could not find module `Distribution.Simple.PackageIndex': > Use -v to see a list of the files searched for. > > Warning: the following items did not execute (for hs-ghc-paths): > org.macports.activate org.macports.configure org.macports.build > org.macports.destroot org.macports.install > Error: Status 1 encountered during processing. > > > Has anyone ever built pandoc with MacPorts ? Would appreciate your > help. > > cheers > -- denis Pandoc built fine for me on Mac OS X 10.5.5/intel with ghc 6.8.3, hs- ghc-paths 0.1.0.5 and haddock 2.2.2. What version of the ghc port are you using (i.e., the output of $ port info ghc ? Also, do you have more than one version of cabal on your system? Best Wishes, Greg From igloo at earth.li Sat Oct 11 15:32:06 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Oct 11 15:28:15 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <48EE091C.10803@dfki.de> References: <20081008200939.GA5675@matrix.chaos.earth.li> <48EE091C.10803@dfki.de> Message-ID: <20081011193206.GA29482@matrix.chaos.earth.li> On Thu, Oct 09, 2008 at 03:37:32PM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > > Please test as much as possible; bugs are much cheaper if we find them > > before the release! > > How about a test-suite? Good point: I've addde one to http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html > P.S. "make binary-dist" creates a big unnecessary ".tar" file together > with the final ".tar.bz2" file. Also a (disturbing) link > "ghc-6.10.0.20081007 -> ." is created. The link is deliberate (we tar things up from the build tree, rather than making a ghc-6.10.0.20081007 directory and copying them there). > ("make install" no longer reports > which path to add) Ooops, the logic for whether to print the message was the wrong way round. Now fixed. Thanks Ian From dons at galois.com Sat Oct 11 21:11:54 2008 From: dons at galois.com (Don Stewart) Date: Sat Oct 11 21:07:52 2008 Subject: 2008-10-11 Hackage status with GHC 6.10 Message-ID: <20081012011154.GK11641@scytale.galois.com> Daily update of the state of Hackage wrt. GHC 6.10 release candidates. Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6 were also put out. Things are in a good shape. Note that you'll need a "soft dep" in your cabal index file, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 for best results. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 684 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 74 DependencyFailed 134 BuildFailed 455 InstallOk Compared to GHC 6.8.x's results, there are now *48* packages that produce different results, or *6%* (down 2% from yesterday). The most common issues are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Packages that have broken wrt. the new core library APIs are, ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 heap-0.4.0 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 unicode-prelude-0.1 xmonad-utils-0.1 yhccore-0.9 GHC bugs are suspected for, xmonad-contrib, stream-fusion, harpy, OpenAFP Tickets are open for these. Build reports for these packages were posted yesterday, http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430 -- Don From igloo at earth.li Sun Oct 12 11:24:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 12 11:20:10 2008 Subject: Parsec in 6.10 RC 1 In-Reply-To: <1f3dc80d0810081710w3f35bf8vd0ccb7939580e18e@mail.gmail.com> References: <1f3dc80d0810081710w3f35bf8vd0ccb7939580e18e@mail.gmail.com> Message-ID: <20081012152403.GA27020@matrix.chaos.earth.li> On Wed, Oct 08, 2008 at 05:10:53PM -0700, Greg Fitzgerald wrote: > The instance for "Functor (Either ParserError)" disappeared. Is that > intentional? The instance is still in Control.Monad.Instances. The problem with the instance is that Haskell 98 doesn't say that it exists, so we can't put it with either the Functor or Either definitions. You were probably indirectly importing Control.Monad.Instances before, but other changes now mean that you no longer are. Thanks Ian From dons at galois.com Sun Oct 12 17:46:05 2008 From: dons at galois.com (Don Stewart) Date: Sun Oct 12 17:41:57 2008 Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate Message-ID: <20081012214605.GA19039@scytale.galois.com> Hey all. The GHC 6.10 RCs are out, and we're preparing the release. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 73 DependencyFailed 132 BuildFailed 456 InstallOk Note that these builds are with "soft deps", provided on hackage, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 which train cabal-install to build a larger set of packages. The important result: *46 packages produce different results to ghc 6.8.2* These packages and their logs are listed below. If you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-12/ The following packages are producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 xmonad-utils-0.1 yhccore-0.9 If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log -- Don From marlowsd at gmail.com Mon Oct 13 04:58:39 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 13 04:54:48 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <1223749192.6878.325.camel@dell.linuxdev.us.dell.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> <48EF7137.9000903@gmail.com> <1223749192.6878.325.camel@dell.linuxdev.us.dell.com> Message-ID: <48F30DBF.2080900@gmail.com> Duncan Coutts wrote: > On Fri, 2008-10-10 at 16:13 +0100, Simon Marlow wrote: >> As far as I can see, you could export a compatibility shim called >> buildVerbose without any difficulty, > > Done. > >> all I have to do is remove the explicit import list. Or is there a >> better fix you had in mind? > > Patches for alex and happy attached. Their Setup.lhs now works with 1.2, > 1.4 and 1.6 (1.6.0.1). Thanks! New versions of Alex & Happy uploaded. Cheers, Simon From marlowsd at gmail.com Mon Oct 13 05:08:44 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 13 05:04:53 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <20081011172147.GD11641@scytale.galois.com> References: <20081011172147.GD11641@scytale.galois.com> Message-ID: <48F3101C.5010402@gmail.com> Don Stewart wrote: > http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10 > > It collects the 7 or so known issues that break code with GHC 6.10. > Please feel free to clean up, and especially *add techniques for > handling each change*. > > If we do this right, with cabal-install being smart, clear summaries of > what is broken and how to fix it, this might be the smoothest major > release yet. This is wonderful. I've been making noises about trying to make the transition smoother this time, but you and Duncan have done most of the hard work. Not only that, but the process has turned up some bugs that hopefully we'll be able to fix in time for the release. Great stuff, thanks guys! Cheers, Simon From simonpj at microsoft.com Mon Oct 13 05:12:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 13 05:07:15 2008 Subject: A wiki page for managing the 6.10 handover In-Reply-To: <48F3101C.5010402@gmail.com> References: <20081011172147.GD11641@scytale.galois.com> <48F3101C.5010402@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A789AC@EA-EXMSG-C334.europe.corp.microsoft.com> | http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_ | 6.10 | > | > It collects the 7 or so known issues that break code with GHC 6.10. | > Please feel free to clean up, and especially *add techniques for | > handling each change*. | > | > If we do this right, with cabal-install being smart, clear summaries of | > what is broken and how to fix it, this might be the smoothest major | > release yet. | | This is wonderful. I've been making noises about trying to make the | transition smoother this time, but you and Duncan have done most of the | hard work. Not only that, but the process has turned up some bugs that | hopefully we'll be able to fix in time for the release. Great stuff, | thanks guys! Yes, a big thank you from me too. Fantastic work. Simon From marlowsd at gmail.com Mon Oct 13 05:14:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 13 05:10:55 2008 Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate In-Reply-To: <20081012214605.GA19039@scytale.galois.com> References: <20081012214605.GA19039@scytale.galois.com> Message-ID: <48F3117C.1020805@gmail.com> Don Stewart wrote: > Note that these builds are with "soft deps", provided on hackage, > > base < 4 > parsec < 3 > HaXml == 1.13.* > QuickCheck < 2 > > which train cabal-install to build a larger set of packages. Will this happen automatically somehow, or will users have to do this manually? > The important result: > > *46 packages produce different results to ghc 6.8.2* > > These packages and their logs are listed below. > > If you maintain one of the following packages, and are able to fix it before > GHC 6.10 is released, your users will be happy. > > The most common issues for these differences are, > > * Changes to Arrow class definition > * Changes to types of Map and Set functions It would be feasible to provide a containers-0.1, if anyone thinks that's worthwhile. > * Cabal changes > * Changes to ghc-api > * Changes to when 'forall' is parsed (add Rank2Types) > * GHC.Prim was moved, Nobody should be importing GHC.Prim, use GHC.Exts instead. > * Changes to -fvia-C and headers I wrote a more detailed entry for the release notes about this: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-1.html ("FFI change" under "User-visible compiler changes") Cheers, Simon From marlowsd at gmail.com Mon Oct 13 05:25:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 13 05:22:05 2008 Subject: Breakage with 6.10 In-Reply-To: <20081011122330.GA8345@matrix.chaos.earth.li> References: <20081010223421.GP6102@scytale.galois.com> <1223679247.6878.241.camel@dell.linuxdev.us.dell.com> <20081011122330.GA8345@matrix.chaos.earth.li> Message-ID: <48F31425.6070704@gmail.com> Ian Lynagh wrote: > On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts wrote: >> On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: >>> arrows fails due to: >>> >>> [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) >>> >>> Control/Arrow/Transformer/CoState.hs:24:29: >>> Module `Control.Arrow' does not export `pure' >>> >>> Even though cabal-install decided to use base-3.0.3.0 >>> >>> So that means base-3 is *not* exporting quite the same interface as last time. >>> Were we aware of this? >> Note that this means that base-3 should have the version number 3.1.x.y >> because there is at least one incompatible api change. We're promoting >> the versioning policy so we need to follow it ourselves in our base >> libs. > > I don't think that that really helps. If you're going to depend on base > 3.1, you might as well just depend on base 4 and be more future-proof. > The base-compat package needs to claim to have the same API as the old > base, because the point is that things just keep on working (except in > the few cases, like the Arrow split, where that isn't possible). Hmm, this is quite annoying. We simply *can't* provide the same API as base-3.0.2 without defining a new Arrow class, and that would kill compatibility with base-4. On the other hand, we did know this could happen (changes to datatypes also cause the same problem), it's the tradeoff with trying to provide base-3 as a compatibility layer over base-4. So the options are: * if we are honest and call it base-3.1, then everyone else has to lie and use dependencies like base==4.*. If they use dependencies like base==4.0, which are more correct, then these packages will break in GHC 6.12 if we have to ship base-4.1 rather than 4.0. * we lie (a bit) and call it base-3.0.3. so the total amount of dishonesty is reduced if we pick the second option :-) Perhaps we've found a use for the second digit of the major version number. Cheers, Simon From jpm at cs.uu.nl Mon Oct 13 05:39:40 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Oct 13 05:35:44 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: <20081011174253.GE11641@scytale.galois.com> References: <20081011174253.GE11641@scytale.galois.com> Message-ID: <52f14b210810130239w1b6004e0g349be92099bf8f4a@mail.gmail.com> Hello, I created a new wiki page for SYB which also contains some more detailed information on the changes for 6.10: http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081013/5432325c/attachment.htm From Christian.Maeder at dfki.de Mon Oct 13 07:41:09 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 13 07:37:13 2008 Subject: pandoc from cabal / MacPorts ? In-Reply-To: <48F326C3.2010301@t-online.de> References: <48EF6360.40301@t-online.de> <48EF67B5.3080807@dfki.de> <48EFBF02.8090204@t-online.de> <9197A232-E1EC-4C0F-B46F-A428E56C65A6@comcast.net> <48F326C3.2010301@t-online.de> Message-ID: <48F333D5.3030105@dfki.de> I'll CC this to glasgow-haskell-users@haskell.org in case someone else has the same problem. 1. Download http://hackage.haskell.org/packages/archive/pandoc/1.0.0.1/pandoc-1.0.0.1.tar.gz http://hackage.haskell.org/packages/archive/zip-archive/0.1.1/zip-archive-0.1.1.tar.gz http://hackage.haskell.org/packages/archive/utf8-string/0.3.1.1/utf8-string-0.3.1.1.tar.gz http://hackage.haskell.org/packages/archive/zlib/0.4.0.4/zlib-0.4.0.4.tar.gz http://hackage.haskell.org/packages/archive/binary/0.4.3.1/binary-0.4.3.1.tar.gz And install all this packages in reverse order (the last 3 packages are independent) 2. Alternatively you can first install http://hackage.haskell.org/packages/archive/cabal-install/0.5.2/cabal-install-0.5.2.tar.gz (versions 0.5.1 or 0.6 will work, too) after installing a further version of Cabal http://hackage.haskell.org/packages/archive/Cabal/1.4.0.2/Cabal-1.4.0.2.tar.gz and http://hackage.haskell.org/packages/archive/HTTP/3001.1.3/HTTP-3001.1.3.tar.gz http://hackage.haskell.org/packages/archive/zlib/0.4.0.4/zlib-0.4.0.4.tar.gz Once you have cabal, installing is much easier (just "cabal install pandoc"). Installing one of the above *.tar.gz packages works as follows: tar zxf .tar.gz cd ghc --make Setup.* ./Setup configure ./Setup build ./Setup install cd .. (This Setup.* is either Setup.hs or Setup.lhs) You may supply a "--prefix=/opt/local" to ./Setup configure. Cheers Christian denis wrote: > Greg, Christian, > still no luck here in macosx 10.4.11 ppc, > port install hs-ghc-paths => the errors in Friday's mail below > > I'm probably missing something basic -- > should I "port install hs-cabal" before hs-ghc-paths <- haddock <- > pandoc ? > It seems to have come in with ghc > cabal --version => > cabal-install version 0.5.1 > using version 1.4.0.2 of the Cabal library > > port list install | egrep => > ghc @6.8.3 lang/ghc > hs-HTTP @3001.0.4 devel/hs-HTTP > hs-libcabal @1.4.0.2 devel/hs-libcabal > hs-zlib @0.4.0.4 devel/hs-zlib > > > Trying to just configure hs-cabal -- maybe a wrong thing to do -- > sudo port clean --all hs-cabal > sudo port -v configure hs-cabal > # from: sudo port -v configure hs-cabal > # run: 13 Oct 2008 11:06 in /opt/local Denis.local mac 10.4.11 ppc > > ---> Verifying checksum(s) for hs-cabal > ---> Checksumming cabal-install-0.5.1.tar.gz > ---> Extracting hs-cabal > ---> Extracting cabal-install-0.5.1.tar.gz > ---> Configuring hs-cabal > Configuring cabal-install-0.5.1... > Setup: At least the following dependencies are missing: > Cabal >=1.4&&<1.5, HTTP >=3000&&<3002, zlib >=0.4 > Error: Target org.macports.configure returned: shell command "cd > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-cabal/work/cabal-install-0.5.1 > && runhaskell Setup configure --ghc --prefix=/opt/local" returned error 1 > Command output: Configuring cabal-install-0.5.1... > Setup: At least the following dependencies are missing: > Cabal >=1.4&&<1.5, HTTP >=3000&&<3002, zlib >=0.4 > > Warning: the following items did not execute (for hs-cabal): > org.macports.configure > Error: Status 1 encountered during processing. > > > Also, is there a way of listing dependency chains / trees like > ghc <- hs-ghc-paths <- haddock <- pandoc > (on all, not just installed, packages) > so that one can build them step by step ? > > > Christian, what's the simplest sequence to build haddock / pandoc from > the source > pandoc-1.0.0.1.tar.gz without MacPorts ? > I just want pandoc, don't care about haskel / ghc / ... at all. > The nice pandoc INSTALL says > Pandoc needs the `utf8-string` and `zip-archive` to compile. > ... On \*nix systems, the easiest way to do this is to install the > [cabal-install] tool ... > But how do I "cabal list installed-locally", "cabal list-tree-to pandoc" ? > > Thanks, > cheers > -- denis > From jpm at cs.uu.nl Mon Oct 13 08:02:07 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Oct 13 07:58:11 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: <52f14b210810130239w1b6004e0g349be92099bf8f4a@mail.gmail.com> References: <20081011174253.GE11641@scytale.galois.com> <52f14b210810130239w1b6004e0g349be92099bf8f4a@mail.gmail.com> Message-ID: <52f14b210810130502v648335e3vbf5e5b3cfbe47a4c@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: outputPatchBase4 Type: application/octet-stream Size: 1596 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081013/052862f7/outputPatchBase4.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: outputPatchSyb Type: application/octet-stream Size: 2389 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081013/052862f7/outputPatchSyb.obj From Christian.Maeder at dfki.de Mon Oct 13 11:08:29 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 13 11:04:41 2008 Subject: Testsuite Re: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081011193206.GA29482@matrix.chaos.earth.li> References: <20081008200939.GA5675@matrix.chaos.earth.li> <48EE091C.10803@dfki.de> <20081011193206.GA29482@matrix.chaos.earth.li> Message-ID: <48F3646D.7060206@dfki.de> Ian Lynagh wrote: > http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html My testsuite results can be found under: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.0.20081007-tests.log.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.0.20081007-tests.log.bz2 371 unexpected failures resp. 195 unexpected failures Christian From dons at galois.com Mon Oct 13 13:54:08 2008 From: dons at galois.com (Don Stewart) Date: Mon Oct 13 13:50:19 2008 Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate In-Reply-To: <48F3117C.1020805@gmail.com> References: <20081012214605.GA19039@scytale.galois.com> <48F3117C.1020805@gmail.com> Message-ID: <20081013175408.GA22398@scytale.galois.com> marlowsd: > Don Stewart wrote: > > >Note that these builds are with "soft deps", provided on hackage, > > > > base < 4 > > parsec < 3 > > HaXml == 1.13.* > > QuickCheck < 2 > > > >which train cabal-install to build a larger set of packages. > > Will this happen automatically somehow, or will users have to do this > manually? Yes, Duncan and Ross have modified the scripts on hackage, so that a "preferred-versions" file is included in the Hackage index. So there is one central point where these version suggestions to cabal-install are set. As long as you're using cabal-install 0.6, and do a 'cabal update' things should just work. -- Don From duncan.coutts at worc.ox.ac.uk Mon Oct 13 14:27:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 13 14:24:12 2008 Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate In-Reply-To: <20081013175408.GA22398@scytale.galois.com> References: <20081012214605.GA19039@scytale.galois.com> <48F3117C.1020805@gmail.com> <20081013175408.GA22398@scytale.galois.com> Message-ID: <1223922475.14942.40.camel@dell.linuxdev.us.dell.com> On Mon, 2008-10-13 at 10:54 -0700, Don Stewart wrote: > marlowsd: > > Don Stewart wrote: > > > > >Note that these builds are with "soft deps", provided on hackage, > > > > > > base < 4 > > > parsec < 3 > > > HaXml == 1.13.* > > > QuickCheck < 2 > > > > > >which train cabal-install to build a larger set of packages. > > > > Will this happen automatically somehow, or will users have to do this > > manually? > > Yes, Duncan and Ross have modified the scripts on hackage, so that a > "preferred-versions" file is included in the Hackage index. There was a day and a half or so when this change got accidentally reverted due to some mis-communication between myself and Ross (my fault). It's all fixed up now. Currently these preferred version are only taken into account by "cabal install" not "cabal configure" (though that's an obvious improvement to do). Duncan From duncan.coutts at worc.ox.ac.uk Mon Oct 13 14:35:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 13 14:31:16 2008 Subject: [Haskell-cafe] Hackage and GUI (was Hackage status with GHC 6.10 release candidate) In-Reply-To: <1223907325.2972.27.camel@localhost.localdomain> References: <20081012214605.GA19039@scytale.galois.com> <1223907325.2972.27.camel@localhost.localdomain> Message-ID: <1223922914.14942.44.camel@dell.linuxdev.us.dell.com> On Mon, 2008-10-13 at 16:15 +0200, Hans van Thiel wrote: > What's the status of Gtk2Hs with regard to Cabal? Is it correct that not > one of the applications on Hackage, and there are some, uses or can use > a GUI at this point in time? Gtk2Hs still does not use Cabal as its build system. With the recent summer of code project on a dependency framework for Cabal we're now much closer to being able to convert Gtk2Hs to use Cabal. There are several packages on hackage that depend on gtk2hs or wxhaskell. > Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the > past there have sometimes been problems with new GHC releases and > Gtk2Hs. These have always been addressed, but it usually took a few > months.. I think I've seen some patches going past on the gtk2hs-devel list for ghc-6.10 compatibility. Duncan From matti.niemenmaa+news at iki.fi Mon Oct 13 16:26:55 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Mon Oct 13 16:31:09 2008 Subject: Hackage and GUI (was Hackage status with GHC 6.10 release candidate) In-Reply-To: <1223907325.2972.27.camel@localhost.localdomain> References: <20081012214605.GA19039@scytale.galois.com> <1223907325.2972.27.camel@localhost.localdomain> Message-ID: Hans van Thiel wrote: > Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the > past there have sometimes been problems with new GHC releases and > Gtk2Hs. These have always been addressed, but it usually took a few > months.. I just built Gtk2Hs with the 6.10-rc on Windows, and it seems to work. The release version, 0.9.13, is a no-go though: I needed a patch (related to an "instance Binary Integer") before I got it to compile. And a lot of other messing about as well, but I've got used to that on Windows. From dons at galois.com Tue Oct 14 01:08:42 2008 From: dons at galois.com (Don Stewart) Date: Tue Oct 14 01:04:29 2008 Subject: 2008-10-13 Hackage status with GHC 6.10 release candidate Message-ID: <20081014050842.GB25748@scytale.galois.com> Hey all. The GHC 6.10 RCs are out, and we're preparing the release of GHC proper. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC from today, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 68 DependencyFailed 122 BuildFailed 469 InstallOk Since yesterday, * dependency failures have reduced by 5 * build failures have reduced by 10 * total successfully installed packages are **up by 14** These new packages now all build ok with the GHC 6.10 release candidate, Graphalyze-0.4 alsa-midi calc glome-hs harpy heap hmp3 ircbouncer mohws panda pandoc roguestar-engine type-level typeof unicode-prelude urlcheck Good work everyone! Some packages are still not ready though, if you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror The following packages are still producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. I've marked the easy ones. ArrayRef-0.1.2 Easy: duplicate type signatures CLASE-2008.9.23.2 Hard: GADT changes EdisonCore-1.2.1.2 Easy: Monadic Map HPDF-1.4 Easy: Monadic Map HaLeX-1.1 Easy: Name clash with permutations Hashell-0.15 ? : GHC API Hipmunk-0.2 Easy: Monadic Map MemoTrie-0.0 Easy: 'forall' parsing NewBinary-0.1.1 Easy: Integer constructors moved PArrows-0.1 Easy: GHC.Prim moved (use GHC.Exts) TypeCompose-0.5 Easy: Arrow class changes YamlReference-0.9.2 Hard. Unknown Yampa-0.9.2.2 Arrow class changes arrows-0.4 Arrow class changes bytestring-show-0.2 Easy: Integer constructors moved cabal-setup-1.2.1 Hard: Cabal changes chp-1.1.0 Easy: Arrow class changes cmath-0.3 Hard: -fvia-C changes fixpoint-0.1 Easy: Uses -Werror unnecessarily hasim-0.1 Hard: GADT changes hask-home-2007.12.6 Easy: Cabal changes hetris-0.2 Easy: header macros/-fvia-C hexpat-0.2 Easy: 'forall' parsing in RULES hinstaller-2008.2.16 Easy: Cabal changes hint-0.2.4.1 Hard? GHC API hslackbuilder-0.0.1 Easy: Cabal changes hxt-8.1.0 Easy: Arrow class change iException-0.0.1 ? Exception changes libGenI-0.16.1 Easy: Monadic Map changes mage-1.1.0 Hard: -fvia-C changes numeric-prelude-0.0.4 Easy: Lanuage pragma plugins-1.3 Easy: Cabal changes quantum-arrow-0.0.4 Easy: Arrow class changes regex-tdfa-0.94 Easy: Map changes streamproc-1.1 Easy: Arrow class changes stringtable-atom-0.0.4 Easy: Monadic Map typalyze-0.1.1 ? GHC API xmonad-utils-0.1 ? GHC API yhccore-0.9 ? Pragma parsing Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-13/ How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log I'll start mailing maintainers personally tomorrow. -- Don From duncan.coutts at worc.ox.ac.uk Tue Oct 14 01:19:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 14 01:15:08 2008 Subject: 2008-10-13 Hackage status with GHC 6.10 release candidate In-Reply-To: <20081014050842.GB25748@scytale.galois.com> References: <20081014050842.GB25748@scytale.galois.com> Message-ID: <1223961549.14942.95.camel@dell.linuxdev.us.dell.com> On Mon, 2008-10-13 at 22:08 -0700, Don Stewart wrote: > Using GHC 6.10 RC from today, Cabal 1.6 and cabal-install 1.16, of 682 > libraries and apps tried in total, Note that's cabal-install-0.6 :-) > 1 UnpackFailed I've diagnosed this one. It will be fixed in the next cabal-install point release. > The following packages are still producing different results than with > ghc 6.8.2. Package maintainers are invited to look at them. > cabal-setup-1.2.1 > Hard: Cabal changes This package is deprecated. Its functionality is completely subsumed by cabal-install. Another point for implementing that hackage feature to tag packages as superseded. Duncan From jules at jellybean.co.uk Tue Oct 14 06:05:19 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Oct 14 06:01:21 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <48EF5CB8.902@gmail.com> References: <20081008200939.GA5675@matrix.chaos.earth.li> <6d74b0d20810100203n38582fffo2227e166514c3a81@mail.gmail.com> <48EF5CB8.902@gmail.com> Message-ID: <48F46EDF.7050304@jellybean.co.uk> Simon Marlow wrote: > Judah Jacobson wrote: > >> Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are >> not thrown in ghci, probably because it installs its own signal >> handlers: >> >> Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt >> -> putStrLn "Caught!") (threadDelay 2000000) >> ^CInterrupted. >> >> For consistency between the compiled and interpreted environments, it >> would be nice if the above could catch the ctrl-c. But maybe there's >> a reason not to do this? If this change sounds OK, I can take a look >> at this and try to put together a patch over the weekend. > > Hmm, tricky one. I agree with the argument for consistency, but on the > other hand you might also want a way to interrupt a computation > regardless, and that almost works - as long as the program isn't > discarding exceptions it knows nothing about. In my mind this is, at least thematically, related to http://hackage.haskell.org/trac/ghc/ticket/1399 that is, it relates to the various ways that running in ghci is different from running independently. To get a really good answer I think we need a couple of RTS enhancements, the ability to have a kind 'supervisor' mode etc... Jules From bulat.ziganshin at gmail.com Tue Oct 14 07:01:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Oct 14 06:57:46 2008 Subject: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible. In-Reply-To: <916b84820810140346o1e71c15bod02b9bd5edd1271@mail.gmail.com> References: <48F456FF.2060101@gmail.com> <916b84820810140212oc6a19f4ncd4ed3bac887d560@mail.gmail.com> <48F46874.2010404@gmail.com> <916b84820810140346o1e71c15bod02b9bd5edd1271@mail.gmail.com> Message-ID: <9010550814.20081014150114@gmail.com> Hello Thomas, Tuesday, October 14, 2008, 2:46:45 PM, you wrote: > The issue is binary compatibility. At the moment, GHC cannot make > sure that a library compiled with an older GHC can work with a newer > GHC. GHC does many cross-module optimisations, and its runtime system > changes occasionally, so it is very pessimistic in that regard. This > becomes an issue for packages that GHC has been build with itself > (like base, process, array), since these cannot be upgraded without > recompiling GHC (hence requiring recompiling every other package). is this correct? i was under impression that upgrading packages never require to recompile GHC itself. it just happen that we have only one version of base or array shipped with each GHC and at least with array this can be changed easily (and for base too - just noone plans to do it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From nominolo at googlemail.com Tue Oct 14 08:44:23 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Oct 14 08:40:23 2008 Subject: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible. In-Reply-To: <9010550814.20081014150114@gmail.com> References: <48F456FF.2060101@gmail.com> <916b84820810140212oc6a19f4ncd4ed3bac887d560@mail.gmail.com> <48F46874.2010404@gmail.com> <916b84820810140346o1e71c15bod02b9bd5edd1271@mail.gmail.com> <9010550814.20081014150114@gmail.com> Message-ID: <916b84820810140544l1cf8e09blcdf8e6d1097b7128@mail.gmail.com> 2008/10/14 Bulat Ziganshin : > Hello Thomas, > > Tuesday, October 14, 2008, 2:46:45 PM, you wrote: > >> The issue is binary compatibility. At the moment, GHC cannot make >> sure that a library compiled with an older GHC can work with a newer >> GHC. GHC does many cross-module optimisations, and its runtime system >> changes occasionally, so it is very pessimistic in that regard. This >> becomes an issue for packages that GHC has been build with itself >> (like base, process, array), since these cannot be upgraded without >> recompiling GHC (hence requiring recompiling every other package). > > is this correct? i was under impression that upgrading packages never > require to recompile GHC itself. it just happen that we have only one > version of base or array shipped with each GHC and at least with array > this can be changed easily (and for base too - just noone plans to do > it) Well, I was a bit imprecise. You can install a new array, but if you have a transitive dependency on the old array, this won't help. I'm not sure, but AFAIK the only thing that can introduce such a transitive dependency is the GHC API. So if you want to use the GHC API and a newer version of array in your program then you need to recompile ghc against the new array package. If you don't use the GHC API but want to use another package that has been compiled against array, you need to upgrade that other package, too. Modern versions of cabal-install should be able to do this where possible, but older ones (< 0.5, I think, Duncan knows) had problems with this. P.S.: I guess the moral of the story is that while cabal upgrade (no args) seems like a reasonable thing to do it is not yet very realiable. Many of these issues only became urgent because we now have such a powerful tool like cabal-install and we now have to add features to GHC, Cabal, and cabal-install to solve them. So, despite these unfortunate (and understandably frustrating) issues, we've come a long way since only 2 years ago, where every package had to be downloaded and installed manually using runghc Setup. P.P.S: Again, to the OP, please help us find out what exactly went wrong, so we can try to make sure that it won't happen again to you or anyone else. From dgorin at dc.uba.ar Tue Oct 14 10:27:12 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Oct 14 10:48:28 2008 Subject: gadt changes in ghc 6.10 Message-ID: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Hi After installing ghc 6.10-rc, I have a program that no longer compiles. I get the dreaded "GADT pattern match...." error, instead :) Here is a boiled-down example: {-# OPTIONS_GHC -XGADTs -XEmptyDataDecls #-} module T where data S data M data Wit t where S :: Wit S M :: Wit M data Impl t a where I1 :: Maybe a -> Impl S a I2 :: [a] -> Impl M a type W_ t a = Wit t -> Impl t a newtype W t a = Wrap (W_ t a) bind :: W t a -> (a -> W t b) -> W_ t b bind (Wrap w) f = \wit -> case wit of S -> case w S of I1 m -> I1 $ do a <- m case f a of Wrap w' -> case w' S of I1 m' -> m' M -> case w M of I2 m -> I2 $ do a <- m case f a of Wrap w' -> case w' M of I2 m' -> m' While in ghc 6.8.3 this compiles fine, with ghc 6.10 i get: $ ghc --make T.hs [1 of 1] Compiling T ( T.hs, T.o ) T.hs:26:57: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: I1 m' -> m' In the expression: case w' S of { I1 m' -> m' } In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } I've tried adding some signatures (together with - XScopedTypeVariables), but with no luck. Why is it that this no longer compiles? More importantly, how can I make it compile again? :) Thanks! Daniel From dons at galois.com Tue Oct 14 17:48:11 2008 From: dons at galois.com (Don Stewart) Date: Tue Oct 14 17:44:11 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Message-ID: <20081014214811.GQ29174@scytale.galois.com> dgorin: > I've tried adding some signatures (together with - > XScopedTypeVariables), but with no luck. Why is it that this no longer > compiles? More importantly, how can I make it compile again? :) > If you work out how to make it compile, can you document the soln. here, http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching Cheers, Don From dgorin at dc.uba.ar Tue Oct 14 20:08:22 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Oct 14 20:04:32 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: <20081014214811.GQ29174@scytale.galois.com> References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> <20081014214811.GQ29174@scytale.galois.com> Message-ID: <0452E6A0-1B9D-4E77-9678-020B6E32AFCA@dc.uba.ar> On Oct 14, 2008, at 7:48 PM, Don Stewart wrote: > dgorin: >> I've tried adding some signatures (together with - >> XScopedTypeVariables), but with no luck. Why is it that this no >> longer >> compiles? More importantly, how can I make it compile again? :) >> > > If you work out how to make it compile, can you document the soln. > here, > > http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching > > Cheers, > Don Sure, but I must say I'm still kind of lost, here.... From dagit at codersbase.com Tue Oct 14 20:19:10 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Oct 14 20:15:09 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Message-ID: On Tue, Oct 14, 2008 at 7:27 AM, Daniel Gor?n wrote: > Hi > > After installing ghc 6.10-rc, I have a program that no longer compiles. I > get the dreaded "GADT pattern match...." error, instead :) > > Here is a boiled-down example: > > {-# OPTIONS_GHC -XGADTs -XEmptyDataDecls #-} > module T where > > data S > data M > > data Wit t where > S :: Wit S > M :: Wit M > > data Impl t a where > I1 :: Maybe a -> Impl S a > I2 :: [a] -> Impl M a > > type W_ t a = Wit t -> Impl t a > > newtype W t a = Wrap (W_ t a) > > bind :: W t a -> (a -> W t b) -> W_ t b > bind (Wrap w) f = \wit -> > case wit of > S -> case w S of > I1 m -> I1 $ do a <- m > case f a of > Wrap w' -> case w' S of > I1 m' -> m' > M -> case w M of > I2 m -> I2 $ do a <- m > case f a of > Wrap w' -> case w' M of > I2 m' -> m' > > While in ghc 6.8.3 this compiles fine, with ghc 6.10 i get: > > $ ghc --make T.hs > [1 of 1] Compiling T ( T.hs, T.o ) > > T.hs:26:57: > GADT pattern match with non-rigid result type `Maybe a' > Solution: add a type signature > In a case alternative: I1 m' -> m' > In the expression: case w' S of { I1 m' -> m' } > In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } I don't have 6.10 handy to try out your program, but in 6.8 and older the type error message you're getting means that the compiler needs more "outside in" help with type checking this. Usually this means adding type more type signatures on the outside. For example, maybe you need to give the type signatures inside the case to make the types inside the pattern matches of the case more rigid. That probably didn't make a lot of sense :( So here is an example, case wit :: {- Try adding a signature here -} of ... Given that your code has such deep pattern nesting I would argue that it is in your best interest to add local functions (in a where clause) along with their explicit type signatures. Start with the inner most case expressions and convert those to local functions and work your way out. I've tried adding some signatures (together with -XScopedTypeVariables), but > with no luck. Why is it that this no longer compiles? More importantly, how > can I make it compile again? :) I think adding local functions is easier than randomly sprinkling in the type signatures. It has a nice side-effect that your new code is often easier to read as well. Good luck! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081014/ec6e2086/attachment.htm From dgorin at dc.uba.ar Tue Oct 14 21:37:04 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Oct 14 21:33:11 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Message-ID: On Oct 14, 2008, at 10:19 PM, Jason Dagit wrote: > > On Tue, Oct 14, 2008 at 7:27 AM, Daniel Gor?n > wrote: > Hi > > After installing ghc 6.10-rc, I have a program that no longer > compiles. I get the dreaded "GADT pattern match...." error, instead :) > > Here is a boiled-down example: > [...] > > I don't have 6.10 handy to try out your program, but in 6.8 and > older the type error message you're getting means that the compiler > needs more "outside in" help with type checking this. > > Usually this means adding type more type signatures on the outside. > For example, maybe you need to give the type signatures inside the > case to make the types inside the pattern matches of the case more > rigid. That probably didn't make a lot of sense :( So here is an > example, > > case wit :: {- Try adding a signature here -} of ... > > Given that your code has such deep pattern nesting I would argue > that it is in your best interest to add local functions (in a where > clause) along with their explicit type signatures. Start with the > inner most case expressions and convert those to local functions and > work your way out. > > I've tried adding some signatures (together with - > XScopedTypeVariables), but with no luck. Why is it that this no > longer compiles? More importantly, how can I make it compile again? :) > > I think adding local functions is easier than randomly sprinkling in > the type signatures. It has a nice side-effect that your new code > is often easier to read as well. > > Good luck! > Jason Thanks for the advice! By using some auxiliary functions I can now compile an alternative version of the program. And although the resulting program is more clear, I'd still like to know if this can be achieved be adding only annotations to the original program. The reason for this is that, for performance reasons, I depend on the case-of-case transformation removing every possible case construct. I already verified this is happening for the original program and I rather keep the code as is than browse through the generated core again :) I must say that I also found this thread to be very helpful: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15153 I'll make sure the wiki points to it. For the record the resulting code is this: {-# LANGUAGE GADTs, EmptyDataDecls #-} module T where data S data M data Wit t where S :: Wit S M :: Wit M data Impl t a where I1 :: Maybe a -> Impl S a I2 :: [a] -> Impl M a type W_ t a = Wit t -> Impl t a newtype W t a = Wrap (W_ t a) unWrap1 :: Impl S a -> Maybe a unWrap1 (I1 m) = m unWrap2 :: Impl M a -> [a] unWrap2 (I2 m) = m bind :: W t a -> (a -> W t b) -> W_ t b bind (Wrap w) f = \wit -> case wit of S -> I1 $ do a <- unWrap1 (w S) case (f a) of Wrap w' -> unWrap1 (w' S) M -> I2 $ do a <- unWrap2 (w M) case (f a) of Wrap w' -> unWrap2 (w' M) Bye Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081014/f4d537f3/attachment.htm From dagit at codersbase.com Tue Oct 14 22:31:54 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Oct 14 22:27:52 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Message-ID: On Tue, Oct 14, 2008 at 6:37 PM, Daniel Gor?n wrote: > > On Oct 14, 2008, at 10:19 PM, Jason Dagit wrote: > > > On Tue, Oct 14, 2008 at 7:27 AM, Daniel Gor?n wrote: > >> Hi >> >> After installing ghc 6.10-rc, I have a program that no longer compiles. I >> get the dreaded "GADT pattern match...." error, instead :) >> >> Here is a boiled-down example: > > [...] > > > I don't have 6.10 handy to try out your program, but in 6.8 and older the > type error message you're getting means that the compiler needs more > "outside in" help with type checking this. > > Usually this means adding type more type signatures on the outside. For > example, maybe you need to give the type signatures inside the case to make > the types inside the pattern matches of the case more rigid. That probably > didn't make a lot of sense :( So here is an example, > > case wit :: {- Try adding a signature here -} of ... > > Given that your code has such deep pattern nesting I would argue that it is > in your best interest to add local functions (in a where clause) along with > their explicit type signatures. Start with the inner most case expressions > and convert those to local functions and work your way out. > > I've tried adding some signatures (together with -XScopedTypeVariables), >> but with no luck. Why is it that this no longer compiles? More importantly, >> how can I make it compile again? :) > > > I think adding local functions is easier than randomly sprinkling in the > type signatures. It has a nice side-effect that your new code is often > easier to read as well. > > Good luck! > Jason > > > Thanks for the advice! > > By using some auxiliary functions I can now compile an alternative version > of the program. And although the resulting program is more clear, I'd still > like to know if this can be achieved be adding only annotations to the > original program. The reason for this is that, for performance reasons, I > depend on the case-of-case transformation removing every possible case > construct. I already verified this is happening for the original program and > I rather keep the code as is than browse through the generated core again :) > It's unfortunate that you have such a situation with the optimizer. How often do you check that the optimizer is still smart enough? It seems like the sort of thing that could easily break between compiler releases. If you are going to depend on, I wonder if you could write a test to ensure that it is happening every time. > > I must say that I also found this thread to be very helpful: > > http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15153 > That is a good thread and it helped me a lot in the past too. One of the most important bits is when Simon says this: GHC now enforces the rule that in a GADT pattern match - the type of the scrutinee must be rigid - the result type must be rigid - the type of any variable free in the case branch must be rigid I would hypothesize that most people who encounter the message you're getting fall into the last case, but I may be biased by my own experiences. > > > I'll make sure the wiki points to it. > Oh, good idea! Thanks! > > For the record the resulting code is this: > > {-# LANGUAGE GADTs, EmptyDataDecls #-} > module T where > > data S > data M > > data Wit t where > S :: Wit S > M :: Wit M > > data Impl t a where > I1 :: Maybe a -> Impl S a > I2 :: [a] -> Impl M a > > type W_ t a = Wit t -> Impl t a > > newtype W t a = Wrap (W_ t a) > > unWrap1 :: Impl S a -> Maybe a > unWrap1 (I1 m) = m > > unWrap2 :: Impl M a -> [a] > unWrap2 (I2 m) = m > > bind :: W t a -> (a -> W t b) -> W_ t b > bind (Wrap w) f = \wit -> > case wit of > S -> I1 $ do a <- unWrap1 (w S) > case (f a) of > Wrap w' -> unWrap1 (w' S) > M -> I2 $ do a <- unWrap2 (w M) > case (f a) of > Wrap w' -> unWrap2 (w' M) > > My (untested) hunch is that, Wrap w', needs a type signature in your original version. I think this because of the 3rd case I mentioned above. It would seem that your unWrap1 and unWrap2 fix the witness type, either S or M. Without playing with it (and again I don't have 6.10 handy), I'm not sure which side of the arrow needs the type signature. It could be that you need something like: Wrap (w' :: A type signature fixing M or S) Or, you need it on the other side: Wrap w' -> (w' :: some type sig) M Either way, I think think the type t needs to be mentioned somewhere. Good luck and let me know what you figure out, I'm quite curious now. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081014/a1662df5/attachment-0001.htm From chak at cse.unsw.edu.au Wed Oct 15 02:43:58 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Oct 15 02:40:06 2008 Subject: Illegal type synonym family application in instance (Was: Breakage with 6.10) In-Reply-To: References: <49a77b7a0810101853j79b1ac3dh5c4e4b316b9dbcbb@mail.gmail.com> Message-ID: <02E09FFC-D302-4788-B304-9C70643A378B@cse.unsw.edu.au> Niklas Broberg: > On 10/11/08, David Menendez wrote: >> On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg >> wrote: >>> src\HSX\XMLGenerator.hs:71:0 >>> Illegal type synonym family application in instance: XML m >>> In the instance declaration for `EmbedAsChild m (XML m)? >>> --------------- >>> >>> Could someone help me point out the problem here? The relevant >>> code is: >>> >>> instance XMLGen m => EmbedAsChild m (XML m) where >>> asChild = return . return . xmlToChild >>> >>> class XMLGen m => EmbedAsChild m c where >>> asChild :: c -> GenChildList m >>> >>> class Monad m => XMLGen m where >>> type XML m >>> .... >>> >>> This works fine with 6.8.3, so what's new in 6.10, and what would >>> I do >>> to solve it? >> >> >> I'm guessing there was a bug in 6.8.3 that allowed this. (The >> implementation of type families is present but not supported in 6.8, >> presumably because of problems like this.) >> >> I don't have 6.10, so I can't test anything, but you might try >> rewriting the EmbedAsChild instances like so: >> >> instance (XMLGen m, XML m ~ x) => EmbedAsChild m x where ... > > Thanks a lot David, that's indeed what I needed. > > I'm not sure I see why the style I used previously was illegal though, > it seemed perfectly natural to me. And it works that way for > `EmbedAsChild m (Child m)?, where `Child m? is a data type family and > not a synonym, so why not for a synonym too? But hey, as long as > there's a way to do what I want. :-) As suggested, it was a bug in 6.8.3 that you could make a class instance where the head involved a type synonym family. We cannot allow synonym families in class instances heads as it is impossible to check for overlap of such instances; eg, consider type family F a type instance F Bool = Int class C a instance C Int instance C (F a) Now a context (C (F Bool)) would match both instances. This is especially bad, as the type instance for F Bool may be defined in a different module as the instances for C; so, it is even in principle impossible to check for such overlap. The situation is different for data families as they are data types and not type synonyms. Moreover, instance (XMLGen m, XML m ~ x) => EmbedAsChild m x where ... is fine as it clearly overlaps with any other instance of EmbedAsChild. I hope that clarifies the situation. Manuel From simonpj at microsoft.com Wed Oct 15 04:22:01 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 15 04:18:05 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A795A8@EA-EXMSG-C334.europe.corp.microsoft.com> | After installing ghc 6.10-rc, I have a program that | no longer compiles. I get the dreaded "GADT pattern match...." | error, instead :) I'm sorry it's dreaded! Jason is right that the key point is this: GHC now enforces the rule that in a GADT pattern match - the type of the scrutinee must be rigid - the result type must be rigid - the type of any variable free in the case branch must be rigid In your case the error message was: GADT.hs:26:56: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: I1 m' -> m' In the expression: case w' S of { I1 m' -> m' } In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } So it's the result type of the entire case match that isn't rigid. Where does that result type come from... ah .. from a do-expression, which itself is the argument of $, which is also applied to I1. That's too hard for GHC to figure out. You need to specify the result type yourself. I've done so in the program below. I've added -XScopedTypeVariables so that I can give the signature. The relevant signatures themselves are marked --- NB ---. I've wrapped them around the entire do-expression, but it'd also be fine to have put them further "in" around the case expression itself. In this program it's not an ideal place to put a type signature because it looks a bit lost at the bottom. I hope this helps. I'm still trying to find a really good way to explain the reasoning here. Do pls augment the wiki page with what you have learned! Simon {-# OPTIONS_GHC -XGADTs -XEmptyDataDecls -XScopedTypeVariables #-} module T where data S data M data Wit t where S :: Wit S M :: Wit M data Impl t a where I1 :: Maybe a -> Impl S a I2 :: [a] -> Impl M a type W_ t a = Wit t -> Impl t a newtype W t a = Wrap (W_ t a) bind :: forall a b t. W t a -> (a -> W t b) -> W_ t b ------- the forall brings a,b,t into scope inside bind bind (Wrap w) f = \wit -> case wit of S -> case w S of I1 m -> I1 (do a <- m case f a of Wrap w' -> case w' S of I1 m' -> m' :: Maybe b) --- NB -------- M -> case w M of I2 m -> I2 (do a <- m case f a of Wrap w' -> case w' M of I2 m' -> m' :: [b]) --- NB -------- From twhitehead at gmail.com Wed Oct 15 10:35:32 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Oct 15 10:31:35 2008 Subject: Strictness in data declaration not matched in assembler? Message-ID: <200810151035.32269.twhitehead@gmail.com> Consider the following code data Data = Data { unData :: !Int } func :: Data -> Int func x = case unData x of 1 -> 2 _ -> 0 Compiling with GHC 6.8.2 gives the following stg code Main.func = \r [x_slg] case x_slg of tpl_slx { Main.Data ipv_slj -> case ipv_slj of wild_sly { GHC.Base.I# ds_slm -> case ds_slm of ds1_slz { __DEFAULT -> Main.lvl1; 1 -> Main.lvl; }; }; }; The native code generator turns it into the following x86_64 assembler Main_func_info: leaq -8(%rbp),%rax cmpq %r14,%rax jb .LcnU movq %rsi,%rbx movq $sni_info,-8(%rbp) addq $-8,%rbp testq $7,%rbx jne sni_info jmp *(%rbx) .LcnU: movl $Main_func_closure,%ebx jmp *-8(%r13) sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) snj_info: cmpq $1,7(%rbx) jne .LcnE movl $Main_lvl_closure+1,%ebx addq $8,%rbp jmp *(%rbp) .LcnE: movl $Main_lvl1_closure+1,%ebx addq $8,%rbp jmp *(%rbp) It seems to me that the !Int member of the Data constructor is being treated like it might be a thunk in sni_info (i.e., the whole "testq $7,%rbx" thing). Isn't this unnecessary as the "!" strictness flag means the Int argument must be forced by the Data constructor before being captured? Thanks! -Tyson From jules at jellybean.co.uk Wed Oct 15 10:48:26 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Oct 15 10:44:24 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <200810151035.32269.twhitehead@gmail.com> References: <200810151035.32269.twhitehead@gmail.com> Message-ID: <48F602BA.5010802@jellybean.co.uk> Tyson Whitehead wrote: > It seems to me that the !Int member of the Data constructor is being treated > like it might be a thunk in sni_info (i.e., the whole "testq $7,%rbx" thing). > > Isn't this unnecessary as the "!" strictness flag means the Int argument must > be forced by the Data constructor before being captured? Strictness does not imply unboxing. To see why not, think about the fact that unboxing breaks sharing. By keeping the pointer-indirection in place, we can share even strict fields between related values. Try -funbox-strict-fields or the UNBOX pragma. Jules From twhitehead at gmail.com Wed Oct 15 10:58:47 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Oct 15 10:54:46 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <48F602BA.5010802@jellybean.co.uk> References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> Message-ID: <200810151058.47528.twhitehead@gmail.com> On Wednesday 15 October 2008 10:48:26 you wrote: > Strictness does not imply unboxing. > > To see why not, think about the fact that unboxing breaks sharing. By > keeping the pointer-indirection in place, we can share even strict > fields between related values. I believe I realize that. What I was wondering about was the fact that it seemed to think the pointer might be to a thunk (instead of constructor closure). Doesn't the strictness flag mean the following assembler would work sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) jmp snj_info (which could be cleaned up further by combining it with snj_info) instead of sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) (i.e., the whole test if it is a thunk and conditionally evaluate it bit is unnecessary due to constructor the strictness flag). Cheers! -Tyson From lennart at augustsson.net Wed Oct 15 11:08:57 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Oct 15 11:04:54 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <200810151058.47528.twhitehead@gmail.com> References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> Message-ID: I totally agree. Getting the value of the field should just evaluate x and then use a pointer indirection; there should be no conditional jumps involved in getting the value. GHC is just doing the wrong thing. -- Lennart On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead wrote: > On Wednesday 15 October 2008 10:48:26 you wrote: >> Strictness does not imply unboxing. >> >> To see why not, think about the fact that unboxing breaks sharing. By >> keeping the pointer-indirection in place, we can share even strict >> fields between related values. > > I believe I realize that. What I was wondering about was the fact that it > seemed to think the pointer might be to a thunk (instead of constructor > closure). Doesn't the strictness flag mean the following assembler would work > > sni_info: > movq 7(%rbx),%rbx > movq $snj_info,(%rbp) > jmp snj_info > > (which could be cleaned up further by combining it with snj_info) instead of > > sni_info: > movq 7(%rbx),%rbx > movq $snj_info,(%rbp) > testq $7,%rbx > jne snj_info > jmp *(%rbx) > > (i.e., the whole test if it is a thunk and conditionally evaluate it bit is > unnecessary due to constructor the strictness flag). > > Cheers! -Tyson > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From jmaessen at alum.mit.edu Wed Oct 15 11:21:39 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Oct 15 11:17:39 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> Message-ID: <7FEEE3DC-EA31-4B60-9F05-B1A558E0AE79@alum.mit.edu> On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote: > I totally agree. Getting the value of the field should just evaluate > x and then use a pointer indirection; there should be no conditional > jumps involved in getting the value. > GHC is just doing the wrong thing. Can indirection nodes occur in this context? [I'd think not, but it depends on what pointer we're storing when we force the thunk in the constructor.] I could see the need for the test if indirection handling is required. -Jan > -- Lennart > > On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead > wrote: >> On Wednesday 15 October 2008 10:48:26 you wrote: >>> Strictness does not imply unboxing. >>> >>> To see why not, think about the fact that unboxing breaks sharing. >>> By >>> keeping the pointer-indirection in place, we can share even strict >>> fields between related values. >> >> I believe I realize that. What I was wondering about was the fact >> that it >> seemed to think the pointer might be to a thunk (instead of >> constructor >> closure). Doesn't the strictness flag mean the following assembler >> would work >> >> sni_info: >> movq 7(%rbx),%rbx >> movq $snj_info,(%rbp) >> jmp snj_info >> >> (which could be cleaned up further by combining it with snj_info) >> instead of >> >> sni_info: >> movq 7(%rbx),%rbx >> movq $snj_info,(%rbp) >> testq $7,%rbx >> jne snj_info >> jmp *(%rbx) >> >> (i.e., the whole test if it is a thunk and conditionally evaluate >> it bit is >> unnecessary due to constructor the strictness flag). >> >> Cheers! -Tyson >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lennart at augustsson.net Wed Oct 15 11:42:24 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Oct 15 11:38:23 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <7FEEE3DC-EA31-4B60-9F05-B1A558E0AE79@alum.mit.edu> References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> <7FEEE3DC-EA31-4B60-9F05-B1A558E0AE79@alum.mit.edu> Message-ID: True, if there can be indirections then that's bad news. That would make strict fields much less efficient. But I don't see why indirections should be needed. Simon? On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen wrote: > > On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote: > >> I totally agree. Getting the value of the field should just evaluate >> x and then use a pointer indirection; there should be no conditional >> jumps involved in getting the value. >> GHC is just doing the wrong thing. > > Can indirection nodes occur in this context? [I'd think not, but it depends > on what pointer we're storing when we force the thunk in the constructor.] > I could see the need for the test if indirection handling is required. > > -Jan > >> -- Lennart >> >> On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead >> wrote: >>> >>> On Wednesday 15 October 2008 10:48:26 you wrote: >>>> >>>> Strictness does not imply unboxing. >>>> >>>> To see why not, think about the fact that unboxing breaks sharing. By >>>> keeping the pointer-indirection in place, we can share even strict >>>> fields between related values. >>> >>> I believe I realize that. What I was wondering about was the fact that >>> it >>> seemed to think the pointer might be to a thunk (instead of constructor >>> closure). Doesn't the strictness flag mean the following assembler would >>> work >>> >>> sni_info: >>> movq 7(%rbx),%rbx >>> movq $snj_info,(%rbp) >>> jmp snj_info >>> >>> (which could be cleaned up further by combining it with snj_info) instead >>> of >>> >>> sni_info: >>> movq 7(%rbx),%rbx >>> movq $snj_info,(%rbp) >>> testq $7,%rbx >>> jne snj_info >>> jmp *(%rbx) >>> >>> (i.e., the whole test if it is a thunk and conditionally evaluate it bit >>> is >>> unnecessary due to constructor the strictness flag). >>> >>> Cheers! -Tyson >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bos at serpentine.com Wed Oct 15 13:28:39 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Oct 15 13:24:35 2008 Subject: breakage with Cabal-1.6 In-Reply-To: <48F30DBF.2080900@gmail.com> References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> <48EF7137.9000903@gmail.com> <1223749192.6878.325.camel@dell.linuxdev.us.dell.com> <48F30DBF.2080900@gmail.com> Message-ID: On Mon, Oct 13, 2008 at 1:58 AM, Simon Marlow wrote: > Thanks! New versions of Alex & Happy uploaded. Where to? I only see 2.3 on Hackage, and haskell.org claims that Alex is still at 2.2. From bertram.felgenhauer at googlemail.com Wed Oct 15 14:13:41 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed Oct 15 14:09:43 2008 Subject: 2008-10-13 Hackage status with GHC 6.10 release candidate In-Reply-To: <20081014050842.GB25748@scytale.galois.com> References: <20081014050842.GB25748@scytale.galois.com> Message-ID: <20081015181341.GB4231@zombie.inf.tu-dresden.de> Don Stewart wrote: [snip] > hetris-0.2 > Easy: header macros/-fvia-C The real culprit here was hscurses. There's a new version on hackage now (sanctioned by Stefan Wehr), so this should be fixed. Bertram From dgorin at dc.uba.ar Wed Oct 15 14:21:16 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Wed Oct 15 14:17:24 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76A795A8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> <638ABD0A29C8884A91BC5FB5C349B1C32D76A795A8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <3BE3F0F9-25CF-4A67-8942-D5082243885A@dc.uba.ar> Hi, Simon Thanks a lot for your mail. It turns out I could have resolved this by myself (with the help of this thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15153 , to be honest). What I was missing was this key part: > bind :: forall a b t. W t a -> (a -> W t b) -> W_ t b > ------- the forall brings a,b,t into scope inside bind So, while I had turned on the ScopedTypeVariables extension, none of the type variables in question was actually in scope. How embarrassing! I can't blame anyone but me for this but, anyway, I feel that it may have helped me if the introduction of Section 8.7.6 of the user manual were a little more explicit about this. Although the example reads "f :: forall a. [a] -> [a]", and the text below says "The type signature for f brings the type variable into scope", the role of the "forall" is not mentioned until Section 8.7.6.2 (and since I already knew what the extension was about, and was only looking for the proper extension name, I didn't make it that far :)) Also, since you are always willing to get examples of confusing error messages, I wanted to bring this one into attention: > In your case the error message was: > > GADT.hs:26:56: > GADT pattern match with non-rigid result type `Maybe a' > Solution: add a type signature > In a case alternative: I1 m' -> m' > In the expression: case w' S of { I1 m' -> m' } > In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } > This is when ScopedTypeVariables is off. Now, what I found very confusing at first is that I thought the "a" in 'Maybe a' was referring to the "a" in 'W t a -> (a -> W t b) -> W_ t b', and I couldn't see how that could be happening. Once ScopedTypeVariables is on, one gets 'GADT pattern match with non-rigid result type `Maybe a1'" and everything makes more sense :) And maybe the "add a type signature" can be more explicit? Like "add a type signature that makes the type of the result known at the matching point". Just a suggestion... > I hope this helps. I'm still trying to find a really good way to > explain the reasoning here. Do pls augment the wiki page with what > you have learned! > I've put some of this in the "Upgrading packages" wiki, and added a link to the previous thread which I found to be very clear. Thanks again! Daniel From dons at galois.com Wed Oct 15 18:22:10 2008 From: dons at galois.com (Don Stewart) Date: Wed Oct 15 18:17:51 2008 Subject: [Haskell-cafe] 2008-10-13 Hackage status with GHC 6.10 release candidate In-Reply-To: <48F662BB.2090904@henning-thielemann.de> References: <20081014050842.GB25748@scytale.galois.com> <48F662BB.2090904@henning-thielemann.de> Message-ID: <20081015222210.GB1320@scytale.galois.com> schlepptop: > Don Stewart schrieb: > > > numeric-prelude-0.0.4 > > Easy: Lanuage pragma > > My question was still not answered: I used the non-existing pragma > LANGUAGE_HOW_CAN_WE_ENABLE - I hoped it would be ignored, but it was > parsed and made GHC fail. Why? Bug or feature? > > Feature. {-# #-} language-y pragmas are parsed now. Check with GHC HQ for details. -- Don From dons at galois.com Wed Oct 15 19:12:13 2008 From: dons at galois.com (Don Stewart) Date: Wed Oct 15 19:07:54 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <200810151035.32269.twhitehead@gmail.com> References: <200810151035.32269.twhitehead@gmail.com> Message-ID: <20081015231213.GG1320@scytale.galois.com> twhitehead: > Consider the following code > > data Data = Data { unData :: !Int } > > func :: Data -> Int > func x = case unData x of > 1 -> 2 > _ -> 0 > > Compiling with GHC 6.8.2 gives the following stg code > > Main.func = > \r [x_slg] > case x_slg of tpl_slx { > Main.Data ipv_slj -> > case ipv_slj of wild_sly { > GHC.Base.I# ds_slm -> > case ds_slm of ds1_slz { > __DEFAULT -> Main.lvl1; > 1 -> Main.lvl; > }; > }; > }; Note that using -funbox-strict-fields helps, A.func :: A.Data -> Int A.func = \ (x_afx :: A.Data) -> case x_afx of tpl_B2 { A.Data rb_B4 -> case rb_B4 of ds_Xg7 { __DEFAULT -> A.lvl1 1 -> A.lvl } } No I#. I'd expect if 'func' was inlined, for the return to be unboxed as well. -- Don From marlowsd at gmail.com Thu Oct 16 04:00:49 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 16 03:56:52 2008 Subject: breakage with Cabal-1.6 In-Reply-To: References: <1223578545.6878.76.camel@dell.linuxdev.us.dell.com> <48EF7137.9000903@gmail.com> <1223749192.6878.325.camel@dell.linuxdev.us.dell.com> <48F30DBF.2080900@gmail.com> Message-ID: <48F6F4B1.1010508@gmail.com> Bryan O'Sullivan wrote: > On Mon, Oct 13, 2008 at 1:58 AM, Simon Marlow wrote: > >> Thanks! New versions of Alex & Happy uploaded. > > Where to? I only see 2.3 on Hackage, and haskell.org claims that Alex > is still at 2.2. Just on Hackage for the time being, I'll update the web pages after a bit of testing. There's already been a fix to Happy since I uploaded 1.18. Cheers, Simon From marlowsd at gmail.com Thu Oct 16 06:14:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Oct 16 06:10:23 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> <7FEEE3DC-EA31-4B60-9F05-B1A558E0AE79@alum.mit.edu> Message-ID: <48F713FE.2080200@gmail.com> Lennart Augustsson wrote: > True, if there can be indirections then that's bad news. > That would make strict fields much less efficient. > But I don't see why indirections should be needed. Simon? This kind of thing has always been a problem for GHC, and IIRC hbc does/did better here. I don't know for sure whether we guarantee not to point to an indirection from a strict constructur field. I imagine it wouldn't be hard to arrange, but it is another invariant we'd have to maintain throughout the Core->Core phases. The real problem is that strictness is not represented in the type system, so we have no way to check that these kind of invariants are being respected. Cheers, Simon > On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen > wrote: >> On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote: >> >>> I totally agree. Getting the value of the field should just evaluate >>> x and then use a pointer indirection; there should be no conditional >>> jumps involved in getting the value. >>> GHC is just doing the wrong thing. >> Can indirection nodes occur in this context? [I'd think not, but it depends >> on what pointer we're storing when we force the thunk in the constructor.] >> I could see the need for the test if indirection handling is required. >> >> -Jan >> >>> -- Lennart >>> >>> On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead >>> wrote: >>>> On Wednesday 15 October 2008 10:48:26 you wrote: >>>>> Strictness does not imply unboxing. >>>>> >>>>> To see why not, think about the fact that unboxing breaks sharing. By >>>>> keeping the pointer-indirection in place, we can share even strict >>>>> fields between related values. >>>> I believe I realize that. What I was wondering about was the fact that >>>> it >>>> seemed to think the pointer might be to a thunk (instead of constructor >>>> closure). Doesn't the strictness flag mean the following assembler would >>>> work >>>> >>>> sni_info: >>>> movq 7(%rbx),%rbx >>>> movq $snj_info,(%rbp) >>>> jmp snj_info >>>> >>>> (which could be cleaned up further by combining it with snj_info) instead >>>> of >>>> >>>> sni_info: >>>> movq 7(%rbx),%rbx >>>> movq $snj_info,(%rbp) >>>> testq $7,%rbx >>>> jne snj_info >>>> jmp *(%rbx) >>>> >>>> (i.e., the whole test if it is a thunk and conditionally evaluate it bit >>>> is >>>> unnecessary due to constructor the strictness flag). >>>> >>>> Cheers! -Tyson >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Thu Oct 16 06:34:39 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 16 06:30:34 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> | I totally agree. Getting the value of the field should just evaluate | x and then use a pointer indirection; there should be no conditional | jumps involved in getting the value. | GHC is just doing the wrong thing. You're right. As Simon says, GHC's Core language has no type distinction between an Int that is evaluated and an Int that might be a thunk, so we generate conservative code. However, even for strict functions we do not *guarantee* to pass evaluated arguments. Consider f x y = if y==0 then g x else 0 g x = x+1 Here g is strict, but f is not (in x). The code that GHC generates for 'f' simply passes 'x' along to 'g'. It does not evaluate 'x' and then pass it. So the fact that 'g' is strict is used to *allow* the caller to use call by value; it does not *require* the caller to do so. So that means that 'g' cannot rely on getting an evaluated argument. One could change that, but that's the way it is right now. For strict *constructors*, on the other hand, we *do* guarantee to evaluate the argument before building the constructor. We generate a wrapper thus wC = \ab. case a of { a' -> C a' b } (Remember 'case' always evaluates in Core.) So for strict constructors we could take advantage of the known evaluated-ness of the result to avoid the test. BUT people who care probably UNPACK their strict fields too, which is even better. The time you can't do that is for sum types data T = MkT ![Int] Whether this case is important enough to be worth the complexity cost, I'm not sure. If someone felt like creating a ticket for this thread, and pasting in the payload of the messages, that'd help us not to forget it. As of now, it doesn't look like a terribly big win to me. But I could be wrong -- intuition is not always a good guide. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Lennart Augustsson | Sent: 15 October 2008 16:09 | To: Tyson Whitehead | Cc: GHC users | Subject: Re: Strictness in data declaration not matched in assembler? | | I totally agree. Getting the value of the field should just evaluate | x and then use a pointer indirection; there should be no conditional | jumps involved in getting the value. | GHC is just doing the wrong thing. | | -- Lennart | | On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead wrote: | > On Wednesday 15 October 2008 10:48:26 you wrote: | >> Strictness does not imply unboxing. | >> | >> To see why not, think about the fact that unboxing breaks sharing. By | >> keeping the pointer-indirection in place, we can share even strict | >> fields between related values. | > | > I believe I realize that. What I was wondering about was the fact that it | > seemed to think the pointer might be to a thunk (instead of constructor | > closure). Doesn't the strictness flag mean the following assembler would work | > | > sni_info: | > movq 7(%rbx),%rbx | > movq $snj_info,(%rbp) | > jmp snj_info | > | > (which could be cleaned up further by combining it with snj_info) instead of | > | > sni_info: | > movq 7(%rbx),%rbx | > movq $snj_info,(%rbp) | > testq $7,%rbx | > jne snj_info | > jmp *(%rbx) | > | > (i.e., the whole test if it is a thunk and conditionally evaluate it bit is | > unnecessary due to constructor the strictness flag). | > | > Cheers! -Tyson | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From rl at cse.unsw.edu.au Thu Oct 16 07:03:05 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Oct 16 06:59:32 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 16/10/2008, at 21:34, Simon Peyton-Jones wrote: > For strict *constructors*, on the other hand, we *do* guarantee to > evaluate the argument before building the constructor. We generate > a wrapper thus > wC = \ab. case a of { a' -> C a' b } > (Remember 'case' always evaluates in Core.) So for strict > constructors we could take advantage of the known evaluated-ness of > the result to avoid the test. > > BUT people who care probably UNPACK their strict fields too, which > is even better. The time you can't do that is for sum types > data T = MkT ![Int] You also can't do it for polymorphic components. I've used code like: data T a = MkT !a foo :: T (a,b) -> a foo (MkT (x,y)) = x Here, unpacking doesn't work but foo could still access the components of the pair directly. Roman From simonpj at microsoft.com Thu Oct 16 07:04:30 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 16 07:00:39 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: References: <200810151035.32269.twhitehead@gmail.com> <48F602BA.5010802@jellybean.co.uk> <200810151058.47528.twhitehead@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA3F2@EA-EXMSG-C334.europe.corp.microsoft.com> | > BUT people who care probably UNPACK their strict fields too, which | > is even better. The time you can't do that is for sum types | > data T = MkT ![Int] | | You also can't do it for polymorphic components. I've used code like: | | data T a = MkT !a | | foo :: T (a,b) -> a | foo (MkT (x,y)) = x | | Here, unpacking doesn't work but foo could still access the components | of the pair directly. Excellent point Roman. S From twhitehead at gmail.com Thu Oct 16 11:49:02 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu Oct 16 11:45:00 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: References: <200810151035.32269.twhitehead@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200810161149.02873.twhitehead@gmail.com> On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote: > On 16/10/2008, at 21:34, Simon Peyton-Jones wrote: > > BUT people who care probably UNPACK their strict fields too, which > > is even better. The time you can't do that is for sum types > > data T = MkT ![Int] > > You also can't do it for polymorphic components. I've used code like: > > data T a = MkT !a > > foo :: T (a,b) -> a > foo (MkT (x,y)) = x > > Here, unpacking doesn't work but foo could still access the components > of the pair directly. This is actually the situation I was originally looking at. I just simplified it for the sake of posting readable core and assembler. Specifically, I was looking at some of the assembler GHC was generating for some array code to see if it could do a clean enough job to be used instead of C, and was finding this sort of thing because STUArrau is defined as data STUArray s i a = STUArray !i !i !Int (MutableByteArray# s) I also seem to recall seeing the same sort of thing in some of the state code I was also looking at because STRep is defined as type STRep s a = State# s -> (# State# s, a #) (the a being the issue here). With regard to cost, it is probably not that representative, but a typical code path for the toy example I posted earlier goes from leaq -8(%rbp),%rax cmpq %r14,%rax -- not taken jump -- (stack overflow check passed) movq %rsi,%rbx movq $sni_info,-8(%rbp) addq $-8,%rbp testq $7,%rbx -- taken jump -- (x argument had already been forced) movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx -- taken jump -- (strict constructor argument is already forced) cmpq $1,7(%rbx) -- not taken jump -- (first of the case options) movl $Main_lvl_closure+1,%ebx addq $8,%rbp jmp *(%rbp) to leaq -8(%rbp),%rax cmpq %r14,%rax -- not taken jump -- (stack overflow check passed) movq %rsi,%rbx movq $sni_info,-8(%rbp) addq $-8,%rbp testq $7,%rbx -- taken jump -- (x argument has already been forced) movq 7(%rbx),%rbx cmpq $1,7(%rbx) -- not taken jump -- (first of the case options) movl $Main_lvl_closure+1,%ebx addq $8,%rbp jmp *(%rbp) which is a 22% reduction (18 to 14) in instructions executed in the entire function, or a 40% reduction (10 to 6) in instruction executed in the core of the function (i.e., after the function's argument is possibly forced). Cheers! -Tyson PS: Thanks everyone for the very informative and interesting discussion. From dons at galois.com Thu Oct 16 14:34:01 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 16 14:29:59 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <200810161149.02873.twhitehead@gmail.com> References: <200810151035.32269.twhitehead@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA395@EA-EXMSG-C334.europe.corp.microsoft.com> <200810161149.02873.twhitehead@gmail.com> Message-ID: <20081016183401.GF4205@scytale.galois.com> twhitehead: > On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote: > > On 16/10/2008, at 21:34, Simon Peyton-Jones wrote: > > > BUT people who care probably UNPACK their strict fields too, which > > > is even better. The time you can't do that is for sum types > > > data T = MkT ![Int] > > > > You also can't do it for polymorphic components. I've used code like: > > > > data T a = MkT !a > > > > foo :: T (a,b) -> a > > foo (MkT (x,y)) = x > > > > Here, unpacking doesn't work but foo could still access the components > > of the pair directly. > > This is actually the situation I was originally looking at. I just simplified > it for the sake of posting readable core and assembler. > > > Specifically, I was looking at some of the assembler GHC was generating for > some array code to see if it could do a clean enough job to be used instead of > C, and was finding this sort of thing because STUArrau is defined as > > data STUArray s i a = STUArray !i !i !Int (MutableByteArray# s) FWIW, I get much nicer code with uvector (which uses type families to select monomorphic instances of things, and aggressive inlining, to yield much better code in practice). The DPH arrays library uses a similar method. So you might make some progress by taking that direction. -- Don From jgmorris at cecs.pdx.edu Fri Oct 17 11:20:55 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Fri Oct 17 11:16:49 2008 Subject: GHC 6.10 confusion Message-ID: <6cf91caa0810170820i2a517acene08147485e4ed33e@mail.gmail.com> Hello everyone, I've been attempting to build darcs under ghc-6.10.0.20080920. Currently, I'm getting the following error: ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: CreateProcess (null): No error Does anyone recognize this? Any pointers for where I should be looking? This is on Vista 64-bit SP1. /g -- I am in here From neil.mitchell.2 at credit-suisse.com Fri Oct 17 11:38:08 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Oct 17 11:35:02 2008 Subject: GHC 6.10 confusion In-Reply-To: <6cf91caa0810170820i2a517acene08147485e4ed33e@mail.gmail.com> References: <6cf91caa0810170820i2a517acene08147485e4ed33e@mail.gmail.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C903960751@ELON17P32001A.csfb.cs-group.com> Hi See: http://hackage.haskell.org/trac/ghc/ticket/2585 The solution is to grab a version of GHC 6.8 and copy its windres.exe into the GHC 6.10 bin directory. This will be fixed before release. Thanks Neil > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of J. Garrett Morris > Sent: 17 October 2008 4:21 pm > To: GHC users > Subject: GHC 6.10 confusion > > Hello everyone, > > I've been attempting to build darcs under ghc-6.10.0.20080920. > Currently, I'm getting the following error: > > ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: > CreateProcess (null): No error > > Does anyone recognize this? Any pointers for where I should > be looking? > > This is on Vista 64-bit SP1. > > /g > > -- > I am in here > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From jgmorris at cecs.pdx.edu Fri Oct 17 12:06:19 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Fri Oct 17 12:02:08 2008 Subject: GHC 6.10 confusion In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C903960751@ELON17P32001A.csfb.cs-group.com> References: <6cf91caa0810170820i2a517acene08147485e4ed33e@mail.gmail.com> <33A3F585590A6F4E81E3D45AA4A111C903960751@ELON17P32001A.csfb.cs-group.com> Message-ID: <6cf91caa0810170906l1aa560e7k9c9232aa61a3f8f@mail.gmail.com> My hero! This resolved my problem. /g On Fri, Oct 17, 2008 at 8:38 AM, Mitchell, Neil wrote: > Hi > > See: http://hackage.haskell.org/trac/ghc/ticket/2585 > > The solution is to grab a version of GHC 6.8 and copy its windres.exe > into the GHC 6.10 bin directory. > > This will be fixed before release. > > Thanks > > Neil > > > >> -----Original Message----- >> From: glasgow-haskell-users-bounces@haskell.org >> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf >> Of J. Garrett Morris >> Sent: 17 October 2008 4:21 pm >> To: GHC users >> Subject: GHC 6.10 confusion >> >> Hello everyone, >> >> I've been attempting to build darcs under ghc-6.10.0.20080920. >> Currently, I'm getting the following error: >> >> ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: >> CreateProcess (null): No error >> >> Does anyone recognize this? Any pointers for where I should >> be looking? >> >> This is on Vista 64-bit SP1. >> >> /g >> >> -- >> I am in here >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > -- I am in here From kili at outback.escape.de Fri Oct 17 14:43:18 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Oct 17 14:40:53 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080929202635.GA23350@petunia.outback.escape.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080927131004.GA27437@petunia.outback.escape.de> <20080929094634.GA8544@matrix.chaos.earth.li> <20080929170733.GA11160@petunia.outback.escape.de> <20080929202635.GA23350@petunia.outback.escape.de> Message-ID: <20081017184318.GA28106@petunia.outback.escape.de> On Mon, Sep 29, 2008 at 10:26:35PM +0200, Matthias Kilian wrote: > A full test log is available at > http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log Same for openbsd-amd64, built from sources pulled from the darcs repository at 15/Oct/2008:13:00:00 +0200: http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-amd64.log OVERALL SUMMARY for test run started at Wed Oct 15 21:07:08 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2301 were skipped 8846 expected passes 128 expected failures 0 unexpected passes 833 unexpected failures And for ghc-head (pulled an hour later): http://openbsd.dead-parrot.de/ghctests/ghc-head-openbsd-amd64.log OVERALL SUMMARY for test run started at Thu Oct 16 12:36:23 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2294 were skipped 8917 expected passes 128 expected failures 0 unexpected passes 769 unexpected failures Most failures are caused by ghci which is still broken for openbsd-amd64. Unfortunately, I don't have enough time to look at the other failures now. Ciao, Kili From igloo at earth.li Sun Oct 19 14:43:43 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 19 14:39:26 2008 Subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10)) In-Reply-To: <52f14b210810130502v648335e3vbf5e5b3cfbe47a4c@mail.gmail.com> References: <20081011174253.GE11641@scytale.galois.com> <52f14b210810130239w1b6004e0g349be92099bf8f4a@mail.gmail.com> <52f14b210810130502v648335e3vbf5e5b3cfbe47a4c@mail.gmail.com> Message-ID: <20081019184343.GA6370@matrix.chaos.earth.li> Hi Pedro, On Mon, Oct 13, 2008 at 02:02:07PM +0200, Jos? Pedro Magalh?es wrote: > > I'm attaching patches that add a link to the new wiki from the haddock of > syb (and change the maintainer to generics@haskell.org). Applied, thanks! Thanks Ian From twhitehead at gmail.com Sun Oct 19 21:24:09 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Sun Oct 19 21:19:56 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <20081016183401.GF4205@scytale.galois.com> References: <200810151035.32269.twhitehead@gmail.com> <200810161149.02873.twhitehead@gmail.com> <20081016183401.GF4205@scytale.galois.com> Message-ID: <200810192124.09818.twhitehead@gmail.com> On Thursday 16 October 2008 14:34:01 Don Stewart wrote: > FWIW, I get much nicer code with uvector (which uses type families > to select monomorphic instances of things, and aggressive inlining, to > yield much better code in practice). The DPH arrays library uses > a similar method. Thanks for the hint Don! : ) I've had a look at the documentation, and I'll hopefully give it a try soon. Cheers! -Tyson PS: Is the document still up-to-date with regards to recommending via c? From dons at galois.com Sun Oct 19 21:42:23 2008 From: dons at galois.com (Don Stewart) Date: Sun Oct 19 21:37:51 2008 Subject: Strictness in data declaration not matched in assembler? In-Reply-To: <200810192124.09818.twhitehead@gmail.com> References: <200810151035.32269.twhitehead@gmail.com> <200810161149.02873.twhitehead@gmail.com> <20081016183401.GF4205@scytale.galois.com> <200810192124.09818.twhitehead@gmail.com> Message-ID: <20081020014223.GA23085@scytale.galois.com> twhitehead: > On Thursday 16 October 2008 14:34:01 Don Stewart wrote: > > FWIW, I get much nicer code with uvector (which uses type families > > to select monomorphic instances of things, and aggressive inlining, to > > yield much better code in practice). The DPH arrays library uses > > a similar method. > > Thanks for the hint Don! : ) > > I've had a look at the documentation, and I'll hopefully give it a try soon. > > Cheers! -Tyson > > PS: Is the document still up-to-date with regards to recommending via c? Yep, but you can always experiment with -fasm -- Don From magicloud.magiclouds at gmail.com Mon Oct 20 01:08:28 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Mon Oct 20 01:04:17 2008 Subject: What a mess.... Message-ID: <48FC124C.4090403@gmail.com> Hi, I want to install ghc 6.10. Well.... I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex (all from darcs, the latest version). Then darcsed 6.10's source. And made. I got: "templates/GenericTemplate.hs:47:21: parse error on input `#'", when "make -C genprimopcode" Any idea what should I do? Thanks. From dons at galois.com Mon Oct 20 01:12:03 2008 From: dons at galois.com (Don Stewart) Date: Mon Oct 20 01:07:32 2008 Subject: What a mess.... In-Reply-To: <48FC124C.4090403@gmail.com> References: <48FC124C.4090403@gmail.com> Message-ID: <20081020051203.GA23456@scytale.galois.com> magicloud.magiclouds: > Hi, > I want to install ghc 6.10. Well.... > > I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex > (all from darcs, the latest version). Then darcsed 6.10's source. And made. > I got: "templates/GenericTemplate.hs:47:21: parse error on input > `#'", when "make -C genprimopcode" > > Any idea what should I do? Thanks. Install a binary release of ghc 6.10. Also note that a) ghc 6.10 isn't released yet , and b) you should know what you're doing, http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html Cheers! Don P.S. More information is required to answer exactly your questions. Ask yourself this question: what information would /I/ need to reproduce what I just did from scratch? The answer to that is how much context to include in your question. From magicloud.magiclouds at gmail.com Mon Oct 20 01:34:11 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Mon Oct 20 01:30:02 2008 Subject: What a mess.... In-Reply-To: <20081020051203.GA23456@scytale.galois.com> References: <48FC124C.4090403@gmail.com> <20081020051203.GA23456@scytale.galois.com> Message-ID: <48FC1853.2060603@gmail.com> Because some libraries' darcs have been updated to fit 6.10. And I do not want to check every library's stable version before I darcs it. So I decide to install ghc-6.10. I have tried a few times, no special action needed, just build 6.10, and as it requires, install the rest. Then, it cannot be made. I will try the binary distribution. Well binary of 6.8 cannot run in my box. Don Stewart wrote: > magicloud.magiclouds: > >> Hi, >> I want to install ghc 6.10. Well.... >> >> I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex >> (all from darcs, the latest version). Then darcsed 6.10's source. And made. >> I got: "templates/GenericTemplate.hs:47:21: parse error on input >> `#'", when "make -C genprimopcode" >> >> Any idea what should I do? Thanks. >> > > Install a binary release of ghc 6.10. > Also note that a) ghc 6.10 isn't released yet , and b) you should know > what you're doing, > > http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html > > Cheers! > Don > > P.S. > > More information is required to answer exactly your questions. > Ask yourself this question: what information would /I/ need to reproduce > what I just did from scratch? > > The answer to that is how much context to include in your question. > > From marlowsd at gmail.com Mon Oct 20 04:51:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Oct 20 04:47:47 2008 Subject: GHC 6.10 confusion In-Reply-To: <6cf91caa0810170906l1aa560e7k9c9232aa61a3f8f@mail.gmail.com> References: <6cf91caa0810170820i2a517acene08147485e4ed33e@mail.gmail.com> <33A3F585590A6F4E81E3D45AA4A111C903960751@ELON17P32001A.csfb.cs-group.com> <6cf91caa0810170906l1aa560e7k9c9232aa61a3f8f@mail.gmail.com> Message-ID: <48FC46AF.6080303@gmail.com> This should actually be fixed in more recent snapshots. If it isn't, please let me know. Cheers, Simon J. Garrett Morris wrote: > My hero! This resolved my problem. > > /g > > On Fri, Oct 17, 2008 at 8:38 AM, Mitchell, Neil > wrote: >> Hi >> >> See: http://hackage.haskell.org/trac/ghc/ticket/2585 >> >> The solution is to grab a version of GHC 6.8 and copy its windres.exe >> into the GHC 6.10 bin directory. >> >> This will be fixed before release. >> >> Thanks >> >> Neil >> >> >> >>> -----Original Message----- >>> From: glasgow-haskell-users-bounces@haskell.org >>> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf >>> Of J. Garrett Morris >>> Sent: 17 October 2008 4:21 pm >>> To: GHC users >>> Subject: GHC 6.10 confusion >>> >>> Hello everyone, >>> >>> I've been attempting to build darcs under ghc-6.10.0.20080920. >>> Currently, I'm getting the following error: >>> >>> ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: >>> CreateProcess (null): No error >>> >>> Does anyone recognize this? Any pointers for where I should >>> be looking? >>> >>> This is on Vista 64-bit SP1. >>> >>> /g >>> >>> -- >>> I am in here >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> ============================================================================== >> Please access the attached hyperlink for an important electronic communications disclaimer: >> >> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html >> ============================================================================== >> >> > > > From Christian.Maeder at dfki.de Mon Oct 20 10:16:05 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 20 10:11:45 2008 Subject: cabal Message-ID: <48FC92A5.6050306@dfki.de> Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian From Christian.Maeder at dfki.de Mon Oct 20 10:28:19 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Oct 20 10:23:59 2008 Subject: cabal Message-ID: <48FC9583.4060404@dfki.de> Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian From bertram.felgenhauer at googlemail.com Mon Oct 20 11:56:22 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Oct 20 11:52:09 2008 Subject: Building ghc-6.10 with ghc-6.6.1 Message-ID: <20081020155622.GA7783@zombie.inf.tu-dresden.de> Hi, I've successfully built ghc-6.10 with ghc-6.6.1; there was one minor problem: Building extensible-exceptions-0.1.0.0... Control/Exception/Extensible.hs:2:13: cannot parse LANGUAGE pragma ghc 6.6.1 does not know about DeriveDataTypeable - I just removed that line. Software used: ghc-6.6.1 alex 2.2 happy 1.17 Cabal 1.4.0.1 (not relevant, I believe) gcc 4.1.2 (may be relevant because of cpp) linux 2.6.24.4 I'm not sure what Magicloud's problem is, but it's related to alex; the contents of .../alex-2.3/AlexTemplate-ghc (whereever alex was installed) would be interesting -- does it contain any lines starting with # ? This template is generated from templates/GenericTemplate.hs while building alex. Another idea is that {-# OPTIONS -fglasgow-exts -cpp #-} is somehow missing from the generated utils/genprimopcode/Lexer.hs file in the ghc tree - but I can't really see how that would happen. Bertram From duncan.coutts at worc.ox.ac.uk Mon Oct 20 14:15:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 20 14:11:32 2008 Subject: cabal In-Reply-To: <48FC9583.4060404@dfki.de> References: <48FC9583.4060404@dfki.de> Message-ID: <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> On Mon, 2008-10-20 at 16:28 +0200, Christian Maeder wrote: > Hi, > > currently I've got a problem installing from hackage. > using: > GHC (package manager) version 6.10.0.20081019 > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library > > I get: > > Building network-2.2.0.0... > > Network/URI.hs:128:7: > Could not find module `Data.Generics': > it is a member of package base-3.0.3.0, which is hidden The basic problem here is that the version number of the network package has not been bumped. You probably installed from a ghc bindist that has network-2.2.0.0 already, however it's not the same as network-2.2.0.0 from hackage. The pre-installed one is built against base-4, so when cabal-install tries to rebuild it then it tries to build it against base 4 which does not work because the one on hackage has not been updated. Normally cabal-install would use base-3 but in this case it's picking 4 because the version that is already installed used 4 so the assumption is that since the same version is already installed then it does indeed work with base 4. Of course that's not true here because the package has changed without the version being bumped. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number. So the solution is for the updated network package to have its version bumped and for it to be released. Duncan From jeff.polakow at db.com Mon Oct 20 14:44:15 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Mon Oct 20 14:39:59 2008 Subject: thread/socket behvior In-Reply-To: <48EF5753.2050707@gmail.com> Message-ID: Hello, Just writing to let people know the resolution of this problem... After much frustration and toil, we realized there was a bug in GHC's handle abstraction over sockets. We resolved our immediate problem by having our code deal directly with the sockets, and we filed a bug report, #2703, which has just been (partially fixed) by Simon Marlow. thanks, Jeff Simon Marlow wrote on 10/10/2008 09:23:31 AM: > Jeff Polakow wrote: > > > Don Stewart wrote on 10/09/2008 02:56:02 PM: > > > > > jeff.polakow: > > > > We have a server that accepts messages over a socket, spawning > > threads to > > > > process them. Processing these messages may cause other, outgoing > > > > connections, to be spawned. Under sufficient load, the main > > server loop > > > > (i.e. the call to accept, followed by a forkIO), becomes > > nonresponsive. > > > > > > > > A smaller distilled testcase reveals that when sufficient socket > > activity > > > > is occurring, an incoming connection may not be responded to > > until other > > > > connections have been cleared out of the way, despite the fact > > that these > > > > other connections are being handled by separate threads. One > > issue that > > > > we've been trying to figure out is where this behavior arises > > from-- the > > > > GHC rts, the Network library, the underlying C libraries. > > > > > > > > Have other GHC users doing applications with large amounts of > > > socket usage > > > > observed similar behavior and managed to trace back where it > > originates > > > > from? Are there any particular architectural solutions that > > people have > > > > found to work well for these situations? > > > > > > Hey Jeff, > > > > > > Can you say which GHC you used, and whether you used the threaded > > > runtime or non-threaded runtime? > > > > > Oops, forgot about that... > > > > We used both ghc-6.8.3 and ghc-6.10.rc1 and we used the threaded > > runtime. We are running on a 64 bit linux machine using openSUSE 10. > > The scheduler doesn't have a concept of priorities, so the accepting thread > will get the same share of the CPU as the other threads. Another issue is > that the accepting thread has to be woken up by the IO manager thread when > a new connection is available, so we might have to wait for the IO manager > thread to run too. But I wouldn't expect to see overly long delays. Maybe > you could try network-alt which does its own IO multiplexing. > > If you have multiple cores, you might want to try fixing the thread > affinity - e.g. put all the worker threads on one core, and the accepting > thread on the other core. You can do this using GHC.Conc.forkOnIO, with > the +RTS -qm -qw options. > > Other than that, I'm not sure what to try right now. We're hoping to get > some better profiling for parallel/concurrent programs in the future, but > it's not ready yet. > > Cheers, > Simon --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081020/3dd726d4/attachment.htm From claus.reinke at talk21.com Mon Oct 20 15:20:08 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Oct 20 15:15:58 2008 Subject: cabal References: <48FC9583.4060404@dfki.de> <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> Message-ID: <2DEE8BA742E949469B2BF1BA473FA9EC@cr3lt> > The basic problem here is that the version number of the network package > has not been bumped. .. > .. Of course that's not true here because the package has > changed without the version being bumped. > .. > Indeed the only reason it's trying to rebuild it at all is because the > installed version has different deps from the available version, again > due to the fact that it changed without changing version number. > > So the solution is for the updated network package to have its version > bumped and for it to be released. For ghc at least, couldn't cabal grep the hashes from the output of find dist/ -name '*.hi' | xargs ghc --show-iface and associate the collection of hashes for the exposed-modules and cross-package imports with the version number, keeping a history of these associations? cabal tag-current would try to add the current version number with the current hashes, complaining if the number already exists with different hashes cabal sdist (and other distribution channels) would check that the current version number is in the history with the current hashes, and complain otherwise Distributing packages without version number checks could result in in "unverified" packages, so users would know that the dependencies and version number haven't been checked (successful checks could create a package signature based on .cabal+.history, or on the whole package contents). Or are Ghc's new hashes non-portable/too specific? Claus From duncan.coutts at worc.ox.ac.uk Mon Oct 20 15:55:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 20 15:51:21 2008 Subject: cabal In-Reply-To: <2DEE8BA742E949469B2BF1BA473FA9EC@cr3lt> References: <48FC9583.4060404@dfki.de> <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> <2DEE8BA742E949469B2BF1BA473FA9EC@cr3lt> Message-ID: <1224532526.21116.113.camel@dell.linuxdev.us.dell.com> On Mon, 2008-10-20 at 20:20 +0100, Claus Reinke wrote: > > The basic problem here is that the version number of the network package > > has not been bumped. .. > > .. Of course that's not true here because the package has > > changed without the version being bumped. > > .. > > Indeed the only reason it's trying to rebuild it at all is because the > > installed version has different deps from the available version, again > > due to the fact that it changed without changing version number. > > > > So the solution is for the updated network package to have its version > > bumped and for it to be released. > > For ghc at least, couldn't cabal grep the hashes from the output of > > find dist/ -name '*.hi' | xargs ghc --show-iface > > and associate the collection of hashes for the exposed-modules and > cross-package imports with the version number, keeping a history of > these associations? Unfortunately the interface can change depending on the way the package is built, in particular the versions of the dependencies it is built with. This is because packages are really functors, parameterised by their dependencies. For this reason we can only associate hashes with built/installed packages, not with source packages on hackage. However for installed packages we certainly should track the package ABI hash. This will help in verifying the dependencies of built packages. It's also the starting point for a nix-style persistent built-package store. Duncan From jgmorris at cecs.pdx.edu Mon Oct 20 18:07:35 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Mon Oct 20 18:03:15 2008 Subject: Instrumenting overlapping instances Message-ID: <6cf91caa0810201507q6d333aadh88f192fd6b9ddd21@mail.gmail.com> Hello, I'm currently studying the use of overlapping instances, and I was hoping to instrument GHC to produce some variety of list of instances that overlapped. I haven't done any GHC hacking so far, so I'm not entirely familiar with the code base. Does anyone have any guidance on which modules I should likely need to modify? Thanks, /g From claus.reinke at talk21.com Mon Oct 20 19:18:23 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Oct 20 19:14:07 2008 Subject: Instrumenting overlapping instances References: <6cf91caa0810201507q6d333aadh88f192fd6b9ddd21@mail.gmail.com> Message-ID: <3C2A5B2B295B41DE8EF51D6979F042E8@cr3lt> > I'm currently studying the use of overlapping instances, and I was > hoping to instrument GHC to produce some variety of list of instances > that overlapped. I haven't done any GHC hacking so far, so I'm not > entirely familiar with the code base. Does anyone have any guidance > on which modules I should likely need to modify? None?-) Loading this {-# LANGUAGE FlexibleInstances #-} class C a instance C a instance C [a] instance C [()] instance C [Bool] instance C Bool into ghci 6.8.3, we can play with various types and get ghci to list overlaps that might match those types. Of course, there are some oddities. Also, the behaviour will differ slightly if we actually enable OverlappingInstances. But it should get you started. Claus *Main> (undefined :: C a => a) *** Exception: Prelude.undefined *Main> (undefined :: C a => a) :: b :1:1: Overlapping instances for C b arising from instantiating a type signature at :1:1-21 Matching instances: instance C a -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 instance C Bool -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:7:0-14 instance C [Bool] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:6:0-16 instance C [()] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:5:0-14 instance C [a] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:4:0-13 (The choice depends on the instantiation of `b' To pick the first instance above, use -fallow-incoherent-instances when compiling the other instance declarations) In the expression: (undefined :: (C a) => a) :: b In the definition of `it': it = (undefined :: (C a) => a) :: b *Main> (undefined :: C a => a) :: Bool :1:1: Overlapping instances for C Bool arising from instantiating a type signature at :1:1-21 Matching instances: instance C a -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 instance C Bool -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:7:0-14 In the expression: (undefined :: (C a) => a) :: Bool In the definition of `it': it = (undefined :: (C a) => a) :: Bool *Main> (undefined :: C a => a) :: [b] :1:1: Overlapping instances for C [b] arising from instantiating a type signature at :1:1-21 Matching instances: instance C a -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 instance C [a] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:4:0-13 instance C [Bool] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:6:0-16 instance C [()] -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:5:0-14 In the expression: (undefined :: (C a) => a) :: [b] In the definition of `it': it = (undefined :: (C a) => a) :: [b] Claus From marlowsd at gmail.com Tue Oct 21 03:59:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 21 03:55:20 2008 Subject: thread/socket behvior In-Reply-To: References: Message-ID: <48FD8BE8.1060409@gmail.com> I'll be interested to know if the fix helps your application. The bug reported in #2703 results in the program just allocating memory endlessly until it dies, so it doesn't sound exactly like the symptoms you were originally describing. Cheers, Simon Jeff Polakow wrote: > > Hello, > > Just writing to let people know the resolution of this problem... > > After much frustration and toil, we realized there was a bug in GHC's > handle abstraction over sockets. > > We resolved our immediate problem by having our code deal directly > with the sockets, and we filed a bug report, #2703, which has just been > (partially fixed) by Simon Marlow. > > thanks, > Jeff > > Simon Marlow wrote on 10/10/2008 09:23:31 AM: > > > Jeff Polakow wrote: > > > > > Don Stewart wrote on 10/09/2008 02:56:02 PM: > > > > > > > jeff.polakow: > > > > > We have a server that accepts messages over a socket, spawning > > > threads to > > > > > process them. Processing these messages may cause other, > outgoing > > > > > connections, to be spawned. Under sufficient load, the main > > > server loop > > > > > (i.e. the call to accept, followed by a forkIO), becomes > > > nonresponsive. > > > > > > > > > > A smaller distilled testcase reveals that when sufficient > socket > > > activity > > > > > is occurring, an incoming connection may not be responded to > > > until other > > > > > connections have been cleared out of the way, despite the fact > > > that these > > > > > other connections are being handled by separate threads. One > > > issue that > > > > > we've been trying to figure out is where this behavior arises > > > from-- the > > > > > GHC rts, the Network library, the underlying C libraries. > > > > > > > > > > Have other GHC users doing applications with large amounts of > > > > socket usage > > > > > observed similar behavior and managed to trace back where it > > > originates > > > > > from? Are there any particular architectural solutions that > > > people have > > > > > found to work well for these situations? > > > > > > > > Hey Jeff, > > > > > > > > Can you say which GHC you used, and whether you used the threaded > > > > runtime or non-threaded runtime? > > > > > > > Oops, forgot about that... > > > > > > We used both ghc-6.8.3 and ghc-6.10.rc1 and we used the threaded > > > runtime. We are running on a 64 bit linux machine using openSUSE 10. > > > > The scheduler doesn't have a concept of priorities, so the accepting > thread > > will get the same share of the CPU as the other threads. Another > issue is > > that the accepting thread has to be woken up by the IO manager thread > when > > a new connection is available, so we might have to wait for the IO > manager > > thread to run too. But I wouldn't expect to see overly long delays. > Maybe > > you could try network-alt which does its own IO multiplexing. > > > > If you have multiple cores, you might want to try fixing the thread > > affinity - e.g. put all the worker threads on one core, and the > accepting > > thread on the other core. You can do this using GHC.Conc.forkOnIO, with > > the +RTS -qm -qw options. > > > > Other than that, I'm not sure what to try right now. We're hoping to > get > > some better profiling for parallel/concurrent programs in the future, > but > > it's not ready yet. > > > > Cheers, > > Simon > > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. From marlowsd at gmail.com Tue Oct 21 04:51:04 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Oct 21 04:46:52 2008 Subject: cabal In-Reply-To: <2DEE8BA742E949469B2BF1BA473FA9EC@cr3lt> References: <48FC9583.4060404@dfki.de> <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> <2DEE8BA742E949469B2BF1BA473FA9EC@cr3lt> Message-ID: <48FD97F8.30409@gmail.com> Claus Reinke wrote: >> The basic problem here is that the version number of the network package >> has not been bumped. .. >> .. Of course that's not true here because the package has >> changed without the version being bumped. >> .. >> Indeed the only reason it's trying to rebuild it at all is because the >> installed version has different deps from the available version, again >> due to the fact that it changed without changing version number. >> >> So the solution is for the updated network package to have its version >> bumped and for it to be released. > > For ghc at least, couldn't cabal grep the hashes from the output of > > find dist/ -name '*.hi' | xargs ghc --show-iface > > and associate the collection of hashes for the exposed-modules and > cross-package imports with the version number, keeping a history of > these associations? > > cabal tag-current > would try to add the current version number with the current hashes, > complaining if the number already exists with different hashes > > cabal sdist (and other distribution channels) > would check that the current version number is in the history with > the current hashes, and complain otherwise > > Distributing packages without version number checks could result in > in "unverified" packages, so users would know that the dependencies > and version number haven't been checked (successful checks could > create a package signature based on .cabal+.history, or on the whole > package contents). > Or are Ghc's new hashes non-portable/too specific? GHC's hashes aren't suitable for this (yet). We do not hash the API, but rather the ABI, and the ABI is often not stable - re-compiling can give you a different ABI, as internal names change and things move around in unpredictable ways. However I do think we should have a way to get a dump of the API. We've talked in the past about having some kind of API tool that would compare APIs and show you the differences (built on the GHC API of course). This would make a nice little project for someone... Cheers, Simon From Christian.Maeder at dfki.de Tue Oct 21 04:51:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Oct 21 04:47:22 2008 Subject: cabal In-Reply-To: <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> References: <48FC9583.4060404@dfki.de> <1224526539.21116.88.camel@dell.linuxdev.us.dell.com> Message-ID: <48FD9820.10105@dfki.de> Duncan Coutts wrote: > The basic problem here is that the version number of the network package > has not been bumped. see below > You probably installed from a ghc bindist that has > network-2.2.0.0 already, Yes, you're right, and I didn't notice that, because I relied on cabal install. > however it's not the same as network-2.2.0.0 > from hackage. The pre-installed one is built against base-4, so when > cabal-install tries to rebuild it then it tries to build it against base > 4 which does not work because the one on hackage has not been updated. So network-2.2.0.0 should be linked against base-3 within the binary dist of ghc-6.10 (or not shipped with ghc-6.10 at all. In fact it worked after I've unregistered my global network-2.2.0.0, first! (but I didn't get much further, see below) > Normally cabal-install would use base-3 but in this case it's picking 4 > because the version that is already installed used 4 so the assumption > is that since the same version is already installed then it does indeed > work with base 4. Of course that's not true here because the package has > changed without the version being bumped. Or cabal-install should be smarter (or less smart). > Indeed the only reason it's trying to rebuild it at all is because the > installed version has different deps from the available version, again > due to the fact that it changed without changing version number. > > So the solution is for the updated network package to have its version > bumped and for it to be released. So why is the version of network not bumped, yet? The maintainer is libraries@haskell.org. Would it interfere with ghc-6.8? Cheers and thanks for your explanation Christian P.S. for hxt and Shellac-editline the sources need to be changed for ghc-6.10: [ 49 of 112] Compiling Text.XML.HXT.RelaxNG.DataTypeLibUtils ( src/Text/XML/HXT/RelaxNG/DataTypeLibUtils.hs, dist/build/Text/XML/HXT/RelaxNG/DataTypeLibUtils.o ) src/Text/XML/HXT/RelaxNG/DataTypeLibUtils.hs:67:7: `>>>' is not a (visible) method of class `Arrow' cabal: Error: some packages failed to install: hxt-8.1.0 failed during the building phase. The exception was: exit: ExitFailure 1 Building Shellac-editline-0.9... [1 of 1] Compiling System.Console.Shell.Backend.Editline ( src/System/Console/Shell/Backend/Editline.hs, dist/build/System/Console/Shell/Backend/Editline.o ) src/System/Console/Shell/Backend/Editline.hs:48:45: Couldn't match expected type `()' against inferred type `Bool' Expected type: IO () Inferred type: IO Bool In the expression: EL.readHistory In the `readHistory' field of a record cabal: Error: some packages failed to install: Shellac-editline-0.9 failed during the building phase. The exception was: exit: ExitFailure 1 From jeff.polakow at db.com Wed Oct 22 15:37:28 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Wed Oct 22 15:33:06 2008 Subject: thread/socket behvior In-Reply-To: <48FD8BE8.1060409@gmail.com> Message-ID: Hello, > I'll be interested to know if the fix helps your application. The bug > reported in #2703 results in the program just allocating memory endlessly > until it dies, so it doesn't sound exactly like the symptoms you were > originally describing. > We are currently using GHC-6.8.3 so we can't try the fixed version. We'll switch to 6.10 after it becomes the stable release and (hopefully) minimal work needs to be done to get everything to compile. This bug actually perfectly explains the behavior we saw in our full system. The distilled test case we reported was based on our then current theory that too many connections were the cause of our problem. We're pretty sure the behavior we described was real, but it was not the cause of our problem as subsequent testing revealed. After delving deeper, we realized that the real culprit was too much data over one connection. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081022/f0fcc98b/attachment.htm From g9ks157k at acme.softbase.org Thu Oct 23 06:59:35 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Oct 23 06:55:12 2008 Subject: More detail on breakage with ghc-6.10 In-Reply-To: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> Message-ID: <200810231259.35263.g9ks157k@acme.softbase.org> Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts: > All, > > We've been using the cabal-install build reporting stuff to get more > detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > generates these build-reports.log files and individual log files for > each build. build-reports.log informs me that configure failed for the lax package with both GHC 6.8 and GHC 6.10. However, lax used to build fine on my machine with GHC 6.8. So I looked at logs/lax-0.0.0.1.log but this file is empty. Why? Best wishes, Wolfgang From daniel.is.fischer at web.de Thu Oct 23 07:28:11 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Oct 23 07:21:25 2008 Subject: More detail on breakage with ghc-6.10 In-Reply-To: <200810231259.35263.g9ks157k@acme.softbase.org> References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> <200810231259.35263.g9ks157k@acme.softbase.org> Message-ID: <200810231328.11181.daniel.is.fischer@web.de> Am Donnerstag, 23. Oktober 2008 12:59 schrieb Wolfgang Jeltsch: > Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts: > > All, > > > > We've been using the cabal-install build reporting stuff to get more > > detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > > generates these build-reports.log files and individual log files for > > each build. > > build-reports.log informs me that configure failed for the lax package with > both GHC 6.8 and GHC 6.10. However, lax used to build fine on my machine > with GHC 6.8. So I looked at logs/lax-0.0.0.1.log but this file is empty. > Why? > > Best wishes, > Wolfgang lax-0.0.0.1 just built fine for me using 6.8.3, package: lax-0.0.0.1 os: linux arch: i386 compiler: ghc-6.8.3 client: cabal-install-0.6.0 flags: dependencies: base-3.0.2.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried Probably the log is empty because no build outcomes have been reported (I just tried cabal report and got cabal: /home/dafis/.cabal/reports/hackage.haskell.org: getDirectoryContents: does not exist (No such file or directory) , I can't be bothered now to find out what I'd have to do to make it work). Cheers, Daniel From phercek at gmail.com Thu Oct 23 08:34:38 2008 From: phercek at gmail.com (Peter Hercek) Date: Thu Oct 23 08:31:20 2008 Subject: could ghci debugger search for free variables better? Message-ID: May be my approach to debugging with ghci is wrong but in about half of the time I find ghci (as a debugger) almost useless. The reason is the limited way it can resolve identifiers. I can examine the free variables in the selected expression and nothing else. Well, I *think* just sometimes I can examine few more variables. But if it happens at all it is rare. Is there a way to make ghci recognize all the variables which could be visible in the selected expression? By "could be visible" I mean they are in scope and can be used in the expression if I would edit the source code. ... well I would like to see the stack too but this does not annoy me that much. Peter. From greenrd at greenrd.org Thu Oct 23 02:31:21 2008 From: greenrd at greenrd.org (Robin Green) Date: Thu Oct 23 09:56:03 2008 Subject: Getting the location of data files from ghc-pkg? Message-ID: <20081023073121.103a304b@greenrd.org> Is there any way of finding out where the Data-files specified in a .cabal file have been installed to? I want to script finding some TeX support files that are installed as part of the Functional MetaPost library. -- Robin From dons at galois.com Thu Oct 23 10:04:53 2008 From: dons at galois.com (Don Stewart) Date: Thu Oct 23 10:00:49 2008 Subject: More detail on breakage with ghc-6.10 In-Reply-To: <200810231259.35263.g9ks157k@acme.softbase.org> References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> <200810231259.35263.g9ks157k@acme.softbase.org> Message-ID: <20081023140453.GA793@scytale.galois.com> g9ks157k: > Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts: > > All, > > > > We've been using the cabal-install build reporting stuff to get more > > detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > > generates these build-reports.log files and individual log files for > > each build. > > build-reports.log informs me that configure failed for the lax package with > both GHC 6.8 and GHC 6.10. However, lax used to build fine on my machine > with GHC 6.8. So I looked at logs/lax-0.0.0.1.log but this file is empty. > Why? Resolving dependencies... 'lax-0.0.0.1' is cached. cabal: The package requires Cabal library version -any && >=1.2 && <1.4 but no suitable version is installed. cabal: Error: some packages failed to install Perhaps? From igloo at earth.li Thu Oct 23 11:00:59 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Oct 23 10:56:31 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: References: <20081008200939.GA5675@matrix.chaos.earth.li> Message-ID: <20081023150059.GA11516@matrix.chaos.earth.li> Hi Paul, On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote: > > With all that, the first problem I hit was with utils/pwd/pwd. > ./configure builds it by calling ghc without any special flags, so the > binary can't find libgmp.so at runtime. I think you need to tell the dynamic linker where to find it, e.g. by setting DYLD_LIBRARY_PATH. See the dyld manpage for more information. Thanks Ian From duncan.coutts at worc.ox.ac.uk Thu Oct 23 14:20:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 23 14:21:54 2008 Subject: Getting the location of data files from ghc-pkg? In-Reply-To: <20081023073121.103a304b@greenrd.org> References: <20081023073121.103a304b@greenrd.org> Message-ID: <1224786007.21116.276.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-23 at 07:31 +0100, Robin Green wrote: > Is there any way of finding out where the Data-files specified in > a .cabal file have been installed to? I want to script finding some TeX > support files that are installed as part of the Functional MetaPost > library. Yes. See the Cabal user guide section on this topic: http://haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module Duncan From duncan.coutts at worc.ox.ac.uk Thu Oct 23 14:21:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 23 14:21:59 2008 Subject: More detail on breakage with ghc-6.10 In-Reply-To: <200810231259.35263.g9ks157k@acme.softbase.org> References: <1223710582.6878.315.camel@dell.linuxdev.us.dell.com> <200810231259.35263.g9ks157k@acme.softbase.org> Message-ID: <1224786103.21116.278.camel@dell.linuxdev.us.dell.com> On Thu, 2008-10-23 at 12:59 +0200, Wolfgang Jeltsch wrote: > Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts: > > All, > > > > We've been using the cabal-install build reporting stuff to get more > > detailed info on build failures with ghc-6.10 vs 6.8. cabal-install > > generates these build-reports.log files and individual log files for > > each build. > > build-reports.log informs me that configure failed for the lax package with > both GHC 6.8 and GHC 6.10. However, lax used to build fine on my machine > with GHC 6.8. So I looked at logs/lax-0.0.0.1.log but this file is empty. > Why? As Don noted, it's because it didn't even get to the stage of running the configure for the package. That's the first part where it starts logging. Yes, the logging is sadly rather primitive. Duncan From Christian.Maeder at dfki.de Fri Oct 24 07:13:24 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Oct 24 07:08:54 2008 Subject: SVN binding with Haskell In-Reply-To: <48CE771E.9010305@dfki.de> References: <1220969616.6626.2.camel@GI32> <48CE771E.9010305@dfki.de> Message-ID: <4901ADD4.80200@dfki.de> just to correct a false impression. One part of my problem (point 3. below) was a wrong hsc2hs program that was found in my PATH by accident (that also caused http://www.haskell.org/pipermail/cabal-devel/2008-October/003980.html) Cheers Christian Christian Maeder wrote: > Hi, > > I've install HsSVN (version 0.3.3) using ghc-6.8.3 and Cabal-1.4.0.1, > but it was a real pain (under i686 Linux 2.6.22.18-0.2-default #1 SMP) > > 1. I had to install subversion-devel-1.4.4-30 (of course) > 2. configure went through after setting: > export CPATH=/usr/include/apr-1:/usr/include/subversion-1 > 3. building failed with: > > Program error: : IO.getContents: protocol error (input contains > non-character data - use binary I/O for binary data) > > because some comments in the sources (i.e. Subversion/FileSystem.hsc) > contain funny (japanese?) characters that hsc2hs does not like. (Under > Solaris and Mac this was no problem, though.) I used iconv to convert > the sources and finally the included HelloWorld example went through. > > 4. Under Solaris, only apr-1-config and apu-1-config found the proper > include path (so I needed to adjust the configure.ac file) > > 5. The file HsSVN.buildinfo.in has no final newline, so that the last > line (containing the ld-options:) is missing in HsSVN.buildinfo after > configure! > > 6. Running the examples under Solaris failed with: > -bash-3.1$ ./HelloWorld > Creating a repository "repos"... > The youngest revision of the repository is 0 > Storing a file "/hello" in it... > HelloWorld: user error (withSubversion: caught an SvnError: UnknownError > 22: Can't set position pointer in file 'repos/db/revs/0': Invalid argument) > > Cheers Christian > > Shahzad wrote: >> Dear Sir/Madam, >> >> I am doctoral student and researcher in Technical University Vienna. I >> need to manage Subversion client and run SVN commands through >> Haskell6.8 , and I need to make that application for ubuntu and Windows, >> Can you guide me how to make any API for Haskell to use Subversion. >> >> I was thinking to use c2hs to make an interface from C++ to haskell but >> I could not find that a solution. There is a Package HsSVN but is also >> not working. >> >> Can you please guide me to the solution.. >> >> Best Regards >> >> Syed > > From marlowsd at gmail.com Fri Oct 24 08:49:26 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Oct 24 08:45:00 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: References: Message-ID: <4901C456.3060008@gmail.com> Peter Hercek wrote: > May be my approach to debugging with ghci is wrong > but in about half of the time I find ghci (as a > debugger) almost useless. The reason is the limited > way it can resolve identifiers. I can examine > the free variables in the selected expression and > nothing else. Well, I *think* just sometimes I can > examine few more variables. But if it happens at > all it is rare. > > Is there a way to make ghci recognize all the variables > which could be visible in the selected expression? > By "could be visible" I mean they are in scope and > can be used in the expression if I would edit the > source code. We thought about this when working on the debugger, and the problem is that to make the debugger retain all the variables that are in scope rather than just free in the expression adds a lot of overhead, and it fundamentally changes the structure of the generated code: everything becomes recursive, for one thing. Well, perhaps you could omit all the recursive references (except the ones that are also free?), but there would still be a lot of overhead due to having to retain all those extra references. It also risks creating serious space leaks, by retaining references to things that the program would normally discard. Fortunately it's usually easy to work around the limitation, just by adding extra references to your code, e.g. in a let expression that isn't used. Cheers, Simon From phercek at gmail.com Fri Oct 24 18:50:28 2008 From: phercek at gmail.com (Peter Hercek) Date: Fri Oct 24 18:47:07 2008 Subject: could ghci debugger search for free variables better? In-Reply-To: <4901C456.3060008@gmail.com> References: <4901C456.3060008@gmail.com> Message-ID: Simon Marlow wrote: > We thought about this when working on the debugger, and the problem is > that to make the debugger retain all the variables that are in scope > rather than just free in the expression adds a lot of overhead, and it > fundamentally changes the structure of the generated code: everything > becomes recursive, for one thing. Well, perhaps you could omit all the > recursive references (except the ones that are also free?), but there > would still be a lot of overhead due to having to retain all those extra > references. > > It also risks creating serious space leaks, by retaining references to > things that the program would normally discard. > > Fortunately it's usually easy to work around the limitation, just by > adding extra references to your code, e.g. in a let expression that > isn't used. Yes, Pepe pointed this to me too along with the "Step inside GHCi debugger" paper in monad reader. The problem is that I mostly can find out what is wrong when I look at values of some important variables when some important place in my code is hit. Using the trick with const function to manually add references is not that much better than simple "printf debugging" (adding Debug.Trace.trace calls to the code). Tracing the execution history is nice too but it provides much more than what is needed and obscures the important parts. OK, It is frustrating that I find "printf debugging" often more productive than ghci debugger. I see that it is not a good idea to keep references to all the variables in scope but maybe few improvements are possible: 1) As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within given function then when user asks for a variable it would be searched first in the selected expression and if not found in the expressions from the tracelocal history. If the result would be printed from tracelocal history it should be indicated so in the output. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the depth of 50 would be enough). The results from the tracelocal history may not be from the expected scope sometimes but the same problem is with "printf debugging". 2) I noticed only now that I do not know how to script breakpoints. I tried :set stop if myFreeVar == 666 then :list else :continue ... and it did not work. My goal was to create a conditional breakpoint. I also wanted to use it instead of "printf debugging" using something like :set stop { :force myFreeVar; :continue } Ideally it should be possible to attach different script for each breakpoint and the functions for controlling debugger should be available in the Haskell. I would expect this is already partially possible now (using :set stop) and possibly some functions from ghci api which correspond to ghci commands (like :set etc.). But I do not know how, any pointers from experienced ghci debugger users? Ghci debugger did not know some functions in my code which I would expect it to know; e.g. field selection functions from a record which is not exported from the module but which are available withing module. Is this expected? (I did not have any *.hi *.o files around when ghci did run the code.) Och and sometimes it did not recognize a free variable in the selected expression. The code looked like let myFn x = x `div` getDivisor state > 100 in if myFn xxx then ... the expression "myFn xxx" was selected while browsing trace history but xxx was not recognized, but when I browsed into myFn definition in the trace log the x (which represented the same value) was recognized. Is this expected? Thanks, Peter. From conal at conal.net Sat Oct 25 17:14:59 2008 From: conal at conal.net (Conal Elliott) Date: Sat Oct 25 17:10:22 2008 Subject: ghc-6.11 + OpenGL/GLUT crashes on WinXP Message-ID: I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on ghc-6.9.20080622 . I'd appreciate hearing about other attempts with these versions on Windows systems. Thanks, - Conal import Graphics.UI.GLUT main :: IO () main = do putStrLn "Initializing" getArgsAndInitialize return () -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081025/e05001f0/attachment.htm From jgmorris at cecs.pdx.edu Mon Oct 27 13:56:11 2008 From: jgmorris at cecs.pdx.edu (J. Garrett Morris) Date: Mon Oct 27 13:51:30 2008 Subject: Instrumenting overlapping instances In-Reply-To: <3C2A5B2B295B41DE8EF51D6979F042E8@cr3lt> References: <6cf91caa0810201507q6d333aadh88f192fd6b9ddd21@mail.gmail.com> <3C2A5B2B295B41DE8EF51D6979F042E8@cr3lt> Message-ID: <6cf91caa0810271056x254de5b6wd610d9e5506d5604@mail.gmail.com> Hi, This is neat - but not quite what I was hoping for. My intended use was to build a number of packages and produce a listing of all overlapping instances, without knowing in advance which classes might contain overlap. This is why I was hoping to instrument GHC instead of using the existing tools like GHCi or my eyes. Thanks though! /g On Mon, Oct 20, 2008 at 4:18 PM, Claus Reinke wrote: >> I'm currently studying the use of overlapping instances, and I was >> hoping to instrument GHC to produce some variety of list of instances >> that overlapped. I haven't done any GHC hacking so far, so I'm not >> entirely familiar with the code base. Does anyone have any guidance >> on which modules I should likely need to modify? > > None?-) Loading this > > {-# LANGUAGE FlexibleInstances #-} > class C a > instance C a > instance C [a] > instance C [()] > instance C [Bool] > instance C Bool > > into ghci 6.8.3, we can play with various types and get ghci to list > overlaps > that might match those types. Of course, there are some oddities. Also, the > behaviour will differ slightly if we actually enable OverlappingInstances. > But > it should get you started. > > Claus > > *Main> (undefined :: C a => a) > *** Exception: Prelude.undefined > *Main> (undefined :: C a => a) :: b > > :1:1: > Overlapping instances for C b > arising from instantiating a type signature at :1:1-21 > Matching instances: > instance C a > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 > instance C Bool > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:7:0-14 > instance C [Bool] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:6:0-16 > instance C [()] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:5:0-14 > instance C [a] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:4:0-13 > (The choice depends on the instantiation of `b' > To pick the first instance above, use -fallow-incoherent-instances > when compiling the other instance declarations) > In the expression: (undefined :: (C a) => a) :: b > In the definition of `it': it = (undefined :: (C a) => a) :: b > *Main> (undefined :: C a => a) :: Bool > > :1:1: > Overlapping instances for C Bool > arising from instantiating a type signature at :1:1-21 > Matching instances: > instance C a > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 > instance C Bool > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:7:0-14 > In the expression: (undefined :: (C a) => a) :: Bool > In the definition of `it': it = (undefined :: (C a) => a) :: Bool > *Main> (undefined :: C a => a) :: [b] > > :1:1: > Overlapping instances for C [b] > arising from instantiating a type signature at :1:1-21 > Matching instances: > instance C a > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:3:0-11 > instance C [a] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:4:0-13 > instance C [Bool] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:6:0-16 > instance C [()] > -- Defined at C:/Documents and Settings/cr3/Desktop/Overlap.hs:5:0-14 > In the expression: (undefined :: (C a) => a) :: [b] > In the definition of `it': it = (undefined :: (C a) => a) :: [b] > > Claus > > -- I am in here From claus.reinke at talk21.com Mon Oct 27 14:10:25 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Oct 27 14:05:48 2008 Subject: Dilemma: DiffArray non-performance vs STArray non-readability Message-ID: I keep wanting to use DiffArray as the natural functional solution to single-threaded array use. But everytime I try, I get smacked over the head with the actual performance figures. Sometimes, even plain arrays are faster in a loop doing array updates, in spite of all the copying involved. And when copying on update dominates the runtime, using IntMap tends to be faster - the "indirections" are the wrong way round, but don't pile up, just that array lookups aren't quite constant time. But when I really need to avoid the updates, and need constant time lookup, I'm stuck: DiffArray tends to slow everything down (I vaguely recall locks and threads being at the heart of this, but I haven't checked the code recently), so my only option seems to be to transform my nice functional code into not-nice sequential code and use STArray. Is there any way out of this dilemma? What do other Ghc users use? If locks really are the issue, perhaps using STM instead of MVars in the DiffArray implementation could help. As long as my array uses are single-threaded, STM optimism might be able to avoid waiting/scheduler issues? Or am I on the wrong track? Claus PS Btw, I thought the DiffArray performance issue was ancient, but I can't find a ticket for it, nor does the haddock page for Data.Array.Diff mention this little hickup. Should I add a ticket? From dons at galois.com Mon Oct 27 14:12:19 2008 From: dons at galois.com (Don Stewart) Date: Mon Oct 27 14:07:22 2008 Subject: Dilemma: DiffArray non-performance vs STArray non-readability In-Reply-To: References: Message-ID: <20081027181219.GH17185@scytale.galois.com> claus.reinke: > I keep wanting to use DiffArray as the natural functional solution to > single-threaded array use. But everytime I try, I get smacked over > the head with the actual performance figures. Sometimes, even plain > arrays are faster in a loop doing array updates, in spite of all the > copying involved. And when copying on update dominates the runtime, > using IntMap tends to be faster - the "indirections" are the wrong way > round, but don't pile up, just that array lookups aren't quite constant > time. In my view, DiffArray needs a modern rewrite. There's no need for it to be as slow as it is. We played with some similar structures at work, and got quite good performance, so I think the problem is not fundamental. Time for someone to step up and write a new fast diff array. -- Don From igloo at earth.li Mon Oct 27 14:49:16 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Oct 27 14:44:38 2008 Subject: Dilemma: DiffArray non-performance vs STArray non-readability In-Reply-To: References: Message-ID: <20081027184916.GA4489@matrix.chaos.earth.li> On Mon, Oct 27, 2008 at 06:10:25PM -0000, Claus Reinke wrote: > > Should I add a ticket? Sounds good - and if you could attach a small example showing how Array is faster that would be helpful too. Thanks Ian From prj at po.cwru.edu Mon Oct 27 15:29:20 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Mon Oct 27 15:24:42 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <20081023150059.GA11516@matrix.chaos.earth.li> (Ian Lynagh's message of "Thu\, 23 Oct 2008 16\:00\:59 +0100") References: <20081008200939.GA5675@matrix.chaos.earth.li> <20081023150059.GA11516@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote: >> With all that, the first problem I hit was with utils/pwd/pwd. >> ./configure builds it by calling ghc without any special flags, so the >> binary can't find libgmp.so at runtime. > > I think you need to tell the dynamic linker where to find it, e.g. by > setting DYLD_LIBRARY_PATH. See the dyld manpage for more information. I'm on GNU/Linux, so it would be LD_LIBRARY_PATH for me. Yes, that would be another useable workaround for pwd. What about the other problems I mentioned? Regardless of my problems, it seems like a build bug that SRC_HC_OPTS isn't used for some compilations. Is SRC_HC_OPTS meant to be used for all Haskell compilations in the build process, or am I misunderstanding its purpose? >> The next problem was with cabal-bin. The command to build it didn't >> use SRC_HC_OPTS, so that binary also couldn't find libgmp.so when it >> ran. I used this patch: >> >> --- libraries/Makefile~ 2008-09-21 13:06:31.000000000 -0400 >> +++ libraries/Makefile 2008-09-23 01:58:29.000000000 -0400 >> @@ -131,7 +131,7 @@ >> >> cabal-bin: cabal-bin.hs >> -mkdir bootstrapping >> - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin >> + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin >> >> bootstrapping.conf: cabal-bin >> echo "[]" > $@.tmp >> @@ -154,9 +154,9 @@ >> mkdir ifBuildable >> $(CP) ifBuildable.hs ifBuildable/ >> ifeq "$(stage)" "2" >> - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable >> + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable >> else >> - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable >> + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable >> endif >> >> .PHONY: all build configure >> >> That gets me to this point: >> >> Preprocessing library hpc-0.5.0.2... >> dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory >> running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed >> command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs >> make[1]: *** [bootstrapping.conf] Error 1 >> make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.10.0.20080921+spf+0/compile/src/ghc-6.10.0.20080921/libraries' >> make: *** [stage1] Error 2 >> >> I'm not sure how to fix this. I assume there's some way to pass >> SRC_HC_OPTS to cabal-bin, but I don't know how. paul From claus.reinke at talk21.com Mon Oct 27 20:45:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Oct 27 20:41:00 2008 Subject: Dilemma: DiffArray non-performance vs STArray non-readability References: <20081027184916.GA4489@matrix.chaos.earth.li> Message-ID: <186D8069457148448D2A4431C3FA5478@cr3lt> >> Should I add a ticket? > > Sounds good - and if you could attach a small example showing how Array > is faster that would be helpful too. Ok, ticket is http://hackage.haskell.org/trac/ghc/ticket/2727 . Hope I got the example right - the effect is clear, but with "functional" DiffArray, it is way too easy to lose single-threadedness. In addition to the basic slowness issue, it appears there has been a serious regression in the area (handling of $! perhaps?) since 6.4.1. Claus From camior at gmail.com Tue Oct 28 12:15:17 2008 From: camior at gmail.com (David Sankel) Date: Tue Oct 28 12:10:33 2008 Subject: Subtle difference between standard instances Message-ID: We, at Anygma, noticed that a and b below have different behavior: a, b :: (Int->Int) -> (Int,Int) -> (Int,Int) a = fmap b = second See the blog post at http://netsuperbrain.com/blog/?p=74. The standard instances for Functor, Monad, and Applicative for tuples is strict. The Arrow on (->) when applied to tuples with first and second, however is non-strict. It is a subtle discrepancy, but it does make a difference for FRP when deriving these standard instances. Any objections to making the Functor, Monad, and Applicative instances for tuples non-strict like Arrows? David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081028/2ba0c00d/attachment.htm From conal at conal.net Tue Oct 28 13:17:53 2008 From: conal at conal.net (Conal Elliott) Date: Tue Oct 28 13:13:26 2008 Subject: [Haskell-cafe] ghc-6.11 + OpenGL/GLUT crashes on WinXP In-Reply-To: References: Message-ID: Thanks, David. Helpful data point. I am using glut32 rather than freeglut (and no need for patching the darcs GLUT). I wonder if glut32-vs-freeglut could account for crash-vs-nocrash on 6.10 and 6.11 but not 6.9. I'd love to hear from someone on Windows and glut32. Please do post a wiki page on freeglut + ghc on windows and let us know here. Could you integrate your glutWin32 patch into the darcs GLUT? - Conal On Tue, Oct 28, 2008 at 8:48 AM, David Sankel wrote: > My setup worked: > > - Windows XP. > - ghc-6.11.20081024 > - freeglut 2.4.0 > - darcs version of GLUT (with patched glutGetProcAddress [attached]) > - darcs version of OpenGL > > Getting freeglut going with ghc on windows is a bit involved. I could write > a walkthrough if there's enough interest. > > David > > 2008/10/25 Conal Elliott > >> I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when >> doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and >> GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on >> ghc-6.9.20080622 . >> >> I'd appreciate hearing about other attempts with these versions on Windows >> systems. >> >> Thanks, - Conal >> >> >> import Graphics.UI.GLUT >> >> main :: IO () >> main = do putStrLn "Initializing" >> getArgsAndInitialize >> return () >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081028/243ecfca/attachment-0001.htm From dons at galois.com Tue Oct 28 13:18:15 2008 From: dons at galois.com (Don Stewart) Date: Tue Oct 28 13:13:30 2008 Subject: Subtle difference between standard instances In-Reply-To: References: Message-ID: <20081028171815.GE21412@scytale.galois.com> camior: > We, at Anygma, noticed that a and b below have different behavior: > > a, b :: (Int->Int) -> (Int,Int) -> (Int,Int) > a = fmap > b = second > > See the blog post at [1]http://netsuperbrain.com/blog/?p=74. > > The standard instances for Functor, Monad, and Applicative for tuples is > strict. The Arrow on (->) when applied to tuples with first and second, > however is non-strict. > > It is a subtle discrepancy, but it does make a difference for FRP when > deriving these standard instances. Any objections to making the Functor, > Monad, and Applicative instances for tuples non-strict like Arrows? > Changes to this kind of thing should be proposed on the libraries@ mailing list, via the submission process. http://haskell.org/haskellwiki/Library_submissions Since you guys are experts in FRP, I imagine this should be fine :) -- Don From conal at conal.net Tue Oct 28 23:17:33 2008 From: conal at conal.net (Conal Elliott) Date: Tue Oct 28 23:12:47 2008 Subject: [Haskell-cafe] Re: ghc-6.11 + OpenGL/GLUT crashes on WinXP In-Reply-To: <4165d3a70810281514y351fd531g7514aa65754d66a9@mail.gmail.com> References: <4165d3a70810281514y351fd531g7514aa65754d66a9@mail.gmail.com> Message-ID: No display lists. The crash happens during the GLUT call "initialize". I can trigger it from ghci with the following simple incantation: Prelude> import Graphics.UI.GLUT Prelude Graphics.UI.GLUT> initialize "foo" [] And no trouble under ghc 6.9.20080622. Stumped. :( - Conal On Tue, Oct 28, 2008 at 3:14 PM, Jefferson Heard < jefferson.r.heard@gmail.com> wrote: > Conal, are you using display lists at all? I've had problems with > allocating lists, but you seem to be able to leave off the allocation > step in Windows on nVidia cards so long as you're careful not to > conflict names yourself. > > On Tue, Oct 28, 2008 at 4:03 PM, Matti Niemenmaa > > wrote: > > Conal Elliott wrote: > >> I am using glut32 rather than freeglut (and no need for patching the > darcs > >> GLUT). I wonder if glut32-vs-freeglut could account for > crash-vs-nocrash on > >> 6.10 and 6.11 but not 6.9. I'd love to hear from someone on Windows and > >> glut32. > > > > Windows XP with SP3 > > ghc-6.10.20081007 > > glut32 > > > > Works fine for me. > > > > Taking a look at my GL headers, I did have to mess with at least glut.h > to get > > something to work---whether it was to build HOpenGL, to make programs > linkable, > > or to make them runnable, I'm not sure. In any case, what I did was force > > GLUTAPIENTRY to be #defined as __stdcall. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > I try to take things like a crow; war and chaos don't always ruin a > picnic, they just mean you have to be careful what you swallow. > > -- Jessica Edwards > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081028/539ac2c6/attachment.htm From igloo at earth.li Wed Oct 29 09:22:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 29 09:17:49 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: References: <20081008200939.GA5675@matrix.chaos.earth.li> <20081023150059.GA11516@matrix.chaos.earth.li> Message-ID: <20081029132236.GA11358@matrix.chaos.earth.li> Hi Paul, On Mon, Oct 27, 2008 at 03:29:20PM -0400, Paul Jarc wrote: > Ian Lynagh wrote: > > On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote: > >> With all that, the first problem I hit was with utils/pwd/pwd. > >> ./configure builds it by calling ghc without any special flags, so the > >> binary can't find libgmp.so at runtime. > > > > I think you need to tell the dynamic linker where to find it, e.g. by > > setting DYLD_LIBRARY_PATH. See the dyld manpage for more information. > > I'm on GNU/Linux, so it would be LD_LIBRARY_PATH for me. Oh, sorry, for some reason I had it in my head that you were on OS X. > Yes, that > would be another useable workaround for pwd. What about the other > problems I mentioned? I thought all your problems boiled down to binaries not being able to find libgmp.so at runtime? So I think this should fix them all. The build system assumes that the bootstrapping compiler knows how to build Haskell programs that can just be run. > Regardless of my problems, it seems like a > build bug that SRC_HC_OPTS isn't used for some compilations. Is > SRC_HC_OPTS meant to be used for all Haskell compilations in the build > process, or am I misunderstanding its purpose? You are probably right that it should technically be passed. Thanks Ian From aeyakovenko at gmail.com Wed Oct 29 14:41:13 2008 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Wed Oct 29 14:40:18 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: <48ED1E8D.6060701@dtek.chalmers.se> References: <20081008200939.GA5675@matrix.chaos.earth.li> <48ED1E8D.6060701@dtek.chalmers.se> Message-ID: I am using the gentoo package for 6.10.1 and when i start ghci it tries to allocate over 1gb of memory, which hits my ulimit. Is anyone else getting absurd memory usage when trying to start ghci? $ ghci GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc: out of memory (requested 1048576 bytes From kolmodin at dtek.chalmers.se Wed Oct 29 16:49:18 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Wed Oct 29 16:44:31 2008 Subject: ANNOUNCE: GHC 6.10.1 RC 1 In-Reply-To: References: <20081008200939.GA5675@matrix.chaos.earth.li> <48ED1E8D.6060701@dtek.chalmers.se> Message-ID: <4908CC4E.2050709@dtek.chalmers.se> Anatoly Yakovenko wrote: > I am using the gentoo package for 6.10.1 and when i start ghci it > tries to allocate over 1gb of memory, which hits my ulimit. > > Is anyone else getting absurd memory usage when trying to start ghci? > $ ghci > GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > ghc: out of memory (requested 1048576 bytes Likely the same bug we've seen before with libedit, or related; GHC bug reported at http://hackage.haskell.org/trac/ghc/ticket/2716 (closed as invalid as the problem isn't with GHC) Gentoo bug report at http://bugs.gentoo.org/237882 to fix gentoo's libedit. You can try to apply the patch in the gentoo bug locally and see if that resolves the issue. Cheers, Lennart K From red5_2 at hotmail.com Thu Oct 30 01:20:43 2008 From: red5_2 at hotmail.com (C Rodrigues) Date: Thu Oct 30 01:15:54 2008 Subject: Type classes in GADTs Message-ID: I discovered that closed type classes can be implicitly defined using GADTs. The GADT value itself acts like a class dictionary. However, GHC (6.8.3) doesn't know anything about these type classes, and it won't infer any class memberships. In the example below, an instance of Eq is not recognized. So is this within the domain of GHC's type inference, not something it shoud infer, or a bug? {-# OPTIONS_GHC -XTypeFamilies -XGADTs -XEmptyDataDecls #-} module CaseAnalysisOnGADTs where -- Commutative and associative operators. data CAOp a where Sum :: CAOp Int Disj :: CAOp Bool Concat :: CAOp String {- For any non-bottom value of type 'CAOp a', the value will have type -- CAOp Int, CAOp Bool, or CAOp String. Int, Bool, and String are all -- members of Eq. Therefore, if we have a non-bottom value of type -- 'CAOp a' then 'a' is a member of Eq. -} data D a = D !(CAOp a) (a, a) -- However, GHC won't figure this out. noEvidenceOfEq :: D a -> Bool noEvidenceOfEq (D op (e1, e2)) = e1 == e2 -- Error, no instance (Eq a) -- Unless you force it to do case analysis on constructors. evidenceOfEq :: CAOp a -> a -> a -> Bool evidenceOfEq Sum = (==) evidenceOfEq Disj = (==) evidenceOfEq Concat = (==) -- Then you can use the result from that, but GHC still won't -- recognize it as an Eq instance. useEvidenceOfEq :: D a -> Bool useEvidenceOfEq (D op (e1, e2)) = evidenceOfEq op e1 e2 _________________________________________________________________ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/ From dagit at codersbase.com Thu Oct 30 03:01:41 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Oct 30 02:56:51 2008 Subject: Type classes in GADTs In-Reply-To: References: Message-ID: On Wed, Oct 29, 2008 at 10:20 PM, C Rodrigues wrote: > > I discovered that closed type classes can be implicitly defined using GADTs The GADT value itself acts like a class dictionary. However, GHC (6.83) doesn't know anything about these type classes, and it won't infer any class memberships. In the example below, an instance of Eq is not recognized. > > So is this within the domain of GHC's type inference, not something it shoud infer, or a bug? > > {-# OPTIONS_GHC -XTypeFamilies -XGADTs -XEmptyDataDecls #-} > module CaseAnalysisOnGADTs where > > -- Commutative and associative operators. > data CAOp a where > Sum :: CAOp Int > Disj :: CAOp Bool > Concat :: CAOp String I guess when you write something like this the type checker doesn't look at the closed set of types that 'a' can take on. I don't know why that would be a problem in your example, but if we did this: data CAOp a where Sum :: CAOp Int Disj :: CAOP Bool Concat :: CAOp String Weird :: Show a => CAOp a Now we have a problem, because the set of types for is { Int, Bool, String, forall a. Show a => a}. It's not a closed set anymore. And I think, but I'm just making this up, that the above set of type must be hard to reason about. I think it would essentially be: data Show a => CAOp a where ... And GHC won't allow that, presumably for a good reason. Neat example, and I hope someone sheds more light on this. By the way, since you mention ghc6.8.3, does that mean some other version of GHC permits noEvidenceOfEq to type check? I tried 6.6.1 but that didn't accept it either. Jason From daniil.elovkov at googlemail.com Thu Oct 30 03:53:14 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Thu Oct 30 03:48:31 2008 Subject: Type classes in GADTs In-Reply-To: References: Message-ID: <490967EA.7070706@gmail.com> Jason Dagit wrote: > On Wed, Oct 29, 2008 at 10:20 PM, C Rodrigues wrote: >> I discovered that closed type classes can be implicitly defined using GADTs The GADT value itself acts like a class dictionary. However, GHC (6.83) doesn't know anything about these type classes, and it won't infer any class memberships. In the example below, an instance of Eq is not recognized. >> >> So is this within the domain of GHC's type inference, not something it shoud infer, or a bug? >> >> {-# OPTIONS_GHC -XTypeFamilies -XGADTs -XEmptyDataDecls #-} >> module CaseAnalysisOnGADTs where >> >> -- Commutative and associative operators. >> data CAOp a where >> Sum :: CAOp Int >> Disj :: CAOp Bool >> Concat :: CAOp String > > I guess when you write something like this the type checker doesn't > look at the closed set of types that 'a' can take on. I don't know > why that would be a problem in your example, but if we did this: > > data CAOp a where > Sum :: CAOp Int > Disj :: CAOP Bool > Concat :: CAOp String > Weird :: Show a => CAOp a > > Now we have a problem, because the set of types for is { Int, Bool, > String, forall a. Show a => a}. It's not a closed set anymore. And I > think, but I'm just making this up, that the above set of type must be > hard to reason about. I think it would essentially be: > > data Show a => CAOp a where ... > I agree with Jason here. Actually we can think of quite a lot of examples where the type checker _can_ know something what we see as obvious. But that something is a special case of a more general situation which is far less obvious and knowing it may require serious program analysis. Then, regarding handling some special cases, I think it's a matter of keeping type checker predictable and clean. In this particular case, handling this situation would require type checker to look at the _values_ of the given datatype, which as I understand Haskell type checker doesn't. If we later add members to CAOp the valid program may become invalid, though the "signature" of CAOp hasn't changed. That doesn't look good. Not all members of CAOp may be exported from a module, that would have to be taken into account as well, probably. In your example, why not just do traditionalEvidenceOfEq :: Eq a => D a -> Bool -- Daniil Elovkov From waldmann at imn.htwk-leipzig.de Thu Oct 30 10:08:27 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Oct 30 10:07:06 2008 Subject: file descriptors Message-ID: <4909BFDB.5090402@imn.htwk-leipzig.de> Dear all, are there any known issues with file handles/descriptors in ghc-compiled executables? My program has a lot of calls to System.Process.runInteractiveProcess and I'm running into unpredictable behaviour (sometimes the program just silently dies, sometimes it gets stuck) The handles I get correspond to file descriptors in the OS? Could there be any conflicts? (Like not enough available, or re-used to early etc.) Or perhaps you see anything that's wrong with my code here http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/box/src/SMT/Time.hs?rev=1.9 I'm compiling this with -threaded, but running with -N1. Of course, terminateProcess is another source of uncertainty here. (Sometimes it takes several seconds until the external process dies.) Any hints appreciated. - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081030/7f7505ed/signature.bin From aslatter at gmail.com Thu Oct 30 11:02:35 2008 From: aslatter at gmail.com (Antoine Latter) Date: Thu Oct 30 10:57:44 2008 Subject: file descriptors In-Reply-To: <4909BFDB.5090402@imn.htwk-leipzig.de> References: <4909BFDB.5090402@imn.htwk-leipzig.de> Message-ID: <694519c50810300802y1485be5dh65746805e2a27a6b@mail.gmail.com> 2008/10/30 Johannes Waldmann : > Dear all, > > are there any known issues > with file handles/descriptors in ghc-compiled executables? > > My program has a lot of calls to System.Process.runInteractiveProcess > and I'm running into unpredictable behaviour (sometimes the program > just silently dies, sometimes it gets stuck) > I don't know a lot about this sort of thing, but I know that there's a bunch of wrappers around runInteractiveProcess that the franchise package uses found here: http://darcs.net/repos/franchise/Distribution/Franchise/Util.hs Maybe those wrappers make up for some gotchas that are often encountered with runInteractiveProcess? -Antoine From red5_2 at hotmail.com Thu Oct 30 11:09:51 2008 From: red5_2 at hotmail.com (C Rodrigues) Date: Thu Oct 30 11:05:00 2008 Subject: Type classes in GADTs In-Reply-To: <20081030074833.E085832452E@www.haskell.org> References: <20081030074833.E085832452E@www.haskell.org> Message-ID: Thanks for the explanation. I see how this wouldn't behave nicely with automatic class constraint inference. I didn't test the example on any other GHC versions. I will probably end up passing in the Eq dictionary from outside like Daniil suggested. I would prefer to do the following, but GHC doesn't accept the type signature. evidenceOfEq :: CAOp a -> (Eq a => b) -> b Neither does it accept data EqConstraint a b = EqConstraint (Eq a => b). Foiled again. _________________________________________________________________ Want to read Hotmail messages in Outlook? The Wordsmiths show you how. http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cns!20EE04FBC541789!167.entry?ocid=TXT_TAGLM_WL_hotmail_092008 From nominolo at googlemail.com Thu Oct 30 11:52:43 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Oct 30 11:47:53 2008 Subject: Type classes in GADTs In-Reply-To: References: <20081030074833.E085832452E@www.haskell.org> Message-ID: <916b84820810300852h6f05096ewb6df1a2edf6286e4@mail.gmail.com> 2008/10/30 C Rodrigues : > evidenceOfEq :: CAOp a -> (Eq a => b) -> b isn't that the same as: evidenceOfEq :: Eq a => CAOp a -> b -> b > Neither does it accept data EqConstraint a b = EqConstraint (Eq a => b). Foiled again. same here: data Eq a => EqConstraint a b = EqConstraint b. although this must be a typo, since it doesn't make any sense to me. From simonpj at microsoft.com Thu Oct 30 12:53:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 30 12:48:41 2008 Subject: gadt changes in ghc 6.10 In-Reply-To: <3BE3F0F9-25CF-4A67-8942-D5082243885A@dc.uba.ar> References: <193FCDD5-C50C-4E30-988F-3D4D020E80FB@dc.uba.ar> <638ABD0A29C8884A91BC5FB5C349B1C32D76A795A8@EA-EXMSG-C334.europe.corp.microsoft.com> <3BE3F0F9-25CF-4A67-8942-D5082243885A@dc.uba.ar> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7A470229@EA-EXMSG-C334.europe.corp.microsoft.com> | > In your case the error message was: | > | > GADT.hs:26:56: | > GADT pattern match with non-rigid result type `Maybe a' | > Solution: add a type signature | > In a case alternative: I1 m' -> m' | > In the expression: case w' S of { I1 m' -> m' } | > In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } | > | ... | And maybe the "add a type signature" can be more explicit? Like "add a | type signature that makes the type of the result known at the matching | point". Just a suggestion... Good suggestion. I've done that. Simon From allbery at ece.cmu.edu Thu Oct 30 20:48:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Oct 30 20:43:59 2008 Subject: file descriptors In-Reply-To: <4909BFDB.5090402@imn.htwk-leipzig.de> References: <4909BFDB.5090402@imn.htwk-leipzig.de> Message-ID: On 2008 Oct 30, at 10:08, Johannes Waldmann wrote: > are there any known issues > with file handles/descriptors in ghc-compiled executables? > > My program has a lot of calls to System.Process.runInteractiveProcess > and I'm running into unpredictable behaviour (sometimes the program > just silently dies, sometimes it gets stuck) runInteractiveProcess returns 3 filehandles and a process handle. Either can cause problems: if you use too many filehandles, the select()-based mechanism in the Haskell runtime will fail (select() has a fairly low limit on filehandles as compared to poll(), epoll(), and other mechanisms); if you spawn too many subprocesses without reaping them (waitForProcess / getProcessExitCode) you will hit the child process limit and not be able to create new child processes. A third problem is that you can deadlock if you write too much data without reading any back. Your best bet is to forkIO so input and output are independent. > Or perhaps you see anything that's wrong with my code here > http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/box/src/SMT/Time.hs?rev=1.9 And there's a fourth problem: you hGetContents after blocking waitForProcess. If the output is larger than the size of a pipe buffer (often 512 bytes), the subprocess will block waiting for the pipe to be read, while you're waiting for it to exit before reading from the pipe. -- 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 From mnislaih at gmail.com Thu Oct 23 09:01:37 2008 From: mnislaih at gmail.com (pepe) Date: Wed Jan 21 12:34:55 2009 Subject: could ghci debugger search for free variables better? In-Reply-To: References: Message-ID: This limitation is annoying, I agree, but often the use of :steplocal combined with :back and :forward makes up for it (and make sure you do ':set stop :list' too). You can also use the trick of instrumenting your function with const annotations to bring into scope the variables you want, demoed by Bernie Pope in The Monad Reader issue 10, and here [1]. E.g. Suppose we have -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.pdf Type: application/pdf Size: 61062 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20081023/17a432b4/pastedGraphic-0001.pdf -------------- next part -------------- We are stopped in the highlighted subexpression, and we want to inspect variables term and text. However these are not in scope in the examined expression. We can modify the expression as follows to bring them into scope: | term == test = searchDef rest `const` (term, text) Best, pepe [1] - http://www.cs.mu.oz.au/~bjpop/papers/ghci-debug.monad.reader.pdf On 23/10/2008, at 14:34, Peter Hercek wrote: > May be my approach to debugging with ghci is wrong > but in about half of the time I find ghci (as a > debugger) almost useless. The reason is the limited > way it can resolve identifiers. I can examine > the free variables in the selected expression and > nothing else. Well, I *think* just sometimes I can > examine few more variables. But if it happens at > all it is rare. > > Is there a way to make ghci recognize all the variables > which could be visible in the selected expression? > By "could be visible" I mean they are in scope and > can be used in the expression if I would edit the > source code. > > ... well I would like to see the stack too but this > does not annoy me that much. > > Peter. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users