From simonpj at microsoft.com Wed Apr 1 02:53:51 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Apr 1 02:41:05 2009 Subject: GADTs with strict fields? In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507F34F04@EA-EXMSG-C334.europe.corp.microsoft.com> Yes it's documented in the user manual http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#gadt-style Since you didn't find it, despite looking, can you suggest how we could improve the manual so that you would? Thanks Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 01 April 2009 00:54 To: glasgow-haskell-users@haskell.org Subject: Re: GADTs with strict fields? I got an answer: precede the argument types by a "!". I didn't realize that type applications then have to be parenthesized. On Tue, Mar 31, 2009 at 4:18 PM, Conal Elliott > wrote: Do strict fields work with GADTs? If so, what's the syntax for the strictness annotations? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090401/adfdfa6b/attachment.htm From marlowsd at gmail.com Wed Apr 1 05:41:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 1 05:29:17 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> Message-ID: <49D336E4.2060307@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> Colin Paul Adams wrote: > >>>>>>> "Simon" == Simon Marlow writes: > >> > >> >> 6.11.20090319 (formerly bootstrapped from 6.10.1). > >> > Simon> Ah, there's your problem. In general you can't bootstrap > Simon> GHC using a development snapshot, we only support building > Simon> using fixed released versions. > >> > >> So I re-installed ghc 6.10.1. > >> > >> Same problem. > >> > >> N.B. haddock --version now reports 2.3.0 > > Simon> I have to ask - you did do a complete 'make distclean' > Simon> etc. before rebuilding? > > I did. > > Simon> If so, could you send me a complete log of the build. > > My xterm window doesn't have a big enough buffer. Should I run the > complete procedure (starting with make distclean) all over again, > diverting output and error to a file? Yes, I normally do it like this: 'make |& tee log' (or if you're using an impoverished shell, 'make 2>&1 | tee log'). The build seems to be working smoothly for most people at the moment, so I'm fairly sure this is something specific to your setup somehow. Could you check for things like local changes: $ ./darcs-all w -s $ ./push-all http://darcs.haskell.org/ --dry-run Cheers, Simon From colin at colina.demon.co.uk Wed Apr 1 08:41:13 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 1 08:28:26 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D336E4.2060307@gmail.com> (Simon Marlow's message of "Wed\, 01 Apr 2009 10\:41\:56 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> $ ./darcs-all w -s Only: == running darcs w -s --repodir . M ./compiler/ghc.cabal.in -5 +6 M ./compiler/main/DynFlags.hs +4 M ./compiler/main/GHC.hs +1 M ./compiler/main/HscTypes.lhs -1 +1 M ./compiler/rename/RnSource.lhs +3 M ./compiler/simplCore/SimplCore.lhs -4 +4 which is what I expect. Nothing that touches Haddock, as far as I know. Simon> $ ./push-all http://darcs.haskell.org/ --dry-run == running darcs push --no-set-default http://darcs.haskell.org//ghc --dry-run --repodir . NOTE: Pushing to http URLs is not supported. You may be able to hack this to work using DARCS_APPLY_HTTP Would push the following changes: Fri Mar 27 19:06:16 GMT 2009 colin@colina.demon.co.uk * Incorporated ESC/Haskell was all that was found. That's the comment for the changes above. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Wed Apr 1 10:53:29 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 1 10:40:46 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> Message-ID: <49D37FE9.1060500@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> $ ./darcs-all w -s > > Only: > > == running darcs w -s --repodir . > M ./compiler/ghc.cabal.in -5 +6 > M ./compiler/main/DynFlags.hs +4 > M ./compiler/main/GHC.hs +1 > M ./compiler/main/HscTypes.lhs -1 +1 > M ./compiler/rename/RnSource.lhs +3 > M ./compiler/simplCore/SimplCore.lhs -4 +4 Is it possible that you changed the exports of the GHC module, perhaps? Haddock is complaining about a name class with maybeParen from the GHC module, but I can't see how maybeParen is exported from GHC, unless that's something you changed. Cheers, Simon From colin at colina.demon.co.uk Wed Apr 1 11:13:10 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 1 11:00:24 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D37FE9.1060500@gmail.com> (Simon Marlow's message of "Wed\, 01 Apr 2009 15\:53\:29 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> <49D37FE9.1060500@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Is it possible that you changed the exports of the GHC Simon> module, perhaps? Haddock is complaining about a name class Simon> with maybeParen from the GHC module, but I can't see how Simon> maybeParen is exported from GHC, unless that's something Simon> you changed. Maybe by accident. How do I do a diff for ghc/ghc.cabal.in against the online repository? If I search for maybeParen in the added modules, I can only find one occurrence, and that is in a commented-out functions. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Wed Apr 1 11:58:04 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 1 11:45:19 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> <49D37FE9.1060500@gmail.com> Message-ID: <49D38F0C.2000302@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> Is it possible that you changed the exports of the GHC > Simon> module, perhaps? Haddock is complaining about a name class > Simon> with maybeParen from the GHC module, but I can't see how > Simon> maybeParen is exported from GHC, unless that's something > Simon> you changed. > > Maybe by accident. How do I do a diff for ghc/ghc.cabal.in > against the online repository? darcs w ghc/ghc.cabal.in that shows your local changes. > If I search for maybeParen in the added modules, I can only find one > occurrence, and that is in a commented-out functions. start with 'darcs w' - I noticed you had a 1-line change to GHC.hs, what was that? Also you had a local patch "Incorporated ESC/Haskell", perhaps that made some changes? Cheers, Simon From colin at colina.demon.co.uk Wed Apr 1 12:12:20 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 1 11:59:31 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D38F0C.2000302@gmail.com> (Simon Marlow's message of "Wed\, 01 Apr 2009 16\:58\:04 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> <49D37FE9.1060500@gmail.com> <49D38F0C.2000302@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> start with 'darcs w' - I noticed you had a 1-line change to Simon> GHC.hs, what was that? Also you had a local patch You can see it in the diff below. But as the diff is not complete, it's not very informative. Simon> "Incorporated ESC/Haskell", perhaps that made some changes? Yes, but I can't see how they could affect haddock. Here is the output of darcs w. I don't see anything that explains the problem. But it is not conatinging the full history of changes from the online repository.: hunk ./compiler/ghc.cabal.in 68 + Build-Depends: parsec >= 2.1 && < 3 hunk ./compiler/ghc.cabal.in 452 - Verify - BasicAbs - EscSyn + Verify + BasicAbs + EscSyn hunk ./compiler/ghc.cabal.in 457 - HsContract - TcHsContract + HsContract + TcHsContract hunk ./compiler/main/DynFlags.hs 143 + | Opt_D_dump_vr + | Opt_D_dump_vr_trace hunk ./compiler/main/DynFlags.hs 963 + | CoreDoVerify Int -- the Int: unrolling depth during CEG unrolling + | CoreDoVerifyWOThmProver Int -- the Int: unrolling depth during CEG unrolling hunk ./compiler/main/GHC.hs 1228 + mg_contracts = emptyContractEnv, hunk ./compiler/main/HscTypes.lhs 1019 - mg_contracts :: !ContractEnv, -- contracts {-# CONTRACT f :: {x | x>0} -> {r | r > x} #-} + mg_contracts :: !ContractEnv, -- ^ contracts {-# CONTRACT f :: {x | x>0} -> {r | r > x} #-} hunk ./compiler/rename/RnSource.lhs 19 + extendLocalRdrEnv, hunk ./compiler/rename/RnSource.lhs 55 +import HsContract + hunk ./compiler/simplCore/SimplCore.lhs 183 -doCorePass (CoreDoVerify n) = {-# SCC "Verification" #-} ^I$ - verifyBinds n +--doCorePass (CoreDoVerify n) = {-# SCC "Verification" #-} ^I$ +-- verifyBinds n hunk ./compiler/simplCore/SimplCore.lhs 186 -doCorePass (CoreDoVerifyWOThmProver n) = {-# SCC "VerifyWOProver" #-} $ - verifyBindsWOThmProver n +--doCorePass (CoreDoVerifyWOThmProver n) = {-# SCC "VerifyWOProver" #-} $ +-- verifyBindsWOThmProver n -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Wed Apr 1 14:43:25 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 1 14:30:42 2009 Subject: Unable to compile ghc from darcs In-Reply-To: (Colin Paul Adams's message of "Wed\, 01 Apr 2009 17\:12\:20 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> <49D336E4.2060307@gmail.com> <49D37FE9.1060500@gmail.com> <49D38F0C.2000302@gmail.com> Message-ID: >>>>> "Colin" == Colin Paul Adams writes: >>>>> "Simon" == Simon Marlow writes: Simon> "Incorporated ESC/Haskell", perhaps that made some changes? I found it. maybeParen was added to the export list for HsTypes. I've added a hiding clause for it when importing HsSyn unqualified into GHC. (I don't know if that's the best fix - this isn't my code - I'm just trying to incorporate it into the current version so I can check the contracts in my code. I'm really out of my depth - I should learn to swim first) Anyway, it does the trick - the make now completes. -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Wed Apr 1 15:35:23 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 1 15:22:32 2009 Subject: doCorePass Message-ID: Between 6.8 and 6.11, function doCorePass in module SimplCore has changed types from: CoreToDo -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount, ModGuts) to: CorePass (== CoreToDo) -> ModGuts -> CoreM ModGuts and it isn't easy for me to figure out the relationship between the two types. Is there some sort of formula I can follow to convert a function with the first type to the second? -- Colin Adams Preston Lancashire From igloo at earth.li Wed Apr 1 16:21:00 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 1 16:08:13 2009 Subject: ANNOUNCE: GHC version 6.10.2 Message-ID: <20090401202100.GA14872@matrix.chaos.earth.li> ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.10.1, including some performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.2/html/users_guide/release-6-10-2.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 batterseapower at hotmail.com Wed Apr 1 18:49:34 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Apr 1 18:36:43 2009 Subject: doCorePass In-Reply-To: References: Message-ID: <9d4d38820904011549pf335e06oda9d07174ed54c37@mail.gmail.com> 2009/4/1 Colin Paul Adams : > Between 6.8 and 6.11, function doCorePass in module SimplCore has changed types from: > > CoreToDo -> HscEnv -> UniqSupply -> RuleBase ?-> ModGuts -> IO (SimplCount, ModGuts) > > to: > > CorePass (== CoreToDo) -> ModGuts -> CoreM ModGuts The file to look at is CoreMonad.lhs. In particular, these functions exist: -- ** Reading from the monad getHscEnv, getAnnEnv, getRuleBase, getModule, getDynFlags, getOrigNameCache, liftIOWithCount And it is an instance of MonadUnique so has getUniqueSupplyM. This suggests the following implementation: lift :: (CoreToDo -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount, ModGuts)) -> CorePass -> ModGuts -> CoreM ModGuts lift f pass guts = do env <- getHscEnv us <- getUniqueSupplyM rb <- getRuleBase liftIOWithCount (f pass env us rb guts) Disclaimer: I have not run this or even type checked it :-) Cheers, Max From DekuDekuplex at Yahoo.com Thu Apr 2 00:47:22 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Apr 2 00:37:13 2009 Subject: ANNOUNCE: GHC version 6.10.2 References: <20090401202100.GA14872@matrix.chaos.earth.li> <670e468e0904011848v624d0895qe918568a0a1522ea@mail.gmail.com> Message-ID: On Wed, 1 Apr 2009 18:48:13 -0700, Lyle Kopnicky wrote: >Great! But what happened to the time package? It was in 6.10.1. Has it been >intentionally excluded from 6.10.2? Then I should probably hold off on installing the new version for now. Any estimate on when this problem will be fixed? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From duncan.coutts at worc.ox.ac.uk Thu Apr 2 05:42:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 2 05:30:02 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 In-Reply-To: References: <20090401202100.GA14872@matrix.chaos.earth.li> <670e468e0904011848v624d0895qe918568a0a1522ea@mail.gmail.com> Message-ID: <1238665370.25888.1390.camel@localhost> On Thu, 2009-04-02 at 13:47 +0900, Benjamin L.Russell wrote: > On Wed, 1 Apr 2009 18:48:13 -0700, Lyle Kopnicky > wrote: > > >Great! But what happened to the time package? It was in 6.10.1. Has it been > >intentionally excluded from 6.10.2? Yes, the maintainer of the time package asked for it to be removed: > Can I remove the time package from the GHC build process? I > want to update it but I don't want to deal with GHC's > autotools stuff or break the GHC build. > Then I should probably hold off on installing the new version for now. > Any estimate on when this problem will be fixed? The time package will be part of the first platform release (assuming we get enough volunteers to do the platform release!) In the mean time you can just: $ cabal install time Duncan From marlowsd at gmail.com Thu Apr 2 07:46:07 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 2 07:33:21 2009 Subject: ghc-pkg check problem in 6.10.2 Message-ID: <49D4A57F.4070905@gmail.com> I just noticed that the new 'ghc-pkg check' feature exposes a silly mistake in the definition of the rts package that we ship with GHC 6.10.2: $ ghc-pkg check There are problems in package rts-1.0: include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory ... To fix it, issue this command: $ ghc-pkg describe rts | sed 's/PAPI_INCLUDE_DIR//' | ghc-pkg update - and now "ghc-pkg check" should give no errors: $ ghc-pkg check $ (Except on Windows, where there also seems to be a problem with the Haddock package. Haddock itself is ok, but the Haddock library has some problems with its registration.) Cheers, Simon From david.waern at gmail.com Thu Apr 2 16:40:44 2009 From: david.waern at gmail.com (David Waern) Date: Thu Apr 2 16:27:51 2009 Subject: ghc-pkg check problem in 6.10.2 In-Reply-To: <49D4A57F.4070905@gmail.com> References: <49D4A57F.4070905@gmail.com> Message-ID: 2009/4/2 Simon Marlow : > I just noticed that the new 'ghc-pkg check' feature exposes a silly mistake > in the definition of the rts package that we ship with GHC 6.10.2: > > $ ghc-pkg check > There are problems in package rts-1.0: > ?include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory > > ... > > To fix it, issue this command: > > ?$ ghc-pkg describe rts | sed 's/PAPI_INCLUDE_DIR//' | ghc-pkg update - > > and now "ghc-pkg check" should give no errors: > > ?$ ghc-pkg check > ?$ > > (Except on Windows, where there also seems to be a problem with the Haddock > package. ?Haddock itself is ok, but the Haddock library has some problems > with its registration.) Oh, which problems? David From DekuDekuplex at Yahoo.com Fri Apr 3 00:44:43 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri Apr 3 00:31:59 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 References: <20090401202100.GA14872@matrix.chaos.earth.li> <670e468e0904011848v624d0895qe918568a0a1522ea@mail.gmail.com> <1238665370.25888.1390.camel@localhost> Message-ID: On Thu, 02 Apr 2009 10:42:50 +0100, Duncan Coutts wrote: >On Thu, 2009-04-02 at 13:47 +0900, Benjamin L.Russell wrote: >> On Wed, 1 Apr 2009 18:48:13 -0700, Lyle Kopnicky >> wrote: >> >> >Great! But what happened to the time package? It was in 6.10.1. Has it been >> >intentionally excluded from 6.10.2? > >Yes, the maintainer of the time package asked for it to be removed: > >> Can I remove the time package from the GHC build process? I >> want to update it but I don't want to deal with GHC's >> autotools stuff or break the GHC build. > > >> Then I should probably hold off on installing the new version for now. >> Any estimate on when this problem will be fixed? > >The time package will be part of the first platform release (assuming we >get enough volunteers to do the platform release!) > >In the mean time you can just: > >$ cabal install time Okay; no problem. I just read through the Release notes for version 6.10.2 (see http://haskell.org/ghc/docs/6.10.2/html/users_guide/release-6-10-2.html), however, and noticed that the removal of the time package hadn't been documented there. Perhaps this information should be included? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From cell at cs.utexas.edu Fri Apr 3 09:19:14 2009 From: cell at cs.utexas.edu (Jason Pepas) Date: Fri Apr 3 09:16:36 2009 Subject: trouble compiling 6.8.3 using 6.8.3 Message-ID: <49D60CD2.2060706@cs.utexas.edu> Hi Guys, I'm trying to rebuild ghc 6.8.3 (the previous version was built without readline linked in), and I'm running into a compilation issue. build error: /lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1 -hide-all-packages -no-user-package-conf -package-conf /v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/bootstrapping.conf -i -idist-stage1/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage1/build/autogen -Idist-stage1/build/autogen -Idist-stage1/build -Istage1 -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-include -optPdist-stage1/build/autogen/cabal_macros.h -odir dist-stage1/build -hidir dist-stage1/build -stubdir dist-stage1/build -package Cabal-1.6.0.1 -package array-0.1.0.0 -package base-3.0.2.0 -package bytestring-0.9.0.1.1 -package containers-0.1.0.2 -package directory-1.0.0.1 -package extensible-exceptions-0.1.0.0 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.0 -package process-1.0.0.1 -package unix-2.3.0.1 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XPatternSignatures -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -idist-stage1/build -H32m -O -Rghc-timing -c types/Unify.lhs -o dist-stage1/build/Unify.o -ohi dist-stage1/build/Unify.hi parser/Lexer.x:1652:17: Not in scope: data constructor `SLIT' parser/Lexer.x:1653:23: Not in scope: data constructor `SLIT' <> make[2]: *** [dist-stage1/build/Lexer.o] Error 1 make[2]: *** Waiting for unfinished jobs.... <> make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 I've hit up google and the only results which stood out were other "data constructor not in scope" messages which were due to people trying to run old haskell code using newer versions of the compiler, but I doubt that's the case here as I am using the same version of the compiler as both host and target. Any ideas? -jason From cell at cs.utexas.edu Fri Apr 3 09:25:13 2009 From: cell at cs.utexas.edu (Jason Pepas) Date: Fri Apr 3 09:22:37 2009 Subject: trouble compiling 6.8.3 using 6.8.3 In-Reply-To: <49D60CD2.2060706@cs.utexas.edu> References: <49D60CD2.2060706@cs.utexas.edu> Message-ID: <49D60E39.4090506@cs.utexas.edu> Jason Pepas wrote: > /lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1 Um, scratch that. I've apparently become confused as to which release I was actually building. -jason From ashley at semantic.org Sun Apr 5 04:24:25 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Apr 5 04:11:27 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 In-Reply-To: <1238665370.25888.1390.camel@localhost> References: <20090401202100.GA14872@matrix.chaos.earth.li> <670e468e0904011848v624d0895qe918568a0a1522ea@mail.gmail.com> <1238665370.25888.1390.camel@localhost> Message-ID: <49D86AB9.9070406@semantic.org> Duncan Coutts wrote: > In the mean time you can just: > > $ cabal install time Where do I get the "cabal" command? I'm installing GHC on a new machine and I was hoping it would be included. I can't obtain it via "cabal install cabal-install" because I don't have the cabal command and I don't know how to tie the knot in this case. -- Ashley Yakeley From daniel.is.fischer at web.de Sun Apr 5 06:11:05 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Apr 5 05:58:13 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 In-Reply-To: <49D86AB9.9070406@semantic.org> References: <20090401202100.GA14872@matrix.chaos.earth.li> <1238665370.25888.1390.camel@localhost> <49D86AB9.9070406@semantic.org> Message-ID: <200904051211.05581.daniel.is.fischer@web.de> Am Sonntag 05 April 2009 10:24:25 schrieb Ashley Yakeley: > Duncan Coutts wrote: > > In the mean time you can just: > > > > $ cabal install time > > Where do I get the "cabal" command? I'm installing GHC on a new machine > and I was hoping it would be included. I can't obtain it via "cabal > install cabal-install" because I don't have the cabal command and I > don't know how to tie the knot in this case. Download the cabal-install .tar.gz from Hackage, unpack it. There's a script bootstrap.sh in the directory, run that, it wgets zlib and HTTP and installs them, after that, it installs cabal-install and you're ready to go. If you're on windows, there's a cabal binary installer somewhere (should be findable from the cabal homepage, I believe). From dons at galois.com Sun Apr 5 12:48:21 2009 From: dons at galois.com (Don Stewart) Date: Sun Apr 5 12:36:23 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 In-Reply-To: <200904051211.05581.daniel.is.fischer@web.de> References: <20090401202100.GA14872@matrix.chaos.earth.li> <1238665370.25888.1390.camel@localhost> <49D86AB9.9070406@semantic.org> <200904051211.05581.daniel.is.fischer@web.de> Message-ID: <20090405164820.GM26834@whirlpool.galois.com> daniel.is.fischer: > Am Sonntag 05 April 2009 10:24:25 schrieb Ashley Yakeley: > > Duncan Coutts wrote: > > > In the mean time you can just: > > > > > > $ cabal install time > > > > Where do I get the "cabal" command? I'm installing GHC on a new machine > > and I was hoping it would be included. I can't obtain it via "cabal > > install cabal-install" because I don't have the cabal command and I > > don't know how to tie the knot in this case. > > Download the cabal-install .tar.gz from Hackage, unpack it. > There's a script bootstrap.sh in the directory, run that, it wgets zlib and HTTP and > installs them, after that, it installs cabal-install and you're ready to go. > If you're on windows, there's a cabal binary installer somewhere (should be > findable from the cabal homepage, I believe). > _______________________________________________ There are binaries of the 'cabal' command on many distros too. -- Don From lennart at augustsson.net Sun Apr 5 14:55:07 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Apr 5 14:42:06 2009 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.10.2 In-Reply-To: <20090405164820.GM26834@whirlpool.galois.com> References: <20090401202100.GA14872@matrix.chaos.earth.li> <1238665370.25888.1390.camel@localhost> <49D86AB9.9070406@semantic.org> <200904051211.05581.daniel.is.fischer@web.de> <20090405164820.GM26834@whirlpool.galois.com> Message-ID: And to make many, many peoples life easier the binaries could have been included in ghc 6.10.2 (but I know there are some philosophical reasons against it). -- Lennart On Sun, Apr 5, 2009 at 5:48 PM, Don Stewart wrote: > daniel.is.fischer: >> Am Sonntag 05 April 2009 10:24:25 schrieb Ashley Yakeley: >> > Duncan Coutts wrote: >> > > In the mean time you can just: >> > > >> > > $ cabal install time >> > >> > Where do I get the "cabal" command? I'm installing GHC on a new machine >> > and I was hoping it would be included. I can't obtain it via "cabal >> > install cabal-install" because I don't have the cabal command and I >> > don't know how to tie the knot in this case. >> >> Download the cabal-install .tar.gz from Hackage, unpack it. >> There's a script bootstrap.sh in the directory, run that, it wgets zlib and HTTP and >> installs them, after that, it installs cabal-install and you're ready to go. >> If you're on windows, there's a cabal binary installer somewhere (should be >> findable from the cabal homepage, I believe). >> _______________________________________________ > > There are binaries of the 'cabal' command on many distros too. > > -- ?Don > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From cell at cs.utexas.edu Mon Apr 6 16:52:18 2009 From: cell at cs.utexas.edu (Jason Pepas) Date: Mon Apr 6 16:49:40 2009 Subject: trouble compiling 6.8.3 using 6.8.3 In-Reply-To: <49D60E39.4090506@cs.utexas.edu> References: <49D60CD2.2060706@cs.utexas.edu> <49D60E39.4090506@cs.utexas.edu> Message-ID: <49DA6B82.4060503@cs.utexas.edu> Jason Pepas wrote: > Jason Pepas wrote: >> /lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1 > > Um, scratch that. I've apparently become confused as to which release I > was actually building. > > -jason > So I've run into a (legitimate) issue with building 6.8.3. Initiall I was getting things like this: build error: ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-g -optc-O0 -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-DDEBUG -c ProfHeap.c -o ProfHeap.debug_o Printer.c:962:17: error: bfd.h: No such file or directory this was being caused by not being able to find binutils-related headers. similar errors occured after not being able to find readline headers. (these were in a non-standard location). I got around this by exporting some env vars: export CPPFLAGS="-I/lusr/gnu/include -I/lusr/include" export LDFLAGS="-L/lusr/lib -L/lusr/gnu/lib" however, that still didn't solve the problem, and eventually I resorted to "grafting" (copying via symlinks) the include files into the build-dir/includes directory. that worked until I ran into this: checking for readline in -lreadline... yes checking for rl_readline_version... yes checking for rl_begin_undo_group... yes checking for rl_erase_empty_line... yes checking for rl_free_undo_list... yes checking for rl_completion_word_break_hook in -lreadline... yes configure: creating ./config.status config.status: creating readline.buildinfo config.status: creating include/HsReadlineConfig.h if ifBuildable/ifBuildable readline; then \ cd readline && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ mv GNUmakefile GNUmakefile.tmp; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ make -wr --jobserver-fds=3,4 -j && \ setup/Setup register --inplace; \ fi mv: cannot stat `GNUmakefile': No such file or directory Preprocessing library readline-1.0.1.0... /lusr/gnu/bin/ld: cannot find -lreadline collect2: ld returned 1 exit status linking dist/build/System/Console/Readline_hsc_make.o failed command was: gcc -lreadline -lncurses dist/build/System/Console/Readline_hsc_make.o -o dist/build/System/Console/Readline_hsc_make make[2]: Entering directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' make[2]: *** No targets specified and no makefile found. Stop. make[2]: Leaving directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' make[1]: *** [make.library.readline] Error 2 make[1]: Leaving directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries' make: *** [stage1] Error 2 specifically, what is failing is the "setup/Setup makefile -f GNUmakefile" command. bash-3.2$ setup/Setup makefile -f GNUmakefile Preprocessing library readline-1.0.1.0... /lusr/gnu/bin/ld: cannot find -lreadline collect2: ld returned 1 exit status linking dist/build/System/Console/Readline_hsc_make.o failed command was: gcc -lreadline -lncurses dist/build/System/Console/Readline_hsc_make.o -o dist/build/System/Console/Readline_hsc_make however, if you cd into build-dir/libraries/readline and run this manually: ./configure --with-readline-includes=/lusr/gnu/include --with-readline-libraries=/lusr/gnu/lib you can then run the "setup/Setup makefile -f GNUmakefile" and it works. so I thought I'd try simply modifying the libraries/Makefile: bash-3.2$ diff -urN libraries/Makefile.orig libraries/Makefile --- libraries/Makefile.orig 2009-04-06 14:36:44.000000000 -0500 +++ libraries/Makefile 2009-04-06 15:29:14.000000000 -0500 @@ -277,9 +277,11 @@ if ifBuildable/ifBuildable $*; then \ cd $* && \ cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ - mv GNUmakefile GNUmakefile.tmp; \ + if [ -e GNUmakefile ] ; then mv GNUmakefile GNUmakefile.tmp ; fi ;\ + if [ "$*" = "readline" ] ; then ./configure --with-readline-includes=/lusr/gnu/include --with-readline-libraries=/lusr/gnu/lib ; fi ; \ setup/Setup makefile -f GNUmakefile; \ cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ + echo $(MAKE) $(MFLAGS) && \ $(MAKE) $(MFLAGS) && \ setup/Setup register --inplace; \ fi but that doesn't work: Preprocessing library readline-1.0.1.0... Generating Makefile readline-1.0.1.0... make -wr make[2]: Entering directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' Registering readline-1.0.1.0... Reading package info from "dist/inplace-pkg-config" ... done. Unable to rename "/lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf" to "/lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf.old" Saving old package config file... ghc-pkg.bin: /lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf: renameFile: permission denied (Permission denied) make[1]: *** [make.library.readline] Error 1 make[1]: Leaving directory `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries' make: *** [stage1] Error 2 At this point I think this has gotten a little too hack-ish, so I thought I'd ask the mailing list what for proper way of telling ghc where your readline installation lives? thanks, jason From colin at colina.demon.co.uk Wed Apr 8 05:32:58 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 8 05:19:54 2009 Subject: Functions for builtin operators (?) Message-ID: Where is a function with a name like the following defined in the ghc source code? .Classes.>_ ( tpl_B6 ) I've tried searching for such names - all I can find is a comment referring to tpl_B2. -- Colin Adams Preston Lancashire From simonpj at microsoft.com Wed Apr 8 05:48:54 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Apr 8 05:35:45 2009 Subject: Functions for builtin operators (?) In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C335080DF108@EA-EXMSG-C334.europe.corp.microsoft.com> Nowhere. It's a name generated by GHC itself during compilation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Colin Paul Adams | Sent: 08 April 2009 10:33 | To: glasgow-haskell-users@haskell.org | Subject: Functions for builtin operators (?) | | Where is a function with a name like the following defined in the ghc source | code? | | .Classes.>_ ( tpl_B6 ) | | I've tried searching for such names - all I can find is a comment | referring to tpl_B2. | -- | Colin Adams | Preston Lancashire | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From colin at colina.demon.co.uk Wed Apr 8 06:03:37 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Apr 8 05:50:28 2009 Subject: Functions for builtin operators (?) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C335080DF108@EA-EXMSG-C334.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Wed\, 8 Apr 2009 10\:48\:54 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C335080DF108@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: >>>>> "Simon" == Simon Peyton-Jones writes: Simon> Nowhere. It's a name generated by GHC itself during Simon> compilation. OK. Is there some way to recognise what the function is? The problem is with ESC/Haskell. I have managed to get the code integrated into the 6.11 tree, and it works up to a point. It produces output like: Len.hs:4:0: Len.pos does not satisfy its contract! Counter example: Len.pos with argument(s) x (Inside _GHC.Classes.>_ ( tpl_B6 )) x ((GHC.Types.I# 0)) which is basically saying that it can't trust _GHC.Classes.>_ ( tpl_B6 ) to do anything in particular, as it doesn't know anything about it. So it would be good to add code that recognises these functions. At best, to know the semantics of each one. Colin> | Where is a function with a name like the following Colin> defined in the ghc source | code? Colin> | Colin> | .Classes.>_ ( tpl_B6 ) -- Colin Adams Preston Lancashire From ndmitchell at gmail.com Wed Apr 8 06:26:25 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 8 06:13:15 2009 Subject: GHC threading bug in QSem Message-ID: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> Hi I believe the following program should always print 100: import Data.IORef import Control.Concurrent main = do sem <- newQSem (-99) r <- newIORef 0 let incRef = atomicModifyIORef r (\a -> (a+1,a)) sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem waitQSem sem v <- readIORef r print v Unfortunately, it doesn't seem to. Running on a 2 processor machine, with +RTS -N3 I usually get 100, but have got answers such as 49, 82, 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100 roughly every other time. >From reading the implementation of QSem, it doesn't seem that negative availability was considered. I think it would be need to be changed as: -- Invariant: avail >= 1 ==> null blocked waitQSem :: QSem -> IO () waitQSem (QSem sem) = do (avail,blocked) <- takeMVar sem -- gain ex. access if avail > 0 then putMVar sem (avail-1,[]) else do block <- newEmptyMVar putMVar sem (avail, blocked++[block]) -- changed line takeMVar block signalQSem :: QSem -> IO () signalQSem (QSem sem) = do (avail,blocked) <- takeMVar sem -- changed below if null blocked || avail < 0 then putMVar sem (avail+1,blocked) else putMVar sem (avail, tail blocked) putMVar (head blocked) () Writing parallel code is hard, so I could have easily got this wrong. I haven't looked at QSemN, which may need similar fixes (or may already deal with this) Thanks Neil From ndmitchell at gmail.com Wed Apr 8 06:40:43 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 8 06:27:33 2009 Subject: GHC threading bug in QSem In-Reply-To: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> References: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> Message-ID: <404396ef0904080340x527c11a8xc4baad73a347dbd8@mail.gmail.com> I've now raised a ticket to track this issue: http://hackage.haskell.org/trac/ghc/ticket/3159 Thanks, Neil On Wed, Apr 8, 2009 at 11:26 AM, Neil Mitchell wrote: > Hi > > I believe the following program should always print 100: > > import Data.IORef > import Control.Concurrent > > main = do > ? ?sem <- newQSem (-99) > ? ?r <- newIORef 0 > ? ?let incRef = atomicModifyIORef r (\a -> (a+1,a)) > ? ?sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem > ? ?waitQSem sem > ? ?v <- readIORef r > ? ?print v > > Unfortunately, it doesn't seem to. Running on a 2 processor machine, > with +RTS -N3 I usually get 100, but have got answers such as 49, 82, > 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This > is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100 > roughly every other time. > > From reading the implementation of QSem, it doesn't seem that negative > availability was considered. I think it would be need to be changed > as: > > -- Invariant: avail >= 1 ==> null blocked > > waitQSem :: QSem -> IO () > waitQSem (QSem sem) = do > ? (avail,blocked) <- takeMVar sem ?-- gain ex. access > ? if avail > 0 then > ? ? putMVar sem (avail-1,[]) > ? ?else do > ? ? block <- newEmptyMVar > ? ? putMVar sem (avail, blocked++[block]) ? -- changed line > ? ? takeMVar block > > signalQSem :: QSem -> IO () > signalQSem (QSem sem) = do > ? (avail,blocked) <- takeMVar sem > ? -- changed below > ? if null blocked || avail < 0 then > ? ? ?putMVar sem (avail+1,blocked) > ? else > ? ? ?putMVar sem (avail, tail blocked) > ? ? ?putMVar (head blocked) () > > Writing parallel code is hard, so I could have easily got this wrong. > I haven't looked at QSemN, which may need similar fixes (or may > already deal with this) > > Thanks > > Neil > From haskell at list.mightyreason.com Wed Apr 8 06:58:16 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Apr 8 06:45:08 2009 Subject: GHC threading bug in QSem In-Reply-To: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> References: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> Message-ID: <49DC8348.6040507@list.mightyreason.com> The code assumes newQsem is never given a negative argument without ever documenting this fact. http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Concurrent-QSem.html#waitQSem change not only putMVar sem (0, blocked++[block]) to putMVar sem (avail, blocked++[block]) in waitQSem but also change signalQSem to > signalQSem :: QSemN -> IO () > signalQSem (QSemN sem) = modifyMVar_ free sem > where free (0,(b:bs)) = putMVar b () >> return (0,bs) > free (avail,blocked) = return (avail+1,blocked) Neil: To allow negative values you have to change signalQSem and waitQSem. And really folks, the waitQSem(N) and signalQSem(N) should be exception safe and this is not currently true. They should all be using the modifyMVar_ idiom ? currently an exception such as killThread between the take and put will leave the semaphore perpetually empty which is not a valid state. I also hereby lobby that a non-blocking "trySem" be added, and while Control.Concurrent is getting updated I think that Neil's last concurrency puzzle would have been helped by having a non-blocking "tryReadChan" in Control.Concurrent.Chan (note that the isEmptyChan is not useful for making non-blocking read), and how about Control.Concurrent.Pony ? "Control.Concurrent.SampleVar" is also not exception safe. Neil Mitchell wrote: > Hi > > I believe the following program should always print 100: > > import Data.IORef > import Control.Concurrent > > main = do > sem <- newQSem (-99) > r <- newIORef 0 > let incRef = atomicModifyIORef r (\a -> (a+1,a)) > sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem > waitQSem sem > v <- readIORef r > print v > > Unfortunately, it doesn't seem to. Running on a 2 processor machine, > with +RTS -N3 I usually get 100, but have got answers such as 49, 82, > 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This > is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100 > roughly every other time. > >>From reading the implementation of QSem, it doesn't seem that negative > availability was considered. I think it would be need to be changed > as: > > -- Invariant: avail >= 1 ==> null blocked > > waitQSem :: QSem -> IO () > waitQSem (QSem sem) = do > (avail,blocked) <- takeMVar sem -- gain ex. access > if avail > 0 then > putMVar sem (avail-1,[]) > else do > block <- newEmptyMVar > putMVar sem (avail, blocked++[block]) -- changed line > takeMVar block > > signalQSem :: QSem -> IO () > signalQSem (QSem sem) = do > (avail,blocked) <- takeMVar sem > -- changed below > if null blocked || avail < 0 then > putMVar sem (avail+1,blocked) > else > putMVar sem (avail, tail blocked) > putMVar (head blocked) () > > Writing parallel code is hard, so I could have easily got this wrong. > I haven't looked at QSemN, which may need similar fixes (or may > already deal with this) > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ben.franksen at online.de Wed Apr 8 14:20:36 2009 From: ben.franksen at online.de (Ben Franksen) Date: Wed Apr 8 14:07:39 2009 Subject: GHC threading bug in QSem References: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com> <49DC8348.6040507@list.mightyreason.com> Message-ID: Chris Kuklewicz wrote: > And really folks, the waitQSem(N) and signalQSem(N) should be exception > safe and > this is not currently true. They should all be using the modifyMVar_ > idiom ? currently an exception such as killThread between the take and put > will leave the semaphore perpetually empty which is not a valid state. > > I also hereby lobby that a non-blocking "trySem" be added, and while > Control.Concurrent is getting updated I think that Neil's last concurrency > puzzle would have been helped by having a non-blocking "tryReadChan" in > Control.Concurrent.Chan (note that the isEmptyChan is not useful for > making non-blocking read), isEmptyChan is not useful for anything because it blocks when the channel is empty and another thread calls readChan. The following code waits forever after printing the "1": import Control.Concurrent import Control.Concurrent.Chan import Control.Monad test = do c <- newChan forkIO $ forever $ do i <- readChan c print i writeChan c 1 threadDelay 1000000 isEmptyChan c >>= print Test session: ben@sarun[1]: .../hca/current > ghci Bug5.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Bug5.hs, interpreted ) Ok, modules loaded: Main. *Main> test 1 BTW, when I interrupt this with Ctrl-C, ghc-6.10.2 crashes with a segmentation fault. With ghc-6.10.1 I get a clean "Interrupted" message and a new prompt. This looks like a regression to me. Cheers Ben From bulat.ziganshin at gmail.com Fri Apr 10 12:33:31 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 10 12:20:37 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 Message-ID: <479126905.20090410203331@gmail.com> Hello glasgow-haskell-users, i've looked for this bug in Trac but don't found anything. so: startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId >>= writeIORef guiThread action >>= widgetShowAll mainGUI guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread" Later in the same thread i ask for myThreadId and get different value. interesting that value returned in startGUI is 23 while later values are about 7000. probably this reflects total amount of threads created so far so that's the problem. Win API call returns constant thread number (that looks natural since the thread is bound). so either: 1) it's feature - please mention this in docs 2) it was fixed since 6.6.1 3) we need full-scale bugreport using 6.10.2 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Fri Apr 10 12:36:32 2009 From: dons at galois.com (Don Stewart) Date: Fri Apr 10 12:24:22 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 In-Reply-To: <479126905.20090410203331@gmail.com> References: <479126905.20090410203331@gmail.com> Message-ID: <20090410163632.GC21502@whirlpool.galois.com> Could you send a full example we can compile and test? This is only a fragment. bulat.ziganshin: > Hello glasgow-haskell-users, > > i've looked for this bug in Trac but don't found anything. so: > > startGUI action = runInBoundThread $ do > unsafeInitGUIForThreadedRTS > myThreadId >>= writeIORef guiThread > action >>= widgetShowAll > mainGUI > > guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread" > > > Later in the same thread i ask for myThreadId and get different value. > interesting that value returned in startGUI is 23 while later values > are about 7000. probably this reflects total amount of threads created > so far > > so that's the problem. Win API call returns constant thread number > (that looks natural since the thread is bound). so either: > > 1) it's feature - please mention this in docs > 2) it was fixed since 6.6.1 > 3) we need full-scale bugreport using 6.10.2 > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bulat.ziganshin at gmail.com Fri Apr 10 12:47:41 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 10 12:40:45 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 In-Reply-To: <20090410163632.GC21502@whirlpool.galois.com> References: <479126905.20090410203331@gmail.com> <20090410163632.GC21502@whirlpool.galois.com> Message-ID: <1241944012.20090410204741@gmail.com> Hello Don, Friday, April 10, 2009, 8:36:32 PM, you wrote: unfortunately, full example is my whole program. i will try to make short example if someone will say that it looks like a bug and it was not fixed in intermediate versions. basically, scenario is simple - myThreadId changed due the life of (bound) thread > Could you send a full example we can compile and test? > This is only a fragment. > bulat.ziganshin: >> Hello glasgow-haskell-users, >> >> i've looked for this bug in Trac but don't found anything. so: >> >> startGUI action = runInBoundThread $ do >> unsafeInitGUIForThreadedRTS >> myThreadId >>= writeIORef guiThread >> action >>= widgetShowAll >> mainGUI >> >> guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread" >> >> >> Later in the same thread i ask for myThreadId and get different value. >> interesting that value returned in startGUI is 23 while later values >> are about 7000. probably this reflects total amount of threads created >> so far >> >> so that's the problem. Win API call returns constant thread number >> (that looks natural since the thread is bound). so either: >> >> 1) it's feature - please mention this in docs >> 2) it was fixed since 6.6.1 >> 3) we need full-scale bugreport using 6.10.2 >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bertram.felgenhauer at googlemail.com Sat Apr 11 12:09:46 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Apr 11 11:56:30 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 In-Reply-To: <479126905.20090410203331@gmail.com> References: <479126905.20090410203331@gmail.com> Message-ID: <49e0c0cd.1ade660a.52cb.ffffee54@mx.google.com> Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > i've looked for this bug in Trac but don't found anything. so: > > startGUI action = runInBoundThread $ do > unsafeInitGUIForThreadedRTS > myThreadId >>= writeIORef guiThread > action >>= widgetShowAll > mainGUI > > guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread" > > > Later in the same thread i ask for myThreadId and get different value. What does "same thread" mean? I'll risk a guess. mainGUI is a safe foreign call that executes a loop on the C side; all future actions that you see and consider to be in the same thread are actually callbacks from C to Haskell. But in GHC's RTS, a new Haskell thread is created for each such callback, with a new thread id. So myThreadId returns varying numbers, leading to the effect that you described. So it's not a bug, although it should be better documented. It's not possible for the RTS to track which Haskell thread a callback was originally registered from (at best it could remember which thread created the original wrapper), and in any case that thread may be dead already, or running Haskell code at the time the callback comes, so I think that the current behaviour is quite sane. regards, Bertram From bulat.ziganshin at gmail.com Sat Apr 11 13:07:38 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 11 12:54:35 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 In-Reply-To: <49e0c0cd.1ade660a.52cb.ffffee54@mx.google.com> References: <479126905.20090410203331@gmail.com> <49e0c0cd.1ade660a.52cb.ffffee54@mx.google.com> Message-ID: <1804158437.20090411210738@gmail.com> Hello Bertram, Saturday, April 11, 2009, 8:09:46 PM, you wrote: > What does "same thread" mean? I'll risk a guess. well, that's possible - i'll ask on gtk2hs list too currently, i believe that mainGUI just runs endless loop processing queue of GUI events -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From phercek at gmail.com Sun Apr 12 13:26:23 2009 From: phercek at gmail.com (Peter Hercek) Date: Sun Apr 12 13:13:04 2009 Subject: failure implementing :next command in ghci Message-ID: Hi, So I wanted to give implementing :next ghci debugger command a shot. It looked easy and I could use it. Moreover it would give me an easy way to implement dynamic stack in ghci (using similar approach as used for trace) ... well if I would feel like that since I was a bit discouraged about it. The problem is I failed miserably. I still think it is easy to do. I just do not know how to create correct arguments for rts_breakpoint_io_action and I have given up finding up myself for now. The proposed meaning for :next Lets mark dynamic stack size at a breakpoint (at which we issue :next) as breakStackSize and its selected expression as breakSpan. Then :next would single step till any of these is true: 1) current dynamic stack size is smaller than breakStackSize 2) current dynamic stack size is equal to breakStackSize and the current selected expression is not a subset of breakSpan I hope the above would make good sense but I do not really know since maybe rts does some funny things with stack sometimes. If you think the proposed behavior is garbage let me know why so that I do not waste more time with this :) Ok, lets get back to why I failed. I think anybody who knows rts well could probably tell me what's wrong in few minutes. The patch representing my attempt is attached. It is done against the latest ghc (head branch). I want to add stack size as the last argument of rts_breakpoint_io_action so its signature would change from: Bool -> BreakInfo -> HValue -> IO () to: Bool -> BreakInfo -> HValue -> Int -> IO () Since dynamic stack is continuous I can find out stack size easily. I did not implemented this yet, as well I did not implement this at all for exceptions. The only thing I cared for now is passing one more integer to rts_breakpoint_io_action. The argument contains only zero now but that should be enough to see if I can add one more argument. I tested it by loading this source code to ghci: f :: Int -> Int f x = x + 1 a = f 1 ... then I used ":break f" and ":force a" in ghci to see whether I can pass the new argument correctly. This test works since I added printing of the last argument (the wanna be stack size) in noBreakAction :: Bool -> BreakInfo -> HValue -> Int -> IO () noBreakAction False _ _ x = putStrLn $ "*** Ignoring breakpoint " ++ show x noBreakAction True _ _ _ = return () -- exception: just continue The noBreakAction implementation is just a test for now. Unfortunately when I force the last argument it crashes. I think it is because I do not create the closure for it correctly in the code for bci_BRK_FUN in rts/Interpreter.c. Can somebody tell me what is wrong there or where to find more information about how to fill in the stack with rts_breakpoint_io_action arguments correctly? Also, any information somewhere about where to use allocate and where to use allocateLocal? I was surprised a bit that interpretBCO uses allocate much but no allocateLocal which is supposed to be quicker for a single thread. I skimmed all of ghc commentary and read the pages which looked related carefully but either it is not there or I missed it :-( Thanks, Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: stackSize.patch Type: text/x-patch Size: 6642 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090412/24dbf35c/stackSize.bin From lambda at 10k.org Mon Apr 13 03:58:42 2009 From: lambda at 10k.org (Jake L) Date: Mon Apr 13 03:45:16 2009 Subject: where is ghcautoconf.h, DerivedConstants.h and GHCConstants.h Message-ID: following wiki to make an unregistered build of ghc 6.6.1 on openbsd-powerpc-current target = powerpc_unknown_openbsd host = x86_64_unknown_linux with ghc-6.10.2 "Copy /includes/ghcautoconf.h, /includes/DerivedConstants.h, and /includes/GHCConstants.h to /includes. Note that we are building on the host machine, using the target machine's configuration files. This is so that the intermediate C files generated here will be suitable for compiling on the target system." looking in the target tree after doing ./configure --enable-hc-boot --enable-hc-boot-unregisterised those 3 files doesn't exist, what step am I missing? Jake From lambda at 10k.org Tue Apr 14 03:40:33 2009 From: lambda at 10k.org (Jake L) Date: Tue Apr 14 03:27:03 2009 Subject: bootstrap openbsd powerpc - continues In-Reply-To: References: Message-ID: Okay, I worked through the .h issue(it was late at night), but wasn't able to make headway with 6.6.1(exception type ambiguities), so I switched platforms and downgraded to earlier versions: take 2 ------ target = powerpc-unknown-openbsd host = i386-unknown-linux with a running ghc 6.4.2 following the instruction here: http://www.haskell.org/ghc/docs/6.4.2/html/building/sec-porting-ghc.html#id2931737 it finished the compiler phase's make boot && make (it didn't build RTS as the instruction fortold) however, it now fails in the phase $ cd H/libraries $ make boot && make ------------------------------------------------------------------------ ==fptools== make boot -r; in /j/ghc-6.4.2/libraries/unix ------------------------------------------------------------------------ ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I../../mk/ -I. System/Posix/DynamicLinker.hsc In file included from DynamicLinker.hsc:48: include/HsUnix.h: In function '__hsunix_rtldNext': include/HsUnix.h:103: error: 'RTLD_NEXT' undeclared (first use in this function) include/HsUnix.h:103: error: (Each undeclared identifier is reported only once include/HsUnix.h:103: error: for each function it appears in.) include/HsUnix.h: In function '__hsunix_rtldDefault': include/HsUnix.h:107: error: 'RTLD_DEFAULT' undeclared (first use in this function) make[1]: *** [System/Posix/DynamicLinker.hs] Error 1 make: *** [boot] Error 1 some digging appears what I have ran into this bug: http://hackage.haskell.org/trac/ghc/ticket/729 any suggestions? Jake From simonpj at microsoft.com Tue Apr 14 04:10:58 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 14 03:57:32 2009 Subject: [Haskell] deriving Show for GADT? In-Reply-To: <20090414042820.AC23B68AF2C7@yorkie.cs.tufts.edu> References: <20090414042820.AC23B68AF2C7@yorkie.cs.tufts.edu> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33508189667@EA-EXMSG-C334.europe.corp.microsoft.com> Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket/3012 Incidentally, the main Haskell list isn't the right place for GHC-specific questions. glasgow-haskell-users@haskell.org is the place Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | Norman Ramsey | Sent: 14 April 2009 05:28 | To: haskell@haskell.org | Subject: [Haskell] deriving Show for GADT? | | I've got a fairly large GADT for which I wished to use | deriving (Show) | but I got a mysterious error message: | | Exp.hs:13:11: | Can't make a derived instance of `Show (Exp a)' | (`Exp' has non-Haskell-98 constructor(s)) | In the data type declaration for `Exp' | | | This is from GHC. Does anybody know a compiler option or other trick | that will coax the compiler into producing a Show instance. | (I know I can write one by hand, but I'd rather not bother.) | | | Norman | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From lennart at augustsson.net Tue Apr 14 04:27:55 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Apr 14 04:14:26 2009 Subject: [Haskell] deriving Show for GADT? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33508189667@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090414042820.AC23B68AF2C7@yorkie.cs.tufts.edu> <638ABD0A29C8884A91BC5FB5C349B1C33508189667@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: If it's easy I think just generating the code and let the type checker report any problems would be a great thing for standalone deriving. -- Lennart On Tue, Apr 14, 2009 at 10:10 AM, Simon Peyton-Jones wrote: > Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket/3012 > > Incidentally, the main Haskell list isn't the right place for GHC-specific questions. ?glasgow-haskell-users@haskell.org is the place > > Simon > > | -----Original Message----- > | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of > | Norman Ramsey > | Sent: 14 April 2009 05:28 > | To: haskell@haskell.org > | Subject: [Haskell] deriving Show for GADT? > | > | I've got a fairly large GADT for which I wished to use > | ? ?deriving (Show) > | but I got a mysterious error message: > | > | Exp.hs:13:11: > | ? ? Can't make a derived instance of `Show (Exp a)' > | ? ? ? (`Exp' has non-Haskell-98 constructor(s)) > | ? ? In the data type declaration for `Exp' > | > | > | This is from GHC. ?Does anybody know a compiler option or other trick > | that will coax the compiler into producing a Show instance. > | (I know I can write one by hand, but I'd rather not bother.) > | > | > | Norman > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org > | http://www.haskell.org/mailman/listinfo/haskell > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From phercek at gmail.com Tue Apr 14 06:00:06 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Apr 14 05:46:54 2009 Subject: failure implementing :next command in ghci In-Reply-To: References: Message-ID: <49E45EA6.6090406@gmail.com> Hi, Pepe Iborra pointed out that my patch is not in the right format for gnu patch command. Sorry for inconvenience (I used "darcs what -u" instead of "darcs diff -u"). Here it is attached in the correct format. Thanks, Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: stackSize.patch Type: text/x-patch Size: 7425 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090414/d784b463/stackSize.bin From igloo at earth.li Tue Apr 14 06:22:32 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Apr 14 06:09:03 2009 Subject: where is ghcautoconf.h, DerivedConstants.h and GHCConstants.h In-Reply-To: References: Message-ID: <20090414102232.GA10821@matrix.chaos.earth.li> Hi Jake, On Mon, Apr 13, 2009 at 03:58:42AM -0400, Jake L wrote: > > following wiki to make an unregistered build of ghc 6.6.1 on > openbsd-powerpc-current > > target = powerpc_unknown_openbsd > host = x86_64_unknown_linux with ghc-6.10.2 You'll probably need to use 6.6.1 on the host. > "Copy /includes/ghcautoconf.h, /includes/DerivedConstants.h, and > /includes/GHCConstants.h to /includes. > > looking in the target tree after doing > ./configure --enable-hc-boot --enable-hc-boot-unregisterised > > those 3 files doesn't exist, what step am I missing? This one: $ cd /includes $ make Thanks Ian From bulat.ziganshin at gmail.com Wed Apr 15 09:47:18 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 15 09:34:15 2009 Subject: [Haskell-cafe] GHC including System.Time but not Data.Time? In-Reply-To: <49E5E284.2080501@complete.org> References: <20090414164412.GA18145@hustlerturf.com> <1821198027.20090414205647@gmail.com> <49E5E284.2080501@complete.org> Message-ID: <1231155101.20090415174718@gmail.com> Hello John, Wednesday, April 15, 2009, 5:35:00 PM, you wrote: > I agree. Is there any chance of 6.10.3 reverting the change? both 6.6 and 6.8 had last releases at spring, so i don't expect new 6.10.* at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From nitralime at googlemail.com Wed Apr 15 12:27:33 2009 From: nitralime at googlemail.com (nitralime) Date: Wed Apr 15 12:14:01 2009 Subject: GHC on AIX Message-ID: <53e0cac60904150927i5b14d627mb70510bd22f69482@mail.gmail.com> Hi, I'm new to GHC (and Haskell). I have tried to install the newest available binary distribution of GHC for AIX which is GHC version 6.8.2. Unfortunately, it didn't work properly. Following the trivial installation steps as described in INSTALL file I executed the following commands: 1) ./configure --prefix=/home/nik/local 2) gmake install But I got the following error message: ------------------------------ -------------------------------------------------------------------------------------------------------- .... Reading package info from stdin ... done. warning: can't find GHCi lib HSrts.o Saving old package config file... done. Writing new package config file... done. /tmp/ghc-6.8.2/utils/mkdirhier/mkdirhier /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2 for i in libHSrts*.a ; do \ case $i in \ *.a) \ /tmp/ghc-6.8.2/install-sh -c -m 644 $i /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2; \ : /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/`basename $i` ;; \ *.dll) \ /tmp/ghc-6.8.2/install-sh -c -m 644 -s $i /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2 ;; \ *.so) \ /tmp/ghc-6.8.2/install-sh -c -m 755 $i /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2 ;; \ *.dylib) \ /tmp/ghc-6.8.2/install-sh -c -m 755 $i /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2; \ install_name_tool -id /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/`basename $i` /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/`basename $i` ;; \ *) \ /tmp/ghc-6.8.2/install-sh -c -m 644 $i /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2; \ esac; \ done gmake[1]: Leaving directory `/tmp/ghc-6.8.2/rts' gmake -C libraries install DOING_BIN_DIST=YES gmake[1]: Entering directory `/tmp/ghc-6.8.2/libraries' if ifBuildable/ifBuildable base; then \ cd base && \ ../installPackage/installPackage '/tmp/ghc-6.8.2/utils/ghc-pkg/ghc-pkg.bin' '/home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/package.conf' '/home/nik/local/ghc-6.8.2' '/home/nik/local/ghc-6.8.2' '/home/nik/local/ghc-6.8.2/bin' '/home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/lib' '/home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/lib' '/home/nik/local/ghc-6.8.2/share/ghc-6.8.2' '/home/nik/local/ghc-6.8.2/share/doc/ghc/libraries/$pkg' '/home/nik/local/ghc-6.8.2/share/doc/ghc/libraries/$pkg' '/home/nik/local/ghc-6.8.2/share/doc/ghc/libraries/$pkg' ; \ fi Installing: /home/nik/local/ghc-6.8.2/lib/ghc-6.8.2/lib/base-3.0.1.0 gmake[1]: *** [install.library.base] Error 127 gmake[1]: Leaving directory `/tmp/ghc-6.8.2/libraries' gmake: *** [install] Error 2 -------------------------------------------------------------------------------------------------------------------------------------- Am I missing something? Any help is very much appreciated! Regards Nik PS: I have originally posted to Haskell-cafe mailing list that was obviousely not the right place for my question!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090415/86666f31/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Thu Apr 16 04:50:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 16 04:37:17 2009 Subject: bug: unstable myThreadId in GHC 6.6.1 In-Reply-To: <1804158437.20090411210738@gmail.com> References: <479126905.20090410203331@gmail.com> <49e0c0cd.1ade660a.52cb.ffffee54@mx.google.com> <1804158437.20090411210738@gmail.com> Message-ID: <1239871852.6315.17.camel@lantern> On Sat, 2009-04-11 at 21:07 +0400, Bulat Ziganshin wrote: > Hello Bertram, > > Saturday, April 11, 2009, 8:09:46 PM, you wrote: > > > What does "same thread" mean? I'll risk a guess. > > well, that's possible - i'll ask on gtk2hs list too > > currently, i believe that mainGUI just runs endless loop processing > queue of GUI events You are both right. mainGUI does just run an endless event processing loop but callbacks for events (like button clicks) are indeed ffi "wrapper" callbacks and so do get run in a fresh thread. Your 'guiThread' is blocked in the mainGUI call, so nothing ever happens in that Haskell thread until the even loop terminates. Duncan From dvde at gmx.net Thu Apr 16 08:05:24 2009 From: dvde at gmx.net (Daniel van den Eijkel) Date: Thu Apr 16 07:51:55 2009 Subject: Problem installing GHC 6.10.2 on Debian Etch Message-ID: <49E71F04.6040102@gmx.net> Hi I am trying to install GHC-6.10.2 on Debian Etch and I get the following error: /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not recognized Does anybody know this issue? I would be happy to get some help. daniel P.S.: I downloaded the file ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 and run the following commands: CONFIGURE $ ./configure --prefix=/usr/local checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu Which we'll further canonicalise into: x86_64-unknown-linux checking for path to top of build tree... /home/daniel/uploaded/ghc-6.10.2 checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... yes checking for ar arguments... q checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether ranlib is needed... no checking for sed... /bin/sed checking version of gcc... 4.1.2 checking how to run the C preprocessor... gcc -E checking for extra options to pass gcc when compiling via C... -fwrapv -mno-omit-leaf-frame-pointer -fno-unit-at-a-time configure: creating ./config.status config.status: creating Makefile-vars config.status: creating extra-gcc-opts **************************************************** Configuration done, ready to 'make install' (see README and INSTALL files for more info.) **************************************************** MAKE INSTALL: $ make install /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier/mkdirhier /usr/local/bin /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier/mkdirhier /usr/local/lib/ghc-6.10.2 echo "[]" > /usr/local/lib/ghc-6.10.2/package.conf make -C includes install DOING_BIN_DIST=YES make[1]: Entering directory `/home/daniel/uploaded/ghc-6.10.2/includes' /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier/mkdirhier /usr/local/lib/ghc-6.10.2/include for i in Block.h Bytecodes.h ClosureMacros.h Closures.h ClosureTypes.h Cmm.h config.h Constants.h DerivedConstants.h DNInvoke.h Dotnet.h FileLock.h ghcconfig.h GHCConstants.h GranSim.h Hooks.h HsFFI.h ieee-flpt.h InfoTables.h Linker.h Liveness.h MachDeps.h MachRegs.h OSThreads.h Parallel.h Regs.h RtsAPI.h RtsConfig.h RtsExternal.h RtsFlags.h Rts.h RtsMessages.h RtsTypeable.h RtsTypes.h SchedAPI.h Signals.h SMPClosureOps.h SMP.h SpinLock.h Stable.h StgDLL.h StgFun.h Stg.h StgLdvProf.h StgMiscClosures.h StgProf.h StgTypes.h STM.h Storage.h TailCalls.h TickyCounters.h TSO.h ghcautoconf.h ghcplatform.h; do \ /usr/bin/install -c -m 644 $i /usr/local/lib/ghc-6.10.2/include; \ done make[1]: Leaving directory `/home/daniel/uploaded/ghc-6.10.2/includes' make -C utils install DOING_BIN_DIST=YES make[1]: Entering directory `/home/daniel/uploaded/ghc-6.10.2/utils' ------------------------------------------------------------------------ == Recursively making `install' in mkdirhier hp2ps parallel unlit ... PWD = /home/daniel/uploaded/ghc-6.10.2/utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make install -w; in /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier ------------------------------------------------------------------------ make[2]: Nothing to be done for `install'. Finished making install in mkdirhier: 0 ------------------------------------------------------------------------ == make install -w; in /home/daniel/uploaded/ghc-6.10.2/utils/hp2ps ------------------------------------------------------------------------ /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier/mkdirhier /usr/local/bin for i in hp2ps ; do \ /usr/bin/install -c -m 755 -m 755 $i /usr/local/bin ; \ if test "" = "1"; then \ sh /mk/fix_install_names.sh /usr/local/lib/ghc-6.10.2 /usr/local/bin/$i ; \ fi ; \ done Finished making install in hp2ps: 0 ------------------------------------------------------------------------ == make install -w; in /home/daniel/uploaded/ghc-6.10.2/utils/parallel ------------------------------------------------------------------------ make[2]: Nothing to be done for `install'. Finished making install in parallel: 0 ------------------------------------------------------------------------ == make install -w; in /home/daniel/uploaded/ghc-6.10.2/utils/unlit ------------------------------------------------------------------------ /home/daniel/uploaded/ghc-6.10.2/utils/mkdirhier/mkdirhier /usr/local/lib/ghc-6.10.2 for i in unlit; do \ /usr/bin/install -c -m 755 -m 755 $i /usr/local/lib/ghc-6.10.2; \ if test "" = "1"; then \ sh /mk/fix_install_names.sh /usr/local/lib/ghc-6.10.2 /usr/local/lib/ghc-6.10.2/`basename $i` ; \ fi ; \ done Finished making install in unlit: 0 ------------------------------------------------------------------------ == Finished making `install' in mkdirhier hp2ps parallel unlit ... PWD = /home/daniel/uploaded/ghc-6.10.2/utils ------------------------------------------------------------------------ make -C ghc-pkg install make[2]: Entering directory `/home/daniel/uploaded/ghc-6.10.2/utils/ghc-pkg' /home/daniel/uploaded/ghc-6.10.2/utils/installPackage/install-inplace/bin/installPackage install \ '/home/daniel/uploaded/ghc-6.10.2/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/usr/local/lib/ghc-6.10.2/package.conf' \ '' '/usr/local' \ '/usr/local' '/usr/local/bin' '/usr/local/lib/ghc-6.10.2' \ '/usr/local/lib/ghc-6.10.2' '' '/usr/local/lib/ghc-6.10.2' \ '/usr/local/share/doc/ghc' '/usr/local/share/doc/ghc' '' \ --distpref dist-install \ --enable-shell-wrappers Installing executable(s) in /usr/local/bin /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not recognized make[2]: *** [install] Error 1 make[2]: Leaving directory `/home/daniel/uploaded/ghc-6.10.2/utils/ghc-pkg' make[1]: *** [install.ghc-pkg] Error 2 make[1]: Leaving directory `/home/daniel/uploaded/ghc-6.10.2/utils' make: *** [install] Error 2 SOME CHECKS $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ ghc-pkg --version GHC package manager version 6.6 $ uname -msr Linux 2.6.18-6-amd64 x86_64 From igloo at earth.li Thu Apr 16 08:31:05 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Apr 16 08:17:30 2009 Subject: Problem installing GHC 6.10.2 on Debian Etch In-Reply-To: <49E71F04.6040102@gmx.net> References: <49E71F04.6040102@gmx.net> Message-ID: <20090416123105.GA30935@matrix.chaos.earth.li> On Thu, Apr 16, 2009 at 02:05:24PM +0200, Daniel van den Eijkel wrote: > > I am trying to install GHC-6.10.2 on Debian Etch and I get the following > error: > > /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not > recognized IIRC, this happens if you have binutils 2.17. Upgrading should fix it. Thanks Ian From dvde at gmx.net Thu Apr 16 11:49:28 2009 From: dvde at gmx.net (Daniel van den Eijkel) Date: Thu Apr 16 11:35:53 2009 Subject: Problem installing GHC 6.10.2 on Debian Etch In-Reply-To: <20090416123105.GA30935@matrix.chaos.earth.li> References: <49E71F04.6040102@gmx.net> <20090416123105.GA30935@matrix.chaos.earth.li> Message-ID: <49E75388.2040306@gmx.net> Thanks for the answer. I upgraded from Debian Etch to Lenny, and this upgraded ghc to version 6.8.2. Then I tried again to install ghc-6.10.2 and it worked without problems. But now I have 2 versions, and by default ghc-6.8 is called. Is there a simple way to make ghc-6.10 the default ghc? Do I have to change the symlinks by hand? Thanks, Daniel Ian Lynagh schrieb: > On Thu, Apr 16, 2009 at 02:05:24PM +0200, Daniel van den Eijkel wrote: > >> I am trying to install GHC-6.10.2 on Debian Etch and I get the following >> error: >> >> /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not >> recognized >> > > IIRC, this happens if you have binutils 2.17. Upgrading should fix it. > > > Thanks > Ian > > From dvde at gmx.net Thu Apr 16 14:23:23 2009 From: dvde at gmx.net (Daniel van den Eijkel) Date: Thu Apr 16 14:09:47 2009 Subject: Problem installing GHC 6.10.2 on Debian Etch In-Reply-To: <49E769F9.3030707@centrum.cz> References: <49E71F04.6040102@gmx.net> <20090416123105.GA30935@matrix.chaos.earth.li> <49E75388.2040306@gmx.net> <49E769F9.3030707@centrum.cz> Message-ID: <49E7779B.8020909@gmx.net> That helped. $ aptitude remove ghc did not remove or install any packages, but now ghc --version says 6.10.2 on the other hand, ghc 6.8.2 is still on the system dpkg -l says ghc6 6.8.2dfsg1-1 GHC - the Glasgow Haskell Compilation system ghc6-doc 6.8.2dfsg1-1 Documentation for the Glasgow Haskell Compilation system ghc6-libsrc 6.6-3 Library Sources of GHC, the Glasgow Haskell Compilation system ghc6-prof 6.8.2dfsg1-1 Profiling libraries for the Glasgow Haskell Compilation system $ ls -l /usr/bin/ghc* /usr/bin/ghc -> /etc/alternatives/ghc /usr/bin/ghc6 -> ../lib/ghc-6.8.2/bin/ghc /usr/bin/ghc-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-6.8.2 /usr/bin/ghci -> /etc/alternatives/ghci /usr/bin/ghci6 -> ../lib/ghc-6.8.2/bin/ghci /usr/bin/ghci-6.8.2 -> ../lib/ghc-6.8.2/bin/ghci-6.8.2 /usr/bin/ghc-pkg -> /etc/alternatives/ghc-pkg /usr/bin/ghc-pkg6 -> ../lib/ghc-6.8.2/bin/ghc-pkg /usr/bin/ghc-pkg-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-pkg-6.8.2 /usr/bin/ghcprof -> /etc/alternatives/ghcprof /usr/bin/ghcprof6 -> ../lib/ghc-6.8.2/bin/ghcprof $ ls -l /etc/alternatives/ghc* /usr/bin/ghc -> /etc/alternatives/ghc /usr/bin/ghc6 -> ../lib/ghc-6.8.2/bin/ghc /usr/bin/ghc-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-6.8.2 /usr/bin/ghci -> /etc/alternatives/ghci /usr/bin/ghci6 -> ../lib/ghc-6.8.2/bin/ghci /usr/bin/ghci-6.8.2 -> ../lib/ghc-6.8.2/bin/ghci-6.8.2 /usr/bin/ghc-pkg -> /etc/alternatives/ghc-pkg /usr/bin/ghc-pkg6 -> ../lib/ghc-6.8.2/bin/ghc-pkg /usr/bin/ghc-pkg-6.8.2 -> ../lib/ghc-6.8.2/bin/ghc-pkg-6.8.2 /usr/bin/ghcprof -> /etc/alternatives/ghcprof /usr/bin/ghcprof6 -> ../lib/ghc-6.8.2/bin/ghcprof $ ls -l /usr/local/bin/ghc* /usr/local/bin/ghc -> ghc-6.10.2 /usr/local/bin/ghc-6.10.2 /usr/local/bin/ghci -> ghci-6.10.2 /usr/local/bin/ghci-6.10.2 /usr/local/bin/ghc-pkg -> ghc-pkg-6.10.2 /usr/local/bin/ghc-pkg-6.10.2 so /usr/local/bin shadows the /usr/bin directory? I am not sure if I'm going to run into trouble with this installation, so I decided to completely uninstall the old ghc6. It removed some other packages, too: g++-4.1{u} ghc6 ghc6-prof{a} haskell-utils{u} libgmp3-dev{u} libgmpxx4ldbl{u} libncurses5-dev{u} libreadline5-dev{u} libstdc++6-4.1-dev{u} After that, there was no ghc anymore except the 6.10.2 - as desired. But a hello-world-compilation failed because of missing lgmp. So I installed libgmp3-dev and libgmpxx4ldbl Now it seems to work again, but I expect to run in trouble again. I'll keep you up-to-date. Thanks, Daniel Karel Gardas schrieb: > What does happen if you uninstall ghc-6.8.2 by using dpkg/apt-get? IIRC > ghc is completely linked statically (haskel libs) so your 6.10.2 does > not depend on 6.8.2. > > Cheers, > Karel > > Daniel van den Eijkel wrote: > >> Thanks for the answer. >> I upgraded from Debian Etch to Lenny, and this upgraded ghc to version >> 6.8.2. Then I tried again to install ghc-6.10.2 and it worked without >> problems. >> >> But now I have 2 versions, and by default ghc-6.8 is called. Is there a >> simple way to make ghc-6.10 the default ghc? Do I have to change the >> symlinks by hand? >> >> Thanks, >> Daniel >> >> Ian Lynagh schrieb: >> >>> On Thu, Apr 16, 2009 at 02:05:24PM +0200, Daniel van den Eijkel wrote: >>> >>> >>>> I am trying to install GHC-6.10.2 on Debian Etch and I get the >>>> following error: >>>> >>>> /usr/bin/strip: /usr/local/lib/ghc-6.10.2/ghc-pkg: File format not >>>> recognized >>>> >>>> >>> IIRC, this happens if you have binutils 2.17. Upgrading should fix it. >>> >>> >>> Thanks >>> Ian >>> >>> >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> > > From lane at downstairspeople.org Thu Apr 16 18:02:29 2009 From: lane at downstairspeople.org (Christopher Lane Hinson) Date: Thu Apr 16 17:48:56 2009 Subject: Segfault in RSAGL with +RTS -G4 Message-ID: I regret that I don't have a simpler failure case, but I'm just going to post this and please advise me. I don't see how to get debugging symbols to work to even look at a core dump. Usually I get a segfault, but sometimes I get this: _rsagl_modelview: internal error: evacuate: strange closure type 2053 (GHC version 6.10.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted This program uses ffi, but in this checkin I've disabled RSAGL's ffi except the GLUT+OpenGL bindings. So it's OpenGL or ghc. The key to getting this error is the -G flag. -G4 or -G3 segfaults. Steps to replicate: git clone http://www.downstairspeople.org/git/rsagl.git cd rsagl/ git checkout possible_rts_bug_g4 cabal configure && cabal build ./dist/build/_rsagl_modelview/_rsagl_modelview +RTS -G4 -RTS <-- just sit and wait, it should display an animation briefly and then segfault. Friendly, --Lane From phercek at gmail.com Fri Apr 17 07:33:27 2009 From: phercek at gmail.com (Peter Hercek) Date: Fri Apr 17 07:19:56 2009 Subject: failure implementing :next command in ghci In-Reply-To: References: Message-ID: <49E86907.80906@gmail.com> Hi, Maybe the code adding one Int argument to rts_breakpoint_io_action is correct in general since when Pepe Iborra applied the patch to his ghc trunk the test did not crash on his machine. Regardless on my machine the test does not work even with the stock ghc 6.10.2 sources (so even when I do not have the patch applied). Here is how I did the test on my 32 bit archlinux: * downloaded ghc-6.10.2-src.tar.bz2 from http://haskell.org/ghc/download_ghc_6_10_2.html#sources (I did not download the extralibs tarball) * unpacked ghc-6.10.2-src.tar.bz2 and did this in the ghc-6.10.2 directory: ./boot ./configure make * then I did this test: status:0 peter@metod [892] ~/haskell/ghc-6.10.2 % cat a.hs f :: Int -> Int f x = x + 1 a = f 1 status:0 peter@metod [893] ~/haskell/ghc-6.10.2 % ghc/stage2-inplace/ghc --interactive a.hs GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main> :break f Breakpoint 0 activated at a.hs:2:0-10 *Main> :force a zsh: segmentation fault ghc/stage2-inplace/ghc --interactive a.hs status:139 peter@metod [894] ~/haskell/ghc-6.10.2 % The test works ok when I do it with the ghc-custom I have installed (6.10.1 with few of my patches). The same behavior is on my laptop which has only stock uptodate archlinux, and stock ghc 6.10.1 installed (so I think it cannot be because of my few patches in ghc 6.10.1). I did the clean build and the test there too. Well to be precise, it works worse on my laptop since when I try to run ghci 6.10.1 (as distributed by archlinux) I'll get a crash too: status:0 peter@dwarf [852] ~/haskell/ghc-6.10.2 % ghci a.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main> :break f Breakpoint 0 activated at a.hs:2:0-10 *Main> :force a% status:139 peter@dwarf [853] ~/haskell/ghc-6.10.2 % The question is: Is the test supposed to work with ghc 6.10.2 without installing it? I hope I'm doing some stupid mistake and that archlinux is not borked. What is the platform (distribution and it's version) ghc HQ uses for ghc development (on which the test I presented works)? Thanks, Peter. From bayer at cpw.math.columbia.edu Sat Apr 18 14:39:00 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Sat Apr 18 14:25:21 2009 Subject: No "last core parallel slowdown" on OS X Message-ID: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> I'm a huge fan of the recent paper http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for-multicore-haskell/ which put me over the top to get started writing parallel code in Haskell. Parallel code is now integral to my and my Ph.D. students' research. For example, we recently checked an assertion for the roughly 69 billion atomic lattices on six atoms, in a day rather than a week, using perhaps 6 lines of parallel code in otherwise sequential code. When you're anxiously waiting for the answer, a day is a lot better than a week. (The enumeration itself is down to two hours on 7 cores, which astounds me. I see no reason to ever use another language.) In that paper, they routinely benchmark N-1 cores on an N core Linux box, because of a noticeable falloff using the last core, which can do more harm than good. I had confirmed this on my four core Linux box, but was puzzled that my two core MacBook showed no such falloff. Hey, two cores isn't representative of many cores, cache issues yada yada, so I waited. I just got an EFi-X "boot processor" (efi-x.com) working on a nearly identical quad core box that I built, and I tested the same computations with OS X. For my test case, there's a mild cost to moving to parallel at all, but... Compared to 2 cores, using 3, 4 cores on a four core Linux box gives speedups of 1.37x, 1.38x Compared to 2 cores, using 3, 4 cores on an equivalent four core box running OS X gives speedups of 1.45x, 1.9x Here 1.5x, 2.0x is ideal, so I'm thrilled. If we can't shame Linux into fixing this, I'm never looking back. How true is this for other parallel languages? Haskell alone is perhaps too fringe to cause a Linux scandal over this, even if it should... The EFi-X boot processor itself is rather expensive ($240 now), and there's sticking to a specific hardware compatibility list, and I needed to update my motherboard BIOS and the EFi-X firmware, but no other fiddling for me. These boxes are just compute servers for me, I would have been ok returning to Linux, but not if it means giving up a core. People worry about compatibility, "I sensed a softness in the surround sound in game X...", but for me the above numbers put all this in perspective. Another way to put this, especially for those who don't have a strong preference for building their own machines, and can't wait for Linux to get its act together: If you're serious about parallel Haskell, buy a Mac Pro. From pumpkingod at gmail.com Sat Apr 18 16:46:44 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Sat Apr 18 16:33:02 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: That looks great! I wonder what about Mac OS leads to such good performance... Now if only we could get a nice x86_64-producing GHC for Mac OS too, I could use all my RAM and the extra registers my Mac Pro gives me :) On Sat, Apr 18, 2009 at 2:39 PM, Dave Bayer wrote: > I'm a huge fan of the recent paper > > http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for-multicore-haskell/ > > which put me over the top to get started writing parallel code in Haskell. > Parallel code is now integral to my and my Ph.D. students' research. For > example, we recently checked an assertion for the roughly 69 billion atomic > lattices on six atoms, in a day rather than a week, using perhaps 6 lines of > parallel code in otherwise sequential code. When you're anxiously waiting > for the answer, a day is a lot better than a week. (The enumeration itself > is down to two hours on 7 cores, which astounds me. I see no reason to ever > use another language.) > > In that paper, they routinely benchmark N-1 cores on an N core Linux box, > because of a noticeable falloff using the last core, which can do more harm > than good. I had confirmed this on my four core Linux box, but was puzzled > that my two core MacBook showed no such falloff. Hey, two cores isn't > representative of many cores, cache issues yada yada, so I waited. > > I just got an EFi-X "boot processor" (efi-x.com) working on a nearly > identical quad core box that I built, and I tested the same computations > with OS X. For my test case, there's a mild cost to moving to parallel at > all, but... > > Compared to 2 cores, using 3, 4 cores on a four core Linux box gives > speedups of > > ? ? ? ?1.37x, 1.38x > > Compared to 2 cores, using 3, 4 cores on an equivalent four core box running > OS X gives speedups of > > ? ? ? ?1.45x, 1.9x > > Here 1.5x, 2.0x is ideal, so I'm thrilled. If we can't shame Linux into > fixing this, I'm never looking back. How true is this for other parallel > languages? Haskell alone is perhaps too fringe to cause a Linux scandal over > this, even if it should... > > The EFi-X boot processor itself is rather expensive ($240 now), and there's > sticking to a specific hardware compatibility list, and I needed to update > my motherboard BIOS and the EFi-X firmware, but no other fiddling for me. > These boxes are just compute servers for me, I would have been ok returning > to Linux, but not if it means giving up a core. People worry about > compatibility, "I sensed a softness in the surround sound in game X...", but > for me the above numbers put all this in perspective. > > Another way to put this, especially for those who don't have a strong > preference for building their own machines, and can't wait for Linux to get > its act together: > > If you're serious about parallel Haskell, buy a Mac Pro. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bayer at cpw.math.columbia.edu Sat Apr 18 20:05:34 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Sat Apr 18 19:51:55 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: <69E15C4E-4681-408F-8EC0-4372F8AFD45B@math.columbia.edu> Yikes! You're right. I never noticed, but I never had an 8 GB Mac before. I looked at ./configure for the GHC 6.10.2 source, and realized there was already something there. I tried ./configure --build=x86_64-apple-darwin and it didn't work. However, it did give me something to Google, leading me to Ticket #2965 (new feature request) GHC on OS X does not compile 64-bit 1/19/09 http://hackage.haskell.org/trac/ghc/ticket/2965 Apparently this isn't a one-liner. Once my semester ends, I'll see if I can help. I've got to wonder if it would be less work to sneak a gift Mac Pro past Microsoft security, and just wait? ;-) The GHC team has been busting their humps on parallel code lately, and OS X does so much better... They should stop having to apologize in papers for the poor parallel performance of Linux itself. A decked-out Mac Pro should be the flagship platform for 64 bit, parallel GHC. On Apr 18, 2009, at 1:46 PM, Daniel Peebles wrote: > That looks great! I wonder what about Mac OS leads to such good > performance... > > Now if only we could get a nice x86_64-producing GHC for Mac OS too, I > could use all my RAM and the extra registers my Mac Pro gives me :) From mad.one at gmail.com Sat Apr 18 20:14:36 2009 From: mad.one at gmail.com (Austin Seipp) Date: Sat Apr 18 20:00:55 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <69E15C4E-4681-408F-8EC0-4372F8AFD45B@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <69E15C4E-4681-408F-8EC0-4372F8AFD45B@math.columbia.edu> Message-ID: <1240099731-sup-232@existential.local> Excerpts from Dave Bayer's message of Sat Apr 18 19:05:34 -0500 2009: > Yikes! You're right. I never noticed, but I never had an 8 GB Mac > before. > > I looked at ./configure for the GHC 6.10.2 source, and realized there > was already something there. I tried > > ./configure --build=x86_64-apple-darwin > > and it didn't work. However, it did give me something to Google, > leading me to > > Ticket #2965 (new feature request) > GHC on OS X does not compile 64-bit > 1/19/09 > http://hackage.haskell.org/trac/ghc/ticket/2965 > > Apparently this isn't a one-liner. Once my semester ends, I'll see if > I can help. > > I've got to wonder if it would be less work to sneak a gift Mac Pro > past Microsoft security, and just wait? ;-) > > The GHC team has been busting their humps on parallel code lately, and > OS X does so much better... They should stop having to apologize in > papers for the poor parallel performance of Linux itself. A decked-out > Mac Pro should be the flagship platform for 64 bit, parallel GHC. > > On Apr 18, 2009, at 1:46 PM, Daniel Peebles wrote: > > > That looks great! I wonder what about Mac OS leads to such good > > performance... > > > > Now if only we could get a nice x86_64-producing GHC for Mac OS too, I > > could use all my RAM and the extra registers my Mac Pro gives me :) > Please add yourself to the CC list of the bug - more people need to show they care! I'm currently the owner of the bug, so if you bother me enough I'll get to working on it quicker (once I have more time...) At the very least, once the build system fixes are in place to allow hc-bootstrapping, it should happen fairly quickly. Right now I'm just not quite sure what the full path necessary is for getting a copy of GHC head to be 64-bit on OS X. Daniel, have you gotten anywhere with your version of GHC 6.6 on OS X? Austin From chak at cse.unsw.edu.au Sun Apr 19 05:58:46 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Apr 19 05:45:03 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: <485A0E3B-5BFD-4BFA-9BAE-CF1E98DA328E@cse.unsw.edu.au> Dave Bayer: > In that paper, they routinely benchmark N-1 cores on an N core Linux > box, because of a noticeable falloff using the last core, which can > do more harm than good. I had confirmed this on my four core Linux > box, but was puzzled that my two core MacBook showed no such > falloff. Hey, two cores isn't representative of many cores, cache > issues yada yada, so I waited. [..] > Compared to 2 cores, using 3, 4 cores on an equivalent four core box > running OS X gives speedups of > > 1.45x, 1.9x As another data point, in our work on Data Parallel Haskell, we ran benchmarks on an 8-core Xserve (OS X) and an 8-core Sun T2 (Solaris). On both machines, we had no problem using all 8 cores. Manuel From twhitehead at gmail.com Mon Apr 20 00:59:12 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Apr 20 00:45:59 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: <200904200059.36197.twhitehead@gmail.com> On April 18, 2009 16:46:44 Daniel Peebles wrote: > That looks great! I wonder what about Mac OS leads to such good > performance... > > Now if only we could get a nice x86_64-producing GHC for Mac OS too, I > could use all my RAM and the extra registers my Mac Pro gives me :) I was a bit surprised when I read the initial report because 1- I thought GHC had a hard time with 32bit x86 code due to the integer register pressure and hacking around the stack based FPU, and 2- I though OS X had multithreading performance issues (or at least that is what I had read in various reports regarding using it as a server). This leave me wondering how do the absolute numbers compare? Could the extra overhead due to the various 32bit issues be giving more room for better threading performance? What do you get if you use 32bit GHC with Linux? Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090420/84d9c627/attachment.bin From marlowsd at gmail.com Mon Apr 20 06:58:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 06:45:02 2009 Subject: ghc-pkg check problem in 6.10.2 In-Reply-To: References: <49D4A57F.4070905@gmail.com> Message-ID: <49EC5562.9010606@gmail.com> David Waern wrote: > 2009/4/2 Simon Marlow : >> I just noticed that the new 'ghc-pkg check' feature exposes a silly mistake >> in the definition of the rts package that we ship with GHC 6.10.2: >> >> $ ghc-pkg check >> There are problems in package rts-1.0: >> include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory >> >> ... >> >> To fix it, issue this command: >> >> $ ghc-pkg describe rts | sed 's/PAPI_INCLUDE_DIR//' | ghc-pkg update - >> >> and now "ghc-pkg check" should give no errors: >> >> $ ghc-pkg check >> $ >> >> (Except on Windows, where there also seems to be a problem with the Haddock >> package. Haddock itself is ok, but the Haddock library has some problems >> with its registration.) > > Oh, which problems? $ ghc-pkg check There are problems in package haddock-2.4.2: import-dirs: c:/builds/slave/x86-win-stable/build/ghc-6.10.2\haddock-2.4.2 doesn't exist or isn't a directory library-dirs: c:/builds/slave/x86-win-stable/build/ghc-6.10.2\haddock-2.4.2 doesn't exist or isn't a directory file Distribution\Haddock.hi is missing file Haddock\DocName.hi is missing file Haddock\Types.hi is missing file Haddock\InterfaceFile.hi is missing file Haddock\Exception.hi is missing file Haddock\Utils.hi is missing file Haddock\GHC\Utils.hi is missing cannot find libHShaddock-2.4.2.a on library path The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. haddock-2.4.2 It's not a serious problem since I don't think the Haddock package is used by anything (is it?). But we ought to have a clean ghc-pkg check nevertheless. Cheers, Simon From ndmitchell at gmail.com Mon Apr 20 08:54:42 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 20 08:40:53 2009 Subject: Parallel performance drops off a cliff Message-ID: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> Hi, Using one benchmark I have, which doesn't create any threads, I have: $ benchmark +RTS -Nx x time (Seconds) 1 2 2 2 3 2 4 3 5 3 6 3 7 3 8 aborted after 2 minutes This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known bug, or should I try and replicate it? (benchmark is fairly big and very dependent on internal things, but I suspect the dramatic performance slowdown is unlikely to be related to these bits). Thanks Neil From marlowsd at gmail.com Mon Apr 20 09:38:13 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 09:24:32 2009 Subject: trouble compiling 6.8.3 using 6.8.3 In-Reply-To: <49DA6B82.4060503@cs.utexas.edu> References: <49D60CD2.2060706@cs.utexas.edu> <49D60E39.4090506@cs.utexas.edu> <49DA6B82.4060503@cs.utexas.edu> Message-ID: <49EC7AC5.1060609@gmail.com> Jason Pepas wrote: > Jason Pepas wrote: >> Jason Pepas wrote: >>> /lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1 >> >> Um, scratch that. I've apparently become confused as to which release >> I was actually building. >> >> -jason >> > > So I've run into a (legitimate) issue with building 6.8.3. > > Initiall I was getting things like this: > > > build error: > ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes > -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel > -optc-Ism > -optc-DCOMPILING_RTS -optc-g -optc-O0 -optc-I../gmp/gmpbuild > -optc-fno-strict-aliasing -H16m -O -package-name rts -static > -I../gmp/gmpbuild > -I. -#include HCIncludes.h -dcmm-lint -hisuf debug_hi -hcsuf debug_hc > -osuf > debug_o -optc-DDEBUG -c ProfHeap.c -o ProfHeap.debug_o > > Printer.c:962:17: error: bfd.h: No such file or directory > > > this was being caused by not being able to find binutils-related > headers. similar errors occured after not being able to find readline > headers. (these were in a non-standard location). > > I got around this by exporting some env vars: > > export CPPFLAGS="-I/lusr/gnu/include -I/lusr/include" > export LDFLAGS="-L/lusr/lib -L/lusr/gnu/lib" > > however, that still didn't solve the problem, and eventually I resorted > to "grafting" (copying via symlinks) the include files into the > build-dir/includes directory. > > that worked until I ran into this: > > > checking for readline in -lreadline... yes > checking for rl_readline_version... yes > checking for rl_begin_undo_group... yes > checking for rl_erase_empty_line... yes > checking for rl_free_undo_list... yes > checking for rl_completion_word_break_hook in -lreadline... yes > configure: creating ./config.status > config.status: creating readline.buildinfo > config.status: creating include/HsReadlineConfig.h > if ifBuildable/ifBuildable readline; then \ > cd readline && \ > cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp > GNUmakefile; \ > make -wr --jobserver-fds=3,4 -j && \ > setup/Setup register --inplace; \ > fi > mv: cannot stat `GNUmakefile': No such file or directory > Preprocessing library readline-1.0.1.0... > /lusr/gnu/bin/ld: cannot find -lreadline > collect2: ld returned 1 exit status > linking dist/build/System/Console/Readline_hsc_make.o failed > command was: gcc -lreadline -lncurses > dist/build/System/Console/Readline_hsc_make.o -o > dist/build/System/Console/Readline_hsc_make > make[2]: Entering directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' > make[2]: *** No targets specified and no makefile found. Stop. > make[2]: Leaving directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' > make[1]: *** [make.library.readline] Error 2 > make[1]: Leaving directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries' > make: *** [stage1] Error 2 > > > specifically, what is failing is the "setup/Setup makefile -f > GNUmakefile" command. > > > bash-3.2$ setup/Setup makefile -f GNUmakefile > Preprocessing library readline-1.0.1.0... > /lusr/gnu/bin/ld: cannot find -lreadline > collect2: ld returned 1 exit status > linking dist/build/System/Console/Readline_hsc_make.o failed > command was: gcc -lreadline -lncurses > dist/build/System/Console/Readline_hsc_make.o -o > dist/build/System/Console/Readline_hsc_make > > > however, if you cd into build-dir/libraries/readline and run this manually: > > > ./configure --with-readline-includes=/lusr/gnu/include > --with-readline-libraries=/lusr/gnu/lib > > > you can then run the "setup/Setup makefile -f GNUmakefile" and it works. > > > so I thought I'd try simply modifying the libraries/Makefile: > > > bash-3.2$ diff -urN libraries/Makefile.orig libraries/Makefile > --- libraries/Makefile.orig 2009-04-06 14:36:44.000000000 -0500 > +++ libraries/Makefile 2009-04-06 15:29:14.000000000 -0500 > @@ -277,9 +277,11 @@ > if ifBuildable/ifBuildable $*; then \ > cd $* && \ > cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ > - mv GNUmakefile GNUmakefile.tmp; \ > + if [ -e GNUmakefile ] ; then mv GNUmakefile GNUmakefile.tmp ; fi ;\ > + if [ "$*" = "readline" ] ; then ./configure > --with-readline-includes=/lusr/gnu/include > --with-readline-libraries=/lusr/gnu/lib ; fi ; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp > GNUmakefile; \ > + echo $(MAKE) $(MFLAGS) && \ > $(MAKE) $(MFLAGS) && \ > setup/Setup register --inplace; \ > fi > > > but that doesn't work: > > Preprocessing library readline-1.0.1.0... > Generating Makefile readline-1.0.1.0... > make -wr > make[2]: Entering directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries/readline' > Registering readline-1.0.1.0... > Reading package info from "dist/inplace-pkg-config" ... done. > Unable to rename "/lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf" to > "/lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf.old" > Saving old package config file... ghc-pkg.bin: > /lusr/opt/ghc-6.8.3/lib/ghc-6.8.3/package.conf: renameFile: permission > denied > (Permission denied) > make[1]: *** [make.library.readline] Error 1 > make[1]: Leaving directory > `/v/filer4b/cvsbuild/CVSBUILD/ghc-6.8.3-linux-i686/ghc/libraries' > make: *** [stage1] Error 2 > > > At this point I think this has gotten a little too hack-ish, so I > thought I'd ask the mailing list what for proper way of telling ghc > where your readline installation lives? I think the problem you're describing never got fixed: see http://hackage.haskell.org/trac/ghc/ticket/2970 and then we decided to replace readline with editline (bad mistake) and later decided to adopt haskeline instead. I believe some OSs (e.g. FreeBSD) that put readline outside the standard locations have their own hacks to get around this. Cheers, Simon From marlowsd at gmail.com Mon Apr 20 09:48:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 09:34:19 2009 Subject: Segfault in RSAGL with +RTS -G4 In-Reply-To: References: Message-ID: <49EC7D12.8090501@gmail.com> Christopher Lane Hinson wrote: > > I regret that I don't have a simpler failure case, but I'm just going to > post this and please advise me. I don't see how to get debugging > symbols to work to even look at a core dump. > > Usually I get a segfault, but sometimes I get this: > > _rsagl_modelview: internal error: evacuate: strange closure type 2053 > (GHC version 6.10.1 for i386_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted > > This program uses ffi, but in this checkin I've disabled RSAGL's ffi > except the GLUT+OpenGL bindings. So it's OpenGL or ghc. > > The key to getting this error is the -G flag. -G4 or -G3 segfaults. > > Steps to replicate: > > git clone http://www.downstairspeople.org/git/rsagl.git > cd rsagl/ > git checkout possible_rts_bug_g4 > cabal configure && cabal build > ./dist/build/_rsagl_modelview/_rsagl_modelview +RTS -G4 -RTS > <-- just sit and wait, it should display an animation briefly and then > segfault. Could you check whether this still happens with 6.10.2, and if so, please report it via http://hackage.haskell.org/trac/ghc/wiki/ReportABug. Cheers, Simon From marlowsd at gmail.com Mon Apr 20 09:54:50 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 09:41:07 2009 Subject: failure implementing :next command in ghci In-Reply-To: References: Message-ID: <49EC7EAA.8030407@gmail.com> Peter Hercek wrote: > Hi, > > So I wanted to give implementing :next ghci debugger command a shot. It > looked easy and I could use it. Moreover it would give me an easy way to > implement dynamic stack in ghci (using similar approach as used for > trace) ... well if I would feel like that since I was a bit discouraged > about it. The problem is I failed miserably. I still think it is easy to > do. I just do not know how to create correct arguments for > rts_breakpoint_io_action and I have given up finding up myself for now. > > > The proposed meaning for :next > > Lets mark dynamic stack size at a breakpoint (at which we issue :next) > as breakStackSize and its selected expression as breakSpan. Then :next > would single step till any of these is true: > 1) current dynamic stack size is smaller than breakStackSize > 2) current dynamic stack size is equal to breakStackSize and the current > selected expression is not a subset of breakSpan So what happens if the stack shrinks and then grows again between two breakpoints? Presumably :next wouldn't notice. I think you'd be better off implementing this with a special stack frame, so that you can guarantee to notice when the current "context" has been exited. Still, I'm not completely sure that :next really makes sense... but I haven't thought about it in any great detail. > I hope the above would make good sense but I do not really know since > maybe rts does some funny things with stack sometimes. If you think the > proposed behavior is garbage let me know why so that I do not waste more > time with this :) Yes the RTS does do "funny thing" with the stack sometimes. The stack can shrink as a result of adjacent update frames being coalesced ("stack squeezing"). Using a stack frame instead of a "low water mark" would be immune to this. Cheers, Simon From marlowsd at gmail.com Mon Apr 20 10:01:34 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 09:47:51 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <485A0E3B-5BFD-4BFA-9BAE-CF1E98DA328E@cse.unsw.edu.au> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <485A0E3B-5BFD-4BFA-9BAE-CF1E98DA328E@cse.unsw.edu.au> Message-ID: <49EC803E.7030500@gmail.com> Manuel M T Chakravarty wrote: > Dave Bayer: >> In that paper, they routinely benchmark N-1 cores on an N core Linux >> box, because of a noticeable falloff using the last core, which can do >> more harm than good. I had confirmed this on my four core Linux box, >> but was puzzled that my two core MacBook showed no such falloff. Hey, >> two cores isn't representative of many cores, cache issues yada yada, >> so I waited. > [..] >> Compared to 2 cores, using 3, 4 cores on an equivalent four core box >> running OS X gives speedups of >> >> 1.45x, 1.9x > > As another data point, in our work on Data Parallel Haskell, we ran > benchmarks on an 8-core Xserve (OS X) and an 8-core Sun T2 (Solaris). > On both machines, we had no problem using all 8 cores. I suspect some scheduling weirdness in Linux, at least in the kernel we're using here (2.6.25). Traces appeared to show that one of our threads was being descheduled for a few ms, and this can be particularly severe in GHC since our stop-the-world GC needs frequent synchronisations. One advantage of moving to processor-independent GCs would be that we could degrade more gracefully if the CPUs are contended, or the OS scheduler just decides to use a core for something else for a while. Cheers, Simon From marlowsd at gmail.com Mon Apr 20 10:12:34 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 20 09:58:47 2009 Subject: Parallel performance drops off a cliff In-Reply-To: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> References: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> Message-ID: 2009/4/20 Neil Mitchell > > Hi, > > Using one benchmark I have, which doesn't create any threads, I have: > > $ benchmark +RTS -Nx > > x ? ? ? ? ? ? time (Seconds) > 1 ? ? ? ? ? ? ?2 > 2 ? ? ? ? ? ? ?2 > 3 ? ? ? ? ? ? ?2 > 4 ? ? ? ? ? ? ?3 > 5 ? ? ? ? ? ? ?3 > 6 ? ? ? ? ? ? ?3 > 7 ? ? ? ? ? ? ?3 > 8 ? ? ? ? ? ? ?aborted after 2 minutes > > This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known > bug, or should I try and replicate it? (benchmark is fairly big and > very dependent on internal things, but I suspect the dramatic > performance slowdown is unlikely to be related to these bits). Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus heuristics about when to turn on the parallel GC, and it just so happens that 8 processors tips it over the point where the parallel GC is enabled for young-generation collections. In 6.10.2 the parallel GC really didn't help most of the time, but it has undergone a lot of tuning since then, and in the HEAD things are much better (see the results from our ICFP submission). In the meantime you might get somewhere by disabling parallel GC altogether (+RTS -g1), but as the results in our paper show, sometimes the parallel GC is essential for retaining locality in parallel programs. Cheers, Simon From cell at cs.utexas.edu Mon Apr 20 10:12:43 2009 From: cell at cs.utexas.edu (Jason Pepas) Date: Mon Apr 20 09:59:59 2009 Subject: trouble compiling 6.8.3 using 6.8.3 In-Reply-To: <49EC7AC5.1060609@gmail.com> References: <49D60CD2.2060706@cs.utexas.edu> <49D60E39.4090506@cs.utexas.edu> <49DA6B82.4060503@cs.utexas.edu> <49EC7AC5.1060609@gmail.com> Message-ID: <49EC82DB.6080504@cs.utexas.edu> Simon Marlow wrote: > I think the problem you're describing never got fixed: see > > http://hackage.haskell.org/trac/ghc/ticket/2970 > > and then we decided to replace readline with editline (bad mistake) and > later decided to adopt haskeline instead. I believe some OSs (e.g. > FreeBSD) that put readline outside the standard locations have their own > hacks to get around this. > > Cheers, > Simon thanks, I'll try either updating to the latest version or cribbing from FreeBSD. -jason From phercek at gmail.com Mon Apr 20 12:06:34 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Apr 20 11:52:58 2009 Subject: failure implementing :next command in ghci In-Reply-To: <49EC7EAA.8030407@gmail.com> References: <49EC7EAA.8030407@gmail.com> Message-ID: <49EC9D8A.2010502@gmail.com> Simon Marlow wrote: > Peter Hercek wrote: >> The proposed meaning for :next >> >> Lets mark dynamic stack size at a breakpoint (at which we issue >> :next) as breakStackSize and its selected expression as breakSpan. >> Then :next would single step till any of these is true: >> 1) current dynamic stack size is smaller than breakStackSize >> 2) current dynamic stack size is equal to breakStackSize and the >> current selected expression is not a subset of breakSpan > > So what happens if the stack shrinks and then grows again between two > breakpoints? Presumably :next wouldn't notice. Yes, if there is no breakpoint in between I would not notice. I did not expect this can happen though. I thought that to add a frame on the stack this must be done within an expression (which is going to be forced) and the expression should be a breakpoint location. If it is so negligible that it does not have a breakpoint location associated then even the things it is calling should be negligible. Where is an error in this? > I think you'd be better off implementing this with a special stack > frame, so that you can guarantee to notice when the current "context" > has been exited. This would be robust but I do not have knowledge to do it yet. If I understand you correctly this means that before executing a BCO which we are going to break at, we must prepare for a possible :next. So regardless whether :next is going to be issued by the user or not we would add a frame which represents a return to a function which: a) if user issued :next it enables all breakpoints so that we stop at the next breakpoint b) if user did not issue a break it would not do anything (just return) We could decide not to insert the frame when we are only tracing. But if I would want to track a simulated dynamic stack I would need to insert this stack frame at the start of each breakpoint (when dynamic stack tracing would be on). Does not sound that good. >> I hope the above would make good sense but I do not really know since >> maybe rts does some funny things with stack sometimes. If you think >> the proposed behavior is garbage let me know why so that I do not >> waste more time with this :) > > Yes the RTS does do "funny thing" with the stack sometimes. The stack > can shrink as a result of adjacent update frames being coalesced > ("stack squeezing"). OK, so it looks like either switching off the squeezing (if shrinking and growing stack between breakpoints/ticks is not such an issue), or inserting a stack frame. Does the "stack squeezing" happen during garbage collection? Thanks, Peter. From bayer at cpw.math.columbia.edu Mon Apr 20 12:13:17 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Mon Apr 20 11:59:31 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> I ran some longer trials, and noticed a further pattern I wish I could explain: I'm comparing the enumeration of the roughly 69 billion atomic lattices on six atoms, on my four core, 2.4 GHz Q6600 box running OS X, against an eight core, 2 x 3.16 Ghz Xeon X5460 box at my department running Linux. Note that my processor now costs $200 (it's the venerable "Dodge Dart" of quad core chips), while the pair of Xeon processors cost $2400. The Haskell code is straightforward; it uses bit fields and reverse search, but it doesn't take advantage of symmetry, so it must "touch" every lattice to complete the enumeration. Its memory footprint is insignificant. Never mind 7 cores, Linux performs worse before it runs out of cores. Comparing 1, 2, 3, 4 cores on each machine, look at "real" and "user" time in minutes, and the ratio: Linux 2 x 3.16 GHz Xeon X5460 1 2 3 4 466.7 250.8 183.7 149.3 466.4 479.0 505.2 528.1 1.00 1.91 2.75 3.54 OS X 2.4 GHx Q6600 1 2 3 4 676.9 359.4 246.7 191.4 673.4 673.7 675.9 674.8 0.99 1.87 2.74 3.53 These ratios match up like physical constants, or at least invariants of my Haskell implementation. However, the user time is constant on OS X, so these ratios reflect the actual parallel speedup on OS X. The user time climbs steadily on Linux, significantly diluting the parallel speedup on Linux. Somehow, whatever is going wrong in the interaction between Haskell and Linux is being captured in this increase in user time. I love how my cheap little box comes close to pulling even with a departmental compute server I can't afford, because of this difference in operating systems. From bayer at cpw.math.columbia.edu Mon Apr 20 12:24:33 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Mon Apr 20 12:10:50 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <200904200059.36197.twhitehead@gmail.com> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <200904200059.36197.twhitehead@gmail.com> Message-ID: On Apr 19, 2009, at 9:59 PM, Tyson Whitehead wrote: > This leave me wondering how do the absolute numbers compare? Could > the extra > overhead due to the various 32bit issues be giving more room for > better > threading performance? What do you get if you use 32bit GHC with > Linux? Oddly enough, these are 32 bit GHC implementations in both cases. Our departmental sys admin has stayed with 32 bit Linux. cores, real, user, ratio > Linux > 2 x 3.16 GHz Xeon X5460 > 1 2 3 4 > 466.7 250.8 183.7 149.3 > 466.4 479.0 505.2 528.1 > 1.00 1.91 2.75 3.54 > > OS X > 2.4 GHx Q6600 > 1 2 3 4 > 676.9 359.4 246.7 191.4 > 673.4 673.7 675.9 674.8 > 0.99 1.87 2.74 3.53 From bayer at cpw.math.columbia.edu Mon Apr 20 12:30:39 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Mon Apr 20 12:16:52 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> Message-ID: <6FF082C9-262D-4CB0-AA65-2BA5FEED159E@math.columbia.edu> [Sorry if this turns out to be a dup, it appears that my first send got lost, while my followup message went through.] I ran some longer trials, and noticed a further pattern I wish I could explain: I'm comparing the enumeration of the roughly 69 billion atomic lattices on six atoms, on my four core, 2.4 GHz Q6600 box running OS X, against an eight core, 2 x 3.16 Ghz Xeon X5460 box at my department running Linux. Note that my processor now costs $200 (it's the venerable "Dodge Dart" of quad core chips), while the pair of Xeon processors cost $2400. The Haskell code is straightforward; it uses bit fields and reverse search, but it doesn't take advantage of symmetry, so it must "touch" every lattice to complete the enumeration. Its memory footprint is insignificant. Never mind 7 cores, Linux performs worse before it runs out of cores. Comparing 1, 2, 3, 4 cores on each machine, look at "real" and "user" time in minutes, and the ratio: Linux 2 x 3.16 GHz Xeon X5460 1 2 3 4 466.7 250.8 183.7 149.3 466.4 479.0 505.2 528.1 1.00 1.91 2.75 3.54 OS X 2.4 GHx Q6600 1 2 3 4 676.9 359.4 246.7 191.4 673.4 673.7 675.9 674.8 0.99 1.87 2.74 3.53 These ratios match up like physical constants, or at least invariants of my Haskell implementation. However, the user time is constant on OS X, so these ratios reflect the actual parallel speedup on OS X. The user time climbs steadily on Linux, significantly diluting the parallel speedup on Linux. Somehow, whatever is going wrong in the interaction between Haskell and Linux is being captured in this increase in user time. I love how my cheap little box comes close to pulling even with a departmental compute server I can't afford, because of this difference in operating systems. From marlowsd at gmail.com Tue Apr 21 04:28:09 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 21 04:14:20 2009 Subject: failure implementing :next command in ghci In-Reply-To: <49EC9D8A.2010502@gmail.com> References: <49EC7EAA.8030407@gmail.com> <49EC9D8A.2010502@gmail.com> Message-ID: 2009/4/20 Peter Hercek : > Simon Marlow wrote: >> >> Peter Hercek wrote: >>> >>> The proposed meaning for :next >>> >>> Lets mark dynamic stack size at a breakpoint (at which we issue :next) as >>> breakStackSize and its selected expression as breakSpan. Then :next would >>> single step till any of these is true: >>> 1) current dynamic stack size is smaller than breakStackSize >>> 2) current dynamic stack size is equal to breakStackSize and the current >>> selected expression is not a subset of breakSpan >> >> So what happens if the stack shrinks and then grows again between two >> breakpoints? ?Presumably :next wouldn't notice. > > Yes, if there is no breakpoint in between I would not notice. I did not > expect this can happen though. I thought that to add a frame on the stack > this must be done within an expression (which is going to be forced) and the > expression should be a breakpoint location. If it is so negligible that it > does not have a breakpoint location associated then even the things it is > calling should be negligible. > Where is an error in this? You can't assume that there are breakpoints everywhere. Compiled code doesn't have breakpoints, for example. Even in interpreted code, there is compiler-generated code that doesn't have breakpoints in it, and after transformations breakpoints may have moved around. >> I think you'd be better off implementing this with a special stack frame, >> so that you can guarantee to notice when the current "context" has been >> exited. > > This would be robust but I do not have knowledge to do it yet. If I > understand you correctly this means that before executing a BCO which we are > going to break at, we must prepare for a possible :next. So regardless > whether :next is going to be issued by the user or not we would add a frame > which represents a return to a function which: > a) if user issued :next it enables all breakpoints so that we stop at the > next breakpoint > b) if user did not issue a break it would not do anything (just return) Yes, exactly. Although we have to worry about stack growth: we don't want the addition of a new stack frame to change constant stack-usage into linear stack-usage, so perhaps we would have to avoid pushing these frames directly on top of each other. > We could decide not to insert the frame when we are only tracing. But if I > would want to track a simulated dynamic stack I would need to insert this > stack frame at the start of each breakpoint (when dynamic stack tracing > would be on). Does not sound that good. > >>> I hope the above would make good sense but I do not really know since >>> maybe rts does some funny things with stack sometimes. If you think the >>> proposed behavior is garbage let me know why so that I do not waste more >>> time with this :) >> >> Yes the RTS does do "funny thing" with the stack sometimes. ?The stack can >> shrink as a result of adjacent update frames being coalesced ("stack >> squeezing"). > > OK, so it looks like either switching off the squeezing (if shrinking and > growing stack between breakpoints/ticks is not such an issue), or inserting > a stack frame. > Does the "stack squeezing" happen during garbage collection? It can happen any time, so yes. Cheers, Simon From marlowsd at gmail.com Tue Apr 21 04:39:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 21 04:25:51 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> Message-ID: 2009/4/20 Dave Bayer : > I ran some longer trials, and noticed a further pattern I wish I could > explain: > > I'm comparing the enumeration of the roughly 69 billion atomic lattices on > six atoms, on my four core, 2.4 GHz Q6600 box running OS X, against an eight > core, 2 x 3.16 Ghz Xeon X5460 box at my department running Linux. Note that > my processor now costs $200 (it's the venerable "Dodge Dart" of quad core > chips), while the pair of Xeon processors cost $2400. The Haskell code is > straightforward; it uses bit fields and reverse search, but it doesn't take > advantage of symmetry, so it must "touch" every lattice to complete the > enumeration. Its memory footprint is insignificant. > > Never mind 7 cores, Linux performs worse before it runs out of cores. > Comparing 1, 2, 3, 4 cores on each machine, look at "real" and "user" time > in minutes, and the ratio: > > Linux > 2 x 3.16 GHz Xeon X5460 > 1 ? ? ? 2 ? ? ? 3 ? ? ? 4 > 466.7 ? 250.8 ? 183.7 ? 149.3 > 466.4 ? 479.0 ? 505.2 ? 528.1 > 1.00 ? ?1.91 ? ?2.75 ? ?3.54 > > OS X > 2.4 GHx Q6600 > 1 ? ? ? 2 ? ? ? 3 ? ? ? 4 > 676.9 ? 359.4 ? 246.7 ? 191.4 > 673.4 ? 673.7 ? 675.9 ? 674.8 > 0.99 ? ?1.87 ? ?2.74 ? ?3.53 > > These ratios match up like physical constants, or at least invariants of my > Haskell implementation. However, the user time is constant on OS X, so these > ratios reflect the actual parallel speedup on OS X. The user time climbs > steadily on Linux, significantly diluting the parallel speedup on Linux. > Somehow, whatever is going wrong in the interaction between Haskell and > Linux is being captured in this increase in user time. We can't necessarily blame this on Linux: the two machines have different hardware. There could be cache-effects at play, for example. Maybe you could try the new affinity options (+RTS -qa) and see if that makes any difference? That would reduce the effect of scheduling effects due to the OS (although when the number of cores you use is less than the real number of cores in the machine, the OS is still free to move threads around. To get reliable numbers you should really disable some of the cores at boot-time). Cheers, Simon From ndmitchell at gmail.com Tue Apr 21 04:55:47 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 21 04:41:57 2009 Subject: Parallel performance drops off a cliff In-Reply-To: References: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> Message-ID: <404396ef0904210155r1dbe7eb0rd6c788f9d69b1049@mail.gmail.com> Hi >> This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known >> bug, or should I try and replicate it? (benchmark is fairly big and >> very dependent on internal things, but I suspect the dramatic >> performance slowdown is unlikely to be related to these bits). > > Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus > heuristics about when to turn on the parallel GC, and it just so > happens that 8 processors tips it over the point where the parallel GC > is enabled for young-generation collections. ?In 6.10.2 the parallel > GC really didn't help most of the time, but it has undergone a lot of > tuning since then, and in the HEAD things are much better (see the > results from our ICFP submission). Fantastic! I'll disable parallel garbage collection (I'm fairly certain it won't have any effect for this application). Thanks Neil From dons at galois.com Tue Apr 21 04:55:25 2009 From: dons at galois.com (Don Stewart) Date: Tue Apr 21 04:42:45 2009 Subject: Parallel performance drops off a cliff In-Reply-To: <404396ef0904210155r1dbe7eb0rd6c788f9d69b1049@mail.gmail.com> References: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> <404396ef0904210155r1dbe7eb0rd6c788f9d69b1049@mail.gmail.com> Message-ID: <20090421085525.GI5381@whirlpool.galois.com> ndmitchell: > Hi > > >> This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known > >> bug, or should I try and replicate it? (benchmark is fairly big and > >> very dependent on internal things, but I suspect the dramatic > >> performance slowdown is unlikely to be related to these bits). > > > > Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus > > heuristics about when to turn on the parallel GC, and it just so > > happens that 8 processors tips it over the point where the parallel GC > > is enabled for young-generation collections. ?In 6.10.2 the parallel > > GC really didn't help most of the time, but it has undergone a lot of > > tuning since then, and in the HEAD things are much better (see the > > results from our ICFP submission). > > Fantastic! I'll disable parallel garbage collection (I'm fairly > certain it won't have any effect for this application). How many cores are you planning to use? ... -- Don From ndmitchell at gmail.com Tue Apr 21 04:58:12 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 21 04:44:22 2009 Subject: Parallel performance drops off a cliff In-Reply-To: <20090421085525.GI5381@whirlpool.galois.com> References: <404396ef0904200554u1d922ea0yae03b3080dedc472@mail.gmail.com> <404396ef0904210155r1dbe7eb0rd6c788f9d69b1049@mail.gmail.com> <20090421085525.GI5381@whirlpool.galois.com> Message-ID: <404396ef0904210158t7c47758aj7d1393835e294ed2@mail.gmail.com> >> > Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus >> > heuristics about when to turn on the parallel GC, and it just so >> > happens that 8 processors tips it over the point where the parallel GC >> > is enabled for young-generation collections. ?In 6.10.2 the parallel >> > GC really didn't help most of the time, but it has undergone a lot of >> > tuning since then, and in the HEAD things are much better (see the >> > results from our ICFP submission). >> >> Fantastic! I'll disable parallel garbage collection (I'm fairly >> certain it won't have any effect for this application). > > How many cores are you planning to use? ... 16 on the best machine we've got. This particular application is a bit weird, I suspect it will be spending very little time actually executing Haskell and most of the time waiting for shell commands. As such, the efficiency of Haskell isn't a problem - parallel garbage collection shouldn't make any difference. Thanks Neil From dons at galois.com Tue Apr 21 04:57:39 2009 From: dons at galois.com (Don Stewart) Date: Tue Apr 21 04:45:06 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> Message-ID: <20090421085739.GJ5381@whirlpool.galois.com> marlowsd: > 2009/4/20 Dave Bayer : > > I ran some longer trials, and noticed a further pattern I wish I could > > explain: > > > > I'm comparing the enumeration of the roughly 69 billion atomic lattices on > > six atoms, on my four core, 2.4 GHz Q6600 box running OS X, against an eight > > core, 2 x 3.16 Ghz Xeon X5460 box at my department running Linux. Note that > > my processor now costs $200 (it's the venerable "Dodge Dart" of quad core > > chips), while the pair of Xeon processors cost $2400. The Haskell code is > > straightforward; it uses bit fields and reverse search, but it doesn't take > > advantage of symmetry, so it must "touch" every lattice to complete the > > enumeration. Its memory footprint is insignificant. > > > > Never mind 7 cores, Linux performs worse before it runs out of cores. > > Comparing 1, 2, 3, 4 cores on each machine, look at "real" and "user" time > > in minutes, and the ratio: > > > > Linux > > 2 x 3.16 GHz Xeon X5460 > > 1 ? ? ? 2 ? ? ? 3 ? ? ? 4 > > 466.7 ? 250.8 ? 183.7 ? 149.3 > > 466.4 ? 479.0 ? 505.2 ? 528.1 > > 1.00 ? ?1.91 ? ?2.75 ? ?3.54 > > > > OS X > > 2.4 GHx Q6600 > > 1 ? ? ? 2 ? ? ? 3 ? ? ? 4 > > 676.9 ? 359.4 ? 246.7 ? 191.4 > > 673.4 ? 673.7 ? 675.9 ? 674.8 > > 0.99 ? ?1.87 ? ?2.74 ? ?3.53 > > > > These ratios match up like physical constants, or at least invariants of my > > Haskell implementation. However, the user time is constant on OS X, so these > > ratios reflect the actual parallel speedup on OS X. The user time climbs > > steadily on Linux, significantly diluting the parallel speedup on Linux. > > Somehow, whatever is going wrong in the interaction between Haskell and > > Linux is being captured in this increase in user time. > > We can't necessarily blame this on Linux: the two machines have > different hardware. There could be cache-effects at play, for > example. > > Maybe you could try the new affinity options (+RTS -qa) and see if > that makes any difference? That would reduce the effect of scheduling > effects due to the OS (although when the number of cores you use is > less than the real number of cores in the machine, the OS is still > free to move threads around. To get reliable numbers you should > really disable some of the cores at boot-time). > Little advice and tidbits are creeping out of Simon's head. Is it time for a parallel performance wiki, where every question that becomes an FAQ gets documented live? http://haskell.org/haskellwiki/Performance/Parallel Maybe put details on the wiki so we can grow a large FAQ to capture this "oral tradition". -- Don From marlowsd at gmail.com Tue Apr 21 05:15:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 21 05:01:15 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <20090421085739.GJ5381@whirlpool.galois.com> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> <20090421085739.GJ5381@whirlpool.galois.com> Message-ID: 2009/4/21 Don Stewart : > Little advice and tidbits are creeping out of Simon's head. > > Is it time for a parallel performance wiki, where every question that > becomes an FAQ gets documented live? > > ? ?http://haskell.org/haskellwiki/Performance/Parallel > > Maybe put details on the wiki so we can grow a large FAQ to capture this > "oral tradition". Absolutely. One reservation I have is that advice is likely to go out of date quite quickly; for example I'm planning to change the RTS options again before we release 6.12.1 to improve the default behaviour. Another reservation I have is that it's very difficult to pin down techniques that work consistently over different OSs and hardware. The best we can do is to document the techniques we know about, and advise people to try a variety of things to see which works best. Even that would be better than nothing, of course. Does anyone feel able to make a start setting up a wiki tree for parallel performance? I'd be more than happy to contribute and review content. Cheers, Simon From mechvel at botik.ru Tue Apr 21 08:23:12 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Apr 21 08:10:30 2009 Subject: my last letter Message-ID: <20090421122311.GA14887@scico.botik.ru> Dear GHC team, I withdraw my last bug report. It was about processing a long list on a 64 bit machine ?n GHC-6.10.2. First, I cannot reproduce (?) this bug report invitation from GHC on using +RTS -M4000m Second, I have found that the process interruption only occurs when this test program runs out of RAM. And personally, I would rather use "+RTS -M15000m -RTS" and not to consider at all the system effects after the RAM overflow. Third, I apply now a more clear example, whith [Int] instead of [Integer]: --------------------------------------------------------- import List (genericReplicate) main = putStr (shows res "\n") where e = -- 22, 23 ... list = genericReplicate (2^e) 1 :: [Int] rList = reverse list res = myMin $ zipWith (+) list rList myMin [] = error "\nmyMin []\n" myMin [x] = x myMin (x: y: xs) = if x > y then myMin (y: xs) else myMin (x: xs) ------------------------------------------------------ ghc -O --make Test64 ./Test64 +RTS -M800m -RTS -- for 1 Gb 32 bit machine ./Test64 +RTS -M12000m -RTS -- for 16 Gb 64 bit machine The last possible e for the small machine (800 Mb) occurs 24, for the big machine (12000 Mb) occurs 27 -- which looks reasonable. The timing also looks reasonable. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From twhitehead at gmail.com Tue Apr 21 10:14:37 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue Apr 21 10:00:55 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> Message-ID: <200904211014.43588.twhitehead@gmail.com> On April 21, 2009 04:39:40 Simon Marlow wrote: > > These ratios match up like physical constants, or at least invariants of > > my Haskell implementation. However, the user time is constant on OS X, so > > these ratios reflect the actual parallel speedup on OS X. The user time > > climbs steadily on Linux, significantly diluting the parallel speedup on > > Linux. Somehow, whatever is going wrong in the interaction between > > Haskell and Linux is being captured in this increase in user time. > > We can't necessarily blame this on Linux: the two machines have > different hardware. There could be cache-effects at play, for > example. Why not try booting a CD or thumb-drive linux distro (e.g., ubuntu live) on your 2.4 GHz Q6600 OS X box and see how things stack up. It would certainly eliminate any questions of hardware differences. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090421/a55ee014/attachment.bin From gkmo at cin.ufpe.br Tue Apr 21 21:56:14 2009 From: gkmo at cin.ufpe.br (Guilherme Oliveira) Date: Tue Apr 21 21:42:20 2009 Subject: Using FFI for .NET Message-ID: <43a2d37b0904211856h78179370h92e3d05bb3a2d05b@mail.gmail.com> Hi guys, I'm new to haskell and I'm trying to make some calls to static methods of the Microsoft .NET framework with GHC 6.10.2 but I'm getting the follwoing error: GHC error in desugarer lookup in main:Main: > Failed to load interface for `GHC.Dotnet': > There are files missing in the `base' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-unknown-mingw32): > initDs IOEnv failure > My haskell code is this: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Prelude import Foreign foreign import dotnet "static foo" foo :: Int -> Int main = do print (foo 5) To build the code above I'm doing like this: ghc -fvia-C Main.hs Am I forgeting something? Does this version of GHC supports FFI for .NET? Regards, Guilherme Oliveira MSc Student, UFPE - Brazil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090421/9eb15667/attachment.htm From sof at galois.com Tue Apr 21 22:49:11 2009 From: sof at galois.com (Sigbjorn Finne) Date: Tue Apr 21 22:35:33 2009 Subject: Using FFI for .NET In-Reply-To: <43a2d37b0904211856h78179370h92e3d05bb3a2d05b@mail.gmail.com> References: <43a2d37b0904211856h78179370h92e3d05bb3a2d05b@mail.gmail.com> Message-ID: <49EE85A7.3040206@galois.com> Hi Guilherme, the support for 'dotnet' FFI declarations isn't really there any longer, having bitrotted badly and hasn't been in use for a number of years. (I'd suggest removing the final vestiges of them from the codebase, actually.) You may want to have a look at http://haskell.forkIO.com/dotnet/ instead. --sigbjorn On 4/21/2009 18:56, Guilherme Oliveira wrote: > Hi guys, > > I'm new to haskell and I'm trying to make some calls to static methods > of the Microsoft .NET framework with GHC 6.10.2 but I'm getting the > follwoing error: > > GHC error in desugarer lookup in main:Main: > Failed to load interface for `GHC.Dotnet': > There are files missing in the `base' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-unknown-mingw32): > initDs IOEnv failure > > > My haskell code is this: > > {-# LANGUAGE ForeignFunctionInterface #-} > > module Main where > > import Prelude > import Foreign > > foreign import dotnet "static foo" foo :: Int -> Int > > main = do print (foo 5) > > To build the code above I'm doing like this: ghc -fvia-C Main.hs > > Am I forgeting something? Does this version of GHC supports FFI for .NET? > > Regards, > Guilherme Oliveira > MSc Student, UFPE - Brazil > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bayer at cpw.math.columbia.edu Wed Apr 22 07:40:44 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Wed Apr 22 07:26:50 2009 Subject: No "last core parallel slowdown" on OS X In-Reply-To: <200904211014.43588.twhitehead@gmail.com> References: <3171A9A7-EB01-4CEA-97F3-9D187A285D57@math.columbia.edu> <5DCB9B85-4985-4642-B5BF-DBD884BBAA5B@math.columbia.edu> <200904211014.43588.twhitehead@gmail.com> Message-ID: <655DD6CD-2599-48BC-92E3-CCD02E930FB1@math.columbia.edu> My first post was comparing almost identical machines: Different Q6600 steppings (the earlier chip makes a good space heater!) on different motherboards, same memory, both stock speeds. In a few weeks when the semester ends, I'll be able to try Linux -vs- BSD -vs- OS X on identical hardware, and try Simon's settings. (I do love overclocking, but five minutes improving Haskell code is generally more effective than a day tweaking motherboard voltages. We're too "green" to use A/C in the hot California summer, and this computer exhausts through a dryer hose out my office window as it is. I don't want it any hotter, I just want more cores!) I do have some experience comparing this code on four different Linux boxes, and three different Macs, and Linux does consistently worse. I waited to post until I could compare 4 cores against 4 cores on nearly identical hardware. Also, I tried many approaches to this code, and what I've been testing is my best version, which also happens to be one of the simplest approaches to parallelism. (It so often works that way with Haskell.) In fairness, I should also run the standard test suite used in the paper. On Apr 21, 2009, at 10:14 AM, Tyson Whitehead wrote: > Why not try booting a CD or thumb-drive linux distro (e.g., ubuntu > live) on > your 2.4 GHz Q6600 OS X box and see how things stack up. It would > certainly > eliminate any questions of hardware differences. > > Cheers! -Tyson I can do even better: This $65 bay device takes four 2.5" SATA or SAS drives: http://addonics.com/products/raid_system/ae4rcs25nsa.asp It has a surprising build quality, makes it trivial to juggle 2.5" SATA drives. Removing the high-low jumper disables the loud fan, which is probably only needed for SAS drives. My primary drive is an OCZ Vertex SSD, for which this is perfect. I also have an assortment of spare laptop drives I can use, so an OS survey will be easy. From ndmitchell at gmail.com Wed Apr 22 08:22:01 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 22 08:08:07 2009 Subject: writeFile/readFile on multiple threads leads to error Message-ID: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Hi, I've got a multi-threaded application which occasionally generates failures in openFile. I haven't been able to reproduce the errors reliably, the code is way too large to send over, and any small attempts at invoking the same problem don't seem to work. Despite the uselessness of the bug report, I thought I'd share what I've seen and how I fixed it. I have many threads, which read and write files. Every so often one thread will write a file, then another thread will read the same file - but fail during the open call. There are locks to ensure that the write call finishes before the read call begins. I modified the code to give: do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) ; return res do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) I then get on the console: WRITE START foo WRITE STOP foo READ START foo openFile doesn't have permission to open foo. The writeFile/readFile are happening in different threads, and they usually succeed - but not always. The bug seems to go away when I add performGC just after writeFile. My guess is that something in the openFile/hClose pair isn't really closed until a garbage collection happens. All this is using GHC 6.10.2 on XP through Cygwin. I'm happy to supply more details if you can think of anything that will help, Thanks Neil From jason.dusek at gmail.com Wed Apr 22 08:35:49 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Apr 22 08:21:57 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: <42784f260904220535m3ab85c49if0f39f9dfe19e21b@mail.gmail.com> Is it too difficult to try this on Linux or Mac, just to see if it shows up there as well? -- Jason Dusek From ndmitchell at gmail.com Wed Apr 22 08:41:13 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 22 08:27:19 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <42784f260904220535m3ab85c49if0f39f9dfe19e21b@mail.gmail.com> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> <42784f260904220535m3ab85c49if0f39f9dfe19e21b@mail.gmail.com> Message-ID: <404396ef0904220541y5d1e335bved7a99744977b4b7@mail.gmail.com> > ?Is it too difficult to try this on Linux or Mac, just to see > ?if it shows up there as well? Yes ;-) I might be able to try it on Linux next week, but that's as far as I'm likely to be able to go. If I get any results I'll email them in. Thanks Neil From bulat.ziganshin at gmail.com Wed Apr 22 08:44:43 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 22 08:31:42 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: <398196773.20090422164443@gmail.com> Hello Neil, Wednesday, April 22, 2009, 4:22:01 PM, you wrote: you can try to use POSIX open/read/write/close calls > Hi, > I've got a multi-threaded application which occasionally generates > failures in openFile. I haven't been able to reproduce the errors > reliably, the code is way too large to send over, and any small > attempts at invoking the same problem don't seem to work. Despite the > uselessness of the bug report, I thought I'd share what I've seen and > how I fixed it. > I have many threads, which read and write files. Every so often one > thread will write a file, then another thread will read the same file > - but fail during the open call. There are locks to ensure that the > write call finishes before the read call begins. I modified the code > to give: > do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) > ; return res > do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) > I then get on the console: > WRITE START foo > WRITE STOP foo > READ START foo > openFile doesn't have permission to open foo. > The writeFile/readFile are happening in different threads, and they > usually succeed - but not always. The bug seems to go away when I add > performGC just after writeFile. My guess is that something in the > openFile/hClose pair isn't really closed until a garbage collection > happens. All this is using GHC 6.10.2 on XP through Cygwin. > I'm happy to supply more details if you can think of anything that will help, > Thanks > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Wed Apr 22 08:56:40 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Apr 22 08:42:51 2009 Subject: writeFile/readFile on multiple threads leads to error References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: > do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) > ; return res Unless you've defined your own version of 'readFile', to mean read entire file now, the first 'print' is optimistic and the second 'print' is a lie. Claus > do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) > > I then get on the console: > > WRITE START foo > WRITE STOP foo > READ START foo > openFile doesn't have permission to open foo. > > The writeFile/readFile are happening in different threads, and they > usually succeed - but not always. The bug seems to go away when I add > performGC just after writeFile. My guess is that something in the > openFile/hClose pair isn't really closed until a garbage collection > happens. All this is using GHC 6.10.2 on XP through Cygwin. > > I'm happy to supply more details if you can think of anything that will help, > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ndmitchell at gmail.com Wed Apr 22 08:59:29 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 22 08:45:34 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: <404396ef0904220559l3c736344idab3c652fe8abec5@mail.gmail.com> Hi Claus, >> do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) >> ; return res > > Unless you've defined your own version of 'readFile', to mean read > entire file now, the first 'print' is optimistic and the second 'print' is a > lie. readFile calls openFile >>= hGetContents. It's the openFile that causes the problem, so READ START happens before openFile and READ STOP happens after openFile. The lazy semantics of the actual reading don't seem to have an effect. I did try changing to the strict bytestring file read, and that gave exactly the same error - apart from openBinaryFile was crashing rather than openFile. Thanks Neil >> do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) >> >> I then get on the console: >> >> WRITE START foo >> WRITE STOP foo >> READ START foo >> openFile doesn't have permission to open foo. >> >> The writeFile/readFile are happening in different threads, and they >> usually succeed - but not always. The bug seems to go away when I add >> performGC just after writeFile. My guess is that something in the >> openFile/hClose pair isn't really closed until a garbage collection >> happens. All this is using GHC 6.10.2 on XP through Cygwin. >> >> I'm happy to supply more details if you can think of anything that will >> help, >> >> Thanks >> >> Neil >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From claus.reinke at talk21.com Wed Apr 22 09:27:07 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Apr 22 09:13:19 2009 Subject: writeFile/readFile on multiple threads leads to error References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> <404396ef0904220559l3c736344idab3c652fe8abec5@mail.gmail.com> Message-ID: <1ACE0E56EC834A49918D7D410D3D4B08@cr3lt> >>> do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) >>> ; return res >> >> Unless you've defined your own version of 'readFile', to mean read >> entire file now, the first 'print' is optimistic and the second 'print' is a >> lie. > > readFile calls openFile >>= hGetContents. It's the openFile that > causes the problem, so READ START happens before openFile and READ > STOP happens after openFile. The lazy semantics of the actual reading > don't seem to have an effect. Just want to make sure that it isn't the latent hClose from readFile. Once upon a time, I spend a lot of time figuring out why nhc98 wouldn't work on windows, until I noticed that its code used to rely on unixy file system tricks like readFile followed by removeFile, followed by looking at the contents. main = do writeFile "data" "file contents" r <- readFile "data" writeFile "data" "different contents" print r *Main> main *** Exception: data: openFile: permission denied (Permission denied) > I did try changing to the strict bytestring file read, and that gave > exactly the same error - apart from openBinaryFile was crashing rather > than openFile. Weren't there versions of bytestring that didn't close the file early enough? Just checking, Claus > Thanks > > Neil > >>> do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) >>> >>> I then get on the console: >>> >>> WRITE START foo >>> WRITE STOP foo >>> READ START foo >>> openFile doesn't have permission to open foo. >>> >>> The writeFile/readFile are happening in different threads, and they >>> usually succeed - but not always. The bug seems to go away when I add >>> performGC just after writeFile. My guess is that something in the >>> openFile/hClose pair isn't really closed until a garbage collection >>> happens. All this is using GHC 6.10.2 on XP through Cygwin. >>> >>> I'm happy to supply more details if you can think of anything that will >>> help, >>> >>> Thanks >>> >>> Neil >>> _______________________________________________ >>> 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 ndmitchell at gmail.com Wed Apr 22 09:32:01 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 22 09:18:07 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <1ACE0E56EC834A49918D7D410D3D4B08@cr3lt> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> <404396ef0904220559l3c736344idab3c652fe8abec5@mail.gmail.com> <1ACE0E56EC834A49918D7D410D3D4B08@cr3lt> Message-ID: <404396ef0904220632p338ec655v2858ad3e3e64abd4@mail.gmail.com> Bulat: I haven't tried moving to Posix calls, I'll try that next - although I was hoping the application wouldn't be posix dependent. >> readFile calls openFile >>= hGetContents. It's the openFile that >> causes the problem, so READ START happens before openFile and READ >> STOP happens after openFile. The lazy semantics of the actual reading >> don't seem to have an effect. > > Just want to make sure that it isn't the latent hClose from readFile. Yeah, I've done that before! It seems to be the writeFile that isn't closing, not the readFile - hence my surprise. >> I did try changing to the strict bytestring file read, and that gave >> exactly the same error - apart from openBinaryFile was crashing rather >> than openFile. > > Weren't there versions of bytestring that didn't close the file early > enough? I only used bytestring for reading, so it shouldn't have made any difference. Thanks Neil From marlowsd at gmail.com Wed Apr 22 10:51:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 22 10:37:38 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: 2009/4/22 Neil Mitchell : > I've got a multi-threaded application which occasionally generates > failures in openFile. I haven't been able to reproduce the errors > reliably, the code is way too large to send over, and any small > attempts at invoking the same problem don't seem to work. Despite the > uselessness of the bug report, I thought I'd share what I've seen and > how I fixed it. > > I have many threads, which read and write files. Every so often one > thread will write a file, then another thread will read the same file > - but fail during the open call. There are locks to ensure that the > write call finishes before the read call begins. I modified the code > to give: > > do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) > ; return res > > do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x) > > I then get on the console: > > WRITE START foo > WRITE STOP foo > READ START foo > openFile doesn't have permission to open foo. > > The writeFile/readFile are happening in different threads, and they > usually succeed - but not always. The bug seems to go away when I add > performGC just after writeFile. My guess is that something in the > openFile/hClose pair isn't really closed until a garbage collection > happens. All this is using GHC 6.10.2 on XP through Cygwin. The hClose really does close the file descriptor. The only thing left is the finalizer, but it is just a no-op on an already-closed Handle. I can't think of anything we're doing that could possibly cause this, but I have seen rogue "permission denied" errors on Windows from time to time, they're quite annoying. Here's a possibly-related ticket: http://hackage.haskell.org/trac/ghc/ticket/2924 You might want to run the process under ProcMon and see if you can figure out what's going on (if you can bear to use ProcMon, it's a very poor replacement for strace IMO). Cheers, Simon From ndmitchell at gmail.com Wed Apr 22 11:44:25 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 22 11:30:34 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: <404396ef0904220844pf4823b9g4253c00b41caea5b@mail.gmail.com> >> I have many threads, which read and write files. Every so often one >> thread will write a file, then another thread will read the same file >> - but fail during the open call. There are locks to ensure that the >> write call finishes before the read call begins. I modified the code >> to give: >> >> The writeFile/readFile are happening in different threads, and they >> usually succeed - but not always. The bug seems to go away when I add >> performGC just after writeFile. My guess is that something in the >> openFile/hClose pair isn't really closed until a garbage collection >> happens. All this is using GHC 6.10.2 on XP through Cygwin. > > The hClose really does close the file descriptor. ?The only thing left > is the finalizer, but it is just a no-op on an already-closed Handle. > > I can't think of anything we're doing that could possibly cause this, > but I have seen rogue "permission denied" errors on Windows from time > to time, they're quite annoying. ?Here's a possibly-related ticket: > > http://hackage.haskell.org/trac/ghc/ticket/2924 I've added information from this thread to that ticket. It looks suspiciously similar, and I have a feeling that some combination of writeFile/readFile in a similar pattern might invoke the same issue - it's certainly quite close to the behaviour of my application. > You might want to run the process under ProcMon and see if you can > figure out what's going on (if you can bear to use ProcMon, it's a > very poor replacement for strace IMO). I tried and the bug goes away, plus the computer grinds to a crunching halt. The bug is very sensitive, and with the speed loss associated with ProcMon probably disappears on its own. No useful information can be obtained there. Thanks Neil From fmartini at gmail.com Wed Apr 22 17:50:38 2009 From: fmartini at gmail.com (Felix Martini) Date: Wed Apr 22 17:36:45 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> Message-ID: <6c0416190904221450u69b67ebbkabdc1bae4273d7db@mail.gmail.com> 2009/4/22 Simon Marlow: > You might want to run the process under ProcMon and see if you can > figure out what's going on (if you can bear to use ProcMon, it's a > very poor replacement for strace IMO). You could try StraceNT instead (not as good as strace though). From igloo at earth.li Wed Apr 22 19:56:46 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 22 19:42:51 2009 Subject: 6.10.3 plans Message-ID: <20090422235646.GA29183@matrix.chaos.earth.li> Hi all, Due to some problems with the handling of ^C in ghci, we are planning to do a 6.10.3 release. The idea is that, rather than being a full-blown release process, including all the various fixes that have been made since 6.10.2, we will only do what is necessary to resolve the ^C issue. By keeping the changes to a minimum, we will minimise the amount of testing, release-note writing, etc that is necessary. An exception to this rule is that we will probably also rebundle time in the bindists, as that has little chance of breaking anything else. There are actually two problems with ^C. One is due to the changes in the signal handling in ghci, and we will fix that. The other is that, on some platforms (including x86/Linux), the interaction between editline and GHC means that pressing ^C causes a segfault. Given all the other issues that people have had with editline, we plan to use haskeline in 6.10.3 instead. We already planned to do this for 6.12, but we think that it makes sense to do it sooner rather than later. The plan is: * Add haskeline and deps as boot packages * Move the interactive modules from the ghc package to the ghc-bin package. This means that the ghc package will not depend on the new boot packages, so there will not be any problems with upgrading them. Any comments? Thanks Ian From sof at galois.com Wed Apr 22 21:55:33 2009 From: sof at galois.com (Sigbjorn Finne) Date: Wed Apr 22 21:41:40 2009 Subject: 6.10.3 plans In-Reply-To: <20090422235646.GA29183@matrix.chaos.earth.li> References: <20090422235646.GA29183@matrix.chaos.earth.li> Message-ID: <49EFCA95.8000709@galois.com> Hi Ian, thanks for the update on plans and the willingness to jump in and do another release cycle so soon after 6.10.2. The suggested fixes seem agreeable to me, but I have one _minor_ additional request for 6.10.3 if you end having to rebuild 'base' -- add a DEPRECATED (or some such) to Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate that the operational behaviour of these have changed. Small change, but could be helpful to package users&authors when migrating beyond 6.10.1 thanks --sigbjorn On 4/22/2009 16:56, Ian Lynagh wrote: > Hi all, > > Due to some problems with the handling of ^C in ghci, we are planning to > do a 6.10.3 release. > > The idea is that, rather than being a full-blown release process, > including all the various fixes that have been made since 6.10.2, we > will only do what is necessary to resolve the ^C issue. By keeping the > changes to a minimum, we will minimise the amount of testing, > release-note writing, etc that is necessary. > > An exception to this rule is that we will probably also rebundle time in > the bindists, as that has little chance of breaking anything else. > > > > There are actually two problems with ^C. One is due to the changes in > the signal handling in ghci, and we will fix that. The other is that, on > some platforms (including x86/Linux), the interaction between editline > and GHC means that pressing ^C causes a segfault. Given all the other > issues that people have had with editline, we plan to use haskeline in > 6.10.3 instead. We already planned to do this for 6.12, but we think > that it makes sense to do it sooner rather than later. The plan is: > > * Add haskeline and deps as boot packages > > * Move the interactive modules from the ghc package to the ghc-bin > package. This means that the ghc package will not depend on the new > boot packages, so there will not be any problems with upgrading them. > > > Any comments? > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From alexander.dunlap at gmail.com Wed Apr 22 22:00:37 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Wed Apr 22 21:46:41 2009 Subject: 6.10.3 plans In-Reply-To: <20090422235646.GA29183@matrix.chaos.earth.li> References: <20090422235646.GA29183@matrix.chaos.earth.li> Message-ID: <57526e770904221900h7910eabbxe75f9dacb058a76f@mail.gmail.com> On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh wrote: > > Hi all, > > Due to some problems with the handling of ^C in ghci, we are planning to > do a 6.10.3 release. > > The idea is that, rather than being a full-blown release process, > including all the various fixes that have been made since 6.10.2, we > will only do what is necessary to resolve the ^C issue. By keeping the > changes to a minimum, we will minimise the amount of testing, > release-note writing, etc that is necessary. > > An exception to this rule is that we will probably also rebundle time in > the bindists, as that has little chance of breaking anything else. > > > > There are actually two problems with ^C. One is due to the changes in > the signal handling in ghci, and we will fix that. The other is that, on > some platforms (including x86/Linux), the interaction between editline > and GHC means that pressing ^C causes a segfault. Given all the other > issues that people have had with editline, we plan to use haskeline in > 6.10.3 instead. We already planned to do this for 6.12, but we think > that it makes sense to do it sooner rather than later. The plan is: > > * Add haskeline and deps as boot packages > > * Move the interactive modules from the ghc package to the ghc-bin > ?package. This means that the ghc package will not depend on the new > ?boot packages, so there will not be any problems with upgrading them. > > > Any comments? > > > Thanks > Ian > Would this be a good time to add the "time" package too, or has that issue been resolved? Alex From allbery at ece.cmu.edu Wed Apr 22 22:02:58 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 22 21:49:17 2009 Subject: 6.10.3 plans In-Reply-To: <57526e770904221900h7910eabbxe75f9dacb058a76f@mail.gmail.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <57526e770904221900h7910eabbxe75f9dacb058a76f@mail.gmail.com> Message-ID: <3C51CB0D-FF34-4E90-A666-6A153C4EAA08@ece.cmu.edu> On Apr 22, 2009, at 22:00 , Alexander Dunlap wrote: > On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh wrote: >> An exception to this rule is that we will probably also rebundle >> time in >> the bindists, as that has little chance of breaking anything else. > > Would this be a good time to add the "time" package too, or has that > issue been resolved? ... -- 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/20090422/c4661a3f/PGP.bin From Alistair.Bayley at invesco.com Thu Apr 23 03:45:02 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Thu Apr 23 03:31:28 2009 Subject: 6.10.3 plans In-Reply-To: <57526e770904221900h7910eabbxe75f9dacb058a76f@mail.gmail.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <57526e770904221900h7910eabbxe75f9dacb058a76f@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911025F96@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Alexander Dunlap > > > > An exception to this rule is that we will probably also > rebundle time in > > the bindists, as that has little chance of breaking anything else. > > Would this be a good time to add the "time" package too, or has that > issue been resolved? I think Ian said time will be rebundled (see excerpt above). Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From duncan.coutts at worc.ox.ac.uk Thu Apr 23 05:05:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 23 04:51:45 2009 Subject: 6.10.3 plans In-Reply-To: <49EFCA95.8000709@galois.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> Message-ID: <1240477519.5557.143.camel@localhost> On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote: > Hi Ian, > > thanks for the update on plans and the willingness to jump in and do another > release cycle so soon after 6.10.2. The suggested fixes seem agreeable to > me, but I have one _minor_ additional request for 6.10.3 if you end having > to rebuild 'base' -- add a DEPRECATED (or some such) to > Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate > that the operational behaviour of these have changed. > > Small change, but could be helpful to package users&authors when migrating > beyond 6.10.1 I agree that it's a little unfortunate that this change is in a minor release. I'm not sure what can be done as far as automatic messages go however. The notice about the change is in the release notes. The functions are not deprecated (they're part of the FFI spec). Duncan From sof at galois.com Thu Apr 23 08:59:31 2009 From: sof at galois.com (Sigbjorn Finne) Date: Thu Apr 23 08:45:45 2009 Subject: 6.10.3 plans In-Reply-To: <1240477519.5557.143.camel@localhost> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> Message-ID: <49F06633.8050908@galois.com> On 4/23/2009 02:05, Duncan Coutts wrote: > On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote: > >> Hi Ian, >> >> thanks for the update on plans and the willingness to jump in and do another >> release cycle so soon after 6.10.2. The suggested fixes seem agreeable to >> me, but I have one _minor_ additional request for 6.10.3 if you end having >> to rebuild 'base' -- add a DEPRECATED (or some such) to >> Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate >> that the operational behaviour of these have changed. >> >> Small change, but could be helpful to package users&authors when migrating >> beyond 6.10.1 >> > > I agree that it's a little unfortunate that this change is in a minor > release. > > I'm not sure what can be done as far as automatic messages go however. > The notice about the change is in the release notes. The functions are > not deprecated (they're part of the FFI spec). > Sorry, didn't mean to imply that they were. Just offered it as a pragmatic solution to deliver extra help to folks without spending the dev. time to implement a more appropriate pragma like WARNING/INFO. If such a thing already existed... --sigbjorn From jgoerzen at complete.org Thu Apr 23 16:19:18 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Apr 23 16:05:20 2009 Subject: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1 In-Reply-To: References: <9BEB5EF43B5A4042B60C0D8179782DB3D693F5C9F9@EXCHANGE10.campus.tue.nl> Message-ID: <49F0CD46.10306@complete.org> Ahn, Ki Yung wrote: > I don't know the exact reason but this should not fail since I have > Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system. > > I think this is because the filename of the OpenGL shared library is > /usr/lib/libGL.so.1 rather than libGL.so. This is why we have two No. Do not manually create the symlink. It sounds like you don't have the -dev packages for OpenGL installed. You should install them and then you should be OK. From kyagrd at gmail.com Thu Apr 23 16:46:38 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Thu Apr 23 16:32:29 2009 Subject: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1 In-Reply-To: <49F0CD46.10306@complete.org> References: <9BEB5EF43B5A4042B60C0D8179782DB3D693F5C9F9@EXCHANGE10.campus.tue.nl> <49F0CD46.10306@complete.org> Message-ID: John Goerzen wrote: > Ahn, Ki Yung wrote: >> I don't know the exact reason but this should not fail since I have >> Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system. >> >> I think this is because the filename of the OpenGL shared library is >> /usr/lib/libGL.so.1 rather than libGL.so. This is why we have two > > No. Do not manually create the symlink. It sounds like you don't have > the -dev packages for OpenGL installed. You should install them and > then you should be OK. I do already have the dev package libgl1-mesa-dev installed. Stunning fact is that in "installed file" section I see from Synaptic package manager shows that I should have /usr/lib/libGL.so installed, but in reality I don't. I even just tried re-installing libgl1-mesa-dev debian package but I still don't get /usr/lib/libGL.so !!! It's just seems to the bug of libgl1-mesa-dev 7.4-2 packaging. It doesn't seem to make the symbolic link which it claims to make. Duh ... @ So, for now, I should make the symbolic link myself anyway. From duncan.coutts at worc.ox.ac.uk Thu Apr 23 17:39:15 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 23 17:25:42 2009 Subject: 6.10.3 plans In-Reply-To: <49F06633.8050908@galois.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> Message-ID: <1240522755.5557.181.camel@localhost> On Thu, 2009-04-23 at 05:59 -0700, Sigbjorn Finne wrote: > On 4/23/2009 02:05, Duncan Coutts wrote: > > On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote: > > > >> Hi Ian, > >> > >> thanks for the update on plans and the willingness to jump in and do another > >> release cycle so soon after 6.10.2. The suggested fixes seem agreeable to > >> me, but I have one _minor_ additional request for 6.10.3 if you end having > >> to rebuild 'base' -- add a DEPRECATED (or some such) to > >> Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate > >> that the operational behaviour of these have changed. > >> > >> Small change, but could be helpful to package users&authors when migrating > >> beyond 6.10.1 > >> > > > > I agree that it's a little unfortunate that this change is in a minor > > release. > > > > I'm not sure what can be done as far as automatic messages go however. > > The notice about the change is in the release notes. The functions are > > not deprecated (they're part of the FFI spec). > > > Sorry, didn't mean to imply that they were. Just offered it as a > pragmatic solution to deliver extra help to folks without spending the > dev. time to implement a more appropriate pragma like WARNING/INFO. If > such a thing already existed... For INFO we'd want a mechanism to have it tell us the first time but once we acknowledge the info, for it not to keep bugging us or our users every time. Hmm, tricky. Duncan From trentbuck at gmail.com Thu Apr 23 20:46:06 2009 From: trentbuck at gmail.com (Trent W. Buck) Date: Thu Apr 23 21:01:06 2009 Subject: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1 References: <9BEB5EF43B5A4042B60C0D8179782DB3D693F5C9F9@EXCHANGE10.campus.tue.nl> <49F0CD46.10306@complete.org> Message-ID: <30eivij2up.fsf@alexlance.com> "Ahn, Ki Yung" writes: >>> I think this is because the filename of the OpenGL shared library is >>> /usr/lib/libGL.so.1 rather than libGL.so. >> >> No. Do not manually create the symlink. It sounds like you don't >> have the -dev packages for OpenGL installed. > > I do already have the dev package libgl1-mesa-dev installed. [...] > It's just seems to the bug of libgl1-mesa-dev 7.4-2 packaging. It > doesn't seem to make the symbolic link which it claims to make. Duh The file exists in that package, so it seems to me the problem is on your workstation, rather than in the package. I suggest you just reinstall the package in question. You may also want to use cruft(8) to find out if any other files have gone missing, and run a fsck over your root partition. $ aptitude download -t unstable libgl1-mesa-dev [...] Get:1 http://mirror.internode.on.net unstable/main libgl1-mesa-dev 7.4-2 $ dpkg -x libgl1-mesa-dev_7.4-2_all.deb . $ find -name \*.so -ls 13003 0 lrwxrwxrwx 1 twb twb 10 Apr 24 10:41 ./usr/lib/libGL.so -> libGL.so.1 $ From marlowsd at gmail.com Fri Apr 24 06:08:38 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Apr 24 05:54:38 2009 Subject: 6.10.3 plans In-Reply-To: <1240522755.5557.181.camel@localhost> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> Message-ID: 2009/4/23 Duncan Coutts : > On Thu, 2009-04-23 at 05:59 -0700, Sigbjorn Finne wrote: >> On 4/23/2009 02:05, Duncan Coutts wrote: >> > On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote: >> > >> >> Hi Ian, >> >> >> >> thanks for the update on plans and the willingness to jump in and do another >> >> release cycle so soon after 6.10.2. The suggested fixes seem agreeable to >> >> me, but I have one _minor_ additional request for 6.10.3 if you end having >> >> to rebuild 'base' -- add a DEPRECATED (or some such) to >> >> Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate >> >> that the operational behaviour of these have changed. >> >> >> >> Small change, but could be helpful to package users&authors when migrating >> >> beyond 6.10.1 >> >> >> > >> > I agree that it's a little unfortunate that this change is in a minor >> > release. >> > >> > I'm not sure what can be done as far as automatic messages go however. >> > The notice about the change is in the release notes. The functions are >> > not deprecated (they're part of the FFI spec). >> > >> Sorry, didn't mean to imply that they were. Just offered it as a >> pragmatic solution to deliver extra help to folks without spending the >> dev. time to implement a more appropriate pragma like WARNING/INFO. If >> such a thing already existed... > > For INFO we'd want a mechanism to have it tell us the first time but > once we acknowledge the info, for it not to keep bugging us or our users > every time. Hmm, tricky. We do have a WARNING pragma, incedentally: http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma Cheers, Simon From marlowsd at gmail.com Fri Apr 24 06:18:51 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Apr 24 06:04:50 2009 Subject: writeFile/readFile on multiple threads leads to error In-Reply-To: <6c0416190904221450u69b67ebbkabdc1bae4273d7db@mail.gmail.com> References: <404396ef0904220522p168e816awed23f63a8c193d41@mail.gmail.com> <6c0416190904221450u69b67ebbkabdc1bae4273d7db@mail.gmail.com> Message-ID: 2009/4/22 Felix Martini : > 2009/4/22 Simon Marlow: >> You might want to run the process under ProcMon and see if you can >> figure out what's going on (if you can bear to use ProcMon, it's a >> very poor replacement for strace IMO). > > You could try StraceNT instead (not as good as strace though). I like it! Thanks for the tip. Simon From p.k.f.holzenspies at utwente.nl Fri Apr 24 06:56:02 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Fri Apr 24 06:40:33 2009 Subject: Static library to redefine entrypoint Message-ID: <1240570562.4561.11.camel@ewi1043> Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just "ghc --make" or "ghci" their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use "labMain" without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have "external" functions and letting the linker sort stuff out? Regards, Philip From gtener at gmail.com Fri Apr 24 07:06:14 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Fri Apr 24 06:52:16 2009 Subject: Static library to redefine entrypoint In-Reply-To: <1240570562.4561.11.camel@ewi1043> References: <1240570562.4561.11.camel@ewi1043> Message-ID: <220e47b40904240406n6dcb60d2wdaf9d444468fe9f6@mail.gmail.com> Why not just tell them to import your library and do something like > main = withSomeInit labMain where "withSomeInit" is the function you provide? This approach is present in some other libs that require initialization. Best regards Christopher Skrz?tnicki On Fri, Apr 24, 2009 at 12:56, Philip K.F. wrote: > Dear GHCers, > > I am trying to write a wrapper library for lab work to give to students. > My problem is, that the libraries I use require initialization that I > really want to hide from our students. The wrapper I'm writing is > compiled to a static library and installed with cabal, so students can > just "ghc --make" or "ghci" their sources. Here comes the problem: I > want to define main and let students just define labMain as an entry > point to their program. > > How can I have my library use "labMain" without a definition? Keep in > mind that I want to give them a cabalized library that they can just > link to, so I can't give them a template file that they fill and compile > together with my code. Is it at all possible to have "external" > functions and letting the linker sort stuff out? > > Regards, > Philip > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090424/41430151/attachment.htm From p.k.f.holzenspies at utwente.nl Fri Apr 24 07:27:08 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Fri Apr 24 07:11:41 2009 Subject: Static library to redefine entrypoint In-Reply-To: <220e47b40904240406n6dcb60d2wdaf9d444468fe9f6@mail.gmail.com> References: <1240570562.4561.11.camel@ewi1043> <220e47b40904240406n6dcb60d2wdaf9d444468fe9f6@mail.gmail.com> Message-ID: <1240572428.4561.18.camel@ewi1043> On Fri, 2009-04-24 at 13:06 +0200, Krzysztof Skrz?tnicki wrote: > Why not just tell them to import your library and do something like > > main = withSomeInit labMain > where "withSomeInit" is the function you provide? This approach is > present in some other libs that require initialization. Dear Christopher, I know there are alternatives and I know some people use them. A particular problem I have now, though, is SDL. On OS X, the SDL library defines an alternative entry-point to the application, called SDL_main, where the libSDL.a provides a main (insert long story about Cocoa frameworks and Objective-C linking here). I don't particularly like this method, but it's the world I have to work with. Also, many alternatives to SDL don't play nice with GHCi, which is particularly useful for lab teaching. If I can somehow introduce my own new entry point, I could also wrap GHCi in something else quite easily (I know I could wrap GHCi as it is, but it would be even nicer if I could just link to the binary). I figured this level of detail would distract form the question, though and I would run the risk that people would try to solve my SDL linking woes, which is not the point of the question. Regards, Philip From waldmann at imn.htwk-leipzig.de Fri Apr 24 13:20:46 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Apr 24 13:06:49 2009 Subject: Threads and memory management Message-ID: <49F1F4EE.8070306@imn.htwk-leipzig.de> Dear all, I was wondering what is the current status of the ghc RTS with respect to threading. Is it true that the allocator and deallocator (garbage collector) are still single-threaded? I made this example: import Control.Concurrent import Control.Concurrent.QSemN primes1 = sieve [ 2 .. ] primes2 = 2 : sieve [ 3, 5 .. ] sieve (x : ys) = x : sieve ( filter ( \ y -> 0 < y `mod` x ) ys ) main = do s <- newQSemN 0 forkIO $ do print $ sum $ take 10000 primes1 ; signalQSemN s 1 forkIO $ do print $ sum $ take 10000 primes2 ; signalQSemN s 1 waitQSemN s 2 Between the two computations, I see absolutely no data dependencies. So the naive expectation is that using two threads (in the RTS, on a multicore machine) gives half the execution time. I compiled with ghc-6.10.2 -o Par -O2 Par.hs -threaded and when I run with +RTS -N2 (instead of N1), I get my CPU load at 140 % (instead of 100) but the total run time (wall clock) stays nearly constant (i.e. CPU time goes up). For reference, I'm pretty sure a similar thing happens with the current mono implementation (they use Boehm GC and that does not know about C#/CIL threads ?), and this is preventing multi-core speedups in "straightforward" programs (that have no data dependencies, but lots of object creation, e.g. via (hidden) Enumerators and such.) Well, then, if the two Haskell threads are (nearly) completely independent like the above, it would be better to compile and run two separate executables and have them communicate via the OS (pipe or port). But that shouldn't be! (the OS being better than Haskell) Is there was a way of partitioning the memory (managed by the ghc RTS) in totally independent parts that each have their stand-alone memory management. Of course then all communication had to go via some Control.Concurrent.Chan, but that should be fine, if there is little of them. Well, just some thought. This idea can't be new? Tell me why it couldn't possibly work ... J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090424/7660c72e/signature-0001.bin From petersen at haskell.org Sat Apr 25 06:17:39 2009 From: petersen at haskell.org (Jens Petersen) Date: Sat Apr 25 06:03:35 2009 Subject: runghc failing sometimes on Linux/ppc? Message-ID: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> I am seeing some strange failures of runghc on Linux/ppc (Fedora 11 specifically) with ghc-6.10.1 and ghc-6.10.2. For example "cabal install HTTP" works fine but "runghc Setup" failing to run. A workaround (other than using cabal-install) seems to be to compile Setup and then use the output of that to build the package. More strangely this only happens sometimes in the buildsystem, which makes me wonder if it is a fedora issue: most packages built ok in the fedora buildsystem except HTTP and haddock so far. http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log On the other hand in a ppc box I tested on runghc seemed to fail consistently. ghci also segfaulted there. Anyway I thought I would ask here if anyone else had experienced something like this. Jens From duncan.coutts at worc.ox.ac.uk Sat Apr 25 06:18:34 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 25 06:04:54 2009 Subject: Static library to redefine entrypoint In-Reply-To: <1240570562.4561.11.camel@ewi1043> References: <1240570562.4561.11.camel@ewi1043> Message-ID: <1240654714.5557.210.camel@localhost> On Fri, 2009-04-24 at 12:56 +0200, Philip K.F. H?lzenspies wrote: > Dear GHCers, > > I am trying to write a wrapper library for lab work to give to students. > My problem is, that the libraries I use require initialization that I > really want to hide from our students. The wrapper I'm writing is > compiled to a static library and installed with cabal, so students can > just "ghc --make" or "ghci" their sources. Here comes the problem: I > want to define main and let students just define labMain as an entry > point to their program. > > How can I have my library use "labMain" without a definition? Keep in > mind that I want to give them a cabalized library that they can just > link to, so I can't give them a template file that they fill and compile > together with my code. Is it at all possible to have "external" > functions and letting the linker sort stuff out? When I've set practicals like this I've just provided them with a 3 line Main module that imports functions exported by the module(s) that the students write. Eg I have them fill in Draw.lhs but tell them to compile the thing using ghc --make Main.hs. I never found that this confused any of them (indeed some were interested in looking at the code). Duncan From waldmann at imn.htwk-leipzig.de Sat Apr 25 08:31:08 2009 From: waldmann at imn.htwk-leipzig.de (j.waldmann) Date: Sat Apr 25 08:17:04 2009 Subject: Threads and memory management In-Reply-To: <49F1F4EE.8070306@imn.htwk-leipzig.de> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> Message-ID: <23231596.post@talk.nabble.com> Here is some more data. It seems the behaviour depends on 32/64 bit arch? ####################################################### waldmann@master:~/tmp$ uname -a Linux master 2.6.18-6-amd64 #1 SMP Fri Dec 12 05:49:32 UTC 2008 x86_64 GNU/Linux waldmann@master:~/tmp$ time ./Par +RTS -N1 496165411 496165411 real 0m22.580s user 0m22.541s sys 0m0.040s waldmann@master:~/tmp$ time ./Par +RTS -N2 496165411 496165411 real 0m21.259s user 0m26.678s sys 0m0.164s ######################################################## waldmann@box:~/tmp> uname -a Linux box 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 GNU/Linux waldmann@box:~/tmp> time ./Par +RTS -N1 496165411 496165411 real 0m29.802s user 0m29.670s sys 0m0.028s waldmann@box:~/tmp> time ./Par +RTS -N2 496165411 496165411 real 0m11.219s user 0m14.917s sys 0m0.164s ################################################### I don't understand this. The fun thing is that the first machine is Intel(R) Xeon(R) CPU X5365 @ 3.00GHz while the second is a much cheaper model name : Genuine Intel(R) CPU T2050 @ 1.60GHz -- View this message in context: http://www.nabble.com/Threads-and-memory-management-tp23221239p23231596.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From igloo at earth.li Sat Apr 25 10:16:14 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Apr 25 10:02:09 2009 Subject: 6.10.3 plans In-Reply-To: References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> Message-ID: <20090425141614.GA26881@matrix.chaos.earth.li> On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote: > > We do have a WARNING pragma, incedentally: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma I don't think that using it for this would be a good idea, though. It would mean that people who really do want Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} would not be able to write warning-free code. Thanks Ian From igloo at earth.li Sat Apr 25 10:43:16 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Apr 25 10:29:13 2009 Subject: runghc failing sometimes on Linux/ppc? In-Reply-To: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> References: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> Message-ID: <20090425144316.GB26881@matrix.chaos.earth.li> On Sat, Apr 25, 2009 at 08:17:39PM +1000, Jens Petersen wrote: > I am seeing some strange failures of runghc on Linux/ppc (Fedora 11 > specifically) > with ghc-6.10.1 and ghc-6.10.2. > > For example "cabal install HTTP" works fine but "runghc Setup" failing to run. Are you using a registerised build? If so, then as PPC/Linux isn't a tier 1 platform, it could well have bitrotted. > http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log These don't seem to contain the output. Thanks Ian From alexander.dunlap at gmail.com Sat Apr 25 14:18:43 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Apr 25 14:04:39 2009 Subject: Extensible Exceptions and IO Message-ID: <57526e770904251118t37c68159k1f8e3e09c5c68374@mail.gmail.com> In the extensible exceptions paper[1], which I believe is the guide behind the current Control.Exception in GHC 6.10, a SomeIOException type is discussed so that it would be possible to use the nice interface for IOExceptions. Is this implemented anywhere? In the GHC libraries, all I see is the old interface just plugged into a simple wrapper, so you have to use guard . isDoesNotExistError (for example) with catchJust to catch a certain type of exception. If not, are there any plans to implement it? Alex From alexander.dunlap at gmail.com Sat Apr 25 14:24:59 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Apr 25 14:10:55 2009 Subject: Extensible Exceptions and IO In-Reply-To: <57526e770904251118t37c68159k1f8e3e09c5c68374@mail.gmail.com> References: <57526e770904251118t37c68159k1f8e3e09c5c68374@mail.gmail.com> Message-ID: <57526e770904251124i12dedd74m80c589810ba498bf@mail.gmail.com> On Sat, Apr 25, 2009 at 11:18 AM, Alexander Dunlap wrote: > In the extensible exceptions paper[1], which I believe is the guide > behind the current Control.Exception in GHC 6.10, a SomeIOException > type is discussed so that it would be possible to use the nice > interface for IOExceptions. Is this implemented anywhere? In the GHC > libraries, all I see is the old interface just plugged into a simple > wrapper, so you have to use guard . isDoesNotExistError (for example) > with catchJust to catch a certain type of exception. If not, are there > any plans to implement it? > > Alex > Sorry...forgot to send the link. [1]http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf Alex From chak at cse.unsw.edu.au Sat Apr 25 19:21:37 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat Apr 25 19:07:36 2009 Subject: 6.10.3 plans In-Reply-To: <20090425141614.GA26881@matrix.chaos.earth.li> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> <20090425141614.GA26881@matrix.chaos.earth.li> Message-ID: <14CB27D9-8BD4-4218-9A03-D97824402E93@cse.unsw.edu.au> Ian Lynagh: > On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote: >> >> We do have a WARNING pragma, incedentally: >> >> http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma > > I don't think that using it for this would be a good idea, though. It > would mean that people who really do want > Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} > would not be able to write warning-free code. I agree. Manuel From lazycat.manatee at gmail.com Sat Apr 25 23:19:35 2009 From: lazycat.manatee at gmail.com (Andy Stewart) Date: Sat Apr 25 23:11:02 2009 Subject: Some suggestion for "mutually recursive modules" problem. Message-ID: <49f3d413.1498600a.7b97.ffff9ea7@mx.google.com> Dear GHC developers: First thanks for your work with GHC! And i have suggestion for "mutually recursive modules" problem: Now GHC use .hs-boot fix "mutually recursive modules" problem, yes it can work, but it not pretty. So GHC can fix this problem automatically at next release version? And programmer not need write .hs-boot file, then programmer's life will be more easier. Thanks! -- Andy From ml at isaac.cedarswampstudios.org Sun Apr 26 13:39:24 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Apr 26 13:25:32 2009 Subject: Some suggestion for "mutually recursive modules" problem. In-Reply-To: <49f3d413.1498600a.7b97.ffff9ea7@mx.google.com> References: <49f3d413.1498600a.7b97.ffff9ea7@mx.google.com> Message-ID: <200904261339.25144.ml@isaac.cedarswampstudios.org> Andy Stewart wrote: > Now GHC use .hs-boot fix "mutually recursive modules" problem, yes it > can work, but it not pretty. > > So GHC can fix this problem automatically at next release version? Please add yourself (that is, your e-mail address) to the "cc:" on the corresponding bug-report, if you want to vote for this feature: http://hackage.haskell.org/trac/ghc/ticket/1409 (you can login as user "guest", password "guest") If enough people do this, then GHC HQ might start to believe that it's an important feature. (Right now they/we seem to think it's a little absurd... probably because it would require some implementation/design work in GHC...) -Isaac From sof at galois.com Sun Apr 26 20:28:49 2009 From: sof at galois.com (Sigbjorn Finne) Date: Sun Apr 26 20:14:45 2009 Subject: 6.10.3 plans In-Reply-To: <20090425141614.GA26881@matrix.chaos.earth.li> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> <20090425141614.GA26881@matrix.chaos.earth.li> Message-ID: <49F4FC41.5010208@galois.com> On 4/25/2009 07:16, Ian Lynagh wrote: > On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote: > >> We do have a WARNING pragma, incedentally: >> >> http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma >> > > I don't think that using it for this would be a good idea, though. It > would mean that people who really do want > Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} > would not be able to write warning-free code. > Repeating myself, I suppose :) , but I would be happy to take that "hit" for 6.10.3 if it avoids other GHC users from spending unproductive time getting on top of this change. ymmv. --sigbjorn From leledumbo_cool at yahoo.co.id Mon Apr 27 01:30:53 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Mon Apr 27 01:16:43 2009 Subject: Newby question re quicksort In-Reply-To: <23250159.post@talk.nabble.com> References: <23250159.post@talk.nabble.com> Message-ID: <23250345.post@talk.nabble.com> I think you miss something important here: quickslop :: (Ord a) => [a] ->[a] quickslop [] = [] quickslop (x:xs) = quickslop [a | a <- xs, a <= x] ++ [x] ++ quickslop [b | b <- xs, b > x] -- View this message in context: http://www.nabble.com/Newby-question-re-quicksort-tp23250159p23250345.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From berthold at Mathematik.Uni-Marburg.de Mon Apr 27 05:41:12 2009 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Mon Apr 27 05:27:04 2009 Subject: Threads and memory management In-Reply-To: <20090424170652.D6760324C34@www.haskell.org> References: <20090424170652.D6760324C34@www.haskell.org> Message-ID: <49F57DB8.80202@mathematik.uni-marburg.de> > Message: 8 > Date: Fri, 24 Apr 2009 19:20:46 +0200 > From: Johannes Waldmann > Subject: Threads and memory management > To: "glasgow-haskell-users@haskell.org" > > Message-ID: <49F1F4EE.8070306@imn.htwk-leipzig.de> > Content-Type: text/plain; charset="iso-8859-1" > > Dear all, > > I was wondering what is the current status of the ghc RTS > with respect to threading. Is it true that the allocator > and deallocator (garbage collector) are still single-threaded? > > > I made this example: > ... > Well, then, if the two Haskell threads are (nearly) completely > independent like the above, it would be better to compile and run > two separate executables and have them communicate via the OS (pipe or > port). But that shouldn't be! (the OS being better than Haskell) > > Is there was a way of partitioning the memory (managed by the ghc RTS) > in totally independent parts that each have their stand-alone > memory management. Of course then all communication > had to go via some Control.Concurrent.Chan, > but that should be fine, if there is little of them. > > Well, just some thought. This idea can't be new? > Tell me why it couldn't possibly work ... > > J.W. Hello everybody, Since I did not see any other replies, I thought I might give you some pointers to more information. Other people will perhaps follow up with more details. In all, quite a few things are recently going on about threading in the GHC world, and it is even difficult to keep the oversight. - GHC has undergone a big overhaul with respect to threading support since last September. I have started this work at Microsoft Research last summer, and a lot more has been done by Simon Marlow since. There are forthcoming papers (mainly one submitted to ICFP) about this work. The main focus here was the shared-heap implementation of the Glasgow-parallel Haskell programming model (see http://www.macs.hw.ac.uk/~dsg/gph/ , mainly the paper here: http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html). This programming model is supported in GHC versions since 2004 already, but should now deliver much better performance. That said, the vast majority of the latest GHC optimisations carried out in the GHC HEAD aim at improving thread performance (the explicit basis of the more implicit programming model), and thus relate directly to what you observe. The version you have tested with is GHC-6.10.2, which does not include substantial threading optimisations. - a related question is tool support for parallel performance tuning. Very recently, GHC (HEAD) supports a visual post-mortem analysis, and a graphical tool "ThreadScope" has been developed by Satnam Singh and others. http://raintown.org/?page_id=132 There is a related posting in glasgow-haskell-users (11 March). - GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html - about your remark that separate OS processes should communicate, rather than having the Haskell RTS manage all threads: yes, there are programming models around which aim at parallel Haskell with distributed heap. Aside from the older GpH cluster implementations, you might have a look at the language Eden: http://www.mathematik.uni-marburg.de/~eden/?content=paper (and personally, I might apologise for the suboptimal web presence...) Using Eden (and its implementation) would be a way to realise the model you propose, communicating processes with separate heaps, but managed by a common parallel runtime system and programmed in one single program. Let me add that Eden also provides a tool with features very similar to what recently became "ThreadScope". Interestingly, a number of recent experiments have shown that Eden has competitive performance to the shared heap GpH implementation when executed on multicores, delegating all communication to the underlying middleware (most commonly PVM). Early papers discussing alike results have been published recently or are in preparation. http://www-fp.cs.st-and.ac.uk/~kh/mainICPP09.pdf I strongly support the idea to collect all this related information systematically! Kickoff is already present here: http://haskell.org/haskellwiki/Performance/Parallel However, the question is where to start... the field is indeed very broad, and the page above will surely focus on GHC rather than general ideas. So I hesitate in dropping all this information into the wiki and rather send a mail for now. Cheers Jost Berthold From marlowsd at gmail.com Mon Apr 27 06:13:26 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 27 05:59:28 2009 Subject: Threads and memory management In-Reply-To: <23231596.post@talk.nabble.com> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> Message-ID: <49F58546.6060707@gmail.com> On 25/04/2009 13:31, j.waldmann wrote: > Here is some more data. It seems the behaviour depends on 32/64 bit arch? > > ####################################################### > > waldmann@master:~/tmp$ uname -a > Linux master 2.6.18-6-amd64 #1 SMP Fri Dec 12 05:49:32 UTC 2008 x86_64 > GNU/Linux > > waldmann@master:~/tmp$ time ./Par +RTS -N1 > 496165411 > 496165411 > > real 0m22.580s > user 0m22.541s > sys 0m0.040s > waldmann@master:~/tmp$ time ./Par +RTS -N2 > 496165411 > 496165411 > > real 0m21.259s > user 0m26.678s > sys 0m0.164s > > ######################################################## > > waldmann@box:~/tmp> uname -a > Linux box 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 > GNU/Linux > > waldmann@box:~/tmp> time ./Par +RTS -N1 > 496165411 > 496165411 > > real 0m29.802s > user 0m29.670s > sys 0m0.028s > waldmann@box:~/tmp> time ./Par +RTS -N2 > 496165411 > 496165411 > > real 0m11.219s > user 0m14.917s > sys 0m0.164s This is a very strange result: the user time should not *decrease*, but rather should stay the same or increase a bit when adding cores. If your program is GC-bound, then using a 32-bit build will improve performance, simply because it is shoveling half as much memory around. Check whether it is GC-bound by using +RTS -sstderr. Anyway, the current situation is that with GHC 6.10.2 there are a lot of performance quirks and bottlenecks with respect to parallel programs, some of which have been squashed in HEAD. Try a recent HEAD snapshot if you can, or wait for 6.12.1. Cheers, Simon From bulat.ziganshin at gmail.com Mon Apr 27 06:29:18 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 27 06:15:30 2009 Subject: Threads and memory management In-Reply-To: <49F58546.6060707@gmail.com> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> <49F58546.6060707@gmail.com> Message-ID: <1177875678.20090427142918@gmail.com> Hello Simon, Monday, April 27, 2009, 2:13:26 PM, you wrote: > This is a very strange result: the user time should not *decrease*, but > rather should stay the same or increase a bit when adding cores. If ability to run two threads simultaneous may increase performance in some scenarios. one example is consumer+producer threads. with 2 OS threads all produced data are consumed immediately, so we live inside L2 cache. with 1 OS thread produced data overflow the cache before threads are switched, making execution much slower -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Mon Apr 27 08:32:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 27 08:17:57 2009 Subject: 6.10.3 plans In-Reply-To: <49F4FC41.5010208@galois.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> <20090425141614.GA26881@matrix.chaos.earth.li> <49F4FC41.5010208@galois.com> Message-ID: <49F5A5C2.8080803@gmail.com> On 27/04/2009 01:28, Sigbjorn Finne wrote: > On 4/25/2009 07:16, Ian Lynagh wrote: >> On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote: >>> We do have a WARNING pragma, incedentally: >>> >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma >>> >> >> I don't think that using it for this would be a good idea, though. It >> would mean that people who really do want >> Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} >> would not be able to write warning-free code. > > Repeating myself, I suppose :) , but I would be happy to take that "hit" > for 6.10.3 if it avoids other GHC users from spending unproductive > time getting on top of this change. ymmv. As a compromise, how about expanding the runtime error message to make it clear that this is a change in 6.10.2? finalizer: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. Cheers, Simon From dons at galois.com Mon Apr 27 11:56:43 2009 From: dons at galois.com (Don Stewart) Date: Mon Apr 27 11:43:52 2009 Subject: Threads and memory management In-Reply-To: <49F57DB8.80202@mathematik.uni-marburg.de> References: <20090424170652.D6760324C34@www.haskell.org> <49F57DB8.80202@mathematik.uni-marburg.de> Message-ID: <20090427155643.GA834@whirlpool.galois.com> I've added more notes to this page: http://haskell.org/haskellwiki/Performance/Parallel berthold: > >> Message: 8 >> Date: Fri, 24 Apr 2009 19:20:46 +0200 >> From: Johannes Waldmann >> Subject: Threads and memory management >> To: "glasgow-haskell-users@haskell.org" >> >> Message-ID: <49F1F4EE.8070306@imn.htwk-leipzig.de> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Dear all, >> >> I was wondering what is the current status of the ghc RTS >> with respect to threading. Is it true that the allocator >> and deallocator (garbage collector) are still single-threaded? >> >> >> I made this example: >> ... >> Well, then, if the two Haskell threads are (nearly) completely >> independent like the above, it would be better to compile and run >> two separate executables and have them communicate via the OS (pipe or >> port). But that shouldn't be! (the OS being better than Haskell) >> >> Is there was a way of partitioning the memory (managed by the ghc RTS) >> in totally independent parts that each have their stand-alone >> memory management. Of course then all communication >> had to go via some Control.Concurrent.Chan, >> but that should be fine, if there is little of them. >> >> Well, just some thought. This idea can't be new? >> Tell me why it couldn't possibly work ... >> >> J.W. > > > > Hello everybody, > > Since I did not see any other replies, I thought I might give you some > pointers to more information. Other people will perhaps follow up with > more details. > In all, quite a few things are recently going on about threading in the > GHC world, and it is even difficult to keep the oversight. > > - GHC has undergone a big overhaul with respect to threading support > since last September. I have started this work at Microsoft Research > last summer, and a lot more has been done by Simon Marlow since. > There are forthcoming papers (mainly one submitted to ICFP) about this > work. The main focus here was the shared-heap implementation of the > Glasgow-parallel Haskell programming model (see > http://www.macs.hw.ac.uk/~dsg/gph/ , mainly the paper here: > http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html). > This programming model is supported in GHC versions since 2004 already, > but should now deliver much better performance. That said, the vast > majority of the latest GHC optimisations carried out in the GHC HEAD aim > at improving thread performance (the explicit basis of the more implicit > programming model), and thus relate directly to what you observe. > The version you have tested with is GHC-6.10.2, which does not include > substantial threading optimisations. > > - a related question is tool support for parallel performance tuning. > Very recently, GHC (HEAD) supports a visual post-mortem analysis, and a > graphical tool "ThreadScope" has been developed by Satnam Singh and > others. http://raintown.org/?page_id=132 > There is a related posting in glasgow-haskell-users (11 March). > > - GHC has parallel garbage collection since 2007 already. However, > recent work showed that this parallel GC sometimes hampers performance, > in particular on Linux systems. See this thread for more: > http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html > > - about your remark that separate OS processes should communicate, > rather than having the Haskell RTS manage all threads: yes, there are > programming models around which aim at parallel Haskell with distributed > heap. Aside from the older GpH cluster implementations, you might have a > look at the language Eden: > http://www.mathematik.uni-marburg.de/~eden/?content=paper > (and personally, I might apologise for the suboptimal web presence...) > Using Eden (and its implementation) would be a way to realise the model > you propose, communicating processes with separate heaps, but managed by > a common parallel runtime system and programmed in one single program. > Let me add that Eden also provides a tool with features very similar to > what recently became "ThreadScope". > > Interestingly, a number of recent experiments have shown that Eden has > competitive performance to the shared heap GpH implementation when > executed on multicores, delegating all communication to the underlying > middleware (most commonly PVM). Early papers discussing alike results > have been published recently or are in preparation. > http://www-fp.cs.st-and.ac.uk/~kh/mainICPP09.pdf > > I strongly support the idea to collect all this related information > systematically! Kickoff is already present here: > http://haskell.org/haskellwiki/Performance/Parallel > However, the question is where to start... the field is indeed very > broad, and the page above will surely focus on GHC rather than general > ideas. So I hesitate in dropping all this information into the wiki and > rather send a mail for now. > > Cheers > Jost Berthold > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From sof at galois.com Mon Apr 27 12:19:46 2009 From: sof at galois.com (Sigbjorn Finne) Date: Mon Apr 27 12:05:36 2009 Subject: 6.10.3 plans In-Reply-To: <49F5A5C2.8080803@gmail.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> <20090425141614.GA26881@matrix.chaos.earth.li> <49F4FC41.5010208@galois.com> <49F5A5C2.8080803@gmail.com> Message-ID: <49F5DB22.3050709@galois.com> Simon Marlow wrote: > On 27/04/2009 01:28, Sigbjorn Finne wrote: >> ... > > As a compromise, how about expanding the runtime error message to make > it clear that this is a change in 6.10.2? > > finalizer: error: a C finalizer called back into Haskell. > This was previously allowed, but is disallowed in GHC 6.10.2 and > later. > To create finalizers that may call back into Haskll, use > Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. > That's definitely helpful; I'm all for it. Hope there's time available to put it in. cheers --sigbjorn From iavor.diatchki at gmail.com Mon Apr 27 19:35:04 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Apr 27 19:21:03 2009 Subject: 6.10.3 plans In-Reply-To: <49F5A5C2.8080803@gmail.com> References: <20090422235646.GA29183@matrix.chaos.earth.li> <49EFCA95.8000709@galois.com> <1240477519.5557.143.camel@localhost> <49F06633.8050908@galois.com> <1240522755.5557.181.camel@localhost> <20090425141614.GA26881@matrix.chaos.earth.li> <49F4FC41.5010208@galois.com> <49F5A5C2.8080803@gmail.com> Message-ID: <5ab17e790904271635r607c0108ndfcd0f9808f42cf4@mail.gmail.com> Hi, Perhaps it would make sense to add something along those lines to the documentation for Foreign.newForeignPtr as well? -Iavor On Mon, Apr 27, 2009 at 5:32 AM, Simon Marlow wrote: > On 27/04/2009 01:28, Sigbjorn Finne wrote: >> >> On 4/25/2009 07:16, Ian Lynagh wrote: >>> >>> On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote: >>>> >>>> We do have a WARNING pragma, incedentally: >>>> >>>> >>>> http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma >>>> >>> >>> I don't think that using it for this would be a good idea, though. It >>> would mean that people who really do want >>> Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} >>> would not be able to write warning-free code. >> >> Repeating myself, I suppose :) , but I would be happy to take that "hit" >> for 6.10.3 if it avoids other GHC users from spending unproductive >> time getting on top of this change. ymmv. > > As a compromise, how about expanding the runtime error message to make it > clear that this is a change in 6.10.2? > > finalizer: error: a C finalizer called back into Haskell. > ? This was previously allowed, but is disallowed in GHC 6.10.2 and later. > ? To create finalizers that may call back into Haskll, use > ? Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. > > Cheers, > ? ? ? ?Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From scooter.phd at gmail.com Tue Apr 28 01:24:31 2009 From: scooter.phd at gmail.com (Scott Michel) Date: Tue Apr 28 01:10:35 2009 Subject: Chimeric syntax Message-ID: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> I've been hacking along on a NetBeans Haskell plugin (*) Looking at Parser.y.pp, because both Eclipse and NetBeans work with antlr, it seems like there are interesting cases in which chimeric constructions parse correctly. Here's an example: class ParsedModule m where let { a = 1; b = 2; } in a + b :: Int :: Int This is mostly accepted by ghc, which complains with an invalid type signature. This got me to thinking that either ghc has issues or I have some fundamental misunderstanding of Haskell syntax. Or, maybe I should use someone else's grammar. -scooter (*) Don't tell me about eclipsefp2: I know already. It's the Monty Python parrot of Haskell IDE support. And the code is about as Teutonic as one can get. :-) From marlowsd at gmail.com Tue Apr 28 05:27:53 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 28 05:14:18 2009 Subject: Threads and memory management In-Reply-To: <1177875678.20090427142918@gmail.com> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> <49F58546.6060707@gmail.com> <1177875678.20090427142918@gmail.com> Message-ID: <49F6CC19.90208@gmail.com> On 27/04/2009 11:29, Bulat Ziganshin wrote: > Hello Simon, > > Monday, April 27, 2009, 2:13:26 PM, you wrote: > >> This is a very strange result: the user time should not *decrease*, but >> rather should stay the same or increase a bit when adding cores. If > > ability to run two threads simultaneous may increase performance in > some scenarios. one example is consumer+producer threads. with 2 > OS threads all produced data are consumed immediately, so we live > inside L2 cache. with 1 OS thread produced data overflow the cache > before threads are switched, making execution much slower Yes, good point. Though I'd be surprised if that was happening here. Cheers, Simon From waldmann at imn.htwk-leipzig.de Tue Apr 28 12:25:52 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Apr 28 12:11:44 2009 Subject: Threads and memory management In-Reply-To: <49F58546.6060707@gmail.com> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> <49F58546.6060707@gmail.com> Message-ID: <49F72E10.9080805@imn.htwk-leipzig.de> Thanks for your comments. > Check whether it is GC-bound by using +RTS -sstderr. Well yes, it does a lot of GC (there's no way for the compiler to optimize away the list of primes) because that was the point of the example: to confirm (or disprove) that GC hurts parallelism (at the moment). INIT time 0.00s ( 0.00s elapsed) MUT time 13.23s ( 7.98s elapsed) GC time 14.12s ( 14.11s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 27.35s ( 22.09s elapsed) %GC time 51.6% (63.9% elapsed) > Try a recent HEAD snapshot if you can, or wait for 6.12.1. I did with 6.11.20090425 and it coredumps with +RTS -N2 (on x86_64) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001950 (LWP 1007)] 0x000000000044e831 in yieldCapability () Current language: auto; currently asm (gdb) where #0 0x000000000044e831 in yieldCapability () #1 0x000000000042d8d3 in schedule () #2 0x000000000042e485 in workerStart () #3 0x00002b680cdcdfc7 in start_thread () from /lib/libpthread.so.0 #4 0x00002b680d0b25ad in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () but it runs with +RTS -N2 -q1 (I don't know exactly what this does) and the numbers did not change much - down from 22 sec to 21 sec maybe) PS: yes, I confirmed that the OS can run the two "primes" enumerations (as separately compiled executables) in parallel in 6 sec wall time. Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090428/9ff40a8a/signature.bin From allbery at ece.cmu.edu Tue Apr 28 15:50:25 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Apr 28 15:36:26 2009 Subject: Chimeric syntax In-Reply-To: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> References: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> Message-ID: <9E3230ED-03A4-4D20-A504-D76F2ED4A68F@ece.cmu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 28, 2009, at 01:24 , Scott Michel wrote: > I've been hacking along on a NetBeans Haskell plugin (*) Looking at > Parser.y.pp, because both Eclipse and NetBeans work with antlr, it > seems like there are interesting cases in which chimeric constructions > parse correctly. Here's an example: > > class ParsedModule m where > let { a = 1; b = 2; } in a + b :: Int :: Int > > This is mostly accepted by ghc, which complains with an invalid type > signature. Looking at the Online Report, my guess is it parses as: exp^0 = "let {a = 1; b = 2; } in a + b" type = "Int :: Int" and of course "Int :: Int" is an invalid type signature. (::) parses as if it were a very low precedence operator. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkn3Xg4ACgkQIn7hlCsL25XQpgCdFnKgoxE8DlJWMpLTabR6gkIW tZIAnjnR8HheL8RtO87Z3ZteRqfHewUo =eptK -----END PGP SIGNATURE----- From batterseapower at hotmail.com Tue Apr 28 16:09:05 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Apr 28 15:54:51 2009 Subject: Chimeric syntax In-Reply-To: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> References: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> Message-ID: <9d4d38820904281309s43e523f1m3b57053beeb0cb8@mail.gmail.com> 2009/4/28 Scott Michel : > This got me to thinking that either ghc has issues or I have some > fundamental misunderstanding of Haskell syntax. Or, maybe I should use > someone else's grammar. GHC's parser is over-generous by design. See http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Parser. A precise description of what is valid Haskell it is certainly NOT, but it will certainly accept any valid Haskell program. This may not be quite what you want for an IDE - but it might be good enough for a first cut. Cheers, Max From scooter.phd at gmail.com Tue Apr 28 22:33:45 2009 From: scooter.phd at gmail.com (Scott Michel) Date: Tue Apr 28 22:19:31 2009 Subject: Chimeric syntax In-Reply-To: <9d4d38820904281309s43e523f1m3b57053beeb0cb8@mail.gmail.com> References: <258cd3200904272224n6be5ad70wd17e32c6dac85d34@mail.gmail.com> <9d4d38820904281309s43e523f1m3b57053beeb0cb8@mail.gmail.com> Message-ID: <258cd3200904281933g6dd60277tda922c50d5b1440e@mail.gmail.com> On Tue, Apr 28, 2009 at 1:09 PM, Max Bolingbroke wrote: > 2009/4/28 Scott Michel : >> This got me to thinking that either ghc has issues or I have some >> fundamental misunderstanding of Haskell syntax. Or, maybe I should use >> someone else's grammar. > > GHC's parser is over-generous by design. See > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Parser. A > precise description of what is valid Haskell it is certainly NOT, but > it will certainly accept any valid Haskell program. This may not be > quite what you want for an IDE - but it might be good enough for a > first cut. Actually, given what ghc will accept, I seriously doubt that the LR grammar can ever successfully translate to a LL(*) grammar. Liberal, it may be, but it probably should be valid. I just followed the current parser rules to their ultimate conclusion. I suspect that people would be quite surprised by what Parser.y.pp will actually accept. Basically, my understanding is that a 'let' should not be allowed in a 'class' declaration and yet, ghc is quite happy to allow it. So my understanding is correct, but ghc grammar is (perhaps) too flexible. -scooter PS: Anyone got a multicore Haskell experience they want to share at Supercomputing this year? The guys from Galois did a great job shocking the audience last year. From scooter.phd at gmail.com Wed Apr 29 13:27:59 2009 From: scooter.phd at gmail.com (Scott Michel) Date: Wed Apr 29 13:13:42 2009 Subject: Multicore Haskell user experiences Message-ID: <258cd3200904291027r418e4aa8r6a83e8b51a8b67b7@mail.gmail.com> [Sorry if this is the wrong place to hold this discussion... I'll move it if told to do so...] Simon P-J (et. al.) did recently publish a paper on making the Haskell runtime more multicore friendly, addressing the GC issue (among many things.) More broadly, though, there are two opportunities for multicore Haskell presentations: a) An IEEE conference in Pasedena, CA, July 19-21. The major theme is multicore in space (if you're familiar with OPERA/MAESTRO), but as a one of the conference-within-a-conference organizers, I'm interested in multicore programmability. Work on runtime environments, new language features, good-bad-and-ugly experiences, and "hard technical topics" are welcome. Looking for one or two presentations for this. b) Supercomputing '09 in Portland, OR next November. Focus here is primarily on user experience programming multicore with up-and-coming languages/environments. Any suggestions or presentation pitches are welcome. -scooter On Wed, Apr 29, 2009 at 3:01 AM, Johannes Waldmann wrote: >> PS: Anyone got a multicore Haskell experience they want to share at >> Supercomputing this year? The guys from Galois did a great job >> shocking the audience last year. > > well, this is my shocking experience: > http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/16809 > > where of course the conclusion is that parallelism > does not work "out of the box". No surprise? > While I completely would buy this statement for Java, C# etc > I hoped it was different for Haskell. > I don't want to rewrite my programs to make them less depend on GC. > Sure it could be done but then I could use Java from the start. > > J.W. > > From dons at galois.com Wed Apr 29 14:11:45 2009 From: dons at galois.com (Don Stewart) Date: Wed Apr 29 13:58:48 2009 Subject: Multicore Haskell user experiences In-Reply-To: <258cd3200904291027r418e4aa8r6a83e8b51a8b67b7@mail.gmail.com> References: <258cd3200904291027r418e4aa8r6a83e8b51a8b67b7@mail.gmail.com> Message-ID: <20090429181145.GR12145@whirlpool.galois.com> Hey Scott, Yes, I think this is the appropriate place. The Data Parallel Haskell team, and the GHC rts team are watching! -- Don scooter.phd: > [Sorry if this is the wrong place to hold this discussion... I'll move > it if told to do so...] > > Simon P-J (et. al.) did recently publish a paper on making the Haskell > runtime more multicore friendly, addressing the GC issue (among many > things.) > > More broadly, though, there are two opportunities for multicore > Haskell presentations: > > a) An IEEE conference in Pasedena, CA, July 19-21. The major theme is > multicore in space (if you're familiar with OPERA/MAESTRO), but as a > one of the conference-within-a-conference organizers, I'm interested > in multicore programmability. Work on runtime environments, new > language features, good-bad-and-ugly experiences, and "hard technical > topics" are welcome. Looking for one or two presentations for this. > > b) Supercomputing '09 in Portland, OR next November. Focus here is > primarily on user experience programming multicore with up-and-coming > languages/environments. > > Any suggestions or presentation pitches are welcome. > > > -scooter > > > On Wed, Apr 29, 2009 at 3:01 AM, Johannes Waldmann > wrote: > >> PS: Anyone got a multicore Haskell experience they want to share at > >> Supercomputing this year? The guys from Galois did a great job > >> shocking the audience last year. > > > > well, this is my shocking experience: > > http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/16809 > > > > where of course the conclusion is that parallelism > > does not work "out of the box". No surprise? > > While I completely would buy this statement for Java, C# etc > > I hoped it was different for Haskell. > > I don't want to rewrite my programs to make them less depend on GC. > > Sure it could be done but then I could use Java from the start. > > > > J.W. > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From p.k.f.holzenspies at utwente.nl Wed Apr 29 18:48:43 2009 From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?Philip_H=F6lzenspies?=) Date: Wed Apr 29 18:34:28 2009 Subject: Compiler modes / FFI / forcing CPP Message-ID: <73935484-BE37-42B9-9C5E-C4426790E02E@utwente.nl> Dear GHC-ers, From earlier questions, it seems no one wants to get down and dirty with linker tricks in ghc. I'm now looking over an alternative solution. I'm currently trying to use SDL. There's a wrapper on hackage, which works fine under Linux, but it takes some tinkering under Mac OS X, because OS X needs instantiated Cocoa stuff for the SDL entry point. Long story short, to use SDL with ghc on the OS X, a little wrapper c- file needs to be written, because the linker will find a 'main' function in libSDLmain.a which expects a function 'SDL_main' as an entry point into the user code. I have written a small c file that can be used to wrap around any haskell module (see below), based on the macro (cpp) definition of MODNAME. I can compile this c file with gcc, for, let's say a module Foo with entry point Foo.bar (so, if we could still have ghc make the entry point, we would say ghc -main-is Foo.bar): gcc -c -DMODNAME=Foo -D"ENTRYPOINT=bar();" -o Foo_entry.o entry.c However, this only works after I explicitly add ghc's "include" dir to my search path so that HsFFI.h can be found. Before I had this pre- processor trick, I could simply feed the c file to ghc, together with all my haskell files. Ghc then simply adds the correct includes and feeds the c file to the c compiler. Unfortunately, giving ghc the above -D options doesn't do much good. The problem seems to lie with the suffix recognition ghc does. I took this from [1]. With the -cpp switch, the c pre-processor is used, but only when the file has a .hs suffix. The c compiler is only run when the file has a .c suffix. Using -x .hs puts the file correctly through the c pre-processor, but then fails to compile it, because it's not haskell code. Using -x .c doesn't do pre-processing (even with -cpp). I tried to compile this wrapper using this command (assume now that we have Foo.hsMain as an entry point): ghc -cpp -pgmP cc -optP-E -DMODNAME=Foo -o Foo_entry.o entry.c (Notice that you can't just use cpp, because on OS X that's a shell script that doesn't provide CPPs full strength, so you want "cc -E".) This doesn't work: entry.c:27:2: error: #error MODNAME undefined! Trying to be more explicit as to where the -D should go: ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o entry.c does exactly the same. Now faking .hs: ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o -x hs entry.c which produces the error (coming from stdio.h inclusion): /usr/include/i386/_types.h:37:28: parse error on input `;' So, I guess my question is: Is it possible to let a c input file of ghc pass through *both* the c pre-processor *and* the c compiler? Kind regards, Philip [1] GHC User's Guide: Section 5.4: Modes of operation http://www.haskell.org/ghc/docs/latest/html/users_guide/modes.html entry.c: #ifdef MODNAME #ifndef ENTRYPOINT #define ENTRYPOINT hsMain(); #endif #include #include "HsFFI.h" #define __HS_mangle(name) __stginit_ ## name #define __Xpand_HS_mangle(nm) __HS_mangle(nm) #define __hs_mangled_module __Xpand_HS_mangle( MODNAME ) #define __pack_quotes(x) #x #define __calc_include(x) __pack_quotes(x##_stub.h) #define __Xpand_calc_include(x) __calc_include(x) #include __Xpand_calc_include(MODNAME) extern void __hs_mangled_module ( void ); int SDL_main(int argc, char *argv[]) { hs_init(&argc, &argv); hs_add_root(__hs_mangled_module); ENTRYPOINT hs_exit(); return 0; } #else /* MODNAME */ #error MODNAME undefined! #endif /* MODNAME */ From marlowsd at gmail.com Thu Apr 30 04:25:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 30 04:11:14 2009 Subject: Compiler modes / FFI / forcing CPP In-Reply-To: <73935484-BE37-42B9-9C5E-C4426790E02E@utwente.nl> References: <73935484-BE37-42B9-9C5E-C4426790E02E@utwente.nl> Message-ID: <49F96071.5050608@gmail.com> On 29/04/2009 23:48, Philip H?lzenspies wrote: > Dear GHC-ers, > > From earlier questions, it seems no one wants to get down and dirty > with linker tricks in ghc. I'm now looking over an alternative solution. > > I'm currently trying to use SDL. There's a wrapper on hackage, which > works fine under Linux, but it takes some tinkering under Mac OS X, > because OS X needs instantiated Cocoa stuff for the SDL entry point. > Long story short, to use SDL with ghc on the OS X, a little wrapper > c-file needs to be written, because the linker will find a 'main' > function in libSDLmain.a which expects a function 'SDL_main' as an entry > point into the user code. > > I have written a small c file that can be used to wrap around any > haskell module (see below), based on the macro (cpp) definition of > MODNAME. I can compile this c file with gcc, for, let's say a module Foo > with entry point Foo.bar (so, if we could still have ghc make the entry > point, we would say ghc -main-is Foo.bar): > > gcc -c -DMODNAME=Foo -D"ENTRYPOINT=bar();" -o Foo_entry.o entry.c > > However, this only works after I explicitly add ghc's "include" dir to > my search path so that HsFFI.h can be found. Before I had this > pre-processor trick, I could simply feed the c file to ghc, together > with all my haskell files. Ghc then simply adds the correct includes and > feeds the c file to the c compiler. Unfortunately, giving ghc the above > -D options doesn't do much good. > > The problem seems to lie with the suffix recognition ghc does. I took > this from [1]. With the -cpp switch, the c pre-processor is used, but > only when the file has a .hs suffix. The c compiler is only run when the > file has a .c suffix. Using -x .hs puts the file correctly through the c > pre-processor, but then fails to compile it, because it's not haskell > code. Using -x .c doesn't do pre-processing (even with -cpp). I tried to > compile this wrapper using this command (assume now that we have > Foo.hsMain as an entry point): > > ghc -cpp -pgmP cc -optP-E -DMODNAME=Foo -o Foo_entry.o entry.c > > (Notice that you can't just use cpp, because on OS X that's a shell > script that doesn't provide CPPs full strength, so you want "cc -E".) > This doesn't work: > > entry.c:27:2: error: #error MODNAME undefined! > > Trying to be more explicit as to where the -D should go: > > ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o entry.c > > does exactly the same. Now faking .hs: > > ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o -x hs entry.c > > which produces the error (coming from stdio.h inclusion): > > /usr/include/i386/_types.h:37:28: parse error on input `;' > > So, I guess my question is: Is it possible to let a c input file of ghc > pass through *both* the c pre-processor *and* the c compiler? Maybe I'm missing something, but what's wrong with ghc -c -optc-DMODNAME=Foo -o Foo_entry.o entry.c Cheers, Simon From marlowsd at gmail.com Thu Apr 30 06:40:58 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 30 06:26:46 2009 Subject: Threads and memory management In-Reply-To: <49F72E10.9080805@imn.htwk-leipzig.de> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> <49F58546.6060707@gmail.com> <49F72E10.9080805@imn.htwk-leipzig.de> Message-ID: <49F9803A.1070207@gmail.com> On 28/04/2009 17:25, Johannes Waldmann wrote: > Thanks for your comments. > > >> Check whether it is GC-bound by using +RTS -sstderr. > > Well yes, it does a lot of GC (there's no way for the compiler > to optimize away the list of primes) because that was the point > of the example: to confirm (or disprove) > that GC hurts parallelism (at the moment). > > > INIT time 0.00s ( 0.00s elapsed) > MUT time 13.23s ( 7.98s elapsed) > GC time 14.12s ( 14.11s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 27.35s ( 22.09s elapsed) > > %GC time 51.6% (63.9% elapsed) > > >> Try a recent HEAD snapshot if you can, or wait for 6.12.1. > > I did with 6.11.20090425 and it coredumps with +RTS -N2 (on x86_64) That's worrying, but I don't see a core dump here. Here are my results: GHC 6.11.20090429 -N1: INIT time 0.00s ( 0.00s elapsed) MUT time 13.52s ( 13.64s elapsed) GC time 21.25s ( 21.23s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 34.76s ( 34.87s elapsed) GHC 6.11.20090429 -N2 -qg0 -qb: INIT time 0.00s ( 0.00s elapsed) MUT time 14.40s ( 7.21s elapsed) GC time 18.35s ( 9.22s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 32.75s ( 16.44s elapsed) which, if I'm not mistaken, is super-linear speedup :-) Don't forget the -qg0 -qb flags with HEAD, these flags usually give the best parallel GC performance at the moment. For the release this might be the default, I still have to do some more experiments. Cheers, Simon From jakubuv at gmail.com Thu Apr 30 09:52:12 2009 From: jakubuv at gmail.com (Jan Jakubuv) Date: Thu Apr 30 09:38:27 2009 Subject: type checking fails with a correct type Message-ID: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> Hi, I have the following problem. Below is the smallest program I have found that shows the problem. That is why the program makes no sense (I have also meaningful but more complicated program). When I run this program in ghci: class SUBST s where empty :: s --nonsense :: SUBST s => t -> Maybe s nonsense t = case nonsense t of Nothing -> Just empty then everything is fine and I can see the type signature of `nonsense` inferred by ghci: *Main> :t nonsense nonsense :: (SUBST s) => t -> Maybe s But, when I put this signature into the code (that is, when the commented line above is uncommented) then type checking fails with the following error: Ambiguous type variable `s' in the constraint: `SUBST s' arising from a use of `nonsense' at problem-type.hs:6:18-27 Probable fix: add a type signature that fixes these type variable(s) Now, what is the problem here? Why does type checking fail with the signature that the type inference itself inferred? I am developing kind of generic interface and I don't want to fix the type `s`. I want `nonsense` to work possibly for any instance of SUBST and the concrete instance to be determined by the context where `nonsense` is used. In my original, meaningful but more complicated example I had the following error: Couldn't match expected type `STerm s' against inferred type `STerm s1' When generalising the type(s) for `refute' (this message does not provide any information where `s1` comes from) The original example shares with the above one the property that the type `s` is not mentioned in types of arguments, just in the type of a result (although, in the original example, some relation between types `t` and `s` is expressed in the type context via equality constrains on associated types (STerm from the error message) ). I tested this with ghc-6.6.1, ghc-6.10.1, ghc-6.10.2 obtaining the same result. BTW, I don't understand why but everything works fine with the following addition: nonsense' :: SUBST s => t -> Maybe s nonsense' t = case nonsense' t of Nothing -> Just empty x -> x I'll be grateful for any explanation of this issue. Sincerely, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From allbery at ece.cmu.edu Thu Apr 30 10:20:44 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 30 10:06:42 2009 Subject: type checking fails with a correct type In-Reply-To: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> References: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> Message-ID: On Apr 30, 2009, at 09:52 , Jan Jakubuv wrote: > *Main> :t nonsense > nonsense :: (SUBST s) => t -> Maybe s > > But, when I put this signature into the code (that is, when the > commented > line above is uncommented) then type checking fails with the following > error: > > Ambiguous type variable `s' in the constraint: > `SUBST s' http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html http://hackage.haskell.org/trac/ghc/ticket/1897 The type really is ambiguous according to GHC's rules, because you're missing some relationships. As I understand it (which may well be wrong), f you leave off the explicit typing it will successfully infer everything including the missing relationship; but if you explicitly type it you prevent inference of the missing relationship. -- 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/20090430/ce803a23/PGP.bin From daniel.is.fischer at web.de Thu Apr 30 11:17:42 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Apr 30 11:03:48 2009 Subject: type checking fails with a correct type In-Reply-To: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> References: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> Message-ID: <200904301717.42827.daniel.is.fischer@web.de> Am Donnerstag 30 April 2009 15:52:12 schrieb Jan Jakubuv: > Hi, > > I have the following problem. Below is the smallest program I have found > that shows the problem. That is why the program makes no sense (I have also > meaningful but more complicated program). When I run this program in ghci: > > class SUBST s where > empty :: s > > --nonsense :: SUBST s => t -> Maybe s > nonsense t = case nonsense t of > Nothing -> Just empty > > then everything is fine and I can see the type signature of `nonsense` > inferred by ghci: > > *Main> :t nonsense > nonsense :: (SUBST s) => t -> Maybe s > > But, when I put this signature into the code (that is, when the commented > line above is uncommented) then type checking fails with the following > error: > > Ambiguous type variable `s' in the constraint: > `SUBST s' > arising from a use of `nonsense' at problem-type.hs:6:18-27 > Probable fix: add a type signature that fixes these type variable(s) > > Now, what is the problem here? Why does type checking fail with the > signature that the type inference itself inferred? > In nonsense t = case nonsense t of Nothing -> Just empty , which type has the Nothing? It can have the type Maybe s1 for all s1 belonging to SUBST, that is the ambiguous type variable. > > BTW, I don't understand why but everything works fine with the following > addition: > > nonsense' :: SUBST s => t -> Maybe s > nonsense' t = case nonsense' t of > Nothing -> Just empty > x -> x > Here, Nothing must have the same type as x. Since x may be returned, x must have type Maybe s, for the type variable s of the signature, so the types are completely determined. > I am developing kind of generic interface and I don't want to fix the type > `s`. I want `nonsense` to work possibly for any instance of SUBST and the > concrete instance to be determined by the context where `nonsense` is used. > > In my original, meaningful but more complicated example I had the following > error: > > Couldn't match expected type `STerm s' > against inferred type `STerm s1' > When generalising the type(s) for `refute' > > (this message does not provide any information where `s1` comes from) Probably something like the above. To fix the error, you could use asTypeOf: nonsense :: SUBST s => t -> Maybe s nonsense t = res where res = case nonsense t `asTypeOf` res of Nothing -> Just empty or {-# LANGUAGE ScopedTypeVariables #-} nonsense :: forall s. SUBST s => t -> Maybe s nonsense t = case nonsense t :: Maybe s of Nothing -> Just empty > > The original example shares with the above one the property that the type > `s` is not mentioned in types of arguments, just in the type of a result > (although, in the original example, some relation between types `t` and `s` > is expressed in the type context via equality constrains on associated > types (STerm from the error message) ). > > I tested this with ghc-6.6.1, ghc-6.10.1, ghc-6.10.2 obtaining the same > result. > I'll be grateful for any explanation of this issue. > > Sincerely, > Jan. From dons at galois.com Thu Apr 30 13:01:35 2009 From: dons at galois.com (Don Stewart) Date: Thu Apr 30 12:48:38 2009 Subject: Threads and memory management In-Reply-To: <49F9803A.1070207@gmail.com> References: <49F1F4EE.8070306@imn.htwk-leipzig.de> <23231596.post@talk.nabble.com> <49F58546.6060707@gmail.com> <49F72E10.9080805@imn.htwk-leipzig.de> <49F9803A.1070207@gmail.com> Message-ID: <20090430170135.GC17041@whirlpool.galois.com> marlowsd: > On 28/04/2009 17:25, Johannes Waldmann wrote: >> Thanks for your comments. >> >> >>> Check whether it is GC-bound by using +RTS -sstderr. >> >> Well yes, it does a lot of GC (there's no way for the compiler >> to optimize away the list of primes) because that was the point >> of the example: to confirm (or disprove) >> that GC hurts parallelism (at the moment). >> >> >> INIT time 0.00s ( 0.00s elapsed) >> MUT time 13.23s ( 7.98s elapsed) >> GC time 14.12s ( 14.11s elapsed) >> EXIT time 0.00s ( 0.00s elapsed) >> Total time 27.35s ( 22.09s elapsed) >> >> %GC time 51.6% (63.9% elapsed) >> >> >>> Try a recent HEAD snapshot if you can, or wait for 6.12.1. >> >> I did with 6.11.20090425 and it coredumps with +RTS -N2 (on x86_64) > > That's worrying, but I don't see a core dump here. Here are my results: > > GHC 6.11.20090429 -N1: > > INIT time 0.00s ( 0.00s elapsed) > MUT time 13.52s ( 13.64s elapsed) > GC time 21.25s ( 21.23s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 34.76s ( 34.87s elapsed) > > GHC 6.11.20090429 -N2 -qg0 -qb: > > INIT time 0.00s ( 0.00s elapsed) > MUT time 14.40s ( 7.21s elapsed) > GC time 18.35s ( 9.22s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 32.75s ( 16.44s elapsed) > > which, if I'm not mistaken, is super-linear speedup :-) > > Don't forget the -qg0 -qb flags with HEAD, these flags usually give the > best parallel GC performance at the moment. For the release this might > be the default, I still have to do some more experiments. I've added this interesting bit of info to the par perf. wiki: http://haskell.org/haskellwiki/Performance/Parallel From ml at isaac.cedarswampstudios.org Thu Apr 30 13:08:15 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Apr 30 12:54:05 2009 Subject: type checking fails with a correct type In-Reply-To: References: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> Message-ID: <200904301308.15325.ml@isaac.cedarswampstudios.org> Brandon S. Allbery KF8NH wrote: > On Apr 30, 2009, at 09:52 , Jan Jakubuv wrote: > > *Main> :t nonsense > > nonsense :: (SUBST s) => t -> Maybe s > > > > But, when I put this signature into the code (that is, when the > > commented > > line above is uncommented) then type checking fails with the following > > error: > > > > Ambiguous type variable `s' in the constraint: > > `SUBST s' > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html > http://hackage.haskell.org/trac/ghc/ticket/1897 > > The type really is ambiguous according to GHC's rules, because you're > missing some relationships. As I understand it (which may well be > wrong), f you leave off the explicit typing it will successfully infer > everything including the missing relationship; but if you explicitly > type it you prevent inference of the missing relationship. hmm, strange, is this a "feature" of Haskell-98? : The definition threatens to be polymorphic recursion. Without a type-signature, the type-checker will assume that the recursion is monomorphic and proceed accordingly. With a type-signature, the type-checker doesn't do that (so therefore it's ambiguous). -Isaac From daniel.is.fischer at web.de Thu Apr 30 13:40:16 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Apr 30 13:26:21 2009 Subject: type checking fails with a correct type In-Reply-To: <20090430162543.GC27924@lxultra2.macs.hw.ac.uk> References: <20090430135212.GA27924@lxultra2.macs.hw.ac.uk> <200904301717.42827.daniel.is.fischer@web.de> <20090430162543.GC27924@lxultra2.macs.hw.ac.uk> Message-ID: <200904301940.16369.daniel.is.fischer@web.de> Am Donnerstag 30 April 2009 18:25:43 schrieb Jan Jakubuv: > Hello Daniel, > > On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > > In > > > > nonsense t = case nonsense t of > > Nothing -> Just empty > > > > , which type has the Nothing? > > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the > > ambiguous type variable. > > thanks for the explanation. Maybe I'm starting to understand what is going > on. Now I understand it thus the call of `nonsense` inside the case > construct can potentially result in a different `SUBST`-type `s1` than the > top-level `nonsense`. That is why it has to be explicitly typed. > > But I am still not following why the type inference works fine without the > signature. Isn't it still ambiguous? Ah, that's a tricky one :) Without the type signature, the type of nonsense has to be inferred from scratch. We start with nonsense t = rhs so nonsense is a function, taking an argument of type argT, giving a result of type resT: nonsense :: argT -> resT Now we infer the type of the rhs, resT. case nonsense t of Nothing -> Just empty or, rewritten, let r = nonsense t in case r of Nothing -> Just empty now r is the result of applying nonsense to t, hence r :: resT. So Nothing has type resT. Since Nothing :: forall a. Maybe a, we can now deduce resT === Maybe b for some b we don't know anything about yet. In case r matches Nothing, the result is (Just empty), so b is the type of empty. empty has type (SUBST s => s), giving resT === SUBST s => Maybe s and nonsense :: SUBST s => argT -> Maybe s *Now* the free type variables are quantified, giving nonsense :: forall argT s. SUBST s => argT -> Maybe s Since in Haskell, type variables are implicitly universally quantified, the "forall argT s." part isn't necessary and not displayed. Here comes the snag: If you give the (implicitly universally quantified) type signature, you explicitly say that nonsense can return a value of type Maybe s, whatever s is, as long as it's a member of SUBST. But then the type-checker cannot assume that r and Just empty have the same type, thus it sees let r = nonsense t , from which it finds r :: forall s1. SUBST s1 => Maybe s1 on the other hand, it finds Just empty :: forall s2. SUBST s2 => Maybe s2, giving nonsense the ambiguous type nonsense :: forall t s1 s2. (SUBST s1, SUBST s2) => t -> Maybe s2 You can ask GHC by compiling the module without the type signature and with the flag -ddump-simpl , the relevant part of the core is: ================================================================== Nonsense.nonsense :: forall t_agD s_agJ. (Nonsense.SUBST s_agJ) => t_agD -> Data.Maybe.Maybe s_agJ [GlobalId] [Arity 2] Nonsense.nonsense = \ (@ t_agD) -- type of argument (@ s_agJ) -- type of result is (Maybe s_agJ) ($dSUBST_agL :: Nonsense.SUBST s_agJ) -- SUBST dictionary for s_agJ (eta_shh :: t_agD) -> letrec { nonsense1_agA :: t_agD -> Data.Maybe.Maybe s_agJ -- inner nonsense, the type is fixed as that at which the outer nonsense is called, -- there is *no* forall here! [Arity 1] nonsense1_agA = \ (t_afx :: t_agD) -> case nonsense1_agA t_afx of wild_Xk { Data.Maybe.Nothing -> Data.Maybe.Just @ s_agJ ($dSUBST_agL `cast` ((Nonsense.:Co:TSUBST) s_agJ :: (Nonsense.:TSUBST) s_agJ ~ s_agJ)); Data.Maybe.Just ipv_shd -> Control.Exception.Base.patError @ (Data.Maybe.Maybe s_agJ) "Nonsense.hs:(16,13)-(17,36)|case" }; } in nonsense1_agA eta_shh ================================================================== > > > {-# LANGUAGE ScopedTypeVariables #-} > > > > nonsense :: forall s. SUBST s => t -> Maybe s > > nonsense t = case nonsense t :: Maybe s of > > Nothing -> Just empty > > Great, ScopedTypeVariables is exactly what I was looking for. It solves all > my problems. Great :D > > Thank you, > Jan. Cheers, Daniel From jakubuv at gmail.com Thu Apr 30 13:45:04 2009 From: jakubuv at gmail.com (Jan Jakubuv) Date: Thu Apr 30 13:31:00 2009 Subject: type checking fails with a correct type Message-ID: <20090430174504.GA6250@lxultra2.macs.hw.ac.uk> Hello Daniel, On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > In > > nonsense t = case nonsense t of > Nothing -> Just empty > > , which type has the Nothing? > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the ambiguous type > variable. > thanks for the explanation. Maybe I'm starting to understand what is going on. Now I understand it thus the call of `nonsense` inside the case construct can potentially result in a different `SUBST`-type `s1` than the top-level `nonsense`. That is why it has to be explicitly typed. But I am still not following why the type inference works fine without the signature. Isn't it still ambiguous? > > {-# LANGUAGE ScopedTypeVariables #-} > > nonsense :: forall s. SUBST s => t -> Maybe s > nonsense t = case nonsense t :: Maybe s of > Nothing -> Just empty > Great, ScopedTypeVariables is exactly what I was looking for. It solves all my problems. Thank you, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From jakubuv at gmail.com Thu Apr 30 13:46:10 2009 From: jakubuv at gmail.com (Jan Jakubuv) Date: Thu Apr 30 13:32:07 2009 Subject: type checking fails with a correct type Message-ID: <20090430174610.GB6250@lxultra2.macs.hw.ac.uk> On Thu, Apr 30, 2009 at 10:20:44AM -0400, Brandon S. Allbery KF8NH wrote: > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html > http://hackage.haskell.org/trac/ghc/ticket/1897 > Thanks for your answer and these links. Although the issue discussed there is more related to type families which were not used in my example, it was still helpful for me. At least now I know about the "show . read" problem ;-) Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From petersen at haskell.org Thu Apr 30 22:26:11 2009 From: petersen at haskell.org (Jens Petersen) Date: Thu Apr 30 22:11:50 2009 Subject: runghc failing sometimes on Linux/ppc? In-Reply-To: <20090425144316.GB26881@matrix.chaos.earth.li> References: <9436bffe0904250317x62673ea1v5cdf0f34509b1052@mail.gmail.com> <20090425144316.GB26881@matrix.chaos.earth.li> Message-ID: <9436bffe0904301926m47bfd76dp6d6e347c8cade96f@mail.gmail.com> 2009/4/26 Ian Lynagh : > Are you using a registerised build? If so, then as PPC/Linux isn't a > tier 1 platform, it could well have bitrotted. So Fedora should build ppc unregistered? Is that what other distros are doing? :) >> http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log : > These don't seem to contain the output. There is no output. :) jens