From marlowsd at gmail.com Mon Sep 1 05:39:08 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 1 05:37:30 2008 Subject: Where STM is unstable at the moment, and how we can fix it In-Reply-To: References: Message-ID: <48BBB83C.1030804@gmail.com> Sterling Clover wrote: > This email is inspired by the discussion here: > http://hackage.haskell.org/trac/ghc/ticket/2401 > > As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or > unsafeInterleaveIO, genuinely completely unsafe in that there is no way > to use it such that a segfault or deadlock is not at least somewhat > encouraged. The code attached to the ticket creates a deadlock solely > through using it to write to stdout. But, for the same reason that > unsafeIOToSTM is unstable, unsafeInterleaveIO now is very unstable as > well -- conceivably, data generated from functions with lazy IO > (including those in the prelude) could cause deadlocks within STM, and > even segfaults. > > In summary, a "validation" step is performed on all threads inside > atomically blocks during garbage collection. This validation step will, > on encountering invalid threads (i.e. ones which should be rolled back) > immediately kill them dead and retry. This is different than the > implementation described in the STM paper, where rollbacks only occur on > commit. However, it does add a measure of efficiency. Its not just an efficiency trick, in fact. The validation step is absolutely necessary for correctness. The problem is that a transaction may have seen an inconsistent view of memory, and as a result it may have gone into an infinite loop; the only way to catch and recover from this situation is to validate at regular intervals, say before a GC (this suffers from the problem that the transaction has to be allocating in order to be stopped, but that's another matter). e.g. the code might be something like atomically $ do a <- readTVar ta b <- readTVar tb if a == b then loop else return () now we might know that a is never equal to b under normal conditions: all the transactions in the program satisfy the invariant. However, since we use optimistic concurrency, it might be the case that this thread sees an inconsistent view of memory in which a==b. The case would normally be caught at commit time, but this thread isn't going to commit: it goes into an infinite loop instead. > As Simon M. notes, the obvious solution would be to turn rollbacks into > regular exceptions, but this would open a number of cans of worms. > > A start, though not sufficient, would be for stm validation to respect > blocked status -- not to block on it, obviously, but simply to refuse to > rollback a transaction within it. That wouldn't be correct, because the thread might be in an infinite loop inside a block. However, it would probably work in the cases you're interested in, so I wouldn't object to a patch that implemented this workaround for the time being. I do agree that we have a problem here, and I'll re-open the ticket (sorry for leaving it closed). I think raising an (asynchronous) exception is the right solution. We have to make sure the exception cannot be caught by an STM catch, but I think that's do-able. However, another problem we have is that when the IO system re-raises the exception, it'll be raised as a synchronous exception rather than an asynchronous exception. I've just spent an hour or so talking this over here with Simon PJ and we have some ideas for fixing it, I'll try to write it up in a ticket later. Cheers, Simon From neil.mitchell.2 at credit-suisse.com Tue Sep 2 05:49:09 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Sep 2 05:47:59 2008 Subject: Windows snapshot binaries Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3974@ELON17P32001A.csfb.cs-group.com> Hi, Looking at: http://www.haskell.org/ghc/dist/current/dist/ The latest Windows binary appears to be the 22nd of June, and thus is before things such as the Control.Exception changes, and will not work with the current version of Haddock. Is it possible to get an updated binary? From what I remember, these snapshots are also used for the Windows binary release, so will have to be fixed before 6.10 can be released. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From g9ks157k at acme.softbase.org Tue Sep 2 07:20:01 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Sep 2 07:18:22 2008 Subject: GADT pattern match in non-rigid context Message-ID: <200809021320.01316.g9ks157k@acme.softbase.org> Hello, I have some code giving me the error message: ?GADT pattern match in non-rigid context for ? Tell GHC HQ if you'd like this to unify the context?. I reduced my code to the following example which still gives this error message: > data T a b where > > C :: T a [b] > > f :: (forall a'. T a' b) -> T a b > f t = case t of C -> C How do I work around this error? Some former e-mail discussion gave the hint of adding a type signature but this probably doesn?t work in my case. Note also that specializing the type of the argument t to T a b inside the definition of f is not an option since in the real code I need the first argument of T to be universally quantified for calling another function which needs this quantification. I use GHC 6.8.2. Don?t know whether this problem still shows up with GHC HEAD but am interested in hearing whether this is the case. I?m thankful for any help. Best wishes, Wolfgang From simonpj at microsoft.com Tue Sep 2 07:58:14 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Sep 2 07:56:26 2008 Subject: GADT pattern match in non-rigid context In-Reply-To: <200809021320.01316.g9ks157k@acme.softbase.org> References: <200809021320.01316.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8749523@EA-EXMSG-C334.europe.corp.microsoft.com> Wolfgang You need to say that type "t", the case scrutinee, has. You can use a type signature for that. Presumably the way that a' is instantiated doesn't matter, but GHC isn't clever enough to realise that. So I just instantiated it to (). The result compiles fine. Simon {-# LANGUAGE RankNTypes, ScopedTypeVariables, GADTs #-} module Foo where data T a b where C :: T a [b] f :: forall a b. (forall a'. T a' b) -> T a b f t = case t :: T () b of C -> C | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Wolfgang Jeltsch | Sent: 02 September 2008 12:20 | To: glasgow-haskell-users@haskell.org | Subject: GADT pattern match in non-rigid context | | Hello, | | I have some code giving me the error message: ?GADT pattern match in non-rigid | context for ? Tell GHC HQ if you'd like this to unify the context?. I | reduced my code to the following example which still gives this error | message: | | > data T a b where | > | > C :: T a [b] | > | > f :: (forall a'. T a' b) -> T a b | > f t = case t of C -> C | | How do I work around this error? Some former e-mail discussion gave the hint | of adding a type signature but this probably doesn?t work in my case. Note | also that specializing the type of the argument t to T a b inside the | definition of f is not an option since in the real code I need the first | argument of T to be universally quantified for calling another function which | needs this quantification. | | I use GHC 6.8.2. Don?t know whether this problem still shows up with GHC HEAD | but am interested in hearing whether this is the case. | | I?m thankful for any help. | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Tue Sep 2 08:37:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 2 08:35:45 2008 Subject: *BSD GHC hackers needed... Message-ID: <48BD3387.5030602@gmail.com> While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476 internal error: awaitEvent: descriptor out of range 2502 segfault with GHC.Handle.fdToHandle' 2511 unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351 NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063 Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Sep 2 19:56:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 2 20:22:28 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1220399791.24846.446.camel@localhost> On Thu, 2008-08-28 at 10:27 +0100, Simon Peyton-Jones wrote: > | So Cabal takes the view that the relationship between features and > | dependencies should be declarative. > ... > | The other principle is that the packager, the environment is in control > | over what things the package 'sees'. > ... > | that we can and that the approach is basically sound. The fact that we > | can automatically generate distro packages for hundreds of packages is > | not insignificant. This is just not possible with the autoconf approach. > ... > | Do you think that separating the Simple build system from the > | declarative part of Cabal would help? It'd make it more obvious that the > | build system part really is replaceable which currently is not so > | obvious since they're in the same package. I'm not averse to splitting > | them if it'd help. They're already completely partitioned internally. > > > Duncan, I'm not following every detail here, but it's clear that you > have some clear mental infrastructure in your head that informs and > underpins the way Cabal is. Cabal "takes the view that...", has > "principles", and "is clearly partitioned internally". > > These things are clear to you, but my sense it that they are *not* > clear even to other well-informed people. (I exclude myself from this > group.) It's like the Loch Ness monster: the bits above the waves > make sense only when you get an underwater picture that shows you the > monster underneath that explains why the humps surface in the way they > do. > > This isn't a criticism: one of the hardest thing to do is to > accurately convey this underwater stuff. But I wonder whether there > might be a useful paper hiding here? Something that establishes > terminology, writes down principles, explains the Cabal viewpoint, > contrasts with alternatives, and thereby allows discussion about Cabal > to be better informed. Yes. Of course there is ?Isaac's existing Cabal paper from '05 but there are also some more recent ideas. http://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/24num.pdf I think the way forward is after the upcoming GHC+Cabal release to take a step back and think about a design document for Cabal-2.x. It should incorporate the things we think were right from the original Cabal design document, things we've learnt along the way and try as much as possible to incorporate the criticisms that people have been making in recent months. The goal should be a design with a somewhat greater ambition than the original Cabal design which was mostly aimed at relatively simple, single package projects (a goal which has mostly been achieved). This would also be the right place to explain the configuration model properly, so that the people who are familiar with the autoconf model don't think we're just crazy. Not that they have to agree with us, but at least we should explain the tradeoffs and limitations in either direction. That should also help to clarify what is a limitation in the model vs what is a limitation in the current implementation of the model in current Cabal. The most obvious and immediate problem (apart perhaps from handling complex multi-package systems) is in specifying dependencies on Haskell code. I did start a discussion on this topic on the libraries mailing list in April/May. We didn't reach any really firm conclusions but it's clear that specifying just module names or just package versions is only an inexact proxy for what we really mean. Modules can be renamed, modules can move between packages, neither capture names or types of exported/imported entities let alone semantics. Various ideas were floated like precisely specifying or inferring interfaces, in a style somewhat like ML functors. > PS: concerning your last point, about "separating the Simple build > system", that might indeed be good. Indeed, the GHC plan described > here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I > think) precisely using the declarative part but not the build-system > part. I don't think it affects that really. GHC would still come with both parts if it were split into two packages and the exported modules and apis would not be changed by splitting. If splitting allowed one part to be separated out and not need to be a boot lib then it'd be a different matter but I don't think that's the case (which I think Ian confirmed in his reply). Splitting might help nhc98 and external perceptions. A possible downside is that it might make bootstrapping Cabal harder. Duncan From duncan.coutts at worc.ox.ac.uk Tue Sep 2 20:22:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 2 20:22:29 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1220401377.24846.460.camel@localhost> On Thu, 2008-08-28 at 15:02 +0100, Simon Peyton-Jones wrote: > | Yes this means that Cabal is less general than autoconf. It was quite a > | revelation when we discovered this during the design of Cabal - originally > | we were going to have everything done programmatically in the Setup.hs > | file, but then we realised that having the package configuration available > | *as data* gave us a lot more scope for automation, albeit at the expense of > | some generality. > > Now there's a useful insight for the paper I hope Duncan (or someone) is going to write > > configuration as code [autoconf] > vs > configuration as data [cabal] and there are more fine distinctions even than that. Each change in the power of the language used for configuration changes the range of things that the developer and packager/user can do, and in opposite directions. It's fairly similar to the tradeoffs between deep and shalow embeddings, but I think we more intermediate points. The challenge is in characterising the relationship between the language and the things the developer and packager can do so that we can pick a useful point (or points) in that tradeoff. Before anyone thinks about writing a paper on this topic, I recommend you read all of Eelco's papers[1] first just to make sure he's not already done it! :-) Which is another point that there's lots that Cabal (and ghc) can learn from Nix and related stuff. Duncan [1] http://nixos.org/docs/papers.html From pgavin at gmail.com Tue Sep 2 23:57:57 2008 From: pgavin at gmail.com (Peter Gavin) Date: Tue Sep 2 23:56:09 2008 Subject: rebinding arrow notation Message-ID: <48BE0B45.804@gmail.com> Section 8.3.5 of the documentation says: Arrow notation (see Section 8.9, ?Arrow notation ?) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! I want to do this. Is there anything special I should know? Pete From pgavin at gmail.com Wed Sep 3 00:09:28 2008 From: pgavin at gmail.com (Peter Gavin) Date: Wed Sep 3 00:07:45 2008 Subject: [Haskell-cafe] Re: Arrow without `>>>' In-Reply-To: References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: <48BE0DF8.9010108@gmail.com> Valery V. Vorotyntsev wrote: > On 1/23/08, David Menendez wrote: >> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: >>> I've built GHC from darcs, and... >>> Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' >>> method? >> It's derived from the Category superclass. > > Yes, it is. > > The right question: how to build `arrows' in such circumstances? > > Here go 2 changes I made to `CoState.hs' accompanied by the > error messages. :) Unfortunately, I'm not arrow-capable enough to > make _proper_ changes to the code and satisfy GHC... Any help? > Well, without looking at your code, generally all you have to do is 1) move the definition of (>>>) to Category and rename it to (.) after flipping the arguments. 2) define the id method of Category which is just (arr id) or returnA. So essentially instance Arrow (Foo a) where a >>> b = compose a b pure f = ... first a = ... becomes instance Arrow (Foo a) where pure f = ... first a = ... instance Category (Foo a) where id = arr id a . b = compose b a That's it. It's too bad there's no way to do this automatically in the libraries, but it could be noted in the API docs. Pete > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #1: > > $ darcs w Control/Arrow/Transformer/CoState.hs > What's new in "Control/Arrow/Transformer/CoState.hs": > > { > hunk ./Control/Arrow/Transformer/CoState.hs 23 > +import Control.Category ((>>>)) > } > > -------------------------------------------------- > Error #1: > > Control/Arrow/Transformer/CoState.hs:29:7: > `>>>' is not a (visible) method of class `Arrow' > Failed, modules loaded: Control.Arrow.Operations. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #2: > > $ darcs diff -u Control/Arrow/Transformer/CoState.hs > --- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > +++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > @@ -20,12 +20,13 @@ > > import Control.Arrow > import Control.Arrow.Operations > +import Control.Category ((>>>)) > > newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c)) > > instance Arrow a => Arrow (CoStateArrow s a) where > arr f = CST (arr (f .)) > - CST f >>> CST g = CST (f >>> g) > +-- CST f >>> CST g = CST (f >>> g) > first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap) > > zipMap :: (s -> a, s -> b) -> (s -> (a,b)) > > -------------------------------------------------- > Error#2: > > Control/Arrow/Transformer/CoState.hs:27:0: > Could not deduce (Control.Category.Category (CoStateArrow s a)) > from the context (Arrow a) > arising from the superclasses of an instance declaration > at Control/Arrow/Transformer/CoState.hs:27:0 > Possible fix: > add (Control.Category.Category > (CoStateArrow s a)) to the context of > the instance declaration > or add an instance declaration for > (Control.Category.Category (CoStateArrow s a)) > In the instance declaration for `Arrow (CoStateArrow s a)' > Failed, modules loaded: Control.Arrow.Operations. > > Thank you. > From simonpj at microsoft.com Wed Sep 3 03:43:02 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 3 03:41:10 2008 Subject: rebinding arrow notation In-Reply-To: <48BE0B45.804@gmail.com> References: <48BE0B45.804@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8809191@EA-EXMSG-C334.europe.corp.microsoft.com> | Section 8.3.5 of the documentation says: | | Arrow notation (see Section 8.9, ?Arrow notation ?) uses whatever arr, (>>>), | first, app, (|||) and loop functions are in scope. But unlike the other | constructs, the types of these functions must match the Prelude types very | closely. Details are in flux; if you want to use this, ask! | | I want to do this. Is there anything special I should know? To be honest I believe I wrote those words some years ago, so I no longer have a clue what the "flux" was. My suggestion would be to try it, starting with small examples, and we can go from there. The other thing to say is that the arrow code is Ross Patterson's, and regret to say that it's one part of GHC's code base that I do not grok in fullness. So before you commit to really needing this feature, check that either (a) it works or (b) Ross is willing to fix it (I'll help of course). Simon From iavor.diatchki at gmail.com Thu Sep 4 12:59:44 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Sep 4 12:57:52 2008 Subject: Build system idea In-Reply-To: <48B6AF34.2010601@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> Message-ID: <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> Hi, On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow wrote: > Because if you *can* use Cabal, you get a lot of value-adds for free (distro > packages, cabal-install, Haddock, source distributions, Hackage). What's > more, it's really cheap to use Cabal: a .cabal file is typically less than a > screenful, so it's no big deal to switch to something else later if you need > to. Well, I think this illustrates the current thinking of the Haskell community, where emphasis has been on making things either easy to do, or really hard/impossible to do (a kind of Mac approach to software development! :-). It has the benefit that it makes things seem really easy occasionally, but is it really honest? Concretely: cabal-install: it does not work well with packages that have flags because it does not know what flags to use when building dependencies. Really, packages with conditionals are different packages in one cabal file. Haddock: something seems wrong, if I need to use a specific build system to document my code! source distributions: cabal is really of very little help here as one has to enumerate everything that should be in the distribution. Hackage: Again, something is wrong if I should have to use a specific build system to distribute my code. distro-packages: I have not used these, but the only ones that I have heard about are Don's Arch packages, which are not binary packages, so there the problem is a bit simpler (still nice that it works though). In summary, it seems to me that there are two or three components that are tangled in the term "cabal": 1) a machine readable format for describing the meta-data associated with a package/application (+ a library that can process this meta data). 2) a build tool that has support for interacting with Haskell compilers and other tools that it knows about, to build a package. It seems to me that most of the benefits of cabal come from (1), and for most "simple" cases, (2) is just a way to avoid writing a completely mundane Makefile, while for more complex cases (2) basically doesn't work. -Iavor From duncan.coutts at worc.ox.ac.uk Thu Sep 4 16:30:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 16:27:02 2008 Subject: Build system idea In-Reply-To: <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> Message-ID: <1220560215.24846.576.camel@localhost> On Thu, 2008-09-04 at 09:59 -0700, Iavor Diatchki wrote: > Hi, > > On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow wrote: > > Because if you *can* use Cabal, you get a lot of value-adds for free (distro > > packages, cabal-install, Haddock, source distributions, Hackage). What's > > more, it's really cheap to use Cabal: a .cabal file is typically less than a > > screenful, so it's no big deal to switch to something else later if you need > > to. > > Well, I think this illustrates the current thinking of the Haskell > community, where emphasis has been on making things either easy to do, > or really hard/impossible to do (a kind of Mac approach to software > development! :-). It has the benefit that it makes things seem really > easy occasionally, but is it really honest? Concretely: > > cabal-install: it does not work well with packages that have flags > because it does not know what flags to use when building dependencies. > Really, packages with conditionals are different packages in one > cabal file. Packages are not supposed to expose different APIs with different flags so I don't think that's right. Under that assumption cabal-install can in principle resolve everything fine. I'm not claiming the current resolution algorithm is very clever when it comes to picking flags (though it should always pick ones that give an overall valid solution) but there is certainly scope for a cleverer one. Also, the user can always specify what features they want, which is what systems like Gentoo do. Do you have any specific test cases where the current algorithm is less than ideal? It'd be useful to report those for the next time someone hacks on the resolver. > Haddock: something seems wrong, if I need to use a specific build > system to document my code! You certainly do not need to use Cabal to use haddock. There are other build systems that integrate support for haddock (eg just makefiles). > source distributions: cabal is really of very little help here as one > has to enumerate everything that should be in the distribution. I think really in the end that the content does need to be specified. You can get quite a long way with inferring or discovering dependencies. Indeed it can work for build, but for source dist you need all the files, not just the ones used in this current build, so things like: #ifdef FOO import Foo #else import Bar #endif mean that if we cpp and then chase imports then we're stuffed, we'll miss one or the other. Trying to discover the deps before cpp is a lost cause becuase it's not just cpp to think about, there's all the other pre-processors, standard and custom. You can get your source control system to do your sdist, eg darcs can do that. It's great but not necessarily what you always want if you want to have files that live in your devel repo that are not included in the source tarball. Also if you want pre-processed files in the tarball it needs some help from the build system. > Hackage: Again, something is wrong if I should have to use a specific > build system to distribute my code. No, you only need to make a Cabal package. You can choose whatever build system you like so long as it presents that standard external command interface and metadata. I guess the fact that very few packages do use any build system other than the "Simple" build system does give the misleading impression that it's the only choice. > distro-packages: I have not used these, but the only ones that I have > heard about are Don's Arch packages, which are not binary packages, so > there the problem is a bit simpler (still nice that it works though). Don has done very well recently and generated a lot of excellent publicity. ?There are also disto packages maintained for Debian, Fedora, Gentoo, FreeBSD which have been around for years. I think Arch packages are binary packages, as are the Debian and Fedora ones. The FreeBSD, MacPorts and Gentoo packages are of course source based. > In summary, it seems to me that there are two or three components that > are tangled in the term "cabal": > 1) a machine readable format for describing the meta-data associated > with a package/application (+ a library that can process this meta > data). 1a) a standard interface for users and package managers to configure, build and install a package which can be implemented by multiple build systems including autoconf+make. > 2) a build tool that has support for interacting with Haskell > compilers and other tools that it knows about, to build a package. Right, a particular implementation of that interface with a bunch of extra features. > It seems to me that most of the benefits of cabal come from (1), and > for most "simple" cases, (2) is just a way to avoid writing a > completely mundane Makefile, while for more complex cases (2) > basically doesn't work. I'm not sure the makefiles were completely mundane, I'd more describe them as gnarly. :-) I would not underestimate the advantage for simple projects of not having to re-implement a build system. Being able to use a standard one and inherit new features and fixes for free is quite and advantage. There's also the issue of portability. For many packages the only thing preventing them from working on Windows was the use of make. Certainly, the Simple build system is not yet up to the task of building our most complex packages and will require some major surgery before we get near that. It is something we're working on, though perhaps not directly inside the current Cabal code base. Saizan's GSoC project was step 1 in that direction. As I mentioned elsewhere we should also take a step back and see what we need for Cabal-2, to think about what kind of design might scale. Duncan From leather at cs.uu.nl Thu Sep 4 19:08:35 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Sep 4 19:06:42 2008 Subject: Build system idea In-Reply-To: <1220560215.24846.576.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> <1220560215.24846.576.camel@localhost> Message-ID: <3c6288ab0809041608r5ba422a7h6cd2fed0e15abdae@mail.gmail.com> > > cabal-install: it does not work well with packages that have flags > > because it does not know what flags to use when building dependencies. > > Really, packages with conditionals are different packages in one > > cabal file. > > Packages are not supposed to expose different APIs with different flags > so I don't think that's right. Under that assumption cabal-install can > in principle resolve everything fine. I'm not claiming the current > resolution algorithm is very clever when it comes to picking flags > (though it should always pick ones that give an overall valid solution) > but there is certainly scope for a cleverer one. Also, the user can > always specify what features they want, which is what systems like > Gentoo do. > > Do you have any specific test cases where the current algorithm is less > than ideal? It'd be useful to report those for the next time someone > hacks on the resolver. > I have a package that builds a library and a test executable. The test executable uses QuickCheck 2, but I don't want to force random Jane who cabal-installs my package to install QuickCheck 2. One, it's not packaged up, and two, it's not necessary for using the library. The cleanest way I found to deal with this is to use a flag for hiding the build-depends of the test executable for the flag-less build. if flag(test) build-depends: QuickCheck >= 2.0 else buildable: False Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080905/98a08727/attachment-0001.htm From pgavin at gmail.com Thu Sep 4 19:13:13 2008 From: pgavin at gmail.com (Peter Gavin) Date: Thu Sep 4 19:11:20 2008 Subject: rebinding arrow notation In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8809191@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48BE0B45.804@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8809191@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48C06B89.7080109@gmail.com> Simon Peyton-Jones wrote: > | Section 8.3.5 of the documentation says: > | > | Arrow notation (see Section 8.9, ?Arrow notation ?) uses whatever arr, (>>>), > | first, app, (|||) and loop functions are in scope. But unlike the other > | constructs, the types of these functions must match the Prelude types very > | closely. Details are in flux; if you want to use this, ask! > | > | I want to do this. Is there anything special I should know? > > To be honest I believe I wrote those words some years ago, so I no longer have a clue what the "flux" was. My suggestion would be to try it, starting with small examples, and we can go from there. > > The other thing to say is that the arrow code is Ross Patterson's, and regret to say that it's one part of GHC's code base that I do not grok in fullness. So before you commit to really needing this feature, check that either (a) it works or (b) Ross is willing to fix it (I'll help of course). Ok. I guess I'm basically going to write the arrow version of the rmonad library on hackage. I'll let you know if I have any problems along the way. If it turns out I don't have any problems, I'll let you know that, too :) Pete From iavor.diatchki at gmail.com Fri Sep 5 02:15:34 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Sep 5 02:13:39 2008 Subject: Build system idea In-Reply-To: <1220560215.24846.576.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <5ab17e790809040959y48259f0s9d28b771069cac2e@mail.gmail.com> <1220560215.24846.576.camel@localhost> Message-ID: <5ab17e790809042315n618b9089j667a7aa130ae823d@mail.gmail.com> Hello, On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts wrote: >> cabal-install: it does not work well with packages that have flags >> because it does not know what flags to use when building dependencies. >> Really, packages with conditionals are different packages in one >> cabal file. > > Packages are not supposed to expose different APIs with different flags > so I don't think that's right. Under that assumption cabal-install can > in principle resolve everything fine. I'm not claiming the current > resolution algorithm is very clever when it comes to picking flags > (though it should always pick ones that give an overall valid solution) > but there is certainly scope for a cleverer one. Also, the user can > always specify what features they want, which is what systems like > Gentoo do. > > Do you have any specific test cases where the current algorithm is less > than ideal? It'd be useful to report those for the next time someone > hacks on the resolver. The examples that I was thinking of arise when libraries can provide conditional functionality, depending on what is already installed on the system, a kind of "co-dependecy". For a concrete example, take a look at the JSON library that I wrote (I think that it is on hackage). It provides a number of different modules containing parsers written with different parser combinators: one that does not use a library, one that uses ReadP, and one that uses Parsec. The idea was that we do not want to force people to install a particular parser combinator library, instead, we provide compatibility with many different ones. Certainly, JSON does not require _all_ libraries to be installed, but the way the flags are at the moment, I think that that is what happens if you just use cabal-install. (The same sort of thing happens when a library provides instances for datatypes defined in different packages---these instances are often not required by the library, but are useful _if you have the other package installed_.) I guess, you could say that we structured the library wrong---perhaps we should have had a core package that only provides manual parsing (no external libraries required), and then have a separate packages for each of the parsers that use a different parsing combinator library. Conceptually, this might be better, but in practice it seems like a bit of a pain---each parser is a single module, but it would need a whole separate directory, with a separate cabal file, license, and a setup script, all of which would be almost copies of each other. Similarly, in the case of providing instances for datatypes from different packages, one would end up with a separate package for each set of instances, which would result in a proliferation of tiny packages. It seems that this problem should be solvable though... :-) (by the way, this has little to do with the GHC build system, so perhaps we should start a separate thread?) -Iavor From neil.mitchell.2 at credit-suisse.com Fri Sep 5 10:14:49 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Sep 5 10:13:32 2008 Subject: (no subject) Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD398B@ELON17P32001A.csfb.cs-group.com> Hi Claus, I was reading your instructions on the GHC wiki page, http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are wonderful - exactly what I wanted. However, they don't work. When downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path so it can pick up the setup.ini file. However, in the latest version of Cygwin it obvious wants signatures for all the .ini files: --------------------------- Cygwin Setup --------------------------- Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from --------------------------- OK --------------------------- Could someone please add the appropriate signature file? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From claus.reinke at talk21.com Fri Sep 5 12:56:28 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 5 12:54:37 2008 Subject: (no subject) References: <33A3F585590A6F4E81E3D45AA4A111C902CD398B@ELON17P32001A.csfb.cs-group.com> Message-ID: <840DD960310C4FB3B6D1777A7E616EAB@cr3lt> Hi Neil, >I was reading your instructions on the GHC wiki page, >http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are >wonderful - exactly what I wanted. However, they don't work. When >downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path >so it can pick up the setup.ini file. However, in the latest version of >Cygwin it obvious wants signatures for all the .ini files: > >--------------------------- >Cygwin Setup >--------------------------- >Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from > >--------------------------- >OK >--------------------------- > >Could someone please add the appropriate signature file? Grr, not just the Haskell Cabal keeps marching on. Apparently, that is a change in last month's setup.exe: Updated: Setup.exe updated to version 2.573.2.3 http://cygwin.com/ml/cygwin-announce/2008-08/msg00001.html If I understand the implications correctly, one would need a three point change to adapt properly: - sign the setup.ini file with a key, in place - put up a public key to check against, somewhere else - point setup.exe to the location of the public key Given that all we want are the dependencies (the package is empty), this is starting to look ridiculous (one has to put in more administrative information than one saves from not having to specify the dependencies by hand..). Meanwhile, there is apparently a command-line option to bypass the check, when using setup.exe on this repository: -X --no-verify Don't verify setup.ini signatures You can easily check the package contents yourself before/after downloading (because it is empty, only the setup.ini text matters;-). Of course, I wouldn't recommend using that switch while you're also sourcing from another repository (the verification has been added for a reason), so one would have to recommend running setup.exe twice, once with verification for the main stuff, once without for ghc-depends? But setup.exe will presumably want to run the check on both downloading and installing, and since the dependencies ought to be installed with verification, it isn't quite clear to me whether there is a successful sequence of calling setup.exe, unless ghc-depends is signed and an additional key is provided.. GHC HQ: unless you want to sign that package, and provide a key to check against, I don't know what to do about this. Please remember to update the log on the wiki page when you succeed - the value of this log comes from being applied from scratch (when just updating, it is easy to miss something). Thanks, Claus From neil.mitchell.2 at credit-suisse.com Mon Sep 8 04:40:47 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 8 04:39:15 2008 Subject: Windows build failure Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> Hi, I've just tried building GHC HEAD using GHC 6.8.3 on Windows following the instructions on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) I initially got a failure about cc1 not being found when executing 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at the end of the path (i.e. last priority) After this error I get a problem with include files, see the attached log file. It looks like include files are going wrong between Mingw and 6.8.3. My current $PATH variable is: /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr ive/c/WI NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi ktex/bin :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT /system3 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem :/cygdri ve/c/Utils:/cygdrive/c/Program Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program Files/Ha skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg drive/f/ Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log.gz Type: application/x-gzip Size: 4327 bytes Desc: make.log.gz Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080908/570480e3/make.log.bin From neil.mitchell.2 at credit-suisse.com Mon Sep 8 06:40:55 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 8 06:39:19 2008 Subject: Windows build In-Reply-To: <840DD960310C4FB3B6D1777A7E616EAB@cr3lt> References: <33A3F585590A6F4E81E3D45AA4A111C902CD398B@ELON17P32001A.csfb.cs-group.com> <840DD960310C4FB3B6D1777A7E616EAB@cr3lt> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3996@ELON17P32001A.csfb.cs-group.com> Hi Claus, > If I understand the implications correctly, one would need a three point change to adapt properly: > - sign the setup.ini file with a key, in place > - put up a public key to check against, somewhere else > - point setup.exe to the location of the public key > Given that all we want are the dependencies (the package is empty), this is starting to look ridiculous (one has to put in more administrative information than one saves from not having to specify the dependencies by hand..). However, the dependency package is very useful, so if its not too much work, it would be useful. > Please remember to update the log on the wiki page when you succeed - the value of this log comes from being > applied from scratch (when just updating, it is easy to miss something). I am keeping an up to date list of what I do and what works, so will combine it in once I have a working build. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 8 08:22:15 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 8 08:20:07 2008 Subject: Making GHC work on BSD Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> Dear BDS hackers We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD. Alas, we didn't get much response to Simon's message below. (One, I think -- thank you to that person! I think it was Kili, but I'm not sure.) So this message is to say: if you'd like GHC on BSD, please help! No help probably means no GHC. Time is short before GHC 6.10. "Help" means more than "can offer a remote login", but less than "solve it by yourself". We'll try hard to support you if you can invest a bit of time at your end. Many thanks Simon -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 02 September 2008 13:37 To: GHC Users Mailing List Cc: cvs-ghc@haskell.org Subject: *BSD GHC hackers needed... While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476 internal error: awaitEvent: descriptor out of range 2502 segfault with GHC.Handle.fdToHandle' 2511 unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351 NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063 Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From donn at avvanta.com Mon Sep 8 12:10:27 2008 From: donn at avvanta.com (Donn Cave) Date: Mon Sep 8 12:08:21 2008 Subject: Making GHC work on BSD References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080908161027.41D5993C8D@mail.avvanta.com> Quoth Simon Peyton-Jones : | Dear BDS hackers ... | So this message is to say: if you'd like GHC on BSD, please help! No help | probably means no GHC. Time is short before GHC 6.10. ... | There's also one NetBSD-specific ticket: | | 2351 NetBSD defines ELF_ST_TYPE In case I didn't express myself very well when I posted that ticket - the ideal fix should be to replace the FreeBSD-specific support in the amd64 case, with the non-platorm-specific logic that 6.8.3 has for the i386 case. There is no need for attention from a NetBSD expert. | ... and one that I think applies to all the *BSDs: | | 2063 Breackage on OpenBSD due to mmap remap | | (actually the latter one is a top priority, because without it GHCi can't | work, so we need it fixed for 6.10.1). Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an optional package for NetBSD/i386 4.0, with ghci included and without any mmap patches as far as I know. It was also working for me on NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?) NetBSD does require a number of other patches to build correctly - I count 18, the bulk of which relate to 1) finding readline when it isn't in a path automatically searched by the compiler, and 2) NetBSD renamed system functions. (They also include the above mentioned ELF_ST_TYPE patch.) These patches are applied by the NetBSD package maintainer, but are also available separately through the package system. Donn Cave, donn@avvanta.com From naur at post11.tele.dk Mon Sep 8 16:08:27 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Mon Sep 8 16:10:07 2008 Subject: Making GHC work on BSD In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200809082208.28969.naur@post11.tele.dk> Hello, On Monday 08 September 2008 14:22, Simon Peyton-Jones wrote: > Dear BDS hackers > > We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD. I would like to do something about this. I have (a number of) x86s that either have some FreeBSD version installed or could get such an installation without too much trouble. The easiest one has an (admittedly old) 5.4 FreeBSD installed, that machine is running at the moment, it has actually managed to build > tn@tn21$ compiler/stage2/ghc-inplace --version > The Glorious Glasgow Haskell Compilation System, version 6.9.20080517 using > tn@tn21$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.4.1 and > tn@tn21$ compiler/stage2/ghc-inplace --interactive > GHCi, version 6.9.20080517: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> 2+2 > 4 works sometimes, but validate is a catastrophy (this is a dormant project). Another machine has some FreeBSD 6.x (I haven't checked), but I don't think it has any GHC running on it at the moment. A third possibility would be to take the latest (7.0) FreeBSD and install that. So, it would be useful to know, which FreeBSD version would you prefer to use for this? > ... Best regards Thorkil From neil.mitchell.2 at credit-suisse.com Tue Sep 9 07:08:12 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Sep 9 07:06:33 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> Hi, I worked around the first problem, lacking cc1, by following the instructions here: http://www.nabble.com/cc1-not-found-td9742088.html - adding c:\mingw\libexec\gcc\mingw32\3.4.5 to the $PATH. Then I get a shorter error: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=c:/ghc/ghc-6.8.3/bin/ghc --with-hc-pkg=c:/ghc/ghc-6.8.3/bin/ghc -pkg --package-db=c:/ghc-build/ghc/libraries/bootstrapping.conf.tmp Configuring hpc-0.5... cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... In file included from /mingw/lib/gcc/mingw32/3.4.5/../../../../include/float.h:1 9, from c:/ghc/ghc-6.8.3/include/mingw/float.h:19, from c:/ghc/ghc-6.8.3/include/HsFFI.h:69, from c:/ghc/ghc-6.8.3/template-hsc.h:4, from dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c:1: /mingw/include/float.h:102: error: syntax error before "_controlfp" /mingw/include/float.h:103: error: syntax error before "_control87" /mingw/include/float.h:106: error: syntax error before "_clearfp" /mingw/include/float.h:107: error: syntax error before "_statusfp" /mingw/include/float.h:121: error: syntax error before "_fpreset" /mingw/include/float.h:122: error: syntax error before "fpreset" /mingw/include/float.h:125: error: syntax error before "__fpecode" /mingw/include/float.h:133: error: syntax error before "_chgsign" /mingw/include/float.h:134: error: syntax error before "_copysign" /mingw/include/float.h:135: error: syntax error before "_logb" /mingw/include/float.h:136: error: syntax error before "_nextafter" /mingw/include/float.h:137: error: syntax error before "_scalb" /mingw/include/float.h:139: error: syntax error before "_finite" /mingw/include/float.h:140: error: syntax error before "_fpclass" /mingw/include/float.h:141: error: syntax error before "_isnan" compiling dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c failed command was: c:\ghc\ghc-6.8.3\gcc.exe -c -D__GLASGOW_HASKELL__=608 -Ic:\ghc\ghc- 6.8.3/lib\directory-1.0.0.1\include -Ic:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0\incl ude -Ic:\ghc\ghc-6.8.3/lib\base-3.0.2.0\include -Ic:\ghc\ghc-6.8.3/include -Ic:\ ghc\ghc-6.8.3/include/mingw dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make. c -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 An example of the first error: _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _controlfp (unsigned int unNew, unsigned int unMask); And all the error lines seem to have _MINGW_NOTHROW just before the syntax error. I therefore added: #define __MINGW_NOTHROW To the mingw\include\float.h header - which is clearly not a good idea to do in general, but may hack it enough until a build expert can give me the right fix. The next error I got was: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... \mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: crtbegin.o: No such file: No such file or directory linking dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o failed command was: c:\ghc\ghc-6.8.3\gcc.exe -Lc:\ghc\ghc-6.8.3/lib\directory-1.0.0.1 - Lc:\ghc\ghc-6.8.3/lib\filepath-1.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0 - Lc:\ghc\ghc-6.8.3/lib\old-locale-1.0.0.0 -Lc:\ghc\ghc-6.8.3/lib\containers-0.1.0 .2 -Lc:\ghc\ghc-6.8.3/lib\array-0.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\base-3.0.2.0 -lws ock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -Lc:\ghc\ghc-6.8.3 -Lc:\ghc\ghc-6.8 .3/gcc-lib -lm -lgmp -lwsock32 dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_ma ke.o -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.exe make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a copy of crtbegin.o. That didn't work. So I then copied crtbegin.o and crtend.o into c:\mingw\lib. That seemed to be enough to get past hpc, but again is just a short-term hack. My build is still going, and I'll report back once it either fails or succeeds. However, a general fix does need to be developed for the two issues above. Adding cc1 to the path can probably go in as an instruction for setting up the build environment. It would be incredibly useful if someone wrote a windows-build.sh command that automated as many steps as possible in the list Claus made, and checked for all the others - i.e. checking darcs is on the path, checking appropriate versions where possible, checking mingw gcc is first etc. If no one else does, I probably will when I install Windows on my home machine. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 08 September 2008 9:41 am To: 'glasgow-haskell-users@haskell.org' Subject: Windows build failure Hi, I've just tried building GHC HEAD using GHC 6.8.3 on Windows following the instructions on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) I initially got a failure about cc1 not being found when executing 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at the end of the path (i.e. last priority) After this error I get a problem with include files, see the attached log file. It looks like include files are going wrong between Mingw and 6.8.3. My current $PATH variable is: /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr ive/c/WI NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi ktex/bin :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT /system3 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem :/cygdri ve/c/Utils:/cygdrive/c/Program Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program Files/Ha skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg drive/f/ Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From neil.mitchell.2 at credit-suisse.com Tue Sep 9 09:56:28 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Sep 9 09:54:53 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> Hi I've now got a build of GHC, and a binary distribution. The compilation succeeded after the hacks detailed in the previous message. There are now two issues: * runhaskell isn't in ghc/bin - but runghc is. I guess something forgot to get copied or created. This issue is very minor to me, but will be of great significance if it was missing in a release. * The ghc API package hasn't been installed. "ghc-pkg list" gives: C:\Neil\haddock>ghc-pkg list C:/ghc/ghc-6.9.20080905\package.conf: Cabal-1.5.4, Win32-2.1, array-0.1, base-3.0.3.0, base-4.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, ghc-prim-0.1, {haddock-2.2.2}, haskell98-1.0.1, hpc-0.5, integer-0.1, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0.1, random-1.0, rts-1.0, syb-0.1, template-haskell-2.2 My aim of building GHC was to run haddock (and eventually hoogle), so not having the ghc library available is a problem. Does something have to be configured to get the library? Is it hiding somewhere, just not exposed? How did haddock-2.2.2 get installed and compiled without a ghc library? Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 12:08 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi, I worked around the first problem, lacking cc1, by following the instructions here: http://www.nabble.com/cc1-not-found-td9742088.html - adding c:\mingw\libexec\gcc\mingw32\3.4.5 to the $PATH. Then I get a shorter error: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=c:/ghc/ghc-6.8.3/bin/ghc --with-hc-pkg=c:/ghc/ghc-6.8.3/bin/ghc -pkg --package-db=c:/ghc-build/ghc/libraries/bootstrapping.conf.tmp Configuring hpc-0.5... cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... In file included from /mingw/lib/gcc/mingw32/3.4.5/../../../../include/float.h:1 9, from c:/ghc/ghc-6.8.3/include/mingw/float.h:19, from c:/ghc/ghc-6.8.3/include/HsFFI.h:69, from c:/ghc/ghc-6.8.3/template-hsc.h:4, from dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c:1: /mingw/include/float.h:102: error: syntax error before "_controlfp" /mingw/include/float.h:103: error: syntax error before "_control87" /mingw/include/float.h:106: error: syntax error before "_clearfp" /mingw/include/float.h:107: error: syntax error before "_statusfp" /mingw/include/float.h:121: error: syntax error before "_fpreset" /mingw/include/float.h:122: error: syntax error before "fpreset" /mingw/include/float.h:125: error: syntax error before "__fpecode" /mingw/include/float.h:133: error: syntax error before "_chgsign" /mingw/include/float.h:134: error: syntax error before "_copysign" /mingw/include/float.h:135: error: syntax error before "_logb" /mingw/include/float.h:136: error: syntax error before "_nextafter" /mingw/include/float.h:137: error: syntax error before "_scalb" /mingw/include/float.h:139: error: syntax error before "_finite" /mingw/include/float.h:140: error: syntax error before "_fpclass" /mingw/include/float.h:141: error: syntax error before "_isnan" compiling dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c failed command was: c:\ghc\ghc-6.8.3\gcc.exe -c -D__GLASGOW_HASKELL__=608 -Ic:\ghc\ghc- 6.8.3/lib\directory-1.0.0.1\include -Ic:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0\incl ude -Ic:\ghc\ghc-6.8.3/lib\base-3.0.2.0\include -Ic:\ghc\ghc-6.8.3/include -Ic:\ ghc\ghc-6.8.3/include/mingw dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make. c -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 An example of the first error: _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _controlfp (unsigned int unNew, unsigned int unMask); And all the error lines seem to have _MINGW_NOTHROW just before the syntax error. I therefore added: #define __MINGW_NOTHROW To the mingw\include\float.h header - which is clearly not a good idea to do in general, but may hack it enough until a build expert can give me the right fix. The next error I got was: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... \mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: crtbegin.o: No such file: No such file or directory linking dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o failed command was: c:\ghc\ghc-6.8.3\gcc.exe -Lc:\ghc\ghc-6.8.3/lib\directory-1.0.0.1 - Lc:\ghc\ghc-6.8.3/lib\filepath-1.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0 - Lc:\ghc\ghc-6.8.3/lib\old-locale-1.0.0.0 -Lc:\ghc\ghc-6.8.3/lib\containers-0.1.0 .2 -Lc:\ghc\ghc-6.8.3/lib\array-0.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\base-3.0.2.0 -lws ock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -Lc:\ghc\ghc-6.8.3 -Lc:\ghc\ghc-6.8 .3/gcc-lib -lm -lgmp -lwsock32 dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_ma ke.o -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.exe make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a copy of crtbegin.o. That didn't work. So I then copied crtbegin.o and crtend.o into c:\mingw\lib. That seemed to be enough to get past hpc, but again is just a short-term hack. My build is still going, and I'll report back once it either fails or succeeds. However, a general fix does need to be developed for the two issues above. Adding cc1 to the path can probably go in as an instruction for setting up the build environment. It would be incredibly useful if someone wrote a windows-build.sh command that automated as many steps as possible in the list Claus made, and checked for all the others - i.e. checking darcs is on the path, checking appropriate versions where possible, checking mingw gcc is first etc. If no one else does, I probably will when I install Windows on my home machine. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 08 September 2008 9:41 am To: 'glasgow-haskell-users@haskell.org' Subject: Windows build failure Hi, I've just tried building GHC HEAD using GHC 6.8.3 on Windows following the instructions on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) I initially got a failure about cc1 not being found when executing 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at the end of the path (i.e. last priority) After this error I get a problem with include files, see the attached log file. It looks like include files are going wrong between Mingw and 6.8.3. My current $PATH variable is: /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr ive/c/WI NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi ktex/bin :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT /system3 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem :/cygdri ve/c/Utils:/cygdrive/c/Program Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program Files/Ha skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg drive/f/ Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marlowsd at gmail.com Tue Sep 9 10:00:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 9 09:58:58 2008 Subject: Making GHC work on BSD In-Reply-To: <20080908161027.41D5993C8D@mail.avvanta.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <20080908161027.41D5993C8D@mail.avvanta.com> Message-ID: <48C6819B.1080406@gmail.com> Donn Cave wrote: > | ... and one that I think applies to all the *BSDs: > | > | 2063 Breackage on OpenBSD due to mmap remap > | > | (actually the latter one is a top priority, because without it GHCi can't > | work, so we need it fixed for 6.10.1). > > Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an > optional package for NetBSD/i386 4.0, with ghci included and without > any mmap patches as far as I know. It was also working for me on > NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?) Yes, the code changed in the HEAD, and currently uses mremap(), which only exists on Linux. We need similar hacks that were done in 6.8.3 to get the BSDs to work, that is to allocate memory from some predefined address in the lower 2Gb of the address space. Cheers, Simon From neil.mitchell.2 at credit-suisse.com Tue Sep 9 10:05:14 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Sep 9 10:05:15 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39A6@ELON17P32001A.csfb.cs-group.com> Hi The haddock placed in bin/ also seems to want to find bin/inplace-datadir/package.conf, which isn't in the distribution tarball as well. I guess haddock either needs building again, or not distributing. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 2:56 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi I've now got a build of GHC, and a binary distribution. The compilation succeeded after the hacks detailed in the previous message. There are now two issues: * runhaskell isn't in ghc/bin - but runghc is. I guess something forgot to get copied or created. This issue is very minor to me, but will be of great significance if it was missing in a release. * The ghc API package hasn't been installed. "ghc-pkg list" gives: C:\Neil\haddock>ghc-pkg list C:/ghc/ghc-6.9.20080905\package.conf: Cabal-1.5.4, Win32-2.1, array-0.1, base-3.0.3.0, base-4.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, ghc-prim-0.1, {haddock-2.2.2}, haskell98-1.0.1, hpc-0.5, integer-0.1, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0.1, random-1.0, rts-1.0, syb-0.1, template-haskell-2.2 My aim of building GHC was to run haddock (and eventually hoogle), so not having the ghc library available is a problem. Does something have to be configured to get the library? Is it hiding somewhere, just not exposed? How did haddock-2.2.2 get installed and compiled without a ghc library? Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 12:08 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi, I worked around the first problem, lacking cc1, by following the instructions here: http://www.nabble.com/cc1-not-found-td9742088.html - adding c:\mingw\libexec\gcc\mingw32\3.4.5 to the $PATH. Then I get a shorter error: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=c:/ghc/ghc-6.8.3/bin/ghc --with-hc-pkg=c:/ghc/ghc-6.8.3/bin/ghc -pkg --package-db=c:/ghc-build/ghc/libraries/bootstrapping.conf.tmp Configuring hpc-0.5... cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... In file included from /mingw/lib/gcc/mingw32/3.4.5/../../../../include/float.h:1 9, from c:/ghc/ghc-6.8.3/include/mingw/float.h:19, from c:/ghc/ghc-6.8.3/include/HsFFI.h:69, from c:/ghc/ghc-6.8.3/template-hsc.h:4, from dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c:1: /mingw/include/float.h:102: error: syntax error before "_controlfp" /mingw/include/float.h:103: error: syntax error before "_control87" /mingw/include/float.h:106: error: syntax error before "_clearfp" /mingw/include/float.h:107: error: syntax error before "_statusfp" /mingw/include/float.h:121: error: syntax error before "_fpreset" /mingw/include/float.h:122: error: syntax error before "fpreset" /mingw/include/float.h:125: error: syntax error before "__fpecode" /mingw/include/float.h:133: error: syntax error before "_chgsign" /mingw/include/float.h:134: error: syntax error before "_copysign" /mingw/include/float.h:135: error: syntax error before "_logb" /mingw/include/float.h:136: error: syntax error before "_nextafter" /mingw/include/float.h:137: error: syntax error before "_scalb" /mingw/include/float.h:139: error: syntax error before "_finite" /mingw/include/float.h:140: error: syntax error before "_fpclass" /mingw/include/float.h:141: error: syntax error before "_isnan" compiling dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c failed command was: c:\ghc\ghc-6.8.3\gcc.exe -c -D__GLASGOW_HASKELL__=608 -Ic:\ghc\ghc- 6.8.3/lib\directory-1.0.0.1\include -Ic:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0\incl ude -Ic:\ghc\ghc-6.8.3/lib\base-3.0.2.0\include -Ic:\ghc\ghc-6.8.3/include -Ic:\ ghc\ghc-6.8.3/include/mingw dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make. c -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 An example of the first error: _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _controlfp (unsigned int unNew, unsigned int unMask); And all the error lines seem to have _MINGW_NOTHROW just before the syntax error. I therefore added: #define __MINGW_NOTHROW To the mingw\include\float.h header - which is clearly not a good idea to do in general, but may hack it enough until a build expert can give me the right fix. The next error I got was: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... \mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: crtbegin.o: No such file: No such file or directory linking dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o failed command was: c:\ghc\ghc-6.8.3\gcc.exe -Lc:\ghc\ghc-6.8.3/lib\directory-1.0.0.1 - Lc:\ghc\ghc-6.8.3/lib\filepath-1.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0 - Lc:\ghc\ghc-6.8.3/lib\old-locale-1.0.0.0 -Lc:\ghc\ghc-6.8.3/lib\containers-0.1.0 .2 -Lc:\ghc\ghc-6.8.3/lib\array-0.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\base-3.0.2.0 -lws ock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -Lc:\ghc\ghc-6.8.3 -Lc:\ghc\ghc-6.8 .3/gcc-lib -lm -lgmp -lwsock32 dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_ma ke.o -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.exe make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a copy of crtbegin.o. That didn't work. So I then copied crtbegin.o and crtend.o into c:\mingw\lib. That seemed to be enough to get past hpc, but again is just a short-term hack. My build is still going, and I'll report back once it either fails or succeeds. However, a general fix does need to be developed for the two issues above. Adding cc1 to the path can probably go in as an instruction for setting up the build environment. It would be incredibly useful if someone wrote a windows-build.sh command that automated as many steps as possible in the list Claus made, and checked for all the others - i.e. checking darcs is on the path, checking appropriate versions where possible, checking mingw gcc is first etc. If no one else does, I probably will when I install Windows on my home machine. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 08 September 2008 9:41 am To: 'glasgow-haskell-users@haskell.org' Subject: Windows build failure Hi, I've just tried building GHC HEAD using GHC 6.8.3 on Windows following the instructions on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) I initially got a failure about cc1 not being found when executing 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at the end of the path (i.e. last priority) After this error I get a problem with include files, see the attached log file. It looks like include files are going wrong between Mingw and 6.8.3. My current $PATH variable is: /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr ive/c/WI NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi ktex/bin :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT /system3 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem :/cygdri ve/c/Utils:/cygdrive/c/Program Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program Files/Ha skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg drive/f/ Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Tue Sep 9 10:32:36 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Sep 9 10:30:22 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8AB9A@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks very much Neil; we (well Ian!) will digest your efforts. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Mitchell, Neil | Sent: 09 September 2008 14:56 | To: glasgow-haskell-users@haskell.org | Subject: RE: Windows build failure | | Hi | | I've now got a build of GHC, and a binary distribution. The compilation | succeeded after the hacks detailed in the previous message. | | There are now two issues: | | * runhaskell isn't in ghc/bin - but runghc is. I guess something forgot | to get copied or created. This issue is very minor to me, but will be of | great significance if it was missing in a release. | | * The ghc API package hasn't been installed. "ghc-pkg list" gives: | | C:\Neil\haddock>ghc-pkg list | C:/ghc/ghc-6.9.20080905\package.conf: | Cabal-1.5.4, Win32-2.1, array-0.1, base-3.0.3.0, base-4.0, | bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, | ghc-prim-0.1, {haddock-2.2.2}, haskell98-1.0.1, hpc-0.5, | integer-0.1, old-locale-1.0, old-time-1.0, packedstring-0.1, | pretty-1.0, process-1.0.1, random-1.0, rts-1.0, syb-0.1, | template-haskell-2.2 | | My aim of building GHC was to run haddock (and eventually hoogle), so | not having the ghc library available is a problem. Does something have | to be configured to get the library? Is it hiding somewhere, just not | exposed? How did haddock-2.2.2 get installed and compiled without a ghc | library? | | Thanks | | Neil | | -----Original Message----- | From: Mitchell, Neil | Sent: 09 September 2008 12:08 pm | To: 'glasgow-haskell-users@haskell.org' | Subject: RE: Windows build failure | | Hi, | | I worked around the first problem, lacking cc1, by following the | instructions here: http://www.nabble.com/cc1-not-found-td9742088.html - | adding c:\mingw\libexec\gcc\mingw32\3.4.5 to the $PATH. Then I get a | shorter error: | | cd hpc && c:/ghc-build/ghc/libraries/cabal-bin | c:/ghc/ghc-6.8.3/bin/ghc c:/gh | c-build/ghc/libraries/bootstrapping.conf configure | --distpref=dist-bootstrapping --with-compiler=c:/ghc/ghc-6.8.3/bin/ghc | --with-hc-pkg=c:/ghc/ghc-6.8.3/bin/ghc | -pkg --package-db=c:/ghc-build/ghc/libraries/bootstrapping.conf.tmp | Configuring hpc-0.5... | cd hpc && c:/ghc-build/ghc/libraries/cabal-bin | c:/ghc/ghc-6.8.3/bin/ghc c:/gh | c-build/ghc/libraries/bootstrapping.conf build | --distpref=dist-bootstrapping | | Preprocessing library hpc-0.5... | In file included from | /mingw/lib/gcc/mingw32/3.4.5/../../../../include/float.h:1 | 9, | from c:/ghc/ghc-6.8.3/include/mingw/float.h:19, | from c:/ghc/ghc-6.8.3/include/HsFFI.h:69, | from c:/ghc/ghc-6.8.3/template-hsc.h:4, | from | dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c:1: | /mingw/include/float.h:102: error: syntax error before "_controlfp" | /mingw/include/float.h:103: error: syntax error before "_control87" | /mingw/include/float.h:106: error: syntax error before "_clearfp" | /mingw/include/float.h:107: error: syntax error before "_statusfp" | /mingw/include/float.h:121: error: syntax error before "_fpreset" | /mingw/include/float.h:122: error: syntax error before "fpreset" | /mingw/include/float.h:125: error: syntax error before "__fpecode" | /mingw/include/float.h:133: error: syntax error before "_chgsign" | /mingw/include/float.h:134: error: syntax error before "_copysign" | /mingw/include/float.h:135: error: syntax error before "_logb" | /mingw/include/float.h:136: error: syntax error before "_nextafter" | /mingw/include/float.h:137: error: syntax error before "_scalb" | /mingw/include/float.h:139: error: syntax error before "_finite" | /mingw/include/float.h:140: error: syntax error before "_fpclass" | /mingw/include/float.h:141: error: syntax error before "_isnan" | compiling dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c failed | command was: c:\ghc\ghc-6.8.3\gcc.exe -c -D__GLASGOW_HASKELL__=608 | -Ic:\ghc\ghc- 6.8.3/lib\directory-1.0.0.1\include | -Ic:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0\incl | ude -Ic:\ghc\ghc-6.8.3/lib\base-3.0.2.0\include | -Ic:\ghc\ghc-6.8.3/include -Ic:\ ghc\ghc-6.8.3/include/mingw | dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make. | c -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o | make[1]: *** [bootstrapping.conf] Error 1 | make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' | make: *** [stage1] Error 2 | | An example of the first error: | | _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _controlfp (unsigned int | unNew, unsigned int unMask); | | And all the error lines seem to have _MINGW_NOTHROW just before the | syntax error. I therefore added: | | #define __MINGW_NOTHROW | | To the mingw\include\float.h header - which is clearly not a good idea | to do in general, but may hack it enough until a build expert can give | me the right fix. | | The next error I got was: | | cd hpc && c:/ghc-build/ghc/libraries/cabal-bin | c:/ghc/ghc-6.8.3/bin/ghc c:/gh | c-build/ghc/libraries/bootstrapping.conf build | --distpref=dist-bootstrapping | | Preprocessing library hpc-0.5... | \mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: crtbegin.o: No such | file: No such file or directory linking | dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o failed command | was: c:\ghc\ghc-6.8.3\gcc.exe -Lc:\ghc\ghc-6.8.3/lib\directory-1.0.0.1 - | Lc:\ghc\ghc-6.8.3/lib\filepath-1.1.0.0 | -Lc:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0 - | Lc:\ghc\ghc-6.8.3/lib\old-locale-1.0.0.0 | -Lc:\ghc\ghc-6.8.3/lib\containers-0.1.0 | .2 -Lc:\ghc\ghc-6.8.3/lib\array-0.1.0.0 | -Lc:\ghc\ghc-6.8.3/lib\base-3.0.2.0 -lws | ock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -Lc:\ghc\ghc-6.8.3 | -Lc:\ghc\ghc-6.8 .3/gcc-lib -lm -lgmp -lwsock32 | dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_ma | ke.o -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.exe | make[1]: *** [bootstrapping.conf] Error 1 | make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' | make: *** [stage1] Error 2 | | So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a | copy of crtbegin.o. That didn't work. So I then copied crtbegin.o and | crtend.o into c:\mingw\lib. That seemed to be enough to get past hpc, | but again is just a short-term hack. | | My build is still going, and I'll report back once it either fails or | succeeds. However, a general fix does need to be developed for the two | issues above. Adding cc1 to the path can probably go in as an | instruction for setting up the build environment. | | It would be incredibly useful if someone wrote a windows-build.sh | command that automated as many steps as possible in the list Claus made, | and checked for all the others - i.e. checking darcs is on the path, | checking appropriate versions where possible, checking mingw gcc is | first etc. If no one else does, I probably will when I install Windows | on my home machine. | | Thanks | | Neil | | -----Original Message----- | From: Mitchell, Neil | Sent: 08 September 2008 9:41 am | To: 'glasgow-haskell-users@haskell.org' | Subject: Windows build failure | | Hi, | | I've just tried building GHC HEAD using GHC 6.8.3 on Windows following | the instructions on the wiki | (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) | | I initially got a failure about cc1 not being found when executing | 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at | the end of the path (i.e. last priority) | | After this error I get a problem with include files, see the attached | log file. It looks like include files are going wrong between Mingw and | 6.8.3. My current $PATH variable is: | | /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr | ive/c/WI | NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi | ktex/bin | :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT | /system3 | 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem | :/cygdri | ve/c/Utils:/cygdrive/c/Program | Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- | 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program | Files/Ha | skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg | drive/f/ | Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib | | Thanks | | Neil | | ============================================================================== | Please access the attached hyperlink for an important electronic communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================== | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From neil.mitchell.2 at credit-suisse.com Tue Sep 9 11:16:47 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Tue Sep 9 11:15:17 2008 Subject: Windows HEAD issues In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A6@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A6@ELON17P32001A.csfb.cs-group.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39A7@ELON17P32001A.csfb.cs-group.com> Hi Another small issue, pwd.exe is placed in the bin directory. Given that pwd is a common and well understood command, GHC shouldn't be hijacking it with a completely different program. Further playing with the haddock installed by GHC shows it to have hardcoded the mingw gcc patch on the build machine into the binary, which causes it to fail when installed on a machine without mingw. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 3:05 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi The haddock placed in bin/ also seems to want to find bin/inplace-datadir/package.conf, which isn't in the distribution tarball as well. I guess haddock either needs building again, or not distributing. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 2:56 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi I've now got a build of GHC, and a binary distribution. The compilation succeeded after the hacks detailed in the previous message. There are now two issues: * runhaskell isn't in ghc/bin - but runghc is. I guess something forgot to get copied or created. This issue is very minor to me, but will be of great significance if it was missing in a release. * The ghc API package hasn't been installed. "ghc-pkg list" gives: C:\Neil\haddock>ghc-pkg list C:/ghc/ghc-6.9.20080905\package.conf: Cabal-1.5.4, Win32-2.1, array-0.1, base-3.0.3.0, base-4.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, ghc-prim-0.1, {haddock-2.2.2}, haskell98-1.0.1, hpc-0.5, integer-0.1, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0.1, random-1.0, rts-1.0, syb-0.1, template-haskell-2.2 My aim of building GHC was to run haddock (and eventually hoogle), so not having the ghc library available is a problem. Does something have to be configured to get the library? Is it hiding somewhere, just not exposed? How did haddock-2.2.2 get installed and compiled without a ghc library? Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 09 September 2008 12:08 pm To: 'glasgow-haskell-users@haskell.org' Subject: RE: Windows build failure Hi, I worked around the first problem, lacking cc1, by following the instructions here: http://www.nabble.com/cc1-not-found-td9742088.html - adding c:\mingw\libexec\gcc\mingw32\3.4.5 to the $PATH. Then I get a shorter error: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=c:/ghc/ghc-6.8.3/bin/ghc --with-hc-pkg=c:/ghc/ghc-6.8.3/bin/ghc -pkg --package-db=c:/ghc-build/ghc/libraries/bootstrapping.conf.tmp Configuring hpc-0.5... cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... In file included from /mingw/lib/gcc/mingw32/3.4.5/../../../../include/float.h:1 9, from c:/ghc/ghc-6.8.3/include/mingw/float.h:19, from c:/ghc/ghc-6.8.3/include/HsFFI.h:69, from c:/ghc/ghc-6.8.3/template-hsc.h:4, from dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c:1: /mingw/include/float.h:102: error: syntax error before "_controlfp" /mingw/include/float.h:103: error: syntax error before "_control87" /mingw/include/float.h:106: error: syntax error before "_clearfp" /mingw/include/float.h:107: error: syntax error before "_statusfp" /mingw/include/float.h:121: error: syntax error before "_fpreset" /mingw/include/float.h:122: error: syntax error before "fpreset" /mingw/include/float.h:125: error: syntax error before "__fpecode" /mingw/include/float.h:133: error: syntax error before "_chgsign" /mingw/include/float.h:134: error: syntax error before "_copysign" /mingw/include/float.h:135: error: syntax error before "_logb" /mingw/include/float.h:136: error: syntax error before "_nextafter" /mingw/include/float.h:137: error: syntax error before "_scalb" /mingw/include/float.h:139: error: syntax error before "_finite" /mingw/include/float.h:140: error: syntax error before "_fpclass" /mingw/include/float.h:141: error: syntax error before "_isnan" compiling dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.c failed command was: c:\ghc\ghc-6.8.3\gcc.exe -c -D__GLASGOW_HASKELL__=608 -Ic:\ghc\ghc- 6.8.3/lib\directory-1.0.0.1\include -Ic:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0\incl ude -Ic:\ghc\ghc-6.8.3/lib\base-3.0.2.0\include -Ic:\ghc\ghc-6.8.3/include -Ic:\ ghc\ghc-6.8.3/include/mingw dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make. c -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 An example of the first error: _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _controlfp (unsigned int unNew, unsigned int unMask); And all the error lines seem to have _MINGW_NOTHROW just before the syntax error. I therefore added: #define __MINGW_NOTHROW To the mingw\include\float.h header - which is clearly not a good idea to do in general, but may hack it enough until a build expert can give me the right fix. The next error I got was: cd hpc && c:/ghc-build/ghc/libraries/cabal-bin c:/ghc/ghc-6.8.3/bin/ghc c:/gh c-build/ghc/libraries/bootstrapping.conf build --distpref=dist-bootstrapping Preprocessing library hpc-0.5... \mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: crtbegin.o: No such file: No such file or directory linking dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.o failed command was: c:\ghc\ghc-6.8.3\gcc.exe -Lc:\ghc\ghc-6.8.3/lib\directory-1.0.0.1 - Lc:\ghc\ghc-6.8.3/lib\filepath-1.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\old-time-1.0.0.0 - Lc:\ghc\ghc-6.8.3/lib\old-locale-1.0.0.0 -Lc:\ghc\ghc-6.8.3/lib\containers-0.1.0 .2 -Lc:\ghc\ghc-6.8.3/lib\array-0.1.0.0 -Lc:\ghc\ghc-6.8.3/lib\base-3.0.2.0 -lws ock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -Lc:\ghc\ghc-6.8.3 -Lc:\ghc\ghc-6.8 .3/gcc-lib -lm -lgmp -lwsock32 dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_ma ke.o -o dist-bootstrapping\build\Trace\Hpc\Reflect_hsc_make.exe make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc/libraries' make: *** [stage1] Error 2 So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a copy of crtbegin.o. That didn't work. So I then copied crtbegin.o and crtend.o into c:\mingw\lib. That seemed to be enough to get past hpc, but again is just a short-term hack. My build is still going, and I'll report back once it either fails or succeeds. However, a general fix does need to be developed for the two issues above. Adding cc1 to the path can probably go in as an instruction for setting up the build environment. It would be incredibly useful if someone wrote a windows-build.sh command that automated as many steps as possible in the list Claus made, and checked for all the others - i.e. checking darcs is on the path, checking appropriate versions where possible, checking mingw gcc is first etc. If no one else does, I probably will when I install Windows on my home machine. Thanks Neil -----Original Message----- From: Mitchell, Neil Sent: 08 September 2008 9:41 am To: 'glasgow-haskell-users@haskell.org' Subject: Windows build failure Hi, I've just tried building GHC HEAD using GHC 6.8.3 on Windows following the instructions on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Windows) I initially got a failure about cc1 not being found when executing 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at the end of the path (i.e. last priority) After this error I get a problem with include files, see the attached log file. It looks like include files are going wrong between Mingw and 6.8.3. My current $PATH variable is: /cygdrive/c/mingw/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdr ive/c/WI NNT/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/local/MikTex/texmf/mi ktex/bin :/cygdrive/c/Perl/site/bin:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/WINNT /system3 2:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/CSsystem :/cygdri ve/c/Utils:/cygdrive/c/Program Files/Sybase.12/OCS-12_0/bin:/cygdrive/c/ghc/ghc- 6.8.3:/cygdrive/c/ghc/ghc-6.8.3/bin:/cygdrive/c/bin:/cygdrive/c/Program Files/Ha skell/bin:/cygdrive/f/ImslNT.30/CNL/Bin:/cygdrive/c/Utils/mks/mksnt:/cyg drive/f/ Fame/76:/cygdrive/c/Utils/mks/MKSNT:/cygdrive/c/ghc/ghc-6.8.3/gcc-lib Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From kili at outback.escape.de Tue Sep 9 14:55:11 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Sep 9 14:58:04 2008 Subject: Making GHC work on BSD In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080909185510.GC30694@petunia.outback.escape.de> On Mon, Sep 08, 2008 at 01:22:15PM +0100, Simon Peyton-Jones wrote: > We'd like GHC to be buildable on BSD, but at the moment it isn't. > We support GHC on Linux, Windows, Mac, but we really need help > with BSD. The current plans for OpenBSD (and I can only speak for OpenBSD here) are to provide a separate port/package with a trimmed down GHC 6.6.1 and use this to bootstrap GHC 6.10. This allows us to get a clean build without HC bootstrapping (and without ugly hacks like having to download a precompiled binary for bootstrapping). And we'll recycle the the 6.6.1 port once HC bootstrapping works again. > Alas, we didn't get much response to Simon's message below. (One, > I think -- thank you to that person! I think it was Kili, but > I'm not sure.) I'm not sure, either. For the GHCi problem with mremap: well, it wouldn't be a catastrophic failure if it can't be fixed for the GHC 6.10 release, IMHO. We already had a broken GHCi on amd64 in the past (due to some real stupidity on my side, for which Don helped out), and the number of complaints I got was rather small ;-) BTW: I've only an i386 here, so fixing bugs happening on amd64 is difficult. > So this message is to say: if you'd like GHC on BSD, please help! > No help probably means no GHC. Time is short before GHC 6.10. If it isn't completely broken and just has some annoyances and bugs, you don't have to despair if bug fixes don't happen before the release. And at least on i386, the current GHC (6.9.20080908) can be built from GHC 6.6.1 up to stage2, and a second GHC can be built with this first build (I've still some problem with the make logic when trying to install this second build, but that's probably a PEBCAK). GHCi seems work fine, too. Any bugs hitting the release can be fixed for us (OpenBSD) after the release. Either upstream, in your repository, or, should any necessary fixes be too intrusive for other platforms, as simple patches in our ports tree. I may sound like a lazy slacker, but unfortunately I've just not enough spare time to work on GHC. And given the frustration I had during the last months, I'll also pass maintainership of our official GHC related ports to someone else, but I'll work on GHC head instead; doing both at the same time just isn't possible for now. Ciao, Kili ps: OpenBSD-4.4 will ship in october, with still GHC 6.6.1; we've time until feburary 2008 to get GHC 6.10 ready to with OpenBSD-4.5. From kili at outback.escape.de Tue Sep 9 15:03:18 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Sep 9 15:03:27 2008 Subject: Making GHC work on BSD In-Reply-To: <48C6819B.1080406@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <20080908161027.41D5993C8D@mail.avvanta.com> <48C6819B.1080406@gmail.com> Message-ID: <20080909190318.GD30694@petunia.outback.escape.de> On Tue, Sep 09, 2008 at 03:00:59PM +0100, Simon Marlow wrote: > >Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an > >optional package for NetBSD/i386 4.0, with ghci included and without > >any mmap patches as far as I know. It was also working for me on > >NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?) > > Yes, the code changed in the HEAD, and currently uses mremap(), which only > exists on Linux. We need similar hacks that were done in 6.8.3 to get the > BSDs to work, that is to allocate memory from some predefined address in > the lower 2Gb of the address space. BTW: are there any big plans[tm] to replace all this OS specific hacks by something like dlopen(3) and friends for GHC 6.12? I really don't want to hack on Linker.c just to be see that hacking obsoleted in a year ;-) Ciao, Kili -- This email is ROT26 encrypted, by reading it you are in violation of the DMCA, and should turn yourself in to the authorities immediately. -- Chris Berry From igloo at earth.li Tue Sep 9 20:52:43 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 9 20:50:34 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080910005243.GA3751@matrix.chaos.earth.li> Hi Neil, On Mon, Sep 08, 2008 at 09:40:47AM +0100, Mitchell, Neil wrote: > > I initially got a failure about cc1 not being found when executing > 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib at > the end of the path (i.e. last priority) I'm not sure why some people see this and others don't. Anyway, John Dias has also seen it, and he and Duncan are working on a patch for it (basically, Cabal needs to pass a "-B " flag to gcc, to tell it where its bits are). Thanks Ian From neil.mitchell.2 at credit-suisse.com Wed Sep 10 03:08:25 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 10 03:06:30 2008 Subject: Windows build failure In-Reply-To: <20080910005243.GA3751@matrix.chaos.earth.li> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <20080910005243.GA3751@matrix.chaos.earth.li> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39AA@ELON17P32001A.csfb.cs-group.com> Hi Ian, > I initially got a failure about cc1 not being found when executing > 6.8.3's gcc, which I worked around by adding c:/ghc/ghc-6.8.3/gcc-lib > at the end of the path (i.e. last priority) | I'm not sure why some people see this and others don't. Anyway, John Dias has also seen it, and he and Duncan | are working on a patch for it (basically, Cabal needs to pass a "-B " flag to gcc, to tell it where its bits are). My best guess is that it's a mingw issue, something that chanced in recent release. It seems to effect more than just GHC. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From claus.reinke at talk21.com Wed Sep 10 05:57:07 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 10 05:55:02 2008 Subject: Windows build failure References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com><20080910005243.GA3751@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AA@ELON17P32001A.csfb.cs-group.com> Message-ID: <45A301232C8B41148F667E055DE42E90@cr3lt> | I'm not sure why some people see this and others don't. Anyway, John | Dias has also seen it, and he and Duncan | are working on a patch for it (basically, Cabal needs to pass a "-B | " flag to gcc, to tell it where its bits are). >My best guess is that it's a mingw issue, something that chanced in >recent release. It seems to effect more than just GHC. If it was just a mingw issue, you could simply go back to an old mingw (mine has gcc 3.4.2). From what I can tell (and I'm just a user) there are interactions with Vista and cygwin. Vista changed some APIs wrt earlier windows versions, which needed following, and occasionally someone changes mingw without taking those changes into account. I thought that mingw had decoupled from the cygwin version of mingw, but there is still talk about that, about not picking up the wrong versions of gcc tools (which relates to usage of -B). Anyway, you can read about it on the mingw mailing list and bug tracker. Below is an email I was about to send when Neil reported that he had got things going himself. Claus ----------------- 1. are you using - cygwin bash+mingw gcc - msys bash+mingw gcc? 2. are you using windows vista? As a point of reference, I'm using cygwin bash and build tools (with no cygwin gcc chain installed) plus mingw gcc (3.4.2) on windows xp, and ghc issues arising tend not to be in mingw or cygwin for this config. There do seem to be quite a few vista issues for mingw (and there have been similar things for cygwin), some fixed, some not, some closed with unhelpful "read the wiki". There's a bug tracker here: https://sourceforge.net/tracker/?group_id=2435&atid=102435 https://sourceforge.net/tracker/index.php?func=detail&aid=1593268&group_id=2435&atid=202435 https://sourceforge.net/tracker/index.php?func=detail&aid=1784372&group_id=2435&atid=102435 Some tickets refer to cc1, some to header files, some are rather old, suggesting that things have been fixed, but some are new? That looks rather confusing to me, as I thought that mingw and cygwin had adapted to the api changes in vista, but then I'm still using xp. From neil.mitchell.2 at credit-suisse.com Wed Sep 10 06:47:14 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 10 06:45:37 2008 Subject: Windows build failure In-Reply-To: <45A301232C8B41148F667E055DE42E90@cr3lt> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com><20080910005243.GA3751@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AA@ELON17P32001A.csfb.cs-group.com> <45A301232C8B41148F667E055DE42E90@cr3lt> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39AC@ELON17P32001A.csfb.cs-group.com> Hi Claus, For reference, I'm using cygwin bash+mingw gcc on Windows XP, following your instructions as closely as possible - but with the latest version of cygwin and mingw. The biggest niggle for me currently is the lack of the GHC API, which is built in stage2, but not transferred across to the bindist. However, there seem to be lots of little things that will require fixing before the Windows version is ready for release. > If it was just a mingw issue, you could simply go back to an old mingw (mine has gcc 3.4.2). > From what I can tell (and I'm just a user) there are interactions with Vista and cygwin. My new home computer will almost certainly be Vista, so I guess I'm in for a world of fun then :-) Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marlowsd at gmail.com Wed Sep 10 06:57:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 10 06:55:01 2008 Subject: Making GHC work on BSD In-Reply-To: <20080909190318.GD30694@petunia.outback.escape.de> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <20080908161027.41D5993C8D@mail.avvanta.com> <48C6819B.1080406@gmail.com> <20080909190318.GD30694@petunia.outback.escape.de> Message-ID: <48C7A807.6030306@gmail.com> Matthias Kilian wrote: > On Tue, Sep 09, 2008 at 03:00:59PM +0100, Simon Marlow wrote: >>> Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an >>> optional package for NetBSD/i386 4.0, with ghci included and without >>> any mmap patches as far as I know. It was also working for me on >>> NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?) >> Yes, the code changed in the HEAD, and currently uses mremap(), which only >> exists on Linux. We need similar hacks that were done in 6.8.3 to get the >> BSDs to work, that is to allocate memory from some predefined address in >> the lower 2Gb of the address space. > > BTW: are there any big plans[tm] to replace all this OS specific > hacks by something like dlopen(3) and friends for GHC 6.12? I really > don't want to hack on Linker.c just to be see that hacking obsoleted > in a year ;-) I don't think we can do it all with dlopen(). Even when we have shared libraries for all the packages and the RTS, so we could use dlopen() to load those, we still need to be able to link plain .o files. I suppose dlopen() migth be able to load ordinary .o files these days, but it probably won't populate its symbol table with symbols from the .o unless it was linked with --export-dynamic or something. Cheers, Simon From claus.reinke at talk21.com Wed Sep 10 07:16:52 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 10 07:14:48 2008 Subject: Windows build failure References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com><20080910005243.GA3751@matrix.chaos.earth.li><33A3F585590A6F4E81E3D45AA4A111C902CD39AA@ELON17P32001A.csfb.cs-group.com><45A301232C8B41148F667E055DE42E90@cr3lt> <33A3F585590A6F4E81E3D45AA4A111C902CD39AC@ELON17P32001A.csfb.cs-group.com> Message-ID: <4BEA5C114D394222B958C9815259CB16@cr3lt> >For reference, I'm using cygwin bash+mingw gcc on Windows XP, following >your instructions as closely as possible - but with the latest version >of cygwin and mingw. Then I'm really surprised to see you having so much trouble. Unless you've accidentally installed parts of the cygwin gcc chain (or cygwin's --no-cygwin mingw variant), that would mean issues in the latest mingw versions. Perhaps going back to an older mingw is easier than working around those issues? >The biggest niggle for me currently is the lack of the GHC API, which is >built in stage2, but not transferred across to the bindist. Sat Sep 6 15:25:46 GMT Daylight Time 2008 Ian Lynagh * Install the stage 2 ghc package when installing; fixes trac #2567 M ./compiler/Makefile -2 +1 M ./compiler/ghc.cabal -1 +1 M ./libraries/Makefile -31 M ./mk/cabal-flags.mk +34 >there seem to be lots of little things that will require fixing before >the Windows version is ready for release. Yes, but since 'make binary-dist' is working again, we can at least start reporting those little things (though Ian sometimes insists on seeing a trac ticket first rather than a mere email, as in the ghc package case;-). >My new home computer will almost certainly be Vista, so I guess I'm >in for a world of fun then :-) Vista has been around for a while, and as you get the issues with XP and new mingw, trying out older mingw might still work on Vista (sometimes a new broom adds new issues before working properly). Claus From igloo at earth.li Wed Sep 10 07:19:55 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 10 07:17:42 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080910111955.GA11821@matrix.chaos.earth.li> On Tue, Sep 09, 2008 at 12:08:12PM +0100, Mitchell, Neil wrote: > > #define __MINGW_NOTHROW > > So I added c:\mingw\lib\gcc\mingw32\3.4.5 to the $PATH, where I found a > copy of crtbegin.o. I'm not sure what's happening here, but I think we should see if the forthcoming -B patch fixes these too. Thanks Ian From igloo at earth.li Wed Sep 10 07:24:14 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 10 07:22:03 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080910112414.GB11821@matrix.chaos.earth.li> On Tue, Sep 09, 2008 at 02:56:28PM +0100, Mitchell, Neil wrote: > > * runhaskell isn't in ghc/bin - but runghc is. I guess something forgot > to get copied or created. This issue is very minor to me, but will be of > great significance if it was missing in a release. Thanks; trac'ed as #2582 so I don't forget about it. > * The ghc API package hasn't been installed. "ghc-pkg list" gives: Do you have this patch?: [Install the stage 2 ghc package when installing; fixes trac #2567 Ian Lynagh **20080906142546] { hunk ./compiler/Makefile 196 -# XXX We ought to actually install the (stage 2) library hunk ./compiler/Makefile 197 - @: + $(INSTALL_PACKAGE) install '$(GHC_PKG_INSTALL_PROG)' '$(DESTDIR)$(datadi r)/package.conf' '$(DESTDIR)' '$(prefix)' '$(iprefix)' '$(ibindir)' '$(ilibdir)' '$(ilibexecdir)' '$(idynlibdir)' '$(idatadir)' '$(idocdir)' '$(ihtmldir)' '$(ih addockdir)' --distpref dist-stage2 [...] Thanks Ian From neil.mitchell.2 at credit-suisse.com Wed Sep 10 07:26:00 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 10 07:24:04 2008 Subject: Windows build failure In-Reply-To: <20080910112414.GB11821@matrix.chaos.earth.li> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <20080910112414.GB11821@matrix.chaos.earth.li> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39AE@ELON17P32001A.csfb.cs-group.com> > * The ghc API package hasn't been installed. "ghc-pkg list" gives: | Do you have this patch?: Probably not, I've just pulled and am rebuilding. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From igloo at earth.li Wed Sep 10 08:14:12 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 10 08:12:00 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39AE@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <20080910112414.GB11821@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AE@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080910121412.GC11821@matrix.chaos.earth.li> On Wed, Sep 10, 2008 at 12:26:00PM +0100, Mitchell, Neil wrote: > > > * The ghc API package hasn't been installed. "ghc-pkg list" gives: > > | Do you have this patch?: > > Probably not, I've just pulled and am rebuilding. OK, I think your haddock problems are also fixed in the HEAD, by: [Fix in-tree haddock on Windows Ian Lynagh **20080829000742] { so if you ./darcs-all pull then that should work too. Thanks Ian From neil.mitchell.2 at credit-suisse.com Wed Sep 10 08:45:34 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 10 08:44:58 2008 Subject: Windows build failure In-Reply-To: <20080910121412.GC11821@matrix.chaos.earth.li> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <20080910112414.GB11821@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AE@ELON17P32001A.csfb.cs-group.com> <20080910121412.GC11821@matrix.chaos.earth.li> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39AF@ELON17P32001A.csfb.cs-group.com> Hi Ian, Fresh pull, and I get in bind-dist: ------------------------------------------------------------------------ ../../utils/mkdirhier/mkdirhier c:/ghc-build/ghc/ghc-6.9.20080905/share/man mkdir c:/ghc-build/ghc/ghc-6.9.20080905/share mkdir c:/ghc-build/ghc/ghc-6.9.20080905/share/man ../../utils/mkdirhier/mkdirhier c:/ghc-build/ghc/ghc-6.9.20080905/share/man/man1 mkdir c:/ghc-build/ghc/ghc-6.9.20080905/share/man/man1 /usr/bin/install -c -m 644 ghc.1 c:/ghc-build/ghc/ghc-6.9.20080905/share/man/ man1 Finished making install-docs in man: 0 ------------------------------------------------------------------------ == make install-docs - --no-print-directory -r; in /cygdrive/c/ghc-build/ghc/docs/docbook-cheat-sheet ------------------------------------------------------------------------ make[3]: Nothing to be done for `install-docs'. Finished making install-docs in docbook-cheat-sheet: 0 ------------------------------------------------------------------------ == make install-docs - --no-print-directory -r; in /cygdrive/c/ghc-build/ghc/docs/users_guide ------------------------------------------------------------------------ make[3]: Nothing to be done for `install-docs'. Finished making install-docs in users_guide: 0 ------------------------------------------------------------------------ == make install-docs - --no-print-directory -r; in /cygdrive/c/ghc-build/ghc/docs/ext-core ------------------------------------------------------------------------ make[3]: *** No rule to make target `install-docs'. Stop. Failed making install-docs in ext-core: 1 make[2]: *** [install-docs] Error 1 make[1]: *** [install-docs] Error 1 make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc' make: *** [binary-dist] Error 2 Ext-core install-docs doesn't work? Thanks Neil -----Original Message----- From: Ian Lynagh [mailto:igloo@earth.li] Sent: 10 September 2008 1:14 pm To: Mitchell, Neil Cc: glasgow-haskell-users@haskell.org Subject: Re: Windows build failure On Wed, Sep 10, 2008 at 12:26:00PM +0100, Mitchell, Neil wrote: > > > * The ghc API package hasn't been installed. "ghc-pkg list" gives: > > | Do you have this patch?: > > Probably not, I've just pulled and am rebuilding. OK, I think your haddock problems are also fixed in the HEAD, by: [Fix in-tree haddock on Windows Ian Lynagh **20080829000742] { so if you ./darcs-all pull then that should work too. Thanks Ian ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From g9ks157k at acme.softbase.org Wed Sep 10 10:20:55 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Sep 10 10:18:43 2008 Subject: Is FPH implemented in GHC? Message-ID: <200809101620.55644.g9ks157k@acme.softbase.org> Hello, is FPH implemented in GHC? If yes, will it be part of GHC 6.10.1? Best wishes, Wolfgang From simonpj at microsoft.com Wed Sep 10 10:24:57 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 10 10:22:46 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <200809101620.55644.g9ks157k@acme.softbase.org> References: <200809101620.55644.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> Not yet. But Dimitrios has just started a postdoc at MSR, so we will be working on fixing, once and for all, the impredicative story in GHC. Meanwhile, why do you ask? Making impredicative polymorphism work seems to be the Right Thing, but it's something of a "technology push", perhpas a solution in search of a problem. Do you have an application that needs it? This is a general question to GHC users. (If you don't know what impredicative polymorphism is, think "can I have a type like (Maybe (forall a. [a] -> [a]))".) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Wolfgang Jeltsch | Sent: 10 September 2008 15:21 | To: glasgow-haskell-users@haskell.org | Subject: Is FPH implemented in GHC? | | Hello, | | is FPH implemented in GHC? If yes, will it be part of GHC 6.10.1? | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ganesh.sittampalam at credit-suisse.com Wed Sep 10 10:32:21 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 10 10:35:17 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B8B9@ELON17P32002A.csfb.cs-group.com> I don't have a specific application that's crying out for this, but I sometimes shy away from using higher-rank polymorphism because of the extra effort it can require. A possibly related question is whether you would expect to make record selectors and updaters work for all record types at the same time? That would definitely be very useful. -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 10 September 2008 15:25 To: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org Cc: Dimitrios Vytiniotis (t-dimitv@microsoft.com) Subject: RE: Is FPH implemented in GHC? Not yet. But Dimitrios has just started a postdoc at MSR, so we will be working on fixing, once and for all, the impredicative story in GHC. Meanwhile, why do you ask? Making impredicative polymorphism work seems to be the Right Thing, but it's something of a "technology push", perhpas a solution in search of a problem. Do you have an application that needs it? This is a general question to GHC users. (If you don't know what impredicative polymorphism is, think "can I have a type like (Maybe (forall a. [a] -> [a]))".) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org | [mailto:glasgow-haskell-users- bounces@haskell.org] On Behalf Of | Wolfgang Jeltsch | Sent: 10 September 2008 15:21 | To: glasgow-haskell-users@haskell.org | Subject: Is FPH implemented in GHC? | | Hello, | | is FPH implemented in GHC? If yes, will it be part of GHC 6.10.1? | | Best wishes, | Wolfgang | _______________________________________________ | 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 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Wed Sep 10 10:43:07 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 10 10:40:59 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B8B9@ELON17P32002A.csfb.cs-group.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> <78A3C5650E28124399107F21A1FA419401D3B8B9@ELON17P32002A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D763935E7@EA-EXMSG-C334.europe.corp.microsoft.com> | A possibly related question is whether you would expect to make record | selectors and updaters work for all record types at the same time? That | would definitely be very useful. I'm not sure what you mean by this. Would you care to elaborate? Simon From ganesh.sittampalam at credit-suisse.com Wed Sep 10 12:42:33 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 10 12:41:31 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D763935E7@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> <78A3C5650E28124399107F21A1FA419401D3B8B9@ELON17P32002A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D763935E7@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B8BF@ELON17P32002A.csfb.cs-group.com> > | A possibly related question is whether you would expect to make record > | selectors and updaters work for all record types at the same time? > | That would definitely be very useful. > I'm not sure what you mean by this. Would you care to elaborate? The most important thing for me is supporting record update for existentially quantified data records, as in the error below. In general I also find working with code that involves existential type variables quite hard work - for example I can't use foo as a record selector either, even if I immediately do something that seals the existential type back up again. I don't understand this stuff well enough to be sure whether it's an impredicativity issue or not, though. Cheers, Ganesh Foo.hs:11:8: Record update for the non-Haskell-98 data type `Foo' is not (yet) supported Use pattern-matching instead In the expression: rec {foo = id} In the definition of `f': f rec = rec {foo = id} {-# LANGUAGE Rank2Types #-} module Foo where data Foo = forall a . Foo { foo :: a -> a, bar :: Int } x :: Foo x = Foo { foo = id, bar = 3 } f :: Foo -> Foo f rec = rec { foo = id } g :: Foo -> Foo g rec = rec { bar = 3 } ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From g9ks157k at acme.softbase.org Wed Sep 10 14:59:07 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Sep 10 14:57:33 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200809102059.07482.g9ks157k@acme.softbase.org> Am Mittwoch, 10. September 2008 16:24 schrieben Sie: > [?] > Meanwhile, why do you ask? Making impredicative polymorphism work seems to > be the Right Thing, but it's something of a "technology push", perhpas a > solution in search of a problem. Do you have an application that needs it? Hello Simon, yes, I have one. It?s the Grapefruit FRP library. The background is as follows: If an FRP library provides first-class signals then often the problem arises that these are actually signal generators?their behavior might depend on the time they are started. To get rid of this deficiency, my signal types now have an additional type argument which denotes the starting time. This way, I?m able to fix the starting time using the type system. The idea is similar to the usage of the ?state? type argument of ST. Now I have a switching combinator which takes a signal of signal transformations (a time-varying signal transformation). The signal transformations have to work with different starting times, so I use an explicit forall and get a type like SSignal t (forall t'. SignalFun t' a). To implement all this stuff, I had to do quite a bit of code obfuscation. That is, I introduced a lot of trivial functions only to give them an explicit impredicative/rank 2 type signature. Maybe my solution isn?t optimal but I didn?t see how to do this simpler. I hope that FPH will reduce the extra effort, I have to spend, dramatically. If you have further questions, please ask. Best wishes, Wolfgang From claus.reinke at talk21.com Wed Sep 10 18:09:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 10 18:07:25 2008 Subject: Is FPH implemented in GHC? References: <200809101620.55644.g9ks157k@acme.softbase.org><638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> <200809102059.07482.g9ks157k@acme.softbase.org> Message-ID: <90AF42D985B64F70AEAA38429210B656@cr3lt> >If an FRP library provides first-class signals then often the problem arises >that these are actually signal generators?their behavior might depend on the >time they are started. To get rid of this deficiency, my signal types now >have an additional type argument which denotes the starting time. This way, >I?m able to fix the starting time using the type system. The idea is similar >to the usage of the ?state? type argument of ST. Dependencies on an absolute clock always caused trouble in Fran/FRP programming and were one of the things I tried to get rid of in my FunWorlds experiments (sigh, way too long ago..). Thinking of behaviours as functions from *all* times to values is an unimplementable theoretical ideal and completely at odds with FRP's more practical ideal of compositional programming (leading to the less sung about "arts" of actual programming in FRP, aging behaviours, start times, etc.). Thinking of behaviours as something one can do measurements on, yielding current value and residual behaviour, leads to simpler semantics, implementation and programming. If you want a (local!) clock, just integrate over a constant. Many of the FunWorlds aspects would need revision, if I ever get round to that.. but dropping absolute time was the right thing to do (as if physics hadn't told us about that anyway;-). Claus From wayne.mokane at gmail.com Wed Sep 10 22:21:34 2008 From: wayne.mokane at gmail.com (Jeff Evans) Date: Wed Sep 10 22:19:21 2008 Subject: gcc-looking error when building GHC 6.8.3 from source - "directives may not be used inside a macro argument" In-Reply-To: References: Message-ID: Hi everyone, I am trying to build GHC 6.8.3 from source in a slightly nonstandard environment (mostly with regard to the filesystem). The build setup, however, is fairly standard (32-bit x86 RHEL, gcc 3.4, glibc 2.3). I managed to get the bootstrap installation from the "ghc-6.6.1-x86_64-unknown-linux" tarball (downloaded from http://www.haskell.org/ghc/download_ghc_661.html#x86linux) working without much trouble. Now I'm trying to use that to build 6.8.3 from source. But I am hitting an error in the build target, apparently for this rts component. Output snippet here: http://hpaste.org/10252 The first of the ghc errors is "RtsFlags.c:1120:1: directives may not be used inside a macro argument" which is followed by many more (I think this is the real cause though). I searched around and it seems like a gcc "limitation" (not supporting something that is not part of the C standard but people still wanted). But even then it has supposedly been supported since gcc 3.2, and I'm using 3.4. To be honest, I don't know anything about the interaction between ghc and gcc at this juncture so I'm a bit in the dark. Any advice is appreciated. I can also provide more complete output/details if it would be useful. Thank you! From wayne.mokane at gmail.com Wed Sep 10 22:37:49 2008 From: wayne.mokane at gmail.com (Jeff Evans) Date: Wed Sep 10 22:35:36 2008 Subject: gcc-looking error when building GHC 6.8.3 from source - "directives may not be used inside a macro argument" In-Reply-To: References: Message-ID: I am trying to build GHC 6.8.3 from source in a slightly nonstandard environment (mostly with regard to the filesystem). The build setup, however, is fairly standard (32-bit x86 RHEL, gcc 3.4, glibc 2.3). I managed to get the bootstrap installation from the "ghc-6.6.1-x86_64-unknown-linux" tarball (downloaded from http://www.haskell.org/ghc/download_ghc_661.html#x86linux) working without much trouble. Now I'm trying to use that to build 6.8.3 from source. But I am hitting an error in the build target, apparently for this rts component. Output snippet here: http://hpaste.org/10252 The first of the ghc errors is "RtsFlags.c:1120:1: directives may not be used inside a macro argument" which is followed by many more (I think this is the real cause though). I searched around and it seems like a gcc "limitation" (not supporting something that is not part of the C standard but people still wanted). But even then it has supposedly been supported since gcc 3.2, and I'm using 3.4. To be honest, I don't know anything about the interaction between ghc and gcc at this juncture so I'm a bit in the dark. Any advice is appreciated. I can also provide more complete output/details if it would be useful. Thank you! From g9ks157k at acme.softbase.org Thu Sep 11 07:58:32 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Sep 11 07:56:19 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <90AF42D985B64F70AEAA38429210B656@cr3lt> References: <200809101620.55644.g9ks157k@acme.softbase.org> <200809102059.07482.g9ks157k@acme.softbase.org> <90AF42D985B64F70AEAA38429210B656@cr3lt> Message-ID: <200809111358.32845.g9ks157k@acme.softbase.org> Am Donnerstag, 11. September 2008 00:09 schrieben Sie: > >If an FRP library provides first-class signals then often the problem > > arises that these are actually signal generators?their behavior might > > depend on the time they are started. To get rid of this deficiency, my > > signal types now have an additional type argument which denotes the > > starting time. This way, I?m able to fix the starting time using the > > type system. The idea is similar to the usage of the ?state? type > > argument of ST. > > Dependencies on an absolute clock always caused trouble in > Fran/FRP programming and were one of the things I tried to get > rid of in my FunWorlds experiments (sigh, way too long ago..). Hmm, maybe you misunderstood. The extra type argument cannot be instantiated to the current time since that would need dependent types or something similar. Actually, we never instantiate this argument but only force it to be independent to other such time arguments via forall, and force it to be equal to other such time arguments by using the same type variable multiple times in the same type. So the whole thing is only about whether something happens at the same time or not. It?s really similar to the first ST type argument without using RealWorld. You never instantiate it, you just put constraints on it in the form that it has to be equal to some other such argument. > Thinking of behaviours as functions from *all* times to values is > an unimplementable theoretical ideal and completely at odds with > FRP's more practical ideal of compositional programming (leading > to the less sung about "arts" of actual programming in FRP, aging > behaviours, start times, etc.). At least, I try to help the FRP programmer to get aging etc. right by using the time argument trick to make wrong signal use result in a type error. In Grapefruit, a signal is a function from a time *interval* to values where the time interval is denoted by this type argument. > [?] > Many of the FunWorlds aspects would need revision, if I ever > get round to that.. but dropping absolute time was the right thing > to do (as if physics hadn't told us about that anyway;-). In Grapefruit, you could implement a continous signal which represents an absolute clock. This is because you can make a continuous signal out of any continuous source that can be asked to tell its current value by means of an I/O action. But absolute time isn?t fundamental to Grapefruit. You could think of some totally ordered set representing time and continuous signals being functions from this set to values. But you can only access continuous signals by sampling them using a discrete signal. So you can only get the value of a continous signal at those times where some event occurs. You have the advantage that you can abstract from sampling rates and similar stuff by composing continuous signals. But at some point you have to sample explicitely. > Claus Best wishes, Wolfgang From bulat.ziganshin at gmail.com Fri Sep 12 04:33:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Sep 12 04:31:38 2008 Subject: -optl-s (strip) by default Message-ID: <56123306.20080912123311@gmail.com> Hello glasgow-haskell-users, when GHC builds executable, it adds debug info by default. since this info is useless for Haskell and since it significantly increases executable size, will it be better to delete it by default by passing -optl-s option to the linker? another question: by adding " -optl-Xlinker -optl--large-address-aware" to cmdline we will allow mingw32-compiled programs to use up to 4gb of memory (instead of 2gb with current settings). now i have 4gb of memory+vista64 so can test this setting if required -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Fri Sep 12 04:54:22 2008 From: dons at galois.com (Don Stewart) Date: Fri Sep 12 04:51:59 2008 Subject: -optl-s (strip) by default In-Reply-To: <56123306.20080912123311@gmail.com> References: <56123306.20080912123311@gmail.com> Message-ID: <20080912085422.GA5621@scytale.galois.com> bulat.ziganshin: > Hello glasgow-haskell-users, > > when GHC builds executable, it adds debug info by default. since this > info is useless for Haskell and since it significantly increases > executable size, will it be better to delete it by default by passing > -optl-s option to the linker? > > another question: by adding " -optl-Xlinker -optl--large-address-aware" > to cmdline we will allow mingw32-compiled programs to use up to 4gb > of memory (instead of 2gb with current settings). now i have 4gb of > memory+vista64 so can test this setting if required You can also achieve this by making sure your deployed programs build with Cabal, http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html No need to hack GHC's view of the linker. From bulat.ziganshin at gmail.com Fri Sep 12 05:06:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Sep 12 05:07:31 2008 Subject: -optl-s (strip) by default In-Reply-To: <20080912085422.GA5621@scytale.galois.com> References: <56123306.20080912123311@gmail.com> <20080912085422.GA5621@scytale.galois.com> Message-ID: <1292182536.20080912130626@gmail.com> Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote: > You can also achieve this by making sure your deployed programs build > with Cabal, *my* programs are built using these opts, how about other haskellers? it comes to surprise that executables contains lot of useless data. second problem is probably rather specific, though -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri Sep 12 05:09:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Sep 12 05:07:50 2008 Subject: -optl-s (strip) by default In-Reply-To: <20080912085422.GA5621@scytale.galois.com> References: <56123306.20080912123311@gmail.com> <20080912085422.GA5621@scytale.galois.com> Message-ID: <98989560.20080912130901@gmail.com> Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote: >> when GHC builds executable, it adds debug info by default. since this > You can also achieve this by making sure your deployed programs build > with Cabal, > http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html > No need to hack GHC's view of the linker. btw, it seems like hack in 3rd party tool to fix weird default ghc behavior -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Fri Sep 12 08:13:14 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 12 08:11:00 2008 Subject: Making GHC work on BSD In-Reply-To: <200809082208.28969.naur@post11.tele.dk> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <200809082208.28969.naur@post11.tele.dk> Message-ID: <20080912121314.GA29922@matrix.chaos.earth.li> On Mon, Sep 08, 2008 at 10:08:27PM +0200, Thorkil Naur wrote: > > take the latest (7.0) FreeBSD and install that. > > So, it would be useful to know, which FreeBSD version would you prefer to use > for this? I think that it's most important to get GHC working in the latest version, so from your message it sounds like 7.0 is the way to go. Thanks Ian From neil.mitchell.2 at credit-suisse.com Fri Sep 12 08:50:32 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Sep 12 08:48:34 2008 Subject: GADT problems Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> Hi The following code works in GHC 6.8.3, works in GHC 6.9.20071111, but doesn't work in GHC HEAD. {-# LANGUAGE GADTs, ScopedTypeVariables #-} module Test where data E x = E x data Foo where Foo :: Gadt a -> Foo data Gadt a where GadtValue :: Gadt (E a) f (Foo GadtValue) = True f _ = False Under GHC HEAD I get the error: GADT pattern match with non-rigid result type `t' Solution: add a type signature In the definition of `f': f (Foo GadtValue) = True Adding a type signature to f fixes this problem: f :: Foo -> Bool But I haven't found anywhere other than the top level f to add a type signature. When the match is in a list comprehension, it becomes much harder. While playing further I discovered this example: foos = undefined g = [() | Foo GadtValue <- foos] This code doesn't compile under GHC HEAD, but does under 6.8.3. However, adding the type signature: g :: [()] Makes the code compile. This is surprising, as [()] isn't a GADT type, so shouldn't need stating explicitly. Any help on what these errors mean, or how they can be fixed with local type annotations? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From phercek at gmail.com Fri Sep 12 11:41:01 2008 From: phercek at gmail.com (Peter Hercek) Date: Fri Sep 12 11:42:06 2008 Subject: simple questions about +RTS -s output Message-ID: Hi, There is an example of +RTS -s output at the end. I have few simple questions: What does "9 Mb total memory in use" mean? Is it in mega bytes (MB) or in mega bits (Mb)? I would expect memory usage to be in bytes (B) but a unit for bits (b) seems to be used. Looks like heap size in mega bytes... What does MUT abbreviation stand for? Peter. 1,175,063,464 bytes allocated in the heap 25,951,288 bytes copied during GC (scavenged) 929,036 bytes copied during GC (not scavenged) 3,932,160 bytes maximum residency (4 sample(s)) 2237 collections in generation 0 ( 0.15s) 4 collections in generation 1 ( 0.04s) 9 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 2.95s ( 20.33s elapsed) GC time 0.19s ( 0.20s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.15s ( 20.53s elapsed) %GC time 6.0% (1.0% elapsed) Alloc rate 397,455,026 bytes per MUT second Productivity 93.9% of total user, 14.4% of total elapsed From neil.mitchell.2 at credit-suisse.com Fri Sep 12 11:47:39 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Fri Sep 12 11:50:10 2008 Subject: simple questions about +RTS -s output In-Reply-To: References: Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39D1@ELON17P32001A.csfb.cs-group.com> Hi > What does "9 Mb total memory in use" mean? Almost certainly mega bytes. Only network communications ever talk in megabits, and even then its only so your broadband provider can multiply their speed by 8 :-) > What does MUT abbreviation stand for? Mutation. Actually doing graph reduction and running computations. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From philip.weaver at gmail.com Fri Sep 12 18:33:17 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Sep 12 18:30:58 2008 Subject: Making GHC work on BSD In-Reply-To: <20080912121314.GA29922@matrix.chaos.earth.li> References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <200809082208.28969.naur@post11.tele.dk> <20080912121314.GA29922@matrix.chaos.earth.li> Message-ID: On Fri, Sep 12, 2008 at 5:13 AM, Ian Lynagh wrote: > On Mon, Sep 08, 2008 at 10:08:27PM +0200, Thorkil Naur wrote: > > > > take the latest (7.0) FreeBSD and install that. > > > > So, it would be useful to know, which FreeBSD version would you prefer to > use > > for this? > > I think that it's most important to get GHC working in the latest > version, so from your message it sounds like 7.0 is the way to go. > I believe that a majority (or at least a plurality) of FreeBSD users are on 6.x still, as indicated by statistics on this page http://www.daemonology.net/portsnap/stats.html > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080912/0acf9c7d/attachment.htm From donn at avvanta.com Fri Sep 12 19:01:46 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Sep 12 18:59:27 2008 Subject: Making GHC work on BSD References: <638ABD0A29C8884A91BC5FB5C349B1C32D75F8A266@EA-EXMSG-C334.europe.corp.microsoft.com> <200809082208.28969.naur@post11.tele.dk> <20080912121314.GA29922@matrix.chaos.earth.li> Message-ID: <20080912230146.DC6F9276CE1@mail.avvanta.com> Quoth "Philip Weaver" : | On Fri, Sep 12, 2008 at 5:13 AM, Ian Lynagh wrote: |> On Mon, Sep 08, 2008 at 10:08:27PM +0200, Thorkil Naur wrote: |>> |>> take the latest (7.0) FreeBSD and install that. |>> |>> So, it would be useful to know, which FreeBSD version would you prefer to use |>> for this? |> |> I think that it's most important to get GHC working in the latest |> version, so from your message it sounds like 7.0 is the way to go. | | I believe that a majority (or at least a plurality) of FreeBSD users are on | 6.x still, as indicated by statistics on this page | | http://www.daemonology.net/portsnap/stats.html Sure, bound to be. It seems like it would be hard for GHC Central to answer this question with more than a general guideline, without knowing a lot about what FreeBSD is up to. The FreeBSD port system lists "haskell@freebsd.org" as the port maintainer. Who's that? Would that be a good place to go to coordinate these efforts? Donn From igloo at earth.li Fri Sep 12 20:07:58 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 12 20:05:39 2008 Subject: Windows HEAD issues In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39A7@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A6@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A7@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080913000758.GA9899@matrix.chaos.earth.li> Hi Neil, On Tue, Sep 09, 2008 at 04:16:47PM +0100, Mitchell, Neil wrote: > > Another small issue, pwd.exe is placed in the bin directory. Given that > pwd is a common and well understood command, GHC shouldn't be hijacking > it with a completely different program. Fixed; thanks for the report. > Further playing with the haddock installed by GHC shows it to have > hardcoded the mingw gcc patch on the build machine into the binary, > which causes it to fail when installed on a machine without mingw. If you want to put it on a different machine then you'll have to do it as part of a GHC bindist (make binary-dist). If that's not working then can you please give more details, showing what's going wrong? Thanks Ian From igloo at earth.li Fri Sep 12 20:11:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 12 20:09:04 2008 Subject: Windows build failure In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39AF@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <20080910112414.GB11821@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AE@ELON17P32001A.csfb.cs-group.com> <20080910121412.GC11821@matrix.chaos.earth.li> <33A3F585590A6F4E81E3D45AA4A111C902CD39AF@ELON17P32001A.csfb.cs-group.com> Message-ID: <20080913001125.GB9899@matrix.chaos.earth.li> Hi Neil, On Wed, Sep 10, 2008 at 01:45:34PM +0100, Mitchell, Neil wrote: > > Fresh pull, and I get in bind-dist: > > == make install-docs - --no-print-directory -r; > in /cygdrive/c/ghc-build/ghc/docs/ext-core > ------------------------------------------------------------------------ > make[3]: *** No rule to make target `install-docs'. Stop. > Failed making install-docs in ext-core: 1 > make[2]: *** [install-docs] Error 1 > make[1]: *** [install-docs] Error 1 > make[1]: Leaving directory `/cygdrive/c/ghc-build/ghc' > make: *** [binary-dist] Error 2 > > Ext-core install-docs doesn't work? This is fixed now. Thanks Ian From igloo at earth.li Fri Sep 12 20:20:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 12 20:18:16 2008 Subject: gcc-looking error when building GHC 6.8.3 from source - "directives may not be used inside a macro argument" In-Reply-To: References: Message-ID: <20080913002036.GA24779@matrix.chaos.earth.li> Hi Jeff, On Wed, Sep 10, 2008 at 09:21:34PM -0500, Jeff Evans wrote: > > The first of the ghc errors is "RtsFlags.c:1120:1: directives may not > be used inside a macro argument" which is followed by many more (I > think this is the real cause though). I searched around and it seems > like a gcc "limitation" (not supporting something that is not part of > the C standard but people still wanted). But even then it has > supposedly been supported since gcc 3.2, and I'm using 3.4. Try running the command manually, but append -v to the commandline. This will show you how gcc is being invoked, and it'll also pass -v to gcc which will therefore announce its version number. Thanks Ian From duncan.coutts at worc.ox.ac.uk Fri Sep 12 20:42:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 12 20:47:21 2008 Subject: -optl-s (strip) by default In-Reply-To: <1292182536.20080912130626@gmail.com> References: <56123306.20080912123311@gmail.com> <20080912085422.GA5621@scytale.galois.com> <1292182536.20080912130626@gmail.com> Message-ID: <1221266572.5395.95.camel@localhost> On Fri, 2008-09-12 at 13:06 +0400, Bulat Ziganshin wrote: > Hello Don, > > Friday, September 12, 2008, 12:54:22 PM, you wrote: > > > You can also achieve this by making sure your deployed programs build > > with Cabal, > > *my* programs are built using these opts, how about other haskellers? Cabal automatically strips executables on installation and has ?the option --disable-executable-stripping to disable that. So packages authors do not have to do anything, indeed they should not try to add any flags to force stripping as that would prevent ?--disable-executable-stripping from working. Hackage checks for this. Duncan From simonpj at microsoft.com Sat Sep 13 17:09:51 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Sep 13 17:07:29 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B8BF@ELON17P32002A.csfb.cs-group.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D763935B3@EA-EXMSG-C334.europe.corp.microsoft.com> <78A3C5650E28124399107F21A1FA419401D3B8B9@ELON17P32002A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D763935E7@EA-EXMSG-C334.europe.corp.microsoft.com> <78A3C5650E28124399107F21A1FA419401D3B8BF@ELON17P32002A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A5E96@EA-EXMSG-C334.europe.corp.microsoft.com> Ah now I see. The relevant comment, TcExpr line 465, says -- Doing record updates on -- GADTs and/or existentials is more than my tiny brain can cope with today Should be fixable, even with a tiny brain. Simon | -----Original Message----- | From: Sittampalam, Ganesh [mailto:ganesh.sittampalam@credit-suisse.com] | Sent: 10 September 2008 17:43 | To: Simon Peyton-Jones; Wolfgang Jeltsch; glasgow-haskell-users@haskell.org | Cc: Dimitrios Vytiniotis | Subject: RE: Is FPH implemented in GHC? | | > | A possibly related question is whether you would expect to make | record | > | selectors and updaters work for all record types at the same time? | > | That would definitely be very useful. | | > I'm not sure what you mean by this. Would you care to elaborate? | | The most important thing for me is supporting record update for | existentially | quantified data records, as in the error below. | | In general I also find working with code that involves existential type | variables quite hard work - for example I can't use foo as a record | selector | either, even if I immediately do something that seals the existential | type back | up again. | | I don't understand this stuff well enough to be sure whether it's an | impredicativity issue or not, though. | | Cheers, | | Ganesh | | Foo.hs:11:8: | Record update for the non-Haskell-98 data type `Foo' is not (yet) | supported | Use pattern-matching instead | In the expression: rec {foo = id} | In the definition of `f': f rec = rec {foo = id} | | {-# LANGUAGE Rank2Types #-} | | module Foo where | | data Foo = forall a . Foo { foo :: a -> a, bar :: Int } | | x :: Foo | x = Foo { foo = id, bar = 3 } | | f :: Foo -> Foo | f rec = rec { foo = id } | | g :: Foo -> Foo | g rec = rec { bar = 3 } | | ============================================================================= | = | Please access the attached hyperlink for an important electronic | communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================= | = | From simonpj at microsoft.com Sun Sep 14 10:11:20 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sun Sep 14 10:08:58 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> Neil It's by design, and for (I think) good reason. 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 Here "rigid" means "fully known to the compiler, usually by way of a type signature". This rule is to make type inference simple and predictable -- it dramatically simplifies inference. To see the issue, ask yourself what is the type of this function data E a where EI :: E Int f EI = 3::Int Should the inferred type be f :: E a -> a or f :: E a -> Int We can't tell, and neither is more general than the other. So GHC insists on knowing the result type. That's why you had to give the signature g::[()] in your example. So that's the story. If you find situations in which it's very hard to give a signature for the result type, I'd like to see them. Dimitrios has just written an Appendix to our ICFP paper about GADT inference, explaining the inference scheme -- it is not otherwise written up anywhere. I'll put it up shortly. Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Mitchell, Neil | Sent: 12 September 2008 13:51 | To: glasgow-haskell-users@haskell.org | Subject: GADT problems | | Hi | | The following code works in GHC 6.8.3, works in GHC 6.9.20071111, but | doesn't work in GHC HEAD. | | {-# LANGUAGE GADTs, ScopedTypeVariables #-} | | module Test where | | data E x = E x | | data Foo where | Foo :: Gadt a -> Foo | | data Gadt a where | GadtValue :: Gadt (E a) | | f (Foo GadtValue) = True | f _ = False | | Under GHC HEAD I get the error: | | GADT pattern match with non-rigid result type `t' | Solution: add a type signature | In the definition of `f': f (Foo GadtValue) = True | | Adding a type signature to f fixes this problem: | | f :: Foo -> Bool | | But I haven't found anywhere other than the top level f to add a type | signature. When the match is in a list comprehension, it becomes much | harder. While playing further I discovered this example: | | foos = undefined | g = [() | Foo GadtValue <- foos] | | This code doesn't compile under GHC HEAD, but does under 6.8.3. However, | adding the type signature: | | g :: [()] | | Makes the code compile. This is surprising, as [()] isn't a GADT type, | so shouldn't need stating explicitly. | | Any help on what these errors mean, or how they can be fixed with local | type annotations? | | Thanks | | Neil | | ============================================================================= | = | Please access the attached hyperlink for an important electronic | communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================= | = | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dagit at codersbase.com Sun Sep 14 17:45:21 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Sep 14 17:42:54 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Sun, Sep 14, 2008 at 7:11 AM, Simon Peyton-Jones wrote: > Neil > > It's by design, and for (I think) good reason. 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 > > Here "rigid" means "fully known to the compiler, usually by way of a type signature". This rule is to make type inference simple and predictable -- it dramatically simplifies inference. > > To see the issue, ask yourself what is the type of this function > > data E a where > EI :: E Int > > f EI = 3::Int > > Should the inferred type be > f :: E a -> a > or > f :: E a -> Int > We can't tell, and neither is more general than the other. So GHC insists on knowing the result type. That's why you had to give the signature g::[()] in your example. > > > So that's the story. If you find situations in which it's very hard to give a signature for the result type, I'd like to see them. I find that usually when it becomes difficult is when I'm using existential types and lexically scoped type variables. I don't have an example ready but I could vaguely describe it. For example, using a case expression to pattern match on a constructor that has an existential type and also expecting part of the type of that expression to match a lexically scope type variable (I'm often also using phantom types, if that matters). In this case, I usually end up adding a where clause to specify the type signature while dancing around the other issues. It's typically not pretty but at the end of the day I've always been able to find a way to specify the type I need. Although, it does make me quite aware that GHC could report the type errors better when dealing with phantom types that are bound to an existential type. If you have multiple such phantoms as part of the type it can be quite confusing to figure out which ones the type checker isn't happy with. data Sealed a where Sealed :: a x y -> Sealed a data Foo a x y where .... case sealedFoo where Sealed (Foo 4) -> ... If you get a type error in the above sometimes it's hard to figure out if it's happening with x or with y. Sometimes the type parameter name chosen doesn't give you a hint about which type parameter of Foo is not unifying. I wish I had a concrete example to show you. I guess the next time it shows up I should send it in. Thanks, Jason From leledumbo_cool at yahoo.co.id Mon Sep 15 00:10:24 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Sep 15 00:07:56 2008 Subject: How to print output and ask input on the same line Message-ID: <19487040.post@talk.nabble.com> This is my main function: main = do putStr "What's the value that each equation must satisfy? " c <- readLn putStr "How many unknowns are there? " n <- readLn sequence_ (result c n) Using runhugs / winhugs / ghci, I can see every output of putStr before it stops for readLn. But compiling it with ghc, it just stops for readLn and putStr output is printed together with sequence_' one. So, instead of: What's the value that each equation must satisfy? How many unknowns are there? I got: What's the value that each equation must satisfy? How many unknowns are there? Hope that's clear enough. -- View this message in context: http://www.nabble.com/How-to-print-output-and-ask-input-on-the-same-line-tp19487040p19487040.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From leledumbo_cool at yahoo.co.id Mon Sep 15 00:11:54 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Sep 15 00:09:26 2008 Subject: How to directly strip ghc generated binaries Message-ID: <19487054.post@talk.nabble.com> Sometimes it's annoying to call strip --strip-all everytime after compilation. Is there anything like gcc's -s so that debugging symbols aren't included? -- View this message in context: http://www.nabble.com/How-to-directly-strip-ghc-generated-binaries-tp19487054p19487054.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From dons at galois.com Mon Sep 15 00:17:34 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 15 00:15:01 2008 Subject: How to directly strip ghc generated binaries In-Reply-To: <19487054.post@talk.nabble.com> References: <19487054.post@talk.nabble.com> Message-ID: <20080915041734.GA26666@scytale.galois.com> leledumbo_cool: > > Sometimes it's annoying to call strip --strip-all everytime > after compilation. Is there anything like gcc's -s so that debugging symbols > aren't included? Use cabal to build your application. It strips the applications for you, in a portable manner. From mad.one at gmail.com Mon Sep 15 00:53:38 2008 From: mad.one at gmail.com (Austin Seipp) Date: Mon Sep 15 00:51:17 2008 Subject: How to print output and ask input on the same line In-Reply-To: <19487040.post@talk.nabble.com> References: <19487040.post@talk.nabble.com> Message-ID: <1221454347-sup-3519@existential.local> It's a buffering issue. You'll need to do: > hSetBuffering stdout NoBuffering Before running putStr and doing readLn. Austin From leledumbo_cool at yahoo.co.id Mon Sep 15 00:56:57 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Sep 15 00:54:31 2008 Subject: How to directly strip ghc generated binaries In-Reply-To: <20080915041734.GA26666@scytale.galois.com> References: <19487054.post@talk.nabble.com> <20080915041734.GA26666@scytale.galois.com> Message-ID: <19487282.post@talk.nabble.com> Don Stewart-2 wrote: > > Use cabal to build your application. It strips the applications for you, > in a portable manner. > Even if it's only a single module program? That's far too complicated! -- View this message in context: http://www.nabble.com/How-to-directly-strip-ghc-generated-binaries-tp19487054p19487282.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From dons at galois.com Mon Sep 15 01:03:23 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 15 01:00:50 2008 Subject: How to directly strip ghc generated binaries In-Reply-To: <19487282.post@talk.nabble.com> References: <19487054.post@talk.nabble.com> <20080915041734.GA26666@scytale.galois.com> <19487282.post@talk.nabble.com> Message-ID: <20080915050323.GC26666@scytale.galois.com> leledumbo_cool: > Don Stewart-2 wrote: > > > > Use cabal to build your application. It strips the applications for you, > > in a portable manner. > > > Even if it's only a single module program? That's far too complicated! It depends on if you want to deploy the code, and if you want to do it portably. Since you're stripping, I guess you do want to deploy. So for that you need a build system. Here, an example. A single module program, that uses cabal. http://code.haskell.org/~dons/code/rss2irc/ As a result, it can be widely distributed from hackage, or natively packaged, or what not. Cabal is easy. -- Don From leledumbo_cool at yahoo.co.id Mon Sep 15 01:03:20 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Sep 15 01:00:54 2008 Subject: How to print output and ask input on the same line In-Reply-To: <1221454347-sup-3519@existential.local> References: <19487040.post@talk.nabble.com> <1221454347-sup-3519@existential.local> Message-ID: <19487319.post@talk.nabble.com> Austin Seipp wrote: > > It's a buffering issue. You'll need to do: > >> hSetBuffering stdout NoBuffering > > Before running putStr and doing readLn. > Just as I thought. Thanks, I'll try when I get home. -- View this message in context: http://www.nabble.com/How-to-print-output-and-ask-input-on-the-same-line-tp19487040p19487319.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From neil.mitchell.2 at credit-suisse.com Mon Sep 15 03:51:32 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 03:49:43 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39D8@ELON17P32001A.csfb.cs-group.com> Hi Simon, I appreciate that everything must be rigid, but am still confused. Given the following operation: op (Foo GadtValue) = () I can add a top-level type signature, and it works: op :: Foo -> () But just putting those same type annotations in the actual function doesn't work: op (Foo GadtValue :: Foo) = () :: () From a simple point of view those two functions seem to have the same amount of type information, but GHC gives different behaviour. I think this is the underlying problem I'm getting. For things like list-comps and cases I don't seem to be able to find any combination of annotations that works, but that is because I'm not using top-level annotations. Thanks Neil > -----Original Message----- > From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] > Sent: 14 September 2008 3:11 pm > To: Mitchell, Neil; glasgow-haskell-users@haskell.org > Subject: RE: GADT problems > > Neil > > It's by design, and for (I think) good reason. 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 > > Here "rigid" means "fully known to the compiler, usually by > way of a type signature". This rule is to make type > inference simple and predictable -- it dramatically > simplifies inference. > > To see the issue, ask yourself what is the type of this function > > data E a where > EI :: E Int > > f EI = 3::Int > > Should the inferred type be > f :: E a -> a > or > f :: E a -> Int > We can't tell, and neither is more general than the other. > So GHC insists on knowing the result type. That's why you > had to give the signature g::[()] in your example. > > > So that's the story. If you find situations in which it's > very hard to give a signature for the result type, I'd like > to see them. > > Dimitrios has just written an Appendix to our ICFP paper > about GADT inference, explaining the inference scheme -- it > is not otherwise written up anywhere. I'll put it up shortly. > > Thanks > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org > | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf Of > | Mitchell, Neil > | Sent: 12 September 2008 13:51 > | To: glasgow-haskell-users@haskell.org > | Subject: GADT problems > | > | Hi > | > | The following code works in GHC 6.8.3, works in GHC > 6.9.20071111, but > | doesn't work in GHC HEAD. > | > | {-# LANGUAGE GADTs, ScopedTypeVariables #-} > | > | module Test where > | > | data E x = E x > | > | data Foo where > | Foo :: Gadt a -> Foo > | > | data Gadt a where > | GadtValue :: Gadt (E a) > | > | f (Foo GadtValue) = True > | f _ = False > | > | Under GHC HEAD I get the error: > | > | GADT pattern match with non-rigid result type `t' > | Solution: add a type signature > | In the definition of `f': f (Foo GadtValue) = True > | > | Adding a type signature to f fixes this problem: > | > | f :: Foo -> Bool > | > | But I haven't found anywhere other than the top level f to > add a type > | signature. When the match is in a list comprehension, it > becomes much > | harder. While playing further I discovered this example: > | > | foos = undefined > | g = [() | Foo GadtValue <- foos] > | > | This code doesn't compile under GHC HEAD, but does under 6.8.3. > | However, adding the type signature: > | > | g :: [()] > | > | Makes the code compile. This is surprising, as [()] isn't a > GADT type, > | so shouldn't need stating explicitly. > | > | Any help on what these errors mean, or how they can be fixed with > | local type annotations? > | > | Thanks > | > | Neil > | > | > ====================================================================== > | ======= > | = > | Please access the attached hyperlink for an important electronic > | communications disclaimer: > | > | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > | > ====================================================================== > | ======= > | = > | > | _______________________________________________ > | 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 neil.mitchell.2 at credit-suisse.com Mon Sep 15 04:11:20 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 04:09:45 2008 Subject: Windows HEAD issues In-Reply-To: <20080913000758.GA9899@matrix.chaos.earth.li> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3994@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A2@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A5@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A6@ELON17P32001A.csfb.cs-group.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39A7@ELON17P32001A.csfb.cs-group.com> <20080913000758.GA9899@matrix.chaos.earth.li> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39DA@ELON17P32001A.csfb.cs-group.com> Hi > If you want to put it on a different machine then you'll have > to do it as part of a GHC bindist (make binary-dist). If > that's not working then can you please give more details, > showing what's going wrong? I did do a binary-dist, and that wasn't working when moved to a different machine. Unfortunately I've tweaked and hacked at too much now to know whether haddock is working or not, and if I've broken it or not. Will try and remember to take a look when I make a fresh build. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 15 04:45:00 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 04:42:36 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39D8@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39D8@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A60EA@EA-EXMSG-C334.europe.corp.microsoft.com> | I appreciate that everything must be rigid, but am still confused. Given | the following operation: | | op (Foo GadtValue) = () | | I can add a top-level type signature, and it works: | | op :: Foo -> () | | But just putting those same type annotations in the actual function | doesn't work: | | op (Foo GadtValue :: Foo) = () :: () The thing is that GHC doesn't know the result type of the match *at the match point*. Suppose you had written op (Foo GadtValue :: Foo) = id (() :: ()) or op (Foo GadtValue :: Foo) = if blah then () :: () else () or op (Foo GadtValue :: Foo) = let x = blah in () :: () The signature is too far "inside". We need to know it from "outside". | I think this is the underlying problem I'm getting. For things like | list-comps and cases I don't seem to be able to find any combination of | annotations that works, but that is because I'm not using top-level | annotations. Perhaps you can give an example that shows your difficulty? Simon From simonpj at microsoft.com Mon Sep 15 04:55:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 04:53:21 2008 Subject: GADT problems In-Reply-To: References: <33A3F585590A6F4E81E3D45AA4A111C902CD39CE@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F29@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A610C@EA-EXMSG-C334.europe.corp.microsoft.com> | > So that's the story. If you find situations in which it's very hard to give a signature for | the result type, I'd like to see them. | | I find that usually when it becomes difficult is when I'm using | existential types and lexically scoped type variables. | ... | | I wish I had a concrete example to show you. I guess the next time it | shows up I should send it in. Yes, please do! I'm always interested in bad type error messages. S From bulat.ziganshin at gmail.com Mon Sep 15 05:20:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Sep 15 05:33:36 2008 Subject: How to directly strip ghc generated binaries In-Reply-To: <19487054.post@talk.nabble.com> References: <19487054.post@talk.nabble.com> Message-ID: <64482359.20080915132036@gmail.com> Hello leledumbo, Monday, September 15, 2008, 8:11:54 AM, you wrote: > Sometimes it's annoying to call strip --strip-all everytime > after compilation. Is there anything like gcc's -s so that debugging symbols > aren't included? ghc -optl-s -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From neil.mitchell.2 at credit-suisse.com Mon Sep 15 05:58:10 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 05:56:42 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A60EA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39D8@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A60EA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> Hi Simon, > | op (Foo GadtValue :: Foo) = () :: () > > The thing is that GHC doesn't know the result type of the > match *at the match point*. Suppose you had written > > op (Foo GadtValue :: Foo) = id (() :: ()) or > op (Foo GadtValue :: Foo) = if blah then () :: () else () or > op (Foo GadtValue :: Foo) = let x = blah in () :: () > > The signature is too far "inside". We need to know it from > "outside". Ah, this is the crucial bit I've been misunderstanding! Instinctively it feels that when a GADT can't type check I should be annotating the GADT part - but that's not the case, I should be annotating the expression containing both the GADT match and its right-hand side. I think the way the error message is formatted (add a type signature, followed by giving the local pattern) seems to hint at this. With this insight I've managed to fix up all the real problems I was experiencing. My general method for solving these problems was to find an expression or statement that enclosed both the left and right hand sides, and add ":: Int" to it. I then recompiled and got an error message saying it couldn't match Int with . I then replaced Int with and it worked. It seems surprising that the compiler can't jump through those hoops for me, but I realise my particular cases may be uncommon or the complexity may be too great. A nice addition to the error message would be hinting at where the type signature should go, if it can reasonably be determined. > | I think this is the underlying problem I'm getting. For things like > | list-comps and cases I don't seem to be able to find any > combination > | of annotations that works, but that is because I'm not > using top-level > | annotations. > > Perhaps you can give an example that shows your difficulty? The following is a fake example I was playing with: {-# LANGUAGE GADTs, ScopedTypeVariables #-} module Test where data E x = E x data Foo a where Foo :: Gadt a -> Foo a data Gadt a where GadtValue :: a -> Gadt (E a) g :: [()] g = [() | Foo (GadtValue _) <- undefined] :: [()] I couldn't figure out how to supply enough annotations to allow the code to work. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 15 06:27:42 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 06:25:16 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39D8@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A60EA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> | > | op (Foo GadtValue :: Foo) = () :: () | > | > The thing is that GHC doesn't know the result type of the | > match *at the match point*. Suppose you had written | > | > op (Foo GadtValue :: Foo) = id (() :: ()) or | > op (Foo GadtValue :: Foo) = if blah then () :: () else () or | > op (Foo GadtValue :: Foo) = let x = blah in () :: () | > | > The signature is too far "inside". We need to know it from | > "outside". | | Ah, this is the crucial bit I've been misunderstanding! Instinctively it | feels that when a GADT can't type check I should be annotating the GADT | part - but that's not the case, I should be annotating the expression | containing both the GADT match and its right-hand side. I think the way | the error message is formatted (add a type signature, followed by giving | the local pattern) seems to hint at this. With this insight I've managed | to fix up all the real problems I was experiencing. Great. Now you can help me! Look at the documentation here http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html#gadt The last bullet. What could I add that would eliminate your misunderstanding? You are in the ideal position to suggest concrete wording, because you know the problem and the solution. Examples are fine. Thanks | > Perhaps you can give an example that shows your difficulty? | | The following is a fake example I was playing with: | | {-# LANGUAGE GADTs, ScopedTypeVariables #-} | module Test where | | data E x = E x | | data Foo a where | Foo :: Gadt a -> Foo a | | data Gadt a where | GadtValue :: a -> Gadt (E a) | | g :: [()] | g = [() | Foo (GadtValue _) <- undefined] :: [()] | | I couldn't figure out how to supply enough annotations to allow the code | to work. The error message here is: GADT pattern match in non-rigid context for `GadtValue' Solution: add a type signature In the pattern: GadtValue _ In the pattern: Foo (GadtValue _) In a stmt of a list comprehension: Foo (GadtValue _) <- undefined And indeed, the type of 'undefined' (which is the scrutinee of this particular pattern match) is forall a. a. Very non-rigid! You need a type signature for the scrutinee. For example, this works: g :: [()] g = [() | Foo (GadtValue _) <- undefined :: [Foo (E ())]] Does that help? Again, what words would help in the user manual. Simon From neil.mitchell.2 at credit-suisse.com Mon Sep 15 06:48:24 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 06:46:38 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> Hi > | Ah, this is the crucial bit I've been misunderstanding! > Instinctively > | it feels that when a GADT can't type check I should be > annotating the > | GADT part - but that's not the case, I should be annotating the > | expression containing both the GADT match and its > right-hand side. I > | think the way the error message is formatted (add a type signature, > | followed by giving the local pattern) seems to hint at > this. With this > | insight I've managed to fix up all the real problems I was > experiencing. > > Great. Now you can help me! Look at the documentation here > http://www.haskell.org/ghc/dist/current/docs/users_guide/data- > type-extensions.html#gadt > The last bullet. > > What could I add that would eliminate your misunderstanding? > You are in the ideal position to suggest concrete wording, > because you know the problem and the solution. Examples are fine. My mistunderstanding stems from: (case undefined of Foo GadtValue -> ()) :: () -- is rigid (case undefined of Foo GadtValue -> () :: ()) -- not rigid The wording in the user manual is perfectly correct, but my intuition of how rigidity propogates was wrong. I'm also still not sure how the scrutinee (undefined in this case) is rigid, when in your response you said undefined was very non-rigid. An example in the user manual would be good, but having the compiler identify where the missing type signature is would be significantly better (albeit significantly more work). The example that would have helped me is: Given the case expression: case scrutinee of GadtConstructor variable -> result The potential type signatures that may be required to ensure rigidity are: (case scrutinee :: t of GadtConstructor (variable :: t) -> result) :: t > You need a type signature for the scrutinee. For example, this works: > > g :: [()] > g = [() | Foo (GadtValue _) <- undefined :: [Foo (E ())]] > > Does that help? Again, what words would help in the user manual. In this particular case I don't fully understand the implications, because the example is fake. If I encounter these issues in real code, I'll take another look. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 15 07:18:58 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 07:16:41 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> | > What could I add that would eliminate your misunderstanding? | > You are in the ideal position to suggest concrete wording, | > because you know the problem and the solution. Examples are fine. | | My mistunderstanding stems from: | | (case undefined of Foo GadtValue -> ()) :: () -- is rigid | | (case undefined of Foo GadtValue -> () :: ()) -- not rigid No, the former isn't rigid either. BOTH the scrutinee AND the return type must be rigid, and in the former case the scrutinee does not have a rigid type. | I'm also still not sure how the scrutinee (undefined in this case) is | rigid, when in your response you said undefined was very non-rigid. Quite right. See my comment above. | An example in the user manual would be good, but having the compiler | identify where the missing type signature is would be significantly | better (albeit significantly more work). The example that would have | helped me is: | | Given the case expression: | | case scrutinee of | GadtConstructor variable -> result | | The potential type signatures that may be required to ensure rigidity | are: | | (case scrutinee :: t of | GadtConstructor (variable :: t) -> result) :: t OK. Can you give a sample program and the error message you'd like to see? If you can suggest improvements to the manual I'm all ears. Notably, it says nothing about what "rigid" means or how it propagates. Simon From g9ks157k at acme.softbase.org Mon Sep 15 07:48:36 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Sep 15 07:46:10 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F2B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200809101620.55644.g9ks157k@acme.softbase.org> <200809101750.12350.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F2B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200809151348.36763.g9ks157k@acme.softbase.org> Am Sonntag, 14. September 2008 16:11 schrieben Sie: > | To implement all this stuff, I had to do quite a bit of code obfuscation. > | That is, I introduced a lot of trivial functions only to give them an > | explicit impredicative/rank 2 type signature. > > But impredicative is not the same as rank-2. GHC has done higher-rank > types for ages; but impredicative instantiation is a different story. Are > you sure that's the bit you need? Can you give an example? > > Simon Hello Simon, I know that rank 2 is something different. I need both, rank 2 and impredicativity. I already mentioned the (impredicative) type SSignal t (forall t'. SignalFun t' a). The full type of my switch operator is SSignal t (forall t'. SignalFun t' a) -> SignalFun t a. Some of the trivial functions, I mentioned above, have rank 2 types, some have impredicative types. The latter ones typically have types of the form f (forall t. signal t a) -> f (forall t. signal' t a') where f is some specific functor. And as far as I understood, FPH brings advantages for both rank n and impredicativity. Am I wrong at this point? Best wishes, Wolfgang From simonpj at microsoft.com Mon Sep 15 08:05:35 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 08:03:10 2008 Subject: Is FPH implemented in GHC? In-Reply-To: <200809151348.36763.g9ks157k@acme.softbase.org> References: <200809101620.55644.g9ks157k@acme.softbase.org> <200809101750.12350.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D764A5F2B@EA-EXMSG-C334.europe.corp.microsoft.com> <200809151348.36763.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C8@EA-EXMSG-C334.europe.corp.microsoft.com> | Some of the trivial functions, I mentioned above, have rank 2 types, some have | impredicative types. The latter ones typically have types of the form | | f (forall t. signal t a) -> f (forall t. signal' t a') | | where f is some specific functor. Aha -- that's impredicative all right. Good thanks. | And as far as I understood, FPH brings advantages for both rank n and | impredicativity. Am I wrong at this point? No, you're right. Simon From neil.mitchell.2 at credit-suisse.com Mon Sep 15 08:24:34 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 08:32:41 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> > | My mistunderstanding stems from: > | > | (case undefined of Foo GadtValue -> ()) :: () -- is rigid > | > | (case undefined of Foo GadtValue -> () :: ()) -- not rigid > > No, the former isn't rigid either. BOTH the scrutinee AND > the return type must be rigid, and in the former case the > scrutinee does not have a rigid type. But the first compiles fine, so it seems that the scrutinee doesn't have to always be rigid? > | An example in the user manual would be good, but having the > compiler > | identify where the missing type signature is would be significantly > | better (albeit significantly more work). The example that > would have > | helped me is: > | > | Given the case expression: > | > | case scrutinee of > | GadtConstructor variable -> result > | > | The potential type signatures that may be required to > ensure rigidity > | are: > | > | (case scrutinee :: t of > | GadtConstructor (variable :: t) -> result) :: t > > OK. Can you give a sample program and the error message > you'd like to see? Given the program: g = case undefined of Foo GadtValue -> () I get the error message: Test.hs:13:12: GADT pattern match with non-rigid result type `t' Solution: add a type signature In a case alternative: Foo GadtValue -> () In the expression: case undefined of { Foo GadtValue -> () } In the definition of `g': g = case undefined of { Foo GadtValue -> () } Which last week I was reading as "add a type signature to Foo GadtValue -> ()". A better hint would be: Solution: add a type signature, probably at _TYPE_ (case undefined of { Foo GadtValue -> () }) :: _TYPE_ > If you can suggest improvements to the manual I'm all ears. > Notably, it says nothing about what "rigid" means or how it > propagates. I think the manual should give a conservative approximation of where type signatures should go -- i.e. if you put type signatures in all these places it will work. Details such as what rigid means or propagation rules are too unnecessary. My example in my previous mail would have helped me. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 15 08:48:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 08:45:53 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A635D@EA-EXMSG-C334.europe.corp.microsoft.com> | > | (case undefined of Foo GadtValue -> ()) :: () -- is rigid ... | | But the first compiles fine, so it seems that the scrutinee doesn't have | to always be rigid? Not for me! Either with 6.8.3 or HEAD. What compiler are you using? Simon $ ghc-6.8.3 -c Neil.hs Neil.hs:17:12: GADT pattern match in non-rigid context for `GadtValue' Solution: add a type signature In the pattern: GadtValue In the pattern: Foo GadtValue In a case alternative: Foo GadtValue -> () bash-3.2$ ~/builds-04/validate-HEAD/ghc/stage1-inplace/ghc -c Neil.hs Neil.hs:17:12: GADT pattern match in non-rigid context for `GadtValue' Solution: add a type signature In the pattern: GadtValue In the pattern: Foo GadtValue In a case alternative: Foo GadtValue -> () bash-3.2$ {-# LANGUAGE GADTs, ScopedTypeVariables #-} module Test where data E x = E x data Foo a where Foo :: Gadt a -> Foo a data Gadt a where GadtValue :: a -> Gadt (E a) g :: Int -> () g x = case undefined of Foo GadtValue -> () From neil.mitchell.2 at credit-suisse.com Mon Sep 15 08:56:23 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 08:54:57 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A635D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A635D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39E5@ELON17P32001A.csfb.cs-group.com> > | > | (case undefined of Foo GadtValue -> ()) :: () -- is rigid > ... > | > | But the first compiles fine, so it seems that the scrutinee doesn't > | have to always be rigid? > > Not for me! Either with 6.8.3 or HEAD. What compiler are you using? HEAD from last Thursday. The code I'm using is slightly different to your code, and is attached at the end of the message. Is matching Foo causing its argument to become rigid? Thanks Neil {-# LANGUAGE GADTs, ScopedTypeVariables #-} module Test where data E x = E x data Foo where Foo :: Gadt a -> Foo data Gadt a where GadtValue :: Gadt (E a) g :: () g = case undefined of Foo GadtValue -> () ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Mon Sep 15 09:00:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 08:58:04 2008 Subject: GADT problems In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD39E5@ELON17P32001A.csfb.cs-group.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A635D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E5@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A6386@EA-EXMSG-C334.europe.corp.microsoft.com> Ah -- you used an *existential* there! Yes, existentially-bound type variables are rigid. They stand for themselves, as it were. That resolves the mystery -- but it existentials admittedly introduce a new complication How should this be clarified? S | -----Original Message----- | From: Mitchell, Neil [mailto:neil.mitchell.2@credit-suisse.com] | Sent: 15 September 2008 13:56 | To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org | Subject: RE: GADT problems | | > | > | (case undefined of Foo GadtValue -> ()) :: () -- is rigid | > ... | > | | > | But the first compiles fine, so it seems that the scrutinee doesn't | > | have to always be rigid? | > | > Not for me! Either with 6.8.3 or HEAD. What compiler are you using? | | HEAD from last Thursday. The code I'm using is slightly different to | your code, and is attached at the end of the message. Is matching Foo | causing its argument to become rigid? | | Thanks | | Neil | | {-# LANGUAGE GADTs, ScopedTypeVariables #-} | module Test where | | data E x = E x | | data Foo where | Foo :: Gadt a -> Foo | | data Gadt a where | GadtValue :: Gadt (E a) | | g :: () | g = case undefined of | Foo GadtValue -> () | | ============================================================================== | Please access the attached hyperlink for an important electronic communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================== | From flippa at flippac.org Mon Sep 15 09:11:05 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Sep 15 09:08:44 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A6386@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E3@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A635D@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E5@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A6386@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1221484265.12058.5.camel@flippa-eee> [sent to list as well this time] On Mon, 2008-09-15 at 14:00 +0100, Simon Peyton-Jones wrote: > Ah -- you used an *existential* there! Yes, existentially-bound type variables are rigid. They stand for themselves, as it were. > > That resolves the mystery -- but it existentials admittedly introduce a new complication > > How should this be clarified? > For me, "existentially-bound variables are rigid" works well enough. They're a somewhat non-obvious case of 'coming from an annotation' though, and it does warrant mention. -- Philippa Cowderoy From Christian.Maeder at dfki.de Mon Sep 15 10:54:22 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Sep 15 10:51:57 2008 Subject: SVN binding with Haskell In-Reply-To: <1220969616.6626.2.camel@GI32> References: <1220969616.6626.2.camel@GI32> Message-ID: <48CE771E.9010305@dfki.de> 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 neil.mitchell.2 at credit-suisse.com Mon Sep 15 11:43:21 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 11:45:33 2008 Subject: Building GHC with time package Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39E8@ELON17P32001A.csfb.cs-group.com> Hi, I want to build GHC HEAD with the time package. I figured out how to do it by editing packages and removing the word extralibs, but that doesn't seem to be the correct way. I suspected I might be able to get time included by giving some incantation to ./darcs-all, but I couldn't figure out what - commands such as help and --help to darcs all were little use. What is the correct way to add a library into the GHC build? If someone tells me I'll add it to the wiki somewhere. I tried looking here: http://hackage.haskell.org/trac/ghc/wiki/Building Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From neil.mitchell.2 at credit-suisse.com Mon Sep 15 12:22:46 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 12:24:59 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A6386@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E5@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A6386@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39EC@ELON17P32001A.csfb.cs-group.com> > Ah -- you used an *existential* there! Yes, > existentially-bound type variables are rigid. They stand for > themselves, as it were. > How should this be clarified? I'd leave it. I wanted a simple set of rules stating "_if_ you provide the following type signatures your code _will_ compile", which is what you currently provide, albeit I interpreted 'result' slightly differently. If people want to learn where these type signatures can be omitted (because a type is already rigid) people can follow the papers, or learn by trial and error. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From dagit at codersbase.com Mon Sep 15 14:00:29 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Sep 15 13:58:02 2008 Subject: GADT problems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD39E0@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A61F4@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD39E2@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D764A626D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Mon, Sep 15, 2008 at 4:18 AM, Simon Peyton-Jones wrote: > > If you can suggest improvements to the manual I'm all ears. Notably, it says nothing about what "rigid" means or how it propagates. A good solid definition of rigid would be nice. You pointed me at a paper on wobbly types that I found to be quite helpful in my understanding of the type checking issues. The paper told me that roughly speaking rigid means explicit. Once I was armed with just that information I started tackling more and more of these type check problems. Thanks, Jason From vss at 73rus.com Mon Sep 15 15:59:52 2008 From: vss at 73rus.com (Vlad Skvortsov) Date: Mon Sep 15 15:57:25 2008 Subject: getting (more) profiling data Message-ID: <48CEBEB8.5090406@73rus.com> Hi! I'm trying to get (more) profiling data out of a program compiled with GHC. Here is a link to a thread with the problem description in haskell-cafe: http://www.nabble.com/-Fwd:-profiling-in-haskell--td19383536.html Thank you! -- Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com From mechvel at botik.ru Tue Sep 16 11:01:31 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Sep 16 10:59:37 2008 Subject: making 6.9.. with 6.8.3 Message-ID: <20080916150131.GA28872@scico.botik.ru> Dear GHC team, I again have problems with making GHC from source. Now, this is for making ghc-6.9.20080910-src.tar.bz with ghc-6.8.3. ./configure --prefix=... reports that Happy is needed. But earlier, I compiled ghc-6.8.3 with itself, and it did not required Happy. Generally, as I recall, I got used to making GHC from source without installing Happy. Please, what (and why) has changed about this? Maybe ghc-6.8.3 has Happy inside it and ghc-6.9.20080910-src has not? Here are the fragments of config.log for ghc-6.8.3 auto-make: --------------------------------------- ... It was created by The Glorious Glasgow Haskell Compilation System configure 6.8.3, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/home/mechvel/ghc/6.8.3/inst ## --------- ## ## Platform. ## ## --------- ## hostname = scico uname -m = i686 uname -r = 2.6.22-1-686 uname -s = Linux uname -v = #1 SMP Mon Jul 23 13:23:02 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/mechvel/ghc/6.8.3/inst1/bin ... ... configure:5565: result: /home/mechvel/ghc/6.8.3/inst1/bin/ghc-pkg configure:5707: checking for happy configure:5740: result: no configure:5744: checking for version of happy configure:5757: result: configure:5794: checking for haddock configure:5827: result: no configure:5837: checking for alex configure:5870: result: no configure:5874: checking for version of alex configure:5887: result: ... ... #define _FILE_OFFSET_BITS 64 configure: exit 0 --------------------------------------------------------------- Why ghc-6.9.20080910-src.tar.bz cannot produce such? What I am missing? Can you somehow preserve the `make' procedure between the versions? Second, several years ago I was able to `make' Happy. Now, I tried to make Happy-1.17, with ghc-6.8.3. But it occurs difficult to find out how to do this. This is not like with GHC. The source GHC has README in the root of the `make' directory, where it is visible an short instruction ./configure ... make make install And in Happy, I do not find such. I am unhappy with Happy. Please, advise, ----------------- Serge Mechveliani mechvel@botik.ru From mad.one at gmail.com Tue Sep 16 19:36:12 2008 From: mad.one at gmail.com (Austin Seipp) Date: Tue Sep 16 19:33:44 2008 Subject: making 6.9.. with 6.8.3 In-Reply-To: <20080916150131.GA28872@scico.botik.ru> References: <20080916150131.GA28872@scico.botik.ru> Message-ID: <1221608053-sup-6424@existential.local> The release tarballs come with an already-happy-generated parser; the darcs version does not (because the parser could change as new extensions are brought in through the development process, so it makes more sense to have to generate it with happy every time to get the latest parser changes.) Austin From allbery at ece.cmu.edu Tue Sep 16 19:49:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Sep 16 19:46:31 2008 Subject: making 6.9.. with 6.8.3 In-Reply-To: <20080916150131.GA28872@scico.botik.ru> References: <20080916150131.GA28872@scico.botik.ru> Message-ID: <8A0B778A-C1FC-486C-8957-A353F3D496B0@ece.cmu.edu> On 2008 Sep 16, at 11:01, Serge D. Mechveliani wrote: > reports that Happy is needed. > But earlier, I compiled ghc-6.8.3 with itself, > and it did not required Happy. > Generally, as I recall, I got used to making GHC from source without > installing Happy. > Please, what (and why) has changed about this? Development snapshots don't include generated files, as a general rule. -- 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 Wed Sep 17 05:35:26 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 17 05:33:29 2008 Subject: making Happy-1.17 Message-ID: <20080917093526.GA30395@scico.botik.ru> Dear team of Happy, Please, where to find the `make' instruction for Happy-1.17 ? How to `make' it from source on Linux, i386 ? I have ghc-6.8.3 installed, and Cabal. As I see happy.cabal, maybe, Happy can be `made' similarly as I make (with Cabal and GHC) my programs under GHC (?). So, I command cd ~/happy/happy-1.17/ runhaskell Setup.lhs configure -v --ghc --prefix=/home/mechvel/happy/happy-1.17/inst It reports Configuring happy-1.17... Setup.lhs: At least the following dependencies are missing: mtl >=1.0 Please, help, ----------------- Serge Mechveliani mechvel@botik.ru From berthold at Mathematik.Uni-Marburg.de Wed Sep 17 05:36:22 2008 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Wed Sep 17 05:33:51 2008 Subject: Adding (some) libraries to a GHC tree Message-ID: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> Hi Neil, You can manually add any package which is listed in http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories by getting it (with darcs), directly into the /libraries subdirectory. When you later use darcs-all, the added library will be included when pulling new changes etc. I have added a wiki page to explain this: http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild (feel free to remove it and add the material to a more convenient place) HTH Jost From neil.mitchell.2 at credit-suisse.com Wed Sep 17 05:39:36 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 17 05:38:55 2008 Subject: making Happy-1.17 In-Reply-To: <20080917093526.GA30395@scico.botik.ru> References: <20080917093526.GA30395@scico.botik.ru> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A02@ELON17P32001A.csfb.cs-group.com> Hi Serge, > It reports > Configuring happy-1.17... > Setup.lhs: At least the following dependencies are missing: > mtl >=1.0 First make mtl, which is avaiable here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mtl Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From neil.mitchell.2 at credit-suisse.com Wed Sep 17 05:50:29 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 17 05:49:05 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> Hi Jost, Many thanks, that's perfect. I moved the page to http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building Thanks Neil > -----Original Message----- > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] > Sent: 17 September 2008 10:36 am > To: Mitchell, Neil > Cc: glasgow-haskell-users@haskell.org > Subject: Adding (some) libraries to a GHC tree > > Hi Neil, > > You can manually add any package which is listed in > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories > by getting it (with darcs), directly into the /libraries subdirectory. > When you later use darcs-all, the added library will be > included when pulling new changes etc. > > I have added a wiki page to explain this: > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild > (feel free to remove it and add the material to a more > convenient place) > > HTH > Jost > > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Wed Sep 17 06:10:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 17 06:08:11 2008 Subject: making Happy-1.17 In-Reply-To: <20080917093526.GA30395@scico.botik.ru> References: <20080917093526.GA30395@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7657AF4D@EA-EXMSG-C334.europe.corp.microsoft.com> Why not grab a binary distribution? | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 17 September 2008 10:35 | To: Simon Marlow | Cc: glasgow-haskell-users@haskell.org | Subject: making Happy-1.17 | | Dear team of Happy, | | Please, where to find the `make' instruction for Happy-1.17 ? | How to `make' it from source on Linux, i386 ? | I have ghc-6.8.3 installed, and Cabal. | As I see happy.cabal, maybe, Happy can be `made' similarly as I | make (with Cabal and GHC) my programs under GHC (?). | So, I command | | cd ~/happy/happy-1.17/ | runhaskell Setup.lhs configure -v --ghc | --prefix=/home/mechvel/happy/happy-1.17/inst | It reports | Configuring happy-1.17... | Setup.lhs: At least the following dependencies are missing: | mtl >=1.0 | | Please, help, | | ----------------- | 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 mechvel at botik.ru Wed Sep 17 07:20:51 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 17 07:19:42 2008 Subject: making Happy-1.17 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D7657AF4D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080917093526.GA30395@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D7657AF4D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080917112051.GA9050@scico.botik.ru> On Wed, Sep 17, 2008 at 11:10:17AM +0100, Simon Peyton-Jones wrote: > Why not grab a binary distribution? > > [..] > | cd ~/happy/happy-1.17/ > | runhaskell Setup.lhs configure -v --ghc > | --prefix=/home/mechvel/happy/happy-1.17/inst I thank people who advised me on my recent request about installing GHC snapshot and Happy. The result of the whole investigation is as follows. 1. Installing ghc-6.9.20080907-i386-unknown-linux.tar.bz2 (from binary) leads to ./configure --prefix=... make install ------------- ... installPackage: Saved package config file seems to be corrupt. Try re-running the 'configure' command. ----------------------------------------------- 2. To `make' a ghc-6.9 snapshot from source by GHC, I need to first install Happy and Alex. 3. I discovered that the simplest way to install Happy and Alex on my Debian Linux, i386 is to command apt-get install happy apt-get install alex -- because they are in the Debian Linux distributive. Now, `making' of ghc-6.9.. is in progress, I hope, it will succeed. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From simonpj at microsoft.com Wed Sep 17 08:40:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 17 08:39:22 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> good stuff -- but with a big overlap with the "Getting more packages" section in http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources. Do you agree? Would it be possible to merge your new paragraphs into the existing page? If the existing page is too big and hard to navigate we could break it up. S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Mitchell, Neil | Sent: 17 September 2008 10:50 | To: Jost Berthold | Cc: glasgow-haskell-users@haskell.org | Subject: RE: Adding (some) libraries to a GHC tree | | Hi Jost, | | Many thanks, that's perfect. | | I moved the page to | http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and | referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building | | Thanks | | Neil | | > -----Original Message----- | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] | > Sent: 17 September 2008 10:36 am | > To: Mitchell, Neil | > Cc: glasgow-haskell-users@haskell.org | > Subject: Adding (some) libraries to a GHC tree | > | > Hi Neil, | > | > You can manually add any package which is listed in | > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories | > by getting it (with darcs), directly into the /libraries subdirectory. | > When you later use darcs-all, the added library will be | > included when pulling new changes etc. | > | > I have added a wiki page to explain this: | > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild | > (feel free to remove it and add the material to a more | > convenient place) | > | > HTH | > Jost | > | > | > | | ============================================================================== | Please access the attached hyperlink for an important electronic communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================== | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From donnie at darthik.com Wed Sep 17 08:52:45 2008 From: donnie at darthik.com (Donnie Jones) Date: Wed Sep 17 08:52:38 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Hello Simon, I agree that this page has a major overlap. I myself added additional libraries recently (time and parallel packages to libraries for GHC RTS parallel profiling testing), and it would have been helpful to have the information from AddingLibsToBuild page. At first, I assumed that additonal libraries would be grabbed like nofib and testsuite with "./darcs-all --testsuite get"; afterwards I did the same as Jost suggested using "darcs get http://darcs.haskell.org/packages/". Combining these two pages would decrease overlap and provide clarification, in my opinion. __ Donnie On Wed, Sep 17, 2008 at 8:40 AM, Simon Peyton-Jones wrote: > good stuff -- but with a big overlap with the "Getting more packages" > section in > http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources. Do > you agree? Would it be possible to merge your new paragraphs into the > existing page? > > If the existing page is too big and hard to navigate we could break it up. > > > S > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto: > glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Mitchell, Neil > | Sent: 17 September 2008 10:50 > | To: Jost Berthold > | Cc: glasgow-haskell-users@haskell.org > | Subject: RE: Adding (some) libraries to a GHC tree > | > | Hi Jost, > | > | Many thanks, that's perfect. > | > | I moved the page to > | http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and > | referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building > | > | Thanks > | > | Neil > | > | > -----Original Message----- > | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] > | > Sent: 17 September 2008 10:36 am > | > To: Mitchell, Neil > | > Cc: glasgow-haskell-users@haskell.org > | > Subject: Adding (some) libraries to a GHC tree > | > > | > Hi Neil, > | > > | > You can manually add any package which is listed in > | > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories > | > by getting it (with darcs), directly into the /libraries subdirectory. > | > When you later use darcs-all, the added library will be > | > included when pulling new changes etc. > | > > | > I have added a wiki page to explain this: > | > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild > | > (feel free to remove it and add the material to a more > | > convenient place) > | > > | > HTH > | > Jost > | > > | > > | > > | > | > ============================================================================== > | Please access the attached hyperlink for an important electronic > communications disclaimer: > | > | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > | > ============================================================================== > | > | _______________________________________________ > | 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080917/9b770bad/attachment-0001.htm From neil.mitchell.2 at credit-suisse.com Wed Sep 17 08:53:18 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 17 08:52:50 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> Hi The paragraph in the new page is better than the old one, but it makes sense to have the information in only one place. When looking for the information "getting the sources" didn't occur to me as a description of how to get any extra libraries (although on reflection, I'm surprised I didn't try it). Thanks Neil > -----Original Message----- > From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] > Sent: 17 September 2008 1:40 pm > To: Mitchell, Neil; Jost Berthold > Cc: glasgow-haskell-users@haskell.org > Subject: RE: Adding (some) libraries to a GHC tree > > good stuff -- but with a big overlap with the "Getting more > packages" section in > http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSo > urces. Do you agree? Would it be possible to merge your new > paragraphs into the existing page? > > If the existing page is too big and hard to navigate we could > break it up. > > > S > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org > | [mailto:glasgow-haskell-users- bounces@haskell.org] On Behalf Of > | Mitchell, Neil > | Sent: 17 September 2008 10:50 > | To: Jost Berthold > | Cc: glasgow-haskell-users@haskell.org > | Subject: RE: Adding (some) libraries to a GHC tree > | > | Hi Jost, > | > | Many thanks, that's perfect. > | > | I moved the page to > | http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and > | referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building > | > | Thanks > | > | Neil > | > | > -----Original Message----- > | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] > | > Sent: 17 September 2008 10:36 am > | > To: Mitchell, Neil > | > Cc: glasgow-haskell-users@haskell.org > | > Subject: Adding (some) libraries to a GHC tree > | > > | > Hi Neil, > | > > | > You can manually add any package which is listed in > | > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories > | > by getting it (with darcs), directly into the /libraries > subdirectory. > | > When you later use darcs-all, the added library will be included > | > when pulling new changes etc. > | > > | > I have added a wiki page to explain this: > | > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild > | > (feel free to remove it and add the material to a more convenient > | > place) > | > > | > HTH > | > Jost > | > > | > > | > > | > | > ====================================================================== > | ======== Please access the attached hyperlink for an important > | electronic communications disclaimer: > | > | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > | > ====================================================================== > | ======== > | > | _______________________________________________ > | 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 berthold at Mathematik.Uni-Marburg.de Wed Sep 17 09:48:43 2008 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Wed Sep 17 09:46:14 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group. com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> Message-ID: <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> Mitchell, Neil wrote: > Hi > > The paragraph in the new page is better than the old one, but it makes > sense to have the information in only one place. When looking for the > information "getting the sources" didn't occur to me as a description of > how to get any extra libraries (although on reflection, I'm surprised I > didn't try it). > > Thanks > > Neil Hi everybody, all of you are right! :) The information I have added should definitely be close to where --extra is explained. However, the overlap is not that big: "Getting more packages" talks about getting a 'package of packages', all extras in one go. What I added is information about not getting everything, but exactly the few lib.s which you miss. (another question is, how many people would want that...) As a result: I suggest my paragraph should be put right below the explanation of darcs --extra, perhaps shortened accordingly. The only reason I made it a (tiny) new page is that I saw the extra section "contributed doc.", so I thought I should put my contribution here to be moved into more "official" pages by other wiki maintainers (i.e. Neil in this case) later. Jost >> -----Original Message----- >> From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] >> Sent: 17 September 2008 1:40 pm >> To: Mitchell, Neil; Jost Berthold >> Cc: glasgow-haskell-users@haskell.org >> Subject: RE: Adding (some) libraries to a GHC tree >> >> good stuff -- but with a big overlap with the "Getting more >> packages" section in >> http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSo >> urces. Do you agree? Would it be possible to merge your new >> paragraphs into the existing page? >> >> If the existing page is too big and hard to navigate we could >> break it up. >> >> >> S >> | -----Original Message----- >> | From: glasgow-haskell-users-bounces@haskell.org >> | [mailto:glasgow-haskell-users- bounces@haskell.org] On Behalf Of >> | Mitchell, Neil >> | Sent: 17 September 2008 10:50 >> | To: Jost Berthold >> | Cc: glasgow-haskell-users@haskell.org >> | Subject: RE: Adding (some) libraries to a GHC tree >> | >> | Hi Jost, >> | >> | Many thanks, that's perfect. >> | >> | I moved the page to >> | http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and >> | referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building >> | >> | Thanks >> | >> | Neil >> | >> | > -----Original Message----- >> | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] >> | > Sent: 17 September 2008 10:36 am >> | > To: Mitchell, Neil >> | > Cc: glasgow-haskell-users@haskell.org >> | > Subject: Adding (some) libraries to a GHC tree >> | > >> | > Hi Neil, >> | > >> | > You can manually add any package which is listed in >> | > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories >> | > by getting it (with darcs), directly into the /libraries >> subdirectory. >> | > When you later use darcs-all, the added library will be included >> | > when pulling new changes etc. >> | > >> | > I have added a wiki page to explain this: >> | > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild >> | > (feel free to remove it and add the material to a more convenient >> | > place) >> | > >> | > HTH >> | > Jost >> | > >> | > >> | > >> | >> | >> ====================================================================== >> | ======== Please access the attached hyperlink for an important >> | electronic communications disclaimer: >> | >> | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html >> | >> ====================================================================== >> | ======== >> | >> | _______________________________________________ >> | 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 simonpj at microsoft.com Wed Sep 17 09:54:44 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 17 09:52:21 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B170@EA-EXMSG-C334.europe.corp.microsoft.com> great. Can you just do the merge? You are hereby appointed an "accredited wiki maintainer"! | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jost Berthold | Sent: 17 September 2008 14:49 | To: Mitchell, Neil | Cc: Jost Berthold; glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: RE: Adding (some) libraries to a GHC tree | | Mitchell, Neil wrote: | > Hi | > | > The paragraph in the new page is better than the old one, but it makes | > sense to have the information in only one place. When looking for the | > information "getting the sources" didn't occur to me as a description of | > how to get any extra libraries (although on reflection, I'm surprised I | > didn't try it). | > | > Thanks | > | > Neil | | Hi everybody, | | all of you are right! :) The information I have added should definitely be | close to where --extra is explained. However, the overlap is not that big: | "Getting more packages" talks about getting a 'package of packages', all | extras in one go. What I added is information about not getting | everything, but exactly the few lib.s which you miss. | (another question is, how many people would want that...) | | As a result: I suggest my paragraph should be put right below the | explanation of darcs --extra, perhaps shortened accordingly. | The only reason I made it a (tiny) new page is that I saw the extra | section "contributed doc.", so I thought I should put my contribution here | to be moved into more "official" pages by other wiki maintainers (i.e. | Neil in this case) later. | | Jost | | | >> -----Original Message----- | >> From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] | >> Sent: 17 September 2008 1:40 pm | >> To: Mitchell, Neil; Jost Berthold | >> Cc: glasgow-haskell-users@haskell.org | >> Subject: RE: Adding (some) libraries to a GHC tree | >> | >> good stuff -- but with a big overlap with the "Getting more | >> packages" section in | >> http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSo | >> urces. Do you agree? Would it be possible to merge your new | >> paragraphs into the existing page? | >> | >> If the existing page is too big and hard to navigate we could | >> break it up. | >> | >> | >> S | >> | -----Original Message----- | >> | From: glasgow-haskell-users-bounces@haskell.org | >> | [mailto:glasgow-haskell-users- bounces@haskell.org] On Behalf Of | >> | Mitchell, Neil | >> | Sent: 17 September 2008 10:50 | >> | To: Jost Berthold | >> | Cc: glasgow-haskell-users@haskell.org | >> | Subject: RE: Adding (some) libraries to a GHC tree | >> | | >> | Hi Jost, | >> | | >> | Many thanks, that's perfect. | >> | | >> | I moved the page to | >> | http://hackage.haskell.org/trac/ghc/wiki/Building/AddingLibs , and | >> | referenced it from http://hackage.haskell.org/trac/ghc/wiki/Building | >> | | >> | Thanks | >> | | >> | Neil | >> | | >> | > -----Original Message----- | >> | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] | >> | > Sent: 17 September 2008 10:36 am | >> | > To: Mitchell, Neil | >> | > Cc: glasgow-haskell-users@haskell.org | >> | > Subject: Adding (some) libraries to a GHC tree | >> | > | >> | > Hi Neil, | >> | > | >> | > You can manually add any package which is listed in | >> | > http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories | >> | > by getting it (with darcs), directly into the /libraries | >> subdirectory. | >> | > When you later use darcs-all, the added library will be included | >> | > when pulling new changes etc. | >> | > | >> | > I have added a wiki page to explain this: | >> | > http://hackage.haskell.org/trac/ghc/wiki/AddingLibsToBuild | >> | > (feel free to remove it and add the material to a more convenient | >> | > place) | >> | > | >> | > HTH | >> | > Jost | >> | > | >> | > | >> | > | >> | | >> | | >> ====================================================================== | >> | ======== Please access the attached hyperlink for an important | >> | electronic communications disclaimer: | >> | | >> | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | >> | | >> ====================================================================== | >> | ======== | >> | | >> | _______________________________________________ | >> | 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 | > ============================================================================== | > | > | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From berthold at Mathematik.Uni-Marburg.de Wed Sep 17 10:22:34 2008 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Wed Sep 17 10:20:03 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B170@EA-EXMSG-C334.europe.corp. microsoft.com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B170@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <34416.213.199.128.147.1221661354.squirrel@www.mathematik.uni-marburg.de> Simon Peyton-Jones wrote: > great. Can you just do the merge? You are hereby appointed an "accredited > wiki maintainer"! Thank you :) I edited GettingTheSources as we said, and removed the links from the /Building page. Neil, if you think the extra links should be kept, sorry and please revert. Jost From neil.mitchell.2 at credit-suisse.com Wed Sep 17 10:38:21 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Wed Sep 17 10:37:04 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <34416.213.199.128.147.1221661354.squirrel@www.mathematik.uni-marburg.de> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B170@EA-EXMSG-C334.europe.corp.microsoft.com> <34416.213.199.128.147.1221661354.squirrel@www.mathematik.uni-marburg.de> Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0B@ELON17P32001A.csfb.cs-group.com> Hi Jost, It looks great now. When I saw the contributed documentation I did wonder if that was the GHC sanctioned way of adding information to the wiki - which defeats the purpose of a wiki somewhat. Perhaps all the "Contributed documentation" titles could be changed to "Miscellaneous documentation", and then merged in to the main stuff over time. Thanks Neil > -----Original Message----- > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] > Sent: 17 September 2008 3:23 pm > To: Simon Peyton-Jones > Cc: Mitchell, Neil; glasgow-haskell-users@haskell.org > Subject: RE: Adding (some) libraries to a GHC tree > > Simon Peyton-Jones wrote: > > great. Can you just do the merge? You are hereby appointed an > > "accredited wiki maintainer"! > > Thank you :) I edited GettingTheSources as we said, and > removed the links from the /Building page. > Neil, > if you think the extra links should be kept, sorry and > please revert. > > Jost > > > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Wed Sep 17 12:58:26 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 17 12:55:55 2008 Subject: Adding (some) libraries to a GHC tree In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0B@ELON17P32001A.csfb.cs-group.com> References: <62026.213.199.128.147.1221644182.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A03@ELON17P32001A.csfb.cs-group.com> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B0AA@EA-EXMSG-C334.europe.corp.microsoft.com> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0A@ELON17P32001A.csfb.cs-group.com> <30087.213.199.128.155.1221659323.squirrel@www.mathematik.uni-marburg.de> <638ABD0A29C8884A91BC5FB5C349B1C32D7657B170@EA-EXMSG-C334.europe.corp.microsoft.com> <34416.213.199.128.147.1221661354.squirrel@www.mathematik.uni-marburg.de> <33A3F585590A6F4E81E3D45AA4A111C902CD3A0B@ELON17P32001A.csfb.cs-group.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7657B330@EA-EXMSG-C334.europe.corp.microsoft.com> I've changed the "contributed docs" intro to make it clearer that we'd like edits everywhere! http://hackage.haskell.org/trac/ghc/wiki/Commentary Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Mitchell, Neil | Sent: 17 September 2008 15:38 | To: Jost Berthold; Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: RE: Adding (some) libraries to a GHC tree | | Hi Jost, | | It looks great now. | | When I saw the contributed documentation I did wonder if that was the | GHC sanctioned way of adding information to the wiki - which defeats the | purpose of a wiki somewhat. Perhaps all the "Contributed documentation" | titles could be changed to "Miscellaneous documentation", and then | merged in to the main stuff over time. | | Thanks | | Neil | | | | > -----Original Message----- | > From: Jost Berthold [mailto:berthold@Mathematik.Uni-Marburg.de] | > Sent: 17 September 2008 3:23 pm | > To: Simon Peyton-Jones | > Cc: Mitchell, Neil; glasgow-haskell-users@haskell.org | > Subject: RE: Adding (some) libraries to a GHC tree | > | > Simon Peyton-Jones wrote: | > > great. Can you just do the merge? You are hereby appointed an | > > "accredited wiki maintainer"! | > | > Thank you :) I edited GettingTheSources as we said, and | > removed the links from the /Building page. | > Neil, | > if you think the extra links should be kept, sorry and | > please revert. | > | > Jost | > | > | > | | ============================================================================== | Please access the attached hyperlink for an important electronic communications disclaimer: | | http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html | ============================================================================== | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From claus.reinke at talk21.com Wed Sep 17 19:30:42 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 17 19:28:11 2008 Subject: Who defines __GLASGOW_HASKELL__, __HADDOCK__, etc? Message-ID: So far, I had assumed that every tool defined its own macro, but it seems that __GLASGOW_HASKELL__ is defined by ghc and by cabal, while __HADDOCK__ is defined only by the latter. Is that right? Context is http://trac.haskell.org/haddock/ticket/48 , ie, how to adapt sources that had to bypass or help along haddock1 for haddock2 (which should need fewer workarounds). Claus From marlowsd at gmail.com Thu Sep 18 08:47:39 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 18 08:45:05 2008 Subject: simple questions about +RTS -s output In-Reply-To: References: Message-ID: <48D24DEB.8020101@gmail.com> Peter Hercek wrote: > Hi, > > There is an example of +RTS -s output at the end. > > I have few simple questions: > > What does "9 Mb total memory in use" mean? > Is it in mega bytes (MB) or in mega bits (Mb)? > I would expect memory usage to be in bytes (B) > but a unit for bits (b) seems to be used. > Looks like heap size in mega bytes... It's mega bytes (MB). I fixed the abbreviation a while ago, it'll be correct in 6.10.1. Also there are some new stats about the amount of memory being wasted due to fragmentation in the memory allocator. Cheers, Simon From ross at soi.city.ac.uk Thu Sep 18 08:51:19 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 18 08:48:43 2008 Subject: Who defines __GLASGOW_HASKELL__, __HADDOCK__, etc? In-Reply-To: References: Message-ID: <20080918125119.GA4317@soi.city.ac.uk> On Thu, Sep 18, 2008 at 12:30:42AM +0100, Claus Reinke wrote: > So far, I had assumed that every tool defined its own macro, > but it seems that __GLASGOW_HASKELL__ is defined by > ghc and by cabal, while __HADDOCK__ is defined only by > the latter. Is that right? Yes, Cabal defines __HADDOCK__ only for haddock1. haddock2 is supposed to be compatible with GHC. From mechvel at botik.ru Thu Sep 18 08:53:22 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Sep 18 08:51:38 2008 Subject: testing ghc-6.10-candidate Message-ID: <20080918125322.GA30261@scico.botik.ru> Simon Peyton-Jones wrote on 15 Sep 2008 about Instances and DoCon To: "Serge D. Mechveliani" CC: "cvs-ghc@haskell.org" > Serge > > I take it all back. I've been persuaded that it's best to accept > DoCon-sty le instances as they appear, and I've put quite a bit of > work into making it so. > > So you should not need to change any code. Do try the HEAD > (any recent snapshot should do) if you can. All right, I have tested ghc-6.9.20080910 on docon-2.12-pre. Find the source on http://botik.ru/pub/local/Mechveliani/ghcBugs/docon-2.12-pre.zip It is put there only for testing GHC, and it has the compilation flag denotation in docon.cabal improved for newer Cabal and ghc-6.10. The tet shows the followng. 1. It accepts the DoCon-style overlapping instances (as in docon-2.11) -- in the example of ... => LinSolvRing (Fraction a) that you pointed out below. 2. But in several places DoCon has parasitic additions (similar to the below MulSemigroup (Fraction a)) to the context for overlapping instances. These places are marked in the docon-2.12-pre source with 'overlaps in ghc'. I would like to cancel them, similar as we now cancel the above MulSemigroup (Fraction a) in the context. But ghc-6.9.20080910 does not allow this. So, I wonder: what is the difference? 3. `Making' under -O2 reports for the module Det_.hs several warnings of the kind ... [25 of 83] Compiling Det_ ( Det_.hs, dist/build/Det_.o ) SpecConstr: too many specialisations for one function (see -fspec-constr-count): Function: dt{v X1E1R} [lid] Specialisations: [([sc_s1E2A{v} [lid], sc_s1E2B{v} [lid], ... What might this mean? 4. It has improved: it `makes' docon-2.12 under -O fast enough, without code explosion, the code is as fast as expected. It also `makes' the test Main under -O fast enough (unlike ghc-6.8.3). 5. The same is for -O2. But this does not gain more performance. -O2 -fvia-C also does not gain more performance, but leads to 7 times longer compilation. Anyway, I am satisfied with -O. Regards, ----------------- Serge Mechveliani mechvel@botik.ru ------------------------------------------------------------------- | Good news: I have cured the massive code-explosion problem you | encountere with GHC 6.8. I'm | about to commit a patch for that, so it'll be in GHC 6.10. | | However, I'm now getting a complaint about overlapping instances | (DoCon 2.11). GHC 6.10 is | being a bit more consistent about coherence. Here is one example: | | Fraction.hs:124:48: | Overlapping instances for MulSemigroup (Fraction a) | arising from a use of `inv' at Fraction.hs:124:48-57 | Matching instances: | instance [overlap ok] (GCDRing a) =3D> MulSemigroup (Fraction a) | -- Defined at Fract_.hs:438:9-46 | instance [overlap ok] MulSemigroup (Fraction Integer) | -- Defined at Fraction.hs:260:9-39 | (The choice depends on the instantiation of `a' | To pick the first instance above, use -XIncoherentInstances | when compiling the other instance declarations) | | It's absolutely right! If you wanted the instance for | (MulSemigroup (Fraction Integer)), then | the call to inv could in principle use | MulSemigroup (Fraction Integer) instance, and give | different behaviour. (See the user manual stuff about incoherent- | instances.) | | Possible solutions: | a) add -XAllowIncoherentInstances | b) make the instance declaration look like | instance (MulSemigroup (Fraction a), GCDRing a) => | LinSolvRing (Fraction a) | thereby deferring the choice [..] From marlowsd at gmail.com Thu Sep 18 08:54:29 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 18 08:51:56 2008 Subject: -optl-s (strip) by default In-Reply-To: <98989560.20080912130901@gmail.com> References: <56123306.20080912123311@gmail.com> <20080912085422.GA5621@scytale.galois.com> <98989560.20080912130901@gmail.com> Message-ID: <48D24F85.4030708@gmail.com> Bulat Ziganshin wrote: > Hello Don, > > Friday, September 12, 2008, 12:54:22 PM, you wrote: > >>> when GHC builds executable, it adds debug info by default. since this >> You can also achieve this by making sure your deployed programs build >> with Cabal, >> http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html >> No need to hack GHC's view of the linker. > > btw, it seems like hack in 3rd party tool to fix weird default ghc behavior It might be weird, but it's traditional. Also the symbol information is sometimes useful: for example on Linux Valgrind understands it and can tell you which function has memory errors, or give you a profile (perhaps only useful for people working on the RTS like me). I don't feel that strongly about it though. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu Sep 18 12:04:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 18 11:59:59 2008 Subject: -optl-s (strip) by default In-Reply-To: <48D24F85.4030708@gmail.com> References: <56123306.20080912123311@gmail.com> <20080912085422.GA5621@scytale.galois.com> <98989560.20080912130901@gmail.com> <48D24F85.4030708@gmail.com> Message-ID: <1221753878.5395.479.camel@localhost> On Thu, 2008-09-18 at 13:54 +0100, Simon Marlow wrote: > Bulat Ziganshin wrote: > > Hello Don, > > > > Friday, September 12, 2008, 12:54:22 PM, you wrote: > > > >>> when GHC builds executable, it adds debug info by default. since this > >> You can also achieve this by making sure your deployed programs build > >> with Cabal, > >> http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html > >> No need to hack GHC's view of the linker. > > > > btw, it seems like hack in 3rd party tool to fix weird default ghc behavior > > It might be weird, but it's traditional. Also the symbol information is > sometimes useful: for example on Linux Valgrind understands it and can tell > you which function has memory errors, or give you a profile (perhaps only > useful for people working on the RTS like me). And some distros have a policy of managing striping themselves (and making it a user preference and allowing either stripping, no stripping or putting debug info in separate files on another part of the file system). Yes it's true that that debug info is not usually useful for Haskell progs like it is for C ones but just doing the same thing as other packages makes life easier for those distros. So the ability to turn it on/off easily when building is reasonably important and that's exactly the situation we have now with Cabal packages. So I think it's fine to leave the stripping feature there rather than pushing it lower into ghc (as we'd still need to be able to turn it on/off). Basically the status-quo is fine, imho. Duncan From simonpj at microsoft.com Fri Sep 19 04:37:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Sep 19 04:34:39 2008 Subject: Type binders in rules Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76620E76@EA-EXMSG-C334.europe.corp.microsoft.com> Friends This is a message for people who use RULES, to ask your opinion. Have a look at http://hackage.haskell.org/trac/ghc/ticket/2600 and add your comments if you want. The intro to the ticket appears below, so you can get an idea of whether you are interested. Simon Roman writes: I found an example I came across while working on the recycling paper and which I subsequently forgot about. Suppose we have: {-# LANGUAGE Rank2Types #-} module T where class T t where to :: [a] -> t a from :: t a -> [a] tmap :: (a -> a) -> t a -> t a {-# RULES "myrule" forall f x. from (tmap f (to x)) = map f (from (to x)) #-} Alas, this fails with: Ambiguous type variable `t' in the constraint: `T t' arising from a use of `to' at T.hs:12:40-43 Probable fix: add a type signature that fixes these type variable(s) Of course, I'd like the t on the rhs to be the same as on the lhs but I don't see how to tell this to GHC. Is it actually possible? The only solution I've found was to add a dummy argument to 'to': to' :: t a -> [a] -> t a to = to' undefined {-# RULES "myrule" forall f t x. from (tmap f (to' t x)) = map f (from (to' t x)) #-} That's ugly, of course. Am I missing something or is this just impossible to do with the current system? From simonpj at microsoft.com Fri Sep 19 05:26:01 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Sep 19 05:23:23 2008 Subject: Overlapping instance declarations Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76620EFB@EA-EXMSG-C334.europe.corp.microsoft.com> | 2. But in several places DoCon has parasitic additions | (similar to the below MulSemigroup (Fraction a)) | to the context for overlapping instances. | These places are marked in the docon-2.12-pre source with | 'overlaps in ghc'. | I would like to cancel them, similar as we now cancel the above | MulSemigroup (Fraction a) in the context. | But ghc-6.9.20080910 does not allow this. | So, I wonder: what is the difference? No you can't cancel them! Consider class Foo a where fop :: a->a instance Foo [a] where ... instance Foo [Int] where .. class Bar a where bop :: a -> a instance Bar [a] where bop = fop In the Bar [a] instance, we get a constraint (Foo [a]). It's wrong to commit to the Foo [a] instance, because if you are ultimately building a Bar [Int] instance you want the Foo [Int] instance of fop! The Right Thing is to add (Foo [a]) to the context of the Bar instance thus instance Foo [a] => Bar [a] where bop = fop I'll expand the user manual (in the section about overlapping instances) to cover this point. The other situation that DoCon contains is more like this: class C a where { op1,op2 :: a -> a } instance C [Int] where... instance C a => C [a] where op1 x = op2 x ++ op2 x op2 x = ... In the C [a] instance you'll see that op1 calls op2, thereby giving rise to a C [a] constraint. I *originally thought* that the same reasoning applied as above, so we should reject the program. But applying the solution I describe above would give instance C [a], C a => C [a] where .. which is silly. Here the Right Thing is to satisfy the C [a] constraint "locally", without worrying about the overlap. This is justified because we'll only be *in* the code for op1 in the C [a] instance if we know that 'a' does not match Int. Thanks for bringing this up. Simon From mechvel at botik.ru Fri Sep 19 11:01:41 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Sep 19 10:59:40 2008 Subject: Overlapping instance declarations In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76620EFB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D76620EFB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080919150141.GA1201@scico.botik.ru> Thank you for the explanation. ------ Sergey On Fri, Sep 19, 2008 at 10:26:01AM +0100, Simon Peyton-Jones wrote: > | 2. But in several places DoCon has parasitic additions > | (similar to the below MulSemigroup (Fraction a)) > | to the context for overlapping instances. > | These places are marked in the docon-2.12-pre source with > | 'overlaps in ghc'. > | I would like to cancel them, similar as we now cancel the above > | MulSemigroup (Fraction a) in the context. > | But ghc-6.9.20080910 does not allow this. > | So, I wonder: what is the difference? > > No you can't cancel them! Consider > > class Foo a where > fop :: a->a > instance Foo [a] where ... > instance Foo [Int] where .. > > class Bar a where > bop :: a -> a > > instance Bar [a] where > bop = fop > > In the Bar [a] instance, we get a constraint (Foo [a]). It's wrong to commit to the Foo [a] instance, because if you are ultimately building a Bar [Int] instance you want the Foo [Int] instance of fop! > > The Right Thing is to add (Foo [a]) to the context of the Bar instance thus > > instance Foo [a] => Bar [a] where > bop = fop > > I'll expand the user manual (in the section about overlapping instances) to cover this point. > > > The other situation that DoCon contains is more like this: > > class C a where { op1,op2 :: a -> a } > instance C [Int] where... > instance C a => C [a] where > op1 x = op2 x ++ op2 x > op2 x = ... > > In the C [a] instance you'll see that op1 calls op2, thereby giving rise to a C [a] constraint. I *originally thought* that the same reasoning applied as above, so we should reject the program. But applying the solution I describe above would give > > instance C [a], C a => C [a] where .. > > which is silly. Here the Right Thing is to satisfy the C [a] constraint "locally", without worrying about the overlap. This is justified because we'll only be *in* the code for op1 in the C [a] instance if we know that 'a' does not match Int. > > Thanks for bringing this up. From mechvel at botik.ru Sat Sep 20 03:52:22 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Sep 20 03:50:19 2008 Subject: Instances and DoCon In-Reply-To: <20080919191712.GA27781@matrix.chaos.earth.li> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A658A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916081309.GA27863@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A67C3@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916094150.GA28646@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A6850@EA-EXMSG-C334.europe.corp.microsoft.com> <20080919191712.GA27781@matrix.chaos.earth.li> Message-ID: <20080920075222.GA2659@scico.botik.ru> On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: > On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: > > | > > | And still ghc-6.8.3 builds itself from source. > > > > I have no idea how -- Happy has been needed for some time. Maybe someone else does. > > It's not meant to be needed for building from a source tarball. > This should be fixed now. Dear GHC team, can you, please, provide such GHC source distributives which require possibly smaller set of programs for the user to separately pre-install? For example, do not require of the user to install Alex, Happy and Cabal. Because we write applications in Haskell. For example, the user needs to program algebra by using some CA library written in Haskell. One needs to install GHC -- and the simpler the better. In this situation, it is bad to force him to think of what is Alex or Happy, and where to find them and how to install. The least hindrance in installation makes some users to reject the tool: "Oh! looks messy, suspicious thing. I tried the binary, but it reports of wrong libarary versions. I have already spent one hough! Also these pure functional languages look restrictive ... Let me better try the Foo system". Regards, ----------------- Serge Mechveliani mechvel@botik.ru From dagit at codersbase.com Sat Sep 20 04:12:43 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sat Sep 20 04:10:03 2008 Subject: Instances and DoCon In-Reply-To: <20080920075222.GA2659@scico.botik.ru> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A658A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916081309.GA27863@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A67C3@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916094150.GA28646@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A6850@EA-EXMSG-C334.europe.corp.microsoft.com> <20080919191712.GA27781@matrix.chaos.earth.li> <20080920075222.GA2659@scico.botik.ru> Message-ID: On Sat, Sep 20, 2008 at 12:52 AM, Serge D. Mechveliani wrote: > On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: >> On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: >> > | >> > | And still ghc-6.8.3 builds itself from source. >> > >> > I have no idea how -- Happy has been needed for some time. Maybe someone else does. >> >> It's not meant to be needed for building from a source tarball. >> This should be fixed now. > > Dear GHC team, > can you, please, provide such GHC source distributives which require > possibly smaller set of programs for the user to separately pre-install? > For example, do not require of the user to install Alex, Happy and Cabal. > > Because we write applications in Haskell. For example, the user needs to > program algebra by using some CA library written in Haskell. One needs to > install GHC -- and the simpler the better. In this situation, it is bad > to force him to think of what is Alex or Happy, and where to find them and > how to install. The least hindrance in installation makes some users to > reject the tool: > "Oh! looks messy, suspicious thing. I tried the binary, but it reports of > wrong libarary versions. I have already spent one hough! Also these pure > functional languages look restrictive ... Let me better try the Foo system". Don't most GHC users just install from a binary distribution? And if those users themselves are not Haskell developers, shouldn't they just be able to get a binary distribution of the applications they are after? Also, aren't Alex, Happy and Cabal available as packages or binary distributions on nearly every platform? I've never heard anyone complain about Happy, Alex and Cabal as reasons to avoid using an application written in Haskell or even GHC. So I have a hard time understanding your position. Maybe on some platform like Gentoo you need to install these dependencies, but then wouldn't the package manager assist you in installing them? Is it still a complaint when the build is automated? Jason From marlowsd at gmail.com Sat Sep 20 06:25:57 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Sep 20 06:23:24 2008 Subject: testing ghc-6.10-candidate In-Reply-To: <20080918125322.GA30261@scico.botik.ru> References: <20080918125322.GA30261@scico.botik.ru> Message-ID: <48D4CFB5.6060500@gmail.com> Serge D. Mechveliani wrote: > 5. The same is for -O2. But this does not gain more performance. > -O2 -fvia-C also does not gain more performance, but leads to 7 times > longer compilation. Just to be sure: are you saying that with -O2 the compile time is ok, but when you add -fvia-C it takes 7 times longer? If so, it's probably not a bug (we don't have any control over the speed of gcc). Here's the bug report: http://hackage.haskell.org/trac/ghc/ticket/2609 Sergey, could you clarify please? Cheers, Simon From mechvel at botik.ru Sat Sep 20 08:06:59 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Sep 20 08:04:47 2008 Subject: testing ghc-6.10-candidate In-Reply-To: <48D4CFB5.6060500@gmail.com> References: <20080918125322.GA30261@scico.botik.ru> <48D4CFB5.6060500@gmail.com> Message-ID: <20080920120659.GA2746@scico.botik.ru> On Sat, Sep 20, 2008 at 11:25:57AM +0100, Simon Marlow wrote: > Serge D. Mechveliani wrote: > > >5. The same is for -O2. But this does not gain more performance. > > -O2 -fvia-C also does not gain more performance, but leads to 7 times > > longer compilation. > > Just to be sure: are you saying that with -O2 the compile time is ok, > but when you add -fvia-C it takes 7 times longer? If so, it's probably > not a bug (we don't have any control over the speed of gcc). Here's the > bug report: > > http://hackage.haskell.org/trac/ghc/ticket/2609 > > Sergey, could you clarify please? With -O2, the compile time is ok, but when I add -fvia-C, it takes 7 times longer -- this is for ghc-6.9-earlySeptember to compile DoCon-2.12-pre. You do not control over the speed of gcc itself. But a small change in the GHC compiler may, in principle, lead to many times faster compilation by gcc of the code produced by GHC. This may occur some problem in GHC as well as some problem in gcc. This is only my observation, I do not pretend for a bug report in this case. I tried -fvia-C for curiosity: "by occasion, would it increase the code performance?". If this ratio of 7 looks curious to you, you could investigate this. And personally, I am satisfied with -O (without via-C). ------ Sergey From mechvel at botik.ru Sat Sep 20 08:21:19 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Sep 20 08:19:01 2008 Subject: skip -O2 via-C Message-ID: <20080920122119.GA2782@scico.botik.ru> I take back my two recent reports about the effect of -O2, -fvia-C. Because 1) -O is sufficient, 2) there are too many issues that are more important than the behavior under -O2 and via-C. So, it is a good idea to save effort. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Sun Sep 21 20:35:43 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 21 20:32:55 2008 Subject: ANNOUNCE: GHC 6.10.1 beta Message-ID: <20080922003543.GA29215@matrix.chaos.earth.li> We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a beta release of GHC 6.10.1. You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows, and a binary distribution for x86_64/Linux. More may appear later. There are a couple of known problems with the x86_64/Linux bindist: * It uses libedit.so.0 whereas some distributions (e.g. Debian) only provide libedit.so.2. * It installs utilities like unlit in the wrong place, so compiling literate code won't work. If you install from source then you won't hit either of those problems. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to have release candidates followed by a release in around 3 weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team From magicloud.magiclouds at gmail.com Sun Sep 21 22:19:00 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Sun Sep 21 22:16:27 2008 Subject: GHC 6.8.3's source is unusable? Message-ID: <48D70094.50909@gmail.com> Hi, I want to compile ghc on my office box, which does not have any binary ghc exist. So I followed http://hackage.haskell.org/trac/ghc/wiki/Building/Porting, "Porting GHC to a new platform" section. Well, this was what I got: (On target) $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target sytem type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for ghc... no checking for ghc-pkg matching... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2660: -v0: command not found ./configure: line 2664: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory What does this mean! From mad.one at gmail.com Mon Sep 22 00:14:20 2008 From: mad.one at gmail.com (Austin Seipp) Date: Mon Sep 22 00:11:33 2008 Subject: GHC 6.8.3's source is unusable? In-Reply-To: <48D70094.50909@gmail.com> References: <48D70094.50909@gmail.com> Message-ID: <1222056378-sup-1032@existential.local> Excerpts from Magicloud Magiclouds's message of Sun Sep 21 21:19:00 -0500 2008: > Hi, > I want to compile ghc on my office box, which does not have any > binary ghc exist. First, porting with an unregistered build is currently supported from GHC 6.4 to GHC 6.6 - it does not work in 6.8 nor will it work in 6.10 (ghc is getting a new build system and other nice stuff so hopefully it will be in 6.12.) Try with something like http://haskell.org/ghc/dist/6.4.2/ghc-6.4.2-src.tar.bz2 Of course, you must be able to build 6.4.2 on your host machine as well - if you are using Linux this shouldn't be a problem. Austin From magicloud.magiclouds at gmail.com Mon Sep 22 02:26:05 2008 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Mon Sep 22 02:23:28 2008 Subject: GHC 6.8.3's source is unusable? In-Reply-To: <1222056378-sup-1032@existential.local> References: <48D70094.50909@gmail.com> <1222056378-sup-1032@existential.local> Message-ID: <48D73A7D.2090904@gmail.com> I see.... So 6.8.3 is not portable.... So in my company-customed-linux box, ghc is nothing to me? Any way I can use it? Austin Seipp wrote: > Excerpts from Magicloud Magiclouds's message of Sun Sep 21 21:19:00 -0500 2008: > >> Hi, >> I want to compile ghc on my office box, which does not have any >> binary ghc exist. >> > > First, porting with an unregistered build is currently supported from > GHC 6.4 to GHC 6.6 - it does not work in 6.8 nor will it work in 6.10 > (ghc is getting a new build system and other nice stuff so hopefully > it will be in 6.12.) > > Try with something like > > http://haskell.org/ghc/dist/6.4.2/ghc-6.4.2-src.tar.bz2 > > Of course, you must be able to build 6.4.2 on your host machine as > well - if you are using Linux this shouldn't be a problem. > > Austin > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From gale at sefer.org Mon Sep 22 02:52:57 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Sep 22 02:50:08 2008 Subject: Debian stable not supported? Message-ID: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> The Debian ghc6 package for the stable distribution is currently back at GHC 6.6 - not surprising given the way stable works at Debian. There is currently no backport of a more recent GHC to Debian stable. I need GHC 6.8 for a project to run on a production server. That means it will be running Debian stable. Unfortunately, the so-called "generic" Linux binary distribution package for GHC 6.8.3 does not work on the current, up-to-date Debian stable distribution because it is "too old". In my case, and I suspect for many people, the production server running stable is on a low-cost hosted VPS. That kind of platform doesn't have nearly enough memory and disk space to compile GHC. So even that is not an option. I know that in the past Haskell was used exclusively for research, but nowadays shouldn't it be possible to use Haskell also for production-quality projects? With help from Igloo and thetallguy on #ghc, for which I am grateful, I was finally able to get a working GHC 6.8.3 on my production server, but only after jumping through a lot of hoops. It involved setting up a Debian-stable-like environment in a chroot on another computer, building GHC there from source, and manually moving all of the appropriate files up to the server. Before I delete that chroot build environment - could it be useful for making GHC 6.8.3 available to others? If someone points me in the right direction, perhaps I could create a binary tarball and/or backport deb. Or at least record somewhere the basic steps of how to get a recent GHC in this situation. Thanks Yitz From roma at ro-che.info Mon Sep 22 05:30:15 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon Sep 22 05:27:59 2008 Subject: Debian stable not supported? In-Reply-To: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> References: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> Message-ID: <20080922093015.GA4384@flit> * Yitzchak Gale [2008-09-22 09:52:57+0300] > Before I delete that chroot build environment - could it > be useful for making GHC 6.8.3 available to others? If someone > points me in the right direction, perhaps I could create a binary > tarball and/or backport deb. Or at least record somewhere the > basic steps of how to get a recent GHC in this situation. I think I'll face with the similar problem in the nearest future, except I have far more old system. So I'll be very greatful if you provide the instructions and record your experience. -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From haskell at list.mightyreason.com Mon Sep 22 06:48:16 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Sep 22 06:45:55 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <20080921165752.GA19677@matrix.chaos.earth.li> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> Message-ID: <48D777F0.7060907@list.mightyreason.com> I am cross-posting this message to several lists. I had learned the trick before the documentation was updated. It seems I have used a very unreliable trick. And the "use castToSTUArray" suggested alternative is a really poor one since I am not using arrays at all. Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the "binary" package). The alloca/poke/peek work around I have looks like castWord32ToFloat :: Word32 -> Float castWord32ToFloat x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) castFloatToWord32 :: Float -> Word32 castFloatToWord32 x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) The unsafeCoerce trick that is no longer working looks like: castWord64ToDouble :: Word64 -> Double castWord64ToDouble (W64# w) = D# (unsafeCoerce# w) castDoubleToWord64 :: Double -> Word64 castDoubleToWord64 (D# d) = W64# (unsafeCoerce# d) Any ideas? Or is the alloca trick the only way to do this? Chris Ian Lynagh wrote: > Hi Chris, > > On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote: >> Also, I tried two tricks: >> (D# x) <-> (W64# x) which works fine >> (F# x) <-> (W32# x) which produced garbage, so I had to replace it with >> alloca/poke/peek. > > This isn't supported, and I suspect is the cause of the -fasm problems. > > Please see > http://hackage.haskell.org/trac/ghc/ticket/2209 > for more details and suggested alternative. > > > Thanks > Ian > From gale at sefer.org Mon Sep 22 07:12:57 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Sep 22 07:10:20 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D777F0.7060907@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> <48D777F0.7060907@list.mightyreason.com> Message-ID: <2608b8a80809220412i64a77870ufb58cf2a1f734f0e@mail.gmail.com> Chris Kuklewicz wrote: > Who can suggest a way to cast from Float to Word32 and Double to Word64 > using ghc? The actual task is that I need to write out the Float as a > little endian sequence of four bytes and also be able to read it back in. > The writing and reading are done in Put and Get monads to ByteString (from > the "binary" package). I think alloca-like hacks is really the wrong direction and asking for trouble. You are trying to translate between platform-dependent native floats, and IEEE floats in a specified platform-independent binary format for Google. So use encodeFloat/decodeFloat - fast primitives in GHC - on the native side, and a hand-written Binary instance for the exact format you need on the Google side. My opinion, YMMV. Regards, Yitz From Christian.Maeder at dfki.de Mon Sep 22 09:32:40 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Sep 22 09:29:50 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080922003543.GA29215@matrix.chaos.earth.li> References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: <48D79E78.5040802@dfki.de> Ian Lynagh wrote: > Right now we have the source bundles: > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralibs.tar.bz2 I've tried to build a binary dist on x86 under Solaris and did not succeed. "make binary-dist" failed with 1. for FILE in ; do if [ -e $FILE ]; then echo ghc-6.10.0.20080921/gmp/$FILE >> /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list ; fi; done /bin/sh: syntax error at line 1: `;' unexpected gmake[1]: *** [binary-dist] Error 2 I added "strip" to bindist.mk: ifneq "$(strip $(BINDIST_EXTRAS))" "" 2. /bin/sh: test: argument expected gmake[1]: *** [binary-dist] Error 1 -e does not work for test under "sh", so I changed it to "-r": ... if [ -r $$FILE ]; then ... 3. tar hcf /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0. 20080921-i386-unknown-solaris2.tar -T /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list tar: -T: No such file or directory gmake: *** [binary-dist] Error 1 I changed tar to gtar 4. gtar: ghc-6.10.0.20080921/gmp/{}: Cannot stat: No such file or directory The file bindist-list contained "{}" instead of filenames, so I changed find to gfind. 5. When trying to install the binary distribution I got: Installing executable(s) in /local/home/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory) gmake[2]: *** [install] Error 1 gmake[2]: Leaving directory `/export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0.20080921/utils/installPackage' gmake[1]: *** [install.installPackage] Error 2 gmake[1]: Leaving directory `/export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0.20080921/utils' gmake: *** [install] Error 2 and I gave up. Cheers Christian P.S. I hope the OpenSPARC project will work under Solaris and sort out the above issues. (Validating under Solaris would be a good idea, too.) From gale at sefer.org Mon Sep 22 09:37:46 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Sep 22 09:34:56 2008 Subject: Debian stable not supported? In-Reply-To: <20080922093015.GA4384@flit> References: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> <20080922093015.GA4384@flit> Message-ID: <2608b8a80809220637r14fc6d0cv97204d4e1d02f182@mail.gmail.com> Hi Roman, Roman Cheplyaka wrote: > I think I'll face with the similar problem in the nearest future, except > I have far more old system. So I'll be very greatful if you provide the > instructions and record your experience. OK, here's a brief summary of what I did. I hope I'm not forgetting anything. (Looks like I may need to do this again soon for 6.10, unless they support Debian stable this time.) On a Debian testing system with some disk space: 1. Install the cdebootstrap package. 2. cdebootstrap --flavour=build etch JAIL http:://your.debian.mirror where JAIL is the path to a new directory that will now be created, and http://your.domain.mirror is the URL to your favorite Debian mirror. 3. Download the GHC 6.8.3 source tarball (ghc-6.8.3-src.tar.bz2) and put it in JAIL/root/. 4. Become root. 5. cd JAIL/root 6. chroot .. You are now root in a simulated copy of the etch distribution. 7. apt-get update 8. apt-get install ghc6 9. tar xjvf ghc-6.8.3-src.tar.bz2 10. cd ghc-6.8.3 11. ./configure 12. make 13. Go to sleep. Wake up the next morning - it's done. 14. make install 15. ^D to exit the chroot jail. ^D again to exit the root shell. You are now yourself again. 16. cd JAIL 17. tar cjvf ghc-6.8.3-etch.tar.bz2 usr/local/bin usr/local/lib/ghc-6.8.3 usr/local/share/doc/ghc 18. Upload ghc-6.8.3-etch.tar.bz2 to your target etch machine. Now, on the target etch machine: 19. cd / 20. sudo tar xjvf /path/to/ghc-6.8.3-etch.tar.bz2 21. Make sure that /usr/local/bin is in your PATH by default. Regards, Yitz From wferi at niif.hu Mon Sep 22 11:00:52 2008 From: wferi at niif.hu (Ferenc Wagner) Date: Mon Sep 22 10:58:06 2008 Subject: Debian stable not supported? In-Reply-To: <2608b8a80809220637r14fc6d0cv97204d4e1d02f182@mail.gmail.com> (Yitzchak Gale's message of "Mon, 22 Sep 2008 16:37:46 +0300") References: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> <20080922093015.GA4384@flit> <2608b8a80809220637r14fc6d0cv97204d4e1d02f182@mail.gmail.com> Message-ID: <878wtk5ior.fsf@tac.ki.iif.hu> "Yitzchak Gale" writes: > Roman Cheplyaka wrote: > >> I think I'll face with the similar problem in the nearest future, except >> I have far more old system. So I'll be very greatful if you provide the >> instructions and record your experience. > > (Looks like I may need to do this again soon for 6.10, > unless they support Debian stable this time.) Hi, Looks like it would be best to coordinate with debian-haskell: http://urchin.earth.li/pipermail/debian-haskell/2008-September/000492.html -- Cheers, Feri. From kili at outback.escape.de Mon Sep 22 13:19:17 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Sep 22 13:17:16 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D79E78.5040802@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> Message-ID: <20080922171917.GA3143@petunia.outback.escape.de> On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote: > I've tried to build a binary dist on x86 under Solaris and did not succeed. > > "make binary-dist" failed with > > 1. > for FILE in ; do if [ -e $FILE ]; then echo > ghc-6.10.0.20080921/gmp/$FILE >> > /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list > ; fi; done > /bin/sh: syntax error at line 1: `;' unexpected > gmake[1]: *** [binary-dist] Error 2 > > > I added "strip" to bindist.mk: > ifneq "$(strip $(BINDIST_EXTRAS))" "" This part could be done a little bit different (without the conditional): ... # And enything else echo $(BINDIST_EXTRAS) | \ xargs -n1 | \ sed '/^$/d;s/.*/test -e & \&\& echo $(WHERE_AM_I)\/&/' | \ sh >> $(BIND_DIST_LIST) (untested!) > 2. > /bin/sh: test: argument expected > gmake[1]: *** [binary-dist] Error 1 > > -e does not work for test under "sh", so I changed it to "-r": > ... if [ -r $$FILE ]; then ... I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does this "argument expected" still appear with your fix to 1.? > 3. > tar hcf /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0. > 20080921-i386-unknown-solaris2.tar -T > /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list > tar: -T: No such file or directory > gmake: *** [binary-dist] Error 1 > > I changed tar to gtar Or use pax(1), which in contrast to tar(1) and gtar(1) is POSIX: pax -hwf $(BIN_DIST_TAR) < $(BIN_DIST_LIST) (also untested, but should work) > 4. > gtar: ghc-6.10.0.20080921/gmp/{}: Cannot stat: No such file or directory > > The file bindist-list contained "{}" instead of filenames, so I changed > find to gfind. Or just omit all the -exec echo ${WHERE_AM_I}/{} goo and use find(1) and sed(1), e.g.: find $(WHATEVER) -print | sed 's/^/$(WHERE_AM_I}\//' > 5. When trying to install the binary distribution I got: > > Installing executable(s) in /local/home/maeder/bin > installPackage: dist-install/build/installPackage/installPackage: > copyFile: does not exist (No such file or directory) Maybe fallout from some of the above problems? Ciao, Kili From Christian.Maeder at dfki.de Mon Sep 22 13:43:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Sep 22 13:40:53 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080922171917.GA3143@petunia.outback.escape.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> Message-ID: <48D7D950.506@dfki.de> Matthias Kilian wrote: >> 2. >> /bin/sh: test: argument expected >> gmake[1]: *** [binary-dist] Error 1 >> >> -e does not work for test under "sh", so I changed it to "-r": >> ... if [ -r $$FILE ]; then ... > > I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does > this "argument expected" still appear with your fix to 1.? It does not work on my system (SunOS 5.10 Generic_137112-07 i86pc): -bash-3.1$ sh $ test -e log test: argument expected $ exit -bash-3.1$ test -e log (it works in the bash, though) > Or use pax(1), which in contrast to tar(1) and gtar(1) is POSIX: > > pax -hwf $(BIN_DIST_TAR) < $(BIN_DIST_LIST) > > (also untested, but should work) I don't know pax, but it is installed on our machines. >> 5. When trying to install the binary distribution I got: >> >> Installing executable(s) in /local/home/maeder/bin >> installPackage: dist-install/build/installPackage/installPackage: >> copyFile: does not exist (No such file or directory) > > Maybe fallout from some of the above problems? No, on an Intel Mac I got the same error (without the previous problems): Installing executable(s) in /Users/Shared/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory) make[2]: *** [install] Error 1 make[1]: *** [install.installPackage] Error 2 make: *** [install] Error 2 Thanks anyway Christian From jason.dusek at gmail.com Mon Sep 22 17:02:55 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Sep 22 17:00:05 2008 Subject: GHC 6.8.3's source is unusable? In-Reply-To: <48D73A7D.2090904@gmail.com> References: <48D70094.50909@gmail.com> <1222056378-sup-1032@existential.local> <48D73A7D.2090904@gmail.com> Message-ID: <42784f260809221402h5470b371o6e6c2a273778387d@mail.gmail.com> Magicloud wrote: > I see.... So 6.8.3 is not portable.... > So in my company-customed-linux box, ghc is nothing to me? > Any way I can use it? What kind of machine do you have? -- _jsn From weihu at cs.virginia.edu Mon Sep 22 17:28:32 2008 From: weihu at cs.virginia.edu (Wei Hu) Date: Mon Sep 22 21:07:13 2008 Subject: ANNOUNCE: GHC 6.10.1 beta References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: I tried it out in Emacs, but ghci always displays some sort of garbage message. For example, when I ask for the value of 0, I get: 0^J0 Is it because ghci switched to libedit? I'm running Emacs-23 with haske-mode- cvs on Debian unstable. From mad.one at gmail.com Mon Sep 22 21:48:53 2008 From: mad.one at gmail.com (Austin Seipp) Date: Mon Sep 22 21:46:03 2008 Subject: Some initial results with DPH Message-ID: <1222132386-sup-8143@existential.local> (I'm posting this here in the hope people like Manual and Roman will see it and take some interest.) I've built the GHC 6.10 beta (that is, The Glorious Glasgow Haskell Compilation System, version 6.10.0.20080921) mainly so I could play around with DPH because it's too exciting to ignore any longer. The program I'm using here is pretty trivial but it's a simple enough test case, I think. It's really cribbed from dph's examples almost entirely, I just made some superficial data sets to test on and here are the results. The code is attached in a .tar file; you'll need to tweak the Makefile to point to your GHC instead of mine if you use it. Things to note: * The vectorise pass boosts compilation times *a lot*. I don't think this is exactly unwarrented since it seems like a pretty complicated transformation, but while making the primitive version using just the unlifted interface the compilation takes about 1.5 seconds, for the vectorised version it's on the order of 15 seconds. For something as trivial as this dot-product thing, that's a bit of a compilation time, though. * It's pretty much impossible to use ghc-core to examine the output core of the vectorised version - I let it run and before anything started showing up in `less` it was already using on the order of 100mb of memory. If I just add -ddump-simpl to the command line, the reason is obvious: the core generated is absolutely huge. * For the benchmark included, the vectorised ver. spends about 98% of its time from what I can see in the GC before it dies from stack overflow. I haven't tried something like +RTS -A1G -RTS yet, though. * The vectoriser is really, really touchy. For example, the below code sample works (from DotPVect.hs): > import Data.Array.Parallel.Prelude.Int as I > > dotp :: [:Int:] -> [:Int:] -> Int > dotp v w = I.sumP [: (I.*) x y | x <- v, y <- w :] This however, does not work: > dotp :: [:Int:] -> [:Int:] -> Int > dotp v w = I.sumP [: (Prelude.*) x y | x <- v, y <- w :] That is, just using the version from Prelude causes the vectoriser to err like so: > ghc -o vect --make test.hs -fcpr-off -threaded -Odph -funbox-strict-fields -fdph-par > [1 of 2] Compiling DotPVect ( DotPVect.hs, DotPVect.o ) > *** Vectorisation error *** > Tycon not vectorised: GHC.Num.:TNum > make: *** [vect] Error 1 > This is a particularly strange occurance; reason being if we dig into the source code of the dph-par package we see that Data.Array.Parallel.Prelude.Int simply re-exports Data.Array.Parallel.Prelude.Base.Int (which is a hidden module, mind you) which is where (*) is defined, and it is defined like so: > (+), (-), (*) :: Int -> Int -> Int > (+) = (P.+) > (-) = (P.-) > (*) = (P.*) Where 'P' is the qualified Prelude import. Am I misunderstanding something here about how the dph packages are layed out? I think this is pretty correct and if so it's a really really strange happening to be honest. I also ran into a few other errs relating to the vectoriser dying - if I can find some I'll reply to this with some results. So far this all seems pretty negative, but on the flip-side... * The unlifted interface exported by the dph-prim-{par,seq} packages is wonderful and already works really well. See http://hpaste.org/10621 for an example - super low-GC time, both of my cores get used. * As I have increased the data sets for the dot-product example, my cores continue to get used and the GC time stays really, really low which is a great thing. * I've yet to hit any strange compilation err or problem when using the primitive packages. * Strictly speaking the dph-{par,seq} packages seem to expose more to code and combinators to those pieces of code using the vectorisation pass, but the combinators here are simple, they work and you get good results. * GHC hits a lot of optimizations, with ghc-core you can see thousands upon thousands of rules firing all over the place to aggressively inline/transform things! The DPH work done so far seems fantastic and I realize this is all in the works so everything I say now might not be worth anything tomorrow, and GHC 6.10 is only shipping with a very limited version of the system, but I figured some people would like to see initial results on some small test cases. I plan on exploiting this package a lot more in the future and testing it with larger computations and data sets, and when I do I'll be sure to give the feedback to you guys (once HEAD is steaming along again and the 6.10 branch has calmed.) Austin -------------- next part -------------- A non-text attachment was scrubbed... Name: test1.tar.gz Type: application/x-gzip Size: 845 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080922/956c7e27/test1.tar.bin From judah.jacobson at gmail.com Tue Sep 23 00:27:35 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Sep 23 00:25:06 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: <6d74b0d20809222127p3d894d41q869431caf5fe5527@mail.gmail.com> On Mon, Sep 22, 2008 at 2:28 PM, Wei Hu wrote: > I tried it out in Emacs, but ghci always displays some sort of garbage message. > For example, when I ask for the value of 0, I get: > 0^J0 > > Is it because ghci switched to libedit? I'm running Emacs-23 with haske-mode- > cvs on Debian unstable. > Do you have the libedit-dev package installed? If not, the editline backend may not have been built. You can check whether it was built by running ghci from a command prompt and checking whether the arrow keys work. -Judah From rl at cse.unsw.edu.au Tue Sep 23 00:59:50 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Sep 23 00:57:09 2008 Subject: Some initial results with DPH In-Reply-To: <1222132386-sup-8143@existential.local> References: <1222132386-sup-8143@existential.local> Message-ID: <87A93CB3-D0D2-49E3-9CD3-363D1EC51AB7@cse.unsw.edu.au> Hi Austin, first of all, thanks a lot for taking the time to report your results! On 23/09/2008, at 11:48, Austin Seipp wrote: > * The vectorise pass boosts compilation times *a lot*. I don't think > this is exactly unwarrented since it seems like a pretty complicated > transformation, but while making the primitive version using just > the unlifted interface the compilation takes about 1.5 seconds, for > the vectorised version it's on the order of 15 seconds. For > something as trivial as this dot-product thing, that's a bit > of a compilation time, though. The problem here is not the vectoriser but rather the subsequent optimisations. The vectoriser itself is (or should be - I haven't really timed it, to be honest) quite fast. It generates very complex code, however, which GHC takes a lot of time to optimise. We'll improve the output of the vectoriser eventually, but not before it is complete. For the moment, there is no solution for this, I'm afraid. > * It's pretty much impossible to use ghc-core to examine the output > core of the vectorised version - I let it run and before anything > started showing up in `less` it was already using on the order of > 100mb of memory. If I just add -ddump-simpl to the command line, the > reason is obvious: the core generated is absolutely huge. Yes. Again, this is something we'll try to improve eventually. > * For the benchmark included, the vectorised ver. spends about 98% of > its time from what I can see in the GC before it dies from stack > overflow. I haven't tried something like +RTS -A1G -RTS yet, though. IIUC, the code is > dotp :: [:Int:] -> [:Int:] -> Int > dotp v w = I.sumP [: (I.*) x y | x <- v, y <- w :] The way the vectoriser works at the moment, it will repeat the array w (lengthP v) times, i.e., create an array of length (lengthP v * lengthP w). This is quite unfortunate and needs to be fused away but isn't at the moment. The only advice I can give is to stay away from array comprehensions for now. They work but are extremely slow. This definition should work fine: dotp v w = I.sumP (zipWithP (I.*) v w) > * The vectoriser is really, really touchy. For example, the below code > sample works (from DotPVect.hs): > >> import Data.Array.Parallel.Prelude.Int as I >> >> dotp :: [:Int:] -> [:Int:] -> Int >> dotp v w = I.sumP [: (I.*) x y | x <- v, y <- w :] > > This however, does not work: > >> dotp :: [:Int:] -> [:Int:] -> Int >> dotp v w = I.sumP [: (Prelude.*) x y | x <- v, y <- w :] This is because the vectorised code needs to call the vectorised version of (*). Internally, the vectoriser has a hardwired mapping from top-level functions to their vectorised versions. That is, it knows that it should replace calls to (Data.Array.Parallel.Prelude.Int.*) by calls to Data.Array.Parallel.Prelude.Base.Int.plusV. There is no vectorised version of (Prelude.*), however, and there won't be one until we can vectorise the Prelude. In fact, the vectoriser doesn't even support classes at the moment. So the rule of thumb is: unless it's in Data.Array.Parallel.Prelude or you wrote and vectorised it yourself, it will choke the vectoriser. > I also ran into a few other errs relating to the vectoriser dying - if > I can find some I'll reply to this with some results. Please do! And please keep using DPH and reporting your results, that is really useful to us! FWIW, we'll include some DPH documentation in 6.10 but it still has to be written... Roman From weihu at cs.virginia.edu Tue Sep 23 01:02:23 2008 From: weihu at cs.virginia.edu (Wei Hu) Date: Tue Sep 23 00:59:45 2008 Subject: ANNOUNCE: GHC 6.10.1 beta References: <20080922003543.GA29215@matrix.chaos.earth.li> <6d74b0d20809222127p3d894d41q869431caf5fe5527@mail.gmail.com> Message-ID: Judah Jacobson gmail.com> writes: > Do you have the libedit-dev package installed? If not, the editline > backend may not have been built. You can check whether it was built > by running ghci from a command prompt and checking whether the arrow > keys work. > > -Judah > I forgot to mention that I was running the binary package -- didn't bother to build ghc from source. Because the binary package relies on libedit.so.0 and Debian only comes with libedit2, I created a symbolic link for libedit.so.0 pointing to libedit.so.2. Could that be a problem for Emacs? But the libedit backend works fine when running ghci from a command line. Thanks, Wei From humasect at gmail.com Tue Sep 23 02:43:53 2008 From: humasect at gmail.com (humasect) Date: Tue Sep 23 02:41:01 2008 Subject: ANNOUNCE: GHC 6.10.1 beta Message-ID: <8b02d2150809222343p133c29c9p3b0dfb7d1019505d@mail.gmail.com> installPackage: internal error: stg_ap_ppp_ret (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [build.stage.1] Abort trap make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 Intel Mac. I will also report bug. peace and happiness, -humasect -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080923/0cf961b2/attachment.htm From rl at cse.unsw.edu.au Tue Sep 23 04:49:52 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Sep 23 04:47:13 2008 Subject: Some initial results with DPH In-Reply-To: <87A93CB3-D0D2-49E3-9CD3-363D1EC51AB7@cse.unsw.edu.au> References: <1222132386-sup-8143@existential.local> <87A93CB3-D0D2-49E3-9CD3-363D1EC51AB7@cse.unsw.edu.au> Message-ID: On 23/09/2008, at 14:59, Roman Leshchinskiy wrote: >> dotp :: [:Int:] -> [:Int:] -> Int >> dotp v w = I.sumP [: (I.*) x y | x <- v, y <- w :] > > The way the vectoriser works at the moment, it will repeat the array > w (lengthP v) times, i.e., create an array of length (lengthP v * > lengthP w). This is quite unfortunate and needs to be fused away but > isn't at the moment. The only advice I can give is to stay away from > array comprehensions for now. They work but are extremely slow. This > definition should work fine: > > dotp v w = I.sumP (zipWithP (I.*) v w) Actually, I didn't pay attention when I wrote this. The two are not equivalent, of course. Only the second one computes the dot product. With comprehensions, you'd have to write dotp v w = [: (I.*) x y | x <- v | y <- w :] I suspect that will perform reasonably even now. Roman From g9ks157k at acme.softbase.org Tue Sep 23 05:11:25 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Sep 23 05:08:34 2008 Subject: Debian stable not supported? In-Reply-To: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> References: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> Message-ID: <200809231111.26104.g9ks157k@acme.softbase.org> Am Montag, 22. September 2008 08:52 schrieb Yitzchak Gale: > [?] > Unfortunately, the so-called "generic" Linux binary distribution > package for GHC 6.8.3 does not work on the current, up-to-date > Debian stable distribution because it is "too old". GHC 6.8.2 worked for me (on i386). > [?] Best wishes, Wolfgang From Christian.Maeder at dfki.de Tue Sep 23 09:38:56 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Sep 23 09:36:01 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D7D950.506@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> Message-ID: <48D8F170.8080003@dfki.de> The error far below is caused by "-perm /a+x" in mk/bindist.mk during find: I've changed it to "-perm -111" Then "make install" could not replace links: ln -s runghc /local/home/maeder/bin/runhaskell ln: cannot create /local/home/maeder/bin/runhaskell: File exists gmake[2]: *** [install] Error 2 But finally installation succeeded (editline is missing and the arrow keys don't work). Why are there 2 base packages? Cheers Christian -bash-3.1$ ghc-pkg list /local/home/maeder/share/ghc-6.10.0.20080921/./package.conf: Cabal-1.5.5, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.0.1.2, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, (ghc-6.10.0.20080921), ghc-prim-0.1.0.0, haddock-2.2.2, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.1, integer-0.1.0.0, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, syb-0.1.0.0, template-haskell-2.3.0.0, time-1.1.2.1, unix-2.3.1.0, xhtml-3000.2.0.1 Christian Maeder wrote: >>> 5. When trying to install the binary distribution I got: >>> >>> Installing executable(s) in /local/home/maeder/bin >>> installPackage: dist-install/build/installPackage/installPackage: >>> copyFile: does not exist (No such file or directory) >> Maybe fallout from some of the above problems? > > No, on an Intel Mac I got the same error (without the previous problems): > > Installing executable(s) in /Users/Shared/maeder/bin > installPackage: dist-install/build/installPackage/installPackage: > copyFile: does not exist (No such file or directory) > make[2]: *** [install] Error 1 > make[1]: *** [install.installPackage] Error 2 > make: *** [install] Error 2 > > Thanks anyway > Christian From g9ks157k at acme.softbase.org Tue Sep 23 12:07:15 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Sep 23 12:04:27 2008 Subject: GADTs and functional dependencies Message-ID: <200809231807.16093.g9ks157k@acme.softbase.org> Hello, please consider the following code: > {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > > data GADT a where > > GADT :: GADT () > > class Class a b | a -> b > > instance Class () () > > fun :: (Class a b) => GADT a -> b > fun GADT = () I?d expect this to work but unfortunately, using GHC 6.8.2, it fails with the following message: > FDGADT.hs:12:11: > Couldn't match expected type `b' against inferred type `()' > `b' is a rigid type variable bound by > the type signature for `fun' at FDGADT.hs:11:16 > In the expression: () > In the definition of `fun': fun GADT = () What?s the reason for this? Is there a workaround? Does this work in 6.8.3 or 6.10.1? Thank you in advance. Best wishes, Wolfgang From alfonso.acosta at gmail.com Tue Sep 23 12:19:39 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Sep 23 12:16:44 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231807.16093.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> On Tue, Sep 23, 2008 at 6:07 PM, Wolfgang Jeltsch wrote: > Hello, > > please consider the following code: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} >> >> data GADT a where >> >> GADT :: GADT () >> >> class Class a b | a -> b >> >> instance Class () () >> >> fun :: (Class a b) => GADT a -> b >> fun GADT = () > > I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with the > following message: bear in mind that the only instance you defined is instance Class () () which doesn't involve your GADT at all. Maybe you meant something like: instance Class (GADT a) () Moreover, your fun cannot typecheck, regardless of using MPTC or GADTs. The unit constructor, (), has type () and not b. From g9ks157k at acme.softbase.org Tue Sep 23 12:36:08 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Sep 23 12:33:15 2008 Subject: GADTs and functional dependencies In-Reply-To: <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> Message-ID: <200809231836.08834.g9ks157k@acme.softbase.org> Am Dienstag, 23. September 2008 18:19 schrieben Sie: > On Tue, Sep 23, 2008 at 6:07 PM, Wolfgang Jeltsch > > wrote: > > Hello, > > > > please consider the following code: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > >> > >> data GADT a where > >> > >> GADT :: GADT () > >> > >> class Class a b | a -> b > >> > >> instance Class () () > >> > >> fun :: (Class a b) => GADT a -> b > >> fun GADT = () > > > > I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with > > the following message: > > bear in mind that the only instance you defined is > > instance Class () () > > which doesn't involve your GADT at all. This is correct. (It?s only a trimmed-down example, after all.) > Maybe you meant something like: > > instance Class (GADT a) () No, I didn?t. > Moreover, your fun cannot typecheck, regardless of using MPTC or > GADTs. The unit constructor, (), has type () and not b. Pattern matching against the data constructor GADT specializes a to (). Since Class uses a functional dependency, it is clear that b has to be (). So it should typecheck. At least, I want it to. ;-) Best wishes, Wolfgang From alfonso.acosta at gmail.com Tue Sep 23 12:44:11 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Sep 23 12:41:17 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231836.08834.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> <200809231836.08834.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0809230944k69f28652k443f88610623c736@mail.gmail.com> On Tue, Sep 23, 2008 at 6:36 PM, Wolfgang Jeltsch wrote: > Pattern matching against the data constructor GADT specializes a to (). Since > Class uses a functional dependency, it is clear that b has to be (). True, but it wont work if you provide () as the result and b in the explicit signature. GHC is ranting with reason, the provided type, b, does not match (). On the other hand, this works: fun :: (Class a b) => GADT a -> b fun GADT = undefined And as you stated, b can only be () From dagit at codersbase.com Tue Sep 23 13:06:33 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Sep 23 13:03:39 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231836.08834.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> <200809231836.08834.g9ks157k@acme.softbase.org> Message-ID: On Tue, Sep 23, 2008 at 9:36 AM, Wolfgang Jeltsch wrote: > Am Dienstag, 23. September 2008 18:19 schrieben Sie: >> On Tue, Sep 23, 2008 at 6:07 PM, Wolfgang Jeltsch >> >> wrote: >> > Hello, >> > >> > please consider the following code: >> >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} >> >> >> >> data GADT a where >> >> >> >> GADT :: GADT () >> >> >> >> class Class a b | a -> b >> >> >> >> instance Class () () >> >> >> >> fun :: (Class a b) => GADT a -> b >> >> fun GADT = () >> > >> > I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with >> > the following message: >> >> bear in mind that the only instance you defined is >> >> instance Class () () >> >> which doesn't involve your GADT at all. > > This is correct. (It's only a trimmed-down example, after all.) > >> Maybe you meant something like: >> >> instance Class (GADT a) () > > No, I didn't. > >> Moreover, your fun cannot typecheck, regardless of using MPTC or >> GADTs. The unit constructor, (), has type () and not b. > > Pattern matching against the data constructor GADT specializes a to (). Since > Class uses a functional dependency, it is clear that b has to be (). So it > should typecheck. At least, I want it to. ;-) In the signature: fun :: (Class a b) => GADT a -> b What is there to determine the type a? It's a phantom in the definition of GADT, so it can unify arbitrarily for us, but there is nothing in your program to cause it to unify a certain way. Based on what you're hoping for, I think you would need: class Class a b | b -> a But, then think about how the type checker looks at fun, which returns (). Now we see that b should be (), but () is not the same as b. That is, () does not generalize to b, even though an arbitrary b could specialize to (). Did some other version of ghc accept this code? Jason From dagit at codersbase.com Tue Sep 23 13:13:46 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Sep 23 13:10:52 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231836.08834.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> <200809231836.08834.g9ks157k@acme.softbase.org> Message-ID: On Tue, Sep 23, 2008 at 9:36 AM, Wolfgang Jeltsch wrote: > Am Dienstag, 23. September 2008 18:19 schrieben Sie: >> On Tue, Sep 23, 2008 at 6:07 PM, Wolfgang Jeltsch >> >> wrote: >> > Hello, >> > >> > please consider the following code: >> >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} >> >> >> >> data GADT a where >> >> >> >> GADT :: GADT () >> >> >> >> class Class a b | a -> b >> >> >> >> instance Class () () >> >> >> >> fun :: (Class a b) => GADT a -> b >> >> fun GADT = () >> > >> > I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with >> > the following message: >> >> bear in mind that the only instance you defined is >> >> instance Class () () >> >> which doesn't involve your GADT at all. > > This is correct. (It's only a trimmed-down example, after all.) > >> Maybe you meant something like: >> >> instance Class (GADT a) () > > No, I didn't. > >> Moreover, your fun cannot typecheck, regardless of using MPTC or >> GADTs. The unit constructor, (), has type () and not b. > > Pattern matching against the data constructor GADT specializes a to (). Since > Class uses a functional dependency, it is clear that b has to be (). So it > should typecheck. At least, I want it to. ;-) I'm re-reading what you said after my first reply. I'm inserting types in places that may not be valid in Haskell... You're saying that the types should be like this: fun :: (Class a b) => GADT a -> b fun (GADT :: GADT ()) = () So, now I'm more inclined to agree with you than before. And suppose we added this: data GADT a where GADT :: GADT () GADT2 :: GADT String Now I would expect this: fun :: (Class a b) => GADT a -> b fun (GADT :: GADT ()) = () fun (GADT2 :: GADT String) = -- I can't put anything here till I add more instances of Class Now, I'm too confused about how this should work. Jason From dagit at codersbase.com Tue Sep 23 13:19:24 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Sep 23 13:16:32 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231807.16093.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> Message-ID: On Tue, Sep 23, 2008 at 9:07 AM, Wolfgang Jeltsch wrote: > Hello, > > please consider the following code: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} >> >> data GADT a where >> >> GADT :: GADT () >> >> class Class a b | a -> b >> >> instance Class () () >> >> fun :: (Class a b) => GADT a -> b >> fun GADT = () > > I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with the > following message: > >> FDGADT.hs:12:11: >> Couldn't match expected type `b' against inferred type `()' >> `b' is a rigid type variable bound by >> the type signature for `fun' at FDGADT.hs:11:16 >> In the expression: () >> In the definition of `fun': fun GADT = () > > What's the reason for this? Is there a workaround? Does this work in 6.8.3 > or 6.10.1? There is one workaround that I can think of. Use a data type to get the level of polymorphism you need. You could create a data type to hold b and return that instead of the naked b. data Any where Any :: a -> Any Now you could say, fun :: GADT a -> Any If you go with this existential solution you'll probably want to add type class constraints to the 'a' in Any so that you can recover enough about the type to use the value later. Jason From judah.jacobson at gmail.com Tue Sep 23 13:25:52 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Sep 23 13:22:58 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D8F170.8080003@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> Message-ID: <6d74b0d20809231025o43278423u7ffb1e485dc308ae@mail.gmail.com> Christian, I'm not sure about the other issues you mentioned but can probably help with the following. On Tue, Sep 23, 2008 at 6:38 AM, Christian Maeder wrote: > > But finally installation succeeded (editline is missing and the arrow > keys don't work). This means that the editline package could not be built for some reason. Is this on your OS X machine? If so, it's strange because libedit should be installed on OS X by default; what OS version are you running? If you separately download and build the editline package from hackage, what errors do you get? > Why are there 2 base packages? base-3.0.3 is a compatibility package which provides the same API as in ghc-6.8.*. The base-4 package has the new API (for example, extensible exceptions). -Judah From haskell at list.mightyreason.com Tue Sep 23 13:44:20 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Sep 23 13:41:28 2008 Subject: GADTs and functional dependencies In-Reply-To: References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> <200809231836.08834.g9ks157k@acme.softbase.org> Message-ID: <48D92AF4.4070008@list.mightyreason.com> You cannot create a normal function "fun". You can make a type class function fun :: Class a b => GADT a -> b > data GADT a where > GADT :: GADT () > GADT2 :: GADT String > > -- fun1 :: GADT () -> () -- infers type > fun1 g = case g of > (GADT :: GADT ()) -> () > > -- fun2 :: GADT String -> Bool -- infers type > fun2 g = case g of > (GADT2 :: GADT String) -> True > > -- "fun" cannot type check. The type of 'g' cannot be both "GADT ()" and "GADT String" > -- This is because "fun" is not a member of type class. > {- > fun g = case g of > (GADT :: GADT ()) -> () > (GADT2 :: GADT String) -> True > -} > > class Class a b | a -> b where > fun :: GADT a -> b > > instance Class () () where > fun GADT = () > > instance Class String Bool where > fun GADT2 = True > > main = print $ (fun GADT, fun GADT2) == ( (), True ) > From marlowsd at gmail.com Tue Sep 23 14:10:52 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 23 14:08:24 2008 Subject: Instances and DoCon In-Reply-To: <20080920075222.GA2659@scico.botik.ru> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A658A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916081309.GA27863@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A67C3@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916094150.GA28646@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32D764A6850@EA-EXMSG-C334.europe.corp.microsoft.com> <20080919191712.GA27781@matrix.chaos.earth.li> <20080920075222.GA2659@scico.botik.ru> Message-ID: <48D9312C.9010408@gmail.com> Serge D. Mechveliani wrote: > On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: >> On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: >>> | >>> | And still ghc-6.8.3 builds itself from source. >>> >>> I have no idea how -- Happy has been needed for some time. Maybe someone else does. >> It's not meant to be needed for building from a source tarball. >> This should be fixed now. > > Dear GHC team, > can you, please, provide such GHC source distributives which require > possibly smaller set of programs for the user to separately pre-install? > For example, do not require of the user to install Alex, Happy and Cabal. GHC source distributions do not require Alex, Happy or Cabal in order to build. If you find one of these is a dependency, then it is a bug - please report it. Note that when building from the development sources (darcs repository), you *do* need more dependencies, but a source distribution is different. Also, as Jason said - this is normally not an issue as few people need to build GHC from source in order to just use it. Cheers, Simon From kili at outback.escape.de Tue Sep 23 14:34:36 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Sep 23 14:32:12 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D8F170.8080003@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> Message-ID: <20080923183436.GA2877@petunia.outback.escape.de> Hi, On Tue, Sep 23, 2008 at 03:38:56PM +0200, Christian Maeder wrote: > The error far below is caused by "-perm /a+x" in mk/bindist.mk > during find: > > I've changed it to "-perm -111" Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be "-perm +111". However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern. This isn't a problem, because bindist isn't very useful at all on OpenBSD, but it may be a problem on other systems (I don't know what implementation of find(1) are used on FreeBSD, NetBSD and MacOS X). A workaround *may* be to use "-perm -100" (setting the execute bit for group and others but not for the user would be really weird). > Then "make install" could not replace links: > > ln -s runghc /local/home/maeder/bin/runhaskell > ln: cannot create /local/home/maeder/bin/runhaskell: File exists > gmake[2]: *** [install] Error 2 ln -fs should do the job. Ciao, Kili From dave at zednenem.com Tue Sep 23 14:35:38 2008 From: dave at zednenem.com (David Menendez) Date: Tue Sep 23 14:32:44 2008 Subject: GADTs and functional dependencies In-Reply-To: <48D92AF4.4070008@list.mightyreason.com> References: <200809231807.16093.g9ks157k@acme.softbase.org> <6a7c66fc0809230919o257f714axecb7df7c19a303e9@mail.gmail.com> <200809231836.08834.g9ks157k@acme.softbase.org> <48D92AF4.4070008@list.mightyreason.com> Message-ID: <49a77b7a0809231135q682ee75eg93e26092ec54db59@mail.gmail.com> On Tue, Sep 23, 2008 at 1:44 PM, Chris Kuklewicz wrote: > You cannot create a normal function "fun". You can make a type class > function > > fun :: Class a b => GADT a -> b > >> data GADT a where >> GADT :: GADT () >> GADT2 :: GADT String >> >> -- fun1 :: GADT () -> () -- infers type >> fun1 g = case g of >> (GADT :: GADT ()) -> () >> >> -- fun2 :: GADT String -> Bool -- infers type >> fun2 g = case g of >> (GADT2 :: GADT String) -> True >> >> -- "fun" cannot type check. The type of 'g' cannot be both "GADT ()" and >> "GADT String" >> -- This is because "fun" is not a member of type class. >> {- fun g = case g of >> (GADT :: GADT ()) -> () >> (GADT2 :: GADT String) -> True >> -} It may be that fun cannot type check, but surely it isn't for the reason you've given. data Rep a where Unit :: Rep () Int :: Rep Int zero :: Rep a -> a zero r = case r of Unit -> () Int -> 0 The type of r is "both" Rep () and Rep Int. No type class needed. If I had to guess, I'd say the original problem is that any specialization triggered by the functional dependency happens before the specialization triggered by pattern matching on the GADT. If I recall correctly, it is known that GADTs and fundeps don't always work nicely together. The example does seem to work if translated to use type families. type family Fam t :: * type instance Fam () = () data GADT a where GADT :: GADT () fun :: GADT a -> Fam a fun GADT = () -- Dave Menendez From kili at outback.escape.de Tue Sep 23 14:50:48 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Sep 23 14:52:12 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080923183436.GA2877@petunia.outback.escape.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> <20080923183436.GA2877@petunia.outback.escape.de> Message-ID: <20080923185048.GA20405@petunia.outback.escape.de> On Tue, Sep 23, 2008 at 08:34:36PM +0200, Matthias Kilian wrote: > > I've changed it to "-perm -111" > > Unfortunately, this will only find files with the executable bit > set for user, group and owner, so it should be "-perm +111". However, > even more unfortunately, at least the find(1) on OpenBSD doesn't > support the +mode pattern.[...] According to http://www.opengroup.org/onlinepubs/000095399/utilities/find.html `-perm +onum' (where onum is an octal number) seems to be yet another gnuism, so `-perm -100' is probably the most portable (and least breaking) option for any system not using gfind. Ciao, Kili From marlowsd at gmail.com Tue Sep 23 15:22:18 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 23 15:19:59 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D777F0.7060907@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> <48D777F0.7060907@list.mightyreason.com> Message-ID: <48D941EA.40207@gmail.com> Chris Kuklewicz wrote: > I am cross-posting this message to several lists. > > I had learned the trick before the documentation was updated. It seems > I have used a very unreliable trick. And the "use castToSTUArray" > suggested alternative is a really poor one since I am not using arrays > at all. castSTUArray is the way GHC does it - the idea is to allocate a small array, store the Float/Double in it, cast the type of the array to Word32 or whatever, and then read out the contents. It's more or less equivalent to the peek/poke solution, except that it doesn't need unsafePerformIO. GHC's code is here: (look for floatToWord): http://darcs.haskell.org/ghc/compiler/cmm/PprC.hs Cheers, Simon From prj at po.cwru.edu Tue Sep 23 21:09:03 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Tue Sep 23 21:06:19 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080922003543.GA29215@matrix.chaos.earth.li> (Ian Lynagh's message of "Mon\, 22 Sep 2008 01\:35\:43 +0100") References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: 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. 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 the binary couldn't find libgmp.so. 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 via cabal-bin, but I don't know how. paul From allbery at ece.cmu.edu Wed Sep 24 00:12:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Sep 24 00:10:02 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D8F170.8080003@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> Message-ID: On 2008 Sep 23, at 9:38, Christian Maeder wrote: > But finally installation succeeded (editline is missing and the arrow > keys don't work). Why are there 2 base packages? Backward compatibility; older Haskell programs using base-3.x will still work. (6.10 has unbundled a bunch more libraries from the base.) -- 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 jules at jellybean.co.uk Wed Sep 24 05:27:00 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Sep 24 05:24:04 2008 Subject: GHC 6.8.3's source is unusable? In-Reply-To: <48D73A7D.2090904@gmail.com> References: <48D70094.50909@gmail.com> <1222056378-sup-1032@existential.local> <48D73A7D.2090904@gmail.com> Message-ID: <48DA07E4.10808@jellybean.co.uk> Magicloud wrote: > I see.... So 6.8.3 is not portable.... > So in my company-customed-linux box, ghc is nothing to me? > Any way I can use it? Yes install 6.4.2, as the last poster suggested, and then use 6.4.2 to build 6.8.3. Alternatively, and probably more simply, get a binary dist. From Christian.Maeder at dfki.de Wed Sep 24 05:54:28 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 05:51:29 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <6d74b0d20809231025o43278423u7ffb1e485dc308ae@mail.gmail.com> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> <6d74b0d20809231025o43278423u7ffb1e485dc308ae@mail.gmail.com> Message-ID: <48DA0E54.9000401@dfki.de> Judah Jacobson wrote: > On Tue, Sep 23, 2008 at 6:38 AM, Christian Maeder > wrote: >> But finally installation succeeded (editline is missing and the arrow >> keys don't work). > > This means that the editline package could not be built for some > reason. Is this on your OS X machine? If so, it's strange because > libedit should be installed on OS X by default; what OS version are > you running? If you separately download and build the editline > package from hackage, what errors do you get? It works fine under OS X. My problem is under x86 solaris. See below my output when trying to install http://hackage.haskell.org/packages/archive/editline/0.2/editline-0.2.tar.gz Cheers Christian -bash-3.1$ cp /local/home/maeder/lib/ghc-6.10.0.20080921/unlit /local/home/maeder/share/ghc-6.10.0.20080921/ -bash-3.1$ ghc --make Setup.lhs [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Setup.lhs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Linking Setup ... -bash-3.1$ ./Setup configure --prefix=/local/home/maeder Warning: defaultUserHooks in Setup script is deprecated. Configuring editline-0.2... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init... no checking for readline... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for sign of read_history result on error... negative configure: error: editline not found, so this package cannot be built See `config.log' for more details. From Christian.Maeder at dfki.de Wed Sep 24 06:09:36 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 06:06:38 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48DA0E54.9000401@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> <6d74b0d20809231025o43278423u7ffb1e485dc308ae@mail.gmail.com> <48DA0E54.9000401@dfki.de> Message-ID: <48DA11E0.3010407@dfki.de> Hi Judah, libedit is simply missing. but ghci used to work with readline! Do I need to install i.e. http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz as a static library in order to create code depending on libedit that can be run on machines without libedit? (This reminds me to the gmp and readline whims on Macs.) Cheers Christian Christian Maeder wrote: > checking editline/readline.h usability... no > checking editline/readline.h presence... no > checking for editline/readline.h... no > checking editline/editline.h usability... no > checking editline/editline.h presence... no > checking for editline/editline.h... no > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes > checking for sign of read_history result on error... negative > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. From g9ks157k at acme.softbase.org Wed Sep 24 06:55:29 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Sep 24 06:52:34 2008 Subject: GADTs and functional dependencies In-Reply-To: References: <200809231807.16093.g9ks157k@acme.softbase.org> Message-ID: <200809241255.29640.g9ks157k@acme.softbase.org> Am Dienstag, 23. September 2008 19:07 schrieben Sie: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > >> > >> data GADT a where > >> > >> GADT :: GADT () > >> > >> class Class a b | a -> b > >> > >> instance Class () () > >> > >> fun :: (Class a b) => GADT a -> b > >> fun GADT = () > > > > I?d expect this to work but unfortunately, using GHC 6.8.2, it fails with > > the > > > > following message: > >> FDGADT.hs:12:11: > >> Couldn't match expected type `b' against inferred type `()' > >> `b' is a rigid type variable bound by > >> the type signature for `fun' at FDGADT.hs:11:16 > >> In the expression: () > >> In the definition of `fun': fun GADT = () > > > > What?s the reason for this? Is there a workaround? Does this work in > > 6.8.3 or 6.10.1? > > This similar code using type families compiles in 6.8.3 and 6.9: > > data GADT a where > GADT :: GADT () > > type family F a > type instance F () = () > > fun :: GADT a -> F a > fun GADT = () Exactly. But this makes my code incompatible with GHC 6.6. :-( I thought, someone said that with the new typing machinery in GHC 6.10, more functional dependency programs are accepted because functional dependencies are handled similarly to type families (or something like that). Is this true? Since the type family version is okay, why shouldn?t the functional dependency version be okay? Best wishes, Wolfgang From mechvel at botik.ru Wed Sep 24 07:40:59 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 24 07:38:26 2008 Subject: 6.10-candidate tested Message-ID: <20080924114059.GA12514@scico.botik.ru> Dear GHC developers, I have tested ghc-6.10.0.20080921 on * making it by ghc-6.8.2, * making it by itself, * the DoCon and Dumatel applications. It looks all right. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Wed Sep 24 08:14:38 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 24 08:34:13 2008 Subject: 6.10-candidate tested In-Reply-To: <20080924114059.GA12514@scico.botik.ru> References: <20080924114059.GA12514@scico.botik.ru> Message-ID: <20080924121438.GA12774@scico.botik.ru> This was on Linux, Debian. > I have tested ghc-6.10.0.20080921 > on > * making it by ghc-6.8.2, > * making it by itself, > * the DoCon and Dumatel applications. From igloo at earth.li Wed Sep 24 08:53:34 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 08:50:49 2008 Subject: Debian stable not supported? In-Reply-To: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> References: <2608b8a80809212352m413d592cvd7fc4615288837d3@mail.gmail.com> Message-ID: <20080924125334.GA6900@matrix.chaos.earth.li> On Mon, Sep 22, 2008 at 09:52:57AM +0300, Yitzchak Gale wrote: > > Before I delete that chroot build environment - could it > be useful for making GHC 6.8.3 available to others? If someone > points me in the right direction, perhaps I could create a binary > tarball and/or backport deb. You can make a binary distribution by running "make binary-dist" in the built tree. To make a backport deb you'd need to start with the Debian source package, not just the GHC tarball. Thanks Ian From igloo at earth.li Wed Sep 24 09:11:47 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 09:08:54 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809241255.29640.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> <200809241255.29640.g9ks157k@acme.softbase.org> Message-ID: <20080924131147.GA20243@matrix.chaos.earth.li> On Wed, Sep 24, 2008 at 12:55:29PM +0200, Wolfgang Jeltsch wrote: > > I thought, someone said that with the new typing machinery in GHC 6.10, more > functional dependency programs are accepted because functional dependencies > are handled similarly to type families (or something like that). Is this > true? Since the type family version is okay, why shouldn?t the functional > dependency version be okay? In http://hackage.haskell.org/trac/ghc/ticket/345 Simon says: Ultimately, I think we can implement fundeps using type families, and then the fundep version will work too. Until then, it'll only work in type-family form. Thanks Ian From g9ks157k at acme.softbase.org Wed Sep 24 11:09:15 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Sep 24 11:06:21 2008 Subject: GADTs and functional dependencies In-Reply-To: <20080924131147.GA20243@matrix.chaos.earth.li> References: <200809231807.16093.g9ks157k@acme.softbase.org> <200809241255.29640.g9ks157k@acme.softbase.org> <20080924131147.GA20243@matrix.chaos.earth.li> Message-ID: <200809241709.15179.g9ks157k@acme.softbase.org> Am Mittwoch, 24. September 2008 15:11 schrieb Ian Lynagh: > On Wed, Sep 24, 2008 at 12:55:29PM +0200, Wolfgang Jeltsch wrote: > > I thought, someone said that with the new typing machinery in GHC 6.10, > > more functional dependency programs are accepted because functional > > dependencies are handled similarly to type families (or something like > > that). Is this true? Since the type family version is okay, why > > shouldn?t the functional dependency version be okay? > > In > http://hackage.haskell.org/trac/ghc/ticket/345 > Simon says: > Ultimately, I think we can implement fundeps using type families, > and then the fundep version will work too. Until then, it'll only > work in type-family form. > > > Thanks > Ian And further: > So, since we now have a good workaround (well, actually, a better way to > write the program rather than a workaround), I'll leave it open, but at low > priority and with milestone bottom. So for now the answer is: Use type families and thereby drop 6.6 compatibility? Best wishes, Wolfgang From Christian.Maeder at dfki.de Wed Sep 24 11:32:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 11:29:51 2008 Subject: 6.10-candidate tested In-Reply-To: <20080924121438.GA12774@scico.botik.ru> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> Message-ID: <48DA5DA3.2070905@dfki.de> Do you have libedit on your linux machine (because I haven't)? In order to check this: Does "ghc-pkg list" the editline package? (And do your arrow keys and backspace work in ghci?) Thanks Christian Serge D. Mechveliani wrote: > This was on Linux, Debian. > >> I have tested ghc-6.10.0.20080921 >> on >> * making it by ghc-6.8.2, >> * making it by itself, >> * the DoCon and Dumatel applications. From simonpj at microsoft.com Wed Sep 24 11:49:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 24 11:45:59 2008 Subject: GADTs and functional dependencies In-Reply-To: <200809231807.16093.g9ks157k@acme.softbase.org> References: <200809231807.16093.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> Wolfgang writes | > data GADT a where | > | > GADT :: GADT () | > | > class Class a b | a -> b | > | > instance Class () () | > | > fun :: (Class a b) => GADT a -> b | > fun GADT = () You're right that this program should typecheck. In the case branch we discover (locally) that a~(), and hence by the fundep, b~(), and away you go. This has never worked with fundeps, because it involves a *local* type equality (one that holds in some places and not others) and my implementation of fundeps is fundamentally based on *global* equality. Prior to GADTs that was fine! By adding local type equalities, GADTs change the game, and associated types/type families change it even more. (One reason that the game is different is that GHC has a typed intermediate language, so we need to maintain evidence of type equality throughout. In contrast, global equalities can be handled by straightforward unification, that makes the two types *identical*.) Our new implementation of type functions does, for the first time, a thorough principled job of handling arbitrary local type equalities. But that still leaves fundeps. Rather than try to fix fudeps directly (which would be a big job -- as I say, the current impl is fundamentally global) the best thing to do is to translate them into type equalities, thus: class (F a ~ b) => C a b type family F a (Note for 6.10 users: type equalities in superclasses is the piece we still have not implemented.) When you write an instance decl you add a type instance decl: instance C () () type F () = () Now everything should be good. Almost all fundep programs can be translated in this way. (Maybe all, I'm not 100% certain.) If you are doing this yourself, you can usually remove C's second parameter; but only if the fundep is unidirectional. So, as of now (6.10), the fundep stuff is still handled exactly as before, using global unification, so your program isn't going to work in 6.10 either. I'm frankly dubious about whether it's worth the effort of automatically performing the above translation from fundeps to type equalities; if you want this level of sophistication, you could just use type functions directly. It's not really a lack of backward compat. I think 6.10 will do all that 6.8 does; but if you want *more* you'll have to switch notation. Does that help clear things up, and explain why things are the way they are? Simon From mechvel at botik.ru Wed Sep 24 12:32:38 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 24 12:31:45 2008 Subject: 6.10-candidate tested In-Reply-To: <48DA5DA3.2070905@dfki.de> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> Message-ID: <20080924163238.GA15136@scico.botik.ru> On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: > Do you have libedit on your linux machine (because I haven't)? > I do not know what is libedit and where to find it. > In order to check this: > Does "ghc-pkg list" the editline package? (And do your arrow keys and > backspace work in ghci?) > 1. ghc-pkg list does not show the editline package. 2. The arrow keys and backspace do not work in ghci. This is so -- on my machine, under Debian Linux. Dear GHC developers, can you comment, please? Is this due to some deficiency in Debian Linux installation or this is a bug in the GHC installation? Regards, ----------------- Serge Mechveliani mechvel@botik.ru > > This was on Linux, Debian. I have tested ghc-6.10.0.20080921 > >> on > >> * making it by ghc-6.8.2, > >> * making it by itself, > >> * the DoCon and Dumatel applications. From claus.reinke at talk21.com Wed Sep 24 12:48:28 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 12:45:36 2008 Subject: GADTs and functional dependencies References: <200809231807.16093.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <2FCBD29987DA4CBCA61D8EAFAFE7B27F@cr3lt> > This has never worked with fundeps, because it involves a *local* type equality (one that holds in > some places and not others) and my implementation of fundeps is fundamentally based on *global* > equality. Prior to GADTs that was fine! Thanks for the explanation, Simon - it clears up some outstanding FD issues. > Now everything should be good. Almost all fundep programs can be translated in this way. (Maybe > all, I'm not 100% certain.) If you are doing this yourself, you can usually remove C's second > parameter; but only if the fundep is unidirectional. You can be 100% certain that not all FD programs can be translated to TF, if only because of interaction with overlapping instances. This is an area where Ghc differs from Hugs, doing different things for the "same" LANGUAGE extension, and it is difficult territory: Hugs' interpretation is safe, but too restricted in practice, Ghc's is a lot more flexible in practice, at the expense of not knowing whether it is safe in general, leaving those concerns to type class library implementers. I had hoped that Haskell' or Ghc would single out the actual use cases, and work towards principled solutions for these, whether for FD or for TF (eg, guards and closed instances might help). > So, as of now (6.10), the fundep stuff is still handled exactly as before, using global > unification, so your program isn't going to work in 6.10 either. I'm frankly dubious about > whether it's worth the effort of automatically performing the above translation from fundeps to > type equalities; if you want this level of sophistication, you could just use type functions > directly. > > It's not really a lack of backward compat. I think 6.10 will do all that 6.8 does; but if you > want *more* you'll have to switch notation. Does that help clear things up, and explain why > things are the way they are? Many of the issues that are going to be fixed for TF have been raised as bugs in the old implementation of FD. If FD are not going to see the same fixes, programs need to switch to TF, which isn't backwards or otherwise compatible (and may well deliver the final blow to the idea of more than one Haskell implementation?). Claus From g9ks157k at acme.softbase.org Wed Sep 24 13:00:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Sep 24 12:58:03 2008 Subject: GADTs and functional dependencies In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200809231807.16093.g9ks157k@acme.softbase.org> <638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200809241900.59229.g9ks157k@acme.softbase.org> Hello Simon, thank you for your extensive answer! I think, I?ll try to work around the fundep deficiencies and if that doesn?t work, switch to type families. But your answer raised further questions/comments: > class (F a ~ b) => C a b > type family F a > > (Note for 6.10 users: type equalities in superclasses is the piece we still > have not implemented.) Do you mean type equalities like the one in the example above? Didn?t this already work in 6.8.2? > Almost all fundep programs can be translated in this way. (Maybe all, I'm > not 100% certain.) Not all, I?m afraid. There was a mailing list discussion between us several months ago where we talked about this. The translation from fundeps to type families doesn?t work as soon as overlapping instances are involved. The type equality check from HList is an example for this. You told me that such a check can be implemented with type families as soon as we have closed TFs: type family TypeEq t1 t2 :: * where TypeEq t t = True TypeEq t1 t2 = False Greetings to Victoria! (from Cottbus) Wolfgang From Christian.Maeder at dfki.de Wed Sep 24 13:18:28 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 13:15:27 2008 Subject: 6.10-candidate tested In-Reply-To: <20080924163238.GA15136@scico.botik.ru> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> <20080924163238.GA15136@scico.botik.ru> Message-ID: <48DA7664.1030602@dfki.de> Serge D. Mechveliani wrote: > On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: >> Do you have libedit on your linux machine (because I haven't)? >> > > I do not know what is libedit and where to find it. It's the library needed for editline http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline editline is the replacement of readline. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline > 1. ghc-pkg list does not show the editline package. > 2. The arrow keys and backspace do not work in ghci. > This is so -- on my machine, under Debian Linux. The advantage is ghci works without editline and readline. The disadvantage is if you want arrow keys and backspace to work, you should have installed http://www.thrysoee.dk/editline/ first. > Is this due to some deficiency in Debian Linux installation or this is > a bug in the GHC installation? A (debian) package manager could install editline (and gmp) before ghc. (Unfortunately user programs may depend on those extra libraries, too.) Christian From roma at ro-che.info Wed Sep 24 13:35:50 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed Sep 24 13:33:29 2008 Subject: 6.10-candidate tested In-Reply-To: <48DA7664.1030602@dfki.de> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> <20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de> Message-ID: <20080924173550.GB5831@flit> * Christian Maeder [2008-09-24 19:18:28+0200] > Serge D. Mechveliani wrote: > > On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: > >> Do you have libedit on your linux machine (because I haven't)? > >> > > > > I do not know what is libedit and where to find it. > > It's the library needed for editline > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline > > editline is the replacement of readline. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline > > > 1. ghc-pkg list does not show the editline package. > > 2. The arrow keys and backspace do not work in ghci. > > This is so -- on my machine, under Debian Linux. > > The advantage is ghci works without editline and readline. The > disadvantage is if you want arrow keys and backspace to work, you should > have installed http://www.thrysoee.dk/editline/ first. > > > Is this due to some deficiency in Debian Linux installation or this is > > a bug in the GHC installation? > > A (debian) package manager could install editline (and gmp) before ghc. > (Unfortunately user programs may depend on those extra libraries, too.) libedit on Debian is very out-dated[1]. Haskell bindings (editline) doesn't compile against it (at least I could not compile it). 1. http://packages.qa.debian.org/e/editline.html -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From claus.reinke at talk21.com Wed Sep 24 13:56:05 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 13:53:13 2008 Subject: editline vs haskeline (was: 6.10-candidate tested) References: <20080924114059.GA12514@scico.botik.ru><20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de><20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de> <20080924173550.GB5831@flit> Message-ID: >> The advantage is ghci works without editline and readline. The >> disadvantage is if you want arrow keys and backspace to work, you should >> have installed http://www.thrysoee.dk/editline/ first. > libedit on Debian is very out-dated[1]. Haskell bindings (editline) > doesn't compile against it (at least I could not compile it). There was also no working libedit for mingw last time I checked (shelarcy was working on a patch at the time - did that work out?). Would it be possible to use haskeline as a fallback/default, for future Ghc's? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline Claus From judah.jacobson at gmail.com Wed Sep 24 14:06:06 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Sep 24 14:03:09 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48DA11E0.3010407@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> <48D8F170.8080003@dfki.de> <6d74b0d20809231025o43278423u7ffb1e485dc308ae@mail.gmail.com> <48DA0E54.9000401@dfki.de> <48DA11E0.3010407@dfki.de> Message-ID: <6d74b0d20809241106m2a218e92gefd559249fac1250@mail.gmail.com> On Wed, Sep 24, 2008 at 3:09 AM, Christian Maeder wrote: > Hi Judah, > > libedit is simply missing. but ghci used to work with readline! Do I > need to install i.e. > http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz > as a static library in order to create code depending on libedit that > can be run on machines without libedit? (This reminds me to the gmp and > readline whims on Macs.) Sure, if you're talking about a program that does user interaction with the libedit library, then I suppose so. But I don't expect this to cause many problems in practice, since - Programs compiled with ghc don't need libedit to run unless they explicitly depend on the editline package, and - There's nothing stopping you from writing and distributing programs that depend on readline instead; just install the readline package from Hackage. -Judah From igloo at earth.li Wed Sep 24 14:07:46 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 14:04:49 2008 Subject: 6.10-candidate tested In-Reply-To: <20080924173550.GB5831@flit> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> <20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de> <20080924173550.GB5831@flit> Message-ID: <20080924180746.GA4120@matrix.chaos.earth.li> Hi Roman, On Wed, Sep 24, 2008 at 08:35:50PM +0300, Roman Cheplyaka wrote: > > libedit on Debian is very out-dated[1]. Haskell bindings (editline) > doesn't compile against it (at least I could not compile it). > > 1. http://packages.qa.debian.org/e/editline.html That's the wrong package; you need: http://packages.qa.debian.org/libe/libedit.html Thanks Ian From claus.reinke at talk21.com Wed Sep 24 14:26:31 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 14:23:42 2008 Subject: GADTs and functional dependencies References: <200809231807.16093.g9ks157k@acme.softbase.org><638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> <2FCBD29987DA4CBCA61D8EAFAFE7B27F@cr3lt> Message-ID: >> This has never worked with fundeps, because it involves a *local* type equality (one that holds >> in some places and not others) and my implementation of fundeps is fundamentally based on >> *global* equality. Prior to GADTs that was fine! Actually, how does that relate to reasoning under assumptions? class FD a b | a -> b f :: (FD t1 t2, FD t1 t3) => .. f = .. There is no instance of 'FD', so no equalities can be derived from there outside of 'f', and no equalities should be derived globally from instances that are only local hypotheses in 'f' . But inside 'f', we assume that those two 'FD' instances exist, so we should assume 't2 ~ t3' to the right of the implication. Isn't that decidedly local? Claus From allbery at ece.cmu.edu Wed Sep 24 14:39:16 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Sep 24 14:36:21 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D7D950.506@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080922171917.GA3143@petunia.outback.escape.de> <48D7D950.506@dfki.de> Message-ID: <2967DABD-3995-489B-8D43-A45CEFEF9892@ece.cmu.edu> On Sep 22, 2008, at 13:43 , Christian Maeder wrote: > Matthias Kilian wrote: >>> 2. >>> /bin/sh: test: argument expected >>> gmake[1]: *** [binary-dist] Error 1 >>> >>> -e does not work for test under "sh", so I changed it to "-r": >>> ... if [ -r $$FILE ]; then ... >> >> I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does >> this "argument expected" still appear with your fix to 1.? > > It does not work on my system (SunOS 5.10 Generic_137112-07 i86pc): Solaris's /bin/sh is not POSIX; /usr/xpg4/bin/sh is the POSIX compatible shell. -- 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 judah.jacobson at gmail.com Wed Sep 24 15:25:01 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Sep 24 15:22:03 2008 Subject: editline vs haskeline (was: 6.10-candidate tested) In-Reply-To: References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> <20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de> <20080924173550.GB5831@flit> Message-ID: <6d74b0d20809241225i7690b6e5p990f65b9e6ba46f6@mail.gmail.com> On Wed, Sep 24, 2008 at 10:56 AM, Claus Reinke wrote: >>> The advantage is ghci works without editline and readline. The >>> disadvantage is if you want arrow keys and backspace to work, you should >>> have installed http://www.thrysoee.dk/editline/ first. >> >> libedit on Debian is very out-dated[1]. Haskell bindings (editline) >> doesn't compile against it (at least I could not compile it). > > There was also no working libedit for mingw last time I checked (shelarcy > was working on a patch at the time - did that work out?). > > Would it be possible to use haskeline as a fallback/default, > for future Ghc's? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline As the author of haskeline, integrating it into ghc is on my TODO list. :-) Note that the earliest this could happen would be ghc-6.12.1, which won't be released for at least another year. But just to reiterate: 1) Other than on Windows, libedit is widely available and compatible (including Debian, which just needs the libedit-dev package). 2) The Windows console provides basic interaction even without libedit, including arrow key left/right, history, delete key, etc. (Tab completion of Haskell identifiers is the most glaring omission.) -Judah From igloo at earth.li Wed Sep 24 16:18:06 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 16:15:09 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <48D79E78.5040802@dfki.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> Message-ID: <20080924201806.GA22304@matrix.chaos.earth.li> On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > > Right now we have the source bundles: > > > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralibs.tar.bz2 > > I've tried to build a binary dist on x86 under Solaris and did not succeed. Thanks Christian et al; all the issues you've identified should now be fixed in darcs. Thanks Ian From igloo at earth.li Wed Sep 24 16:29:06 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 16:26:09 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: References: <20080922003543.GA29215@matrix.chaos.earth.li> <6d74b0d20809222127p3d894d41q869431caf5fe5527@mail.gmail.com> Message-ID: <20080924202906.GB22304@matrix.chaos.earth.li> On Tue, Sep 23, 2008 at 05:02:23AM +0000, Wei Hu wrote: > > I forgot to mention that I was running the binary package -- didn't bother to > build ghc from source. Because the binary package relies on libedit.so.0 and > Debian only comes with libedit2, I created a symbolic link for libedit.so.0 > pointing to libedit.so.2. Could that be a problem for Emacs? But the libedit > backend works fine when running ghci from a command line. It sounds like emacs isn't understanding the libedit output then. Can any emacs experts provide any clues? Thanks Ian From igloo at earth.li Wed Sep 24 16:36:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 16:33:22 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <8b02d2150809222343p133c29c9p3b0dfb7d1019505d@mail.gmail.com> References: <8b02d2150809222343p133c29c9p3b0dfb7d1019505d@mail.gmail.com> Message-ID: <20080924203618.GC22304@matrix.chaos.earth.li> On Tue, Sep 23, 2008 at 12:43:53AM -0600, humasect wrote: > installPackage: internal error: stg_ap_ppp_ret > (GHC version 6.8.3 for i386_apple_darwin) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > make[2]: *** [build.stage.1] Abort trap > make[1]: *** [build.stage.1] Error 2 > make: *** [stage1] Error 1 This is a bug in GHC 6.8.3, so isn't something we can fix (unless it also happens with 6.10). Unfortunately it means you can't build 6.10, but you will be able to install a binary distribution or OS X installer. Thanks Ian From igloo at earth.li Wed Sep 24 16:46:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 16:43:06 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: <20080924204603.GD22304@matrix.chaos.earth.li> Hi Paul, On Tue, Sep 23, 2008 at 09:09:03PM -0400, Paul Jarc wrote: > 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. I'm confused. If the bootstrapping GHC uses a gmp from a non-standard directory, then that directory should be listed in the "library-dirs" field of the rts package. You shouldn't need to tell GHC where it is whenever you run GHC. Thanks Ian From prj at po.cwru.edu Wed Sep 24 17:02:28 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Wed Sep 24 16:59:35 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080924204603.GD22304@matrix.chaos.earth.li> (Ian Lynagh's message of "Wed\, 24 Sep 2008 21\:46\:03 +0100") References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080924204603.GD22304@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > I'm confused. If the bootstrapping GHC uses a gmp from a non-standard > directory, then that directory should be listed in the "library-dirs" > field of the rts package. Running "strings" on the bootstrap compiler's lib/ghc-6.8.3/libHSrts* shows some references to the gmp include directory, but none to the library directory. I can try rebuilding 6.8.3, keeping the build directory for inspection afterwards to see what's happening there. paul From claus.reinke at talk21.com Wed Sep 24 17:34:16 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 17:31:23 2008 Subject: editline vs haskeline (was: 6.10-candidate tested) References: <20080924114059.GA12514@scico.botik.ru><20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de><20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de><20080924173550.GB5831@flit> <6d74b0d20809241225i7690b6e5p990f65b9e6ba46f6@mail.gmail.com> Message-ID: <1389616DA3CF468F83694C740AF0D457@cr3lt> >> Would it be possible to use haskeline as a fallback/default, >> for future Ghc's? >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline > > As the author of haskeline, integrating it into ghc is on my TODO > list. :-) Good to hear!-) > Note that the earliest this could happen would be > ghc-6.12.1, which won't be released for at least another year. Why that? It wouldn't change any APIs, and if you're afraid of changing client programs that use ghci (is that likely? is the key set different from editline? and for windows, you'd only be adding line editing functionality, not removing/changing any), you can always put it behind an option. Or is the API so different that you'd have to rewrite ghci? There shouldn't be more than a handful locations affected, iirc, but they are all tuned to readline/editline's imperative API. > But just to reiterate: > 1) Other than on Windows, libedit is widely available and compatible > (including Debian, which just needs the libedit-dev package). > 2) The Windows console provides basic interaction even without > libedit, including arrow key left/right, history, delete key, etc. > (Tab completion of Haskell identifiers is the most glaring omission.) I don't mind whether it is editline or haskeline, but as a windows user, I'd like to have ghci's tab completion (it isn't limited to identifiers, either, I think) - ever since adding support for various Haskell-related completions in my Vim editing, I miss it when using ghci.. rlwrap is ok, but no proper replacement. Claus From igloo at earth.li Wed Sep 24 18:10:15 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 18:07:18 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080924204603.GD22304@matrix.chaos.earth.li> Message-ID: <20080924221015.GA15101@matrix.chaos.earth.li> Hi Paul, On Wed, Sep 24, 2008 at 05:02:28PM -0400, Paul Jarc wrote: > Ian Lynagh wrote: > > I'm confused. If the bootstrapping GHC uses a gmp from a non-standard > > directory, then that directory should be listed in the "library-dirs" > > field of the rts package. > > Running "strings" on the bootstrap compiler's lib/ghc-6.8.3/libHSrts* > shows some references to the gmp include directory, but none to the > library directory. I can try rebuilding 6.8.3, keeping the build > directory for inspection afterwards to see what's happening there. Running ghc-pkg describe rts will show you library-dirs, amongst other things. If that's the problem then you should be able to edit /usr/lib/ghc-6.8.2/package.conf or similar, and add the directory to the libraryDirs of the rts package entry. Thanks Ian From prj at po.cwru.edu Wed Sep 24 18:22:53 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Wed Sep 24 18:20:18 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080924221015.GA15101@matrix.chaos.earth.li> (Ian Lynagh's message of "Wed\, 24 Sep 2008 23\:10\:15 +0100") References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080924204603.GD22304@matrix.chaos.earth.li> <20080924221015.GA15101@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > Running > ghc-pkg describe rts > will show you library-dirs, amongst other things. Ah, ok. Well, the gmp library directory is indeed listed there. But what exactly is ghc supposed to do with it? From the behavior I'm seeing, it looks like it passes -L to the linker, but not -Xlinker -R. pwd gets compiled and linked just fine; it only complains when it runs. The *dynamic* linker can't find libgmp.so, since it isn't in a systemwide library directory, and pwd wasn't linked with -Xlinker -R. paul From marlowsd at gmail.com Wed Sep 24 20:59:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 24 20:56:55 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080924203618.GC22304@matrix.chaos.earth.li> References: <8b02d2150809222343p133c29c9p3b0dfb7d1019505d@mail.gmail.com> <20080924203618.GC22304@matrix.chaos.earth.li> Message-ID: <48DAE274.4030206@gmail.com> Ian Lynagh wrote: > On Tue, Sep 23, 2008 at 12:43:53AM -0600, humasect wrote: >> installPackage: internal error: stg_ap_ppp_ret >> (GHC version 6.8.3 for i386_apple_darwin) >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> make[2]: *** [build.stage.1] Abort trap >> make[1]: *** [build.stage.1] Error 2 >> make: *** [stage1] Error 1 > > This is a bug in GHC 6.8.3, so isn't something we can fix (unless it > also happens with 6.10). Unfortunately it means you can't build 6.10, > but you will be able to install a binary distribution or OS X installer. Ian - do you happen to know which bug this is? Cheers, Simon From leledumbo_cool at yahoo.co.id Thu Sep 25 01:07:12 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu Sep 25 01:04:13 2008 Subject: Is -fvia-C still needed? Message-ID: <19663119.post@talk.nabble.com> I notice that speed from code generated by -fasm and -fvia-C isn't significant, furthermore -fvia-C takes longer time. So, why ghc still needs gcc (at least on Windows)? -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19663119.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From paulrbrown at gmail.com Thu Sep 25 03:31:24 2008 From: paulrbrown at gmail.com (Paul Brown) Date: Thu Sep 25 03:28:26 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080924203618.GC22304@matrix.chaos.earth.li> References: <8b02d2150809222343p133c29c9p3b0dfb7d1019505d@mail.gmail.com> <20080924203618.GC22304@matrix.chaos.earth.li> Message-ID: <4249453d0809250031p50754846o40d5378127aab662@mail.gmail.com> For what it's worth, I just built 6.10.0.20080921... on two of my MacOS 10.5 machines using 6.8.3 without problems (other than a complaint about a preexisting "runhaskell" in the target bin directory). -- Paul On Wed, Sep 24, 2008 at 1:36 PM, Ian Lynagh wrote: > On Tue, Sep 23, 2008 at 12:43:53AM -0600, humasect wrote: >> installPackage: internal error: stg_ap_ppp_ret >> (GHC version 6.8.3 for i386_apple_darwin) >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> make[2]: *** [build.stage.1] Abort trap >> make[1]: *** [build.stage.1] Error 2 >> make: *** [stage1] Error 1 > > This is a bug in GHC 6.8.3, so isn't something we can fix (unless it > also happens with 6.10). Unfortunately it means you can't build 6.10, > but you will be able to install a binary distribution or OS X installer. > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From jason.dusek at gmail.com Thu Sep 25 03:45:11 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Sep 25 03:42:12 2008 Subject: Is -fvia-C still needed? In-Reply-To: <19663119.post@talk.nabble.com> References: <19663119.post@talk.nabble.com> Message-ID: <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> Without GCC, how would we compile C extensions? -- _jsn From Christian.Maeder at dfki.de Thu Sep 25 04:29:19 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Sep 25 04:26:16 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080924201806.GA22304@matrix.chaos.earth.li> References: <20080922003543.GA29215@matrix.chaos.earth.li> <48D79E78.5040802@dfki.de> <20080924201806.GA22304@matrix.chaos.earth.li> Message-ID: <48DB4BDF.8050807@dfki.de> Ian Lynagh wrote: > On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote: >> Ian Lynagh wrote: >>> Right now we have the source bundles: >>> >>> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 >>> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralibs.tar.bz2 >> I've tried to build a binary dist on x86 under Solaris and did not succeed. > > Thanks Christian et al; all the issues you've identified should now be > fixed in darcs. Yes, I've noticed your patches. They look good (but how knows without testing). Thank You! Christian From marlowsd at gmail.com Thu Sep 25 08:18:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 25 08:15:40 2008 Subject: Is -fvia-C still needed? In-Reply-To: <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> Message-ID: <48DB8188.9070105@gmail.com> Jason Dusek wrote: > Without GCC, how would we compile C extensions? I'm not sure what you mean. To answer the original question: yes, -fvia-C is almost redundant. We took some steps in 6.10.1 to make -fvia-C behave in a way more consistent with -fasm (that I still need to document properly!), so -fvia-C no longer includes any header files when compiling the generated C code. If you were using -fvia-C to call C functions defined as CPP macros via the FFI, then you can't do that any more in 6.10.1. You have to write a C wrapper function and call that instead. I think -fvia-C generates slightly faster code in some cases, but it might also generate slower code sometimes. FWIW, we still use it for our binary distributions, but I haven't measured the difference it makes, if any. Cheers, Simon From jason.dusek at gmail.com Thu Sep 25 12:36:17 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Sep 25 12:33:17 2008 Subject: Is -fvia-C still needed? In-Reply-To: <48DB8188.9070105@gmail.com> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> <48DB8188.9070105@gmail.com> Message-ID: <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> I understood the OP's closing remark -- "...why ghc still needs gcc (at least on Windows)?" -- as a suggestion that GHC on Windows would be better served by not bundling GCC. However, I'm probably not the only one who's written a little C to go along with a lot of Haskell -- and it's nice that the default Windows distribution supports that code (unlike some other type-inferring, statically typed, strongly typed languages, which ship with a little hole to fill in for the C compiler). -- _jsn From leledumbo_cool at yahoo.co.id Fri Sep 26 00:54:00 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Fri Sep 26 00:50:58 2008 Subject: Is -fvia-C still needed? In-Reply-To: <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> <48DB8188.9070105@gmail.com> <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> Message-ID: <19682498.post@talk.nabble.com> The reason why I don't like gcc shipped with ghc distribution is that I waste my harddisk space for two same compilers, only differ in version (I use 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes behaves unexpectedly. For instance, I try to delete the shipped gcc because I think ghc will be able to find mine (hmm...I suggest ghc implements this, especially for people with low harddisk space). But when I try to compile, it complains about not finding gcc. Crazily, upon compiling with -fvia-C it runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in my PATH)! This also happens when I try to bootstrap from source. Second reason, if ghc already performs very well using its ncg, I think it's better to improve it rather than relying on gcc's one. -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19682498.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From jason.dusek at gmail.com Fri Sep 26 03:00:20 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Sep 26 02:57:18 2008 Subject: Is -fvia-C still needed? In-Reply-To: <19682498.post@talk.nabble.com> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> <48DB8188.9070105@gmail.com> <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> <19682498.post@talk.nabble.com> Message-ID: <42784f260809260000p3d6099f5k5dfd7122ee2d6295@mail.gmail.com> leledumbo wrote: > The reason why I don't like gcc shipped with ghc... I have not encountered these difficulties, but I can see the problem now. -- _jsn From marlowsd at gmail.com Fri Sep 26 10:40:17 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Sep 26 10:37:38 2008 Subject: Is -fvia-C still needed? In-Reply-To: <19682498.post@talk.nabble.com> References: <19663119.post@talk.nabble.com> <42784f260809250045h5c9462d6md4afb77e649a2dce@mail.gmail.com> <48DB8188.9070105@gmail.com> <42784f260809250936o3245cd6qe44c75077596fb8a@mail.gmail.com> <19682498.post@talk.nabble.com> Message-ID: <48DCF451.1030409@gmail.com> leledumbo wrote: > The reason why I don't like gcc shipped with ghc distribution is that I waste > my harddisk space for two same compilers, only differ in version (I use > 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes > behaves unexpectedly. For instance, I try to delete the shipped gcc because > I think ghc will be able to find mine (hmm...I suggest ghc implements this, > especially for people with low harddisk space). But when I try to compile, > it complains about not finding gcc. Crazily, upon compiling with -fvia-C it > runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in > my PATH)! This also happens when I try to bootstrap from source. > Second reason, if ghc already performs very well using its ncg, I think it's > better to improve it rather than relying on gcc's one. If GHC isn't using its own gcc, that's a bug. We could theoretically ship a cut-down GHC bundle with no gcc, but as others have said it's often useful. For example, hsc2hs needs it, and you'll need a gcc if you write 'foreign export' or 'foreign import "wrapper"' anywhere in your source code. Cheers, Simon From simonpj at microsoft.com Fri Sep 26 12:08:24 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Sep 26 12:05:21 2008 Subject: GADTs and functional dependencies In-Reply-To: References: <200809231807.16093.g9ks157k@acme.softbase.org><638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com> <2FCBD29987DA4CBCA61D8EAFAFE7B27F@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7676A8CD@EA-EXMSG-C334.europe.corp.microsoft.com> By "global" I really meant "throughout the scope of the type variable concerned. Nevertheless, the program you give is rejected, even though the scope is global: class FD a b | a -> b f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3 f x y = y Both GHC and Hugs erroneously reject the program, just as they do this one instance FD Int Bool g :: FD Int b => ... The problem is that the implementation technique for FDs used by GHC and Hugs (global unification) isn't up to the job. That is what we are fixing with type functions. I do not know how to fix it for FDs (except by way of translation to TFs) -- at least, not while maintaining a strongly typed intermediate language. This latter constraint is a condition imposed by GHC, but it's one I am strongly committed to. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 24 September 2008 19:27 | To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org | Subject: Re: GADTs and functional dependencies | | >> This has never worked with fundeps, because it involves a *local* type | equality (one that holds | >> in some places and not others) and my implementation of fundeps is | fundamentally based on | >> *global* equality. Prior to GADTs that was fine! | | Actually, how does that relate to reasoning under assumptions? | | class FD a b | a -> b | | f :: (FD t1 t2, FD t1 t3) => .. | f = .. | | There is no instance of 'FD', so no equalities can be derived from there | outside of 'f', and no equalities should be derived globally from instances | that are only local hypotheses in 'f' . But inside 'f', we assume that those | two 'FD' instances exist, so we should assume 't2 ~ t3' to the right of | the implication. | | Isn't that decidedly local? | Claus | | From claus.reinke at talk21.com Fri Sep 26 12:58:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 12:55:36 2008 Subject: GADTs and functional dependencies References: <200809231807.16093.g9ks157k@acme.softbase.org><638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com><2FCBD29987DA4CBCA61D8EAFAFE7B27F@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32D7676A8CD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4863948A624342C99848690D74780218@cr3lt> > By "global" I really meant "throughout the scope of the type variable concerned. > > Nevertheless, the program you give is rejected, even though the scope is global: > > class FD a b | a -> b > > f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3 > f x y = y > > Both GHC and Hugs erroneously reject the program, while both GHC and Hugs accept this variation: class FD a b | a -> b f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3 f x y = undefined and infer the type of 'f' to be 'f :: (FD t1 t3) => t1 -> t3 -> t3'. So they use the FD globally (when checking use of 'f'), but not locally (when checking the definition of 'f'). Is that interpretation correct, or is there another bug involved? > The problem is that the implementation technique for FDs used by GHC and Hugs (global unification) > isn't up to the job. Interesting. When the FD-via-CHR discussion started, I toyed with the idea of writing an instance inference engine based on CHR (since CHR happen to be a variant of CPN - Coloured Petri Nets -, I happened to have an implementation at hand;-). But once I noticed the difficulties of managing local constraint stores (and exchanging some, but not all inferred information with the global constraint store), I abandoned the idea. Ever since then I've been wondering how GHC handles that!-) >That is what we are fixing with type functions. I do not know how to fix it for FDs (except by way >of translation to TFs) -- at least, not while maintaining a strongly typed intermediate language. >This latter constraint is a condition imposed by GHC, but it's one I am strongly committed to. Since FDs constrain the set of valid instances, I had been wondering whether one could apply the FD-based refinements/substitutions to the code obtained (just as they are applied to the class constraints) while keeping a typed intermediate language. Claus From claus.reinke at talk21.com Fri Sep 26 13:07:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 13:04:38 2008 Subject: Is -fvia-C still needed? 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> Message-ID: <03325F35F37E4F408F528B72D14EE592@cr3lt> >> The reason why I don't like gcc shipped with ghc distribution is that I waste >> my harddisk space for two same compilers, only differ in version (I use >> 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes >> behaves unexpectedly. For instance, I try to delete the shipped gcc because >> I think ghc will be able to find mine (hmm...I suggest ghc implements this, >> especially for people with low harddisk space). But when I try to compile, >> it complains about not finding gcc. Crazily, upon compiling with -fvia-C it >> runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in >> my PATH)! This also happens when I try to bootstrap from source. >> Second reason, if ghc already performs very well using its ncg, I think it's >> better to improve it rather than relying on gcc's one. > > If GHC isn't using its own gcc, that's a bug. > > We could theoretically ship a cut-down GHC bundle with no gcc, but as > others have said it's often useful. For example, hsc2hs needs it, and > you'll need a gcc if you write 'foreign export' or 'foreign import > "wrapper"' anywhere in your source code. Having fully-functional-out-of-the-box GHC installers is very useful, but you might be interested in http://hackage.haskell.org/trac/ghc/ticket/1502 which promises to reduce the tension by making GHC's gcc just another gcc (so you'll be more likely to get by with only one gcc) Claus From kili at outback.escape.de Sat Sep 27 09:10:04 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sat Sep 27 09:12:04 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080922003543.GA29215@matrix.chaos.earth.li> References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: <20080927131004.GA27437@petunia.outback.escape.de> Hi, On Mon, Sep 22, 2008 at 01:35:43AM +0100, Ian Lynagh wrote: > We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a > beta release of GHC 6.10.1. [...] > Please test as much as possible; bugs are much cheaper if we find them > before the release! Not quite the beta snapshot, but from HEAD about the same time you tagged and branched, I got the following positive results on OpenBSD/i386: 1) Build it up to stage2 and make install from ghc-6.6: ok 2) The same again with the result of 1): ok 3) Full build including all extralibs with the result of 2): ok I'll restart the whole process with what's in the ghc-6.10 branch now (hopefully that's ok for you, since some fixes have been already committed to the branch), and I'll also try to run the testsuite after step 3). BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond sh boot ./configure --prefix=... gmake install required? Ciao, Kili ps: I've also an amd64 (aka x86_64) at work and will run the tests on it next week. Wether I'll be able to fix the ghci problem in time: no idea. From marlowsd at gmail.com Sat Sep 27 10:36:03 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Sep 27 10:33:22 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080927131004.GA27437@petunia.outback.escape.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080927131004.GA27437@petunia.outback.escape.de> Message-ID: <48DE44D3.9030803@gmail.com> Matthias Kilian wrote: > Hi, > > On Mon, Sep 22, 2008 at 01:35:43AM +0100, Ian Lynagh wrote: >> We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a >> beta release of GHC 6.10.1. > [...] >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! > > Not quite the beta snapshot, but from HEAD about the same time you > tagged and branched, I got the following positive results on > OpenBSD/i386: > > 1) Build it up to stage2 and make install from ghc-6.6: ok > 2) The same again with the result of 1): ok > 3) Full build including all extralibs with the result of 2): ok > > I'll restart the whole process with what's in the ghc-6.10 branch > now (hopefully that's ok for you, since some fixes have been already > committed to the branch), and I'll also try to run the testsuite > after step 3). > > BTW: I had some problems running the testsuite some weeks ago, > because some autoconf'd stuff was missing. When building from the > repository (*not* from the source tarballs), are there any additional > steps beyond > > sh boot > ./configure --prefix=... > gmake install > > required? No, that should be enough. Thanks for testing it! Cheers, Simon From jcab.lists at JCABs-Rumblings.com Sat Sep 27 11:58:18 2008 From: jcab.lists at JCABs-Rumblings.com (Juan Carlos Arevalo Baeza) Date: Sat Sep 27 11:55:11 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080922003543.GA29215@matrix.chaos.earth.li> References: <20080922003543.GA29215@matrix.chaos.earth.li> Message-ID: <48DE581A.7070402@JCABs-Rumblings.com> Two regressions with Template Haskell on Windows: --- {-# LANGUAGE TemplateHaskell #-} module MkData where import Language.Haskell.TH import Language.Haskell.TH.Syntax op a b = a + b decl = [d| func = 0 `op` 3 |] --- This gives a very weird error: C:\Users\JCAB\Haskell\THTest>ghc --make main.hs [1 of 2] Compiling MkData ( MkData.hs, MkData.o ) attempting to use module `main:MkData' (.\MkData.hs) which is not loaded It is related to using inline named function operators `op` in declaration quotations in the same module. If the function is defined in another module, like `const` then everything works as expected. The other: --- {-# LANGUAGE TemplateHaskell #-} module MkData where import Language.Haskell.TH import Language.Haskell.TH.Syntax decl name = returnQ $ [ DataD [] (mkName name) [] [RecC (mkName name) []] [] ] --- {-# LANGUAGE TemplateHaskell #-} module Main where import MkData $(decl "KK") main = undefined --- Also gives a spooky error message: C:\Users\JCAB\Haskell\THTest>ghc --make main.hs [1 of 2] Compiling MkData ( MkData.hs, MkData.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking main.exe ... C:\ghc\ghc-6.10.0.20080925\bin/windres: CreateProcess (null): Invalid argument I have verified that both were working with GHC 6.8.3. Fail with the latest beta 6.10.0.20080925. JCAB Ian Lynagh wrote: > We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a > beta release of GHC 6.10.1. > > You can download snapshots from here: > > http://www.haskell.org/ghc/dist/stable/dist/ > > Right now we have the source bundles: > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralibs.tar.bz2 > > Only the first of these is necessary. The "extralibs" package contains > various extra packages that we normally supply with GHC - unpack the > extralibs tarball on top of the source tree to add them, and they will > be included in the build automatically. > > There is also currently an installer for i386/Windows, and a binary > distribution for x86_64/Linux. More may appear later. > > There are a couple of known problems with the x86_64/Linux bindist: > * It uses libedit.so.0 whereas some distributions (e.g. Debian) only > provide libedit.so.2. > * It installs utilities like unlit in the wrong place, so compiling > literate code won't work. > If you install from source then you won't hit either of those problems. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > We hope to have release candidates followed by a release in around 3 > weeks time, but of course that may slip if problems are uncovered. > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From humasect at gmail.com Sun Sep 28 11:42:36 2008 From: humasect at gmail.com (humasect) Date: Sun Sep 28 11:39:27 2008 Subject: ANNOUNCE: GHC 6.10.1 beta Message-ID: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> uh oh.. ~/Haskell/bin/ghc +RTS -N2 -RTS -hidir ../build/ -odir ../build/ -threaded -package ghc -main-is Shell --make Shell -DCALLCONV=ccall [4 of 4] Compiling Shell ( Shell.hs, ../build/Shell.o ) Linking Shell ... ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) When linking with new GHC api after converting this shell to use it ( http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus) -lyndon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080928/f218c090/attachment-0001.htm From mad.one at gmail.com Sun Sep 28 12:01:10 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sun Sep 28 11:58:03 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> Message-ID: <1222617622-sup-6544@existential.local> The atom sorting errors are fairly harmless it seems; you should still get an executable in the end (I was playing with the new API today too.) Austin Excerpts from humasect's message of Sun Sep 28 10:42:36 -0500 2008: > uh oh.. > ~/Haskell/bin/ghc +RTS -N2 -RTS -hidir ../build/ -odir ../build/ -threaded > -package ghc -main-is Shell --make Shell -DCALLCONV=ccall > [4 of 4] Compiling Shell ( Shell.hs, ../build/Shell.o ) > Linking Shell ... > ld: atom sorting error for > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in > /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.1 > 0.0.20080927.a(LibFFI.o) > ld: atom sorting error for > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in > /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.1 > 0.0.20080927.a(LibFFI.o) > > When linking with new GHC api after converting this shell to use it ( > http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus) > > -lyndon From humasect at gmail.com Sun Sep 28 13:27:48 2008 From: humasect at gmail.com (humasect) Date: Sun Sep 28 13:24:40 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <1222617622-sup-6544@existential.local> References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> <1222617622-sup-6544@existential.local> Message-ID: <8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com> Ah, indeed it does! Then, more about GHC API: "Shell: Shell: missing -B option" I can't find any information of what this -B is, it is not in GHC sources or anything helpful from google. I tried to add "-B../build" or similar to GHC api DynFlags, no luck. I've only found "[ "-shared", "-Wl,-Bsymbolic" ]" in compiler/main/DriverPipeline.hs thanks, -lyndon 2008/9/28 Austin Seipp > The atom sorting errors are fairly harmless it seems; you should still > get an executable in the end (I was playing with the new API today too.) > > Austin > > Excerpts from humasect's message of Sun Sep 28 10:42:36 -0500 2008: > > uh oh.. > > ~/Haskell/bin/ghc +RTS -N2 -RTS -hidir ../build/ -odir ../build/ > -threaded > > -package ghc -main-is Shell --make Shell -DCALLCONV=ccall > > [4 of 4] Compiling Shell ( Shell.hs, ../build/Shell.o ) > > Linking Shell ... > > ld: atom sorting error for > > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and > > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in > > > /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.1 > > 0.0.20080927.a(LibFFI.o) > > ld: atom sorting error for > > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and > > _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in > > > /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.1 > > 0.0.20080927.a(LibFFI.o) > > > > When linking with new GHC api after converting this shell to use it ( > > http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus) > > > > -lyndon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080928/9bab4889/attachment.htm From naur at post11.tele.dk Sun Sep 28 15:09:14 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Sun Sep 28 15:07:24 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com> References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> <1222617622-sup-6544@existential.local> <8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com> Message-ID: <200809282109.14811.naur@post11.tele.dk> Hello, On Sunday 28 September 2008 19:27, humasect wrote: > Ah, indeed it does! Then, more about GHC API: > "Shell: Shell: missing -B option" > > I can't find any information of what this -B is, it is not in GHC sources or > anything helpful from google. The -B is used from a ghc shell script to identify where the rest of the GHC installation resides. An example with a GHC 6.8.2 installed in $HOME/tn/install/ghc-6.8.2: > tn@linux:~> cat tn/install/ghc-6.8.2/bin/ghc > #!/bin/sh > GHCBIN=/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2/ghc-6.8.2 > TOPDIROPT=-B/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2 > exec $GHCBIN $TOPDIROPT ${1+"$@"} > tn@linux:~> There is likely some designation for this option that I cannot recall. If it is documented anywhere, I haven't noticed. > ... Best regards Thorkil From humasect at gmail.com Sun Sep 28 16:53:51 2008 From: humasect at gmail.com (humasect) Date: Sun Sep 28 16:50:41 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <8b02d2150809281353i4d55fb5cqcc65c3af6296354a@mail.gmail.com> References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com> <1222617622-sup-6544@existential.local> <8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com> <200809282109.14811.naur@post11.tele.dk> <8b02d2150809281353i4d55fb5cqcc65c3af6296354a@mail.gmail.com> Message-ID: <8b02d2150809281353w64b93736te2a00cca43ebd197@mail.gmail.com> Thank you all. Everything is great now. It was because (Just ghcPath) was not passed into runGhc, and lack of ghc-path. peace and happiness, -lyndon 2008/9/28 Thorkil Naur Hello, > > On Sunday 28 September 2008 19:27, humasect wrote: > > Ah, indeed it does! Then, more about GHC API: > > "Shell: Shell: missing -B option" > > > > I can't find any information of what this -B is, it is not in GHC sources > or > > anything helpful from google. > > The -B is used from a ghc shell script to identify where the rest of the > GHC > installation resides. An example with a GHC 6.8.2 installed in > $HOME/tn/install/ghc-6.8.2: > > > tn@linux:~> cat tn/install/ghc-6.8.2/bin/ghc > > #!/bin/sh > > GHCBIN=/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2/ghc-6.8.2 > > TOPDIROPT=-B/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2 > > exec $GHCBIN $TOPDIROPT ${1+"$@"} > > tn@linux:~> > > There is likely some designation for this option that I cannot recall. If > it > is documented anywhere, I haven't noticed. > > > ... > > Best regards > Thorkil > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080928/0fc77176/attachment.htm From claus.reinke at talk21.com Sun Sep 28 18:10:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Sep 28 18:07:45 2008 Subject: ghc-path (was: ANNOUNCE: GHC 6.10.1 beta) References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com><1222617622-sup-6544@existential.local><8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com><200809282109.14811.naur@post11.tele.dk><8b02d2150809281353i4d55fb5cqcc65c3af6296354a@mail.gmail.com> <8b02d2150809281353w64b93736te2a00cca43ebd197@mail.gmail.com> Message-ID: > Thank you all. Everything is great now. It was because (Just ghcPath) was > not passed into runGhc, and lack of ghc-path. btw: is ghc-path going to be part of the ghc release or the haskell platform? Currently, I can't see it in either, which would be a pity. I thought the idea was to provide it in the ghc release, but not install it (since cabal install isn't going to be part of the ghc release after all). Claus From neil.mitchell.2 at credit-suisse.com Mon Sep 29 05:42:22 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 29 05:39:54 2008 Subject: newSession gone from GHC API Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A3B@ELON17P32001A.csfb.cs-group.com> Hi I just noticed that newSession has been removed from the GHC API. Unfortunately, this breaks nearly all examples on the web: http://www.haskell.org/haskellwiki/GHC/As_a_library http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API Could someone fix those up, to show the new style of interaction? Also are the breaking changes to newSession in GHC 6.10, or only in GHC Head? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From igloo at earth.li Mon Sep 29 05:46:34 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 29 05:43:23 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080927131004.GA27437@petunia.outback.escape.de> References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080927131004.GA27437@petunia.outback.escape.de> Message-ID: <20080929094634.GA8544@matrix.chaos.earth.li> On Sat, Sep 27, 2008 at 03:10:04PM +0200, Matthias Kilian wrote: > > BTW: I had some problems running the testsuite some weeks ago, > because some autoconf'd stuff was missing. When building from the > repository (*not* from the source tarballs), are there any additional > steps beyond > > sh boot > ./configure --prefix=... > gmake install > > required? I'm not sure if running "gmake install" without first running "gmake" works. Also, note that if you are building the extralibs then you need to run "sh boot" after getting them. Thanks Ian From claus.reinke at talk21.com Mon Sep 29 07:26:29 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 29 07:23:23 2008 Subject: newSession gone from GHC API References: <33A3F585590A6F4E81E3D45AA4A111C902CD3A3B@ELON17P32001A.csfb.cs-group.com> Message-ID: >I just noticed that newSession has been removed from the GHC API. >Unfortunately, this breaks nearly all examples on the web: >http://www.haskell.org/haskellwiki/GHC/As_a_library >http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API >Could someone fix those up, to show the new style of interaction? Also >are the breaking changes to newSession in GHC 6.10, or only in GHC Head? Thomas said he was working on a conversion guide, but delayed by travelling: http://www.haskell.org/pipermail/cvs-ghc/2008-September/045361.html Meanwhile, since you're somewhat familar with haddock, his patches to port haddock to the new api may help (I used them to figure out where to look for more info;). Or, if you prefer smaller examples, have a look at http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/syb-utils/examples/GhcApiSybTesting.hs which I patched recently (diff below). Mostly, you'll be looking for runGhc, dropping session parameters, changing dynamic flags from String to Located String, and splitting checkModule into separate phases (there's a class that simplifies access via the old record selector functions). Possibly other small things, like using liftIO to do IO in the Ghc monads. Hth, Claus $ darcs changes -v -p 'new Ghc Api' | sed 's/\[_.._\]\[_._\]$//' diffing dir... Mon Sep 22 20:01:02 GMT Daylight Time 2008 claus.reinke@talk21.com * adapt example to new Ghc Api { hunk ./examples/GhcApiSybTesting.hs 15 +import SrcLoc +import MonadUtils hunk ./examples/GhcApiSybTesting.hs 35 -main = defaultErrorHandler defaultDynFlags $ do - s <- newSession (Just libdir) - flags <- getSessionDynFlags s - (flags,_,_) <- parseDynamicFlags flags ["-package ghc"] +main = defaultErrorHandler defaultDynFlags $ + runGhc (Just libdir) $ do + flags <- getSessionDynFlags + (flags,_,_) <- parseDynamicFlags flags [noLoc "-package ghc"] hunk ./examples/GhcApiSybTesting.hs 40 - setSessionDynFlags s flags{ hscTarget=HscInterpreted } - addTarget s =<< guessTarget source Nothing - load s LoadAllTargets - unqual <- getPrintUnqual s + setSessionDynFlags flags{ hscTarget=HscInterpreted } + addTarget =<< guessTarget source Nothing + load LoadAllTargets + unqual <- getPrintUnqual + {- hunk ./examples/GhcApiSybTesting.hs 50 + -} + tcm <- typecheckModule =<< parseModule (mkModuleName modName) + doSomething unqual tcm hunk ./examples/GhcApiSybTesting.hs 63 - doSomething unqual cm = do - let parsed = parsedSource cm - renamed = renamedSource cm - typechecked = typecheckedSource cm + doSomething unqual tcm = liftIO $ do + let parsed = parsedSource tcm + renamed = renamedSource tcm + typechecked = typecheckedSource tcm hunk ./examples/GhcApiSybTesting.hs 84 - maybe (putStrLn "no typechecked source") - (printForUser stdout unqual . shown TypeChecker) typechecked + printForUser stdout unqual $ shown TypeChecker typechecked } From mechvel at botik.ru Mon Sep 29 07:54:36 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Sep 29 07:51:47 2008 Subject: 6.10-candidate tested In-Reply-To: <48DA7664.1030602@dfki.de> References: <20080924114059.GA12514@scico.botik.ru> <20080924121438.GA12774@scico.botik.ru> <48DA5DA3.2070905@dfki.de> <20080924163238.GA15136@scico.botik.ru> <48DA7664.1030602@dfki.de> Message-ID: <20080929115436.GA20655@scico.botik.ru> On Wed, Sep 24, 2008 at 07:18:28PM +0200, Christian Maeder wrote: > Serge D. Mechveliani wrote: > > On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: > >> Do you have libedit on your linux machine (because I haven't)? > >> > > > > I do not know what is libedit and where to find it. > > It's the library needed for editline > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline > > editline is the replacement of readline. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline > > > 1. ghc-pkg list does not show the editline package. > > 2. The arrow keys and backspace do not work in ghci. > > This is so -- on my machine, under Debian Linux. > > The advantage is ghci works without editline and readline. The > disadvantage is if you want arrow keys and backspace to work, you should > have installed http://www.thrysoee.dk/editline/ first. > > > Is this due to some deficiency in Debian Linux installation or this is > > a bug in the GHC installation? > > A (debian) package manager could install editline (and gmp) before ghc. > (Unfortunately user programs may depend on those extra libraries, too.) > As I recall, earlier, there were needed for GHC the shared libraries gmp and libreadline.so* As I understand, I need now to install the shared library editline instead of libreadline. Is this so? But maybe, the installation procedure (configure command or make install command) should search for editline, gmp, and such, and report an error if the GHC installation does not find them? ----------------- Serge Mechveliani mechvel@botik.ru From simonpj at microsoft.com Mon Sep 29 07:59:50 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 29 07:56:40 2008 Subject: GADTs and functional dependencies In-Reply-To: <4863948A624342C99848690D74780218@cr3lt> References: <200809231807.16093.g9ks157k@acme.softbase.org><638ABD0A29C8884A91BC5FB5C349B1C32D766E2DCC@EA-EXMSG-C334.europe.corp.microsoft.com><2FCBD29987DA4CBCA61D8EAFAFE7B27F@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32D7676A8CD@EA-EXMSG-C334.europe.corp.microsoft.com> <4863948A624342C99848690D74780218@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7680D08E@EA-EXMSG-C334.europe.corp.microsoft.com> | while both GHC and Hugs accept this variation: | | class FD a b | a -> b | f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3 | f x y = undefined | | and infer the type of 'f' to be 'f :: (FD t1 t3) => t1 -> t3 -> t3'. | | So they use the FD globally (when checking use of 'f'), but not locally | (when checking the definition of 'f'). Is that interpretation correct, or is | there another bug involved? No, by "globally" I meant "throughout the scope of a type variable". I'm surprised GHC accepts the program you give, because it should unify two skolems. With a minor change it fails f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3 f x y = y As I say, GHC's implementation of FDs is flaky and inconsistent; and that is not just because I'm lazy but because it is hard to know just what to do, most especially in situations like this when there is no System F translation. That is why I've been working so hard on FC. Simon From humasect at gmail.com Mon Sep 29 11:19:56 2008 From: humasect at gmail.com (humasect) Date: Mon Sep 29 11:16:46 2008 Subject: newSession gone from GHC API In-Reply-To: <8b02d2150809290819n7692cf2fla9a99020c2e3d89@mail.gmail.com> References: <33A3F585590A6F4E81E3D45AA4A111C902CD3A3B@ELON17P32001A.csfb.cs-group.com> <8b02d2150809290819n7692cf2fla9a99020c2e3d89@mail.gmail.com> Message-ID: <8b02d2150809290819w1362aa3fp4f363b84baf804f@mail.gmail.com> Also to make Located String in the simple way: import SrcLoc L noSrcSpan "-hidir ../build" also make sure to "import MonadUtils" for that version of liftIO. I have converted the graphical/opengl/openal shell for the project I am working on successfully, let me know if you have questions! -lyndon 2008/9/29 Claus Reinke I just noticed that newSession has been removed from the GHC API. >> Unfortunately, this breaks nearly all examples on the web: >> http://www.haskell.org/haskellwiki/GHC/As_a_library >> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API >> Could someone fix those up, to show the new style of interaction? Also >> are the breaking changes to newSession in GHC 6.10, or only in GHC Head? >> > > Thomas said he was working on a conversion guide, but > delayed by travelling: > > http://www.haskell.org/pipermail/cvs-ghc/2008-September/045361.html > > Meanwhile, since you're somewhat familar with haddock, his > patches to port haddock to the new api may help (I used them > to figure out where to look for more info;). Or, if you prefer > smaller examples, have a look at > > http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/syb-utils/examples/GhcApiSybTesting.hs > > which I patched recently (diff below). Mostly, you'll be looking for > runGhc, dropping session parameters, changing dynamic flags from > String to Located String, and splitting checkModule into separate > phases (there's a class that simplifies access via the old record selector > functions). Possibly other small things, like using liftIO to > do IO in the Ghc monads. > > Hth, > Claus > > $ darcs changes -v -p 'new Ghc Api' | sed 's/\[_.._\]\[_._\]$//' > diffing dir... > Mon Sep 22 20:01:02 GMT Daylight Time 2008 claus.reinke@talk21.com > * adapt example to new Ghc Api > { > hunk ./examples/GhcApiSybTesting.hs 15 > +import SrcLoc > +import MonadUtils > hunk ./examples/GhcApiSybTesting.hs 35 > -main = defaultErrorHandler defaultDynFlags $ do > - s <- newSession (Just libdir) > - flags <- getSessionDynFlags s > - (flags,_,_) <- parseDynamicFlags flags ["-package ghc"] > +main = defaultErrorHandler defaultDynFlags $ > + runGhc (Just libdir) $ do > + flags <- getSessionDynFlags > + (flags,_,_) <- parseDynamicFlags flags [noLoc "-package ghc"] > hunk ./examples/GhcApiSybTesting.hs 40 > - setSessionDynFlags s flags{ hscTarget=HscInterpreted } > - addTarget s =<< guessTarget source Nothing > - load s LoadAllTargets > - unqual <- getPrintUnqual s > + setSessionDynFlags flags{ hscTarget=HscInterpreted } > + addTarget =<< guessTarget source Nothing > + load LoadAllTargets > + unqual <- getPrintUnqual > + {- > hunk ./examples/GhcApiSybTesting.hs 50 > + -} > + tcm <- typecheckModule =<< parseModule (mkModuleName modName) > + doSomething unqual tcm > hunk ./examples/GhcApiSybTesting.hs 63 > - doSomething unqual cm = do > - let parsed = parsedSource cm > - renamed = renamedSource cm > - typechecked = typecheckedSource cm > + doSomething unqual tcm = liftIO $ do > + let parsed = parsedSource tcm > + renamed = renamedSource tcm > + typechecked = typecheckedSource tcm > hunk ./examples/GhcApiSybTesting.hs 84 > - maybe (putStrLn "no typechecked source") > - (printForUser stdout unqual . shown TypeChecker) > typechecked > + printForUser stdout unqual $ shown TypeChecker typechecked > > } > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080929/4a85bc98/attachment.htm From kili at outback.escape.de Mon Sep 29 13:07:33 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Sep 29 13:06:52 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080929094634.GA8544@matrix.chaos.earth.li> References: <20080922003543.GA29215@matrix.chaos.earth.li> <20080927131004.GA27437@petunia.outback.escape.de> <20080929094634.GA8544@matrix.chaos.earth.li> Message-ID: <20080929170733.GA11160@petunia.outback.escape.de> On Mon, Sep 29, 2008 at 10:46:34AM +0100, Ian Lynagh wrote: > > BTW: I had some problems running the testsuite some weeks ago, > > because some autoconf'd stuff was missing. When building from the > > repository (*not* from the source tarballs), are there any additional > > steps beyond > > > > sh boot > > ./configure --prefix=... > > gmake install > > > > required? > > I'm not sure if running "gmake install" without first running "gmake" > works. Also, note that if you are building the extralibs then you need > to run "sh boot" after getting them. I was sloppy in my mail. Actually I'm even building stage1 and stage2 explicitely before installing. From my script: nice time gmake stage1 nice time gmake stage2 nice time gmake install And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it. I've yet to evaluate the results of the testsuite. I'll post it in a few hours. Ciao, Kili From kili at outback.escape.de Mon Sep 29 16:26:35 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Sep 29 16:26:50 2008 Subject: ANNOUNCE: GHC 6.10.1 beta In-Reply-To: <20080929170733.GA11160@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> Message-ID: <20080929202635.GA23350@petunia.outback.escape.de> On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote: > And my problem with the testsuite was a PEBKAC (of course): on > OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 > (you can have several versions installed in parallel), which isn't > found by configure, which in turn lets the testsuite bail out. > Setting PythonCmd during configure fixed it. > > I've yet to evaluate the results of the testsuite. I'll post it in > a few hours. Summary (skipping all the details): OVERALL SUMMARY for test run started at Sun Sep 28 17:57:33 CEST 2008 2233 total tests, which gave rise to 12011 test cases, of which 0 caused framework failures 2244 were skipped 9324 expected passes 140 expected failures 20 unexpected passes 283 unexpected failures This looks more scary than it is; many unexpected failures are caused by a change in Rational formatin ("17%42" vs. "17 % 42"), some others are probably caused by OpenBSD specific stuff (e.g., warnings about the use of unsafe functions like strcpy(3), different output behaviour on signals like SIGSEGV, and, well the unicode (causing unexpected passes) and some threading differences are most probably also OS-dependent candidates). Some problems are not strictly OpenBSD specific, but just triggered due to the more restrictive default limits (number of open file descriptors, datasize, etc.). Finally, some tests just did time out (this isn't the fastest machine in the universe). A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log And a shorter log (using a really horrible awk script for stripping down the full log): http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.shortlog Fallout from the following tests looks a little bit suspicious: num009 num012 galois_raytrace (well, I didn't read the whol diff ;-)) driver019 (I think a fix for this has been pushed during the last 24 hours) ffi009 tough all the hpc stuff copyFile001 (but there was a push for it recently, IIRC) Ciao, Kili From dons at galois.com Mon Sep 29 17:36:41 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 29 17:33:26 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: <20080929213641.GE23645@scytale.galois.com> kili: > On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote: > > And my problem with the testsuite was a PEBKAC (of course): on > > OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 > > (you can have several versions installed in parallel), which isn't > > found by configure, which in turn lets the testsuite bail out. > > Setting PythonCmd during configure fixed it. > > > > I've yet to evaluate the results of the testsuite. I'll post it in > > a few hours. > > Summary (skipping all the details): > > OVERALL SUMMARY for test run started at Sun Sep 28 17:57:33 CEST 2008 > 2233 total tests, which gave rise to > 12011 test cases, of which > 0 caused framework failures > 2244 were skipped > > 9324 expected passes > 140 expected failures > 20 unexpected passes > 283 unexpected failures > > This looks more scary than it is; many unexpected failures are > caused by a change in Rational formatin ("17%42" vs. "17 % 42"), > some others are probably caused by OpenBSD specific stuff (e.g., > warnings about the use of unsafe functions like strcpy(3), different > output behaviour on signals like SIGSEGV, and, well the unicode > (causing unexpected passes) and some threading differences are most > probably also OS-dependent candidates). Some problems are not > strictly OpenBSD specific, but just triggered due to the more > restrictive default limits (number of open file descriptors, datasize, > etc.). Finally, some tests just did time out (this isn't the fastest > machine in the universe). > > A full test log is available at > http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log > > And a shorter log (using a really horrible awk script for stripping down > the full log): > http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.shortlog > > Fallout from the following tests looks a little bit suspicious: > > num009 > num012 > galois_raytrace (well, I didn't read the whol diff ;-)) > driver019 (I think a fix for this has been pushed during the last 24 hours) > ffi009 > tough > all the hpc stuff > copyFile001 (but there was a push for it recently, IIRC) Great work Kili!! -- Don From elliottslaughter at gmail.com Tue Sep 30 02:28:38 2008 From: elliottslaughter at gmail.com (Elliott Slaughter) Date: Tue Sep 30 02:25:24 2008 Subject: GHC on Solaris/SPARC? Message-ID: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> Hi, I am having trouble with precompiled binary http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-sparc-sun-solaris2.tar.bz2 . My first problem was that the machine is 64-bit SPARC while the binary seems to be 32-bit. Since the dynamically linked GHC binary requires additional .so files to run, any libs which I try to compile on the machine itself run into ELF class incompatibility errors. So I tried installing prebuilt packages from http://sunfreeware.com/, and spent a couple hours grokking the Solaris package system before I figured out how to extract the right files. Now I think I have the right libs installed, but when I try to run GHC, I get this: -bash-3.00$ runhaskell Setup configure ld.so.1: ghc-6.8.3: fatal: relocation error: file /home/.../lib/libncurses.so.5: symbol main: referenced symbol not found (FYI, I got ncurses 5.6 from http://sunfreeware.com/programlistsparc10.html#ncurses.) Any suggestions would be welcome, thanks in advance. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert -- 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/20080929/fc803486/attachment.htm From Christian.Maeder at dfki.de Tue Sep 30 03:35:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Sep 30 03:32:39 2008 Subject: GHC on Solaris/SPARC? In-Reply-To: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> References: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> Message-ID: <48E1D6D9.8020107@dfki.de> 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 Cheers Christian Elliott Slaughter wrote: > Hi, > > I am having trouble with precompiled > binary http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-sparc-sun-solaris2.tar.bz2. > > My first problem was that the machine is 64-bit SPARC while the binary > seems to be 32-bit. Since the dynamically linked GHC binary requires > additional .so files to run, any libs which I try to compile on the > machine itself run into ELF class incompatibility errors. So I tried > installing prebuilt packages from http://sunfreeware.com/, and spent a > couple hours grokking the Solaris package system before I figured out > how to extract the right files. Now I think I have the right libs > installed, but when I try to run GHC, I get this: > > -bash-3.00$ runhaskell Setup configure > ld.so.1: ghc-6.8.3: fatal: relocation error: file > /home/.../lib/libncurses.so.5: symbol main: referenced symbol not found > > (FYI, I got ncurses 5.6 > from http://sunfreeware.com/programlistsparc10.html#ncurses.) > > Any suggestions would be welcome, thanks in advance. > > > -- > Elliott Slaughter > > "Any road followed precisely to its end leads precisely nowhere." - > Frank Herbert > > > > -- > Elliott Slaughter > > "Any road followed precisely to its end leads precisely nowhere." - > Frank Herbert > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From org.haskell.glasgow-haskell-users at pooryorick.com Tue Sep 30 09:54:23 2008 From: org.haskell.glasgow-haskell-users at pooryorick.com (Poor Yorick) Date: Tue Sep 30 09:53:18 2008 Subject: GHC on Solaris/SPARC? In-Reply-To: <48E1D6D9.8020107@dfki.de> References: <42c0ab790809292328h164ca74fn62bd037f66b9ba4c@mail.gmail.com> <48E1D6D9.8020107@dfki.de> Message-ID: <48E22F8F.6050806@pooryorick.com> 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 > > Or just build ncurses-5.6 with all the current patches. -- Yorick From marlowsd at gmail.com Tue Sep 30 11:20:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 30 11:17:48 2008 Subject: ghc-path In-Reply-To: References: <8b02d2150809280842n17072f2cp1d342252c56e9464@mail.gmail.com><1222617622-sup-6544@existential.local><8b02d2150809281027q7d2d0451tac382643b133afc9@mail.gmail.com><200809282109.14811.naur@post11.tele.dk><8b02d2150809281353i4d55fb5cqcc65c3af6296354a@mail.gmail.com> <8b02d2150809281353w64b93736te2a00cca43ebd197@mail.gmail.com> Message-ID: <48E243DB.7010803@gmail.com> Claus Reinke wrote: >> Thank you all. Everything is great now. It was because (Just ghcPath) was >> not passed into runGhc, and lack of ghc-path. > > btw: is ghc-path going to be part of the ghc release or the haskell > platform? Currently, I can't see it in either, which > would be a pity. I thought the idea was to provide it in the > ghc release, but not install it (since cabal install isn't going to be > part of the ghc release after all). I don't think we use ghc-paths in GHC's Haddock now (Ian - correct me if I'm wrong). And it's hard to provide ghc-paths with a GHC installation, because it would have to be built at install-time, or at least binary-patched. So I think we decided it was easiest to just let the user install it with cabal-install later. Cheers, Simon From igloo at earth.li Tue Sep 30 11:42:38 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 30 11:39:25 2008 Subject: ghc-path In-Reply-To: <48E243DB.7010803@gmail.com> References: <8b02d2150809281353w64b93736te2a00cca43ebd197@mail.gmail.com> <48E243DB.7010803@gmail.com> Message-ID: <20080930154238.GA11411@matrix.chaos.earth.li> On Tue, Sep 30, 2008 at 04:20:59PM +0100, Simon Marlow wrote: > Claus Reinke wrote: > >>Thank you all. Everything is great now. It was because (Just ghcPath) was > >>not passed into runGhc, and lack of ghc-path. > > > >btw: is ghc-path going to be part of the ghc release or the haskell > >platform? Currently, I can't see it in either, which > >would be a pity. I thought the idea was to provide it in the > >ghc release, but not install it (since cabal install isn't going to be > >part of the ghc release after all). > > I don't think we use ghc-paths in GHC's Haddock now (Ian - correct me if > I'm wrong). You are right. Thanks Ian