From igloo at earth.li Wed Jul 1 07:19:17 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jul 1 07:01:50 2009 Subject: ANNOUNCE: GHC 6.10.4 Release Candidate 1 Message-ID: <20090701111917.GA2560@matrix.chaos.earth.li> We are pleased to announce the first release candidate for GHC 6.10.4: http://www.haskell.org/ghc/dist/6.10.4-rc1/ We have now fixed all the bugs that we intend to fix for 6.10.4, so if there is a bug that is important to you that hasn't been fixed in the release candidate, please let us know. The release notes are here: http://www.haskell.org/ghc/dist/6.10.4-rc1/release-6-10-4.html The directory above contains two source bundles: ghc-6.10.3.20090628-src.tar.bz2 ghc-6.10.3.20090628-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 are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team From christiaan.baaij at gmail.com Thu Jul 2 06:20:22 2009 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Thu Jul 2 06:02:56 2009 Subject: GHC API: How to determine Type.Type equality when using type operators? Message-ID: Hi all, I've been doing some work with the GHC API where I translate Haskell to VHDL, and as such I have to translate Haskell Types to VHDL Types. I store the translations in a Map as such: -- A orderable equivalent of CoreSyn's Type for use as a map key newtype OrdType = OrdType { getType :: Type.Type } instance Eq OrdType where (OrdType a) == (OrdType b) = Type.tcEqType a b instance Ord OrdType where compare (OrdType a) (OrdType b) = Type.tcCmpType a b -- A map of a Core type to the corresponding type name type TypeMap = Map.Map OrdType (AST.VHDLId, Either AST.TypeDef AST.SubtypeIn) This solution work fine for 'simple' types and ensures that the VHDL Type definitions are all unique. However, a problem rises when type operators come in to play, as Type.tcEqType does not know the 'rules' of these type operators and can thus not infer that two types are equal. Let me give some context for my problem: We use statically fixed-size vectors instead of lists, as we always want to know the static length of an array. We use a vector implementation similar to Data.Param.FSVec defined in the parameterized-data package [1], except that we use type-level integers from the tfp library [2] to define the static vector lenght. The tfp library support things like type-level multiplication, something that we use in our vector library. Now, say we have two bit vectors of length 12 defined as such: a :: Vector D12 Bit b :: Vector (D3 :*: D4) Bit The GHC type checker can infer that 'a' and 'b' are of equal type, as it knows the definitions for the ':*:' multiplication type-operator that is defined in the tfp library. Of course, the only answer Type.tcEqType can give us if we ask if the types of 'a' and 'b' are equals is False, as it does not know the context provided by the type-operator. So my question is: Is there a functions in the GHC API that I can use to check the equality of two types given the context provided by certain type operators? I have looked at the Haddock documentation, the GHC Wiki, and the GHC code itself, but have been unable to find such a function. Regards, Christiaan [1] http://hackage.haskell.org/package/parameterized-data [2] http://hackage.haskell.org/package/tfp From phercek at gmail.com Thu Jul 2 08:11:33 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jul 2 07:54:16 2009 Subject: better generation of vi ctags in ghci References: <4A38DA9C.9000505@gmail.com> Message-ID: On Wed, 17 Jun 2009 13:59:24 +0200, Peter Hercek wrote: >>> * If your code happens to have definitions on lines which happen to >>> exist more times in one source file then it may put you at an >>> incorrect location. I doubt it will ever happen but if anybody thinks >>> it is really bad we can keep the original format of vim tags too. Then >>> e.g. :ctags would generate tags with line numbers and :ctags! would >>> generate tags with search expressions. >> >> See above for other things that can go wrong with search-based tags, so >> I'd prefer to have both options. > Ok, I can add it. Generating line numbers instead of search patterns > will be quicker too. For big projects, the time difference may be > noticeable. > So what about UI? :ctags would generate tags with line numbers and > :ctags! would generate tags with search patterns? Or will we add an > argument to :ctags to specify what kind of tags we want? This option > would break ghci UI backward compatibility. Bump! Looks like nobody cares enough to respond. Do we have at least a "general agreement" of two for :ctags[!] user interface? Is "general agreement" of two and nobody caring enough to respond good enough for a merge? If nobody responds to this I'll assume there is no general agreement and I'll maintain the patch only for myself. Peter. From superwushu at gmail.com Fri Jul 3 05:23:22 2009 From: superwushu at gmail.com (Shu Wu) Date: Fri Jul 3 05:05:49 2009 Subject: How to save a haskell data structure in C? Message-ID: <5c7d4fb80907030223h3d421cb7lcc3100f4ca3ca089@mail.gmail.com> Hey, folks. I've got a problem which I've thought about for days. I need to write a program that mixes C and haskell code. And the C code controls the procedure. In C code, I want to save a complex data strcuture defined in haskell and pass it back to a haskell function at certain time. Like the following: in haskell: data A = A {...} -- very very complex data structure initA :: A initA = A {...} func :: A -> A func a = ... -- return a new 'A' in C: main { a = initA ... take some actions a = func a; ... take some other actions a = func a; ... ... } Different from most cross-language programs, this C program doesn't alter the data in haskell, just saves it and passes it on. So I'm wondering if there's some convienent way other than marshalling the data in haskell? BTW, mashalling data requires all work done in IO monad, which will change the program stucture. So I really don't want to mashal it. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090703/6c9c46e9/attachment-0001.html From Malcolm.Wallace at cs.york.ac.uk Fri Jul 3 05:47:37 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Jul 3 05:30:06 2009 Subject: How to save a haskell data structure in C? In-Reply-To: <5c7d4fb80907030223h3d421cb7lcc3100f4ca3ca089@mail.gmail.com> References: <5c7d4fb80907030223h3d421cb7lcc3100f4ca3ca089@mail.gmail.com> Message-ID: > In C code, I want to save a complex data strcuture defined in > haskell and pass it back to a haskell function at certain time. Look up "StablePtr" in Haskell's FFI spec. Regards, Malcolm From simonpj at microsoft.com Fri Jul 3 06:27:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jul 3 06:10:06 2009 Subject: GHC API: How to determine Type.Type equality when using type operators? In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C344C3FF4FB1@EA-EXMSG-C334.europe.corp.microsoft.com> I believe that you are asking about type functions. Specifically, I think what you are asking is this: How can I normalise a type, by rewriting it exhaustively using the top-level type-function definitions I think the function TcTyFuns.tcNormaliseFamInst (rather an odd name!) does this. But it's not very helpful to you because it's in the main typechecker monad. -- |Normalise the given type as far as possible with toplevel equalities. -- This results in a coercion witnessing the type equality, in addition to the -- normalised type. -- tcNormaliseFamInst :: TcType -> TcM (CoercionI, TcType) You probably wanted something like normaliseType :: FamInstEnv -> TcType -> (CoercionI, TcType) where FamInstEnv contains the top-level type-function definitions. I believe that the only use of the monad is to carry the definitions around, so it should be easy to define the former in terms of the latter, although that'd need a bit of refactoring. Manuel may know more Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Christiaan Baaij | Sent: 02 July 2009 11:20 | To: glasgow-haskell-users@haskell.org | Subject: GHC API: How to determine Type.Type equality when using type operators? | | Hi all, | | I've been doing some work with the GHC API where I translate Haskell | to VHDL, | and as such I have to translate Haskell Types to VHDL Types. I store the | translations in a Map as such: | | | -- A orderable equivalent of CoreSyn's Type for use as a map key | newtype OrdType = OrdType { getType :: Type.Type } | instance Eq OrdType where | (OrdType a) == (OrdType b) = Type.tcEqType a b | instance Ord OrdType where | compare (OrdType a) (OrdType b) = Type.tcCmpType a b | | -- A map of a Core type to the corresponding type name | type TypeMap = Map.Map OrdType (AST.VHDLId, Either AST.TypeDef | AST.SubtypeIn) | | | This solution work fine for 'simple' types and ensures that the VHDL | Type | definitions are all unique. However, a problem rises when type | operators come | in to play, as Type.tcEqType does not know the 'rules' of these type | operators | and can thus not infer that two types are equal. Let me give some | context for | my problem: | | We use statically fixed-size vectors instead of lists, as we always | want to | know the static length of an array. We use a vector implementation | similar to | Data.Param.FSVec defined in the parameterized-data package [1], except | that we | use type-level integers from the tfp library [2] to define the static | vector | lenght. The tfp library support things like type-level multiplication, | something that we use in our vector library. | | Now, say we have two bit vectors of length 12 defined as such: | | a :: Vector D12 Bit | b :: Vector (D3 :*: D4) Bit | | The GHC type checker can infer that 'a' and 'b' are of equal type, as | it knows | the definitions for the ':*:' multiplication type-operator that is | defined in | the tfp library. Of course, the only answer Type.tcEqType can give us | if we | ask if the types of 'a' and 'b' are equals is False, as it does not | know the | context provided by the type-operator. | | So my question is: | Is there a functions in the GHC API that I can use to check the | equality of | two types given the context provided by certain type operators? I have | looked | at the Haddock documentation, the GHC Wiki, and the GHC code itself, | but have | been unable to find such a function. | | Regards, | Christiaan | | | [1] http://hackage.haskell.org/package/parameterized-data | [2] http://hackage.haskell.org/package/tfp | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From christiaan.baaij at gmail.com Mon Jul 6 10:37:08 2009 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon Jul 6 10:19:29 2009 Subject: GHC API: How to determine Type.Type equality when using type operators? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C344C3FF4FB1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C344C3FF4FB1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > I believe that you are asking about type functions. Specifically, I > think what you are asking is this: > > How can I normalise a type, by rewriting it exhaustively using > the top-level type-function definitions That is indeed a better formulation of my original question > I think the function TcTyFuns.tcNormaliseFamInst (rather an odd > name!) does this. But it's not very helpful to you because it's in > the main typechecker monad. At the moment it is not such a big problem that it is in the typechecker monad, as we run some parts of our compiler in a GHC Monad, and can thus initialize a typechecker monad with the function TcRnMonad.initTc. However, at the moment I can't get to normalise the types as far as I had hoped. Here is an example of my debug output: Before normalisation: Types.Data.Num.Decimal.Literals.D4 Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Literals.D3 After normalisation: Types.Data.Num.Decimal.Digits.Dec (Types.Data.Num.Decimal.Digits.DecN Types.Data.Num.Ops.:. Types.Data.Num.Decimal.Digits.Dec4) Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Digits.Dec (Types.Data.Num.Decimal.Digits.DecN Types.Data.Num.Ops.:. Types.Data.Num.Decimal.Digits.Dec3) So, currently I can normalize the synonyms D4 and D3, but I can't normalize the type function :*:. Maybe it has something to do with how I load the module and its dependencies. Below is the code that I use to normalize a type-level integer from the tfp library, I hope it's not too much to read. normalise_tfp_int :: Type.Type -> Type.Type normalise_tfp_int ty = unsafeRunGhc $ do -- Automatically import modules for any fully qualified identifiers setDynFlag DynFlags.Opt_ImplicitImportQualified let modules = map GHC.mkModuleName ["Types.Data.Num"] nty <- normaliseType modules ty return nty normaliseType :: [Module.ModuleName] -> Type.Type -> GHC.Ghc Type.Type normaliseType modules ty = do env <- GHC.getSession nty <- HscTypes.ioMsgMaybe $ MonadUtils.liftIO $ -- Initialize the typechecker monad TcRnMonad.initTcPrintErrors env PrelNames.iNTERACTIVE $ do mapM importModule modules -- Normalize the type (_, nty) <- TcTyFuns.tcNormaliseFamInst ty return nty return nty importModule :: Module.ModuleName -> TcRnTypes.RnM () importModule mod = do let reason = Outputable.text "Hardcoded import" let pkg = Nothing -- Load the interface. iface <- LoadIface.loadSrcInterface reason mod False pkg let deps = HscTypes.mi_deps iface let orphs = HscTypes.dep_orphs deps let finsts = HscTypes.dep_finsts deps -- Load the dependencies and family instances LoadIface.loadOrphanModules orphs False LoadIface.loadOrphanModules finsts True From mechvel at botik.ru Mon Jul 6 14:12:21 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Jul 6 13:59:38 2009 Subject: 6.10.4-pre test Message-ID: <20090706181221.GA2258@scico.botik.ru> Dear GHC developers, I have tested ghc-6.10.3.20090628 on Debian Linux, i-386-kind machine. There were only two tests: 1) making from source by itself 2) making DoCon and running its test (without profiling). It looks all right. With kind regards, ----------------- Serge Mechveliani mechvel@botik.ru From igloo at earth.li Mon Jul 6 15:01:11 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jul 6 14:43:28 2009 Subject: 6.10.4-pre test In-Reply-To: <20090706181221.GA2258@scico.botik.ru> References: <20090706181221.GA2258@scico.botik.ru> Message-ID: <20090706190111.GA20353@matrix.chaos.earth.li> On Mon, Jul 06, 2009 at 10:12:21PM +0400, Serge D. Mechveliani wrote: > > I have tested ghc-6.10.3.20090628 > on Debian Linux, i-386-kind machine. > There were only two tests: > 1) making from source by itself > 2) making DoCon and running its test (without profiling). > It looks all right. Great, thanks Serge! Thanks Ian From sanzhiyan at gmail.com Wed Jul 8 07:12:17 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Wed Jul 8 06:54:31 2009 Subject: ANNOUNCE: GHC 6.10.4 Release Candidate 1 In-Reply-To: <20090701111917.GA2560@matrix.chaos.earth.li> References: <20090701111917.GA2560@matrix.chaos.earth.li> Message-ID: <8625cd9c0907080412v3eda2db4kfae8012ee970a57b@mail.gmail.com> the bug about ^C (http://hackage.haskell.org/trac/ghc/ticket/3317) doesn't look fixed to me, on amd64 linux. saizan@astarte:~/cabal$ ~/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3.20090628 saizan@astarte:~/cabal$ ~/bin/ghc --make foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... saizan@astarte:~/cabal$ ./foo ^Ca a b b ^C cat: -: Input/output error saizan@astarte:~/cabal$ where foo.hs is the code from the ticket. On Wed, Jul 1, 2009 at 1:19 PM, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 6.10.4: > > ? ?http://www.haskell.org/ghc/dist/6.10.4-rc1/ > > We have now fixed all the bugs that we intend to fix for 6.10.4, so if > there is a bug that is important to you that hasn't been fixed in the > release candidate, please let us know. The release notes are here: > > ? ?http://www.haskell.org/ghc/dist/6.10.4-rc1/release-6-10-4.html > > > The directory above contains two source bundles: > > ? ?ghc-6.10.3.20090628-src.tar.bz2 > ? ?ghc-6.10.3.20090628-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 are also installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. More may appear later. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > 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 marlowsd at gmail.com Wed Jul 8 08:57:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 08:39:28 2009 Subject: ANNOUNCE: GHC 6.10.4 Release Candidate 1 In-Reply-To: <8625cd9c0907080412v3eda2db4kfae8012ee970a57b@mail.gmail.com> References: <20090701111917.GA2560@matrix.chaos.earth.li> <8625cd9c0907080412v3eda2db4kfae8012ee970a57b@mail.gmail.com> Message-ID: <4A5497A7.5020108@gmail.com> On 08/07/2009 12:12, Andrea Vezzosi wrote: > the bug about ^C (http://hackage.haskell.org/trac/ghc/ticket/3317) > doesn't look fixed to me, on amd64 linux. > > saizan@astarte:~/cabal$ ~/bin/ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.3.20090628 > saizan@astarte:~/cabal$ ~/bin/ghc --make foo.hs > [1 of 1] Compiling Main ( foo.hs, foo.o ) > Linking foo ... > saizan@astarte:~/cabal$ ./foo > ^Ca > a > b > b > ^C > cat: -: Input/output error > > saizan@astarte:~/cabal$ > > where foo.hs is the code from the ticket. Looks like the fix was merged on 28/6, so the version you're trying doesn't have it. I just tried it with 20090702, and it seems to work there. Cheers, Simon From john at repetae.net Wed Jul 8 20:29:53 2009 From: john at repetae.net (John Meacham) Date: Wed Jul 8 20:12:03 2009 Subject: signals and GHC 6.10 Message-ID: <20090709002952.GM4430@sliver.repetae.net> I noticed that programs compiled with GHC 6.10 seem to be eating signals and exiting with an error code of 255, rather than the proper exit code for the signal that killed the process. I can understand that the GHC runtime may need to perform some cleanup on a SIGINT or other signal, but instead of doing an exit after catching it, could it be modified to restore the original handle (which may be none) and reraise the signal via kill(getpid(), sig)? This is much friendlier and standard behavior and will also ensure any chained signal handlers are run properly. (in addition to giving proper exit codes). John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From chak at cse.unsw.edu.au Thu Jul 9 08:27:20 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jul 9 08:09:33 2009 Subject: GHC API: How to determine Type.Type equality when using type operators? In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C344C3FF4FB1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Christiaan Baaij: >> I believe that you are asking about type functions. Specifically, >> I think what you are asking is this: >> >> How can I normalise a type, by rewriting it exhaustively using >> the top-level type-function definitions > > That is indeed a better formulation of my original question > >> I think the function TcTyFuns.tcNormaliseFamInst (rather an odd >> name!) does this. But it's not very helpful to you because it's in >> the main typechecker monad. > > At the moment it is not such a big problem that it is in the > typechecker > monad, as we run some parts of our compiler in a GHC Monad, and can > thus > initialize a typechecker monad with the function TcRnMonad.initTc. > > However, at the moment I can't get to normalise the types as far as I > had hoped. Here is an example of my debug output: > > Before normalisation: > Types.Data.Num.Decimal.Literals.D4 > Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Literals.D3 > > After normalisation: > Types.Data.Num.Decimal.Digits.Dec > (Types.Data.Num.Decimal.Digits.DecN > Types.Data.Num.Ops.:. Types.Data.Num.Decimal.Digits.Dec4) > Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Digits.Dec > (Types.Data.Num.Decimal.Digits.DecN > Types.Data.Num.Ops.:. > Types.Data.Num.Decimal.Digits.Dec3) > > So, currently I can normalize the synonyms D4 and D3, but I can't > normalize the type function :*:. Maybe it has something to do with > how I > load the module and its dependencies. Yes, it has something to do with module loading and the type-checker monad. It's not enough to load the modules, you also need to initialise those components of the type-checker monad that contain the environment of visible type instance declarations. The component is called tcg_fam_inst_env and you can see in the function TcRnDriver.tcRnImports how to extend it. You did well in remembering to load the orphan modules, but you also ought to call FamInst.checkFamInstConsistency to check for overlapping instances in the modules that you are loading (it's used right at the end of TcRnDriver.tcRnImports). Hope that helps a bit. Manuel From dons at galois.com Thu Jul 9 13:01:37 2009 From: dons at galois.com (Don Stewart) Date: Thu Jul 9 12:45:44 2009 Subject: signals and GHC 6.10 In-Reply-To: <20090709002952.GM4430@sliver.repetae.net> References: <20090709002952.GM4430@sliver.repetae.net> Message-ID: <20090709170137.GG28909@whirlpool.galois.com> john: > I noticed that programs compiled with GHC 6.10 seem to be eating signals > and exiting with an error code of 255, rather than the proper exit code > for the signal that killed the process. > > I can understand that the GHC runtime may need to perform some cleanup > on a SIGINT or other signal, but instead of doing an exit after catching > it, could it be modified to restore the original handle (which may be > none) and reraise the signal via kill(getpid(), sig)? This is much > friendlier and standard behavior and will also ensure any chained signal > handlers are run properly. (in addition to giving proper exit codes). Hmm. Do you have code that reproduces this? Our signal handling code seems to be running fine here, with multiple editions of 6.10.x -- Don From john at repetae.net Thu Jul 9 15:59:51 2009 From: john at repetae.net (John Meacham) Date: Thu Jul 9 15:42:02 2009 Subject: signals and GHC 6.10 In-Reply-To: <20090709170137.GG28909@whirlpool.galois.com> References: <20090709002952.GM4430@sliver.repetae.net> <20090709170137.GG28909@whirlpool.galois.com> Message-ID: <20090709195951.GN4430@sliver.repetae.net> On Thu, Jul 09, 2009 at 10:01:37AM -0700, Don Stewart wrote: > john: > > I noticed that programs compiled with GHC 6.10 seem to be eating signals > > and exiting with an error code of 255, rather than the proper exit code > > for the signal that killed the process. > > > > I can understand that the GHC runtime may need to perform some cleanup > > on a SIGINT or other signal, but instead of doing an exit after catching > > it, could it be modified to restore the original handle (which may be > > none) and reraise the signal via kill(getpid(), sig)? This is much > > friendlier and standard behavior and will also ensure any chained signal > > handlers are run properly. (in addition to giving proper exit codes). > > Hmm. Do you have code that reproduces this? > > Our signal handling code seems to be running fine here, with multiple > editions of 6.10.x Yes, you are right. ghc 6.10 appears to be doing the right thing. It was 6.8 that was odd, between the change in exceptions and my old workaround for 6.8 I got somewhat mixed up. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From g9ks157k at acme.softbase.org Fri Jul 10 05:03:00 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Jul 10 04:45:07 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <200907101103.01555.g9ks157k@acme.softbase.org> Am Samstag, 27. Juni 2009 12:44 schrieb Niklas Broberg: > Hi all, > > Following the discussion on the use of 'forall' and extensions that > use it [1], I would hereby like to propose that the > ExistentialQuantification extension is deprecated. > > My rationale is as follows. With the introduction of GADTs, we now > have two ways to write datatype declarations, the old simple way and > the GADTs way. Isn?t ExistentialQuantification more powerful than using GADTs for emulating existential quantification? To my knowledge, it is possible to use lazy patterns with existential types but not with GADTs. Best wishes, Wolfgang From phercek at gmail.com Fri Jul 10 10:31:51 2009 From: phercek at gmail.com (Peter Hercek) Date: Fri Jul 10 10:14:09 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition Message-ID: Hi, It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case it should provide bindings of the function arguments. Is it doable without bad consequences? Looks to me like it should not result in some memory leak problems though I do not have idea whether it is hard to do. The reason I want it is that if it would be available I could put a break point which never stops and only continues at the start of a function I'm interested in. Then If I later stop somewhere in the function I have a pretty good chance that the correct arguments are stored in the trace history and I could retrieve them. E.g. with my GhciExt it would be as simple as: -- to strobe function arguments :count 0 -- and to look them up later when stopped somewhere -- in the function I could just use :locate :back -- ... or for a specific argument value :find :back If you are interested GhciExt is available here: http://www.hck.sk/users/peter/pub/ But other users could do it too in a bit more complicated way (e.g. by stopping at the function start manually and then continuing and then searching the trace history manually again). Of course I can make sure the function arguments get to the history even now but in much more complicated way (by putting a non-stopping break point at each first use of each argument). The problem with this approach is that: * one must look up all the places in the source code * some of the places may not be hit before we stop at some interesting place in the function so some arguments would not be visible yet Thanks, Peter. From bulat.ziganshin at gmail.com Sat Jul 11 13:32:43 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Jul 11 13:14:54 2009 Subject: CLDouble serialization bug in 6.10.1 Message-ID: <1867675096.20090711213243@gmail.com> Hello glasgow-haskell-users, sorry, i tested it only with 6.6 and 6.10.1. testcase available as http://www.haskell.org/bz/ldouble-bug.zip it's as simple as > foreign import ccall unsafe "" > client :: Ptr CLDouble -> IO () > > main = with 1.0 client and > void client(long double *p) > { > printf ("%f\n",(double)(*p)); > } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sun Jul 12 09:34:06 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Jul 12 09:26:05 2009 Subject: CLDouble serialization bug in 6.10.1 In-Reply-To: <1867675096.20090711213243@gmail.com> References: <1867675096.20090711213243@gmail.com> Message-ID: <13010399567.20090712173406@gmail.com> Hello Bulat, Saturday, July 11, 2009, 9:32:43 PM, you wrote: Error remains in 6.10.3 (mingw) version i also got stack trace from Trac trying to report this problem :))) > sorry, i tested it only with 6.6 and 6.10.1. testcase available as > http://www.haskell.org/bz/ldouble-bug.zip > it's as simple as >> foreign import ccall unsafe "" >> client :: Ptr CLDouble -> IO () >> >> main = with 1.0 client > and >> void client(long double *p) >> { >> printf ("%f\n",(double)(*p)); >> } -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dgorin at dc.uba.ar Sun Jul 12 11:49:15 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Sun Jul 12 11:31:24 2009 Subject: Using the ghc-api to run more than one instance of ghc simultaneously Message-ID: Hi I'm trying to use the GHC API to have several instances of GHC's interpreter loaded simultaneously; each with its own loaded modules, etc. However, this doesn't seem to work well when two instances have loaded modules with the same name. I'm including the code of a small(ish) example of this at the end of the message. The example launches two threads (with forkIO) and fires GHC in interpreted mode on each thread (with GHC.runGhc); then it sequentially loads file TestMain1.hs in the first and TestMain2.hs in the second one and finally tries to evaluate expression test1 defined in the first one followed by test2 defined in the second one. The output is: #./Main 1: Load succeded 2: Load succeded 3: (1,2,3) 4: Main: During interactive linking, GHCi couldn't find the following symbol: Main_test1_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org Main: thread blocked indefinitely # The "thread blocked indefinitely" message is not important (comes from simplifying the original example). I tried this both in ghc 6.10.1 and ghc 6.11.20090607 with the same results. Is this a known limitation? Or should I be doing it some other way? Thanks, Daniel {-# LANGUAGE MagicHash #-} module Main where import Prelude hiding ( init ) import Control.Monad ( join, forever ) import Control.Concurrent ( forkIO ) import Control.Concurrent.Chan import GHC ( Ghc ) import qualified GHC import qualified MonadUtils as GHC import qualified GHC.Paths import qualified GHC.Exts main :: IO () main = do let test1 = "TestMain1.hs" let test2 = "TestMain2.hs" writeFile test1 "module Main where test1 = (1,2,3)" writeFile test2 "module Main where test1 = (3,2,1)" -- ghc_1 <- newGhcServer ghc_2 <- newGhcServer line "1" $ runInServer ghc_1 $ load (test1, "Main") line "2" $ runInServer ghc_2 $ load (test2, "Main") line "3" $ runInServer ghc_1 $ eval "test1" line "4" $ runInServer ghc_2 $ eval "test1" where line n a = putStr (n ++ ": ") >> a type ModuleName = String type GhcServerHandle = Chan (Ghc ()) newGhcServer :: IO GhcServerHandle newGhcServer = do pChan <- newChan let be_a_server = forever $ join (GHC.liftIO $ readChan pChan) forkIO $ ghc be_a_server return pChan where ghc action = GHC.runGhc (Just GHC.Paths.libdir) (init >> action) init = do df <- GHC.getSessionDynFlags GHC.setSessionDynFlags df{GHC.ghcMode = GHC.CompManager, GHC.hscTarget = GHC.HscInterpreted, GHC.ghcLink = GHC.LinkInMemory, GHC.verbosity = 0} runInServer :: GhcServerHandle -> Ghc a -> IO a runInServer h action = do me <- newChan writeChan h $ action >>= (GHC.liftIO . writeChan me) readChan me load :: (FilePath,ModuleName) -> Ghc () load (f,mn) = do target <- GHC.guessTarget f Nothing GHC.setTargets [target] res <- GHC.load GHC.LoadAllTargets GHC.liftIO $ putStrLn ("Load " ++ showSuccessFlag res) -- m <- GHC.findModule (GHC.mkModuleName mn) Nothing GHC.setContext [m] [] where showSuccessFlag GHC.Succeeded = "succeded" showSuccessFlag GHC.Failed = "failed" eval :: String -> Ghc () eval e = do show_e <- GHC.compileExpr $ "(show ("++ e ++")) :: String" GHC.liftIO $ putStrLn (GHC.Exts.unsafeCoerce# show_e) From marco-oweber at gmx.de Sun Jul 12 12:14:09 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jul 12 11:56:10 2009 Subject: Using the ghc-api to run more than one instance of ghc simultaneously In-Reply-To: References: Message-ID: <20090712161409.GA22007@gmx.de> On Sun, Jul 12, 2009 at 05:49:15PM +0200, Daniel Gor?n wrote: > Hi > > I'm trying to use the GHC API to have several instances of GHC's > interpreter loaded simultaneously; [snip] Is this possible now? 6-12 month ago it was not possible to run multiple ghc threads within the same instance due to some global state IORefs or such. But I'd appreciate hearing that this changed recently. My knowledge can be outdated. Sincerly Marc Weber From bulat.ziganshin at gmail.com Sun Jul 12 15:22:13 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Jul 12 15:04:22 2009 Subject: CLDouble serialization bug in 6.10.1 In-Reply-To: <20090712191800.GA21785@linode.davidb.org> References: <1867675096.20090711213243@gmail.com> <20090712191800.GA21785@linode.davidb.org> Message-ID: <1333265695.20090712232213@gmail.com> Hello David, Sunday, July 12, 2009, 11:18:00 PM, you wrote: >>> foreign import ccall unsafe "" >>> client :: Ptr CLDouble -> IO () > The source suggests the CLDouble isn't implemented, and it just uses a > Double. This probably worked when compiling via-C and including > proper prototypes (the C compiler coerced the value). Since that > isn't done any more, it now incorrectly passes the regular double. i think the same about double. but it not worked either in 6.6.1, even with explicit -fvia-C option -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Mon Jul 13 06:24:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 13 06:06:46 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition In-Reply-To: References: Message-ID: <4A5B0B70.6010408@gmail.com> On 10/07/2009 15:31, Peter Hercek wrote: > Hi, > > It would be cool if ghci debugger could grab not only the free variables > in the selected expression but in one case a bit more. The case is when > we stop at a function definition the first time (when just entering it). > In this case it should provide bindings of the function arguments. Is it > doable without bad consequences? Looks to me like it should not result in > some memory leak problems though I do not have idea whether it is hard to > do. The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in f x 0 = x f 0 x = x when we stop at f, what do you want to see? I think the current policy is to stop at the outer level (no bindings), and the next breakpoint is on the right-hand side of the equation taken, with the appropriate free variables bound. I suppose you could use a scheme whereby the bindings are named if there is only one equation, or otherwise use "_arg1" "_arg2", etc. Cheers, Simon From marlowsd at gmail.com Mon Jul 13 06:30:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 13 06:12:25 2009 Subject: Using the ghc-api to run more than one instance of ghc simultaneously In-Reply-To: References: Message-ID: <4A5B0CC3.6010509@gmail.com> On 12/07/2009 16:49, Daniel Gor?n wrote: > Hi > > I'm trying to use the GHC API to have several instances of GHC's > interpreter loaded simultaneously; each with its own loaded modules, > etc. However, this doesn't seem to work well when two instances have > loaded modules with the same name. I'm including the code of a > small(ish) example of this at the end of the message. > > The example launches two threads (with forkIO) and fires GHC in > interpreted mode on each thread (with GHC.runGhc); then it sequentially > loads file TestMain1.hs in the first and TestMain2.hs in the second one > and finally tries to evaluate expression test1 defined in the first one > followed by test2 defined in the second one. The output is: > > #./Main > 1: Load succeded > 2: Load succeded > 3: (1,2,3) > 4: Main: > During interactive linking, GHCi couldn't find the following symbol: > Main_test1_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi. > If you suspect the latter, please send a bug report to: > glasgow-haskell-bugs@haskell.org > > Main: thread blocked indefinitely > # > > The "thread blocked indefinitely" message is not important (comes from > simplifying the original example). I tried this both in ghc 6.10.1 and > ghc 6.11.20090607 with the same results. > > Is this a known limitation? Or should I be doing it some other way? Yes, it is a known limitation. It ought to be documented somewhere. There are two problems: 1. GHC is not thread-safe. There are some items of global state (the NameCache and the PackageInterfaceTable) that should be protected. It's not a trivial matter to do this - we had a hacky solution for the parallel compilation experiment we did a while back, but it wasn't finished. You could workaround this by using a mutex and only invoking GHC API operations in one thread at a time. 2. There is only one RTS linker with a single symbol table. This is the problem you ran into. There's no workaround that I'm aware of. Cheers, Simon From Christian.Maeder at dfki.de Mon Jul 13 11:38:51 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jul 13 11:20:53 2009 Subject: ANNOUNCE: GHC 6.10.4 Release Candidate 1 In-Reply-To: <20090701111917.GA2560@matrix.chaos.earth.li> References: <20090701111917.GA2560@matrix.chaos.earth.li> Message-ID: <4A5B550B.8090206@dfki.de> Ian Lynagh wrote: > We are pleased to announce the first release candidate for GHC 6.10.4: > > http://www.haskell.org/ghc/dist/6.10.4-rc1/ Worked like a charm for me under x86 Solaris. Cheers Christian From marco-oweber at gmx.de Mon Jul 13 16:53:31 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Jul 13 16:35:29 2009 Subject: Using the ghc-api to run more than one instance of ghc simultaneously In-Reply-To: <4A5B0CC3.6010509@gmail.com> References: <4A5B0CC3.6010509@gmail.com> Message-ID: <1247518345-sup-567@nixos> > Yes, it is a known limitation. It ought to be documented somewhere. > > There are two problems: > > 1. GHC is not thread-safe. There are some items of global state (the > NameCache and the PackageInterfaceTable) that should be protected. > It's not a trivial matter to do this - we had a hacky solution for > the parallel compilation experiment we did a while back, but it > wasn't finished. > > You could workaround this by using a mutex and only invoking GHC > API operations in one thread at a time. > > 2. There is only one RTS linker with a single symbol table. This is > the problem you ran into. There's no workaround that I'm aware > of. Are there already bug tracker items for these two problems? I've tried finding them but didn't succeed. This would be a fast way to document this issue even if its unlikely to be fixed soon. Marc Weber From phercek at gmail.com Mon Jul 13 19:04:52 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Jul 13 18:54:47 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition In-Reply-To: <4A5B0B70.6010408@gmail.com> References: <4A5B0B70.6010408@gmail.com> Message-ID: <4A5BBD94.7020304@gmail.com> Simon Marlow wrote: > On 10/07/2009 15:31, Peter Hercek wrote: >> Hi, >> >> It would be cool if ghci debugger could grab not only the free variables >> in the selected expression but in one case a bit more. The case is when >> we stop at a function definition the first time (when just entering it). > > The problem is that functions can be defined with multiple equations, > each giving different names for the arguments. e.g. in > > f x 0 = x > f 0 x = x > > when we stop at f, what do you want to see? Right, I did not realize this problem. But your idea of using _arx naming in case of more equations seems best to me. I would still like to have it available. So it looks doable without bad consequences. Now, the question is: Is there any support for it except me? Thanks, Peter. From ml at isaac.cedarswampstudios.org Mon Jul 13 20:48:42 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Jul 13 20:30:47 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition In-Reply-To: <4A5BBD94.7020304@gmail.com> References: <4A5B0B70.6010408@gmail.com> <4A5BBD94.7020304@gmail.com> Message-ID: <4A5BD5EA.3050904@isaac.cedarswampstudios.org> Peter Hercek wrote: > Simon Marlow wrote: >> On 10/07/2009 15:31, Peter Hercek wrote: >>> Hi, >>> >>> It would be cool if ghci debugger could grab not only the free variables >>> in the selected expression but in one case a bit more. The case is when >>> we stop at a function definition the first time (when just entering it). >> >> The problem is that functions can be defined with multiple equations, >> each giving different names for the arguments. e.g. in >> >> f x 0 = x >> f 0 x = x >> >> when we stop at f, what do you want to see? > > Right, I did not realize this problem. But your idea of using _arx > naming in case of more equations seems best to me. I would still like to > have it available. Even in one equation, pattern match can make it undesirable. Say, in fromJust (Just x) = ... doesn't allow you access to the argument directly. Can _argN be provided in *all* cases (possibly in addition to other bindings)? -Isaac From gwright at comcast.net Tue Jul 14 02:13:35 2009 From: gwright at comcast.net (Gregory Wright) Date: Tue Jul 14 01:55:30 2009 Subject: ANNOUNCE: GHC 6.10.4 Release Candidate 1 Message-ID: <4A5C220F.6080207@comcast.net> Good rc1 build on OS X 10.5.7 (Leopard/intel). Couldn't run the 6.10.3 testsuite all the way through. Failed with things like =====> getGroupEntryForName(normal) cd ../../../libraries/unix/tests && '/opt/local/var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-beta/work/ghc-6.10.3.20090628/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o getGroupEntryForName getGroupEntryForName.hs -package unix >getGroupEntryForName.comp.stderr 2>&1 cd ../../../libraries/unix/tests && ./getGroupEntryForName getGroupEntryForName.run.stdout 2>getGroupEntryForName.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: getGroupEntryForName: thisIsNotMeantToExist: getGroupEntryForName: does not exist (no group name) Should I be running a different version of the tests? Best Wishes, Greg -- Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 USA gwright@antiope.com +1 (732) 924-4549 +1 (732) 345-8378 [fax] From marlowsd at gmail.com Tue Jul 14 04:24:03 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 14 04:05:58 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition In-Reply-To: <4A5BBD94.7020304@gmail.com> References: <4A5B0B70.6010408@gmail.com> <4A5BBD94.7020304@gmail.com> Message-ID: <4A5C40A3.2020803@gmail.com> Peter Hercek wrote: > Simon Marlow wrote: >> On 10/07/2009 15:31, Peter Hercek wrote: >>> Hi, >>> >>> It would be cool if ghci debugger could grab not only the free variables >>> in the selected expression but in one case a bit more. The case is when >>> we stop at a function definition the first time (when just entering it). >> >> The problem is that functions can be defined with multiple equations, >> each giving different names for the arguments. e.g. in >> >> f x 0 = x >> f 0 x = x >> >> when we stop at f, what do you want to see? > > Right, I did not realize this problem. But your idea of using _arx > naming in case of more equations seems best to me. I would still like to > have it available. > > So it looks doable without bad consequences. Now, the question is: Is > there any support for it except me? No objections here. Cheers, Simon From dominic at steinitz.org Tue Jul 14 05:08:46 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Tue Jul 14 16:21:59 2009 Subject: HPC gives spurious results if sources are compiled with -cpp Message-ID: Trac doesn't seem to work for us so I'm sending this bug report by email. ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ghc.exe -fhpc -cpp --make CommonHPC.hs -o CommonHPC commonHPC hpc markup CommonHPC --fun-entry-count This gives no entry counts for fact in Common.hs. With more complex modules, you get spurious red, yellow and green over expressions. Dominic. CommonHPC.hs: module Main (main) where import Common main = do test test test = do putStrLn $ show $ fact 4 putStrLn $ show $ fact 5 Common.hs: module Common ( fact ) where fact 0 = 1 fact n = n * fact (n-1) From dgorin at dc.uba.ar Tue Jul 14 18:33:30 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Jul 14 18:15:31 2009 Subject: Using the ghc-api to run more than one instance of ghc simultaneously In-Reply-To: <1247518345-sup-567@nixos> References: <4A5B0CC3.6010509@gmail.com> <1247518345-sup-567@nixos> Message-ID: <969F900C-D1F7-4258-803C-D83FC5921996@dc.uba.ar> On Jul 13, 2009, at 10:53 PM, Marc Weber wrote: >> Yes, it is a known limitation. It ought to be documented somewhere. >> >> There are two problems: >> >> 1. GHC is not thread-safe. [...] >> >> 2. There is only one RTS linker with a single symbol table. [...] > > Are there already bug tracker items for these two problems? > I've tried finding them but didn't succeed. This would be a fast way > to > document this issue even if its unlikely to be fixed soon. > > Marc Weber For the record, now there are: http://hackage.haskell.org/trac/ghc/ticket/3372 http://hackage.haskell.org/trac/ghc/ticket/3373 Daniel From kazu at iij.ad.jp Tue Jul 14 21:48:11 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue Jul 14 21:30:16 2009 Subject: buildFdSets: file descriptor out of range Message-ID: <20090715.104811.88104602.kazu@iij.ad.jp> Hello, If this is not a right place to ask this question, please tell me another place to ask. I'm developing a mail server with GHC 6.10.3 on Linux. The server is running well at the beginning. But after several hours, it receives an error, "buildFdSets: file descriptor out of range". Please tell me what happened? And please suggest me how to fix this problem. Here is brief description of the server. - linked with ADNS. - complied with the -threaded option since ADNS requires it. - uses forkIO to produce threads. - does not use "deamonize" of System.Posix.Daemonize since it uses forkProcess. I execute my server as foreground process. - Because there are so many nasty SMTP clients, most SMTP connections are time out. Handles of the SMTP connections disappear, so I cannot use "hClose" to close the handles. - pushes the limit of file descriptors to 65536 with setResourceLimit. --Kazu From allbery at ece.cmu.edu Wed Jul 15 00:16:21 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jul 14 23:58:31 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <20090715.104811.88104602.kazu@iij.ad.jp> References: <20090715.104811.88104602.kazu@iij.ad.jp> Message-ID: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> On Jul 14, 2009, at 21:48 , Kazu Yamamoto (????) wrote: > running well at the beginning. But after several hours, it receives an > error, "buildFdSets: file descriptor out of range". I believe the runtime uses select(), which has a hard limit (enforced by the kernel) that the maximum file descriptor id be 1023. (select() uses bitmasks and there is a limit on the size of a bitmask; see FD_SETSIZE.) > - pushes the limit of file descriptors to 65536 with setResourceLimit. Reduce this to 1024, otherwise the runtime will eventually find itself dealing with file descriptors beyond the select() limit mentioned above. Someone with more knowledge of the Haskell runtime will have to advise as to possible ways around it if you really need more than 1024 file descriptors. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090714/4c1027cb/PGP.bin From kazu at iij.ad.jp Wed Jul 15 00:42:43 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed Jul 15 00:24:40 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> Message-ID: <20090715.134243.264074179.kazu@iij.ad.jp> > I believe the runtime uses select(), which has a hard limit (enforced > by the kernel) that the maximum file descriptor id be 1023. (select() > uses bitmasks and there is a limit on the size of a bitmask; see > FD_SETSIZE.) I understand. Thank you. > Reduce this to 1024, otherwise the runtime will eventually find itself > dealing with file descriptors beyond the select() limit mentioned > above. Someone with more knowledge of the Haskell runtime will have > to advise as to possible ways around it if you really need more than > 1024 file descriptors. I used to execute my server with the limit of 1024 since this is the default limit of my machine. At that time, I suffered from the following errors: rpf: user error (Cannot create OS thread.) rpf: accept: resource exhausted (Too many open files) So, I pushed the limit to 65536. I don't believe my server receives 1024 connections at once. So, I guess file descriptors leak. Does anyone know what happens when a TCP connection is reset by the peer and its handle disappears. Does the file descriptor bound to the handle leak? --Kazu From allbery at ece.cmu.edu Wed Jul 15 02:12:59 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jul 15 01:55:06 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <20090715.134243.264074179.kazu@iij.ad.jp> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <20090715.134243.264074179.kazu@iij.ad.jp> Message-ID: <092309DC-52D3-4A37-B010-C4C1757A092F@ece.cmu.edu> On Jul 15, 2009, at 00:42 , Kazu Yamamoto (????) wrote: > I don't believe my server receives 1024 connections at once. So, I > guess > file descriptors leak. IIRC finalization of file handles is delayed, so there is effectively a leak in the runtime where unused file descriptors don't get freed until the Handle itself is garbage collected due to memory (i.e. the runtime makes no attempt to collect unreferenced file handles per se). -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090715/f6af3d72/PGP.bin From phercek at gmail.com Wed Jul 15 03:09:59 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Jul 15 02:52:05 2009 Subject: ghci debugger: showing function argumetns when stopped at its definition References: <4A5B0B70.6010408@gmail.com> <4A5BBD94.7020304@gmail.com> <4A5BD5EA.3050904@isaac.cedarswampstudios.org> Message-ID: On Mon, 13 Jul 2009 20:48:42 -0400, Isaac Dupree wrote: > Peter Hercek wrote: >> Simon Marlow wrote: >>> On 10/07/2009 15:31, Peter Hercek wrote: >>>> It would be cool if ghci debugger could grab not only the free >>>> variables in the selected expression but in one case a bit more. The >>>> case is when we stop at a function definition the first time (when >>>> just entering it). >>> >>> The problem is that functions can be defined with multiple equations, >>> each giving different names for the arguments. e.g. in >>> >>> f x 0 = x >>> f 0 x = x >>> >>> when we stop at f, what do you want to see? >> >> Right, I did not realize this problem. But your idea of using _arx >> naming in case of more equations seems best to me. I would still like >> to have it available. > > Even in one equation, pattern match can make it undesirable. Say, in > fromJust (Just x) = ... > doesn't allow you access to the argument directly. Can _argN be > provided in *all* cases (possibly in addition to other bindings)? I was thinking about adding _argN always too. If it is done in addition to other binding (which are not ambiguous) then even better. Regardless I'm fine with any solution which allows me to access arguments more easily (i.e. without tracing on (to manually search for call site) or without trying to mark all first usages). Peter. From marlowsd at gmail.com Wed Jul 15 08:36:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 15 08:18:21 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: References: Message-ID: <4A5DCD4C.9030905@gmail.com> On 14/07/2009 10:08, Dominic Steinitz wrote: > Trac doesn't seem to work for us so I'm sending this bug report by email. What's the symptom? Cheers, Simon From marlowsd at gmail.com Wed Jul 15 08:55:25 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 15 08:37:17 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> Message-ID: <4A5DD1BD.5010705@gmail.com> On 15/07/2009 05:16, Brandon S. Allbery KF8NH wrote: > On Jul 14, 2009, at 21:48 , Kazu Yamamoto (????) wrote: >> running well at the beginning. But after several hours, it receives an >> error, "buildFdSets: file descriptor out of range". > > I believe the runtime uses select(), which has a hard limit (enforced by > the kernel) that the maximum file descriptor id be 1023. (select() uses > bitmasks and there is a limit on the size of a bitmask; see FD_SETSIZE.) Strictly speaking it's the IO library, not the runtime, that calls select() when you're using -threaded. But otherwise that's all correct. >> - pushes the limit of file descriptors to 65536 with setResourceLimit. > > > Reduce this to 1024, otherwise the runtime will eventually find itself > dealing with file descriptors beyond the select() limit mentioned above. > Someone with more knowledge of the Haskell runtime will have to advise > as to possible ways around it if you really need more than 1024 file > descriptors. There's no easy workaround. We could have the IO library switch to using blocking read() calls for the out-of-range FDs to avoid the error from the IO manager, but that is likely to lead to a different problem: too many OS threads. The right fix is to move to using epoll() instead. I understand it is being worked on, but I don't know the current status (Johan?). Cheers, Simon From bulat.ziganshin at gmail.com Wed Jul 15 08:59:27 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 15 08:49:14 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: <4A5DCD4C.9030905@gmail.com> References: <4A5DCD4C.9030905@gmail.com> Message-ID: <1555448794.20090715165927@gmail.com> Hello Simon, Wednesday, July 15, 2009, 4:36:28 PM, you wrote: >> Trac doesn't seem to work for us so I'm sending this bug report by email. > What's the symptom? i filled bugreport few days ago and when i hit send it was crashdumped -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Wed Jul 15 11:44:48 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jul 15 11:26:58 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <4A5DD1BD.5010705@gmail.com> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> Message-ID: <90889fe70907150844l564fc72eyf10a1bd33176607b@mail.gmail.com> 2009/7/15 Simon Marlow > On 15/07/2009 05:16, Brandon S. Allbery KF8NH wrote: > > Reduce this to 1024, otherwise the runtime will eventually find itself >> dealing with file descriptors beyond the select() limit mentioned above. >> Someone with more knowledge of the Haskell runtime will have to advise >> as to possible ways around it if you really need more than 1024 file >> descriptors. >> > > There's no easy workaround. We could have the IO library switch to using > blocking read() calls for the out-of-range FDs to avoid the error from the > IO manager, but that is likely to lead to a different problem: too many OS > threads. > > The right fix is to move to using epoll() instead. I understand it is > being worked on, but I don't know the current status (Johan?). > I have a standalone (i.e. not integrated into the RTS yet) proof of concept working using kqueue. However, to be portable we still need to fall back to select on systems that don't support anything better. This implies that if you want to write portable code you still suffer from this limit. I've been unable to hack lately due to an injury but I'll be able to get back to it next week. - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090715/2a20cdef/attachment.html From dominic at steinitz.org Wed Jul 15 12:05:14 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Wed Jul 15 11:47:21 2009 Subject: HPC gives spurious results if sources are compiled with -cpp References: <4A5DCD4C.9030905@gmail.com> Message-ID: Simon Marlow gmail.com> writes: > > On 14/07/2009 10:08, Dominic Steinitz wrote: > > Trac doesn't seem to work for us so I'm sending this bug report by email. > > What's the symptom? > > Cheers, > Simon > I hit "New Bug" and get TICKET_CREATE privileges are required to perform this operation If I then hit "login" I get a Create New Ticket screen. I then fill in the details and hit submit and I get TICKET_CREATE privileges are required to perform this operation and all my details are lost :-( From kazu at iij.ad.jp Thu Jul 16 01:53:48 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu Jul 16 01:35:44 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <4A5DD1BD.5010705@gmail.com> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> Message-ID: <20090716.145348.44123669.kazu@iij.ad.jp> Hello, >> Reduce this to 1024, otherwise the runtime will eventually find itself >> dealing with file descriptors beyond the select() limit mentioned >> above. >> Someone with more knowledge of the Haskell runtime will have to advise >> as to possible ways around it if you really need more than 1024 file >> descriptors. > > There's no easy workaround. We could have the IO library switch to > using blocking read() calls for the out-of-range FDs to avoid the > error from the IO manager, but that is likely to lead to a different > problem: too many OS threads. Thank you for reply. I changed forkIO to forkOS. But I received the following error. ERRORCannot create OS thread. I want to decrease the stack size of threads to increase the number of threads to be created. How can I do this? I tried to decrease ResourceStackSize and tried the RTS -k option but both does not increase the number of threads... --Kazu From kazu at iij.ad.jp Thu Jul 16 02:01:04 2009 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu Jul 16 01:42:57 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <90889fe70907150844l564fc72eyf10a1bd33176607b@mail.gmail.com> References: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> <90889fe70907150844l564fc72eyf10a1bd33176607b@mail.gmail.com> Message-ID: <20090716.150104.93373914.kazu@iij.ad.jp> Hello, > I have a standalone (i.e. not integrated into the RTS yet) proof of concept > working using kqueue. However, to be portable we still need to fall back to > select on systems that don't support anything better. This implies that if you > want to write portable code you still suffer from this limit. If portability is important, how about falling back to poll(), not epoll()? > I've been unable to hack lately due to an injury but I'll be able to get back > to it next week. Take care. --Kazu From johan.tibell at gmail.com Thu Jul 16 03:32:25 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jul 16 03:14:36 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <20090716.150104.93373914.kazu@iij.ad.jp> References: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> <90889fe70907150844l564fc72eyf10a1bd33176607b@mail.gmail.com> <20090716.150104.93373914.kazu@iij.ad.jp> Message-ID: <90889fe70907160032o2d5a1711w7b3c28a7d57b1777@mail.gmail.com> 2009/7/16 Kazu Yamamoto > Hello, > > > I have a standalone (i.e. not integrated into the RTS yet) proof of > concept > > working using kqueue. However, to be portable we still need to fall back > to > > select on systems that don't support anything better. This implies that > if you > > want to write portable code you still suffer from this limit. > > If portability is important, how about falling back to poll(), not > epoll()? > We could provide poll as a possible backend but I don't think it's available on Windows. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090716/684ee315/attachment.html From marlowsd at gmail.com Thu Jul 16 05:33:26 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 16 05:15:16 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <20090716.145348.44123669.kazu@iij.ad.jp> References: <20090715.104811.88104602.kazu@iij.ad.jp> <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> <20090716.145348.44123669.kazu@iij.ad.jp> Message-ID: <4A5EF3E6.3000809@gmail.com> On 16/07/2009 06:53, Kazu Yamamoto (????) wrote: > Hello, > >>> Reduce this to 1024, otherwise the runtime will eventually find itself >>> dealing with file descriptors beyond the select() limit mentioned >>> above. >>> Someone with more knowledge of the Haskell runtime will have to advise >>> as to possible ways around it if you really need more than 1024 file >>> descriptors. >> There's no easy workaround. We could have the IO library switch to >> using blocking read() calls for the out-of-range FDs to avoid the >> error from the IO manager, but that is likely to lead to a different >> problem: too many OS threads. > > Thank you for reply. > > I changed forkIO to forkOS. But I received the following error. > > ERRORCannot create OS thread. I don't think forkOS is going to help you here. The IO library is still using select(), all you're doing is making more OS threads. We could do blocking read() for a bound thread. That would make some sense, but we don't do it at the moment, and it does add an extra test to the code. > I want to decrease the stack size of threads to increase the number of > threads to be created. How can I do this? That's an OS issue, I'm not sure. Cheers, Simon From allbery at ece.cmu.edu Thu Jul 16 09:47:23 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jul 16 09:29:39 2009 Subject: buildFdSets: file descriptor out of range In-Reply-To: <90889fe70907160032o2d5a1711w7b3c28a7d57b1777@mail.gmail.com> References: <950EE52E-AF78-450A-96F7-F86387AD7A16@ece.cmu.edu> <4A5DD1BD.5010705@gmail.com> <90889fe70907150844l564fc72eyf10a1bd33176607b@mail.gmail.com> <20090716.150104.93373914.kazu@iij.ad.jp> <90889fe70907160032o2d5a1711w7b3c28a7d57b1777@mail.gmail.com> Message-ID: <2AB836E6-D323-432F-AB03-267696FD09EC@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090716/e298096a/PGP.bin From igloo at earth.li Thu Jul 16 10:42:10 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 16 10:23:57 2009 Subject: ANNOUNCE: GHC version 6.10.4 Message-ID: <20090716144210.GA23789@matrix.chaos.earth.li> ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.10.3, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.4/html/users_guide/release-6-10-4.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug From igloo at earth.li Thu Jul 16 12:26:40 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 16 12:08:27 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: References: Message-ID: <20090716162640.GA26184@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 09:08:46AM +0000, Dominic Steinitz wrote: > > ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.1 > > ghc.exe -fhpc -cpp --make CommonHPC.hs -o CommonHPC > > commonHPC > > hpc markup CommonHPC --fun-entry-count > > This gives no entry counts for fact in Common.hs. Thanks for the report; I've filed it here: http://hackage.haskell.org/trac/ghc/ticket/3376 Thanks Ian From igloo at earth.li Thu Jul 16 12:28:29 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 16 12:10:15 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: <1555448794.20090715165927@gmail.com> References: <4A5DCD4C.9030905@gmail.com> <1555448794.20090715165927@gmail.com> Message-ID: <20090716162829.GB26184@matrix.chaos.earth.li> On Wed, Jul 15, 2009 at 04:59:27PM +0400, Bulat Ziganshin wrote: > Hello Simon, > > Wednesday, July 15, 2009, 4:36:28 PM, you wrote: > > >> Trac doesn't seem to work for us so I'm sending this bug report by email. > > > What's the symptom? > > i filled bugreport few days ago and when i hit send it was crashdumped If it gives a stacktrace and says "The database was locked" or something, then if you wait a couple of seconds and "reload" (say yes to the "are you sure you want to resend the data" questions) then it'll probably work. Thanks Ian From gale at sefer.org Thu Jul 16 12:29:58 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jul 16 12:12:04 2009 Subject: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090716144210.GA23789@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> Message-ID: <2608b8a80907160929i4d83e27cu59a3b42f97a4cc9@mail.gmail.com> > ? ?The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 > How to get it > ? ? ? ?http://www.haskell.org/ghc/ I have a few comments about the "Distribution Packages" page that is linked from there: http://www.haskell.org/ghc/distribution_packages.html Debian: Remove the line "Newer packages may be available in Haskell Unsafe." That stuff is very, very old. Mac OS X: Paragraph beginning "Contrary to the recommendation at the top of this page... rather than using the alternatives below." It makes no sense. It appears to be referring to an older version of the page. "Both 10.3 (Panther) and 10.4 (Tiger) are supported." should be changed to 10.4 (Tiger) and 10.5 (Leopard). The paragraph about the ghc-devel port should be removed, I think. The port still exists, but it doesn't seem to be actively supported since 6.7. Anyone who wants to use GHC HEAD will probably just build current HEAD manually. (Greg - is this correct?) Thanks, Yitz From igloo at earth.li Thu Jul 16 12:35:48 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 16 12:17:35 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: References: <4A5DCD4C.9030905@gmail.com> Message-ID: <20090716163548.GC26184@matrix.chaos.earth.li> On Wed, Jul 15, 2009 at 04:05:14PM +0000, Dominic Steinitz wrote: > Simon Marlow gmail.com> writes: > > > > > On 14/07/2009 10:08, Dominic Steinitz wrote: > > > Trac doesn't seem to work for us so I'm sending this bug report by email. > > > > What's the symptom? > > > > Cheers, > > Simon > > > I hit "New Bug" and get > > TICKET_CREATE privileges are required to perform this operation > > If I then hit "login" I get a Create New Ticket screen. > > I then fill in the details and hit submit and I get > > TICKET_CREATE privileges are required to perform this operation > > and all my details are lost :-( I've explicitly added "dominic" and "Dominic" to group "user", but I don't think that should be necessary. If that doesn't fix it then my guess would be that you have some sort of firewall or HTTP proxy that is fiddling with the cookie data. When you log in, does trac say "logged in as ...", or does it still look like you are not logged in? Thanks Ian From igloo at earth.li Fri Jul 17 13:26:00 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 17 13:07:46 2009 Subject: CLDouble serialization bug in 6.10.1 In-Reply-To: <1867675096.20090711213243@gmail.com> References: <1867675096.20090711213243@gmail.com> Message-ID: <20090717172600.GA28127@matrix.chaos.earth.li> Hi Bulat, On Sat, Jul 11, 2009 at 09:32:43PM +0400, Bulat Ziganshin wrote: > > > foreign import ccall unsafe "" > > client :: Ptr CLDouble -> IO () I'm afraid GHC has never supported CLDouble properly. It's been removed from the HEAD: http://hackage.haskell.org/trac/ghc/ticket/2793 and there's a ticket to add proper support: http://hackage.haskell.org/trac/ghc/ticket/3353 If it's important to you, please add a note to the ticket. Thanks Ian From jeff at renci.org Fri Jul 17 13:58:49 2009 From: jeff at renci.org (Jeff Heard) Date: Fri Jul 17 13:40:53 2009 Subject: CLDouble serialization bug in 6.10.1 In-Reply-To: <4165d3a70907171057h3a090ae1qc38e012d7d508af3@mail.gmail.com> References: <1867675096.20090711213243@gmail.com> <20090717172600.GA28127@matrix.chaos.earth.li> <4165d3a70907171057h3a090ae1qc38e012d7d508af3@mail.gmail.com> Message-ID: <4165d3a70907171058j60ead9b2l4e7c3e4c4773361c@mail.gmail.com> There is a package for serializing doubles on Hackage, Data.Bunary.IEEE754. See: http://hackage.haskell.org/package/data-binary-ieee754 -- Jeff On Fri, Jul 17, 2009 at 1:57 PM, Jeff Heard wrote: > Bulat, > > There is a package for serializing doubles on Hackage, > Data.Bunary.IEEE754. ?See: > http://hackage.haskell.org/package/data-binary-ieee754 > > -- Jeff > > On Fri, Jul 17, 2009 at 1:26 PM, Ian Lynagh wrote: >> >> Hi Bulat, >> >> On Sat, Jul 11, 2009 at 09:32:43PM +0400, Bulat Ziganshin wrote: >>> >>> > foreign import ccall unsafe "" >>> > ? client :: Ptr CLDouble -> IO () >> >> I'm afraid GHC has never supported CLDouble properly. It's been removed >> from the HEAD: >> ? ?http://hackage.haskell.org/trac/ghc/ticket/2793 >> and there's a ticket to add proper support: >> ? ?http://hackage.haskell.org/trac/ghc/ticket/3353 >> If it's important to you, please add a note to the ticket. >> >> >> Thanks >> Ian >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > From dominic at steinitz.org Sat Jul 18 04:38:03 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Sat Jul 18 03:25:05 2009 Subject: HPC gives spurious results if sources are compiled with -cpp In-Reply-To: <20090716163548.GC26184@matrix.chaos.earth.li> References: <4A5DCD4C.9030905@gmail.com> <20090716163548.GC26184@matrix.chaos.earth.li> Message-ID: <4A6189EB.4040305@steinitz.org> Ian Lynagh wrote: > On Wed, Jul 15, 2009 at 04:05:14PM +0000, Dominic Steinitz wrote: >> Simon Marlow gmail.com> writes: >> >>> On 14/07/2009 10:08, Dominic Steinitz wrote: >>>> Trac doesn't seem to work for us so I'm sending this bug report by email. >>> What's the symptom? >>> >>> Cheers, >>> Simon >>> >> I hit "New Bug" and get >> >> TICKET_CREATE privileges are required to perform this operation >> >> If I then hit "login" I get a Create New Ticket screen. >> >> I then fill in the details and hit submit and I get >> >> TICKET_CREATE privileges are required to perform this operation >> >> and all my details are lost :-( > > I've explicitly added "dominic" and "Dominic" to group "user", but I > don't think that should be necessary. > > If that doesn't fix it then my guess would be that you have some sort of > firewall or HTTP proxy that is fiddling with the cookie data. > > When you log in, does trac say "logged in as ...", or does it still look > like you are not logged in? > > > Thanks > Ian > > > Ian, We are behind a proxy and a firewall so that's the most likely explanation. I don't think I have a problem logging in to other sites (I'm sure I would have noticed). I'm not in work now so I can't try anything out. I know I have to set up various darcs environment variables at work to get darcs to work (DARCS_PROXYUSERPWD is one and there may be another). Thanks for investigating, Dominic. From gwright at comcast.net Sat Jul 18 17:15:55 2009 From: gwright at comcast.net (Gregory Wright) Date: Sat Jul 18 16:57:37 2009 Subject: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <2608b8a80907160929i4d83e27cu59a3b42f97a4cc9@mail.gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <2608b8a80907160929i4d83e27cu59a3b42f97a4cc9@mail.gmail.com> Message-ID: <4A623B8B.2030500@comcast.net> Hi Yitz, Yitzchak Gale wrote: >> The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 >> How to get it >> http://www.haskell.org/ghc/ >> > > I have a few comments about the "Distribution Packages" page > that is linked from there: > > http://www.haskell.org/ghc/distribution_packages.html > > Debian: > > Remove the line "Newer packages may be available in Haskell Unsafe." > That stuff is very, very old. > > Mac OS X: > > Paragraph beginning "Contrary to the recommendation at > the top of this page... rather than using the alternatives > below." It makes no sense. It appears to be referring to > an older version of the page. > > "Both 10.3 (Panther) and 10.4 (Tiger) are supported." > should be changed to 10.4 (Tiger) and 10.5 (Leopard). > > The paragraph about the ghc-devel port should be removed, > I think. The port still exists, but it doesn't seem to be actively > supported since 6.7. Anyone who wants to use GHC HEAD > will probably just build current HEAD manually. (Greg - is > this correct?) > > The ghc-devel port is not supported now. I will modify it to print a message to that effect. When there is a more reliable procedure for development builds is available I can re-enable the port. > Thanks, > Yitz > > From igloo at earth.li Sat Jul 18 18:17:48 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 18 17:59:28 2009 Subject: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <2608b8a80907160929i4d83e27cu59a3b42f97a4cc9@mail.gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <2608b8a80907160929i4d83e27cu59a3b42f97a4cc9@mail.gmail.com> Message-ID: <20090718221747.GA9905@matrix.chaos.earth.li> On Thu, Jul 16, 2009 at 07:29:58PM +0300, Yitzchak Gale wrote: > > ? ?The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 > > How to get it > > ? ? ? ?http://www.haskell.org/ghc/ > > I have a few comments about the "Distribution Packages" page > that is linked from there: Applied, thanks! Thanks Ian From dons at galois.com Mon Jul 20 12:37:46 2009 From: dons at galois.com (Don Stewart) Date: Mon Jul 20 12:21:27 2009 Subject: [reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties] Message-ID: <20090720163746.GC15846@whirlpool.galois.com> Something for SimonPJ ----- Forwarded message from Reiner Pope ----- Date: Mon, 20 Jul 2009 22:09:09 +0930 From: Reiner Pope To: Haskell Cafe mailing list Subject: [Haskell-cafe] SpecConstr difficulties Hi everyone, I've been having some trouble getting SpecConstr to work as I want it to. The following example (see end of email) came up in some code I was playing around with. The loops g1 and g2 both compute the same thing: the maximum element of the "list" (which has been fused away) of numbers from 1 to 10. Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as an accumulator. The Maybe gets filled after the first element is seen, so the Maybe is a Just for almost the entire running of the loop. It would be good to have this recognised by SpecConstr, to create an optimised loop for the Just case. This does indeed happen for g1, but not for g2. My difficulty is that I am only able to produce code similar to g2, i.e. where the pattern matching is in a separate function, 'expose', because the 'expose' function is implemented in a type-class, like in stream-fusion. Is there some way to keep the SpecConstr while leaving the 'expose' as a separate function? Here is the code: > {-# LANGUAGE BangPatterns #-} > > module Test(ans1,ans2) where > > import Prelude hiding(Maybe(..)) > > data Maybe a = Just !a | Nothing > > Nothing `mapp` Just b = Just b > Just a `mapp` Just b = Just (max a b) > > ans1 = g1 Nothing (0::Int) > > g1 m !n = case m of > Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > > ans2 = g2 Nothing (0::Int) > > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) > expose Nothing b = b > expose (Just a) b = a `seq` b On a similar note, when I was having difficulties with this problem, I started to wonder if it would be possible to come up with a more direct way to tell GHC, "do SpecConstr on this variable". From reading the source code of the stream-fusion package, it seems that the current way of doing this is with 'expose' functions like I wrote below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used on function arguments, like: foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... This pragma should say to the GHC something like "ignore conditions H2, H5 and H6 of the SpecConstr paper, for this function and this argument". Cheers, Reiner _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- From wasserman.louis at gmail.com Mon Jul 20 19:19:35 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Mon Jul 20 19:01:27 2009 Subject: Unpacking multi-type constructors Message-ID: I think this is a feasible idea. Whether this is in fact a good idea is an entirely separate question, however, and I want feedback. Currently, I believe that an UNPACK pragma used on a multi-constructor type has no effect. For example, data Node = Node Int {-# UNPACK #-} !(Maybe Node) {-# UNPACK #-} !(Maybe Node) is the same as data Node = Node Int !(Maybe Node) !(Maybe Node) What I'd like is for this to translate into four constructors, one for each combination of constructors for the UNPACK'd fields: data Node = Node0 Int -- Nothing, Nothing | Node1 Int Node -- Just, Nothing | Node2 Int Node -- Nothing, Just | Node3 Int Node Node -- Just, Just The primary counterargument I can think of is that this can result in a single-constructor type being turned into a multi-constructor type, which runs the risk of interfering with GHC's sexcellent handling of single-constructor types. The countercounterargument is, of course, that the {-# UNPACK #-} pragma already behaves differently depending on the single-constructorness of the underlying type, and that the obligation is already on the programmer to check such things. For reference, could somebody point me to the place in GHC that currently takes care of {-# UNPACK #-} pragmas, so I could -- for instance -- figure out whether or not there's another reason that this idea isn't in place already? Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090720/191fa2a9/attachment.html From simonpj at microsoft.com Tue Jul 21 04:11:27 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 21 03:52:29 2009 Subject: Unpacking multi-type constructors In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34B7F59492A@EA-EXMSG-C334.europe.corp.microsoft.com> Nice idea, but I'm not yet convinced that it would work well in practice. First, there's an exponential explosion in the number of constructors required. Anything with an exponential is worrying. Second, you presumably do not want massive code duplication. So I assume that if you start with case x of { Node i n2 n2) -> e then you'll desugar to something like this: let fj i n1 n2 = e in case x of Node1 I -> fj i Nothing Nothing Node2 I n1 -> fj I (Just n1) Nothing ... etc for other cases... This doesn't look like a win, because you end up allocating the (Just n1) things anyway! So maybe you want to *duplicate* e, so you generate case x of Node1 I -> e[Nothing/n1, Nothing/n2] Node2 I n1 -> e[Just n1/n1, Nothing/n2] ... etc for other cases... But now you not only have an exponential number of branches: in each of those branches you duplicate an arbitrarily large expression e. That doesn't look attractive to me. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Louis Wasserman Sent: 21 July 2009 00:20 To: glasgow-haskell-users@haskell.org Subject: Unpacking multi-type constructors I think this is a feasible idea. Whether this is in fact a good idea is an entirely separate question, however, and I want feedback. Currently, I believe that an UNPACK pragma used on a multi-constructor type has no effect. For example, data Node = Node Int {-# UNPACK #-} !(Maybe Node) {-# UNPACK #-} !(Maybe Node) is the same as data Node = Node Int !(Maybe Node) !(Maybe Node) What I'd like is for this to translate into four constructors, one for each combination of constructors for the UNPACK'd fields: data Node = Node0 Int -- Nothing, Nothing | Node1 Int Node -- Just, Nothing | Node2 Int Node -- Nothing, Just | Node3 Int Node Node -- Just, Just The primary counterargument I can think of is that this can result in a single-constructor type being turned into a multi-constructor type, which runs the risk of interfering with GHC's sexcellent handling of single-constructor types. The countercounterargument is, of course, that the {-# UNPACK #-} pragma already behaves differently depending on the single-constructorness of the underlying type, and that the obligation is already on the programmer to check such things. For reference, could somebody point me to the place in GHC that currently takes care of {-# UNPACK #-} pragmas, so I could -- for instance -- figure out whether or not there's another reason that this idea isn't in place already? Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090721/a982b68e/attachment-0001.html From ch27k89 at gmail.com Tue Jul 21 17:30:10 2009 From: ch27k89 at gmail.com (Christian Klauser) Date: Tue Jul 21 17:11:41 2009 Subject: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST Message-ID: <000601ca0a4a$70631600$51294200$@com> Hi, I'm in the process of learning haskell and came across this problem: Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.1` Common beginning of the file ============================ {-# LANGUAGE FlexibleContexts #-} module UPSO where import Control.Monad(forM,forM_) import Control.Monad.ST.Lazy (ST,runST) import Data.Array.MArray (MArray, Ix, getBounds, newArray, readArray, writeArray) import Data.Array.ST (STArray,STUArray) minmax xs@(x:_) = foldr (\x (l,u) -> (min x l,max x u)) (x,x) xs modify a i f = do x <- readArray a i writeArray a i (f x) increment a i = modify a i (+1) decrement a i = modify a i (\x -> x - 1) uniquePermutationsM t 0 = return $! [[]] uniquePermutationsM t pos = do (l,u) <- getBounds t perms <- forM [l..u] (\d -> do count <- readArray t d -- t[d] if count == 0 then return $! [] else do decrement t d pss <- uniquePermutationsM t (pos-1) increment t d return $! (map (d:) pss) ) return $! (concat perms) Using STArray (works) ===================== mkArray :: (Int,Int) -> (ST s) (STArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Using STUArray (doesn't work) ============================= But when I try to switch to unboxed arrays, I get an error message. mkArray :: (Int,Int) -> (ST s) (STUArray s Int Int) mkArray bounds = newArray bounds 0 uniquePermutationsST :: [Int] -> ST s [[Int]] uniquePermutationsST xs = do let bounds@(l,u) = (minmax xs) t <- mkArray bounds forM_ xs (increment t) pos <- sum `fmap` mapM (readArray t) [l..u] uniquePermutationsM t pos uniquePermutations xs = runST (uniquePermutationsST xs) Error messages ============== Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'newArray' at UPSO.hs:35:17-33 Possible fix: add (MArray (STUArray s) Int (ST s)) to the context of the type signature for 'mkArray' or add an instance declaration for (MArray (STUArray s) Int (ST s)) In the expression: newArray bounds 0 In the definition of 'mkArray': mkArray bounds = newArray bounds 0 and also: Could not deduce (MArray (STUArray s) Int (ST s)) from the context () arising from a use of 'increment' at UPSO.hs:41:14-24 After almost two hours of fiddling with the type annotations I hope someone can point me in the right direction. What on earth is going wrong? Thank you for your time. From dons at galois.com Tue Jul 21 18:38:56 2009 From: dons at galois.com (Don Stewart) Date: Tue Jul 21 18:22:26 2009 Subject: Unpacking multi-type constructors In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C34B7F59492A@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C34B7F59492A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20090721223856.GP10150@whirlpool.galois.com> Might be interesting to try the transformation manually and benchmark? simonpj: > Nice idea, but I?m not yet convinced that it would work well in practice. > > > > First, there?s an exponential explosion in the number of constructors > required. Anything with an exponential is worrying. > > > > Second, you presumably do not want massive code duplication. So I assume that > if you start with > > > > case x of { Node i n2 n2) -> e > > > > then you?ll desugar to something like this: > > > > let fj i n1 n2 = e > > in > > case x of > > Node1 I -> fj i Nothing Nothing > > Node2 I n1 -> fj I (Just n1) Nothing > > ? etc for other cases? > > > > This doesn?t look like a win, because you end up allocating the (Just n1) > things anyway! > > > > So maybe you want to *duplicate* e, so you generate > > case x of > > Node1 I -> e[Nothing/n1, Nothing/n2] > > Node2 I n1 -> e[Just n1/n1, Nothing/n2] > > ? etc for other cases? > > > > But now you not only have an exponential number of branches: in each of those > branches you duplicate an arbitrarily large expression e. That doesn?t look > attractive to me. > > > > Simon > > > > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Louis Wasserman > Sent: 21 July 2009 00:20 > To: glasgow-haskell-users@haskell.org > Subject: Unpacking multi-type constructors > > > > I think this is a feasible idea. Whether this is in fact a good idea is an > entirely separate question, however, and I want feedback. > > Currently, I believe that an UNPACK pragma used on a multi-constructor type has > no effect. For example, > > data Node = Node Int {-# UNPACK #-} !(Maybe Node) {-# UNPACK #-} !(Maybe Node) > > is the same as > > data Node = Node Int !(Maybe Node) !(Maybe Node) > > What I'd like is for this to translate into four constructors, one for each > combination of constructors for the UNPACK'd fields: > > data Node = Node0 Int -- Nothing, Nothing > > | Node1 Int Node -- Just, Nothing > | Node2 Int Node -- Nothing, Just > | Node3 Int Node Node -- Just, Just > > The primary counterargument I can think of is that this can result in a > single-constructor type being turned into a multi-constructor type, which runs > the risk of interfering with GHC's sexcellent handling of single-constructor > types. > > The countercounterargument is, of course, that the {-# UNPACK #-} pragma > already behaves differently depending on the single-constructorness of the > underlying type, and that the obligation is already on the programmer to check > such things. > > For reference, could somebody point me to the place in GHC that currently takes > care of {-# UNPACK #-} pragmas, so I could -- for instance -- figure out > whether or not there's another reason that this idea isn't in place already? > > Louis Wasserman > wasserman.louis@gmail.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dave at zednenem.com Tue Jul 21 18:53:15 2009 From: dave at zednenem.com (David Menendez) Date: Tue Jul 21 18:34:45 2009 Subject: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST In-Reply-To: <000601ca0a4a$70631600$51294200$@com> References: <000601ca0a4a$70631600$51294200$@com> Message-ID: <49a77b7a0907211553g5ea5f13dqd8ad6ae006054ca4@mail.gmail.com> On Tue, Jul 21, 2009 at 5:30 PM, Christian Klauser wrote: > Hi, I'm in the process of learning haskell and came across this problem: > > Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 > booted by GHC version 6.10.1` > > Common beginning of the file > ============================ > ? ?{-# LANGUAGE FlexibleContexts #-} > > ? ?module UPSO where > > ? ?import Control.Monad(forM,forM_) > ? ?import Control.Monad.ST.Lazy (ST,runST) This works if I replace Control.Monad.ST.Strict instead of Control.Monad.ST.Lazy. The problem is that the MArray instances are declared for the strict ST monad; there appear to be no corresponding instances for the lazy ST monad. -- Dave Menendez From ch27k89 at gmail.com Tue Jul 21 19:16:41 2009 From: ch27k89 at gmail.com (Christian Klauser) Date: Tue Jul 21 18:58:06 2009 Subject: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST In-Reply-To: <49a77b7a0907211553g5ea5f13dqd8ad6ae006054ca4@mail.gmail.com> References: <000601ca0a4a$70631600$51294200$@com> <49a77b7a0907211553g5ea5f13dqd8ad6ae006054ca4@mail.gmail.com> Message-ID: <002f01ca0a59$4f13df70$ed3b9e50$@com> Hi, Thank you, works indeed with the strict ST monad. Didn't think of that. But makes kind of sense not to define these instances, since unboxed values cannot have their computation delayed. It's a bit unfortunate, however, that a single use of an unboxed array "forces" the whole state thread to become strict. -----Original Message----- From: d4ve.menendez@gmail.com [mailto:d4ve.menendez@gmail.com] On Behalf Of David Menendez Sent: Mittwoch, 22. Juli 2009 00:53 To: Christian Klauser Cc: glasgow-haskell-users@haskell.org Subject: Re: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST On Tue, Jul 21, 2009 at 5:30 PM, Christian Klauser wrote: > Hi, I'm in the process of learning haskell and came across this problem: > > Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 > booted by GHC version 6.10.1` > > Common beginning of the file > ============================ > ? ?{-# LANGUAGE FlexibleContexts #-} > > ? ?module UPSO where > > ? ?import Control.Monad(forM,forM_) > ? ?import Control.Monad.ST.Lazy (ST,runST) This works if I replace Control.Monad.ST.Strict instead of Control.Monad.ST.Lazy. The problem is that the MArray instances are declared for the strict ST monad; there appear to be no corresponding instances for the lazy ST monad. -- Dave Menendez From peteg42 at gmail.com Tue Jul 21 19:24:39 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Tue Jul 21 19:06:15 2009 Subject: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST In-Reply-To: <002f01ca0a59$4f13df70$ed3b9e50$@com> References: <000601ca0a4a$70631600$51294200$@com> <49a77b7a0907211553g5ea5f13dqd8ad6ae006054ca4@mail.gmail.com> <002f01ca0a59$4f13df70$ed3b9e50$@com> Message-ID: On 22/07/2009, at 9:16 AM, Christian Klauser wrote: > Thank you, works indeed with the strict ST monad. Didn't think of > that. But > makes kind of sense not to define these instances, since unboxed > values > cannot have their computation delayed. It's a bit unfortunate, > however, that > a single use > of an unboxed array "forces" the whole state thread to become strict. Hmm. Have you seen the strictToLazyST function? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-ST-Lazy.html#v%3AstrictToLazyST cheers peter From ch27k89 at gmail.com Tue Jul 21 19:56:12 2009 From: ch27k89 at gmail.com (Christian Klauser) Date: Tue Jul 21 19:37:35 2009 Subject: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST In-Reply-To: References: <000601ca0a4a$70631600$51294200$@com> <49a77b7a0907211553g5ea5f13dqd8ad6ae006054ca4@mail.gmail.com> <002f01ca0a59$4f13df70$ed3b9e50$@com> Message-ID: <003001ca0a5e$d3b94b20$7b2be160$@com> Interesting. Would be used like this: uniquePermutations xs = runST $ strictToLazyST $ (uniquePermutationsST xs) After also swapping `runST` to the lazy version, it compiles and runs. Thank you! -----Original Message----- From: Peter Gammie [mailto:peteg42@gmail.com] Sent: Mittwoch, 22. Juli 2009 01:25 To: Christian Klauser Cc: glasgow-haskell-users@haskell.org Subject: Re: "Could not deduce (MArray (STUArray s) Int (ST s)) from context ()" when applying runST On 22/07/2009, at 9:16 AM, Christian Klauser wrote: > Thank you, works indeed with the strict ST monad. Didn't think of > that. But > makes kind of sense not to define these instances, since unboxed > values > cannot have their computation delayed. It's a bit unfortunate, > however, that > a single use > of an unboxed array "forces" the whole state thread to become strict. Hmm. Have you seen the strictToLazyST function? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-ST- Lazy.html#v%3AstrictToLazyST cheers peter From leledumbo_cool at yahoo.co.id Wed Jul 22 00:10:52 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Tue Jul 21 23:52:22 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) Message-ID: <24599789.post@talk.nabble.com> I've just installed 6.10.4 and try to rebuild a minimal version from source, but the rebuild process failed. It stops with message: Capability.c: error converting to pointer type on stage1. configure command: ./configure --prefix=/c/ghc CFLAGS=-O4 LDFLAGS=-s -- View this message in context: http://www.nabble.com/Failed-to-bootstrap-6.10.4-with-itself-on-Windows-%28MinGW%29-tp24599789p24599789.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Wed Jul 22 01:48:53 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jul 22 01:30:26 2009 Subject: [reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties] In-Reply-To: <20090720163746.GC15846@whirlpool.galois.com> References: <20090720163746.GC15846@whirlpool.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34B7F594DE9@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks. You've found a bug in 6.10, which is happily fixed in the HEAD and in the upcoming 6.12. Here's the code for g2: Test.$s$wg2 = \ (sc_soL :: GHC.Prim.Int#) (sc1_soM :: GHC.Prim.Int#) -> case GHC.Prim.># sc_soL 10 of _ { GHC.Bool.False -> case GHC.Prim.<=# sc1_soM sc_soL of _ { GHC.Bool.False -> Test.$s$wg2 (GHC.Prim.+# sc_soL 1) sc1_soM; GHC.Bool.True -> Test.$s$wg2 (GHC.Prim.+# sc_soL 1) sc_soL }; GHC.Bool.True -> Test.Just @ GHC.Types.Int (GHC.Types.I# sc1_soM) } Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Don Stewart | Sent: 20 July 2009 17:38 | To: glasgow-haskell-users@haskell.org | Subject: [reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties] | | Something for SimonPJ | | ----- Forwarded message from Reiner Pope ----- | | Date: Mon, 20 Jul 2009 22:09:09 +0930 | From: Reiner Pope | To: Haskell Cafe mailing list | Subject: [Haskell-cafe] SpecConstr difficulties | | Hi everyone, | | I've been having some trouble getting SpecConstr to work as I want it | to. The following example (see end of email) came up in some code I | was playing around with. The loops g1 and g2 both compute the same | thing: the maximum element of the "list" (which has been fused away) | of numbers from 1 to 10. | | Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as | an accumulator. The Maybe gets filled after the first element is seen, | so the Maybe is a Just for almost the entire running of the loop. | | It would be good to have this recognised by SpecConstr, to create an | optimised loop for the Just case. This does indeed happen for g1, but | not for g2. | | My difficulty is that I am only able to produce code similar to g2, | i.e. where the pattern matching is in a separate function, 'expose', | because the 'expose' function is implemented in a type-class, like in | stream-fusion. Is there some way to keep the SpecConstr while leaving | the 'expose' as a separate function? | | Here is the code: | | > {-# LANGUAGE BangPatterns #-} | > | > module Test(ans1,ans2) where | > | > import Prelude hiding(Maybe(..)) | > | > data Maybe a = Just !a | Nothing | > | > Nothing `mapp` Just b = Just b | > Just a `mapp` Just b = Just (max a b) | > | > ans1 = g1 Nothing (0::Int) | > | > g1 m !n = case m of | > Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) | > Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) | > | > ans2 = g2 Nothing (0::Int) | > | > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) | > expose Nothing b = b | > expose (Just a) b = a `seq` b | | On a similar note, when I was having difficulties with this problem, I | started to wonder if it would be possible to come up with a more | direct way to tell GHC, "do SpecConstr on this variable". From reading | the source code of the stream-fusion package, it seems that the | current way of doing this is with 'expose' functions like I wrote | below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used | on function arguments, like: | | foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... | | This pragma should say to the GHC something like "ignore conditions | H2, H5 and H6 of the SpecConstr paper, for this function and this | argument". | | Cheers, | Reiner | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe | | ----- End forwarded message ----- | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Wed Jul 22 05:35:07 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 22 05:16:40 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090716144210.GA23789@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> Message-ID: <4A66DD4B.4000600@dfki.de> Ian Lynagh wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 > ============================================================== > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. I've built http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-i386-unknown-solaris2.tar.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-tests.log.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.4-powerpc-apple-darwin.tar.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.4-tests.log.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-6.10.4-i386-apple-darwin.tar.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-6.10.4-tests.log.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/ghc-6.10.4-sparc-sun-solaris2.tar.bz2 For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) and the binary depends (at least) on: libiconv.so.2 => /usr/local/lib/libiconv.so.2 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libm.so.2 => /usr/local/lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 (The other binary distributions use their own static libgmp.a.) For x86-solaris 10 only libcurses.so.1 (and no libiconv) is needed whereas /usr/lib/libiconv.2.dylib and /usr/lib/libncurses.5.4.dylib are available on the Leopard Macs (one being a PowerMacG5). Cheers Christian (Maybe someone can explain the bad testsuite results.) From Christian.Maeder at dfki.de Wed Jul 22 05:58:33 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 22 05:40:10 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A66DD4B.4000600@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> Message-ID: <4A66E2C9.7070200@dfki.de> P.S. before installing the Haskell-Platform look at http://trac.haskell.org/haskell-platform/ticket/74 and take measures to avoid loosing your profiling libs. (Either by not re-installing the listed packages or by re-installing them with profiling switched on.) Cheers Christian Maeder wrote: > Ian Lynagh wrote: >> ============================================================== >> The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 >> ============================================================== > >> Packages will appear as they are built - if the package for your >> system isn't available yet, please try again later. > > I've built > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-i386-unknown-solaris2.tar.bz2 > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-tests.log.bz2 > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.4-powerpc-apple-darwin.tar.bz2 > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.4-tests.log.bz2 > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-6.10.4-i386-apple-darwin.tar.bz2 > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/ghcs/ghc-6.10.4-tests.log.bz2 > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/ghc-6.10.4-sparc-sun-solaris2.tar.bz2 > > For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) > and the binary depends (at least) on: > libiconv.so.2 => /usr/local/lib/libiconv.so.2 > libncurses.so.5 => /usr/local/lib/libncurses.so.5 > libm.so.2 => /usr/local/lib/libm.so.2 > libgmp.so.3 => /usr/local/lib/libgmp.so.3 > > (The other binary distributions use their own static libgmp.a.) > > For x86-solaris 10 only libcurses.so.1 (and no libiconv) is needed > whereas /usr/lib/libiconv.2.dylib and /usr/lib/libncurses.5.4.dylib are > available on the Leopard Macs (one being a PowerMacG5). > > Cheers Christian > > (Maybe someone can explain the bad testsuite results.) From marlowsd at gmail.com Wed Jul 22 06:38:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 22 06:20:13 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <24599789.post@talk.nabble.com> References: <24599789.post@talk.nabble.com> Message-ID: <4A66EC2C.2090206@gmail.com> On 22/07/2009 05:10, leledumbo wrote: > I've just installed 6.10.4 and try to rebuild a minimal version from source, > but the rebuild process failed. It stops with message: > Capability.c: error converting to pointer type > > on stage1. > > configure command: > ./configure --prefix=/c/ghc CFLAGS=-O4 LDFLAGS=-s I presume you're on Windows? MSYS or Cygwin? Which version of gcc? Cheers, Simon From bulat.ziganshin at gmail.com Wed Jul 22 07:13:26 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 22 06:55:02 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A66DD4B.4000600@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> Message-ID: <1987533073.20090722151326@gmail.com> Hello Christian, Wednesday, July 22, 2009, 1:35:07 PM, you wrote: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-i386-unknown-solaris2.tar.bz2 is it compatible with OpenSolaris too? if so, it's great, my users asks about OpenSolaris/Mac/FreeBSD support -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Christian.Maeder at dfki.de Wed Jul 22 07:35:33 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 22 07:17:05 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <1987533073.20090722151326@gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <1987533073.20090722151326@gmail.com> Message-ID: <4A66F985.3080702@dfki.de> Bulat Ziganshin wrote: > Hello Christian, > > Wednesday, July 22, 2009, 1:35:07 PM, you wrote: > >> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.4-i386-unknown-solaris2.tar.bz2 > > is it compatible with OpenSolaris too? if so, it's great, my users > asks about OpenSolaris/Mac/FreeBSD support I think, older versions worked under OpenSolaris, too. But maybe someone else can really confirm this for the current version. Cheers Christian From jsch at informatik.uni-kiel.de Wed Jul 22 09:28:28 2009 From: jsch at informatik.uni-kiel.de (Jan =?iso-8859-1?Q?Schauml=F6ffel?=) Date: Wed Jul 22 09:09:59 2009 Subject: Generating valid Haskell code using the GHC API pretty printer Message-ID: <20090722132828.GA11619@chuck> Hello everyone, we are trying to use the GHC API for a source-to-source transformation on Haskell programs. The result of parsing and typechecking a module enables us to apply the transformation, but writing the transformed module back using the pretty printer (Outputable) generates invalid Haskell code. For one thing, since even the names defined in the current module are fully qualified, the resulting code is not valid anymore. This can be worked around, but there is another issue: Simply reading the following program and then writing it out using the pretty printer renders the resulting code invalid. > module Main where > main = do > if True then putStrLn "longlonglonglonglonglongline" > else return () > longlonglonglonglonglonglonglonglonglonglonglongname $ "test" > longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn The result looks like this: > Main.main = do if GHC.Bool.True then > System.IO.putStrLn "longlonglonglonglonglongline" > else > GHC.Base.return () > Main.longlonglonglonglonglonglonglonglonglonglonglongname > GHC.Base.$ > "test" > Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn There are two different problems in this output: 1) the indentation of "if ... then ... else" violates the "do"-block layout rule 2) the indentation of the long function call is invalid It looks like those problems could be avoided if the pretty printer could be configured to consistently use "do { ... ; ... }" notation, but we have been unable to figure out how. Is there a canonical way to use the GHC API to pretty print to valid Haskell code? Kind regards, Jan Appended is our current code to execute the transformation above (the module to be read is expected in a file "dummy.hs" for simplicity). Please excuse if this might not be a minimal example. module Main where import GHC import GHC.Paths import Outputable main = do x <- runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags (dflags { hscTarget = HscNothing, ghcLink = NoLink }) target <- guessTarget "dummy.hs" Nothing setTargets [target] load LoadAllTargets graph <- getModuleGraph let unparsedmod = head graph parsedmod <- parseModule unparsedmod typecheckedmod <- typecheckModule parsedmod let Just renamedsource = renamedSource typecheckedmod (group,_,_,_,_) = renamedsource moduledings = (ms_mod unparsedmod) return (showSDoc (ppr group)) putStr $ x ++ "\n" -- If you're happy and you know it, syntax error! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090722/5933d30a/attachment.bin From nominolo at googlemail.com Wed Jul 22 09:52:33 2009 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Jul 22 09:34:22 2009 Subject: Fwd: Generating valid Haskell code using the GHC API pretty printer In-Reply-To: <916b84820907220649u7404e082yf0df45e377a3eaa0@mail.gmail.com> References: <20090722132828.GA11619@chuck> <916b84820907220649u7404e082yf0df45e377a3eaa0@mail.gmail.com> Message-ID: <916b84820907220652t1dc651f8m871b5fe9626ae2a3@mail.gmail.com> Forgot to include the list. ---------- Forwarded message ---------- From: Thomas Schilling Date: 2009/7/22 Subject: Re: Generating valid Haskell code using the GHC API pretty printer To: Jan Schauml?ffel The pretty printer never prints { .. } for a do expression. ?You can control which things are printed unqualified by setting the "PrintUnqualified" part properly. ?The most straightforward way is to use GHC.mkPrintUnqualifiedForModule which only prints things qualified that are not imported in the given module. See 'withPprStyle' and 'mkUserStyle' in Outputable. That said, if you're trying to do source-to-source transformations you probably want to keep the original layout as much as possible. ?GHC's pretty-printer isn't designed for that. ?GHC's syntax tree has very accurate source locations, so you could start from there and build your own pretty printer. 2009/7/22 Jan Schauml?ffel : > Hello everyone, > > we are trying to use the GHC API for a source-to-source transformation > on Haskell programs. ?The result of parsing and typechecking a module > enables us to apply the transformation, but writing the transformed > module back using the pretty printer (Outputable) generates invalid > Haskell code. > > For one thing, since even the names defined in the current module are > fully qualified, the resulting code is not valid anymore. > > This can be worked around, but there is another issue: Simply reading > the following program and then writing it out using the pretty printer > renders the resulting code invalid. > >> module Main where >> main = do >> ?if True then putStrLn "longlonglonglonglonglongline" >> ? ? ? ? ?else return () >> ?longlonglonglonglonglonglonglonglonglonglonglongname $ "test" >> longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn > > The result looks like this: > >> Main.main = do if GHC.Bool.True then >> ? ? ? ? ? ? ? ? ? ?System.IO.putStrLn "longlonglonglonglonglongline" >> ? ? ? ? ? ? ? ?else >> ? ? ? ? ? ? ? ? ? ?GHC.Base.return () >> ? ? ? ? ? ? ? ? ?Main.longlonglonglonglonglonglonglonglonglonglonglongname >> ? ? ? ? ? ? ? ?GHC.Base.$ >> ? ? ? ? ? ? ? ? ?"test" >> Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn > > There are two different problems in this output: > > 1) the indentation of "if ... then ... else" violates the "do"-block > ? layout rule > 2) the indentation of the long function call is invalid > > It looks like those problems could be avoided if the pretty printer > could be configured to consistently use "do { ... ; ... }" notation, > but we have been unable to figure out how. ?Is there a canonical way > to use the GHC API to pretty print to valid Haskell code? > > Kind regards, > Jan > > Appended is our current code to execute the transformation above (the > module to be read is expected in a file "dummy.hs" for simplicity). > Please excuse if this might not be a minimal example. > > module Main where > > import GHC > import GHC.Paths > import Outputable > > main = do > ?x <- runGhc (Just libdir) $ do > ? ?dflags <- getSessionDynFlags > ? ?setSessionDynFlags (dflags { hscTarget = HscNothing, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ghcLink = NoLink }) > > ? ?target <- guessTarget "dummy.hs" Nothing > ? ?setTargets [target] > ? ?load LoadAllTargets > > ? ?graph <- getModuleGraph > ? ?let unparsedmod = head graph > > ? ?parsedmod <- parseModule unparsedmod > ? ?typecheckedmod <- typecheckModule parsedmod > ? ?let Just renamedsource = renamedSource typecheckedmod > ? ? ? ?(group,_,_,_,_) = renamedsource > ? ? ? ?moduledings = (ms_mod unparsedmod) > > ? ?return (showSDoc (ppr group)) > ?putStr $ x ++ "\n" > > -- > If you're happy and you know it, syntax error! > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- Push the envelope. ?Watch it bend. -- Push the envelope. Watch it bend. From Christian.Maeder at dfki.de Wed Jul 22 10:33:47 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 22 10:15:19 2009 Subject: Fwd: Generating valid Haskell code using the GHC API pretty printer In-Reply-To: <916b84820907220652t1dc651f8m871b5fe9626ae2a3@mail.gmail.com> References: <20090722132828.GA11619@chuck> <916b84820907220649u7404e082yf0df45e377a3eaa0@mail.gmail.com> <916b84820907220652t1dc651f8m871b5fe9626ae2a3@mail.gmail.com> Message-ID: <4A67234B.7070504@dfki.de> Thomas Schilling wrote: > Forgot to include the list. > > ---------- Forwarded message ---------- > From: Thomas Schilling > Date: 2009/7/22 > Subject: Re: Generating valid Haskell code using the GHC API pretty printer > To: Jan Schauml?ffel > > > The pretty printer never prints { .. } for a do expression. You can > control which things are printed unqualified by setting the > "PrintUnqualified" part properly. The most straightforward way is to > use GHC.mkPrintUnqualifiedForModule which only prints things qualified > that are not imported in the given module. See 'withPprStyle' and > 'mkUserStyle' in Outputable. > > That said, if you're trying to do source-to-source transformations you > probably want to keep the original layout as much as possible. GHC's > pretty-printer isn't designed for that. GHC's syntax tree has very > accurate source locations, so you could start from there and build > your own pretty printer. I believe, Language.Haskell.Pretty can properly output haskell code (and the GHC API should be able to do so, too. Does the GHC API output tabs?) Below is a snippet for parsing and printing only. Cheers Christian import Language.Haskell.Pretty as HP import Language.Haskell.Syntax import Language.Haskell.Parser import System.Environment processFile :: String -> IO () processFile file = do src <- readFile file case parseModuleWithMode (ParseMode file) src of ParseOk hsMod -> putStrLn $ HP.prettyPrint hsMod ParseFailed loc err -> fail $ err ++ " in '" ++ file ++ "' line " ++ show (srcLine loc) main :: IO () main = do args <- getArgs mapM_ processFile args From dons at galois.com Wed Jul 22 13:39:57 2009 From: dons at galois.com (Don Stewart) Date: Wed Jul 22 13:23:27 2009 Subject: [relapse.dev@gmx.com: [Haskell-cafe] System.Mem.performGC leaks?] Message-ID: <20090722173957.GD25975@whirlpool.galois.com> Interesting. ----- Forwarded message from Neal Alexander ----- Date: Tue, 21 Jul 2009 18:48:38 -0700 From: Neal Alexander To: haskell-cafe@haskell.org Subject: [Haskell-cafe] System.Mem.performGC leaks? main = forever performGC The OS reported memory usage skyrockets. If i enable +RTS -S the GC statistics show the heap "live bytes" being constant. Is it accumulating statistics even when profiling is disabled (and can you turn that off), or is there something going on with the FFI call to performGC. Compiled with "ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded" btw. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- From wasserman.louis at gmail.com Wed Jul 22 13:56:39 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Wed Jul 22 13:38:27 2009 Subject: Unpacking multi-type constructors In-Reply-To: <20090721223856.GP10150@whirlpool.galois.com> References: <638ABD0A29C8884A91BC5FB5C349B1C34B7F59492A@EA-EXMSG-C334.europe.corp.microsoft.com> <20090721223856.GP10150@whirlpool.galois.com> Message-ID: Some very rough benchmarks: folding over these two implementations of a binary tree data Node1 a = Node1 a (Maybe (Node1 a)) (Maybe (Node1 a)) data Node2 a = Node2A a | Node2B a (Node2 a) | Node2C a (Node2 a) | Node2D a (Node2 a) (Node2 a) with the latter of Simon's examples gives the following measurements when performing 100 traversals over randomly generated trees of size 3000: min mean +/-sd median max Packed: 12.001 16.001 4.000 16.001 24.002 Unpacked: 12.000 13.144 1.952 12.001 16.001 (I'm not entirely sure what I'm doing, as this is my first contribution to the compiler proper, and pointers as to how to obtain more convincing benchmarks would be appreciated.) My motivation is more philosophical than anything else, though: - The behavior of unpacking several multi-constructor types can be highly useful to the programmer, and is also (precisely because of the exponential growth) difficult and time-consuming for the programmer to duplicate by hand. - Currently, UNPACK pragmas have *no effect* when used on multi-constructor types, and give no warnings or other hints that they are having no effect. There is currently no reason for a programmer to use an UNPACK pragma on a multi-constructor type, so I would not expect to see code bloat occurring in older programs. The primary exception to this would be in programmers that use the (already regarded as a sledgehammer) -funbox-strict-fields option. - As it stands, it is already the programmer's burden to know how many constructors an UNPACK'd type has, because the pragma will only have any effect if it is a single-constructor type. The effect of the proposal is to attach consequences to UNPACKing multi-constructor types, and placing the burden on the programmer to be sure that exponentially great code expansion does not get out of hand. The first two bullets are really the ones that grate on me -- that use of the UNPACK pragma in this fashion on multi-constructor types could be seriously useful to a programmer, but currently has no effect, and as a result, I would expect that implementing this proposal wouldn't cause problems in old programs and could be useful in new ones. I think I'm making sense. Would anyone else care to chime in? Louis Wasserman wasserman.louis@gmail.com On Tue, Jul 21, 2009 at 6:38 PM, Don Stewart wrote: > Might be interesting to try the transformation manually and benchmark? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090722/841cbf21/attachment.html From leledumbo_cool at yahoo.co.id Thu Jul 23 03:10:32 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu Jul 23 02:51:58 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <4A66EC2C.2090206@gmail.com> References: <24599789.post@talk.nabble.com> <4A66EC2C.2090206@gmail.com> Message-ID: <24620500.post@talk.nabble.com> > I presume you're on Windows? MSYS or Cygwin? Which version of gcc? MSYS 1.0.11 and MinGW GCC 4.4.0. -- View this message in context: http://www.nabble.com/Failed-to-bootstrap-6.10.4-with-itself-on-Windows-%28MinGW%29-tp24599789p24620500.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From leledumbo_cool at yahoo.co.id Thu Jul 23 03:11:15 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu Jul 23 02:52:41 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <4A66EC2C.2090206@gmail.com> References: <24599789.post@talk.nabble.com> <4A66EC2C.2090206@gmail.com> Message-ID: <24620505.post@talk.nabble.com> > I presume you're on Windows? MSYS or Cygwin? Which version of gcc? MSYS 1.0.11 and MinGW GCC 4.4.0 (it's installed and on PATH it's put before ghc, but I don't know whether ghc will use this one or the one bundled with it). -- View this message in context: http://www.nabble.com/Failed-to-bootstrap-6.10.4-with-itself-on-Windows-%28MinGW%29-tp24599789p24620505.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From marlowsd at gmail.com Thu Jul 23 06:42:45 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 23 06:24:13 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <24620505.post@talk.nabble.com> References: <24599789.post@talk.nabble.com> <4A66EC2C.2090206@gmail.com> <24620505.post@talk.nabble.com> Message-ID: <4A683EA5.7050900@gmail.com> On 23/07/2009 08:11, leledumbo wrote: > >> I presume you're on Windows? MSYS or Cygwin? Which version of gcc? > > MSYS 1.0.11 and MinGW GCC 4.4.0 (it's installed and on PATH it's put before > ghc, but I don't know whether ghc will use this one or the one bundled with > it). We haven't tested with gcc 4.4.0 yet. I've just created a ticket: http://hackage.haskell.org/trac/ghc/ticket/3390 FYI, if you want your GHC build to work on Windows, it is best to use the same tools that we do: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Cheers, Simon From niklas.broberg at gmail.com Thu Jul 23 06:50:47 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 06:32:13 2009 Subject: Fwd: Generating valid Haskell code using the GHC API pretty printer In-Reply-To: <4A67234B.7070504@dfki.de> References: <20090722132828.GA11619@chuck> <916b84820907220649u7404e082yf0df45e377a3eaa0@mail.gmail.com> <916b84820907220652t1dc651f8m871b5fe9626ae2a3@mail.gmail.com> <4A67234B.7070504@dfki.de> Message-ID: > I believe, Language.Haskell.Pretty can properly output haskell code (and > the GHC API should be able to do so, too. Does the GHC API output tabs?) Surely you mean Language.Haskell.Exts.Pretty, right? ;-) The haskell-src-exts library does not (yet) support full round-tripping source-to-source, so the generated output will be different from what was read. But it will at least produce valid output. Hopefully in a few months' time it will do the full round-tripping as well, at least that's the plan. In general, unless you actually want to use any other components of the GHC API, e.g. evaluate your code, then I see no reason to use the GHC API for source manipulation. haskell-src-exts simply does that better (and definitely better than haskell-src). But I couldn't tell if that's enough for the original poster's needs. :-) [/shameless plug] Cheers, /Niklas From ganesh.sittampalam at credit-suisse.com Thu Jul 23 07:05:30 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jul 23 06:47:38 2009 Subject: Fwd: Generating valid Haskell code using the GHC API pretty printer In-Reply-To: References: <20090722132828.GA11619@chuck><916b84820907220649u7404e082yf0df45e377a3eaa0@mail.gmail.com><916b84820907220652t1dc651f8m871b5fe9626ae2a3@mail.gmail.com><4A67234B.7070504@dfki.de> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F802@ELON17P32001A.csfb.cs-group.com> Niklas Broberg wrote: >> I believe, Language.Haskell.Pretty can properly output haskell code >> (and the GHC API should be able to do so, too. Does the GHC API >> output tabs?) > > Surely you mean Language.Haskell.Exts.Pretty, right? ;-) > > The haskell-src-exts library does not (yet) support full > round-tripping source-to-source, so the generated output will be > different from what was read. But it will at least produce valid > output. Hopefully in a few months' time it will do the full > round-tripping as well, at least that's the plan. > > In general, unless you actually want to use any other components of > the GHC API, e.g. evaluate your code, The original post did mention the need for typechecking. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From niklas.broberg at gmail.com Thu Jul 23 07:47:27 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 07:28:53 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: > Discussion period: 2 weeks Returning to this discussion, I'm surprised that so few people have actually commented yea or nay. Seems to me though that... * Some people are clearly in favor of a move in this direction, as seen both by their replies here and discussion over other channels. * Others are wary of deprecating anything of this magnitude for practical reasons. * No one has commented in true support of the classic existential syntax, only wanting to keep it for "legacy" reasons. I'm in no particular hurry to see this deprecation implemented, and I certainly understand the practical concerns, but I would still very much like us to make a statement that this is the direction we intend to go in the longer run. I'm not sure what the best procedure for doing so would be, but some sort of soft deprecation seems reasonable to me. Further thoughts? Cheers, /Niklas From niklas.broberg at gmail.com Thu Jul 23 07:36:33 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 07:32:51 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > Alright, let's set an actual discussion period of 2 weeks for > ExplicitForall. If there is no opposition by then, we can add > ExplicitForall to the registered extensions in cabal as a first step. Slightly more than two weeks later, there has been no voices against and at least a few in favor. The attached patch for Cabal adds ExplicitForall to the Extension datatype, with documentation, and adds it to knownExtensions. Cheers, /Niklas -------------- next part -------------- A non-text attachment was scrubbed... Name: ExplicitForall.dpatch Type: application/octet-stream Size: 41637 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090723/9e6fd5ac/ExplicitForall-0001.obj From claus.reinke at talk21.com Thu Jul 23 08:06:43 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jul 23 07:48:16 2009 Subject: Generating valid Haskell code using the GHC API pretty printer References: <20090722132828.GA11619@chuck> Message-ID: <30D114A286B04471BD748C5BA4EAC796@cr3lt> Hallo Kiel!-) >we are trying to use the GHC API for a source-to-source transformation >on Haskell programs. The result of parsing and typechecking a module >enables us to apply the transformation, but writing the transformed >module back using the pretty printer (Outputable) generates invalid >Haskell code. It would help to know more about your intended application. For instance, if there is a need for user-visible output, the requirements are very different from those of a simple preprocessor. In the former case, pretty-printing isn't going to get you far, even if you do write your own pretty printer - the AST doesn't have enough information to reconstruct the input program (one would need to combine the lexer's token stream with the modified AST to print out modified code - similarly to what was done in HaRe). In the latter case, you might not need to pretty-print, just modify the input before passing it on to later phases of GHC. Since you don't seem to care about formatting or comments, I suspect it is the latter - have you looked into Template Haskell as an alternative? As Thomas pointed out, there is some control over what gets qualified and what doesn't; the two indentation items you list look like plain bugs in search of a ticket and patch. Please record them on GHC's trac. Claus From simonpj at microsoft.com Thu Jul 23 11:27:18 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jul 23 11:09:33 2009 Subject: Generating valid Haskell code using the GHC API pretty printer In-Reply-To: <20090722132828.GA11619@chuck> References: <20090722132828.GA11619@chuck> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34B7FA6CD96@EA-EXMSG-C334.europe.corp.microsoft.com> I've fixed GHC's pretty-printer to print do-notation using braces and semi-colons, which is much more robust. I hope that's useful SImon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jan Schauml?ffel | Sent: 22 July 2009 14:28 | To: glasgow-haskell-users@haskell.org | Subject: Generating valid Haskell code using the GHC API pretty printer | | Hello everyone, | | we are trying to use the GHC API for a source-to-source transformation | on Haskell programs. The result of parsing and typechecking a module | enables us to apply the transformation, but writing the transformed | module back using the pretty printer (Outputable) generates invalid | Haskell code. | | For one thing, since even the names defined in the current module are | fully qualified, the resulting code is not valid anymore. | | This can be worked around, but there is another issue: Simply reading | the following program and then writing it out using the pretty printer | renders the resulting code invalid. | | > module Main where | > main = do | > if True then putStrLn "longlonglonglonglonglongline" | > else return () | > longlonglonglonglonglonglonglonglonglonglonglongname $ "test" | > longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn | | The result looks like this: | | > Main.main = do if GHC.Bool.True then | > System.IO.putStrLn "longlonglonglonglonglongline" | > else | > GHC.Base.return () | > Main.longlonglonglonglonglonglonglonglonglonglonglongname | > GHC.Base.$ | > "test" | > Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn | | There are two different problems in this output: | | 1) the indentation of "if ... then ... else" violates the "do"-block | layout rule | 2) the indentation of the long function call is invalid | | It looks like those problems could be avoided if the pretty printer | could be configured to consistently use "do { ... ; ... }" notation, | but we have been unable to figure out how. Is there a canonical way | to use the GHC API to pretty print to valid Haskell code? | | Kind regards, | Jan | | Appended is our current code to execute the transformation above (the | module to be read is expected in a file "dummy.hs" for simplicity). | Please excuse if this might not be a minimal example. | | module Main where | | import GHC | import GHC.Paths | import Outputable | | main = do | x <- runGhc (Just libdir) $ do | dflags <- getSessionDynFlags | setSessionDynFlags (dflags { hscTarget = HscNothing, | ghcLink = NoLink }) | | target <- guessTarget "dummy.hs" Nothing | setTargets [target] | load LoadAllTargets | | graph <- getModuleGraph | let unparsedmod = head graph | | parsedmod <- parseModule unparsedmod | typecheckedmod <- typecheckModule parsedmod | let Just renamedsource = renamedSource typecheckedmod | (group,_,_,_,_) = renamedsource | moduledings = (ms_mod unparsedmod) | | return (showSDoc (ppr group)) | putStr $ x ++ "\n" | | -- | If you're happy and you know it, syntax error! From iavor.diatchki at gmail.com Thu Jul 23 12:25:15 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 23 12:06:39 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> Hello, Sorry for responding so late---I just saw the thread. I don't think that we should deprecate the usual way to define existentials. While the GADT syntax is nice in some cases, there are also examples when it is quite verbose. For example, there is a lot of repetition in datatypes that have many constructors, especially if the datatype has parameters and a slightly longer name. Furthermore, I find the type variables in the declaration of the type quite confusing because they have no relation to the type variables in the constructors. Finally, there is quite a lot of literature about the semantics of existential types, while the semantics of GADTs seems quite complex, so it seems a bit risky to mix up the two. -Iavor On Thu, Jul 23, 2009 at 2:47 PM, Niklas Broberg wrote: >> Discussion period: 2 weeks > > Returning to this discussion, I'm surprised that so few people have > actually commented yea or nay. Seems to me though that... > * Some people are clearly in favor of a move in this direction, as > seen both by their replies here and discussion over other channels. > * Others are wary of deprecating anything of this magnitude for > practical reasons. > * No one has commented in true support of the classic existential > syntax, only wanting to keep it for "legacy" reasons. > > I'm in no particular hurry to see this deprecation implemented, and I > certainly understand the practical concerns, but I would still very > much like us to make a statement that this is the direction we intend > to go in the longer run. I'm not sure what the best procedure for > doing so would be, but some sort of soft deprecation seems reasonable > to me. > > Further thoughts? > > Cheers, > > /Niklas > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ganesh.sittampalam at credit-suisse.com Thu Jul 23 12:36:00 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jul 23 12:18:01 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> References: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> One can use the following style of GADT definition, which avoids the type variables in the declaration: {-# LANGUAGE GADTs, KindSignatures #-} module GADT where data Foo :: * -> * where Foo :: Int -> Foo Int Iavor Diatchki wrote: > Hello, > > Sorry for responding so late---I just saw the thread. I don't think > that we should deprecate the usual way to define existentials. While > the GADT syntax is nice in some cases, there are also examples when > it is quite verbose. For example, there is a lot of repetition in > datatypes that have many constructors, especially if the datatype has > parameters and a slightly longer name. Furthermore, I find the type > variables in the declaration of the type quite confusing because they > have no relation to the type variables in the constructors. Finally, > there is quite a lot of literature about the semantics of existential > types, while the semantics of GADTs seems quite complex, so it seems > a bit risky to mix up the two. > > -Iavor > > > > > > On Thu, Jul 23, 2009 at 2:47 PM, Niklas > Broberg wrote: >>> Discussion period: 2 weeks >> >> Returning to this discussion, I'm surprised that so few people have >> actually commented yea or nay. Seems to me though that... >> * Some people are clearly in favor of a move in this direction, as >> seen both by their replies here and discussion over other channels. >> * Others are wary of deprecating anything of this magnitude for >> practical reasons. >> * No one has commented in true support of the classic existential >> syntax, only wanting to keep it for "legacy" reasons. >> >> I'm in no particular hurry to see this deprecation implemented, and I >> certainly understand the practical concerns, but I would still very >> much like us to make a statement that this is the direction we intend >> to go in the longer run. I'm not sure what the best procedure for >> doing so would be, but some sort of soft deprecation seems >> reasonable to me. >> >> Further thoughts? >> >> Cheers, >> >> /Niklas >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > _______________________________________________ > 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 iavor.diatchki at gmail.com Thu Jul 23 18:28:00 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 23 18:09:25 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> References: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> Message-ID: <5ab17e790907231528r7c2b0f8fkaac94565c89087ba@mail.gmail.com> Hi, True, but then you have to declare the kind manually. -Iavor On Thu, Jul 23, 2009 at 7:36 PM, Sittampalam, Ganesh wrote: > One can use the following style of GADT definition, which avoids the > type variables in the declaration: > > {-# LANGUAGE GADTs, KindSignatures #-} > module GADT where > > data Foo :: * -> * where > ?Foo :: Int -> Foo Int > > Iavor Diatchki wrote: >> Hello, >> >> Sorry for responding so late---I just saw the thread. ?I don't think >> that we should deprecate the usual way to define existentials. ?While >> the GADT syntax is nice in some cases, there are also examples when >> it is quite verbose. For example, there is a lot of repetition in >> datatypes that have many constructors, especially if the datatype has >> parameters and a slightly longer name. ?Furthermore, I find the type >> variables in the declaration of the type quite confusing because they >> have no relation to the type variables in the constructors. ?Finally, >> there is quite a lot of literature about the semantics of existential >> types, while the semantics of GADTs seems quite complex, so it seems >> a bit risky to mix up the two. >> >> -Iavor >> >> >> >> >> >> On Thu, Jul 23, 2009 at 2:47 PM, Niklas >> Broberg wrote: >>>> Discussion period: 2 weeks >>> >>> Returning to this discussion, I'm surprised that so few people have >>> actually commented yea or nay. Seems to me though that... >>> * Some people are clearly in favor of a move in this direction, as >>> seen both by their replies here and discussion over other channels. >>> * Others are wary of deprecating anything of this magnitude for >>> practical reasons. >>> * No one has commented in true support of the classic existential >>> syntax, only wanting to keep it for "legacy" reasons. >>> >>> I'm in no particular hurry to see this deprecation implemented, and I >>> certainly understand the practical concerns, but I would still very >>> much like us to make a statement that this is the direction we intend >>> to go in the longer run. I'm not sure what the best procedure for >>> doing so would be, but some sort of soft deprecation seems >>> reasonable to me. >>> >>> Further thoughts? >>> >>> Cheers, >>> >>> /Niklas >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> >> _______________________________________________ >> 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 dan.doel at gmail.com Thu Jul 23 18:42:53 2009 From: dan.doel at gmail.com (Dan Doel) Date: Thu Jul 23 18:24:22 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <200907101103.01555.g9ks157k@acme.softbase.org> References: <200907101103.01555.g9ks157k@acme.softbase.org> Message-ID: <200907231842.53995.dan.doel@gmail.com> On Friday 10 July 2009 5:03:00 am Wolfgang Jeltsch wrote: > Isn?t ExistentialQuantification more powerful than using GADTs for > emulating existential quantification? To my knowledge, it is possible to > use lazy patterns with existential types but not with GADTs. 6.10.4 doesn't allow you to use ~ matches against either. -- Dan From leledumbo_cool at yahoo.co.id Fri Jul 24 00:17:56 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Thu Jul 23 23:59:21 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <4A683EA5.7050900@gmail.com> References: <24599789.post@talk.nabble.com> <4A66EC2C.2090206@gmail.com> <24620505.post@talk.nabble.com> <4A683EA5.7050900@gmail.com> Message-ID: <24638402.post@talk.nabble.com> OK, I've tried ghc's supplied gcc, too (not so easy, I need to set some environment variables first) and here are the results: With ghc's gcc: D:/Sources/ghc/ghc-6.10.4/ghc/stage1-inplace/ghc.exe -package rts-1.0 -optc-O2 - odir dist/build -c cbits/longlong.c -o dist/build/cbits/longlong.o (echo dist/build/cbits/longlong.o `find dist/build -name "*_stub.o" -print`; fin d dist/build/GHC/Bool_split dist/build/GHC/Generics_split dist/build/GHC/Orderin g_split dist/build/GHC/PrimopWrappers_split dist/build/GHC/IntWord32_split dist/ build/GHC/IntWord64_split dist/build/GHC/Tuple_split dist/build/GHC/Types_split dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/ghc/bin/ar.exe q dist/ build/libHSghc-prim-0.1.0.0.a xargs: c:/ghc/bin/ar.exe: Bad file number make[2]: *** [dist/build/libHSghc-prim-0.1.0.0.a] Error 126 make[2]: Leaving directory `/d/Sources/ghc/ghc-6.10.4/libraries/ghc-prim' make[1]: *** [make.library.ghc-prim] Error 2 make[1]: Leaving directory `/d/Sources/ghc/ghc-6.10.4/libraries' make: *** [stage1] Error 2 With gcc 4.4.0: d:/Sources/ghc/ghc-6.10.4/ghc/stage1-inplace/ghc -optc-O -optc-Wall -optc-W -opt c-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc -Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -op tc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -op tc-I../libffi/build/include -optc-fno-strict-aliasing -fvia-C -static -I../gmp /gmpbuild -I../libffi/build/include -I. -dcmm-lint -hisuf thr_hi -hcsuf thr_hc -osuf thr_o -optc-DTHREADED_RTS -c Capability.c -o Capability.thr_o Capability.c: In function 'giveCapabilityToTask': Capability.c:257:0: error: cannot convert to a pointer type make[2]: *** [Capability.thr_o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/d/Sources/ghc/ghc-6.10.4/rts' make: *** [stage1] Error 2 > FYI, if you want your GHC build to work on Windows, it is best to use > the same tools that we do It's the same as using ghc's supplied gcc, right (other requirements from the page already fulfilled)? -- View this message in context: http://www.nabble.com/Failed-to-bootstrap-6.10.4-with-itself-on-Windows-%28MinGW%29-tp24599789p24638402.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Fri Jul 24 03:00:50 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jul 24 02:42:16 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <200907231842.53995.dan.doel@gmail.com> References: <200907101103.01555.g9ks157k@acme.softbase.org> <200907231842.53995.dan.doel@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34CB4AFEFA0@EA-EXMSG-C334.europe.corp.microsoft.com> | On Friday 10 July 2009 5:03:00 am Wolfgang Jeltsch wrote: | > Isn?t ExistentialQuantification more powerful than using GADTs for | > emulating existential quantification? To my knowledge, it is possible to | > use lazy patterns with existential types but not with GADTs. | | 6.10.4 doesn't allow you to use ~ matches against either. In that respect GADTs and existentials are the same, regardless of the synatx with which they are declared. I hope. Simon From marlowsd at gmail.com Fri Jul 24 06:13:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 24 05:55:06 2009 Subject: Failed to bootstrap 6.10.4 with itself on Windows (MinGW) In-Reply-To: <24638402.post@talk.nabble.com> References: <24599789.post@talk.nabble.com> <4A66EC2C.2090206@gmail.com> <24620505.post@talk.nabble.com> <4A683EA5.7050900@gmail.com> <24638402.post@talk.nabble.com> Message-ID: <4A698954.20102@gmail.com> On 24/07/2009 05:17, leledumbo wrote: > > OK, I've tried ghc's supplied gcc, too (not so easy, I need to set some > environment variables first) and here are the results: > > With ghc's gcc: > > D:/Sources/ghc/ghc-6.10.4/ghc/stage1-inplace/ghc.exe -package rts-1.0 > -optc-O2 - > odir dist/build -c cbits/longlong.c -o dist/build/cbits/longlong.o > (echo dist/build/cbits/longlong.o `find dist/build -name "*_stub.o" -print`; > fin > d dist/build/GHC/Bool_split dist/build/GHC/Generics_split > dist/build/GHC/Orderin > g_split dist/build/GHC/PrimopWrappers_split dist/build/GHC/IntWord32_split > dist/ > build/GHC/IntWord64_split dist/build/GHC/Tuple_split > dist/build/GHC/Types_split > dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/ghc/bin/ar.exe q > dist/ > build/libHSghc-prim-0.1.0.0.a > xargs: c:/ghc/bin/ar.exe: Bad file number See this ticket: http://hackage.haskell.org/trac/ghc/ticket/3201 work-aroundable by adding SplitObjs=NO to mk/build.mk >> FYI, if you want your GHC build to work on Windows, it is best to use >> the same tools that we do > > It's the same as using ghc's supplied gcc, right (other requirements from > the page already fulfilled)? I think so, yes. Although, as you noticed, using GHC's built-in gcc is not terribly convenient. It will be much easier in 6.12.1, as we've made the layout of the bundled gcc files match the standard MinGW layout. Cheers, Simon From marlowsd at gmail.com Fri Jul 24 06:22:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 24 06:03:36 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A66DD4B.4000600@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> Message-ID: <4A698B53.7000508@gmail.com> On 22/07/2009 10:35, Christian Maeder wrote: > > For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) What went wrong? > (Maybe someone can explain the bad testsuite results.) Could you publish the results? Cheers, Simon From Christian.Maeder at dfki.de Fri Jul 24 06:46:25 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 06:27:53 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A698B53.7000508@gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> Message-ID: <4A699101.3080803@dfki.de> Simon Marlow wrote: > On 22/07/2009 10:35, Christian Maeder wrote: >> >> For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) > > What went wrong? Building went ok, despite the following warning at the end of ./configure: WARNING: It looks like "gmake" is GNU make 3.80. This version cannot be used to build GHC. Please use GNU make >= 3.81. But running the testsuite failed with: Looks like you don't have timeout, building it first... gmake -C ../../timeout all gmake[1]: Entering directory `/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/timeout' Makefile:16: *** missing `endif'. Stop. gmake[1]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/timeout' gmake: *** [../../timeout/install-inplace/bin/timeout] Error 2 This error refers to the line $(eval $(call canonicalise,PREFIX)) in timeout/Makefile. >> (Maybe someone can explain the bad testsuite results.) > > Could you publish the results? See the links in my original email Cheers Christian From Christian.Maeder at dfki.de Fri Jul 24 07:11:07 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 06:52:36 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A698B53.7000508@gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> Message-ID: <4A6996CB.8000202@dfki.de> Simon Marlow wrote: > On 22/07/2009 10:35, Christian Maeder wrote: >> >> For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) > > What went wrong? Even after creating timeout, I get the failure below with Python 2.4.1 (I see, 2.5.2 or later is required) Cheers Christian python ../../driver/runtests.py -e ghc_with_native_codegen=0 -e ghc_with_profiling=1 -e ghc_with_threaded_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_with_smp=1 --rootdir=. --config=../../config/ghc -e config.confdir=\"../../config\" -e config.compiler=\"/home/pub-bkb/bin/ghc\" -e config.compiler_always_flags.append"(\"\")" -e config.ghc_pkg=\"/home/pub-bkb/bin//ghc-pkg\" -e config.hp2ps=\"/home/pub-bkb/bin//hp2ps\" -e config.gs=\"gs\" -e config.platform=\"sparc-sun-solaris2\" -e config.os=\"solaris2\" -e config.wordsize=\"32\" -e default_testopts.cleanup=\"\" -e config.timeout="int() or config.timeout" -e config.timeout_prog=\"../../timeout/install-inplace/bin/timeout\" -e config.exeext=\"\" -e config.top=\"\" --rootdir=../../../libraries/containers/tests --rootdir=../../../libraries/hpc/tests --rootdir=../../../libraries/bytestring/tests --rootdir=../../../libraries/random/tests --rootdir=../../../libraries/directory/tests --rootdir=../../../libraries/process/tests --rootdir=../../../libraries/parallel/tests --rootdir=../../../libraries/Cabal/tests --rootdir=../../../libraries/stm/tests --rootdir=../../../libraries/network/tests --rootdir=../../../libraries/unix/tests \ \ \ \ \ \ gs -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../../config/good.ps Traceback (most recent call last): File "../../driver/runtests.py", line 105, in ? from testlib import * File "/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/driver/testlib.py", line 1274, in ? resultGood = runCmdExitCode(genGSCmd(config.confdir + '/good.ps')); File "/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/driver/testlib.py", line 1257, in runCmdExitCode return (runCmd(cmd) >> 8); File "/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/driver/testlib.py", line 1251, in runCmd r = rawSystem([config.timeout_prog, str(config.timeout), cmd]) File "/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/driver/testlib.py", line 1228, in rawSystem return subprocess.call(cmd_and_args) File "/usr/lib/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib/python2.4/subprocess.py", line 543, in __init__ errread, errwrite) File "/usr/lib/python2.4/subprocess.py", line 975, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory gmake: *** [test] Error From marlowsd at gmail.com Fri Jul 24 07:32:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 24 07:13:56 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A66DD4B.4000600@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> Message-ID: <4A699BCE.5030500@gmail.com> On 22/07/2009 10:35, Christian Maeder wrote: > (Maybe someone can explain the bad testsuite results.) My comments begin with "SDM:" below: =====> 2469(ghci) cd ./ffi/should_run && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output 2469.hs --interactive -v0 -ignore-dot-ghci -optc-std=gnu99 -fglasgow-exts <2469.genscript 1>2469.interp.stdout 2>2469.interp.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: GHCi runtime linker: fatal error: I found a duplicate definition for symbol __gmpz_get_ui whilst processing object file 2469_stub.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. SDM: I'd guess your gmp.h is dropping definitions for some inline functions into the code. =====> ghci024(normal) cd ./ghci/scripts && $MAKE -s --no-print-directory ghci024 ghci024.run.stdout 2>ghci024.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: ~~~~~~~~~~ Testing :set Stderr: grep: Unzul?ssige Option -- E Syntax: grep -hblcnsviw pattern file . . . gmake[1]: *** [ghci024] Fehler 2 SDM: this test needs fixing for non-GNU grep. =====> ghci028(ghci) cd ./ghci/scripts && HC='/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output ' '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output ghci028.run.stdout 2>ghci028.run.stderr Actual stderr output differs from expected: --- /dev/null Fr Jul 17 19:28:04 2009 +++ ./ghci/scripts/ghci028.run.stderr.normalised Fr Jul 17 19:28:06 2009 @@ -1,0 +1,4 @@ + +:1:6: lexical error at character '\136' + +:1:9: lexical error at character '\136' *** unexpected failure for ghci028(ghci) SDM: this (and 2816) can be fixed by setting your locale to UTF-8. =====> derefnull(profc) cd ./rts && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o derefnull derefnull.hs -O -prof -auto-all -fvia-C >derefnull.comp.stderr 2>&1 cd ./rts && ./derefnull +RTS -p -RTS derefnull.run.stdout 2>derefnull.run.stderr Segmentierungsfehler ./rts/derefnull.prof is empty *** unexpected failure for derefnull(profc) SDM: don't know why this works for us, or why we're expecting to find a .prof file at all. Looks like the tests need fixing. =====> tcfail126(normal) cd ./typecheck/should_fail && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -c tcfail126.hs >tcfail126.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./typecheck/should_fail/tcfail126.stderr.normalised Fr Jul 17 19:34:07 2009 +++ ./typecheck/should_fail/tcfail126.comp.stderr.normalised Fr Jul 17 19:34:07 2009 @@ -1,10 +1,4 @@ -tcfail126.hs:20:14: - Couldn't match expected type `forall (m :: * -> *). - (Monad m) => - Bar m' - against inferred type `Bar m' - In the pattern: Bar run op - In the pattern: Foo (Bar run op) - In the definition of `runProg': - runProg (Foo (Bar run op)) = run (prog op) +tcfail126.hs:11:0: + Failed to load interface for `Control.Monad.Trans': + it was found in multiple packages: mtl-1.1.0.2 ghc-mtl-1.1.0.2 SDM: I don't have a ghc-mtl library. Where does that come from? (There are lots of these) =====> conc034(threaded2) cd ./concurrent/should_run && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o conc034 conc034.hs -O -threaded -fglasgow-exts >conc034.comp.stderr 2>&1 cd ./concurrent/should_run && ./conc034 +RTS -C0 -RTS +RTS -N2 -RTS conc034.run.stdout 2>conc034.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: conc034: <> SDM: probably not a serious problem, but I should investigate this result. If you could make a ticket, that would be great. =====> num009(normal) cd ./lib/Numeric && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o num009 num009.hs >num009.comp.stderr 2>&1 cd ./lib/Numeric && ./num009 num009.run.stdout 2>num009.run.stderr Actual stdout output differs from expected: --- ./lib/Numeric/num009.stdout.normalised Fr Jul 17 20:28:56 2009 +++ ./lib/Numeric/num009.run.stdout.normalised Fr Jul 17 20:28:56 2009 @@ -1,1 +1,31 @@ +sind +-0.6452512852657808 +-0.7469218912594929 +(-5811906895766608,-53) +(-6727674302302237,-53) +sinf +0.6565767 +-0.7710884 +(11015529,-24) +(-12936717,-24) +cosd +0.7639704044417283 +-0.6649117899070088 +(6881233657531709,-53) +(-5988992978518909,-53) +cosf +0.7542593 +0.63672805 +(12654371,-24) +(10682524,-24) +tand +-0.8446024630198843 +1.123339821307656 +(-7607502675465108,-53) +(5059072800651599,-52) +tanf +0.870492 +-1.2110169 +(14604432,-24) +(-10158746,-23) Done *** unexpected failure for num009(normal) SDM: I don't have a clue about this one. =====> list001(ghci) cd ./lib/should_run && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output list001.hs --interactive -v0 -ignore-dot-ghci list001.interp.stdout 2>list001.interp.stderr Segmentierungsfehler Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: SDM: ouch! Please make a ticket for this one. =====> hClose002(normal) cd ./lib/IO && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o hClose002 hClose002.hs >hClose002.comp.stderr 2>&1 cd ./lib/IO && ./hClose002 hClose002.run.stdout 2>hClose002.run.stderr Actual stdout output differs from expected: --- ./lib/IO/hClose002.stdout.normalised Fr Jul 17 20:39:15 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Fr Jul 17 20:39:15 2009 @@ -1,4 +1,4 @@ -Left hClose: invalid argument (Bad file descriptor) +Left hClose: invalid argument (Bad file number) Right () Right () Right () *** unexpected failure for hClose002(normal) SDM: we need test output for this platform added to the test suite. Please make a ticket or submit a patch. =====> concio002(threaded2) cd ./lib/IO && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o concio002 concio002.hs -O -threaded >concio002.comp.stderr 2>&1 cd ./lib/IO && ./concio002 +RTS -N2 -RTS concio002.run.stdout 2>concio002.run.stderr Timeout happened...killing process... Beendet Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: SDM: This looks bad. Another ticket! =====> 1861(optc) cd ./codeGen/should_run && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o 1861 1861.hs -O -fvia-C >1861.comp.stderr 2>&1 Compile failed (status 256) errors were: /tmp/ghc10001_0/ghc10001_0.hc: In Funktion ?s1ua_ret?: /tmp/ghc10001_0/ghc10001_0.hc:100:0: Fehler: ?INFINITY? nicht deklariert (erste Benutzung in dieser Funktion) /tmp/ghc10001_0/ghc10001_0.hc:100:0: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgef?hrt /tmp/ghc10001_0/ghc10001_0.hc:100:0: Fehler: f?r jede Funktion in der er auftritt.) /tmp/ghc10001_0/ghc10001_0.hc: In Funktion ?s1ug_ret?: /tmp/ghc10001_0/ghc10001_0.hc:145:0: Fehler: ?INFINITY? nicht deklariert (erste Benutzung in dieser Funktion) *** unexpected failure for 1861(optc) SDM: we have a ticket for this already: #2929 =====> user001(normal) cd ./libraries/unix && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd ./libraries/unix && ./user001 user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./libraries/unix/user001.stdout.normalised Fr Jul 17 21:09:45 2009 +++ ./libraries/unix/user001.run.stdout.normalised Fr Jul 17 21:09:45 2009 @@ -3,9 +3,9 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getEffectiveUserName: OK -getGroupEntryForID: OK -getGroupEntryForName: OK +getEffectiveUserName: ERROR: getUserEntryForID: failed (Unknown error) +getGroupEntryForID: ERROR: getGroupEntryForID: failed (Unknown error) +getGroupEntryForName: ERROR: getGroupEntryForID: failed (Unknown error) getAllGroupEntries: OK -getUserEntryForID: OK +getUserEntryForID: ERROR: getUserEntryForID: failed (Unknown error) getAllUserEntries: OK *** unexpected failure for user001(normal) SDM: I have a machine that does this too. I don't remember why, but AFAIR it's not serious. =====> signals004(ghci) cd ./libraries/unix && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output signals004.hs --interactive -v0 -ignore-dot-ghci -package unix signals004.interp.stdout 2>signals004.interp.stderr Timeout happened...killing process... Beendet Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: signals004: lost signal due to full pipe: 16 SDM: Probably not a bug as such, but interesting that it happens to you. Something to investigate one day. =====> process006(threaded2) cd ./libraries/process && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o process006 process006.hs -O -threaded >process006.comp.stderr 2>&1 cd ./libraries/process && ./process006 +RTS -N2 -RTS process006.run.stdout 2>process006.run.stderr Timeout happened...killing process... Beendet Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: SDM: looks bad. Tickets please. =====> process007(normal) cd ./libraries/process && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o process007 process007.hs >process007.comp.stderr 2>&1 cd ./libraries/process && ./process007 process007.run.stdout 2>process007.run.stderr Actual stdout output differs from expected: --- ./libraries/process/process007.stdout.normalised Fr Jul 17 21:42:20 2009 +++ ./libraries/process/process007.run.stdout.normalised Fr Jul 17 21:42:20 2009 @@ -1,2 +1,2 @@ You bad pie-rats! -failed, as expected +eek! *** unexpected failure for process007(normal) SDM: looks bad. Tickets please. =====> num012(normal) cd ./numeric/should_run && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o num012 num012.hs >num012.comp.stderr 2>&1 cd ./numeric/should_run && ./num012 num012.run.stdout 2>num012.run.stderr Actual stdout output differs from expected: --- ./numeric/should_run/num012.stdout.normalised Fr Jul 17 21:47:56 2009 +++ ./numeric/should_run/num012.run.stdout.normalised Fr Jul 17 21:47:56 2009 @@ -1,4 +1,4 @@ -[0,1,5,9,10,14,31,31,32,32,32,32,33] +[0,1,5,9,10,14,31,31,31,32,32,32,33] -2.147483648e9 -2.1474837e9 -2.147483648e9 *** unexpected failure for num012(normal) SDM: no idea about this one. =====> cabal01(normal) cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 PROF=--enable-library-profiling cabal01.run.stdout 2>cabal01.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: install1: bin lib Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. install2: bin lib Stderr: tar: C: unbekannter Funktionsmodifizierer Syntax: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X...] [Blockgr??e] [tar-Datei] [Gr??e] [Ausschlussdatei...] {Datei | -I Einschlussdatei | -C Verzeichnis Datei}... gmake[1]: *** [cabal01] Fehler 1 *** unexpected failure for cabal01(normal) SDM: looks like the test needs to be fixed to work with non-GNU tar? Or is it a Cabal issue? =====> ghcpkg05(normal) cd ./cabal && $MAKE -s --no-print-directory ghcpkg05 ghcpkg05.run.stdout 2>ghcpkg05.run.stderr Actual stderr output differs from expected: --- ./cabal/ghcpkg05.stderr.normalised Fr Jul 17 21:49:05 2009 +++ ./cabal/ghcpkg05.run.stderr.normalised Fr Jul 17 21:49:05 2009 @@ -8,9 +8,15 @@ file C/D.hi is missing file C/E.hi is missing cannot find libtestpkg-2.0.a on library path +There are problems in package HAIFA-0.12: + dependency HTTP-3001.1.5 doesn't exist + dependency dataenc-0.13.0.0 doesn't exist + dependency hxt-8.2.0 doesn't exist + dependency hxt-filter-8.2.0 doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. testpkg-2.0 +HAIFA-0.12 testpkg-3.0 ghc-pkg: unregistering testpkg-2.0 would break the following packages: testpkg-3.0 (use --force to override) *** unexpected failure for ghcpkg05(normal) SDM: What is HAIFA? =====> driver063(normal) cd ./driver && $MAKE -s --no-print-directory test063 driver063.run.stdout 2>driver063.run.stderr Actual stderr output differs from expected: --- ./driver/driver063.stderr.normalised Fr Jul 17 21:50:02 2009 +++ ./driver/driver063.run.stderr.normalised Fr Jul 17 21:50:02 2009 @@ -1,4 +1,0 @@ - -D.hs:2:7: - Could not find module `A': - it is not a module in the current program, or in any known package. *** unexpected failure for driver063(normal) SDM: looks wrong, but might be benign if you have a module A floating about somewhere. =====> 3231(normal) cd ../../../libraries/process/tests && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o 3231 3231.hs >3231.comp.stderr 2>&1 cd ../../../libraries/process/tests && ./3231 3231.run.stdout 2>3231.run.stderr Actual stderr output differs from expected: --- /dev/null Fr Jul 17 21:52:05 2009 +++ ../../../libraries/process/tests/3231.run.stderr.normalised Fr Jul 17 21:58:29 2009 @@ -1,0 +1,457 @@ +sleep: Falsches Zeichen im Argument SDM: test needs fixing to work with your sleep, I imagine. =====> conc068(normal) cd ../../../libraries/parallel/tests && $MAKE -s --no-print-directory test068 conc068.run.stdout 2>conc068.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: Makefile:6: ../../../testsuite/mk/boilerplate.mk: Datei oder Verzeichnis nicht gefunden Makefile:7: ../../../testsuite/mk/test.mk: Datei oder Verzeichnis nicht gefunden gmake[1]: *** Keine Regel, um ?../../../testsuite/mk/test.mk? zu erstellen. Schluss. SDM: ? =====> conc049(hpc) cd ../../../libraries/stm/tests && '/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -o conc049 conc049.hs -O -fhpc -package stm >conc049.comp.stderr 2>&1 cd ../../../libraries/stm/tests && ./conc049 conc049.run.stdout 2>conc049.run.stderr Timeout happened...killing process... Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: SDM: I see this from time to time. AFAIK it's not serious. Cheers, Simon From Christian.Maeder at dfki.de Fri Jul 24 08:19:15 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 08:00:41 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A699BCE.5030500@gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A699BCE.5030500@gmail.com> Message-ID: <4A69A6C3.9080105@dfki.de> Simon Marlow wrote: > SDM: I'd guess your gmp.h is dropping definitions for some inline > functions into the code. gmp for ghc was taking from the ghc-sources, but maybe my gcc uses /usr/local/include/gmp.h nevertheless (because that's a system path). > +tcfail126.hs:11:0: > + Failed to load interface for `Control.Monad.Trans': > + it was found in multiple packages: mtl-1.1.0.2 ghc-mtl-1.1.0.2 > > SDM: I don't have a ghc-mtl library. Where does that come from? I see "ghc-mtl" for the first time, too. > Stderr: > tar: C: unbekannter Funktionsmodifizierer > Syntax: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X...] [Blockgr??e] > [tar-Datei] [Gr??e] [Ausschlussdatei...] {Datei | -I Einschlussdatei | > -C Verzeichnis Datei}... > gmake[1]: *** [cabal01] Fehler 1 > > *** unexpected failure for cabal01(normal) > > SDM: looks like the test needs to be fixed to work with non-GNU tar? > Or is it a Cabal issue? Cabal usually works fine for me. It's a typical error when tar was used instead of gtar. > =====> ghcpkg05(normal) > cd ./cabal && $MAKE -s --no-print-directory ghcpkg05 >ghcpkg05.run.stdout 2>ghcpkg05.run.stderr > Actual stderr output differs from expected: > --- ./cabal/ghcpkg05.stderr.normalised Fr Jul 17 21:49:05 2009 > +++ ./cabal/ghcpkg05.run.stderr.normalised Fr Jul 17 21:49:05 2009 > @@ -8,9 +8,15 @@ > file C/D.hi is missing > file C/E.hi is missing > cannot find libtestpkg-2.0.a on library path > +There are problems in package HAIFA-0.12: > + dependency HTTP-3001.1.5 doesn't exist > + dependency dataenc-0.13.0.0 doesn't exist > + dependency hxt-8.2.0 doesn't exist > + dependency hxt-filter-8.2.0 doesn't exist > > The following packages are broken, either because they have a problem > listed above, or because they depend on a broken package. > testpkg-2.0 > +HAIFA-0.12 > testpkg-3.0 > ghc-pkg: unregistering testpkg-2.0 would break the following packages: > testpkg-3.0 (use --force to override) > *** unexpected failure for ghcpkg05(normal) > > SDM: What is HAIFA? I can explain this one. I ran the testsuite after having installed ghc and HAIFA (not on hackage) in the user base and the other packages globally. The inplace compiler being tested does not know my additional global packages but still looks in the user base. > > =====> driver063(normal) > cd ./driver && $MAKE -s --no-print-directory test063 >driver063.run.stdout 2>driver063.run.stderr > Actual stderr output differs from expected: > --- ./driver/driver063.stderr.normalised Fr Jul 17 21:50:02 2009 > +++ ./driver/driver063.run.stderr.normalised Fr Jul 17 21:50:02 2009 > @@ -1,4 +1,0 @@ > - > -D.hs:2:7: > - Could not find module `A': > - it is not a module in the current program, or in any known package. > *** unexpected failure for driver063(normal) > > SDM: looks wrong, but might be benign if you have a module A floating > about somewhere. "ghc-pkg find-module A" does not show a module A (Maybe an early test left a module A in the user base.) Thanks for looking through it. I don't know when I'll have time for tickets. Cheers Christian From marlowsd at gmail.com Fri Jul 24 08:39:38 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 24 08:21:03 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69A6C3.9080105@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A699BCE.5030500@gmail.com> <4A69A6C3.9080105@dfki.de> Message-ID: <4A69AB8A.2030106@gmail.com> On 24/07/2009 13:19, Christian Maeder wrote: > Simon Marlow wrote: >> SDM: I'd guess your gmp.h is dropping definitions for some inline >> functions into the code. > > gmp for ghc was taking from the ghc-sources, but maybe my gcc uses > /usr/local/include/gmp.h nevertheless (because that's a system path). > >> +tcfail126.hs:11:0: >> + Failed to load interface for `Control.Monad.Trans': >> + it was found in multiple packages: mtl-1.1.0.2 ghc-mtl-1.1.0.2 >> >> SDM: I don't have a ghc-mtl library. Where does that come from? > > I see "ghc-mtl" for the first time, too. It's probably in your user package DB, installed as a dependency of something else. The testsuite should be ignoring your user package DB; I'll fix that. Cheers, Simon From Christian.Maeder at dfki.de Fri Jul 24 08:48:58 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 08:30:24 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69AB8A.2030106@gmail.com> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A699BCE.5030500@gmail.com> <4A69A6C3.9080105@dfki.de> <4A69AB8A.2030106@gmail.com> Message-ID: <4A69ADBA.6090000@dfki.de> Simon Marlow wrote: >>> SDM: I don't have a ghc-mtl library. Where does that come from? >> >> I see "ghc-mtl" for the first time, too. > > It's probably in your user package DB, installed as a dependency of > something else. The testsuite should be ignoring your user package DB; > I'll fix that. For some reason a ghc-mtl was built when compiling from source. Also haskeline-0.6.1.5, terminfo and test is no package later on. -bash-3.00$ utils/ghc-pkg/install-inplace/bin/ghc-pkg list /export/local1/home/maeder/haskell/ghc-6.10.4/inplace-datadir/./package.conf: Cabal-1.6.0.3, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, (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), extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.1.0.2, ghc-prim-0.1.0.0, haddock-2.4.2, haskeline-0.6.1.5, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.2, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, terminfo-0.3.1, test-1.0, time-1.1.4, unix-2.3.2.0, utf8-string-0.3.4, xhtml-3000.2.0.1 /home/maeder/.ghc/i386-solaris2-6.10.4/package.conf: {HAIFA-0.12}, programatica-1.0, syb-generics-2.9 -bash-3.00$ ghc-pkg list /home/pub-bkb/pc-solaris/ghc/ghc-6.10.4/lib/ghc-6.10.4/./package.conf: Cabal-1.6.0.3, HTTP-3001.1.5, HTTP-4000.0.7, HUnit-1.2.0.3, HaXml-1.13.3, QuickCheck-1.2.0.0, Shellac-0.9.5, Shellac-haskeline-0.2, WashNGo-2.12, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, cpphs-1.7, curl-1.3.5, dataenc-0.13.0.0, directory-1.0.0.3, (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), extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-prim-0.1.0.0, haddock-2.4.2, haskeline-0.6.1.6, haskell-src-1.0.1.3, haskell-src-exts-1.0.1, haskell98-1.0.1.0, hpc-0.5.0.3, hscolour-1.13, html-1.0.1.2, hxt-8.2.0, hxt-filter-8.2.0, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.2, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, tabular-0.1.0.2, tagsoup-0.6, tar-0.3.0.0, template-haskell-2.3.0.1, time-1.1.4, uni-events-2.0, uni-graphs-2.0, uni-htk-2.0, uni-posixutil-2.0, uni-reactor-2.0, uni-uDrawGraph-2.0, uni-util-2.0, uniplate-1.2.0.3, unix-2.3.2.0, utf8-string-0.3.4, xhtml-3000.2.0.1, xml-1.3.4, zlib-0.5.0.0 /home/maeder/.ghc/i386-solaris2-6.10.4/package.conf: HAIFA-0.12, programatica-1.0, syb-generics-2.9 From marlowsd at gmail.com Fri Jul 24 08:54:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 24 08:35:54 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69ADBA.6090000@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A699BCE.5030500@gmail.com> <4A69A6C3.9080105@dfki.de> <4A69AB8A.2030106@gmail.com> <4A69ADBA.6090000@dfki.de> Message-ID: <4A69AF06.7020405@gmail.com> On 24/07/2009 13:48, Christian Maeder wrote: > Simon Marlow wrote: >>>> SDM: I don't have a ghc-mtl library. Where does that come from? >>> >>> I see "ghc-mtl" for the first time, too. >> >> It's probably in your user package DB, installed as a dependency of >> something else. The testsuite should be ignoring your user package DB; >> I'll fix that. > > For some reason a ghc-mtl was built when compiling from source. Also > haskeline-0.6.1.5, terminfo and test is no package later on. Oh, I see. In the 6.10 branch, ghc-mtl is our internal copy of mtl, which breaks the tests that use the mtl package. It's a bit late to do anything about this now, but maybe ghc-mtl should have been hidden by default, or something. Cheers, Simon From igloo at earth.li Fri Jul 24 09:56:07 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 09:37:29 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A699101.3080803@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> <4A699101.3080803@dfki.de> Message-ID: <20090724135607.GA4845@matrix.chaos.earth.li> On Fri, Jul 24, 2009 at 12:46:25PM +0200, Christian Maeder wrote: > Simon Marlow wrote: > > On 22/07/2009 10:35, Christian Maeder wrote: > >> > >> For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80) > > > > What went wrong? > > Building went ok, despite the following warning at the end of ./configure: > > WARNING: It looks like "gmake" is GNU make 3.80. > This version cannot be used to build GHC. > Please use GNU make >= 3.81. > > But running the testsuite failed with: > > Looks like you don't have timeout, building it first... > gmake -C ../../timeout all > gmake[1]: Entering directory > `/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/timeout' > Makefile:16: *** missing `endif'. Stop. > gmake[1]: Leaving directory > `/export/local2/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/timeout' > gmake: *** [../../timeout/install-inplace/bin/timeout] Error 2 > > This error refers to the line > > $(eval $(call canonicalise,PREFIX)) > > in timeout/Makefile. Hmm, this test: ------------- HAVE_EVAL := NO $(eval HAVE_EVAL := YES) ifeq "$(HAVE_EVAL)" "NO" $(error Your make does not support eval. You need GNU make >= 3.80) endif ------------- in testsuite/mk/boilerplate.mk is supposed to fail if running the testsuite would fail, so I don't know what's gone wrong there. If you work out what else is breaking then let me know and we can add a test for it. Thanks Ian From igloo at earth.li Fri Jul 24 09:57:55 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 09:39:18 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A66DD4B.4000600@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> Message-ID: <20090724135755.GB4845@matrix.chaos.earth.li> On Wed, Jul 22, 2009 at 11:35:07AM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > > ============================================================== > > The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 > > ============================================================== > > > Packages will appear as they are built - if the package for your > > system isn't available yet, please try again later. > > I've built [bindists] Thanks! All now added to the download page. Thanks Ian From Christian.Maeder at dfki.de Fri Jul 24 10:39:53 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 10:21:20 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090724135607.GA4845@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> <4A699101.3080803@dfki.de> <20090724135607.GA4845@matrix.chaos.earth.li> Message-ID: <4A69C7B9.8030908@dfki.de> Ian Lynagh wrote: >> This error refers to the line >> >> $(eval $(call canonicalise,PREFIX)) >> >> in timeout/Makefile. > > Hmm, this test: > ------------- > HAVE_EVAL := NO > $(eval HAVE_EVAL := YES) > > ifeq "$(HAVE_EVAL)" "NO" > $(error Your make does not support eval. You need GNU make >= 3.80) > endif > ------------- > in testsuite/mk/boilerplate.mk is supposed to fail if running the > testsuite would fail, so I don't know what's gone wrong there. If you > work out what else is breaking then let me know and we can add a test > for it. eval works, but abspath does not! From superwushu at gmail.com Fri Jul 24 10:43:46 2009 From: superwushu at gmail.com (Shu Wu) Date: Fri Jul 24 10:25:08 2009 Subject: can we bootstrap GHC 6.x? Message-ID: <5c7d4fb80907240743g4a31ffecq17a51e40d8c11358@mail.gmail.com> Hi buddies. I've been looking for methods to bootstrap GHC 6.10 but with no luck. It seems GHC 5.0 is the last version that provides HC source for bootstrapping. I think, however, bootstrapping GHC above 6.x is still necessary. First, it will be easier to build GHC on a new platform, eg, OpenSolaris. By now I succeed building GHC 6.10.4 on OpenSolaris(x86), with the help of GHC 6.6 binary package for Solaris x86 by Christian Maeder. But that was a terrible procedure. I have to deal with bins and libs for two versions of GHC. Second, compiling GHC from strap is the only way to go into OpenSolaris' official package repository, since all packages for OpenSolaris are built by Source Juicer (http://jucr.opensolaris.org/home/) from pure source code, and there can't be any pre-installed GHC on Source Juicer Build Grid. Cheers, Wu Shu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090724/f10b8073/attachment.html From bulat.ziganshin at gmail.com Fri Jul 24 10:55:20 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 24 10:36:51 2009 Subject: can we bootstrap GHC 6.x? In-Reply-To: <5c7d4fb80907240743g4a31ffecq17a51e40d8c11358@mail.gmail.com> References: <5c7d4fb80907240743g4a31ffecq17a51e40d8c11358@mail.gmail.com> Message-ID: <1614636191.20090724185520@gmail.com> Hello Shu, Friday, July 24, 2009, 6:43:46 PM, you wrote: > OpenSolaris. By now I succeed building GHC 6.10.4 on > OpenSolaris(x86),?with the help of GHC 6.6 binary package for > Solaris x86 by?Christian Maeder. But that?was a terrible procedure. two days ago he published his build of 6.10.4, now available at http://www.haskell.org/ghc/download_ghc_6_10_4.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Christian.Maeder at dfki.de Fri Jul 24 11:18:43 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 11:00:09 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090724135755.GB4845@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <20090724135755.GB4845@matrix.chaos.earth.li> Message-ID: <4A69D0D3.1060305@dfki.de> Ian Lynagh wrote: > On Wed, Jul 22, 2009 at 11:35:07AM +0200, Christian Maeder wrote: >> Ian Lynagh wrote: >>> ============================================================== >>> The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 >>> ============================================================== >>> Packages will appear as they are built - if the package for your >>> system isn't available yet, please try again later. >> I've built [bindists] > > Thanks! All now added to the download page. Could you also remove (or correct) the line "It needs libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/" for both Mac dists, because I've included gmp statically. The two dists only rely on libiconv.2.dylib and libncurses.5.4.dylib (and libSystem.B.dylib and libgcc_s.1.dylib) which should be under /usr/lib/. Cheers Christian P.S. I think, you can simply remove libgmp.a from a ghc installation and try to link your own binaries dynamically against your own libgmp.3.dylib From Christian.Maeder at dfki.de Fri Jul 24 11:23:38 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 11:05:07 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69D0D3.1060305@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <20090724135755.GB4845@matrix.chaos.earth.li> <4A69D0D3.1060305@dfki.de> Message-ID: <4A69D1FA.2000504@dfki.de> Christian Maeder wrote: > Could you also remove (or correct) the line > "It needs libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/" > for both Mac dists, because I've included gmp statically. Please also correct: My PowerPC dists works on Leopard only not on Tiger! Christian From Christian.Maeder at dfki.de Fri Jul 24 11:26:44 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 24 11:08:12 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090724135755.GB4845@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <20090724135755.GB4845@matrix.chaos.earth.li> Message-ID: <4A69D2B4.7010608@dfki.de> Ian Lynagh wrote: > On Wed, Jul 22, 2009 at 11:35:07AM +0200, Christian Maeder wrote: >> Ian Lynagh wrote: >>> ============================================================== >>> The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 >>> ============================================================== >>> Packages will appear as they are built - if the package for your >>> system isn't available yet, please try again later. >> I've built [bindists] > > Thanks! All now added to the download page. The sparc dist will not run under Solaris 8 or 9, since it was built under Solaris 10. It should work for (Open) Solaris 11, though. C. From jgbailey at gmail.com Fri Jul 24 15:02:31 2009 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Jul 24 14:44:12 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? Message-ID: I apologize in advance for the vagueness of my report here - it's one of those situations I'm not sure how to cut it down to size yet. I have a module that uses HaskellDB and Template Haskell together. The module itself depends on 23 other modules, each of which give a type definition for a particular database table or view. I only mention that to emphasize that the module depends on some "big" types (HList records w/ 20+ members) and on compile-time generated code. My problem is this - when GHC compile the module, it consumes 1.2 GB of memory, takes about 10 minutes, and finally produces an object file. The memory usage seems related to template haskell, but I'm not positive. I've attached verbose output from compiling the module in question. The command line I used was: ghc -v --make -c DeliveryManagementQueries.hs -XEmptyDataDecls -XTypeSynonymInstances -XTemplateHa skell Now for my question - please ignore the specifics of haskelldb/template haskell - any suggestions for figuring out what GHC is doing, besides tried-and-true divide and conquer? Justin -------------- next part -------------- Glasgow Haskell Compiler, Version 6.10.2, for Haskell 98, stage 2 booted by GHC version 6.10.1 Using package config file: C:\Program Files\Haskell Platform\2009.2.0\ghc-6.10.2\package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *DeliveryManagementQueries.hs Stable obj: [DM.Pts_dlvry_stat_list_v, DM.Pts_dlvry_order_hdr_emp_v, DM.Pts_dlvry_carryover_v, DM.Pts_dlvry_carrier_flight_v, DM.Pts_dlvry_ship_via_v, DM.Pts_dlvry_carrier_v, DM.Pts_dlvry_order_hdr_pend_mnfst_v, DM.Pts_dlvry_mnfst_dtl_v, DM.Pts_dlvry_mnfst_hdr_v, DM.Pts_dm_event_dtl, DM.Pts_dm_event_hdr, DM.Pts_pull_order_dtl_v, DM.Pts_pull_order_hdr_v, DM.Pts_dlvry_order_dtl_v, DM.Pts_dlvry_order_hdr_v, DM.Pts_dlvry_order_dtl, DM.Pts_dlvry_order_hdr, DM.Pts_dlvry_status_v] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Wed Jul 22 15:49:20 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_status_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_hdr, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_dtl, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_hdr_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_dtl_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:51 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_pull_order_hdr_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:51 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_pull_order_dtl_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Wed Jul 22 11:44:35 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dm_event_hdr, ms_imps = [ADP.EasySQL.AppModel, Database.HaskellDB, Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Wed Jul 22 11:44:58 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dm_event_dtl, ms_imps = [ADP.EasySQL.AppModel, Database.HaskellDB, Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_mnfst_hdr_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_mnfst_dtl_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_hdr_pend_mnfst_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:49 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_carrier_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:51 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_ship_via_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:49 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_carrier_flight_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:49 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_carryover_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:50 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_order_hdr_emp_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Mon Jul 20 15:34:51 Pacific Daylight Time 2009 ms_mod = main:DM.Pts_dlvry_stat_list_v, ms_imps = [Database.HaskellDB.DBLayout] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Thu Jul 23 17:18:18 Pacific Daylight Time 2009 ms_mod = main:DeliveryManagementQueries, ms_imps = [DM.Pts_dlvry_stat_list_v, DM.Pts_dlvry_stat_list_v, DM.Pts_dlvry_order_hdr_emp_v, DM.Pts_dlvry_order_hdr_emp_v, DM.Pts_dlvry_carryover_v, DM.Pts_dlvry_carryover_v, DM.Pts_dlvry_carrier_flight_v, DM.Pts_dlvry_carrier_flight_v, DM.Pts_dlvry_ship_via_v, DM.Pts_dlvry_ship_via_v, DM.Pts_dlvry_carrier_v, DM.Pts_dlvry_carrier_v, DM.Pts_dlvry_order_hdr_pend_mnfst_v, DM.Pts_dlvry_order_hdr_pend_mnfst_v, DM.Pts_dlvry_mnfst_dtl_v, DM.Pts_dlvry_mnfst_dtl_v, DM.Pts_dlvry_mnfst_hdr_v, DM.Pts_dlvry_mnfst_hdr_v, DM.Pts_dm_event_dtl, DM.Pts_dm_event_dtl, DM.Pts_dm_event_hdr, DM.Pts_dm_event_hdr, DM.Pts_pull_order_dtl_v, DM.Pts_pull_order_dtl_v, DM.Pts_pull_order_hdr_v, DM.Pts_pull_order_hdr_v, DM.Pts_dlvry_order_dtl_v, DM.Pts_dlvry_order_dtl_v, DM.Pts_dlvry_order_hdr_v, DM.Pts_dlvry_order_hdr_v, DM.Pts_dlvry_order_dtl, DM.Pts_dlvry_order_dtl, DM.Pts_dlvry_order_hdr, DM.Pts_dlvry_order_hdr, DM.Pts_dlvry_status_v, DM.Pts_dlvry_status_v, ADP.EasySQL.DataSetM, ADP.EasySQL.QueryM, ADP.EasySQL.TableM, ADP.EasySQL.AppModelM, Database.HaskellDB.BoundedString, Data.HList, Data.HList.HListPrelude, Data.HList.TypeCastGeneric1, Database.HDBC.ColTypes, Database.HaskellDB.CodeGen, Database.HaskellDB.BoundedList, Database.HaskellDB.PrintQuery, Database.HaskellDB.PrimQuery, Database.HaskellDB.Query, Database.HaskellDB.DBLayout, Database.HaskellDB, Prelude] ms_srcimps = [] }] compile: input file .\DM\Pts_dlvry_status_v.hs Created temporary directory: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0 *** Checking old interface for main:DM.Pts_dlvry_status_v: [ 1 of 19] Skipping DM.Pts_dlvry_status_v ( DM\Pts_dlvry_status_v.hs, DM\Pts_dlvry_status_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_hdr.hs *** Checking old interface for main:DM.Pts_dlvry_order_hdr: [ 2 of 19] Skipping DM.Pts_dlvry_order_hdr ( DM\Pts_dlvry_order_hdr.hs, DM\Pts_dlvry_order_hdr.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_dtl.hs *** Checking old interface for main:DM.Pts_dlvry_order_dtl: [ 3 of 19] Skipping DM.Pts_dlvry_order_dtl ( DM\Pts_dlvry_order_dtl.hs, DM\Pts_dlvry_order_dtl.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_hdr_v.hs *** Checking old interface for main:DM.Pts_dlvry_order_hdr_v: [ 4 of 19] Skipping DM.Pts_dlvry_order_hdr_v ( DM\Pts_dlvry_order_hdr_v.hs, DM\Pts_dlvry_order_hdr_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_dtl_v.hs *** Checking old interface for main:DM.Pts_dlvry_order_dtl_v: [ 5 of 19] Skipping DM.Pts_dlvry_order_dtl_v ( DM\Pts_dlvry_order_dtl_v.hs, DM\Pts_dlvry_order_dtl_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_pull_order_hdr_v.hs *** Checking old interface for main:DM.Pts_pull_order_hdr_v: [ 6 of 19] Skipping DM.Pts_pull_order_hdr_v ( DM\Pts_pull_order_hdr_v.hs, DM\Pts_pull_order_hdr_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_pull_order_dtl_v.hs *** Checking old interface for main:DM.Pts_pull_order_dtl_v: [ 7 of 19] Skipping DM.Pts_pull_order_dtl_v ( DM\Pts_pull_order_dtl_v.hs, DM\Pts_pull_order_dtl_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dm_event_hdr.hs *** Checking old interface for main:DM.Pts_dm_event_hdr: [ 8 of 19] Skipping DM.Pts_dm_event_hdr ( DM\Pts_dm_event_hdr.hs, DM\Pts_dm_event_hdr.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dm_event_dtl.hs *** Checking old interface for main:DM.Pts_dm_event_dtl: [ 9 of 19] Skipping DM.Pts_dm_event_dtl ( DM\Pts_dm_event_dtl.hs, DM\Pts_dm_event_dtl.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_mnfst_hdr_v.hs *** Checking old interface for main:DM.Pts_dlvry_mnfst_hdr_v: [10 of 19] Skipping DM.Pts_dlvry_mnfst_hdr_v ( DM\Pts_dlvry_mnfst_hdr_v.hs, DM\Pts_dlvry_mnfst_hdr_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_mnfst_dtl_v.hs *** Checking old interface for main:DM.Pts_dlvry_mnfst_dtl_v: [11 of 19] Skipping DM.Pts_dlvry_mnfst_dtl_v ( DM\Pts_dlvry_mnfst_dtl_v.hs, DM\Pts_dlvry_mnfst_dtl_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_hdr_pend_mnfst_v.hs *** Checking old interface for main:DM.Pts_dlvry_order_hdr_pend_mnfst_v: [12 of 19] Skipping DM.Pts_dlvry_order_hdr_pend_mnfst_v ( DM\Pts_dlvry_order_hdr_pend_mnfst_v.hs, DM\Pts_dlvry_order_hdr_pend_mnfst_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_carrier_v.hs *** Checking old interface for main:DM.Pts_dlvry_carrier_v: [13 of 19] Skipping DM.Pts_dlvry_carrier_v ( DM\Pts_dlvry_carrier_v.hs, DM\Pts_dlvry_carrier_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_ship_via_v.hs *** Checking old interface for main:DM.Pts_dlvry_ship_via_v: [14 of 19] Skipping DM.Pts_dlvry_ship_via_v ( DM\Pts_dlvry_ship_via_v.hs, DM\Pts_dlvry_ship_via_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_carrier_flight_v.hs *** Checking old interface for main:DM.Pts_dlvry_carrier_flight_v: [15 of 19] Skipping DM.Pts_dlvry_carrier_flight_v ( DM\Pts_dlvry_carrier_flight_v.hs, DM\Pts_dlvry_carrier_flight_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_carryover_v.hs *** Checking old interface for main:DM.Pts_dlvry_carryover_v: [16 of 19] Skipping DM.Pts_dlvry_carryover_v ( DM\Pts_dlvry_carryover_v.hs, DM\Pts_dlvry_carryover_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_order_hdr_emp_v.hs *** Checking old interface for main:DM.Pts_dlvry_order_hdr_emp_v: [17 of 19] Skipping DM.Pts_dlvry_order_hdr_emp_v ( DM\Pts_dlvry_order_hdr_emp_v.hs, DM\Pts_dlvry_order_hdr_emp_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file .\DM\Pts_dlvry_stat_list_v.hs *** Checking old interface for main:DM.Pts_dlvry_stat_list_v: [18 of 19] Skipping DM.Pts_dlvry_stat_list_v ( DM\Pts_dlvry_stat_list_v.hs, DM\Pts_dlvry_stat_list_v.o ) *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Warning: deleting non-existent C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s compile: input file DeliveryManagementQueries.hs *** Checking old interface for main:DeliveryManagementQueries: [19 of 19] Compiling DeliveryManagementQueries ( DeliveryManagementQueries.hs, DeliveryManagementQueries.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: 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.1 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size = 616969 *** Simplify: Result size = 538498 Result size = 538331 *** Tidy Core: Result size = 538331 writeBinIface: 321 Names writeBinIface: 460 dict entries *** CorePrep: Result size = 540901 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: C:\Program Files\Haskell Platform\2009.2.0\ghc-6.10.2\gcc -BC:\Program Files\Haskell Platform\2009.2.0\ghc-6.10.2\gcc-lib/ -IC:\Program Files\Haskell Platform\2009.2.0\ghc-6.10.2\include/mingw -I. -c C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s -o DeliveryManagementQueries.o *** Deleting temp files: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0/ghc3908_0.s Upsweep completely successful. *** Deleting temp files: Deleting: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: C:\DOCUME~1\baileyj\LOCALS~1\Temp\/ghc3908_0 Loading package template-haskell ... linking ... done. Loading package HList-0.1.1 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package haskelldb-1.0 ... linking ... done. Loading package haskelldb-th-1.2 ... linking ... done. From dons at galois.com Fri Jul 24 17:02:35 2009 From: dons at galois.com (Don Stewart) Date: Fri Jul 24 16:45:57 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? In-Reply-To: References: Message-ID: <20090724210235.GG4547@whirlpool.galois.com> jgbailey: > I apologize in advance for the vagueness of my report here - it's one > of those situations I'm not sure how to cut it down to size yet. > > I have a module that uses HaskellDB and Template Haskell together. The > module itself depends on 23 other modules, each of which give a type > definition for a particular database table or view. I only mention > that to emphasize that the module depends on some "big" types (HList > records w/ 20+ members) and on compile-time generated code. > > My problem is this - when GHC compile the module, it consumes 1.2 GB > of memory, takes about 10 minutes, and finally produces an object > file. The memory usage seems related to template haskell, but I'm not > positive. > > I've attached verbose output from compiling the module in question. > The command line I used was: > > ghc -v --make -c DeliveryManagementQueries.hs -XEmptyDataDecls > -XTypeSynonymInstances -XTemplateHa > skell > > Now for my question - please ignore the specifics of > haskelldb/template haskell - any suggestions for figuring out what GHC > is doing, besides tried-and-true divide and conquer? > Oh, and I note you're not using -O or -O2 either? -- Don From jgbailey at gmail.com Fri Jul 24 17:52:03 2009 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Jul 24 17:33:44 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? In-Reply-To: <20090724210235.GG4547@whirlpool.galois.com> References: <20090724210235.GG4547@whirlpool.galois.com> Message-ID: On Fri, Jul 24, 2009 at 2:02 PM, Don Stewart wrote: > Oh, and I note you're not using -O or -O2 either? > > -- Don > This is a compile time problem, wouldn't -O make it worse? Justin From dons at galois.com Fri Jul 24 17:51:38 2009 From: dons at galois.com (Don Stewart) Date: Fri Jul 24 17:35:01 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? In-Reply-To: References: <20090724210235.GG4547@whirlpool.galois.com> Message-ID: <20090724215138.GN4547@whirlpool.galois.com> jgbailey: > On Fri, Jul 24, 2009 at 2:02 PM, Don Stewart wrote: > > Oh, and I note you're not using -O or -O2 either? > > > > -- Don > > > > This is a compile time problem, wouldn't -O make it worse? Almost certainly! From jgbailey at gmail.com Fri Jul 24 18:01:22 2009 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Jul 24 17:43:03 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? In-Reply-To: <20090724215138.GN4547@whirlpool.galois.com> References: <20090724210235.GG4547@whirlpool.galois.com> <20090724215138.GN4547@whirlpool.galois.com> Message-ID: Ironically adding -O does reduce the compile time in this case. I shouldn't have been so quick to reply! On Fri, Jul 24, 2009 at 2:51 PM, Don Stewart wrote: > jgbailey: >> On Fri, Jul 24, 2009 at 2:02 PM, Don Stewart wrote: >> > Oh, and I note you're not using -O or -O2 either? >> > >> > -- Don >> > >> >> This is a compile time problem, wouldn't -O make it worse? > > Almost certainly! > From Christian.Maeder at dfki.de Sat Jul 25 13:47:42 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Sat Jul 25 13:29:02 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69ADBA.6090000@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A699BCE.5030500@gmail.com> <4A69A6C3.9080105@dfki.de> <4A69AB8A.2030106@gmail.com> <4A69ADBA.6090000@dfki.de> Message-ID: <4A6B453E.50206@dfki.de> Christian Maeder wrote: > For some reason a ghc-mtl was built when compiling from source. Also > haskeline-0.6.1.5, terminfo and test is no package later on. This test-1.0 package contains module A and was installed by test case cabal01(normal) that failed with the "Syntax: tar {c|r|t|u|x}" error and later on caused the difference/failure for driver063(normal) exposed-modules: A hidden-modules: B.A import-dirs: /export/local1/home/maeder/haskell/ghc-6.10.4/testsuite-6.10.4/tests/ghc-regress/cabal/cabal01/install/lib/test-1.0/ghc-6.10.4 (Just to explain the driver063 failure) Cheers Christian > -bash-3.00$ utils/ghc-pkg/install-inplace/bin/ghc-pkg list > /export/local1/home/maeder/haskell/ghc-6.10.4/inplace-datadir/./package.conf: > Cabal-1.6.0.3, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0, > base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, > directory-1.0.0.3, (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), extensible-exceptions-0.1.1.0, filepath-1.1.0.2, > (ghc-6.10.4), ghc-mtl-1.1.0.2, ghc-prim-0.1.0.0, haddock-2.4.2, > haskeline-0.6.1.5, haskell-src-1.0.1.3, haskell98-1.0.1.0, > hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, > network-2.2.1.2, old-locale-1.0.0.1, old-time-1.0.0.2, > packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, > pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, > regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, > rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, > terminfo-0.3.1, test-1.0, time-1.1.4, unix-2.3.2.0, > utf8-string-0.3.4, xhtml-3000.2.0.1 > /home/maeder/.ghc/i386-solaris2-6.10.4/package.conf: > {HAIFA-0.12}, programatica-1.0, syb-generics-2.9 From igloo at earth.li Sun Jul 26 08:48:37 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 08:29:55 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69D0D3.1060305@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <20090724135755.GB4845@matrix.chaos.earth.li> <4A69D0D3.1060305@dfki.de> Message-ID: <20090726124837.GA23437@matrix.chaos.earth.li> On Fri, Jul 24, 2009 at 05:18:43PM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > > On Wed, Jul 22, 2009 at 11:35:07AM +0200, Christian Maeder wrote: > >> Ian Lynagh wrote: > >>> ============================================================== > >>> The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 > >>> ============================================================== > >>> Packages will appear as they are built - if the package for your > >>> system isn't available yet, please try again later. > >> I've built [bindists] > > > > Thanks! All now added to the download page. > > Could you also remove (or correct) the line I've applied your 3 changes. Thanks Ian From igloo at earth.li Sun Jul 26 09:10:02 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 08:51:20 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A69C7B9.8030908@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> <4A699101.3080803@dfki.de> <20090724135607.GA4845@matrix.chaos.earth.li> <4A69C7B9.8030908@dfki.de> Message-ID: <20090726131002.GA23598@matrix.chaos.earth.li> On Fri, Jul 24, 2009 at 04:39:53PM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > >> This error refers to the line > >> > >> $(eval $(call canonicalise,PREFIX)) > >> > >> in timeout/Makefile. > > > > Hmm, this test: > > ------------- > > HAVE_EVAL := NO > > $(eval HAVE_EVAL := YES) > > > > ifeq "$(HAVE_EVAL)" "NO" > > $(error Your make does not support eval. You need GNU make >= 3.80) > > endif > > ------------- > > in testsuite/mk/boilerplate.mk is supposed to fail if running the > > testsuite would fail, so I don't know what's gone wrong there. If you > > work out what else is breaking then let me know and we can add a test > > for it. > > eval works, but abspath does not! Does make give the expected abspath error with this patch to testsuite/? hunk ./mk/boilerplate.mk 8 -$(error Your make does not support eval. You need GNU make >= 3.80) +$(error Your make does not support eval. You need GNU make >= 3.81) +endif + +ifeq "$(abspath /)" "" +$(error Your make does not support abspath. You need GNU make >= 3.81) Thanks Ian From igloo at earth.li Sun Jul 26 10:14:54 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 09:56:10 2009 Subject: can we bootstrap GHC 6.x? In-Reply-To: <5c7d4fb80907240743g4a31ffecq17a51e40d8c11358@mail.gmail.com> References: <5c7d4fb80907240743g4a31ffecq17a51e40d8c11358@mail.gmail.com> Message-ID: <20090726141454.GA25846@matrix.chaos.earth.li> On Fri, Jul 24, 2009 at 10:43:46PM +0800, Shu Wu wrote: > Hi buddies. I've been looking for methods to bootstrap GHC 6.10 but with no > luck. It seems GHC 5.0 is the last version that provides HC source for > bootstrapping. I think, however, bootstrapping GHC above 6.x is still > necessary. > First, it will be easier to build GHC on a new platform, eg, OpenSolaris. We have a procedure for porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting It's not perfectly smooth, and it's a bit of hassle, but you only need to do it once for each platform. > Second, compiling GHC from strap is the only way to go into OpenSolaris' > official package repository, since all packages for OpenSolaris are built by > Source Juicer (http://jucr.opensolaris.org/home/) from pure source code, and > there can't be any pre-installed GHC on Source Juicer Build Grid. We recommend that distributions bootstrap GHC from a binary, in the same way that they bootstrap gcc. Thanks Ian From aslatter at gmail.com Sun Jul 26 16:09:42 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Jul 26 15:50:58 2009 Subject: Working with GHC HEAD Message-ID: <694519c50907261309j77162c91vd973b7ce2dc01558@mail.gmail.com> Folks, I was trying to see what GHC head was like, but I've run into a few snags compiling packages. My existing binary for cabal-install can install quite a few packages, but then starts giving me strange errors eventually: >>> $ cabal --version cabal-install version 0.6.2 using version 1.6.0.1 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.11.20090724 $ cabal install zlib Resolving dependencies... Configuring zlib-0.5.2.0... ghc-stage2: /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf:6:163: parse error on input `Nothing' cabal: Error: some packages failed to install: zlib-0.5.2.0 failed during the configure step. The exception was: exit: ExitFailure 1 <<< If I then do: >>> $ mv /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf.back $ cabal install zlib <<< Everything works great. After looking at the package.conf being complained about, the last line looks like so: >>> InstalledPackageInfo {package = PackageIdentifier {pkgName = PackageName "cpphs", pkgVersion = Version {versionBranch = [1,7], versionTags = []}}, license = LGPL Nothing, copyright = "2004-8, Malcolm Wallace", maintainer = "Malcolm Wallace ", author = ... <<< Not the license field of the package info - we have "license = LGPL Nothing, copright ...". I thought that maybe since GHC head ships with the new dev version of Cabal, I need the dev version of cabal-install to properly install packages. However cabal-install (and most of the things I want to test out) require the 'network' package, which doesn't build against GHC head (System.Posix.Internals doesn't exist, and the functionality that 'network' uses from there now lives in GHC.IO.* and is much changed). So a few things: - Should I expect the stable version of cabal-install built against GHC 6.10 to work for head? Are the errors I'm getting expected? - Does anyone have a version of 'network' which builds against GHC head? I could bludgeon in the new GHC.IO.FD.FD type myself, but I'd thought I'd ask around first. Thanks, Antoine From aslatter at gmail.com Sun Jul 26 23:50:03 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Jul 26 23:31:19 2009 Subject: Working with GHC HEAD In-Reply-To: <694519c50907261309j77162c91vd973b7ce2dc01558@mail.gmail.com> References: <694519c50907261309j77162c91vd973b7ce2dc01558@mail.gmail.com> Message-ID: <694519c50907262050u7f36997ft7c401f832588ce8f@mail.gmail.com> On Sun, Jul 26, 2009 at 3:09 PM, Antoine Latter wrote: > >>>> > $ cabal --version > cabal-install version 0.6.2 > using version 1.6.0.1 of the Cabal library > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.11.20090724 > > $ cabal install zlib > Resolving dependencies... > Configuring zlib-0.5.2.0... > ghc-stage2: /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf:6:163: > ? ?parse error on input `Nothing' > cabal: Error: some packages failed to install: > zlib-0.5.2.0 failed during the configure step. The exception was: > exit: ExitFailure 1 > <<< > I finally noticed that the error is coming from the new GHC executable, not the cabal-install executable. So building the new version won't help me, as evidenced by trying to run 'ghci' in this state: >>> $ ghci GHCi, version 6.11.20090724: http://www.haskell.org/ghc/ :? for help ghc-stage2: /home/alatter/usr/lib/ghc-6.11.20090724/package.conf:40:168: parse error on input `Nothing' <<< It looks like I'm not allowed to install any GPL or LGPL licensed software with Cabal :-) Antoine From Christian.Maeder at dfki.de Mon Jul 27 04:39:07 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jul 27 04:20:24 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <20090726131002.GA23598@matrix.chaos.earth.li> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> <4A699101.3080803@dfki.de> <20090724135607.GA4845@matrix.chaos.earth.li> <4A69C7B9.8030908@dfki.de> <20090726131002.GA23598@matrix.chaos.earth.li> Message-ID: <4A6D67AB.30101@dfki.de> Ian Lynagh wrote: > On Fri, Jul 24, 2009 at 04:39:53PM +0200, Christian Maeder wrote: >> eval works, but abspath does not! > > Does make give the expected abspath error with this patch to testsuite/? Yes: -bash-3.00$ gmake mk/boilerplate.mk:12: *** Your make does not support abspath. You need GNU make >= 3.81. Stop. C. > > hunk ./mk/boilerplate.mk 8 > -$(error Your make does not support eval. You need GNU make >= 3.80) > +$(error Your make does not support eval. You need GNU make >= 3.81) > +endif > + > +ifeq "$(abspath /)" "" > +$(error Your make does not support abspath. You need GNU make >= 3.81) > > > Thanks > Ian > From marlowsd at gmail.com Mon Jul 27 08:17:44 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 27 07:59:00 2009 Subject: GHC 6.10.2 consuming lots of memory while compiling - help? In-Reply-To: References: <20090724210235.GG4547@whirlpool.galois.com> <20090724215138.GN4547@whirlpool.galois.com> Message-ID: <4A6D9AE8.3010707@gmail.com> On 24/07/2009 23:01, Justin Bailey wrote: > On Fri, Jul 24, 2009 at 2:51 PM, Don Stewart wrote: >> jgbailey: >>> On Fri, Jul 24, 2009 at 2:02 PM, Don Stewart wrote: >>>> Oh, and I note you're not using -O or -O2 either? >>>> >>>> -- Don >>>> >>> >>> This is a compile time problem, wouldn't -O make it worse? >> >> Almost certainly! >> > Ironically adding -O does reduce the compile time in this case. I > shouldn't have been so quick to reply! > -O may reduce compilation time by simplifying the code. It's rare in practice, but more likely to happen when you're dealing with a lot of automatically-generated code. To answer the original question, there are various debugging options that will give you an idea of what GHC is up to: -ddump-rn-trace, -ddump-tc-trace -ddump-splices. And +RTS -hT -RTS will give you a heap profile of GHC, which might provide more clues (though matching the profile with what GHC was doing at the time is mostly guesswork). If you think there's something we ought to investigate here, please make a self-contained test case and attach it to a ticket. Cheers, Simon From marlowsd at gmail.com Mon Jul 27 08:21:55 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 27 08:03:10 2009 Subject: Working with GHC HEAD In-Reply-To: <694519c50907261309j77162c91vd973b7ce2dc01558@mail.gmail.com> References: <694519c50907261309j77162c91vd973b7ce2dc01558@mail.gmail.com> Message-ID: <4A6D9BE3.1090209@gmail.com> On 26/07/2009 21:09, Antoine Latter wrote: > Folks, > > I was trying to see what GHC head was like, but I've run into a few > snags compiling packages. > > My existing binary for cabal-install can install quite a few packages, > but then starts giving me strange errors eventually: > >>>> > $ cabal --version > cabal-install version 0.6.2 > using version 1.6.0.1 of the Cabal library > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.11.20090724 > > $ cabal install zlib > Resolving dependencies... > Configuring zlib-0.5.2.0... > ghc-stage2: /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf:6:163: > parse error on input `Nothing' > cabal: Error: some packages failed to install: > zlib-0.5.2.0 failed during the configure step. The exception was: > exit: ExitFailure 1 > <<< > > If I then do: > >>>> > $ mv /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf > /home/alatter/.ghc/x86_64-linux-6.11.20090724/package.conf.back > > $ cabal install zlib > <<< > > Everything works great. > > After looking at the package.conf being complained about, the last > line looks like so: > >>>> > InstalledPackageInfo {package = PackageIdentifier {pkgName = > PackageName "cpphs", pkgVersion = Version {versionBranch = [1,7], > versionTags = []}}, license = LGPL Nothing, copyright = "2004-8, > Malcolm Wallace", maintainer = "Malcolm Wallace > ", author = ... > <<< > > Not the license field of the package info - we have "license = LGPL > Nothing, copright ...". > > I thought that maybe since GHC head ships with the new dev version of > Cabal, I need the dev version of cabal-install to properly install > packages. However cabal-install (and most of the things I want to test > out) require the 'network' package, which doesn't build against GHC > head (System.Posix.Internals doesn't exist, and the functionality that > 'network' uses from there now lives in GHC.IO.* and is much changed). > > So a few things: > > - Should I expect the stable version of cabal-install built against > GHC 6.10 to work for head? Are the errors I'm getting expected? Yes, you'll need a new cabal-install built against the version of Cabal that comes with GHC HEAD. > - Does anyone have a version of 'network' which builds against GHC > head? I could bludgeon in the new GHC.IO.FD.FD type myself, but I'd > thought I'd ask around first. Not that I know of. This is something that needs to be done for the first platform release after GHC 6.12.1, but preferably earlier in case there are any changes we need to make in base. Cheers, Simon From reiner.pope at gmail.com Tue Jul 28 03:29:58 2009 From: reiner.pope at gmail.com (Reiner Pope) Date: Tue Jul 28 03:11:09 2009 Subject: [reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties] In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C34B7F594DE9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090720163746.GC15846@whirlpool.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C34B7F594DE9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4cf038ee0907280029g7f269b04r324470b057a6930@mail.gmail.com> Thanks for following this up. Reiner 2009/7/22 Simon Peyton-Jones : > Thanks. ?You've found a bug in 6.10, which is happily fixed in the HEAD and in the upcoming 6.12. Here's the code for g2: > > Test.$s$wg2 = > ?\ (sc_soL :: GHC.Prim.Int#) (sc1_soM :: GHC.Prim.Int#) -> > ? ?case GHC.Prim.># sc_soL 10 of _ { > ? ? ?GHC.Bool.False -> > ? ? ? ?case GHC.Prim.<=# sc1_soM sc_soL of _ { > ? ? ? ? ?GHC.Bool.False -> Test.$s$wg2 (GHC.Prim.+# sc_soL 1) sc1_soM; > ? ? ? ? ?GHC.Bool.True -> Test.$s$wg2 (GHC.Prim.+# sc_soL 1) sc_soL > ? ? ? ?}; > ? ? ?GHC.Bool.True -> Test.Just @ GHC.Types.Int (GHC.Types.I# sc1_soM) > ? ?} > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- > | users-bounces@haskell.org] On Behalf Of Don Stewart > | Sent: 20 July 2009 17:38 > | To: glasgow-haskell-users@haskell.org > | Subject: [reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties] > | > | Something for SimonPJ > | > | ----- Forwarded message from Reiner Pope ----- > | > | Date: Mon, 20 Jul 2009 22:09:09 +0930 > | From: Reiner Pope > | To: Haskell Cafe mailing list > | Subject: [Haskell-cafe] SpecConstr difficulties > | > | Hi everyone, > | > | I've been having some trouble getting SpecConstr to work as I want it > | to. The following example (see end of email) came up in some code I > | was playing around with. The loops g1 and g2 both compute the same > | thing: the maximum element of the "list" (which has been fused away) > | of numbers from 1 to 10. > | > | Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as > | an accumulator. The Maybe gets filled after the first element is seen, > | so the Maybe is a Just for almost the entire running of the loop. > | > | It would be good to have this recognised by SpecConstr, to create an > | optimised loop for the Just case. This does indeed happen for g1, but > | not for g2. > | > | My difficulty is that I am only able to produce code similar to g2, > | i.e. where the pattern matching is in a separate function, 'expose', > | because the 'expose' function is implemented in a type-class, like in > | stream-fusion. Is there some way to keep the SpecConstr while leaving > | the 'expose' as a separate function? > | > | Here is the code: > | > | > {-# LANGUAGE BangPatterns #-} > | > > | > module Test(ans1,ans2) where > | > > | > import Prelude hiding(Maybe(..)) > | > > | > data Maybe a = Just !a | Nothing > | > > | > Nothing `mapp` Just b = Just b > | > Just a `mapp` Just b = Just (max a b) > | > > | > ans1 = g1 Nothing (0::Int) > | > > | > g1 m !n = case m of > | > ? ? ? ? ? ?Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > | > ? ? ? ? ? ?Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > | > > | > ans2 = g2 Nothing (0::Int) > | > > | > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) > | > expose Nothing ?b = b > | > expose (Just a) b = a `seq` b > | > | On a similar note, when I was having difficulties with this problem, I > | started to wonder if it would be possible to come up with a more > | direct way to tell GHC, "do SpecConstr on this variable". From reading > | the source code of the stream-fusion package, it seems that the > | current way of doing this is with 'expose' functions like I wrote > | below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used > | on function arguments, like: > | > | foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... > | > | This pragma should say to the GHC something like "ignore conditions > | H2, H5 and H6 of the SpecConstr paper, for this function and this > | argument". > | > | Cheers, > | Reiner > | _______________________________________________ > | Haskell-Cafe mailing list > | Haskell-Cafe@haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-cafe > | > | ----- End forwarded message ----- > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From igloo at earth.li Tue Jul 28 08:10:51 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 28 07:52:02 2009 Subject: more binary dists Re: ANNOUNCE: GHC version 6.10.4 In-Reply-To: <4A6D67AB.30101@dfki.de> References: <20090716144210.GA23789@matrix.chaos.earth.li> <4A66DD4B.4000600@dfki.de> <4A698B53.7000508@gmail.com> <4A699101.3080803@dfki.de> <20090724135607.GA4845@matrix.chaos.earth.li> <4A69C7B9.8030908@dfki.de> <20090726131002.GA23598@matrix.chaos.earth.li> <4A6D67AB.30101@dfki.de> Message-ID: <20090728121051.GA10308@matrix.chaos.earth.li> On Mon, Jul 27, 2009 at 10:39:07AM +0200, Christian Maeder wrote: > Ian Lynagh wrote: > > On Fri, Jul 24, 2009 at 04:39:53PM +0200, Christian Maeder wrote: > >> eval works, but abspath does not! > > > > Does make give the expected abspath error with this patch to testsuite/? > > Yes: > > -bash-3.00$ gmake > mk/boilerplate.mk:12: *** Your make does not support abspath. You need > GNU make >= 3.81. Stop. Thanks for testing; I've pushed it. Thanks Ian From pjdennis at gmail.com Wed Jul 29 01:29:47 2009 From: pjdennis at gmail.com (Phil Dennis) Date: Wed Jul 29 01:10:56 2009 Subject: Attempted install on Mac OS X - recent versions - FAIL Message-ID: <441dad160907282229r774743ecm1aaa00d675b2b51d@mail.gmail.com> I am looking for some assistance with installing GHC on Mac OS X. If there is a more appropriate place for me to ask, please let me know. I have tried, with no luck so far, the 2 different binary distributions of 6.10.4 provided for the Mac on the haskell.org ghc download page (http://www.haskell.org/ghc/download_ghc_6_10_4.html#macosxintel) I have OS X version 10.5.7 with XCode version 3.1.2 installed. When I run the installer (GHC-6.10.4-i386.pkg) I get as far as the "Installation Type" screen with the following text displayed: "Click Install to perform a standard installation of this software for all users of this computer". However the 'Install' button is greyed out and cannot be clicked. The last entries in the installer log are as follows: Jul 29 00:03:29 phil-denniss-macbook-pro Installer[11740]: Glasgow Haskell Compiler Installation Log Jul 29 00:03:29 phil-denniss-macbook-pro Installer[11740]: Opened from: /Users/pjdennis/Downloads/GHC-6.10.4-i386.pkg Jul 29 00:03:30 phil-denniss-macbook-pro installdb[11743]: started (uid 96) Jul 29 00:03:30 phil-denniss-macbook-pro installdb[11743]: Opened receipt database on '/' with schema 17. Jul 29 00:03:36 phil-denniss-macbook-pro installdb[11743]: done. (0.003u + 0.003s) ALSO I tried the binary distribution (ghc-6.10.4-i386-apple-darwin.tar.bz2) which I extracted, and then ran ./configure, as instructed in the INSTALL file. After adding /Developer/usr/bin to the path (so that the configure script could find the 'ar' program) I now get the following error from the configure script: configure: error: C compiler cannot create executables See `config.log' for more details. I have pasted some of what looks relevant from config.log, below. Any help with either one of the install methods for OS X would be much appreciated. I am keen to get started trying out Haskell, instead of mucking with installers. Regards, Phil Dennis --------------------------------------------------------------- >From config.log configure:2298: found /Developer/usr/bin/gcc configure:2309: result: gcc configure:2547: checking for C compiler version configure:2554: gcc --version >&5 i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2557: $? = 0 configure:2564: gcc -v >&5 Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c+ +/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5490) configure:2567: $? = 0 configure:2574: gcc -V >&5 gcc-4.0: argument to `-V' is missing configure:2577: $? = 1 configure:2600: checking for C compiler default output file name configure:2627: gcc conftest.c >&5 ld: library not found for -lcrt1.10.5.o collect2: ld returned 1 exit status configure:2630: $? = 1 configure:2668: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2675: error: C compiler cannot create executables See `config.log' for more details. From pjdennis at gmail.com Wed Jul 29 02:17:25 2009 From: pjdennis at gmail.com (Phil Dennis) Date: Wed Jul 29 01:58:38 2009 Subject: Attempted install on Mac OS X - recent versions - FAIL In-Reply-To: <441dad160907282229r774743ecm1aaa00d675b2b51d@mail.gmail.com> References: <441dad160907282229r774743ecm1aaa00d675b2b51d@mail.gmail.com> Message-ID: <441dad160907282317h4497e203k6fd94be10cb0abfc@mail.gmail.com> On Wed, Jul 29, 2009 at 12:29 AM, Phil Dennis wrote: > I am looking for some assistance with installing GHC on Mac OS X. Never mind, I solved my own problem. I had XCode installed but had done this via the iPhone SDK and had NOT installed the "Unix Development Support". After reinstalling the iPhone SDK, this time including "Unix Development Support" I was able to run the GHC 6.10.4 installer and now have a working Haskell environment. From Christian.Maeder at dfki.de Thu Jul 30 09:12:56 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jul 30 08:54:03 2009 Subject: Haskell Platform 2009.2.0.2 In-Reply-To: <20090729174205.GB18734@whirlpool.galois.com> References: <20090729174205.GB18734@whirlpool.galois.com> Message-ID: <4A719C58.2080700@dfki.de> Don Stewart wrote: > Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2 > > http://code.haskell.org/haskell-platform/haskell-platform.cabal I still see time ==1.1.2.4, although ghc-6.10.4 comes with: time-1.1.4 http://trac.haskell.org/haskell-platform/ticket/74 Is this on purpose (possibly installing two time versions)? I only know that time-1.1.4 and time-1.1.3 supply more Typeable instances (which may break existing code) Cheers Christian