From ajb at spamcop.net Thu May 1 03:46:20 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu May 1 03:40:44 2008 Subject: Unexpected lack of optimisation In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C4AAA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0804281413q3bb1b9d1y100560d0592103f9@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE543A2BB@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0804290458k739a2b00n26d8201bd7ed7fa6@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE543A6C6@EA-EXMSG-C334.europe.corp.microsoft.com> <20080429203357.7j5knbel4ckc8wos-nwo@fcnzpbc.arg@webmail.spamcop.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C4AAA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080501034620.7li5fwu05cwgwkko-nwo@fcnzpbc.arg@webmail.spamcop.net> G'day all. Quoting Simon Peyton-Jones : > Interesting thought. I think you're describing a possible extension > to the SpecConstr transformation described in "Call pattern > specialisation for Haskell" Without reading the paper, that sounds right to me. > Here 'x' is free in 'g', but x's value is known at g's call sites. > It's not enough just to know "x is a cons" inside g; we must also > have access to z,zs. I would have thought that GHC already optimised this in a separate pass. Doesn't it do some kind of redundant case test elimination? > And it's arguably a bad shortcoming that currently the mere act of > lambda lifting can affect how effective SpecConstr is. Indeed. It also suggests to me that perhaps lambda lifting the pattern matching "retries" might _always_ be a good idea, given that the programmer has no way of controlling inlining for this kind of intermediately-generated function. Cheers, Andrew Bromage From gwright at comcast.net Thu May 1 08:59:12 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu May 1 08:53:37 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <20080426205802.GA17765@matrix.chaos.earth.li> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> Message-ID: <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> On Apr 26, 2008, at 4:58 PM, Ian Lynagh wrote: > On Thu, Apr 24, 2008 at 09:25:26AM -0400, Gregory Wright wrote: >> >> I'll see if I can come up with a patch to the build system that >> avoids >> this. > > I think that this was actually done a while ago: > > [pass -no-user-package-conf to ghc-inplace > Simon Marlow **20080104162840] { > > > Thanks > Ian I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf flag. Wouter, could you check if this fixes the problem you had? bw, Greg From simonpj at microsoft.com Thu May 1 10:21:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 10:15:37 2008 Subject: instance export decls In-Reply-To: <20080422123244.GA18149@scico.botik.ru> References: <20080422123244.GA18149@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists module Foo( data T (f :: * -> *), instance Functor f => Eq (T f), g :: T f -> T f ) The first step is to evolve a well-worked-out design. I think that'd be a very valuable thing for someone to do. Indeed, I'd really like to see it in Haskell', but it doesn't meet the "tried and tested" criterion. I'm a bit reluctant to invest effort in half-way-house solutions, though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 22 April 2008 13:33 | To: glasgow-haskell-users@haskell.org | Subject: instance export decls | | Dear GHC developers, people, | | Do you agree that there exists such a problem for a programmer as | recalling exported instances? | Have Haskell and/or GHC some constructs and tools to help the programmer | to recall the exported instances for a module? | Could GHC support the instance export messages for each module? | | In Haskell-98, the exported instances cannot be named explicitly in the | export list. | Right? | But for easier understanding of a program, it is desirable to allow to | name (in a short form) instances in the export list. | For this reason, I add comments, and write the export like this: | | module Poly | (WithHead(..), WithTail(..), -- classes | Mon(..), Polynomial(..), | lc, polMons | -- , instances | -- for Mon: WithHead, List; | -- for Polynomial: WithHead, Cast Polynomial Mon | ) | The comment of kind "-- , instances ..." | helps to recall which instances are exported, without inspecting all | the (lengthy) module source. | | But when the programmer changes the source, one often forgets to | add/remove the needed comments about instances. | I often forget them (maybe, lazy to recall) when I move pieces of code | between modules. | | So, I suggest the following feature for GHC. | | 1. To allow the export declarations of kind instance {} | (maybe to suggest this for Haskell ?) | 2. If the module under compilation has the word `instance' in its | export list, | then ghc finds the difference set diff for the exported instance | kinds eKinds and the instance kinds nKinds named in the export | list. If not $ null diff, it issues the message: | "Warning: the exported instance kinds and the instance kinds named | in the export differ in the following items: ...". | | Seeing such a message, the user corrects the export list in the source | according to diff. | | For the export list and for their messages, it is probably better to | use a short denotation: the instance kind rather than full instance | declaration. In the instance kind, the part of "(...) =>" is skipped. | | What people think of this suggestion? | | Thank you in advance for your notes and help, | | ----------------- | Serge Mechveliani | mechvel@botik.ru From wss at Cs.Nott.AC.UK Thu May 1 11:50:38 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Thu May 1 11:45:03 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> Message-ID: On 1 May 2008, at 13:59, Gregory Wright wrote: > > I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf > flag. Wouter, could you check if this fixes the problem you had? I tried a "port selfupdate" and "port clean --all ghc", followed by a "port install ghc". I ran into the error below (seems like another file-locking bug). I Bjorn's advice (getting rid of the .ghc directory) - the build went through smoothly. I'm not sure what's going on here. Hope this helps, Wouter ---> Fetching ghc ---> Attempting to fetch ghc-6.8.2-src.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Attempting to fetch ghc-6.8.2-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Attempting to fetch ghc-6.8.2-darwin-i386-leopard- bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all ---> Staging ghc into destroot Error: Target org.macports.destroot returned: shell command "cd /opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2 && make install" returned error 2 Command output: Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/hpc-0.5.0.0 Registering hpc-0.5.0.0... if ifBuildable/ifBuildable template-haskell; then \ cd template-haskell && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/template-haskell-2.2.0.0 Registering template-haskell-2.2.0.0... if ifBuildable/ifBuildable readline; then \ cd readline && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/readline-1.0.1.0 Registering readline-1.0.1.0... if ifBuildable/ifBuildable Cabal; then \ cd Cabal && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/Cabal-1.2.3.0 installPackage: copyFile: resource busy (file is locked) make[1]: *** [install.library.Cabal] Error 1 make: *** [install] Error 1 Error: Status 1 encountered during processing. From mechvel at botik.ru Thu May 1 12:31:40 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 1 12:27:48 2008 Subject: instance export decls In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080501163140.GA32180@scico.botik.ru> On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > Indeed! I think it'd be good to allow type signatures, including > instance signatures, in export lists > > module Foo( > data T (f :: * -> *), > instance Functor f => Eq (T f), > g :: T f -> T f > ) > > The first step is to evolve a well-worked-out design. I think that'd be > a very valuable thing for someone to do. Indeed, I'd really like to > see it in Haskell', but it doesn't meet the "tried and tested" criterion. Maybe, the GHC developers will first try it in GHC ? > I'm a bit reluctant to invest effort in half-way-house solutions, though. My idea was that the GHC developers may like to convert my suggestion into a carefully designed one and to implement it. > | Behalf Of Serge D. Mechveliani > | Sent: 22 April 2008 13:33 > | To: glasgow-haskell-users@haskell.org > | Subject: instance export decls > | > | Dear GHC developers, people, > | > | Do you agree that there exists such a problem for a programmer as > | recalling exported instances? > | Have Haskell and/or GHC some constructs and tools to help the programmer > | to recall the exported instances for a module? > | Could GHC support the instance export messages for each module? > | > | In Haskell-98, the exported instances cannot be named explicitly in the > | export list. > | Right? > | But for easier understanding of a program, it is desirable to allow to > | name (in a short form) instances in the export list. > | For this reason, I add comments, and write the export like this: > | > | module Poly > | (WithHead(..), WithTail(..), -- classes > | Mon(..), Polynomial(..), > | lc, polMons > | -- , instances > | -- for Mon: WithHead, List; > | -- for Polynomial: WithHead, Cast Polynomial Mon > | ) > | The comment of kind "-- , instances ..." > | helps to recall which instances are exported, without inspecting all > | the (lengthy) module source. > | > | But when the programmer changes the source, one often forgets to > | add/remove the needed comments about instances. > | I often forget them (maybe, lazy to recall) when I move pieces of code > | between modules. > | > | So, I suggest the following feature for GHC. > | > | 1. To allow the export declarations of kind instance {} > | (maybe to suggest this for Haskell ?) > | 2. If the module under compilation has the word `instance' in its > | export list, > | then ghc finds the difference set diff for the exported instance > | kinds eKinds and the instance kinds nKinds named in the export > | list. If not $ null diff, it issues the message: > | "Warning: the exported instance kinds and the instance kinds named > | in the export differ in the following items: ...". > | > | Seeing such a message, the user corrects the export list in the source > | according to diff. > | > | For the export list and for their messages, it is probably better to > | use a short denotation: the instance kind rather than full instance > | declaration. In the instance kind, the part of "(...) =>" is skipped. > | > | What people think of this suggestion? > | > | Thank you in advance for your notes and help, > | > | ----------------- > | Serge Mechveliani > | mechvel@botik.ru > From gwright at comcast.net Fri May 2 08:47:40 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri May 2 08:42:01 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> Message-ID: <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> Hi Wouter, On May 1, 2008, at 11:50 AM, Wouter Swierstra wrote: > > On 1 May 2008, at 13:59, Gregory Wright wrote: >> >> I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf >> flag. Wouter, could you check if this fixes the problem you had? > > I tried a "port selfupdate" and "port clean --all ghc", followed by > a "port install ghc". I ran into the error below (seems like another > file-locking bug). > > I Bjorn's advice (getting rid of the .ghc directory) - the build > went through smoothly. > > I'm not sure what's going on here. Hope this helps, > > Wouter > > ---> Fetching ghc > '/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ > doc/ghc/libraries/$pkg' ; \ > fi > Installing: /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ > ghc-6.8.2/lib/Cabal-1.2.3.0 > installPackage: copyFile: resource busy (file is locked) > > make[1]: *** [install.library.Cabal] Error 1 > make: *** [install] Error 1 > > Error: Status 1 encountered during processing. Hmmm. If I understand correctly, doing a "port selfupdate" and "port clean --all" gave a locking bug, but after you deleted .ghc, everything worked properly? The locking bug looks like #2134, which is fixed by a patch in Macports' ghc-6.8.2. The patch strictifies a readFile invocation in Cabal, so probably you were still using the out-of-date Cabal installed as a user package. There are two possible causes: either -no-user-package-conf has a bug and doesn't always work right, or you still have the previous revision of the ghc port, before the -no- user-package-conf patch. The latter can happen if there was some problem on the Macports server that delayed indexing the new portfile and serving it as a selfupdate. Can you do a "port installed ghc" and verify that you have revision 3? Best WIshes, Greg From john at repetae.net Fri May 2 18:03:14 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 17:57:34 2008 Subject: instance export decls In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502220314.GB21252@sliver.repetae.net> On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > Indeed! I think it'd be good to allow type signatures, including > instance signatures, in export lists The problem with instance signatures is that it would give the impression that it would be possible to _not_ export an instance, and it wouldn't make explicit the fact that the instances of all modules it depends on are also exported. John -- John Meacham - ?repetae.net?john? From mechvel at botik.ru Sat May 3 08:33:32 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat May 3 08:29:37 2008 Subject: instance export decls In-Reply-To: <20080502220314.GB21252@sliver.repetae.net> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502220314.GB21252@sliver.repetae.net> Message-ID: <20080503123332.GA411@scico.botik.ru> On Fri, May 02, 2008 at 03:03:14PM -0700, John Meacham wrote: > On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > > Indeed! I think it'd be good to allow type signatures, including > > instance signatures, in export lists > > The problem with instance signatures is that it would give the > impression that it would be possible to _not_ export an instance, and it > wouldn't make explicit the fact that the instances of all modules it > depends on are also exported. Yes. Still, listing instances in export makes it possible not to look through all the source module in order to recall the instances defined in this module. ----------- Mechveliani From simonpj at microsoft.com Tue May 6 05:09:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 6 05:03:26 2008 Subject: Warnings about unused variables or imports In-Reply-To: References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> [Moving to GHC users: this thread concerns GHC's warning messages about unused things.] | But there are a few other inconvenient behaviors related only to | warnings, for instance | | module A where | foo x = x | | module B(foo) where | import A | | module C (module A, module B) where | import A | import B | | %> ghc --make C.hs -W: | | C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' | | That's certainly true, but it's the same 'foo'. Just a warning of | course, and I'm not so sure I would argue that it shouldn't be there. | It's the same kind of warning as with any other multiple export of a | symbol I guess. But this pattern is not uncommon (in my code at | least), so the warning is inconvenient. Then again, that particular | warning can be turned off. Here the original intention was to warn about module C( foo, foo ) where... or perhaps module C( module A, foo ) where... but I agree that in the situation you describe the warning is silly. File a ticket for it? | Another, somewhat stranger, behavior: | | module A where | foo x = x | | module B(foo) where | import A | | module C(foo) where | import A | | module D () where | import B | import C | bar x = foo x | | %> ghc --make D.hs -W | | D.hs:2:0: | Warning: Module `B' is imported, but nothing from it is used, | except perhaps instances visible in `B' | To suppress this warning, use: import B() | | D.hs:3:0: | Warning: Module `C' is imported, but nothing from it is used, | except perhaps instances visible in `C' | To suppress this warning, use: import C() | | D.hs:4:0: Warning: Defined but not used: `bar' | | This might be said to be a bug, although it's a bug that would rarely | bite you, since it requires that 'bar' is not exported (or used in | something that is exported). If you export bar, then the warning talks | only of B - which is a rather arbitrary choice. There is something more substantial here. Suppose we have module Foo( g ) where import Bar( f4 ) f1 = f2 f2 = f3 f3 = f4 g = 7 At the moment GHC takes the view that f1,f2,f3,f4, and the import are *all* unused. If we said that just f1 was unused, then you'd delete it and get a new warning about f2; you delete that and get a new warning about f3; and so on. Yet the current behaviour is clearly confusing, even to a clued-up user, let alone a beginner. I'm starting to think that we should just do the obvious thing: report something as unused only if it physically does not occur. Any opinions? Your message also objects to arbitrarily choosing one of the imports as redundant. But if there are two imports import B import C and only one is needed, what would you like GHC to say? It's pretty hard to say "only one of these is needed", because it might be "of these three import declarations, you need 1&2 or 2&3 or 1&3". Simon From duncan.coutts at worc.ox.ac.uk Tue May 6 05:31:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 05:24:20 2008 Subject: Warnings about unused variables or imports In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1210066275.30059.309.camel@localhost> On Tue, 2008-05-06 at 10:09 +0100, Simon Peyton-Jones wrote: > There is something more substantial here. Suppose we have > > module Foo( g ) where > import Bar( f4 ) > f1 = f2 > f2 = f3 > f3 = f4 > g = 7 > > At the moment GHC takes the view that f1,f2,f3,f4, and the import are > *all* unused. If we said that just f1 was unused, then you'd delete > it and get a new warning about f2; you delete that and get a new > warning about f3; and so on. > > Yet the current behaviour is clearly confusing, even to a clued-up > user, let alone a beginner. Perhaps to eliminate the confusion we just need to distinguish directly unused and indirectly unused in the warning message: Foo.hs:3:8: Warning: Defined but not used: `f1' Foo.hs:4:8: Warning: Defined but used only by other things that are themselves unused: `f2' Foo.hs:5:8: Warning: Defined but used only by other things that are themselves unused: `f3' (suggestions for better messages text welcome) and similarly for the unused import. Duncan From wss at Cs.Nott.AC.UK Tue May 6 05:38:19 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Tue May 6 05:33:09 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> Message-ID: <39F9436B-7935-46F5-8F47-7321EED5F626@Cs.Nott.AC.UK> Hi Greg, On 2 May 2008, at 13:47, Gregory Wright wrote: > Hmmm. If I understand correctly, doing a "port selfupdate" and > "port clean --all" > gave a locking bug, but after you deleted .ghc, everything worked > properly? Yes. I wouldn't worry about it too much. Somehow the problem only pops up if you have an existing ghc installation and a newish Cabal. And even then, there's an easy fix. > Can you do a "port installed ghc" and verify that you have revision 3? The following ports are currently installed: ghc @6.8.2_3+darwin_9_i386 (active) That looks ok to me... Thanks again for your help! Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From hp at rentec.com Tue May 6 15:00:59 2008 From: hp at rentec.com (HP Wei) Date: Tue May 6 14:55:08 2008 Subject: large binary footprint ? Message-ID: machine: Sun Sparc, with SunOS 5.10 ghc version --- 6.8.2 [ solaris-binaries downloaded from ghc site ] The Question: I compiled the code: putStr "Hello World!\n" ghc -o hello -L../lib hello.hs where ../lib contains the libgmp.so The resulting binary code size is 3.9 Mbytes I had the impression that it should be of the order of 500 Kbytes. How can I reach that number ? Thanks HP From bulat.ziganshin at gmail.com Tue May 6 14:41:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 6 15:15:05 2008 Subject: large binary footprint ? In-Reply-To: References: Message-ID: <324117814.20080506224106@gmail.com> Hello HP, Tuesday, May 6, 2008, 11:00:59 PM, you wrote: > The resulting binary code size is 3.9 Mbytes > I had the impression that it should be of the order > of 500 Kbytes. How can I reach that number ? strip executable. you can just add -optl-s to ghc cmdline -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From hp at rentec.com Tue May 6 15:26:10 2008 From: hp at rentec.com (HP Wei) Date: Tue May 6 15:20:27 2008 Subject: large binary footprint ? In-Reply-To: <324117814.20080506224106@gmail.com> References: <324117814.20080506224106@gmail.com> Message-ID: hi Bulat, thanks for the speedy reply! I tried the following two ways and got the same result: (1) in the shell, strip hello (2) ghc -optl-s -o hello -L../lib hello.hs They both result in a binary size of ~2.5MBytes, which is about 5 times what I expected (500kbytes). Have I had the 'incorrect impression' of 500kbytes ? Thanks hp On Tue, 6 May 2008, Bulat Ziganshin wrote: > Hello HP, > > Tuesday, May 6, 2008, 11:00:59 PM, you wrote: > > > The resulting binary code size is 3.9 Mbytes > > I had the impression that it should be of the order > > of 500 Kbytes. How can I reach that number ? > > strip executable. you can just add -optl-s to ghc cmdline > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From bulat.ziganshin at gmail.com Tue May 6 15:10:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 6 15:36:33 2008 Subject: large binary footprint ? In-Reply-To: References: <324117814.20080506224106@gmail.com> Message-ID: <1368172200.20080506231021@gmail.com> Hello HP, Tuesday, May 6, 2008, 11:26:10 PM, you wrote: my haskell-fu ends here :) on win32 platform, hello is about 600k, afair > hi Bulat, thanks for the speedy reply! > I tried the following two ways and got the same result: > (1) in the shell, > strip hello > (2) ghc -optl-s -o hello -L../lib hello.hs > They both result in a binary size of ~2.5MBytes, > which is about 5 times what I expected (500kbytes). > Have I had the 'incorrect impression' of 500kbytes ? > Thanks > hp > On Tue, 6 May 2008, Bulat Ziganshin wrote: >> Hello HP, >> >> Tuesday, May 6, 2008, 11:00:59 PM, you wrote: >> >> > The resulting binary code size is 3.9 Mbytes >> > I had the impression that it should be of the order >> > of 500 Kbytes. How can I reach that number ? >> >> strip executable. you can just add -optl-s to ghc cmdline >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From alexander.fuchs at uni-koblenz.de Wed May 7 10:25:04 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Wed May 7 10:19:11 2008 Subject: Performance: Faster to define a function writing out all arguments? Message-ID: <4821BBC0.5040601@uni-koblenz.de> Hi there, I am trying to write my first serious Haskell program, but have problems understanding 'strange' performance results. It seems to be a ghc specific question, so I am asking here. In a happy parser I have this code 1): %monad { Parsed } { thenP } { returnP } type Parsed = State Env.Env returnP :: a -> Parsed a returnP a = return a thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP x k = x >>= k An alternative was this 2) (yes, redundant in happy): returnP :: a -> Parsed a returnP = return thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP = (>>=) And strangely enough on my machine 1) is faster by a few percent than 2) using ghc 6.8.2 with -O2. A few percent might seem unimportant, but I am currently developing my Haskell style. And I want to write efficient code by default, if that doesn't lead to obfuscation. Now, first I dislike using option 1) because it seems pointlessly verbose. Second, I have no clue why option 2) should be faster. Using ghc -O2 -C I get two code blocks with 1) (appended at the end of this mail), whereas I get nothing with 2. Unfortunately, that doesn't help me as I have no clue what it means. There are also various strictness annotations throughout the code to make parsing less memory hungry (and getting an intuition about what is appropriate here drives me crazy). Random guess: perhaps somehow strictness analysis of ghc benefits from the code in 1)? Or does ghc create specialized versions of return and >>= for State instantiated to Parsed, i.e. State Env.Env? Anyhow, I am puzzled and grateful for any explanations and recommendations about what is going on and when to avoid style 2). Thanks, Alexander C-- code blocks: ------------------------------------------------------- EI_(DarwinziTptpziParser_a106_info); StgWord DarwinziTptpziParser_a106_closure[] = { (W_)&DarwinziTptpziParser_a106_info }; static StgWord s8Ey_info[] = { 0x42U, 0x22U }; IF_(s8Ey_ret) { W_ _c8EL; FB_ Sp[2] = *((P_)(R1.w+7)); _c8EL = *((P_)(R1.w+3)); R1.w = Sp[1]; Sp[1] = _c8EL; Sp=Sp+1; JMP_((W_)&stg_ap_pp_fast); FE_ } StgWord DarwinziTptpziParser_a106_info[] = { 0x30014U, 0x0, 0xfU }; EI_(DarwinziTptpziParser_a106_closure); II_(s8Ey_info); FN_(DarwinziTptpziParser_a106_entry) { FB_ if ((W_)(((W_)Sp - 0x4U) < (W_)SpLim)) goto _c8EO; R1.w = *Sp; Sp[-1] = Sp[2]; *Sp = (W_)&s8Ey_info; Sp=Sp-1; JMP_((W_)&stg_ap_p_fast); _c8EO: R1.w = (W_)&DarwinziTptpziParser_a106_closure; JMP_(stg_gc_fun); FE_ } ------------------------------------------------------- ------------------------------------------------------- II_(r6AT_info); static StgWord r6AT_closure[] = { (W_)&r6AT_info, 0x0, 0x0, 0x0 }; static char c97W_str[] = "Internal Happy error\012"; static StgWord r6AT_info[] = { 0x0, 0x16U }; EI_(base_GHCziBase_unpackCStringzh_info); IF_(r6AT_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c97Z; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c97Z; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; Sp[-3] = (W_)&c97W_str; Sp=Sp-3; JMP_((W_)&base_GHCziBase_unpackCStringzh_info); _c97Z: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } EI_(base_GHCziErr_error_closure); II_(r6AT_closure); StgWord DarwinziTptpziParser_notHappyAtAll_srt[] = { (W_)&base_GHCziErr_error_closure, (W_)&r6AT_closure }; EI_(DarwinziTptpziParser_notHappyAtAll_info); StgWord DarwinziTptpziParser_notHappyAtAll_closure[] = { (W_)&DarwinziTptpziParser_notHappyAtAll_info, 0x0, 0x0, 0x0 }; StgWord DarwinziTptpziParser_notHappyAtAll_info[] = { ((W_)&DarwinziTptpziParser_notHappyAtAll_srt+0), 0x0, 0x30016U }; EI_(base_GHCziErr_error_closure); II_(r6AT_closure); FN_(DarwinziTptpziParser_notHappyAtAll_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c989; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c989; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; R1.w = (W_)&base_GHCziErr_error_closure; Sp[-3] = (W_)&r6AT_closure; Sp=Sp-3; JMP_((W_)&stg_ap_p_fast); _c989: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } ------------------------------------------------------- From hp at rentec.com Wed May 7 17:04:41 2008 From: hp at rentec.com (HP Wei) Date: Wed May 7 16:58:46 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: I convinced myself that the ~500kbytes for the 'hello' code is 'correct' in version 6.6.1. [ The exact size on the platform mentioned below is 422k. ] Looks like version 6.8.2 blows up the binary code size significantly --- 3.9Mbytes vs 0.422Mbytes. Is this a known issue with 6.8.2 ? Is it a specific platform dependent issue --- i.e. does it occur on linux machines ?? --hp On Tue, 6 May 2008, HP Wei wrote: > > machine: Sun Sparc, with SunOS 5.10 > ghc version --- 6.8.2 [ solaris-binaries downloaded from ghc site ] > > The Question: > > I compiled the code: putStr "Hello World!\n" > ghc -o hello -L../lib hello.hs > where ../lib contains the libgmp.so > > The resulting binary code size is 3.9 Mbytes > I had the impression that it should be of the order > of 500 Kbytes. How can I reach that number ? > > Thanks > HP > > > From hp at rentec.com Wed May 7 17:20:10 2008 From: hp at rentec.com (HP Wei) Date: Wed May 7 17:14:14 2008 Subject: problem with concurrent port scanner In-Reply-To: References: Message-ID: I cut and paste the code from http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell And compiled the resulting portscan.hs with both ghc-6.8.2 and ghc-6.6.1 on a host with Sun-Sparc [SunOS 5.10]. Besides the issue of binary-code-size blow-up with ghc-6.8.2, there is a much more serious problem with codes compiled from both 6.8.2 and 6.6.1. Here is the output of two runs. ------------------------------------------- portscan a_remote_sun_sparc_machine 1 1000 portscan: internal error: getMBlock: mmap: Bad file number (GHC version 6.6.1 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort [ note: same result for 6.8.2 ] ---------------------------------------- portscan a_remote_linux_machine 1 1000 22 ssh 111 sunrpc 513 login 514 shell 631 ------------------------------------------ Anyone knows this problem ? --hp From dons at galois.com Wed May 7 17:20:22 2008 From: dons at galois.com (Don Stewart) Date: Wed May 7 17:14:30 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: <20080507212022.GF5108@scytale.galois.com> hp: > > I convinced myself that the ~500kbytes for the > 'hello' code is 'correct' in version 6.6.1. > [ The exact size on the platform mentioned below > is 422k. ] > > Looks like version 6.8.2 blows up the binary code size > significantly --- 3.9Mbytes vs 0.422Mbytes. > > Is this a known issue with 6.8.2 ? > Is it a specific platform dependent issue --- i.e. > does it occur on linux machines ?? That's platform dependent. It means on ghc 6.8.2 wasn't built with split-objs enabled, so it includes a whole bunch of dead code normally stripped out. Consult whoever built the ghc on your platform, to ensure they know how to build with split objects. -- Don From daniel.is.fischer at web.de Wed May 7 17:24:14 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 7 17:17:10 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: <200805072324.14790.daniel.is.fischer@web.de> Am Mittwoch, 7. Mai 2008 23:04 schrieb HP Wei: > I convinced myself that the ~500kbytes for the > 'hello' code is 'correct' in version 6.6.1. > [ The exact size on the platform mentioned below > is 422k. ] > > Looks like version 6.8.2 blows up the binary code size > significantly --- 3.9Mbytes vs 0.422Mbytes. > > Is this a known issue with 6.8.2 ? > Is it a specific platform dependent issue --- i.e. > does it occur on linux machines ?? > I get 490k for hello without stripping and 274k with stripping on linux. It might be the "-L../lib" option which blows up the binary size. What happens if you just ghc --make hello ? Cheers, Daniel From ndmitchell at gmail.com Thu May 8 04:41:13 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 8 04:35:15 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <4821BBC0.5040601@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> Message-ID: <404396ef0805080141j6cd8aff4y49e2b3f28a089e6e@mail.gmail.com> Hi > And strangely enough on my machine 1) is faster by a few percent than Consider a few percent to be "noise". It may not really be a faster result, and it may not have anything to do with what you wrote. > A few percent might seem unimportant, but I am > currently developing my Haskell style. And I want to write efficient code by > default, if that doesn't lead to obfuscation. Write clear code by default - GHC can usually make the leap between clear and efficient. You may want to read http://haskell.org/haskellwiki/Performance - but if you are developing your Haskell style I'd not bother yet. Thanks Neil From simonmarhaskell at gmail.com Thu May 8 07:39:14 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 8 07:33:26 2008 Subject: problem with concurrent port scanner In-Reply-To: References: Message-ID: <4822E662.5030506@gmail.com> HP Wei wrote: > I cut and paste the code from > http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell > > And compiled the resulting portscan.hs > with both ghc-6.8.2 and ghc-6.6.1 > on a host with Sun-Sparc [SunOS 5.10]. > > Besides the issue of binary-code-size blow-up with ghc-6.8.2, > there is a much more serious problem with codes > compiled from both 6.8.2 and 6.6.1. > > Here is the output of two runs. > > ------------------------------------------- > portscan a_remote_sun_sparc_machine 1 1000 > portscan: internal error: getMBlock: mmap: Bad file number > (GHC version 6.6.1 for sparc_sun_solaris2) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort Please report the bug as instructed! Cheers, Simon From dons at galois.com Thu May 8 17:40:26 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 17:34:29 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <4821BBC0.5040601@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> Message-ID: <20080508214026.GD3528@scytale.galois.com> alexander.fuchs: > Hi there, > > I am trying to write my first serious Haskell program, but have > problems understanding 'strange' performance results. It seems to be > a ghc specific question, so I am asking here. > > In a happy parser I have this code 1): > > %monad { Parsed } { thenP } { returnP } > > type Parsed = State Env.Env > > returnP :: a -> Parsed a > returnP a = return a > > thenP :: Parsed a -> (a -> Parsed b) -> Parsed b > thenP x k = x >>= k > > > An alternative was this 2) (yes, redundant in happy): > > returnP :: a -> Parsed a > returnP = return > > thenP :: Parsed a -> (a -> Parsed b) -> Parsed b > thenP = (>>=) > Could you submit a minimal, complete grammar file, so we can look at the generated code? -- Don From alexander.fuchs at uni-koblenz.de Mon May 12 11:52:04 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Mon May 12 11:46:07 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <20080508214026.GD3528@scytale.galois.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> Message-ID: <482867A4.6020102@uni-koblenz.de> Hi Don. Don Stewart wrote: > alexander.fuchs: >> >> In a happy parser I have this code 1): >> >> %monad { Parsed } { thenP } { returnP } >> >> type Parsed = State Env.Env >> >> returnP :: a -> Parsed a >> returnP a = return a >> >> thenP :: Parsed a -> (a -> Parsed b) -> Parsed b >> thenP x k = x >>= k >> >> >> An alternative was this 2) (yes, redundant in happy): >> >> returnP :: a -> Parsed a >> returnP = return >> >> thenP :: Parsed a -> (a -> Parsed b) -> Parsed b >> thenP = (>>=) >> > > Could you submit a minimal, complete grammar file, so > we can look at the generated code? After reducing and simplifying the grammar file to the minimum for my sample input I can't see any difference in performance anymore. Due to other code changes the difference is almost non-existent anymore even before simplification. I blame laziness for my lack of intuition of what is going on ;-) Anyway, as I am still wondering why ghc creates different code for returnP a = return a returnP = return I put the grammar file online, in case you still want to have a look at it: http://cs.uiowa.edu/~fuchs/DarwinCS/DarwinCS/Darwin/Tptp/Parser.y The complete source (compiles with make opt) is here: http://cs.uiowa.edu/~fuchs/DarwinCS/DarwinCS.tar.gz And I use it on this input: http://cs.uiowa.edu/~fuchs/DarwinCS/SYN854-1.p with the command line: time Darwin/Main +RTS -sstderr -RTS 600 SYN854-1.p Sorry about the noise, Alexander From kili at outback.escape.de Mon May 12 15:57:33 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon May 12 15:53:53 2008 Subject: How MD are .hi files? Message-ID: <20080512195733.GA2091@petunia.outback.escape.de> Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski From dons at galois.com Mon May 12 19:28:47 2008 From: dons at galois.com (Don Stewart) Date: Mon May 12 19:22:39 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <482867A4.6020102@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> Message-ID: <20080512232847.GO8256@scytale.galois.com> alexander.fuchs: > Hi Don. > >Could you submit a minimal, complete grammar file, so > >we can look at the generated code? > > After reducing and simplifying the grammar file to the minimum for my > sample input I can't see any difference in performance anymore. Due to > other code changes the difference is almost non-existent anymore even > before simplification. I blame laziness for my lack of intuition of what > is going on ;-) > > > Anyway, as I am still wondering why ghc creates different code for > returnP a = return a > returnP = return > Ah, now I rember this coming up before. Simon, is this a CAF issue? Or did it trigger the -fno-state-hack case? I've definitely run into the odd other case where point-freeing a bit of code messes with the complexity. -- Don From simonpj at microsoft.com Tue May 13 04:47:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 13 04:41:36 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <20080512232847.GO8256@scytale.galois.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> <20080512232847.GO8256@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> | > Anyway, as I am still wondering why ghc creates different code for | > returnP a = return a | > returnP = return | > | | Ah, now I rember this coming up before. | | Simon, is this a CAF issue? Or did it trigger the -fno-state-hack case? I'm not sure. A small example would be good. | I've definitely run into the odd other case where point-freeing | a bit of code messes with the complexity. That should not happen -- except for the state-hack. Which is this: Consider f1 :: Char -> IO () f1 = \c. let i = ord c in \s. print i s Here s::State World. Is this equivalent to f2 = \c.\s. print (ord c) s The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda. This matters a lot in I/O-intensive programs. But if 'f' is called thus: forever (f 'w') then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1. And that can make a big difference too. I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great. Simon From sedillard at gmail.com Tue May 13 19:12:30 2008 From: sedillard at gmail.com (Scott Dillard) Date: Tue May 13 19:06:15 2008 Subject: laziness, memoization and inlining Message-ID: Hi Everybody, I'm experiencing some undesirable performance behavior, I suspect from inlining things that shouldn't be, defeating my memoization attempts. I've been experimenting with purely functional 3D modeling code, so a mesh is (initially) something like > type Mesh = Map (Int,Int) (Int,Int) that is, a function from from an edge to the next edge around the face, where an edge is a pair of Ints (the vertices.) This nice and pure and everything, but its slow to read from. So I have another immutable pointer-based representation > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } which is something like a half-edge, for those familiar with such things. Its basically a big net made of circular lists that are tied together. I do the knot tying stuff to create this thing, > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int > memoMesh nexts = head $ Map.elems ties > where > ties = Map.mapWithKey (\ij _ -> make ij) nexts > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) The program first loads the model file and creates the Edge-based mesh using the memoMesh function. The result is then captured in the closure for the rendering callback in GLUT. When I compile with -O0 I see the "hello" traces only during the first drawing. Subsequent redraws are fast and output no traces. When I compile with -O1 or -O2, the traces get output on every redraw, and its very slow. I suspect all of the calls which create the mesh are inlined into the rendering callback, effectively rebuilding the mesh on every draw. I've tried littering NOINLINE pragmas all around, to no avail. The main function is something like > main = do > initGlut ... > rawMesh <- loadMeshFile ... > let > mesh = memoMesh rawMesh > otherstuff = ... > display = > draw mesh >> amongOtherThings > displayCallback $= display > glutMainLoop Can someone help me understand what's going on here? Is there a nice solution to this, hopefully a single strategic pragma or something? Scott From dons at galois.com Tue May 13 23:20:11 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 23:13:58 2008 Subject: laziness, memoization and inlining In-Reply-To: References: Message-ID: <20080514032011.GA9332@scytale.galois.com> sedillard: > Hi Everybody, > > I'm experiencing some undesirable performance behavior, I suspect from > inlining things that shouldn't be, defeating my memoization attempts. > I've been experimenting with purely functional 3D modeling code, so a > mesh is (initially) something like > > > type Mesh = Map (Int,Int) (Int,Int) > > that is, a function from from an edge to the next edge around the > face, where an edge is a pair of Ints (the vertices.) > > This nice and pure and everything, but its slow to read from. So I > have another immutable pointer-based representation > > > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } > > which is something like a half-edge, for those familiar with such > things. Its basically a big net made of circular lists that are tied > together. I do the knot tying stuff to create this thing, > > > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int > > memoMesh nexts = head $ Map.elems ties > > where > > ties = Map.mapWithKey (\ij _ -> make ij) nexts > > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties > > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) > > The program first loads the model file and creates the Edge-based mesh > using the memoMesh function. The result is then captured in the > closure for the rendering callback in GLUT. When I compile with -O0 I > see the "hello" traces only during the first drawing. Subsequent > redraws are fast and output no traces. When I compile with -O1 or -O2, > the traces get output on every redraw, and its very slow. I suspect > all of the calls which create the mesh are inlined into the rendering > callback, effectively rebuilding the mesh on every draw. Hmm. I wonder if *this* is the no-state-hack at play. Does -fno-state-hack help? > I've tried littering NOINLINE pragmas all around, to no avail. > > The main function is something like > > > main = do > > initGlut ... > > rawMesh <- loadMeshFile ... > > let > > mesh = memoMesh rawMesh > > otherstuff = ... > > display = > > draw mesh >> amongOtherThings > > displayCallback $= display > > glutMainLoop > > Can someone help me understand what's going on here? Is there a nice > solution to this, hopefully a single strategic pragma or something? Is it possible to boil this down to a program that doesn't use GL? -- Don From leledumbo_cool at yahoo.co.id Wed May 14 03:31:41 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed May 14 03:25:23 2008 Subject: small and compact ghc distribution Message-ID: <17223701.post@talk.nabble.com> Currently, GHC distribution is VERY BIG (about 410 MB). 2 Things that I noticed which contributed most of this problem are: libraries (about 220 MB) and GCC and friends compiler (including perl, ar, as, ld, etc). I'm a college student and I just want to learn functional programming with Haskell. No need to access libraries other than GHC rtl (or whatever you call it). I already have gcc on my machine, does GHC still need its own? Will there be any small and compact GHC distribution (if someone wants to make it, I'd be very grateful)? -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17223701.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From bulat.ziganshin at gmail.com Wed May 14 03:45:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 03:39:13 2008 Subject: small and compact ghc distribution In-Reply-To: <17223701.post@talk.nabble.com> References: <17223701.post@talk.nabble.com> Message-ID: <656997252.20080514114506@gmail.com> Hello leledumbo, Wednesday, May 14, 2008, 11:31:41 AM, you wrote: > I'm a college student and I just want to learn functional programming with > Haskell. No need to access libraries other than GHC rtl (or whatever you > call it). > I already have gcc on my machine, does GHC still need its own? > Will there be any small and compact GHC distribution (if someone wants to > make it, I'd be very grateful)? 1. you can use winhugs - it's more user-friendly. and need only ~10mb in stripped installation 2. you can try to delete all the unneeded libs from ghc distro. in particular, all those *_p* files are just profiling versions - you don't need them 3. i think that ghc should work without gcc at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Wed May 14 03:48:00 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 14 03:41:45 2008 Subject: laziness, memoization and inlining In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Scott | I'm experiencing some undesirable performance behavior, I suspect from | inlining things that shouldn't be, defeating my memoization attempts. This is bad, very bad. I think Don is right. I believe the following is happening. In your main program you have do let mesh = memoMesh rawMesh display :: IO () display = draw mesh >> stuff setDisplayCallback display glutMainLoop So the effect is that 'display' is performed many times, by glutMainLoop. Now 'display' is seen by GHC thus: display = \s -> draw mesh s >> stuff The "\s" says "given the state of the world, s, I'll draw the mesh on it". The "state hack" makes GHC think that a "\s" will only ever be called once (which is utterly false in this case), so it can inline mesh=memoMesh rawMesh. Result disaster. I bet you'll be fine if you compile your main module with -fno-state-hack. But I should fix this, somehow. It's coming up too often to justify the hack. Can you make a Trac bug report, and include your message and this one? Thanks for reporting it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Scott Dillard | Sent: 14 May 2008 00:13 | To: glasgow-haskell-users@haskell.org | Subject: laziness, memoization and inlining | | Hi Everybody, | | I'm experiencing some undesirable performance behavior, I suspect from | inlining things that shouldn't be, defeating my memoization attempts. | I've been experimenting with purely functional 3D modeling code, so a | mesh is (initially) something like | | > type Mesh = Map (Int,Int) (Int,Int) | | that is, a function from from an edge to the next edge around the | face, where an edge is a pair of Ints (the vertices.) | | This nice and pure and everything, but its slow to read from. So I | have another immutable pointer-based representation | | > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } | | which is something like a half-edge, for those familiar with such | things. Its basically a big net made of circular lists that are tied | together. I do the knot tying stuff to create this thing, | | > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int | > memoMesh nexts = head $ Map.elems ties | > where | > ties = Map.mapWithKey (\ij _ -> make ij) nexts | > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties | > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) | | The program first loads the model file and creates the Edge-based mesh | using the memoMesh function. The result is then captured in the | closure for the rendering callback in GLUT. When I compile with -O0 I | see the "hello" traces only during the first drawing. Subsequent | redraws are fast and output no traces. When I compile with -O1 or -O2, | the traces get output on every redraw, and its very slow. I suspect | all of the calls which create the mesh are inlined into the rendering | callback, effectively rebuilding the mesh on every draw. | | I've tried littering NOINLINE pragmas all around, to no avail. | | The main function is something like | | > main = do | > initGlut ... | > rawMesh <- loadMeshFile ... | > let | > mesh = memoMesh rawMesh | > otherstuff = ... | > display = | > draw mesh >> amongOtherThings | > displayCallback $= display | > glutMainLoop | | Can someone help me understand what's going on here? Is there a nice | solution to this, hopefully a single strategic pragma or something? | | Scott | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From leledumbo_cool at yahoo.co.id Wed May 14 04:14:35 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed May 14 04:08:20 2008 Subject: small and compact ghc distribution In-Reply-To: <656997252.20080514114506@gmail.com> References: <17223701.post@talk.nabble.com> <656997252.20080514114506@gmail.com> Message-ID: <17225910.post@talk.nabble.com> Bulat Ziganshin-2 wrote: > > 1. you can use winhugs - it's more user-friendly. and need only ~10mb > in stripped installation > That's what I'm using for now, but I need GHC's compilation capability. Bulat Ziganshin-2 wrote: > > 2. you can try to delete all the unneeded libs from ghc distro. in > particular, all those *_p* files are just profiling versions - you > don't need them > OK, I'll try. Bulat Ziganshin-2 wrote: > > 3. i think that ghc should work without gcc at all > Yes, but to scan and delete which files are belong to GHC and which are belong to GCC is quite difficult. That's why I ask for a pre-made (or pre-cleaned) one. -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17225910.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From marlowsd at gmail.com Wed May 14 06:35:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 14 06:29:23 2008 Subject: How MD are .hi files? In-Reply-To: <20080512195733.GA2091@petunia.outback.escape.de> References: <20080512195733.GA2091@petunia.outback.escape.de> Message-ID: <482AC078.6000802@gmail.com> Matthias Kilian wrote: > Hi, > > for an unregisterised ghc-6.8.2 (or newer), are the .hi files > dependent (except for the 32 vs. 64 bit word size)? I had a quick > look at the stuff in compiler/iface, but the only MD part I found > was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. First, you have to watch out for conditional compilation in the original Haskell source file. For example, if the .hs file contains something like #ifdef mingw32_HOST_OS, then the .hc and .hi files will both be Windows-only. There are certainly many instances of this in the libraries right now. Another problem is the configuration information that gets into the build via the autoconf scripts. Things like the size of C types in Foreign.C.Types, or the errno values in Foreign.C.Error might be different on the target machine. I hope I've managed to understand your question correctly... if not please ask again! Cheers, Simon From r.kelsall at millstream.com Wed May 14 10:08:51 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Wed May 14 10:02:33 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? Message-ID: <482AF273.90407@millstream.com> Hello Glasgow-Haskell Users, It was suggested to me in this thread in Haskell-Cafe http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html which was a subsidiary of a previous thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html that there might be some reason other than the -O2 optimisation level I applied to my version of splitAt that was making my program run about 30% faster than when I used the built-in splitAt. Can somebody tell me how to check what the -O level is for the built-in splitAt? Or alternatively tell me what the optimisation level is for the libraries. (Sorry I'm not sure of the right terminology for these built-in / library / Prelude things.) Richard. From sedillard at ucdavis.edu Wed May 14 11:31:08 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Wed May 14 11:24:50 2008 Subject: laziness, memoization and inlining In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon, Don, You're right. -fno-state-hack fixed it. I've opened a trac ticket. Program and test data are there. http://hackage.haskell.org/trac/ghc/ticket/2284 Scott On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones wrote: > Scott > > | I'm experiencing some undesirable performance behavior, I suspect from > | inlining things that shouldn't be, defeating my memoization attempts. > > This is bad, very bad. I think Don is right. I believe the following is happening. In your main program you have > > do let mesh = memoMesh rawMesh > display :: IO () > display = draw mesh >> stuff > setDisplayCallback display > glutMainLoop > > So the effect is that 'display' is performed many times, by glutMainLoop. > > Now 'display' is seen by GHC thus: > display = \s -> draw mesh s >> stuff > > The "\s" says "given the state of the world, s, I'll draw the mesh on it". The "state hack" makes GHC think that a "\s" will only ever be called once (which is utterly false in this case), so it can inline mesh=memoMesh rawMesh. Result disaster. > > > I bet you'll be fine if you compile your main module with -fno-state-hack. > > But I should fix this, somehow. It's coming up too often to justify the hack. Can you make a Trac bug report, and include your message and this one? > > Thanks for reporting it. > > Simon > From alexander.fuchs at uni-koblenz.de Wed May 14 12:58:11 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Wed May 14 12:52:04 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> <20080512232847.GO8256@scytale.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <482B1A23.6000307@uni-koblenz.de> Hi. Simon Peyton-Jones wrote: > | I've definitely run into the odd other case where point-freeing > | a bit of code messes with the complexity. > > That should not happen -- except for the state-hack. Which is this: > > Consider > f1 :: Char -> IO () > f1 = \c. let i = ord c in \s. print i s > > Here s::State World. Is this equivalent to > f2 = \c.\s. print (ord c) s > > The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda. This matters a lot in I/O-intensive programs. But if 'f' is called thus: > > forever (f 'w') > > then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1. And that can make a big difference too. Thanks for the explanation. State World here really means the IO and ST monad, not the State monad, right? Compiling with -fno-state-hack actually does actually lead to both versions (the point-free and explicit) being equally fast (14.4s instead of 15.2s resp. 14.0s). Though I am not sure why. Running in profiled mode makes all difference vanish. I tested this on an Intel(R) Pentium(R) 4 CPU 3.00GHz and got the reported speed difference there. Using instead an AMD Athlon(tm) 64 Processor 3800+ I got no difference even without using -fno-state-hack. > I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great. I am sorry, I completely failed to do that. The parser builds up a data structure from several data types using memoization. Any significant simplification of the code base reduced the performance gap until it quickly disappeared. Alexander From kili at outback.escape.de Wed May 14 14:38:54 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed May 14 14:33:48 2008 Subject: How MD are .hi files? In-Reply-To: <482AC078.6000802@gmail.com> References: <20080512195733.GA2091@petunia.outback.escape.de> <482AC078.6000802@gmail.com> Message-ID: <20080514183853.GB16920@petunia.outback.escape.de> On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: > >for an unregisterised ghc-6.8.2 (or newer), are the .hi files > >dependent (except for the 32 vs. 64 bit word size)? I had a quick > >look at the stuff in compiler/iface, but the only MD part I found > >was that 32/64 bit difference. > > The word size is probably the only dependency, but there are many reasons > that you can't just take the .hc/.hi files generated by an unregisterised > build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: "does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC?" Ciao, Kili [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. -- It compiles -- let's ship it! From marlowsd at gmail.com Thu May 15 05:29:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:23:36 2008 Subject: How MD are .hi files? In-Reply-To: <20080514183853.GB16920@petunia.outback.escape.de> References: <20080512195733.GA2091@petunia.outback.escape.de> <482AC078.6000802@gmail.com> <20080514183853.GB16920@petunia.outback.escape.de> Message-ID: <482C028E.9090104@gmail.com> Matthias Kilian wrote: > On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: >>> for an unregisterised ghc-6.8.2 (or newer), are the .hi files >>> dependent (except for the 32 vs. 64 bit word size)? I had a quick >>> look at the stuff in compiler/iface, but the only MD part I found >>> was that 32/64 bit difference. >> The word size is probably the only dependency, but there are many reasons >> that you can't just take the .hc/.hi files generated by an unregisterised >> build on one machine and expect them to work on another machine. > > I really don't expect this. I just decided to be lazy and provide > not only .hc files but also .hi files[1] for the OpenBSD port, and > then I thought: "does this make sense at all? Can it even be of use > for porting GHC to other archs on OpenBSD, or for the NetBSD folks > working on GHC?" Here's a message I wrote quite a while ago on this topic: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-May/008456.html some of that is out of date, but at least it describes most of the issues with having a platform-independen hc bootstrap. > [1] Of course, the correct solution would not need the .hi files, > but just use the stage1 bootstrapped from .hc files to start > rebuilding the libraries. But that would require even more hacking > on the Makefiles, and I've already an insane amount of hacks sitting > around. If the .hc files were platform independent, then the .hi files would be too, by definition. Cheers, Simon From marlowsd at gmail.com Thu May 15 05:31:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:25:16 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482AF273.90407@millstream.com> References: <482AF273.90407@millstream.com> Message-ID: <482C02F4.8050202@gmail.com> Richard Kelsall wrote: > Hello Glasgow-Haskell Users, > > It was suggested to me in this thread in Haskell-Cafe > > http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html > > which was a subsidiary of a previous thread > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html > > that there might be some reason other than the -O2 optimisation level > I applied to my version of splitAt that was making my program run about > 30% faster than when I used the built-in splitAt. > > Can somebody tell me how to check what the -O level is for the built-in > splitAt? Or alternatively tell me what the optimisation level is for > the libraries. > > (Sorry I'm not sure of the right terminology for these built-in / > library / Prelude things.) It's hard to tell what optimisation level your libraries were compiled with. The default setting is -O, but when building binary distributions we usually set it explicitly to -O2. If you got your binary from another source, they might have only used -O. Cheers, Simon From marlowsd at gmail.com Thu May 15 05:35:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:29:10 2008 Subject: laziness, memoization and inlining In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <482C03DF.9080108@gmail.com> Scott Dillard wrote: > Simon, Don, > > You're right. -fno-state-hack fixed it. I've opened a trac ticket. > Program and test data are there. > > http://hackage.haskell.org/trac/ghc/ticket/2284 Ok, but do we really need two tickets for this? Why open a new ticket rather than adding the information to the existing ticket? Cheers, Simon From bulat.ziganshin at gmail.com Thu May 15 05:54:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 05:48:01 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482C02F4.8050202@gmail.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> Message-ID: <1392674559.20080515135409@gmail.com> Hello Simon, Thursday, May 15, 2008, 1:31:32 PM, you wrote: > It's hard to tell what optimisation level your libraries were compiled > with. The default setting is -O, but when building binary distributions we > usually set it explicitly to -O2. If you got your binary from another > source, they might have only used -O. not surprising that noone answered this question in cafe :) actually, main Windows builds goes from Sigbjorn Finne afair. may be from Neil too. so we probably need to warn them that their builds may be sub-optimal? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Thu May 15 06:15:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 15 06:09:02 2008 Subject: laziness, memoization and inlining In-Reply-To: <482C03DF.9080108@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> <482C03DF.9080108@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE56A033F@EA-EXMSG-C334.europe.corp.microsoft.com> i'd forgotten there was an existing one when I asked Scott document his problem. I've cross-linked them, but equally good would be to transfer the info | -----Original Message----- | From: Simon Marlow [mailto:simonmarhaskell@gmail.com] On Behalf Of Simon Marlow | Sent: 15 May 2008 10:35 | To: Scott Dillard | Cc: Simon Peyton-Jones; Don Stewart; glasgow-haskell-users@haskell.org | Subject: Re: laziness, memoization and inlining | | Scott Dillard wrote: | > Simon, Don, | > | > You're right. -fno-state-hack fixed it. I've opened a trac ticket. | > Program and test data are there. | > | > http://hackage.haskell.org/trac/ghc/ticket/2284 | | Ok, but do we really need two tickets for this? Why open a new ticket | rather than adding the information to the existing ticket? | | Cheers, | Simon From r.kelsall at millstream.com Thu May 15 09:13:32 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Thu May 15 09:07:19 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <1392674559.20080515135409@gmail.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> <1392674559.20080515135409@gmail.com> Message-ID: <482C36FC.2010003@millstream.com> Bulat Ziganshin wrote: > Hello Simon, > >> It's hard to tell what optimisation level your libraries were compiled >> with. The default setting is -O, but when building binary distributions we >> usually set it explicitly to -O2. If you got your binary from another >> source, they might have only used -O. > > not surprising that noone answered this question in cafe :) > > actually, main Windows builds goes from Sigbjorn Finne afair. may be > from Neil too. so we probably need to warn them that their builds may > be sub-optimal? > Thanks chaps, For the record I'm using the Windows version of GHC 6.8.2 downloaded from here http://haskell.org/ghc/download_ghc_682.html MD5 is 5356a12f056a32ef35fa44db2e2204fc I just downloaded the one that's there currently and it's the same as the one I'm using which I think I downloaded in January. Richard. From stefan at cs.uu.nl Thu May 15 09:46:57 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu May 15 09:40:35 2008 Subject: Type checker loops with innocent looking associated type synonym Message-ID: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> I've written this cute ;-) piece of code involving an associated type synonym, {-# OPTIONS_GHC -fglasgow-exts #-} class ZipWithA a where type Elem a :: * zipWithA :: [Elem a] -> a instance ZipWithA [a] where type Elem [a] = a zipWithA xs = xs instance ZipWithA b => ZipWithA ([a] -> b) where type Elem ([a] -> b) = a -> Elem b zipWithA fs = zipWithA . zipWith ($) fs and it behaves as intended: *Main> zipWithA [2, 3] :: [Int] [2,3] *Main> zipWithA [pred, succ] [2, 3] :: [Int] [1,4] *Main> zipWithA [(+), (-)] [2, 3] [5, 7] :: [Int] [7,-4] However, as soon as the overloading cannot be resolved, the type checker loops: *Main> zipWithA [head, last] ["more than", "haskell"] :: String "ml" *Main> zipWithA [head, last] ["more than", "haskell"] <> Just to be clear, I do not expect GHC to be able to type this last example, I would just have thought it would want to tell me in finite time that it cannot resolve the overloading here. Should I report this a bug? Or is it perhaps already been taken care of in the head? Or am I just plain unreasonable here? :-) Cheers, Stefan From igloo at earth.li Thu May 15 10:05:15 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 15 09:58:58 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482C36FC.2010003@millstream.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> <1392674559.20080515135409@gmail.com> <482C36FC.2010003@millstream.com> Message-ID: <20080515140514.GA24952@matrix.chaos.earth.li> On Thu, May 15, 2008 at 02:13:32PM +0100, Richard Kelsall wrote: > Bulat Ziganshin wrote: > >Hello Simon, > > > >>It's hard to tell what optimisation level your libraries were compiled > >>with. The default setting is -O, but when building binary distributions > >>we > >>usually set it explicitly to -O2. If you got your binary from another > >>source, they might have only used -O. > > > >not surprising that noone answered this question in cafe :) > > > >actually, main Windows builds goes from Sigbjorn Finne afair. may be > >from Neil too The builds were always done on MSR machines, although Sigbjorn used to bundle them up into installers. These days the MSR machines make the installers too, with a script from Neil. > For the record I'm using the Windows version of GHC 6.8.2 downloaded > from here > > http://haskell.org/ghc/download_ghc_682.html I'm pretty sure that's got the libraries built with -O, although I haven't looked for the log of that actual build. We only use -O2 on the Linux builds as far as I can see, but I'm not sure there's a good reason for that. I also don't know why we don't just make our preferred settings the default in the build system; Simon? Thanks Ian From bulat.ziganshin at gmail.com Thu May 15 10:26:37 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 10:20:49 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: <969114973.20080515182637@gmail.com> Hello Stefan, Thursday, May 15, 2008, 5:46:57 PM, you wrote: > class ZipWithA a where > type Elem a :: * > Should I report this a bug? Or is it perhaps already been taken care > of in the head? Or am I just plain unreasonable here? :-) afair, the rule of thumb is: please don't report us errors with type families in 6.8 - it's unofficial and incomplete here. test against HEAD if you are really interested -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Thu May 15 14:47:20 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 14:41:01 2008 Subject: -optc-O2 considered useful Message-ID: <20080515184720.GE31635@scytale.galois.com> I discovered something today I didn't know. gcc -O2 can optimise out the computed jumps GHC produces in tight loops. Consider this program, import Data.Array.Vector import Data.Bits main = print . sumU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) Yields this core: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sMp :: Int#) (ww1_sMt :: Int#) -> case ww1_sMt of wild_X10 { __DEFAULT -> $wfold (+# ww_sMp 40) (+# wild_X10 1); 100000000 -> ww_sMp And -O2 -fasm: Main_zdwfold_info: movq %rdi,%rax cmpq $100000000,%rax jne .LcOk movq %rsi,%rbx jmp *(%rbp) .LcOk: incq %rax addq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.19s user 0.00s system 101% cpu 0.188 total -O2 -fvia-C -optc-O: Main_zdwfold_info: cmpq $100000000, %rdi jne .L3 movq %rsi, %rbx movq (%rbp), %rax .L4: jmp *%rax .L3: addq $40, %rsi leaq 1(%rdi), %rdi movl $Main_zdwfold_info, %eax jmp .L4 $ time ./sum 4000000000 ./sum 0.34s user 0.00s system 94% cpu 0.361 total Hmm. That movl, jmp .L4 ; jmp *%rax looks sucky, and performance got worse. And now with -O2 -fvia-C -optc-O2 Main_zdwfold_info: cmpq $100000000, %rdi je .L5 .L3: addq $40, %rsi leaq 1(%rdi), %rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.11s user 0.02s system 106% cpu 0.122 total Woot, back in business. -- Don From bulat.ziganshin at gmail.com Thu May 15 15:00:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 15:05:01 2008 Subject: -optc-O2 considered useful In-Reply-To: <20080515184720.GE31635@scytale.galois.com> References: <20080515184720.GE31635@scytale.galois.com> Message-ID: <1693468577.20080515230026@gmail.com> Hello Don, Thursday, May 15, 2008, 10:47:20 PM, you wrote: > I discovered something today I didn't know. > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. seems that decision to use native backend in ghc -O2 was too early? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Thu May 15 18:31:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 15 18:23:38 2008 Subject: -optc-O2 considered useful In-Reply-To: <1693468577.20080515230026@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> Message-ID: <1210890711.5824.157.camel@localhost> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: > Hello Don, > > Thursday, May 15, 2008, 10:47:20 PM, you wrote: > > > I discovered something today I didn't know. > > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. > > seems that decision to use native backend in ghc -O2 was too early? Though note that the native backend never introduced the computed jump. I think it's clear that -fvia-C -O should imply -optc-O2 if it does not already. gcc -O0 is for painfully obvious C translation into assembler, -O is for quick optimisations. gcc -O2 is the "standard" optimisation level used for building packages for most distros. Duncan From dons at galois.com Thu May 15 18:37:26 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 18:31:09 2008 Subject: -optc-O2 considered useful In-Reply-To: <1210890711.5824.157.camel@localhost> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> Message-ID: <20080515223726.GL31635@scytale.galois.com> duncan.coutts: > > On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: > > Hello Don, > > > > Thursday, May 15, 2008, 10:47:20 PM, you wrote: > > > > > I discovered something today I didn't know. > > > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. > > > > seems that decision to use native backend in ghc -O2 was too early? > > Though note that the native backend never introduced the computed jump. > > I think it's clear that -fvia-C -O should imply -optc-O2 if it does not > already. gcc -O0 is for painfully obvious C translation into assembler, > -O is for quick optimisations. gcc -O2 is the "standard" optimisation > level used for building packages for most distros. Another idea: should -fstrictness be on by default? I run into too many users writing little tail recursive Int loops, and not using optimisations, with the impression that compiling, e.g. ghc A.hs should just work. -- Don From marlowsd at gmail.com Fri May 16 05:38:46 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 16 05:32:27 2008 Subject: -optc-O2 considered useful In-Reply-To: <20080515223726.GL31635@scytale.galois.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> Message-ID: <482D5626.5010606@gmail.com> Don Stewart wrote: > duncan.coutts: >> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: >>> Hello Don, >>> >>> Thursday, May 15, 2008, 10:47:20 PM, you wrote: >>> >>>> I discovered something today I didn't know. >>>> gcc -O2 can optimise out the computed jumps GHC produces in tight loops. >>> seems that decision to use native backend in ghc -O2 was too early? >> Though note that the native backend never introduced the computed jump. >> >> I think it's clear that -fvia-C -O should imply -optc-O2 if it does not >> already. gcc -O0 is for painfully obvious C translation into assembler, >> -O is for quick optimisations. gcc -O2 is the "standard" optimisation >> level used for building packages for most distros. > > Another idea: > > should -fstrictness be on by default? > > I run into too many users writing little tail recursive Int loops, and > not using optimisations, with the impression that compiling, e.g. > > ghc A.hs > > should just work. This is part of a larger question, namely whether we can get substantial benefit for doing a tiny bit of extra work in -O0. With -O0 we're optimising for compile time in preference to code speed, although we do want to find a good compromise that doesn't generate abysmal code. I bet there are things we can do with -O0 that would generate significantly better code in some cases, without increasing compile times, and perhaps even decreasing compile times due to the reduction in the amount of code being generated. As for the specific issue of whether we should turn on -fstrictness with -O0, I suspect the answer is that the compile-time cost would be too high. Cheers, Simon From ndmitchell at gmail.com Fri May 16 08:00:20 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 16 07:53:57 2008 Subject: -optc-O2 considered useful In-Reply-To: <482D5626.5010606@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> <482D5626.5010606@gmail.com> Message-ID: <404396ef0805160500h5e04a05egec3dc80ba6b966f@mail.gmail.com> Hi > As for the specific issue of whether we should turn on -fstrictness with > -O0, I suspect the answer is that the compile-time cost would be too high. There would also be the issue that it would increase the amount of Haskell code which works only in GHC, which is probably a bad thing. Would the strictness still recover the loop if they turned on hpc/profiling? I can see many reasons why making things faster is good, but making things asymptotically faster/less space in -O0 could bite later. One ticket that probably makes a big difference in -O0 is: http://hackage.haskell.org/trac/ghc/ticket/2207 Thanks Neil From dominic.steinitz at blueyonder.co.uk Fri May 16 14:09:39 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri May 16 14:03:12 2008 Subject: Building GHC Message-ID: <482DCDE3.3040105@blueyonder.co.uk> When I look at the instructions http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources they say the distribution is split in two but when I look at http://darcs.haskell.org/ it seems to be split in three ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:25 102M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:20 92M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:12 57M I'm assuming I unpack these on top of each other but I'd be grateful if someone could confirm this. Thanks, Dominic. From igloo at earth.li Fri May 16 17:13:20 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 16 17:06:56 2008 Subject: Building GHC In-Reply-To: <482DCDE3.3040105@blueyonder.co.uk> References: <482DCDE3.3040105@blueyonder.co.uk> Message-ID: <20080516211320.GA7862@matrix.chaos.earth.li> Hi Dominic, On Fri, May 16, 2008 at 07:09:39PM +0100, Dominic Steinitz wrote: > When I look at the instructions > > http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources That's talking about the sources of a release, from a page like http://www.haskell.org/ghc/download_ghc_682.html > they say the distribution is split in two but when I look at > > http://darcs.haskell.org/ > > it seems to be split in three > > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:25 102M > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:20 92M > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:12 57M These are darcs source snapshots. The filenames are ghc-HEAD-2007-12-16-ghc-corelibs-testsuite.tar.bz2 ghc-HEAD-2007-12-16-ghc-corelibs.tar.bz2 ghc-HEAD-2007-12-16-ghc.tar.bz2 The first includes all of the second, which in turn includes all of the third. > I'm assuming I unpack these on top of each other but I'd be grateful if > someone could confirm this. No, you only want one of them - probably the first one. I don't think it includes the most recent library split, so you'll need to ./darcs-all get after untarring it. Thanks Ian From isaacdupree at charter.net Fri May 16 20:17:17 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri May 16 20:10:54 2008 Subject: -optc-O2 considered useful In-Reply-To: <482D5626.5010606@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> <482D5626.5010606@gmail.com> Message-ID: <482E240D.5080504@charter.net> Simon Marlow wrote: > This is part of a larger question, namely whether we can get substantial > benefit for doing a tiny bit of extra work in -O0. With -O0 we're > optimising for compile time in preference to code speed, although we do > want to find a good compromise that doesn't generate abysmal code. there's the other use of -O0, namely, debugging the compiler -- but then, debugging the optimizations probably requires pretty specific knowledge of what you're looking for, anyway, and testing on multiple platforms usually finds out whether a problem is with a port or with the compilation process. oh, and also that profiling/debugging optimized code can be confusing, so it might be good to avoid optimizations that have too much of that effect -Isaac From bertram.felgenhauer at googlemail.com Sat May 17 00:33:08 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat May 17 00:26:51 2008 Subject: Experiment: ghc-api and --split-objs Message-ID: <20080517043307.GB10526@zombie.inf.tu-dresden.de> Hi, I've made an experiment compiling ghc-api with --split-objs. To summarize, while this is not worthwhile for the compiler itself, it could be a huge win for plugin libraries. A fairly detailed description can be found here, http://int-e.home.tlink.de/haskell/README.ghc-api-test A tarball with the examples and auxiliary files is at http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 Open questions: - How much work would it to do this within the ghc build? - Maybe users that only need the parser can win as well? Haddock comes to mind here. In any case, this is food for thought, I hope. Enjoy, Bertram From conal at conal.net Sat May 17 23:38:56 2008 From: conal at conal.net (Conal Elliott) Date: Sat May 17 23:32:27 2008 Subject: whence _stub.c ? Message-ID: what causes ghc to emit a stub.c file? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080517/1d05b481/attachment-0001.htm From dons at galois.com Sat May 17 23:48:19 2008 From: dons at galois.com (Don Stewart) Date: Sat May 17 23:41:57 2008 Subject: whence _stub.c ? In-Reply-To: References: Message-ID: <20080518034819.GE25300@scytale.galois.com> > what causes ghc to emit a stub.c file? - Conal the use of 'foreign export' - Don From mechvel at botik.ru Sun May 18 09:01:51 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun May 18 08:55:24 2008 Subject: making Happy Message-ID: <20080518130151.GA30353@scico.botik.ru> People, please, how can I download happy-1.14 source ? I need to install ghc-6.8.2 from source, and this needs Happy -- right? I would like to build Happy from source. Its page shows only 1.17. 1.14 was easy to build in a standard way: ./configue --path=... make make install And in 1.17, I am looking into its unzipped root directory, and do not see how to make and install. Generally, it is good to show an easy way to make and install somewhere in the root, in README ... Probably, Happy is a wise and remarkable project. But many people need only to `make' GHC, and do not intend to study right now many documents and philosophy about Happy and Cabal, etc. Thank you in advance for your help, ----------------- Serge Mechveliani mechvel@botik.ru From duncan.coutts at worc.ox.ac.uk Sun May 18 10:54:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 10:45:41 2008 Subject: making Happy In-Reply-To: <20080518130151.GA30353@scico.botik.ru> References: <20080518130151.GA30353@scico.botik.ru> Message-ID: <1211122440.5824.236.camel@localhost> On Sun, 2008-05-18 at 17:01 +0400, Serge D. Mechveliani wrote: > People, > > please, how can I download happy-1.14 source ? > > I need to install ghc-6.8.2 from source, and this needs Happy > -- right? > I would like to build Happy from source. Its page shows only 1.17. > 1.14 was easy to build in a standard way: ./configue --path=... > make > make install The standard procedure for installing cabal packages is pretty similar: runghc Setup configure --prefix=... runghc Setup build runghc Setup install For those brave souls helping us test cabal-install it's even simpler: cabal install happy Duncan From daniel.is.fischer at web.de Sun May 18 11:15:33 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun May 18 11:07:12 2008 Subject: making Happy In-Reply-To: <20080518130151.GA30353@scico.botik.ru> References: <20080518130151.GA30353@scico.botik.ru> Message-ID: <200805181715.33265.daniel.is.fischer@web.de> Am Sonntag, 18. Mai 2008 15:01 schrieb Serge D. Mechveliani: > People, > > please, how can I download happy-1.14 source ? > > I need to install ghc-6.8.2 from source, and this needs Happy > -- right? > I would like to build Happy from source. Its page shows only 1.17. > 1.14 was easy to build in a standard way: ./configue --path=... > make > make install > And in 1.17, I am looking into its unzipped root directory, and do not > see how to make and install. > Generally, it is good to show an easy way to make and install somewhere > in the root, in README ... > Probably, Happy is a wise and remarkable project. But many people need > only to `make' GHC, and do not intend to study right now many documents > and philosophy about Happy and Cabal, etc. > > Thank you in advance for your help, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > If you don't want to go the cabal way, I could send you happy-1.15-src.tar.gz, that builds with ./configure; make; make install, too. From bulat.ziganshin at gmail.com Sun May 18 11:33:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:34:18 2008 Subject: bug in 6.8.2? Message-ID: <1113146976.20080518193302@gmail.com> Hello glasgow-haskell-users, i've rather complicated class structure: class BufferData a where instance (FastBufferData a) => BufferData a where class FastBufferData a where instance (Storable a) => FastBufferData a where of course, it's compiled with -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances BufferData class includes procedure `write`: class BufferData a where write :: OutStream -> a -> IO () there is writeAll procedure which uses this `write` and therefore should be able to write any BufferData instance: writeAll receiveBuf sendBuf cleanup x = bracket (create receiveBuf sendBuf cleanup) (closeOut) (\buf -> write buf x) it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can write only Storable instances, so i was forced to add signature to writeAll: writeAll :: (BufferData a) => RecvBuf -> SendBuf -> Cleanup -> a -> IO () the same problems raised many times when i switched from 6.6.1 to 6.8.2 - lots of procedures need to add signatures because by default 6.8.2 decided that they are restricted to Storable does GHC developers interested in minimal test case for this problem? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon May 19 07:00:40 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon May 19 06:54:10 2008 Subject: bug in 6.8.2? In-Reply-To: <1113146976.20080518193302@gmail.com> References: <1113146976.20080518193302@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE570832C@EA-EXMSG-C334.europe.corp.microsoft.com> | class BufferData a where | write :: OutStream -> a -> IO () | | there is writeAll procedure which uses this `write` and therefore | should be able to write any BufferData instance: | | writeAll receiveBuf sendBuf cleanup x = | bracket (create receiveBuf sendBuf cleanup) (closeOut) | (\buf -> write buf x) | | it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can | write only Storable instances, so i was forced to add signature to | writeAll: Ah, well. You have write :: BufferData a => ... So a call to write gives rise to the constraint (BufferData a). Ah, but there's an instance declaration for that, so GHC simplifies it using. instance (FastBufferData a) => BufferData a where Now we need (FastBufferData a). Ah, there's an instance for that too. instance (Storable a) => FastBufferData a where Oh, you say, I didn't want GHC to simplify (BufferData a), because in a *call* of writeAll, I might instantiate 'a' to T, and I have a more specialised instance of (BufferData T). Fair enough. And indeed, GHC is *supposed* to refrain from using the (BufferData a) instance if it sees *any* more specialised instance. UNLESS a) it can only "see" the (BufferData a) instance, so it doesn't know there are more specialised one b) you specify -fallow-incoherent-instances. Which you do. So you get, well, incoherence. I suspect you are being bitten by (b). The incoherent-instance thing is the most dodgy of GHC's type-class flags. Are you sure you want it? Simon From mechvel at botik.ru Mon May 19 08:37:40 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon May 19 08:31:09 2008 Subject: making GHC from source Message-ID: <20080519123740.GA4798@scico.botik.ru> People, I need to install ghc-6.8.2 from source. As I recall, this needs Happy and Alex. Right? Among Happy versions, it is visible only a couple latest ones, and to install any of them, one needs Cabal. Installing Cabal is as follows: make install mkdir -p dist/tmp ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: ghc: command not found. We have a `make' loop: ghc --> Happy --> Cabal --> ghc Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Now I have to install GHC from binary, and it will report of library version mismatch ... and so on. Do not you think that, generally, something is going wrong here? Regards, ----------------- Serge Mechveliani mechvel@botik.ru http://www.botik.ru/~mechvel From duncan.coutts at worc.ox.ac.uk Mon May 19 14:31:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 19 14:22:31 2008 Subject: making GHC from source In-Reply-To: <20080519123740.GA4798@scico.botik.ru> References: <20080519123740.GA4798@scico.botik.ru> Message-ID: <1211221860.5824.443.camel@localhost> On Mon, 2008-05-19 at 16:37 +0400, Serge D. Mechveliani wrote: > People, > > I need to install ghc-6.8.2 from source. > As I recall, this needs Happy and Alex. Right? No, not if you are using a released ghc tarball because they include the output of happy and alex. You only need happy and alex if you want to build the development version of ghc from darcs. > Among Happy versions, it is visible only a couple latest ones, and to install > any of them, one needs Cabal. > Installing Cabal is as follows: > make install > mkdir -p dist/tmp > ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp > -hidir dist/tmp Setup.lhs -o setup > make: ghc: command not found. > > We have a `make' loop: ghc --> Happy --> Cabal --> ghc Remember that you always need an existing ghc binary to be able to build ghc from source. > Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Happy is written in Haskell and typically people build it from source using GHC. > Now I have to install GHC from binary, and it will report of library version mismatch ... > and so on. > Do not you think that, generally, something is going wrong here? You'll need at least a ghc binary to bootstrap with. See the ghc building guide: http://hackage.haskell.org/trac/ghc/wiki/Building Duncan From marlowsd at gmail.com Tue May 20 03:54:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue May 20 03:47:40 2008 Subject: Experiment: ghc-api and --split-objs In-Reply-To: <20080517043307.GB10526@zombie.inf.tu-dresden.de> References: <20080517043307.GB10526@zombie.inf.tu-dresden.de> Message-ID: <483283A2.2050207@gmail.com> Bertram Felgenhauer wrote: > I've made an experiment compiling ghc-api with --split-objs. To > summarize, while this is not worthwhile for the compiler itself, > it could be a huge win for plugin libraries. > > A fairly detailed description can be found here, > http://int-e.home.tlink.de/haskell/README.ghc-api-test > > A tarball with the examples and auxiliary files is at > http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 > > Open questions: > - How much work would it to do this within the ghc build? > - Maybe users that only need the parser can win as well? Haddock > comes to mind here. > > In any case, this is food for thought, I hope. I hope that for 6.10 we'll have shared libraries working on the major platforms, so split-objs should be a non-issue. For platforms where we don't have shared libraries, or perhaps if we want to have static-only distributions, then probably enabling split-objs for stage 2 would be a good idea, yes. Cheers, Simon From marlowsd at gmail.com Tue May 20 03:54:44 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue May 20 03:48:12 2008 Subject: whence _stub.c ? In-Reply-To: <20080518034819.GE25300@scytale.galois.com> References: <20080518034819.GE25300@scytale.galois.com> Message-ID: <483283C4.3050401@gmail.com> Don Stewart wrote: >> what causes ghc to emit a stub.c file? - Conal > > the use of 'foreign export' - Don or 'foreign import "wrapper"' From bbr at informatik.uni-kiel.de Tue May 20 05:31:51 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Tue May 20 05:26:01 2008 Subject: -optc-O2 considered useful Message-ID: <48329A87.705@informatik.uni-kiel.de> I think it would be nice to have some speedy optimizations turned on by default in ghc. Might even be good to win new users. But I also think that much hacking for and around ghc+tool support needs a way to achieve what -O0 does today. So, how about an -O(-1) or flag? From chak at cse.unsw.edu.au Tue May 20 23:38:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue May 20 23:32:19 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: Stefan Holdermans: > Should I report this a bug? Or is it perhaps already been taken care > of in the head? Probably the latter. But really as, Bulat wrote, type families in 6.8 are unsupported. Please test your code with a HEAD snapshot. If that goes wrong, a bug report on Trac would be most appreciated. Manuel From hp at rentec.com Wed May 21 12:11:56 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 12:05:17 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: Suppose p1, p2, p3 are 3 predicates that take an input -- say, a String. They return either (True, result) or False. I want to get an effect like in this expression: case p1 s of (True, r) -> r False -> case p2 s of (True, r) -> r False -> case p3 s of (True, r) -> r False -> none Is this a job for Maybe monad ? How do I do that ? Thanks HP From hp at rentec.com Wed May 21 12:21:01 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 12:14:20 2008 Subject: ghc compiler <--- ld -R ? In-Reply-To: References: Message-ID: In the linker ld, there is a -R option to encode lib-search-directories into the object file. Can we not do that in compiling this ghc -o foo --make foo.hs ??? Thanks HP From bulat.ziganshin at gmail.com Wed May 21 12:31:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 21 12:27:26 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: <1453427852.20080521203142@gmail.com> Hello HP, Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. impossible because these are different types :)) if they return Just result or Nothing - yes, use Maybe as monad: combine p1 p2 p3 x= do x1 <- p1 x x2 <- p2 x1 x3 <- p3 x2 return x3 or shortly combine p1 p2 p3 x = p1 x >>= p2 >>= p3 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed May 21 12:33:16 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 21 12:29:26 2008 Subject: ghc compiler <--- ld -R ? In-Reply-To: References: Message-ID: <668354053.20080521203316@gmail.com> Hello HP, Wednesday, May 21, 2008, 8:21:01 PM, you wrote: > In the linker ld, there is a -R option example of passing option to ld: ghc ... -optl-Xlinker -optl--large-address-aware -optl-Xlinker may be optional -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniel.is.fischer at web.de Wed May 21 12:57:01 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 21 12:48:33 2008 Subject: how do I abstract this pattern ? In-Reply-To: <1453427852.20080521203142@gmail.com> References: <1453427852.20080521203142@gmail.com> Message-ID: <200805211857.01686.daniel.is.fischer@web.de> Am Mittwoch, 21. Mai 2008 18:31 schrieb Bulat Ziganshin: > Hello HP, > > Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > > Suppose p1, p2, p3 are 3 predicates > > that take an input -- say, a String. > > They return either (True, result) > > or False. > > impossible because these are different types :)) > > if they return Just result or Nothing - yes, use Maybe as monad: > > combine p1 p2 p3 x= do x1 <- p1 x > x2 <- p2 x1 > x3 <- p3 x2 > return x3 > > or shortly > > combine p1 p2 p3 x = p1 x >>= p2 >>= p3 Actually, (s)he wanted a sort of catch chain, so import Control.Monad -- for MonadPlus combine p1 p2 p3 x = p1 x `mplus` p2 x `mplus` p3 x or combine ps x = msum $ map ($ x) ps or just case p1 x of Just r -> return r Nothing -> case p2 x of Just r -> return r Nothing -> ... From cmb21 at kent.ac.uk Wed May 21 13:00:13 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed May 21 12:53:38 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: On Wed, 21 May 2008, HP Wei wrote: > > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. > > I want to get an effect like in this expression: > > case p1 s of > (True, r) -> r > False -> case p2 s of > (True, r) -> r > False -> case p3 s of > (True, r) -> r > False -> none > > Is this a job for Maybe monad ? > How do I do that ? > I think this is a job for the Either monad: data Either a b = Left a | Right b case p1 s of (Left (True, r)) -> r (Right False) -> case p2 s of (Left (True, r)) -> r (Right False) -> case p3 s of (Left (True, r)) -> r (Right False) -> none So you wrap up your (Bool, result) type using Left, and your Bool type using Right. Regards, Chris. > Thanks > HP > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From cmb21 at kent.ac.uk Wed May 21 13:02:48 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed May 21 12:56:09 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: On further thought, better to use the Maybe afterall. You can use Nothing to signify your False and Just to signify your result. case p1 s of Just result -> result Nothing -> case p2 s of ... That's probably more intuitive to what you were intending. Chris. On Wed, 21 May 2008, C.M.Brown wrote: > On Wed, 21 May 2008, HP Wei wrote: > > > > > Suppose p1, p2, p3 are 3 predicates > > that take an input -- say, a String. > > They return either (True, result) > > or False. > > > > I want to get an effect like in this expression: > > > > case p1 s of > > (True, r) -> r > > False -> case p2 s of > > (True, r) -> r > > False -> case p3 s of > > (True, r) -> r > > False -> none > > > > Is this a job for Maybe monad ? > > How do I do that ? > > > > I think this is a job for the Either monad: > > data Either a b = Left a | Right b > > case p1 s of > (Left (True, r)) -> r > (Right False) -> case p2 s of > (Left (True, r)) -> r > (Right False) -> case p3 s of > (Left (True, r)) -> r > (Right False) -> none > > So you wrap up your (Bool, result) type using Left, and your Bool type > using Right. > > Regards, > Chris. > > > > > > Thanks > > HP > > _______________________________________________ > > 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 hp at rentec.com Wed May 21 13:25:15 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 13:18:34 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: Thanks to all who has replied in such a short time. >From your reponses, I looked at the definition of `mplus` Nothing `mplus` ys = ys xs `mplus` _ = xs It catches the essence of what I am trying to do! Later, if pn grows in number, I can scale up by using some-kind-of-zero with some higher order foldx-like functions. Thanks a lot, --hp On Wed, 21 May 2008, HP Wei wrote: > > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. > > I want to get an effect like in this expression: > > case p1 s of > (True, r) -> r > False -> case p2 s of > (True, r) -> r > False -> case p3 s of > (True, r) -> r > False -> none > > Is this a job for Maybe monad ? > How do I do that ? > > Thanks > HP > From allbery at ece.cmu.edu Wed May 21 16:55:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 21 16:48:53 2008 Subject: how do I abstract this pattern ? In-Reply-To: <1453427852.20080521203142@gmail.com> References: <1453427852.20080521203142@gmail.com> Message-ID: <47041C0A-90E6-4FAA-8942-DFB342EE530A@ece.cmu.edu> On 2008 May 21, at 12:31, Bulat Ziganshin wrote: > Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > >> Suppose p1, p2, p3 are 3 predicates >> that take an input -- say, a String. >> They return either (True, result) >> or False. > > if they return Just result or Nothing - yes, use Maybe as monad: > > combine p1 p2 p3 x= do x1 <- p1 x > x2 <- p2 x1 > x3 <- p3 x2 > return x3 S/He's not passing on r (the result), but s (the argument). Monad ((- >) r)? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From stefan at cs.uu.nl Thu May 22 07:40:37 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu May 22 07:33:55 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: <10993B3D-C6CB-4793-99E9-4A84B051B8BE@cs.uu.nl> Manuel, >> Should I report this a bug? Or is it perhaps already been taken >> care of in the head? > > Probably the latter. > > But really as, Bulat wrote, type families in 6.8 are unsupported. > Please test your code with a HEAD snapshot. If that goes wrong, a > bug report on Trac would be most appreciated. Indeed: no problem with yesterday's HEAD. Thanks, Stefan From donn at avvanta.com Thu May 22 12:09:51 2008 From: donn at avvanta.com (Donn Cave) Date: Thu May 22 12:03:01 2008 Subject: integer size on NetBSD amd64 Message-ID: <20080522090951.ba7247aa.donn@avvanta.com> I have been trying to get ghc working on the NetBSD AMD64 platform, and there seems to be a little problem with the integer size. With minInt and maxInt defined as they are in GHC/Base.lhs, ghc can't compile this file - it cranks away and just gets bigger until all the memory is gone. Base.lhs compiles right away if I reduce the size of minInt and maxInt by several bits - minInt = I# (-0x2000000000000000#) maxInt = I# 0x1FFFFFFFFFFFFFFF# -- minInt = I# (-0x8000000000000000#) -- maxInt = I# 0x7FFFFFFFFFFFFFFF# (... and it goes on to crash in GHC/Num.lhs.) So ... maybe somewhere in there, something isn't configured right for 64 bit integer arithmetic, even though the word size parameters in ghcautoconf.h look right? Anyone have an idea what to look for? The GHC version is 6.6.1. The .hc donor host is OpenBSD, gcc3 (NetBSD has gcc4.) The include files from NetBSD (DerivedConstants.h, GHCConstants.h, ghcautoconf.h) look fine, I just went back to the OpenBSD build to verify that they weren't changed during the build. The procedure I'm following is `Cross-compiling to produce an unregisterised GHC' http://hackage.haskell.org/trac/ghc/wiki/Building/Porting thanks! Donn Cave, donn@avvanta.com From Christian.Maeder at dfki.de Fri May 23 05:46:36 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri May 23 05:39:53 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: <20080507212022.GF5108@scytale.galois.com> References: <20080507212022.GF5108@scytale.galois.com> Message-ID: <4836927C.70008@dfki.de> Don Stewart wrote: > hp: >> I convinced myself that the ~500kbytes for the >> 'hello' code is 'correct' in version 6.6.1. >> [ The exact size on the platform mentioned below >> is 422k. ] >> >> Looks like version 6.8.2 blows up the binary code size >> significantly --- 3.9Mbytes vs 0.422Mbytes. >> >> Is this a known issue with 6.8.2 ? >> Is it a specific platform dependent issue --- i.e. >> does it occur on linux machines ?? I can confirm HP's code size. I've no idea what went wrong (or differently): -bash-3.00$ ls -l hello -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello > That's platform dependent. It means on ghc 6.8.2 wasn't built with > split-objs enabled, so it includes a whole bunch of dead code > normally stripped out. > > Consult whoever built the ghc on your platform, to ensure > they know how to build with split objects. > > -- Don Object Splitting was enabled: -bash-3.00$ ll hello -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello -bash-3.00$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.1") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug") ,("Leading underscore","NO") ] Cheers Christian From bulat.ziganshin at gmail.com Fri May 23 16:15:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 23 16:11:38 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <1211572557.5824.542.camel@localhost> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> <1211572557.5824.542.camel@localhost> Message-ID: <279581828.20080524001538@gmail.com> Hello Duncan, Friday, May 23, 2008, 11:55:57 PM, you wrote: >> > me too. btw, this already present in jhc. inlining doesn't work in any >> > complex case since recursive functions can't be inlined >> >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' >> and friends into plain machine loops. > As I understand it, if foldl was written in the standard directly way > then ghc would not inline it well, i'm not a True GHC Hacker ;) but i was bitten by this problem in 6.4. i had a lot of SPECIALIZE pragmas in Streams library exactly because INLINE doesn't help. actually, it even does things worser by disabling some other form of optimization, i don't remember which one i have proposal of inlining even recursive functions just for one level of recursion in order to allow to call here specialized version of function. what GHC HQ will say? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Fri May 23 16:19:42 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 16:12:56 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <279581828.20080524001538@gmail.com> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> <1211572557.5824.542.camel@localhost> <279581828.20080524001538@gmail.com> Message-ID: <20080523201942.GG4034@scytale.galois.com> bulat.ziganshin: > Hello Duncan, > > Friday, May 23, 2008, 11:55:57 PM, you wrote: > > >> > me too. btw, this already present in jhc. inlining doesn't work in any > >> > complex case since recursive functions can't be inlined > >> > >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' > >> and friends into plain machine loops. > > > As I understand it, if foldl was written in the standard directly way > > then ghc would not inline it > > well, i'm not a True GHC Hacker ;) but i was bitten by this problem > in 6.4. i had a lot of SPECIALIZE pragmas in Streams library exactly > because INLINE doesn't help. actually, it even does things worser by > disabling some other form of optimization, i don't remember which one It would be good to try this with 6.8 -- there have been some huge improvements to the strictness analyser and inliner in the last 2 years. Could you dig up some examples? -- Don From igloo at earth.li Fri May 23 17:35:28 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 23 17:28:42 2008 Subject: integer size on NetBSD amd64 In-Reply-To: <20080522090951.ba7247aa.donn@avvanta.com> References: <20080522090951.ba7247aa.donn@avvanta.com> Message-ID: <20080523213528.GA6765@matrix.chaos.earth.li> Hi Donn, On Thu, May 22, 2008 at 09:09:51AM -0700, Donn Cave wrote: > Anyone have an idea what to look for? This doesn't ring any bells for me. If I were you I'd start by trying to work out what it's doing, by running in gdb and hitting ^C after a while to see where it is. Then find the function in the .hc files; you might need to recompile the module with -ddump-simpl to see what Haskell function that C function is part of. I suspect it'll be in something like the show integer code, in which case adding some debugging prints might help - but you'll need to use C's printf "%zd" or something to show any Int's, of course! You might also want to change GHC's main to do something that you think will tickle the bug first, e.g. print (I# (-0x8000000000000000#)). Thanks Ian From dominic.steinitz at blueyonder.co.uk Sun May 25 05:46:43 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sun May 25 05:39:33 2008 Subject: Building ndp Problem Message-ID: <48393583.2070201@blueyonder.co.uk> I wanted to try out data parallel haskell. I followed the instructions on http://haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP but I get the following error: > dom@lagrange:~/ghc/libraries> make make.library.ndp > make: *** No rule to make target `build.library.ndp', needed by `make.library.ndp'. Stop. BTW when I built ghc, I had the following problem with happy (and alex). It kept telling me I needed dvips but dvips is already installed. In the end I used --nodeps. > dom@lagrange:~/happy> rpmbuild -ta happy-1.17.tar.gz > error: Failed build dependencies: > dvips is needed by happy-1.17-1.i586 > dom@lagrange:~/happy> rpmlocate dvips > /usr/bin/dvips > dom@lagrange:~/happy> rpm --query -f /usr/bin/dvips > texlive-2007-69 > dom@lagrange:~/happy> dvips --version > dvips(k) 5.96 > kpathsea version 3.5.6 > Copyright (C) 2005 Radical Eye Software. > There is NO warranty. You may redistribute this software > under the terms of the GNU General Public License > and the Dvips copyright. > For more information about these matters, see the files > named COPYING and dvips.h. > Primary author of Dvips: T. Rokicki; -k maintainer: T. Kacvinsky/ S. Rahtz. > rpmbuild -ta --nodeps happy-1.17.tar.gz From dominic.steinitz at blueyonder.co.uk Mon May 26 03:24:11 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 03:16:55 2008 Subject: Building ndp Problem In-Reply-To: <48393583.2070201@blueyonder.co.uk> References: <48393583.2070201@blueyonder.co.uk> Message-ID: <483A659B.40606@blueyonder.co.uk> Dominic Steinitz wrote: > I wanted to try out data parallel haskell. I followed the instructions > on http://haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP but I > get the following error: > >> dom@lagrange:~/ghc/libraries> make make.library.ndp >> make: *** No rule to make target `build.library.ndp', needed by `make.library.ndp'. Stop. > I'm sure I shouldn't have done this but I did get ndp to build. 1. In libraries/Makefile, I replaced > SUBDIRS += process pretty hpc template-haskell editline Cabal random haskell98 with > SUBDIRS += process pretty hpc template-haskell editline Cabal random haskell98 ndp ^^^ I suspect I didn't supply the correct build.mk but there weren't any clues on http://haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP so I therefore used the one suggested on http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking entitled "How to make GHC build quickly" 2. There was already a hack for ndp so I added my own > # Hack for ndp, as described above > make.library.ndp: build.library.ndp > > MYSUBDIRS = ndp > > # Build the library using 'setup build' (not the default) > $(foreach SUBDIR,$(MYSUBDIRS),build.library.$(SUBDIR)):\ > build.library.%: stamp/configure.library.build$(CONFIGURE_STAMP_EXTRAS).% \ > %/setup/Setup ifBuildable/ifBuildable > if ifBuildable/ifBuildable $*; then \ > cd $* && \ > setup/Setup build $(addprefix --ghc-option=,$(GhcLibHcOpts)); \ > setup/Setup register --inplace; \ > fi > I'm guessing if I'd got the right build.mk I wouldn't have needed to do this. Dominic. From dominic.steinitz at blueyonder.co.uk Mon May 26 03:56:14 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 03:48:57 2008 Subject: ghci Problem Message-ID: <483A6D1E.4080600@blueyonder.co.uk> I've built ghc and installed it but when I run ghci e.g. the up arrow keys don't work :-( Can someone let me know what I've done wrong and how to fix it? Thanks, Dominic. > dom@lagrange:~/ndp> ghci > GHCi, version 6.9.20080517: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> ^[[A From waldmann at imn.htwk-leipzig.de Mon May 26 04:30:23 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon May 26 04:23:29 2008 Subject: ghci Problem In-Reply-To: <483A6D1E.4080600@blueyonder.co.uk> References: <483A6D1E.4080600@blueyonder.co.uk> Message-ID: <483A751F.704@imn.htwk-leipzig.de> Dominic Steinitz wrote: > I've built ghc and installed it but when I run ghci e.g. the up arrow > keys don't work :-( Can someone let me know what I've done wrong and how > to fix it? Thanks, Dominic. sounds like missing readline package during configure be warned - there have been endless discussions on readline (because of licensing issues). best regards, Johannes. From dominic.steinitz at blueyonder.co.uk Mon May 26 04:54:23 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 04:47:06 2008 Subject: ghci Problem In-Reply-To: <483A751F.704@imn.htwk-leipzig.de> References: <483A6D1E.4080600@blueyonder.co.uk> <483A751F.704@imn.htwk-leipzig.de> Message-ID: <483A7ABF.4010905@blueyonder.co.uk> Johannes Waldmann wrote: > Dominic Steinitz wrote: > >> I've built ghc and installed it but when I run ghci e.g. the up arrow >> keys don't work :-( Can someone let me know what I've done wrong and how >> to fix it? Thanks, Dominic. > > sounds like missing readline package during configure > > be warned - there have been endless discussions on readline > (because of licensing issues). > > best regards, Johannes. > > Johannes, Thanks for the reply and I'm sure you are right but I'm still stuck with knowing what to do about it. I think I have a readline: > dom@lagrange:~/ghc> ls /usr/include/readline/ > chardefs.h keymaps.h rlconf.h rltypedefs.h > history.h readline.h rlstdc.h tilde.h I couldn't see anywhere on http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking where it mentioned readline. Ok I can see in config.log that I don't have editline. That sounds very suspicious. Mind you I'm not sure where to get it from for opensuse. I'll have a hunt around. Dominic. From dominic.steinitz at blueyonder.co.uk Mon May 26 05:13:56 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 05:06:40 2008 Subject: ghci Problem In-Reply-To: <483A7ABF.4010905@blueyonder.co.uk> References: <483A6D1E.4080600@blueyonder.co.uk> <483A751F.704@imn.htwk-leipzig.de> <483A7ABF.4010905@blueyonder.co.uk> Message-ID: <483A7F54.3060709@blueyonder.co.uk> > Ok I can see in config.log that I don't have editline. That sounds very > suspicious. Mind you I'm not sure where to get it from for opensuse. > I'll have a hunt around. > I found the editline package but now I have the following. I'm not even sure installing the editline package is the right thing to do > dom@lagrange:~/editline/editline-0.2> ./Setup build > Preprocessing library editline-0.2... > > In file included from Editline.hsc:52:0: > > include/HsEditline.h:11:0: > error: conflicting types for ?el_get? > > /usr/include/histedit.h:112:0: > error: previous declaration of ?el_get? was here > compiling dist/build/System/Console/Editline_hsc_make.c failed > command was: /usr/local/bin/ghc -c -package base-3.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o From dominic.steinitz at blueyonder.co.uk Mon May 26 07:17:40 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 07:10:25 2008 Subject: ghci Problem In-Reply-To: <483A7F54.3060709@blueyonder.co.uk> References: <483A6D1E.4080600@blueyonder.co.uk> <483A751F.704@imn.htwk-leipzig.de> <483A7ABF.4010905@blueyonder.co.uk> <483A7F54.3060709@blueyonder.co.uk> Message-ID: <483A9C54.5010200@blueyonder.co.uk> Dominic Steinitz wrote: >> Ok I can see in config.log that I don't have editline. That sounds very >> suspicious. Mind you I'm not sure where to get it from for opensuse. >> I'll have a hunt around. >> > > I found the editline package but now I have the following. I'm not even > sure installing the editline package is the right thing to do > >> dom@lagrange:~/editline/editline-0.2> ./Setup build >> Preprocessing library editline-0.2... >> >> In file included from Editline.hsc:52:0: >> >> include/HsEditline.h:11:0: >> error: conflicting types for ?el_get? >> >> /usr/include/histedit.h:112:0: >> error: previous declaration of ?el_get? was here >> compiling dist/build/System/Console/Editline_hsc_make.c failed >> command was: /usr/local/bin/ghc -c -package base-3.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o > > Sorry for the running commentary but you can always hit delete. This looks a bit dodgy in configure: > if "${GhcPkgCmd-ghc-pkg}" --show-package editline >/dev/null 2>&1; then > fp_cv_ghc_has_editline=yes > else > fp_cv_ghc_has_editline=no > fi As I suspect: > dom@lagrange:~/ghc> ghc-pkg --show-package editline > ghc-pkg: unrecognized option `--show-package' This works but configure doesn't seem to be in darcs so I'm not sure how to send a patch. Happy to raise a ticket. Let me know. > if "${GhcPkgCmd-ghc-pkg}" describe editline >/dev/null 2>&1; then > fp_cv_ghc_has_editline=yes > else > fp_cv_ghc_has_editline=no > fi Dominic. From dominic.steinitz at blueyonder.co.uk Mon May 26 07:54:48 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 26 07:47:31 2008 Subject: ghci Problem In-Reply-To: <483A9C54.5010200@blueyonder.co.uk> References: <483A6D1E.4080600@blueyonder.co.uk> <483A751F.704@imn.htwk-leipzig.de> <483A7ABF.4010905@blueyonder.co.uk> <483A7F54.3060709@blueyonder.co.uk> <483A9C54.5010200@blueyonder.co.uk> Message-ID: <483AA508.5000201@blueyonder.co.uk> Dominic Steinitz wrote: > Dominic Steinitz wrote: >>> Ok I can see in config.log that I don't have editline. That sounds very >>> suspicious. Mind you I'm not sure where to get it from for opensuse. >>> I'll have a hunt around. >>> >> I found the editline package but now I have the following. I'm not even >> sure installing the editline package is the right thing to do >> >>> dom@lagrange:~/editline/editline-0.2> ./Setup build >>> Preprocessing library editline-0.2... >>> >>> In file included from Editline.hsc:52:0: >>> >>> include/HsEditline.h:11:0: >>> error: conflicting types for ?el_get? >>> >>> /usr/include/histedit.h:112:0: >>> error: previous declaration of ?el_get? was here >>> compiling dist/build/System/Console/Editline_hsc_make.c failed >>> command was: /usr/local/bin/ghc -c -package base-3.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o >> > > Sorry for the running commentary but you can always hit delete. > > This looks a bit dodgy in configure: > >> if "${GhcPkgCmd-ghc-pkg}" --show-package editline >/dev/null 2>&1; then >> fp_cv_ghc_has_editline=yes >> else >> fp_cv_ghc_has_editline=no >> fi > > As I suspect: > >> dom@lagrange:~/ghc> ghc-pkg --show-package editline >> ghc-pkg: unrecognized option `--show-package' > > This works but configure doesn't seem to be in darcs so I'm not sure how > to send a patch. Happy to raise a ticket. Let me know. > >> if "${GhcPkgCmd-ghc-pkg}" describe editline >/dev/null 2>&1; then >> fp_cv_ghc_has_editline=yes >> else >> fp_cv_ghc_has_editline=no >> fi > > Dominic. > We seem to be back to a problem in readline again. > Preprocessing library editline-0.2... > In file included from Editline.hsc:52: > include/HsEditline.h:11: error: conflicting types for ?el_get? > /usr/include/histedit.h:112: error: previous declaration of ?el_get? was here > compiling dist/build/System/Console/Editline_hsc_make.c failed > command was: gcc -c -D__GLASGOW_HASKELL__=609 -I/home/dom/ghc/includes -I/home/dom/ghc/gmp/gmpbuild -D__GLASGOW_HASKELL__=609 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o Commenting out this line seems to make things compile. > /* extern int el_get(EditLine *e, int op, void *result); */ Finally ghci works. I think I should get points for persistence. Dominic. From judah.jacobson at gmail.com Mon May 26 13:53:33 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon May 26 13:46:51 2008 Subject: ghci Problem In-Reply-To: <483AA508.5000201@blueyonder.co.uk> References: <483A6D1E.4080600@blueyonder.co.uk> <483A751F.704@imn.htwk-leipzig.de> <483A7ABF.4010905@blueyonder.co.uk> <483A7F54.3060709@blueyonder.co.uk> <483A9C54.5010200@blueyonder.co.uk> <483AA508.5000201@blueyonder.co.uk> Message-ID: <6d74b0d20805261053m2608c35uaa64ff829641c716@mail.gmail.com> On Mon, May 26, 2008 at 4:54 AM, Dominic Steinitz wrote: > Dominic Steinitz wrote: >> Dominic Steinitz wrote: >>>> Ok I can see in config.log that I don't have editline. That sounds very >>>> suspicious. Mind you I'm not sure where to get it from for opensuse. >>>> I'll have a hunt around. >>>> > >> Preprocessing library editline-0.2... >> In file included from Editline.hsc:52: >> include/HsEditline.h:11: error: conflicting types for 'el_get' >> /usr/include/histedit.h:112: error: previous declaration of 'el_get' was here >> compiling dist/build/System/Console/Editline_hsc_make.c failed >> command was: gcc -c -D__GLASGOW_HASKELL__=609 -I/home/dom/ghc/includes -I/home/dom/ghc/gmp/gmpbuild -D__GLASGOW_HASKELL__=609 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o > > Commenting out this line seems to make things compile. > >> /* extern int el_get(EditLine *e, int op, void *result); */ > > Finally ghci works. I think I should get points for persistence. > Points definitely awarded! Thank you for tracking down the cause of your problem. The issue was that we weren't handling the el_get function portably enough. I've uploaded a fix to the darcs repo at http:code.haskell.org/editline ; I'll submit it for inclusion in the main repository at darcs.haskell.org as well. Thanks, -Judah From chak at cse.unsw.edu.au Mon May 26 21:21:21 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon May 26 21:14:26 2008 Subject: Building ndp Problem In-Reply-To: <48393583.2070201@blueyonder.co.uk> References: <48393583.2070201@blueyonder.co.uk> Message-ID: <066B8FEE-5784-42B4-98AC-225F2852D812@cse.unsw.edu.au> Dominic Steinitz: > I wanted to try out data parallel haskell. I followed the instructions > on http://haskell.org/haskellwiki/Data_Parallel_Haskell/PackageNDP > but I > get the following error: > >> dom@lagrange:~/ghc/libraries> make make.library.ndp >> make: *** No rule to make target `build.library.ndp', needed by >> `make.library.ndp'. Stop. The ndp libraries are currently undergoing a fundamental restructure. We'll update the instructions once matters settle down. Sorry for the inconvenience. Manuel From peteg42 at gmail.com Mon May 26 23:37:56 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Mon May 26 23:31:05 2008 Subject: static linking Message-ID: <9083BFDB-E96A-4222-A8DD-76CB9BEAC3BD@gmail.com> Hello, I am having a bit of trouble static linking my program using GHC 6.8.2. In brief: "rt" uses "pthread", but -lrt is the final thing on the command line passed to the linker, and so the pthread symbols are not resolved. Manually moving -lpthread to the end of the collect2 command line does the trick. The question is how to do this using ghc. This is on Debian, using the 6.8.2-5 from unstable. I can provide the command lines if that is helpful. Note the same setup worked fine under GHC 6.6.1. cheers peter From jakubuv at gmail.com Tue May 27 13:00:00 2008 From: jakubuv at gmail.com (Jan Jakubuv) Date: Tue May 27 12:53:01 2008 Subject: GHC rewrite rules pragma Message-ID: Hi, I'm trying to find out how the GHC rewrite rules pragma work, but I'm not able to make it working. I have this simple example, where I would like to specialize the function gen to spec on strings: {-# OPTIONS -O2 -fglasgow-exts #-} gen :: [a] -> a gen = head {-# RULES "gen/Char" gen=spec #-} spec :: [Char] -> Char spec x = 'x' main :: IO () main = putStr (gen "aaa":"\n") -- EOF I compile it as: ghc -O2 -fglasgow-exts spec.hs but as a result, is always prints 'a' while I expect 'x'. Is it right? What is the problem here? I would be glad for any answer. I'm using GHC 6.8.2. Sincerely, Jan. From dons at galois.com Tue May 27 13:22:44 2008 From: dons at galois.com (Don Stewart) Date: Tue May 27 13:15:47 2008 Subject: GHC rewrite rules pragma In-Reply-To: References: Message-ID: <20080527172244.GB8351@scytale.galois.com> jakubuv: > Hi, > > I'm trying to find out how the GHC rewrite rules pragma work, but I'm > not able to make it working. I have this simple example, where I would > like to specialize the function gen to spec on strings: > > {-# OPTIONS -O2 -fglasgow-exts #-} > > gen :: [a] -> a > gen = head > > {-# RULES "gen/Char" gen=spec #-} > spec :: [Char] -> Char > spec x = 'x' > > main :: IO () > main = putStr (gen "aaa":"\n") > > -- EOF > > I compile it as: > ghc -O2 -fglasgow-exts spec.hs > > but as a result, is always prints 'a' while I expect 'x'. Is it right? > What is the problem here? I would be glad for any answer. I'm using > GHC 6.8.2. > > Sincerely, > Jan. This is the main wibble people forget when writing rules -- inlining. In your example, 'gen' is so cheap, it is immediately inlined, so it won't be available to match on in your rule. Anything you want to match should have its inlining delayed: {-# OPTIONS -O2 -fglasgow-exts #-} gen :: [a] -> a gen = head {-# INLINE [1] gen #-} {-# RULES "gen/Char" gen = spec #-} spec :: [Char] -> Char spec x = 'x' main :: IO () main = putStr (gen "aaa":"\n") Running this in ghc-core, we see: RuleFired 1 gen/Char Good. And the program prints out: $ ./A x There was some discussion of adding a warning for any function used in the left hand side of a rewrite rule, that doesn't have precise inlining control added. That would have caught this. -- Don From jakubuv at gmail.com Tue May 27 15:29:05 2008 From: jakubuv at gmail.com (Jan Jakubuv) Date: Tue May 27 15:22:06 2008 Subject: GHC rewrite rules pragma In-Reply-To: <20080527172244.GB8351@scytale.galois.com> References: <20080527172244.GB8351@scytale.galois.com> Message-ID: Thanks lot, it works now. Now, I have just a simple question: Is there any chance to make rewriting working in ghci ? jan. 2008/5/27 Don Stewart : > jakubuv: >> Hi, >> >> I'm trying to find out how the GHC rewrite rules pragma work, but I'm >> not able to make it working. I have this simple example, where I would >> like to specialize the function gen to spec on strings: >> >> {-# OPTIONS -O2 -fglasgow-exts #-} >> >> gen :: [a] -> a >> gen = head >> >> {-# RULES "gen/Char" gen=spec #-} >> spec :: [Char] -> Char >> spec x = 'x' >> >> main :: IO () >> main = putStr (gen "aaa":"\n") >> >> -- EOF >> >> I compile it as: >> ghc -O2 -fglasgow-exts spec.hs >> >> but as a result, is always prints 'a' while I expect 'x'. Is it right? >> What is the problem here? I would be glad for any answer. I'm using >> GHC 6.8.2. >> >> Sincerely, >> Jan. > > This is the main wibble people forget when writing rules -- inlining. > In your example, 'gen' is so cheap, it is immediately > inlined, so it won't be available to match on in your rule. > > Anything you want to match should have its inlining delayed: > > {-# OPTIONS -O2 -fglasgow-exts #-} > > gen :: [a] -> a > gen = head > {-# INLINE [1] gen #-} > > {-# RULES > "gen/Char" gen = spec > #-} > > spec :: [Char] -> Char > spec x = 'x' > > main :: IO () > main = putStr (gen "aaa":"\n") > > Running this in ghc-core, we see: > > RuleFired > 1 gen/Char > > Good. > And the program prints out: > > $ ./A > x > > There was some discussion of adding a warning for any function > used in the left hand side of a rewrite rule, that doesn't have > precise inlining control added. That would have caught this. > > -- Don > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From dons at galois.com Tue May 27 17:02:43 2008 From: dons at galois.com (Don Stewart) Date: Tue May 27 16:55:49 2008 Subject: GHC rewrite rules pragma In-Reply-To: References: <20080527172244.GB8351@scytale.galois.com> Message-ID: <20080527210243.GI8351@scytale.galois.com> jakubuv: > Thanks lot, it works now. Now, I have just a simple question: > > Is there any chance to make rewriting working in ghci ? I think you can actually enable them by putting: {-# OPTIONS -frewrite-rules #-} at the top of the file to be interpreted. Works for me, anyway. -- Don From jakubuv at gmail.com Tue May 27 17:52:06 2008 From: jakubuv at gmail.com (Jan Jakubuv) Date: Tue May 27 17:45:07 2008 Subject: GHC rewrite rules pragma In-Reply-To: <20080527210243.GI8351@scytale.galois.com> References: <20080527172244.GB8351@scytale.galois.com> <20080527210243.GI8351@scytale.galois.com> Message-ID: thanks, it works fine now. 2008/5/27 Don Stewart : > jakubuv: >> Thanks lot, it works now. Now, I have just a simple question: >> >> Is there any chance to make rewriting working in ghci ? > > I think you can actually enable them by putting: > > {-# OPTIONS -frewrite-rules #-} > > at the top of the file to be interpreted. Works for me, anyway. > > -- Don > > From peteg42 at gmail.com Wed May 28 05:03:10 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 28 04:56:21 2008 Subject: static linking In-Reply-To: <9083BFDB-E96A-4222-A8DD-76CB9BEAC3BD@gmail.com> References: <9083BFDB-E96A-4222-A8DD-76CB9BEAC3BD@gmail.com> Message-ID: Hello, Further on my static linking woes: debian ~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 -debian ~$ cat T.hs main :: IO () main = putStrLn "Hello world" -debian ~$ ghc -optl-static -static --make T.hs Linking T ... /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/ librt.a(timer_create.o): In function `timer_create': (.text+0x107): undefined reference to `pthread_once' ... < references to missing pthread symbols > Does anyone have static linking working for GHC 6.8.2 and can inform me of the magic incantation? "Get the latest development version from darcs", perhaps? BTW when I said "move to the end", I meant "move to the end of -l flags". cheers peter On 27/05/2008, at 10:37 AM, Peter Gammie wrote: > Hello, > > I am having a bit of trouble static linking my program using GHC > 6.8.2. > > In brief: "rt" uses "pthread", but -lrt is the final thing on the > command line passed to the linker, and so the pthread symbols are > not resolved. Manually moving -lpthread to the end of the collect2 > command line does the trick. > > The question is how to do this using ghc. > > This is on Debian, using the 6.8.2-5 from unstable. > > I can provide the command lines if that is helpful. > > Note the same setup worked fine under GHC 6.6.1. > > cheers > peter From marlowsd at gmail.com Wed May 28 05:05:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 28 04:58:41 2008 Subject: *BSD support in 6.8.3 Message-ID: <483D205E.5010004@gmail.com> Hi Folks, 6.8.3 is nearing release, and we have an outstanding bug affecting the GHCi on the BSDs: http://hackage.haskell.org/trac/ghc/ticket/2013 We need someone to help out with this. The patch in the ticket apparently works, but can't be committed as is because it isn't correctly #ifdef'd and will presumably break other platforms. Also it needs to be tested on OpenBSD/NetBSD in addition to FreeBSD. I don't have access to a *BSD machine right now, and I don't have the time available to set one up. If someone can donate a temporary account then that would be helpful, but most helpful would be if someone could work with us to get this bug fixed in time for 6.8.3 (i.e. the next few days). Otherwise, we have to release with the bug still in, which would be bad. Cheers, Simon From marlowsd at gmail.com Wed May 28 05:24:56 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 28 05:18:01 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: <4836927C.70008@dfki.de> References: <20080507212022.GF5108@scytale.galois.com> <4836927C.70008@dfki.de> Message-ID: <483D24E8.1040906@gmail.com> Christian Maeder wrote: > Don Stewart wrote: >> hp: >>> I convinced myself that the ~500kbytes for the 'hello' code is >>> 'correct' in version 6.6.1. >>> [ The exact size on the platform mentioned below >>> is 422k. ] >>> >>> Looks like version 6.8.2 blows up the binary code size >>> significantly --- 3.9Mbytes vs 0.422Mbytes. >>> >>> Is this a known issue with 6.8.2 ? >>> Is it a specific platform dependent issue --- i.e. >>> does it occur on linux machines ?? > > I can confirm HP's code size. I've no idea what went wrong (or > differently): > > -bash-3.00$ ls -l hello > -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello > >> That's platform dependent. It means on ghc 6.8.2 wasn't built with >> split-objs enabled, so it includes a whole bunch of dead code normally >> stripped out. >> >> Consult whoever built the ghc on your platform, to ensure >> they know how to build with split objects. >> >> -- Don > > Object Splitting was enabled: > > -bash-3.00$ ll hello > -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello > > -bash-3.00$ ghc --info > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("Project version","6.8.2") > ,("Booter version","6.8.1") > ,("Stage","2") > ,("Interface file version","6") > ,("Have interpreter","YES") > ,("Object splitting","YES") > ,("Have native code generator","NO") > ,("Support SMP","YES") > ,("Unregisterised","NO") > ,("Tables next to code","YES") > ,("Win32 DLLs","") > ,("RTS ways"," debug thr thr_p thr_debug") > ,("Leading underscore","NO") > ] If the libraries were built with -fvia-C, we occasionally get incompabitilities with newer versions of gcc and end up duplicating too much stuff in the split .o files. If this is happening to you, please report a bug. Otherwise, please report a bug giving as much info as possible, and we'll try to figure out what is wrong. Cheers, Simon From marlowsd at gmail.com Wed May 28 05:27:44 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 28 05:20:59 2008 Subject: static linking In-Reply-To: References: <9083BFDB-E96A-4222-A8DD-76CB9BEAC3BD@gmail.com> Message-ID: <483D2590.7060302@gmail.com> Peter Gammie wrote: > Hello, > > Further on my static linking woes: > > debian ~$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > -debian ~$ cat T.hs > main :: IO () > main = putStrLn "Hello world" > -debian ~$ ghc -optl-static -static --make T.hs > Linking T ... > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): > In function `timer_create': > (.text+0x107): undefined reference to `pthread_once' > ... > < references to missing pthread symbols > > > Does anyone have static linking working for GHC 6.8.2 and can inform me > of the magic incantation? "Get the latest development version from > darcs", perhaps? > > BTW when I said "move to the end", I meant "move to the end of -l flags". We may need to tweak the order of the libraries in rts/package.conf.in (this is where -lrt comes from). The question is, do we need a configure test? Cheers, Simon > cheers > peter > > On 27/05/2008, at 10:37 AM, Peter Gammie wrote: > >> Hello, >> >> I am having a bit of trouble static linking my program using GHC 6.8.2. >> >> In brief: "rt" uses "pthread", but -lrt is the final thing on the >> command line passed to the linker, and so the pthread symbols are not >> resolved. Manually moving -lpthread to the end of the collect2 command >> line does the trick. >> >> The question is how to do this using ghc. >> >> This is on Debian, using the 6.8.2-5 from unstable. >> >> I can provide the command lines if that is helpful. >> >> Note the same setup worked fine under GHC 6.6.1. >> >> cheers >> peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Wed May 28 05:38:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed May 28 05:31:52 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: <483D24E8.1040906@gmail.com> References: <20080507212022.GF5108@scytale.galois.com> <4836927C.70008@dfki.de> <483D24E8.1040906@gmail.com> Message-ID: <483D282D.9010902@dfki.de> see http://hackage.haskell.org/trac/ghc/ticket/2312 -split-objs is passed to stage1/ghc-inplace when building the library, yet there's only at most one part for each module. Cheers Christian Simon Marlow wrote: >> -bash-3.00$ ghc --info >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("Project version","6.8.2") >> ,("Booter version","6.8.1") >> ,("Stage","2") >> ,("Interface file version","6") >> ,("Have interpreter","YES") >> ,("Object splitting","YES") >> ,("Have native code generator","NO") >> ,("Support SMP","YES") >> ,("Unregisterised","NO") >> ,("Tables next to code","YES") >> ,("Win32 DLLs","") >> ,("RTS ways"," debug thr thr_p thr_debug") >> ,("Leading underscore","NO") >> ] > > If the libraries were built with -fvia-C, we occasionally get > incompabitilities with newer versions of gcc and end up duplicating too > much stuff in the split .o files. If this is happening to you, please > report a bug. > > Otherwise, please report a bug giving as much info as possible, and > we'll try to figure out what is wrong. > > Cheers, > Simon From igloo at earth.li Wed May 28 11:20:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed May 28 11:13:32 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate Message-ID: <20080528152033.GA6188@matrix.chaos.earth.li> We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team From gwright at comcast.net Wed May 28 12:25:48 2008 From: gwright at comcast.net (Gregory Wright) Date: Wed May 28 12:19:01 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <483D205E.5010004@gmail.com> References: <483D205E.5010004@gmail.com> Message-ID: Hi Simon, On May 28, 2008, at 5:05 AM, Simon Marlow wrote: > Hi Folks, > > 6.8.3 is nearing release, and we have an outstanding bug affecting > the GHCi on the BSDs: > > http://hackage.haskell.org/trac/ghc/ticket/2013 > > We need someone to help out with this. The patch in the ticket > apparently works, but can't be committed as is because it isn't > correctly #ifdef'd and will presumably break other platforms. Also > it needs to be tested on OpenBSD/NetBSD in addition to FreeBSD. > > I don't have access to a *BSD machine right now, and I don't have > the time available to set one up. If someone can donate a temporary > account then that would be helpful, but most helpful would be if > someone could work with us to get this bug fixed in time for 6.8.3 > (i.e. the next few days). Otherwise, we have to release with the bug > still in, which would be bad. > > Cheers, > Simon I have a FreeBSD 7.0/x86_64 machine I can test this on. Should the patch be applied to the 6.8.3 release candidate tarball, or just the head of the 6.8.x branch? Greg From igloo at earth.li Wed May 28 13:14:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed May 28 13:07:37 2008 Subject: *BSD support in 6.8.3 In-Reply-To: References: <483D205E.5010004@gmail.com> Message-ID: <20080528171437.GA9878@matrix.chaos.earth.li> On Wed, May 28, 2008 at 12:25:48PM -0400, Gregory Wright wrote: > > I have a FreeBSD 7.0/x86_64 machine I can test this on. Should the > patch be applied to the > 6.8.3 release candidate tarball, or just the head of the 6.8.x branch? Either, they're the same at the moment - although if you want to make a darcs patch of the result then you'll need to apply it to the darcs branch. It's possible there will be some fuzz, as the patch is 5 months old. Thanks Ian From dons at galois.com Wed May 28 13:46:16 2008 From: dons at galois.com (Don Stewart) Date: Wed May 28 13:39:16 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <483D205E.5010004@gmail.com> References: <483D205E.5010004@gmail.com> Message-ID: <20080528174616.GA10471@scytale.galois.com> marlowsd: > Hi Folks, > > 6.8.3 is nearing release, and we have an outstanding bug affecting the > GHCi on the BSDs: > > http://hackage.haskell.org/trac/ghc/ticket/2013 > > We need someone to help out with this. The patch in the ticket apparently > works, but can't be committed as is because it isn't correctly #ifdef'd > and will presumably break other platforms. Also it needs to be tested on > OpenBSD/NetBSD in addition to FreeBSD. > > I don't have access to a *BSD machine right now, and I don't have the time > available to set one up. If someone can donate a temporary account then > that would be helpful, but most helpful would be if someone could work > with us to get this bug fixed in time for 6.8.3 (i.e. the next few days). > Otherwise, we have to release with the bug still in, which would be bad. So, try the patch to get the patch to compile against ghc 6.8.3-snapshot, and see if it works on OpenBSD? -- Don From mechvel at botik.ru Wed May 28 14:28:58 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed May 28 14:21:56 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080528152033.GA6188@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: <20080528182858.GA16929@scico.botik.ru> No, ghc-6.8.2.20080527-src.tar.bz2 (`made' on Debian Linux, i686) does not work. See DoCon-2.11. It compiles DoCon-2.11 with taking too much memory (> 300 Mb) and 3-4 times more of time than ghc-6.8.2. And then, the test fails. ----------------- Serge Mechveliani mechvel@botik.ru On Wed, May 28, 2008 at 04:20:33PM +0100, Ian Lynagh wrote: > > We are pleased to announce the Release Candidate phase for GHC 6.8.3. > > Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 > > You can download snapshots from here: > > http://www.haskell.org/ghc/dist/stable/dist/ > > Right now we have the source bundles: > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2 > > > Only the first of these is necessary. The "extralibs" package contains > various extra packages that are often supplied with GHC - unpack the > extralibs tarball on top of the source tree to add them, and they will > be included in the build automatically. > > There is also currently an installer for i386/Windows and binary > distributions for x86_64/Linux and i386/Linux. More may appear later. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > We expect to release in a few days, assuming no major issues are > discovered. > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From peteg42 at gmail.com Wed May 28 23:07:21 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 28 23:00:28 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080528152033.GA6188@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: Ian: does static linking on linux work? See my earlier emails, it is easy enough to test. Would you like me to report a bug? There really should be a unit test for this. cheers peter On 28/05/2008, at 10:20 PM, Ian Lynagh wrote: > We are pleased to announce the Release Candidate phase for GHC 6.8.3. > > Snapshots beginning with 6.8.2.20080527 are release candidates > for 6.8.3 From igloo at earth.li Thu May 29 05:44:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 29 05:37:36 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080528182858.GA16929@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> Message-ID: <20080529094440.GA415@matrix.chaos.earth.li> Hi Serge, On Wed, May 28, 2008 at 10:28:58PM +0400, Serge D. Mechveliani wrote: > No, ghc-6.8.2.20080527-src.tar.bz2 (`made' on Debian Linux, i686) > does not work. > See DoCon-2.11. > It compiles DoCon-2.11 with taking too much memory (> 300 Mb) and > 3-4 times more of time than ghc-6.8.2. > And then, the test fails. Thanks for the feedback! Can you please send us complete instructions for reproducing the problem, along with the output that you are seeing? Thanks Ian From igloo at earth.li Thu May 29 05:58:20 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 29 05:51:15 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: <20080529095819.GB415@matrix.chaos.earth.li> On Thu, May 29, 2008 at 10:07:21AM +0700, Peter Gammie wrote: > Ian: does static linking on linux work? It does. I don't remember it being fixed, though; this might be a difference in how the bindists and Debian packages were built (or it could just be my bad memory, or some other change might have accidentally fixed it). Thanks Ian From chak at cse.unsw.edu.au Thu May 29 06:19:31 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu May 29 06:12:28 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080528152033.GA6188@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: <0238D121-16AB-4009-B426-A53A81B12484@cse.unsw.edu.au> A Mac installer version of the release candidate for Intel/Leopard Macs is at http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg This version of GHC includes neither editline nor readline at the moment (this will be fixed for the final release). It also only works for Leopard (MacOS X 10.5) as I haven't managed to get cross compiling for older OS versions fully functional yet. In any case, please test this if you have an Intel/Leopard Mac and are interested in a one-click installer with no dependencies other than a recent version of Xcode. The packages comes with an uninstall script located at /Library/Frameworks/GHC.framework/Tools/Uninstaller It will overwrite other 6.8.x versions of GHC installed from an installer package, but peacefully coexist with other distributions of 6.8 and with GHC versions other than 6.8 independent of how they were installed. Manuel > > We are pleased to announce the Release Candidate phase for GHC 6.8.3. > > Snapshots beginning with 6.8.2.20080527 are release candidates > for 6.8.3 > > You can download snapshots from here: > > http://www.haskell.org/ghc/dist/stable/dist/ > > Right now we have the source bundles: > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralibs.tar.bz2 > > > Only the first of these is necessary. The "extralibs" package contains > various extra packages that are often supplied with GHC - unpack the > extralibs tarball on top of the source tree to add them, and they will > be included in the build automatically. > > There is also currently an installer for i386/Windows and binary > distributions for x86_64/Linux and i386/Linux. More may appear later. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > We expect to release in a few days, assuming no major issues are > discovered. > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Thu May 29 07:19:54 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 29 07:12:55 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <20080528174616.GA10471@scytale.galois.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> Message-ID: <483E915A.3090606@gmail.com> Don Stewart wrote: > marlowsd: >> Hi Folks, >> >> 6.8.3 is nearing release, and we have an outstanding bug affecting the >> GHCi on the BSDs: >> >> http://hackage.haskell.org/trac/ghc/ticket/2013 >> >> We need someone to help out with this. The patch in the ticket apparently >> works, but can't be committed as is because it isn't correctly #ifdef'd >> and will presumably break other platforms. Also it needs to be tested on >> OpenBSD/NetBSD in addition to FreeBSD. >> >> I don't have access to a *BSD machine right now, and I don't have the time >> available to set one up. If someone can donate a temporary account then >> that would be helpful, but most helpful would be if someone could work >> with us to get this bug fixed in time for 6.8.3 (i.e. the next few days). >> Otherwise, we have to release with the bug still in, which would be bad. > > So, try the patch to get the patch to compile against ghc > 6.8.3-snapshot, and see if it works on OpenBSD? It's not just a case of testing the patch, there are a couple of issues to address: - it has a couple of wired-in addresses: one place to load object files, another to put jump tables at. This is necessary because *BSD doesn't have the MAP_32BIT flag for mmap(). However, the particular wired-in addresses needed will probably vary on the different *BSDs. Someone needs to look at the memory map and make sure we're picking sensible addresses. - the patch doesn't #ifdef its changes, so it'll break other platforms (easy to fix). Also the code has changed in HEAD, and we need a completely different patch there (although the same idea applies, pick an address and use MAP_FIXED). Cheers, Simon From mechvel at botik.ru Thu May 29 07:48:36 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 29 07:41:36 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080529094440.GA415@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> Message-ID: <20080529114836.GA18601@scico.botik.ru> On Thu, May 29, 2008 at 10:44:40AM +0100, Ian Lynagh wrote: > > Hi Serge, > > On Wed, May 28, 2008 at 10:28:58PM +0400, Serge D. Mechveliani wrote: > > No, ghc-6.8.2.20080527-src.tar.bz2 (`made' on Debian Linux, i686) > > does not work. > > See DoCon-2.11. > > It compiles DoCon-2.11 with taking too much memory (> 300 Mb) and > > 3-4 times more of time than ghc-6.8.2. > > And then, the test fails. > > Thanks for the feedback! Can you please send us complete instructions > for reproducing the problem, along with the output that you are seeing? Take the public docon-2.11 (for example, from www.haskell/ghc/docon/) and follow its instruction install.txt. Let us call ghc-6.8.2.20080527 may27. 1) In ghc-6.8.2, it suffices -M300m to build, and may27 needs more -- change it to -M700m -K99m in source/docon.cabal. 2) 6.8.2 builds DoCon 3 times faster. 3) The size of libHSdocon-2.11.a in 6.8.2 is about 14.2 Mb, in may27 it is about 16.7 Mb. 4) The module RsePol_.hs (close to the end of `make') takes particularly long to compile. 5) Build and run source/demotest/Main as it is described in install.txt ( cd source/demotest ghc $doconCpOpt --make Main ./Main +RTS -M60m -RTS ) ghc-6.8.2 runs it all right, and may27 reports ------------------------------------------------- Permutation group S = S(n) =============== List all permutations p from S and test each p as follows cG = cyclicGroup(p) in S(n) cycles = [cl(1)..cl(k)] = decomposition of p to cycles Verify 0 < card cG <= card S, cG is free of repetitions and contains unity, composition of cycles == p, lcM (map length cycles) == card cG. And for n, test osetCard S == n! Do this all for n <- [1..nN]. Here nN = 7. --- RESULT: [[True,True],[True,True],[True,True],[True,True],[True,True], [True,True],[True,True]] Integer factorization and List of primes test - sieve and other --- RESULT: [True,True] Properties and division in a residue ring Z/(b) - modelled as ResidueE Z: --- RESULT: [True,True] Arithmetic in P = Z[z,y,x] and in Z[x][y][z]. The isomorphism test for these domains: verify (^n) == fromP .(^n) .toP --- RESULT: Main: fromInteger to (Pol ..): use fromi -------------------------------------------------------------------- It breaks in the first half of the test. The reason may be, for example, in different treatment of overlapping instances. As to the DoCon message fromInteger to (Pol ..): use fromi , it means a run-time error: the code tries to make a polynomial :: (Pol _) from an Integer value by applying fromInteger, while DoCon allows for this only the operation `fromi'. Here (^n) in fromP .(^n) .toP (in one of the test modules in demotest/) is powering a polynomial to the degree n :: Integer. I am not sure, but the impression is that the code tries to convert n to the type (Pol _), which it must not do. 6.8.2 is correct here, and may27 maybe, confuses types or instances, I do not know. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From wb at arb-phys.uni-dortmund.de Thu May 29 07:56:59 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Thu May 29 07:50:03 2008 Subject: *BSD support in 6.8.3 References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> Message-ID: Simon Marlow schrieb: >> >> So, try the patch to get the patch to compile against ghc >> 6.8.3-snapshot, and see if it works on OpenBSD? > > It's not just a case of testing the patch, there are a couple of issues to > address: > > - it has a couple of wired-in addresses: one place to load object files, > another to put jump tables at. This is necessary because *BSD doesn't > have the MAP_32BIT flag for mmap(). However, the particular wired-in > addresses needed will probably vary on the different *BSDs. Someone > needs to look at the memory map and make sure we're picking sensible > addresses. It is not very likely that the adresses change between *BSDs because they are resulting from simple hardware-related constraints. Though, a test is necessary. OTOH, has anybody from the GHC team asked the *BSD developers to add a MAP_32BIT flag already? I know that these people are very reluctant to change requests, this one may find their mercy if the right persons ask for it. > - the patch doesn't #ifdef its changes, so it'll break other platforms > (easy to fix). > I looked into the patch, and it doesn't look as if it would break other platforms, as the changed code is inside proper ifdefs mostly. Some parts may be superfluous. The easiest check is to compile the FreeBSD-patched code under one of the other platforms (are there other than Linux and OSX?). In any case, the ifdef'ing can be automated using diff with -D__FreeBSD__ option. > Also the code has changed in HEAD, and we need a completely different patch > there (although the same idea applies, pick an address and use MAP_FIXED). This is, of course, the most significant problem for GHC, but probably not relevant to this special release process. It is better to include the patch than to leave it out (provided that I am right resp. to the breaking of otherplatforms). -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From mechvel at botik.ru Thu May 29 08:21:13 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 29 08:14:19 2008 Subject: SCC "ab cd" Message-ID: <20080529122113.GA18946@scico.botik.ru> Dear GHC developers, ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right. And the GHC candidate of May 27, 2008 reports the error: "spaces are not allowed in SCC". Do you think that this latter has more sense? Is not this a matter of the programmer to give string names to SCC points? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From isaacdupree at charter.net Thu May 29 09:07:32 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 29 09:00:31 2008 Subject: SCC "ab cd" In-Reply-To: <20080529122113.GA18946@scico.botik.ru> References: <20080529122113.GA18946@scico.botik.ru> Message-ID: <483EAA94.6000203@charter.net> Serge D. Mechveliani wrote: > Dear GHC developers, > > ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right. > > And the GHC candidate of May 27, 2008 reports the error: > > "spaces are not allowed in SCC". > > Do you think that this latter has more sense? > Is not this a matter of the programmer to give string names to SCC > points? see http://hackage.haskell.org/trac/ghc/ticket/2071 . Agree or disagree. "it probably never worked" -- Did you ever get any useful profiling information when you had spaces in your SCC? Or did it just not work anyway (in which case a sooner error message is probably better) -Isaac From igloo at earth.li Thu May 29 10:10:07 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 29 10:03:02 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080529114836.GA18601@scico.botik.ru> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20080528182858.GA16929@scico.botik.ru> <20080529094440.GA415@matrix.chaos.earth.li> <20080529114836.GA18601@scico.botik.ru> Message-ID: <20080529141006.GA12898@matrix.chaos.earth.li> On Thu, May 29, 2008 at 03:48:36PM +0400, Serge D. Mechveliani wrote: > > Main: fromInteger to (Pol ..): use fromi OK, I can reproduce this, but as we aren't familiar with the code, it would be very helpful if you could make a small case demonstrating the problem (i.e. something that doesn't depend on the huge docon library). Thanks Ian From donn at avvanta.com Thu May 29 11:15:40 2008 From: donn at avvanta.com (Donn Cave) Date: Thu May 29 11:08:41 2008 Subject: *BSD support in 6.8.3 In-Reply-To: References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> Message-ID: <20080529081540.f3728f08.donn@avvanta.com> On Thu, 29 May 2008 11:56:59 +0000 (UTC) "Wilhelm B. Kloke" wrote: > Simon Marlow schrieb: > > - it has a couple of wired-in addresses: one place to load object files, > > another to put jump tables at. This is necessary because *BSD doesn't > > have the MAP_32BIT flag for mmap(). However, the particular wired-in > > addresses needed will probably vary on the different *BSDs. Someone > > needs to look at the memory map and make sure we're picking sensible > > addresses. > > It is not very likely that the adresses change between *BSDs because > they are resulting from simple hardware-related constraints. Though, > a test is necessary. I have made some progress with NetBSD-amd64, now I'm working on stage2 of 6.8.2. So there's some hope that I may be able to look at this issue on that platform. (It's going pretty slow, though - lucky I got laid off last week and I have a 1.8 Ghz computer with nearly empty hard disk to work with, or building GHC would be just about out of the question!) But I noticed that, in Linker.c, NetBSD doesn't configure USE_MMAP - whatever the hardware platform. I don't know if that's just by neglect, but if I don't use mmap(), then support for MAP_32BIT is no concern? -- Donn Cave From marlowsd at gmail.com Thu May 29 11:19:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 29 11:12:22 2008 Subject: *BSD support in 6.8.3 In-Reply-To: References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> Message-ID: <483EC97C.8080908@gmail.com> Ok, I've now modified the patch and attached a new version to the ticket: http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch *BSD folks please test. Wilhelm B. Kloke wrote: > Simon Marlow schrieb: >>> So, try the patch to get the patch to compile against ghc >>> 6.8.3-snapshot, and see if it works on OpenBSD? >> It's not just a case of testing the patch, there are a couple of issues to >> address: >> >> - it has a couple of wired-in addresses: one place to load object files, >> another to put jump tables at. This is necessary because *BSD doesn't >> have the MAP_32BIT flag for mmap(). However, the particular wired-in >> addresses needed will probably vary on the different *BSDs. Someone >> needs to look at the memory map and make sure we're picking sensible >> addresses. > > It is not very likely that the adresses change between *BSDs because > they are resulting from simple hardware-related constraints. Though, > a test is necessary. These are virtual addresses, so hardware doesn't really come into it, right? I remember seeing memory maps change between versions of Linux in the past (i.e. where shared libraries are loaded, where the binary is loaded, etc.). We need to avoid clashing with anything else, otherwise the OS might allocate us an address outside the 2Gb range. > OTOH, has anybody from the GHC team asked the *BSD developers to add > a MAP_32BIT flag already? I know that these people are very reluctant > to change requests, this one may find their mercy if the right persons > ask for it. That's a good idea, I might try it. > I looked into the patch, and it doesn't look as if it would break other > platforms, as the changed code is inside proper ifdefs mostly. Some > parts may be superfluous. The easiest check is to compile the > FreeBSD-patched code under one of the other platforms (are there other than > Linux and OSX?). So the patch as it stands always passes 1Gb as the address to mmap(). This might have undesirable effects on other systems. I fixed that in the new version of the patch (see above). Cheers, Simon From mechvel at botik.ru Thu May 29 13:33:15 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 29 13:26:15 2008 Subject: SCC "ab cd" In-Reply-To: <483EAA94.6000203@charter.net> References: <20080529122113.GA18946@scico.botik.ru> <483EAA94.6000203@charter.net> Message-ID: <20080529173315.GA19637@scico.botik.ru> On Thu, May 29, 2008 at 09:07:32AM -0400, Isaac Dupree wrote: > Serge D. Mechveliani wrote: > >Dear GHC developers, > > > >ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right. > > > >And the GHC candidate of May 27, 2008 reports the error: > > > > "spaces are not allowed in SCC". > > > >Do you think that this latter has more sense? > >Is not this a matter of the programmer to give string names to SCC > >points? > > see http://hackage.haskell.org/trac/ghc/ticket/2071 . Agree or > disagree. "it probably never worked" -- Did you ever get any useful > profiling information when you had spaces in your SCC? Or did it just > not work anyway (in which case a sooner error message is probably better) Why, in ghc-6.8.2, it works in my Dumatel program: let ... (pairsPassed, pairsRest) = {-# SCC "(pairsPassed, pairsRest)" #-} span (not . isFalseTerm . fst) [(dj', c) | sb <- testingSubsts, let (_, dj', _reduction, c) = reduceDisjunct emptyUMRMemo jump calcExt [] $ substitute sb dj] ... in ... The SCC point is named so that it is easy to recall where in the source this point is set. Here it is better that denoting, say "103". Am I missing something? ----------------- Serge Mechveliani mechvel@botik.ru From marco-oweber at gmx.de Thu May 29 14:08:52 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 29 14:01:49 2008 Subject: ANNOUNCE: GHC 6.8.3 Release Candidate In-Reply-To: <20080528152033.GA6188@matrix.chaos.earth.li> References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: <20080529180852.GA22228@gmx.de> > Please test as much as possible; bugs are much cheaper if we find them > before the release! Hi Ian, I haven't done extensive testing, but at least you can start ghci and compile simple hello world apps on nixos 64 bit without trouble. I've noted that I had to use a more recent ghc for bootstrapping than ghc-6.4. Sincerly Marc Weber From twhitehead at gmail.com Thu May 29 23:48:11 2008 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu May 29 23:40:03 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) Message-ID: <483F78FB.2080207@gmail.com> main = print $ foldl' (+) 0 [1..] with foldl' f y xs = foldl' y xs where foldl' y [] = y foldl' y (x:xs) = foldl' (f y x) xs runs indefinitely with very little memory consumption, while foldl' f y [] = y foldl' f y (x:xs) = foldl' f (f y x) xs rapidly consumes all the machine's memory and dies. Running ghc with -ddump-stranal shows the outer foldl' of the first gets inlined into main as a call to the following specialized version of the inner foldl': foldl'_sSY [ALWAYS LoopBreaker Nothing] :: GHC.Num.Integer -> [GHC.Num.Integer] -> GHC.Num.Integer [Arity 2 Str: DmdType SS] foldl'_sSY = \ (y_aj7 [ALWAYS Just S] :: GHC.Num.Integer) (ds_dQl [ALWAYS Just S] :: [GHC.Num.Integer]) -> case ds_dQl of wild_XH [ALWAYS Just A] { [] -> y_aj7; : x_aja [ALWAYS Just S] xs_ajb [ALWAYS Just S] -> foldl'_sSY (GHC.Num.plusInteger y_aj7 x_aja) xs_ajb } Doing the same with the second foldl' shows it to remains non-inlined and fully polymorphic: foldl'_sQN [ALWAYS LoopBreaker Nothing] :: forall t_auW t_av2. (t_av2 -> t_auW -> t_av2) -> t_av2 -> [t_auW] -> t_av2 [Arity 3 Str: DmdType LLS] foldl'_sQN = \ (@ t_auW) (@ t_av2) (f_aj0 [ALWAYS Just L] :: t_av2 -> t_auW -> t_av2) (y_aj1 [ALWAYS Just L] :: t_av2) (ds_dQg [ALWAYS Just S] :: [t_auW]) -> case ds_dQg of wild_XK [ALWAYS Just A] { [] -> y_aj1; : x_aj5 [ALWAYS Just L] xs_aj6 [ALWAYS Just S] -> foldl'_sQN @ t_auW @ t_av2 f_aj0 (f_aj0 y_aj1 x_aj5) xs_aj6 } Forcing it inline with {-# INLINE foldl' #-} just specialized it: foldl'_sSS [ALWAYS LoopBreaker Nothing] :: (GHC.Num.Integer -> GHC.Num.Integer -> GHC.Num.Integer) -> GHC.Num.Integer -> [GHC.Num.Integer] -> GHC.Num.Integer [Arity 3 Str: DmdType LLS] foldl'_sSS = \ (f_aj0 [ALWAYS Just L] :: GHC.Num.Integer -> GHC.Num.Integer -> GHC.Num.Integer) (y_aj1 [ALWAYS Just L] :: GHC.Num.Integer) (ds_dQg [ALWAYS Just S] :: [GHC.Num.Integer]) -> case ds_dQg of wild_XI [ALWAYS Just A] { [] -> y_aj1; : x_aj5 [ALWAYS Just L] xs_aj6 [ALWAYS Just S] -> foldl'_sSS f_aj0 (f_aj0 y_aj1 x_aj5) xs_aj6 } I thought this was interesting. Is it to be expected? Am I right in interpreting this to mean it was just too much for the strictness analyzer. I believe the first ultimately produces significantly superior code, so should one always write their recursive functions such that the constant (functional?) parameters are first captured in a closure? In that vein, would it be useful if the compiler automatically transformed the second into the first? Thanks! -Tyson From dan.doel at gmail.com Fri May 30 00:17:44 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri May 30 00:10:41 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <483F78FB.2080207@gmail.com> References: <483F78FB.2080207@gmail.com> Message-ID: <200805300017.44825.dan.doel@gmail.com> On Thursday 29 May 2008, Tyson Whitehead wrote: > I thought this was interesting. Is it to be expected? Am I right in > interpreting this to mean it was just too much for the strictness > analyzer. I believe the first ultimately produces significantly > superior code, so should one always write their recursive functions such > that the constant (functional?) parameters are first captured in a closure? > > In that vein, would it be useful if the compiler automatically > transformed the second into the first? I've had similar experiences. I've been working on sorting the mutable arrays in the new uvector library, and on at least one occasion, changing from code like: foo f x y = ... foo f x' y' to code like: foo f = loop where loop x y = ... loop x' y' resulted in 50% faster code (that is, 10 seconds -> 5 seconds). It doesn't always make such a dramatic difference, but it seems significant enough to have gotten me in the habit of writing such code by default (for the sorting, at least, where I'm trying to squeeze out as much performance as possible). Unfortunately, I think the resulting code is somewhat ugly, as I occasionally end up with code like: foo a b = loop1 c where loop1 c d = loop2 e where loop2 e = ... which may or may not actually be faster with more or less nested loops, but trying each possibility is a bit of a pain. If the compiler could automatically derive the more straightforward definition into the fast one, it'd be quite a boon, but I haven't thought very hard about whether there are any pitfalls to doing so. -- Dan From Christian.Maeder at dfki.de Fri May 30 05:40:59 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri May 30 05:33:52 2008 Subject: darcs-2 executable for PowerPC Macintosh In-Reply-To: References: Message-ID: <483FCBAB.8060603@dfki.de> I was able to statically link in libgmp.a by changing my installation: 1. I've copied libgmp.a into /lib/ghc-6.8.2 2. I've changed /lib/ghc-6.8.2/package.conf manually: changed: ], frameworkDirs = [], frameworks = ["GMP"], to: ,"-lgmp"], frameworkDirs = [], frameworks = [], so that "-lgmp" is in ldOptions and frameworks are empty 3. called ghc with the additional flags: -optl-Xlinker -optl-search_paths_first HTH Christian zooko wrote: > Here is a darcs-2 executable for PowerPC Mac. It was built on Mac OS > 10.4, and this tarball includes the "GMP.framework", which > (unfortunately) you have to copy into /Library/Frameworks or ~/ > Library/Frameworks before darcs will run. > > If any Haskell experts can tell me how to statically link or remove > this dependency on this GMP.framework I would like to know, and then > I can build a darcs binary which doesn't require such a step during > installation. > > https://zooko.com/darcs-2-mac-powerpc.tar.bz2 > > Regards, > > Zooko From duncan.coutts at worc.ox.ac.uk Fri May 30 05:56:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 30 05:46:41 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <483F78FB.2080207@gmail.com> References: <483F78FB.2080207@gmail.com> Message-ID: <1212141413.15010.14.camel@localhost> On Thu, 2008-05-29 at 23:48 -0400, Tyson Whitehead wrote: > main = print $ foldl' (+) 0 [1..] > > with > > foldl' f y xs = foldl' y xs > where foldl' y [] = y > foldl' y (x:xs) = foldl' (f y x) xs > > runs indefinitely with very little memory consumption, while > > foldl' f y [] = y > foldl' f y (x:xs) = foldl' f (f y x) xs > > rapidly consumes all the machine's memory and dies. This is for two reasons. One is because your second foldl' is directly recursive so does not get inlined. The static argument transformation it what you're doing manually to turn the latter into the former. The SAT is implemented in ghc 6.9 (though it seems to be having integration problems). The reason the second version consumes all the memory is because it is not strict in the accumulator. You're misleading yourself by calling it foldl', you've actually written the standard foldl. The reason the first version does not consume all the memory is because once foldl' got inlined there is enough information for the strictness analyser to see that it is indeed all strict (for the particular parameters, not for all possible parameters as is the case with the real foldl'). Duncan From simonpj at microsoft.com Fri May 30 09:30:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 30 09:23:23 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <483F78FB.2080207@gmail.com> References: <483F78FB.2080207@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE58CEC20@EA-EXMSG-C334.europe.corp.microsoft.com> | main = print $ foldl' (+) 0 [1..] | | with | | foldl' f y xs = foldl' y xs | where foldl' y [] = y | foldl' y (x:xs) = foldl' (f y x) xs | | runs indefinitely with very little memory consumption, while | | foldl' f y [] = y | foldl' f y (x:xs) = foldl' f (f y x) xs | | rapidly consumes all the machine's memory and dies. Others have explained this nicely. But there's a real tension here. The fast version comes from a combination of (a) the static argument transformation, so you get the first version above, and (b) bodily inlining the entire function, so that at *each call site* you get a locally-recursive function where 'f' is known. That's ok for small functions, but not so good for big ones. Furthermore, the code duplication is only worthwhile if the specialisation is truly useful. For example, would it be better to write append like this (++) xs ys = letrec app [] = ys app (x:xs) = x : app xs in app xs and inline that at every call of (++)? Probably not. So that is why GHC does not automate this transformation. If you know that's what you want, write a local recursion, and use an INLINE pragma. If someone felt like summarising this thread on the Haskell performance-advice wiki that would be great. http://haskell.org/haskellwiki/Performance Meanwhile, I'll clarify in the user manual that recursive functions are not inlined. Simon From bulat.ziganshin at gmail.com Fri May 30 09:32:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 30 09:46:55 2008 Subject: Recursive functions and constant parameter closures (inlining/strictness analyzer question) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE58CEC20@EA-EXMSG-C334.europe.corp.microsoft.com> References: <483F78FB.2080207@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE58CEC20@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <413713693.20080530173211@gmail.com> Hello Simon, Friday, May 30, 2008, 5:30:25 PM, you wrote: may be i don't understand something. isn't it better to do automatic SAT and inline results for every recursive function marked as INLINE? it's how i want to work - just mark with INLINE speed-critical funcs. manual checking that they are recursive and doing appropriate transformation is too hard for me :) and, btw, how about adding warnings about functions marked as INLINE which was not actually inlined due to some reasons - may be very helpful for optimizing programs without going into studying Core output > Others have explained this nicely. But there's a real tension > here. The fast version comes from a combination of (a) the static > argument transformation, so you get the first version above, and (b) > bodily inlining the entire function, so that at *each call site* you > get a locally-recursive function where 'f' is known. That's ok for > small functions, but not so good for big ones. Furthermore, the > code duplication is only worthwhile if the specialisation is truly > useful. For example, would it be better to write append like this > (++) xs ys = letrec app [] = ys > app (x:xs) = x : app xs > in app xs > and inline that at every call of (++)? Probably not. > So that is why GHC does not automate this transformation. If you > know that's what you want, write a local recursion, and use an INLINE pragma. > If someone felt like summarising this thread on the Haskell > performance-advice wiki that would be great. > http://haskell.org/haskellwiki/Performance > Meanwhile, I'll clarify in the user manual that recursive functions are not inlined. > Simon > _______________________________________________ > 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 gwright at comcast.net Fri May 30 10:43:22 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri May 30 10:36:15 2008 Subject: *BSD support in 6.8.3 In-Reply-To: <483EC97C.8080908@gmail.com> References: <483D205E.5010004@gmail.com> <20080528174616.GA10471@scytale.galois.com> <483E915A.3090606@gmail.com> <483EC97C.8080908@gmail.com> Message-ID: Hi Simon, On May 29, 2008, at 11:19 AM, Simon Marlow wrote: > Ok, I've now modified the patch and attached a new version to the > ticket: > > http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch > > *BSD folks please test. > I built the 20080529 snapshot with this patch and my light testing of ghci showed no problems (FreeBSD 7.0/x86_64). I will built it again tonight in a darcs checkout and run the test suite. I should be able to send back any tweaks to the patch in the next two days. -Greg From simonpj at microsoft.com Fri May 30 10:44:20 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 30 10:37:13 2008 Subject: GHC rewrite rules pragma In-Reply-To: <20080527172244.GB8351@scytale.galois.com> References: <20080527172244.GB8351@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE58CEC9C@EA-EXMSG-C334.europe.corp.microsoft.com> | This is the main wibble people forget when writing rules -- inlining. | In your example, 'gen' is so cheap, it is immediately | inlined, so it won't be available to match on in your rule. I'll add a note in the user manual about this. In general, GHC tries RULES before inlining. In this particular example that fails for a tiresome internal reason -- but in any case the solution Don mentions is noticeably more robust. Simon | | Anything you want to match should have its inlining delayed: | | {-# OPTIONS -O2 -fglasgow-exts #-} | | gen :: [a] -> a | gen = head | {-# INLINE [1] gen #-} | | {-# RULES | "gen/Char" gen = spec | #-} | | spec :: [Char] -> Char | spec x = 'x' | | main :: IO () | main = putStr (gen "aaa":"\n") | | Running this in ghc-core, we see: | | RuleFired | 1 gen/Char | | Good. | And the program prints out: | | $ ./A | x | | There was some discussion of adding a warning for any function | used in the left hand side of a rewrite rule, that doesn't have | precise inlining control added. That would have caught this. | | -- Don | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dgorin at dc.uba.ar Sat May 31 22:54:40 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Sat May 31 22:48:08 2008 Subject: [Haskell-cafe] hint / ghc api and reloading modules In-Reply-To: <2518b95d0805311046k7cc66919u6adc9fc2771e0a5c@mail.gmail.com> References: <2518b95d0805311046k7cc66919u6adc9fc2771e0a5c@mail.gmail.com> Message-ID: (Since this can be of interest to those using the ghc-api I'm cc-ing the ghc users' list.) Hi, Evan The odd behavior you spotted happens only with hint under ghc-6.8. It turns out the problem was in the session initialization. Since ghc-6.8 the newSession function no longer receives a GhcMode. The thing is that, apparently, if one was passing the Interactive mode to newSession under ghc-6.6, now you ought to set the ghcLink dynflag to LinkInMemory instead. I couldn't find this documented anywhere (except for this patch http://www.haskell.org/pipermail/cvs-ghc/2007-April/034974.html) but it is what ghci is doing and after patching hint to do this the reloading of modules works fine. I'll be uploading a fixed version of hint to hackage in the next days. Thanks, Daniel On May 31, 2008, at 2:46 PM, Evan Laforge wrote: > I'm using "hint", but since it's basically a thin wrapper around the > GHC API, this is probably a GHC api question too. Maybe this should > go to cvs-ghc? Let me know and I'll go subscribe over there. > > It's my impression from the documentation that I should be able to > load a module interpreted, make changes to it, and then reload it. > This is, after all what ghci does. It's also my impression that the > other imported modules should be loaded as object files, if the .hi > and .o exist, since this is also what ghci does. > > However, if I load a module and run code like so (using hint): > > GHC.loadModules ["Cmd.LanguageEnviron"] > GHC.setTopLevelModules ["Cmd.LanguageEnviron"] > GHC.setImports ["Prelude"] > cmd_func <- GHC.interpret (mangle_code text) (GHC.as :: LangType) > > It works fine until I change LanguageEnviron. If I make a change to a > function, I don't see my changes in the output, as if the session is > only getting partially reset. If I insert a syntax error, then I do > see it, so it is recompiling the file in some way. However, if I > *rename* the function and call it with the new name, I get a > GhcException: > > During interactive linking, GHCi couldn't find the following symbol: > ... etc. > > So I examined the code in hint for loadModules and the code in > ghci/InteractiveUI.hs:/loadModule, and they do look like they're doing > basically the same things, except a call to rts_revertCAFs, which I > called too just for good measure but it didn't help (I can't find its > source anywhere, but the ghci docs imply it's optional, so I suspect > it's a red herring). > > Here's a condensed summary of what hint is doing: > -- reset > GHC.setContext session [] [] > GHC.setTargets session [] > GHC.load session GHC.LoadAllTargets > -- rts_revertCAFs > > -- load > targets <- mapM (\f -> GHC.guessTarget f Nothing) fs > GHC.setTargets session targets > GHC.load session GHC.LoadAllTargets > > -- interpret > let expr_typesig = "($expr) :: xyz" > expr_val <- GHC.compileExpr session expr_typesig > return (GHC.Exts.unsafeCorce# expr_val :: a) > > -- GHC.compileExpr > maybe_stuff <- hscStmt hsc_env ("let __cmCompileExpr = "++expr) > ([n],[hv]) <- (unsafeCoerce# hval) :: IO [HValue] > return (Just hv) > > > and then ghci does: > -- load > GHC.setTargets session [] > GHC.load session LoadAllTargets > > targets <- io (mapM (uncurry GHC.guessTarget) files') > GHC.setTargets session targets > GHC.load session LoadAllTargets > > rts_revertCAFs > putStrLn "Ok, modules loaded: $modules" > > -- interpret > GHC.runStmt session stmt step > > -- GHC.runStmt > Just (ids, hval) <- hscStmt hsc_env' expr > coerce hval to (IO [HValue]) and run it carefully > > > So it *looks* like I'm doing basically the same thing as ghci... > except obviously I'm not because ghci reloads modules without any > trouble. Before I go start trying to make hint even more identical to > ghci, is there anything obviously wrong here that I'm doing? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe