From alistair at abayley.org Tue Jul 1 07:46:21 2008 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jul 1 07:37:31 2008 Subject: Takusen build error In-Reply-To: References: Message-ID: <79d7c4980807010446x99c7365mcf07492187752d02@mail.gmail.com> > I get a strange error building Takusen (more precisely: the module > Foreign/C/UTF8.hs) with ghc-6.8.3. It says > > [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, > dist/build/Foreign/C/UTF8.o ) > /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: > > /tmp/ghc18936_0/ghc18936_0.s:1257:0: > Error: symbol `base_GHCziBase_Z0T_closure' is already defined > > I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. What happens when you say: ghc -c Foreign/C/UTF8.hs I expect you get the same error. If so, then this is one for ghc maintainers. If not, then we'll have to do some more digging. Alistair From Christian.Maeder at dfki.de Tue Jul 1 09:49:34 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jul 1 09:40:45 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> <485BCEAC.1000509@dfki.de> <485BD7A3.1070301@dfki.de> <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <486A35EE.90309@dfki.de> Since I've switched back from ghc-6.8.3 to ghc-6.8.2 I would like to see a new minor ghc version 6.8.4 with this "bug" fixed. Cheers Christian Simon Peyton-Jones wrote: > As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function > instance C T where > op = op_T > > op_T = .... > > But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned. From igloo at earth.li Tue Jul 1 11:32:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 1 11:23:57 2008 Subject: Takusen build error In-Reply-To: References: Message-ID: <20080701153247.GA5272@matrix.chaos.earth.li> On Mon, Jun 30, 2008 at 02:25:22PM +0200, Benjamin Franksen wrote: > I get a strange error building Takusen (more precisely: the module > Foreign/C/UTF8.hs) with ghc-6.8.3. It says > > /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: > > /tmp/ghc18936_0/ghc18936_0.s:1257:0: > Error: symbol `base_GHCziBase_Z0T_closure' is already defined Thanks for the report; I've filed a bug here: http://hackage.haskell.org/trac/ghc/ticket/2409 As a workaround, removing the (redundant) uses of () `seq` in Foreign/C/UTF8.hs makes the build go through. Thanks Ian From christian.hoener at uni-bielefeld.de Tue Jul 1 11:37:35 2008 From: christian.hoener at uni-bielefeld.de (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Tue Jul 1 11:28:57 2008 Subject: X11-1.4.2 on 64bit Fedora 8 fails to build Message-ID: <20080701153735.GA18237@tinytux.univie.ac.at> Hi, I'm trying to get X11-1.4.1 compiled on a 64 bit x86 Fedora 8 system. runhaskell Setup.hs configure --prefix $HOME/ghc has no problems but runhaskell Setup.hs build produces: Preprocessing library X11-1.4.2... /usr/bin/ld: skipping incompatible /usr/lib/libXinerama.so when searching for -lXinerama /usr/bin/ld: cannot find -lXinerama collect2: ld returned 1 exit status linking dist/build/Graphics/X11/Types_hsc_make.o failed command was: /scr/airline/choener/ghc-6.8.3/bin/ghc -optl-lXinerama \ -optl-lXext -optl-lX11 -optl-L/usr/lib64 \ dist/build/Graphics/X11/Types_hsc_make.o -o \ dist/build/Graphics/X11/Types_hsc_make Trying something like runhaskell Setup.hs configure --ld-options="-nostdlib -L/usr/lib64" runhaskell Setup.hs build --ld-options="-nostdlib -L/usr/lib64" does not change the fact that ld looks in the wrong place for libXinerama. It looks in /usr/lib, but should look in /usr/lib64. Btw. I don't have root on the machine. Thanks, Christian H?ner zu Siederdissen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080701/5f0a9665/attachment.bin From Christian.Maeder at dfki.de Wed Jul 2 07:25:35 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 2 07:16:51 2008 Subject: ANNOUNCE: GHC version 6.8.3 binary-dists In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080617185945.GA2262@matrix.chaos.earth.li> <485B74D2.8030703@dfki.de> <485BC7AB.3080603@gmail.com> <485BCEAC.1000509@dfki.de> <485BD7A3.1070301@dfki.de> <638ABD0A29C8884A91BC5FB5C349B1C32AE6D38909@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <486B65AF.6090605@dfki.de> Simon Peyton-Jones wrote: > As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function > instance C T where > op = op_T > > op_T = .... I've changed our generation of instances to follow this pattern and indeed the object code size is much smaller! This is a workaround for http://hackage.haskell.org/trac/ghc/ticket/955 Thanks Christian From benjamin.franksen at bessy.de Wed Jul 2 10:10:54 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 10:02:13 2008 Subject: Takusen build error References: <79d7c4980807010446x99c7365mcf07492187752d02@mail.gmail.com> Message-ID: Alistair Bayley wrote: >> I get a strange error building Takusen (more precisely: the module >> Foreign/C/UTF8.hs) with ghc-6.8.3. It says >> >> [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, >> dist/build/Foreign/C/UTF8.o ) >> /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: >> >> /tmp/ghc18936_0/ghc18936_0.s:1257:0: >> Error: symbol `base_GHCziBase_Z0T_closure' is already defined >> >> I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. > > What happens when you say: > ghc -c Foreign/C/UTF8.hs > > I expect you get the same error. Yes. > If so, then this is one for ghc maintainers. Indeed, it seems so, as Ian Lynagh wrote: > Thanks for the report; I've filed a bug here: > http://hackage.haskell.org/trac/ghc/ticket/2409 > > As a workaround, removing the (redundant) uses of > () `seq` > in Foreign/C/UTF8.hs makes the build go through. Thanks, Ian, for the quick response and the work-around which works fine for me. Cheers Ben From waldmann at imn.htwk-leipzig.de Thu Jul 3 05:00:19 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Jul 3 04:51:25 2008 Subject: ghc-6.8.1 on solaris-sparc Message-ID: <486C9523.40305@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I am assuming that 6.8.1 is the latest binary release for solaris-sparc? When I try to call ghc, it says ld.so.1: ghc-6.8.1: fatal: relocation error: file /usr/local/lib/libncurses.so.5: symbol main: referenced symbol not found my machine is: sparc-sun-solaris2.10 I think I have all the necessary packages: ldd /home/waldmann/built/lib/ghc-6.8.1/ghc-6.8.1 librt.so.1 => /lib/librt.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /home/waldmann/built/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd.so.1 => /lib/libmd.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /platform/SUNW,Sun-Fire-V445/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-V445/lib/libmd_psr.so.1 but this looks strange: nm /usr/local/lib/libncurses.so.5|grep main [1192] | 0| 0|NOTY |GLOB |0 |UNDEF |main Any hints appreciated - J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIbJUjDqiTJ5Q4dm8RAqWvAKCAwkVKJgLnLL3Uz0rr3Yp3AzVQmACfVyEe n3LqWHh2zvaeGopm4t7xpSc= =nryk -----END PGP SIGNATURE----- From Christian.Maeder at dfki.de Thu Jul 3 10:14:06 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jul 3 10:05:16 2008 Subject: ghc-6.8.1 on solaris-sparc In-Reply-To: <486C9523.40305@imn.htwk-leipzig.de> References: <486C9523.40305@imn.htwk-leipzig.de> Message-ID: <486CDEAE.4080808@dfki.de> Johannes Waldmann wrote: > nm /usr/local/lib/libncurses.so.5|grep main > > [1192] | 0| 0|NOTY |GLOB |0 |UNDEF |main I get no output at all. Christian From rl at cse.unsw.edu.au Fri Jul 4 21:20:28 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Jul 4 21:11:32 2008 Subject: Generalized phase control for GHC In-Reply-To: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> Message-ID: <486ECC5C.80406@cse.unsw.edu.au> Hi Max, sorry for replying so late, I've completely forgotten about this. > I would be interested in feedback on the design before the > implementation is complete and in the wild. I'm especially interested > in hearing if you believe that loss of support for numeric phase > numbers > 2 is a problem, as this is the only breaking change that I'm > proposing. Three things. Firstly, what would lenient ordering be useful for? You probably had a specific use case in mind? Secondly, I think it is quite important to be able to specify dependencies for already declared phases. That is, I (probably) want to be able to say in module C that phase X from module A should come before phase Y from module B. I suspect that's not quite possible with your current design. Lastly, in addition to < and > I'd also like to have = (i.e., phase X = phase Y which would make X an alias for Y). As to the numeric phase ids, I'm all in favour of dropping them altogether. For legacy code, you could provide wired-in names 0, 1 and 2 for now but I would deprecate them. Also, I'm one of the probably very few people who have ever used phase 3 and beyond and dropping support for that is perfectly fine with me. Thanks for working on this! Roman From batterseapower at hotmail.com Sat Jul 5 04:12:00 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Jul 5 04:03:08 2008 Subject: Generalized phase control for GHC In-Reply-To: <486ECC5C.80406@cse.unsw.edu.au> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> Message-ID: <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> Hi Roman, > Three things. Firstly, what would lenient ordering be useful for? You > probably had a specific use case in mind? I suspect that when you have multiple plugins all specifying constraints on the phase ordering independently it is possible to end up in a situation where using each plugin individually results in a consistent phase ordering but a combination of multiple plugins causes a cycle to appear in the order. Hence it is useful to let plugin authors flag up dependencies they don't >need< to have so we can intellegently break the cycle using those constraints rather than just giving up. Admittedly I only have a superstition that this will be a practical problem. > Secondly, I think it is quite > important to be able to specify dependencies for already declared phases. > That is, I (probably) want to be able to say in module C that phase X from > module A should come before phase Y from module B. This in interesting. You're right that it's not possible with this system: to support this you would need a more class + instance rather than single declaration flavour for phases. Do you have a practical example in mind of how you would use it? > I suspect that's not > quite possible with your current design. Lastly, in addition to < and > I'd > also like to have = (i.e., phase X = phase Y which would make X an alias for > Y). Ah! This would also let you do what you wanted with your second point: module C where {-# PHASE XAlias = A.X, < B.Y #-} This could indeed be useful, and since it subsumes your other proposal without complicating the phase declaration experience this looks like a good extension to have. > As to the numeric phase ids, I'm all in favour of dropping them altogether. > For legacy code, you could provide wired-in names 0, 1 and 2 for now but I > would deprecate them. Also, I'm one of the probably very few people who have > ever used phase 3 and beyond and dropping support for that is perfectly fine > with me. Agreed: we should deprecate numeric ids if we have this alternative. Thanks for your interesting comments! Max From rl at cse.unsw.edu.au Sat Jul 5 06:46:40 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sat Jul 5 06:37:41 2008 Subject: Generalized phase control for GHC In-Reply-To: <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> Message-ID: <486F5110.3090202@cse.unsw.edu.au> Max Bolingbroke wrote: > Hi Roman, >> Three things. Firstly, what would lenient ordering be useful for? You >> probably had a specific use case in mind? > > I suspect that when you have multiple plugins all specifying > constraints on the phase ordering independently it is possible to end > up in a situation where using each plugin individually results in a > consistent phase ordering but a combination of multiple plugins causes > a cycle to appear in the order. Hence it is useful to let plugin > authors flag up dependencies they don't >need< to have so we can > intellegently break the cycle using those constraints rather than just > giving up. Admittedly I only have a superstition that this will be a > practical problem. If you don't need a dependency and it can be ignored anyway, why would you want to specify it in the first place? I just can't quite imagine a situation in which I would use this. As to cycles, I think just aborting if they occur would be ok. >> Secondly, I think it is quite >> important to be able to specify dependencies for already declared phases. >> That is, I (probably) want to be able to say in module C that phase X from >> module A should come before phase Y from module B. > > This in interesting. You're right that it's not possible with this > system: to support this you would need a more class + instance rather > than single declaration flavour for phases. Do you have a practical > example in mind of how you would use it? Yeah, I'd prefer the class/instance model. An example: suppose you have two independent libraries which implement two optimisations and you want one of them to run before another. I think we really need this if we want to compose optimisations. >> I suspect that's not >> quite possible with your current design. Lastly, in addition to < and > I'd >> also like to have = (i.e., phase X = phase Y which would make X an alias for >> Y). > > Ah! This would also let you do what you wanted with your second point: > > module C where > {-# PHASE XAlias = A.X, < B.Y #-} True. It's a bit of a hack, though :-) Roman From batterseapower at hotmail.com Sat Jul 5 13:03:30 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Jul 5 12:54:27 2008 Subject: Generalized phase control for GHC In-Reply-To: <486F5110.3090202@cse.unsw.edu.au> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> <486F5110.3090202@cse.unsw.edu.au> Message-ID: <9d4d38820807051003l553a059dv29de29911c22469f@mail.gmail.com> > If you don't need a dependency and it can be ignored anyway, why would you > want to specify it in the first place? I just can't quite imagine a > situation in which I would use this. I think it makes sense because many of the inter-pass dependencies we have in the GHC pipeline today are actually somewhat lenient. For example, something quite sensible will happen if we do CSE before full laziness, it will simply lead to less efficient code. In contrast, it's imperative that we perform strictness analysis before applying worker-wrapper based on the annotations it adds. > Yeah, I'd prefer the class/instance model. An example: suppose you have two > independent libraries which implement two optimisations and you want one of > them to run before another. I think we really need this if we want to > compose optimisations. This is an interesting observation. So, you imagine that the >user program itself< might import the compiler plugins and add a constraint between the phases they export. I'm not sure how many users would really want to do this, but I can see it being useful. Thanks for your input: I've got a lot to think about now. Max From rl at cse.unsw.edu.au Sun Jul 6 01:00:00 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Jul 6 00:50:59 2008 Subject: Generalized phase control for GHC In-Reply-To: <9d4d38820807051003l553a059dv29de29911c22469f@mail.gmail.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> <486F5110.3090202@cse.unsw.edu.au> <9d4d38820807051003l553a059dv29de29911c22469f@mail.gmail.com> Message-ID: <48705150.8030102@cse.unsw.edu.au> Max Bolingbroke wrote: >> If you don't need a dependency and it can be ignored anyway, why would you >> want to specify it in the first place? I just can't quite imagine a >> situation in which I would use this. > > I think it makes sense because many of the inter-pass dependencies we > have in the GHC pipeline today are actually somewhat lenient. For > example, something quite sensible will happen if we do CSE before full > laziness, it will simply lead to less efficient code. In contrast, > it's imperative that we perform strictness analysis before applying > worker-wrapper based on the annotations it adds. I see. I suspect I'd prefer if GHC asked me to manually resolve such conflicts rather than silently generating suboptimal code but then again, perhaps not. In any case, my comments mostly apply to phase control for inlining and rule matching; other passes probably have different requirements which I haven't thought about at all. >> Yeah, I'd prefer the class/instance model. An example: suppose you have two >> independent libraries which implement two optimisations and you want one of >> them to run before another. I think we really need this if we want to >> compose optimisations. > > This is an interesting observation. So, you imagine that the >user > program itself< might import the compiler plugins and add a constraint > between the phases they export. I'm not sure how many users would > really want to do this, but I can see it being useful. What I had in mind is a library/plugin which uses other libraries/plugins. For instance, let's say we have two libraries which both implement rule-based fusion, one for some high-level stuff and one for something low level. Now, a third library which uses the first two might want to specify that high-level fusion should be done before low-level fusion. Or consider something like loop optimisations, where you might have separate plugins which implement unrolling, PRE and so on and one plugin which aggregates all these to provide a complete loop optimiser. It's all about compositionality, really. Roman From claus.reinke at talk21.com Sun Jul 6 18:02:12 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Jul 6 17:53:08 2008 Subject: using ghc-paths and rlwrap with GHCi - two additions to the GHCi HaskellWiki Message-ID: <00ec01c8dfb3$f2b90190$65238351@cr3lt> 1. If you ever find yourself inside a GHCi session, wondering what packages are installed for this very GHCi, whereever those OpenGL modules were located in the module hierarchy, what package that module belongs to, or where the library docs are, well, anything that means you need to find the *matching ghc-pkg*, or the *matching users_guide* for your GHCi session, you can exploit Simon's new ghc-paths package (also for GHC API clients who need to find that libdir for their session): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths This wiki entry suggests some command :defs, using ghc-paths to call the right ghc-pkg, or open the right users_guide from within a GHCi session: http://www.haskell.org/haskellwiki/GHC/GHCi#Package_and_documentation_lookup_in_GHCi.2C_via_ghc-paths 2. If you're using GHCi on windows, you're probably missing out on its commandline completion support - rlwrap can get you at least some of that (might also be interesting for other Haskell apps that can't or won't use readline/editline for user input). This wiki entry shows basic usage, and how to extract lists of GHC options and package modules, for completion purposes: http://www.haskell.org/haskellwiki/GHC/GHCi#rlwrap_-_what_to_try_when_your_GHCi_was_compiled_without_readline.2Feditline Enjoy (and don't forget to add your own tips&tricks to that wiki page!-), Claus From simonpj at microsoft.com Mon Jul 7 05:17:59 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jul 7 05:08:55 2008 Subject: Generalized phase control for GHC In-Reply-To: <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> | giving up. Admittedly I only have a superstition that this will be a | practical problem. I agree with Roman -- let's not bother with lenience until we need it | > Secondly, I think it is quite | > important to be able to specify dependencies for already declared phases. | > That is, I (probably) want to be able to say in module C that phase X from | > module A should come before phase Y from module B. | | This in interesting. You're right that it's not possible with this | system: to support this you would need a more class + instance rather | than single declaration flavour for phases. Do you have a practical | example in mind of how you would use it? Ah -- Roman you mean you want to add a phase-ordering constraint at some time *other* than when you declare one or other of the phases. Are you sure this is important? It's an awkward addition because, like orphan instances, it means there's an interface file with perhaps-vital info which you might have no other reason to visit. Also, why do you want phase aliases? Simon From batterseapower at hotmail.com Mon Jul 7 06:00:23 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jul 7 05:51:23 2008 Subject: Generalized phase control for GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9d4d38820807070300m738b6446la12d675b72318429@mail.gmail.com> > Ah -- Roman you mean you want to add a phase-ordering constraint at some time *other* than when you declare one or other of the phases. Are you sure this is important? It's an awkward addition because, like orphan instances, it means there's an interface file with perhaps-vital info which you might have no other reason to visit. I've begun to think that we need some generalized framework for gathering "orphaned" information since, as we discussed, the same problem occurs with my new annotations system (http://blog.omega-prime.co.uk/2008/07/05/compiler-plugins-for-ghc-weeks-three-and-four/) if you wish to implement the ability to annotate identifiers from other modules. Max From rl at cse.unsw.edu.au Mon Jul 7 07:34:31 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Jul 7 07:25:29 2008 Subject: Generalized phase control for GHC In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4871FF47.6050504@cse.unsw.edu.au> Simon Peyton-Jones wrote: > > Ah -- Roman you mean you want to add a phase-ordering constraint at some time *other* than when you declare one or other of the phases. Are you sure this is important? Fairly. I've explained why in a follow-up to Max's message. > Also, why do you want phase aliases? Modularity. Let's take NDP fusion as an example. We have 2 logically distinct fusion phases, one for fusing distributed stuff and one for stream fusion (let's call the DIST and STREAM). At the moment, the two are performed simultaneously, i.e., we have DIST = STREAM. However, I suspect that having DIST < STREAM might produce better results. This means that I'd like to use INLINE DIST when implementing distributed fusion, INLINE STREAM for stream fusion and only have one place where I declare DIST = STREAM or DIST < STREAM. I don't quite see how to achieve this without aliases. This will be even more of a problem once I add additional fusion layers. Incidentially, this is also an example of why adding ordering constraints on already declared phases is useful. Neither of the two fusion systems really depends on the other so it would be nice to be able to put the DIST < STREAM or DIST = STREAM declaration into a module which *integrates* the two. Roman From batterseapower at hotmail.com Mon Jul 7 16:52:50 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jul 7 16:43:42 2008 Subject: Generalized phase control for GHC In-Reply-To: <4871FF47.6050504@cse.unsw.edu.au> References: <9d4d38820806141815s6bff3f3fuc77928121c64b3fb@mail.gmail.com> <486ECC5C.80406@cse.unsw.edu.au> <9d4d38820807050112m7a70491fo25c1196d3ff9003a@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE741BAEA@EA-EXMSG-C334.europe.corp.microsoft.com> <4871FF47.6050504@cse.unsw.edu.au> Message-ID: <9d4d38820807071352r366edf3ah62acd7ebd564c2c9@mail.gmail.com> >> Also, why do you want phase aliases? > > I don't quite see how to achieve this without aliases. This > will be even more of a problem once I add additional fusion layers. I've added phase equality to the implementation. It seems like a nice clean extension. Since this lets you add constraints to existing phases (given that the module defining the phase alias that accomplishes this is directly or indirectly imported into every affected module) I'm going to hold off on the "class/instance" style. Although it might be nice, it's rather complicated, and we can retrofit it at a later date if it turns out to be essential. Cheers, Max From marlowsd at gmail.com Fri Jul 11 05:08:52 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 11 04:59:34 2008 Subject: Weekly IRC meeting? Message-ID: <48772324.5070304@gmail.com> Hi folks, I've been wondering whether it would be useful to have a weekly IRC meeting to discuss GHC. The idea would be that this is a scheduled time when the developers turn up on #ghc, we'll discuss current topics around GHC, and users can chime in with questions, points for discussion, complaints :-) and so on. I imagine making it completely informal to begin with, and later adding some structure (an agenda etc.) if necessary. Another option is a conference call, but personally I prefer the IRC medium for this kind of meeting. A conference call could work too, though. Thoughts? I'm thinking a time around 1600 UK time (currently UTC+1) would probably work best, does anyone have preferences for days? Cheers, Simon From bulat.ziganshin at gmail.com Fri Jul 11 05:21:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 11 05:10:18 2008 Subject: Weekly IRC meeting? In-Reply-To: <48772324.5070304@gmail.com> References: <48772324.5070304@gmail.com> Message-ID: <1185138972.20080711132152@gmail.com> Hello Simon, Friday, July 11, 2008, 1:08:52 PM, you wrote: > Another option is a conference call, but personally I prefer the IRC medium > for this kind of meeting. A conference call could work too, though. i propose to sent every meeting log into cvs-ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Christian.Maeder at dfki.de Fri Jul 11 06:53:00 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 11 06:43:39 2008 Subject: cvs.haskell.org Message-ID: <48773B8C.2050402@dfki.de> Hi, What happened to the haskell cvs server? I used to get the programatica sources from there. But cvs -d :pserver:anoncvs@cvs.haskell.org:/cvs co -P programatica times out. monk.galois.com (69.30.63.197) Cheers Christian From johan.tibell at gmail.com Fri Jul 11 08:50:52 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Jul 11 08:41:32 2008 Subject: cvs.haskell.org In-Reply-To: <48773B8C.2050402@dfki.de> References: <48773B8C.2050402@dfki.de> Message-ID: <90889fe70807110550y6f06e89bk7310a40a58e6da70@mail.gmail.com> I've been trying to get the latest haskell-mode the last few weeks without success. On Fri, Jul 11, 2008 at 12:53 PM, Christian Maeder wrote: > Hi, > > What happened to the haskell cvs server? I used to get the programatica > sources from there. > > But > cvs -d :pserver:anoncvs@cvs.haskell.org:/cvs co -P programatica > times out. > > monk.galois.com (69.30.63.197) > > Cheers Christian > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From johan.tibell at gmail.com Fri Jul 11 09:03:05 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Jul 11 08:53:44 2008 Subject: Weekly IRC meeting? In-Reply-To: <48772324.5070304@gmail.com> References: <48772324.5070304@gmail.com> Message-ID: <90889fe70807110603s4706972ye78a6b67f558bd67@mail.gmail.com> On Fri, Jul 11, 2008 at 11:08 AM, Simon Marlow wrote: > Hi folks, > > I've been wondering whether it would be useful to have a weekly IRC meeting > to discuss GHC. The idea would be that this is a scheduled time when the > developers turn up on #ghc, we'll discuss current topics around GHC, and > users can chime in with questions, points for discussion, complaints :-) and > so on. I imagine making it completely informal to begin with, and later > adding some structure (an agenda etc.) if necessary. I would definitely be interested. 16:00 UK time would work for me. Personally I'd have an easier time attending during work hours. From dons at galois.com Fri Jul 11 13:33:58 2008 From: dons at galois.com (Don Stewart) Date: Fri Jul 11 13:24:40 2008 Subject: Weekly IRC meeting? In-Reply-To: <48772324.5070304@gmail.com> References: <48772324.5070304@gmail.com> Message-ID: <20080711173358.GC10273@scytale.galois.com> marlowsd: > Hi folks, > > I've been wondering whether it would be useful to have a weekly IRC > meeting to discuss GHC. The idea would be that this is a scheduled time > when the developers turn up on #ghc, we'll discuss current topics around > GHC, and users can chime in with questions, points for discussion, > complaints :-) and so on. I imagine making it completely informal to > begin with, and later adding some structure (an agenda etc.) if necessary. > > Another option is a conference call, but personally I prefer the IRC > medium for this kind of meeting. A conference call could work too, though. > > Thoughts? I'm thinking a time around 1600 UK time (currently UTC+1) would > probably work best, does anyone have preferences for days? I think this is a good plan. 1600 UTC+1 is currently 8am Friday on the USA west coast fwiw. -- Don From phercek at gmail.com Sat Jul 12 16:34:08 2008 From: phercek at gmail.com (Peter Hercek) Date: Sat Jul 12 16:25:26 2008 Subject: ghc.exe: panic! (the 'impossible' happened) Message-ID: Hi, I was advised to report it here ... and maybe somebody who knows ghc better can reproduce it or knows what is the problem. I uninstalled all ghc, gtk, and gtk2hs packages then installed ghc 6.8.3 and then gtk2hs 0.9.13 on Windows XP 32bit. This should not be because of some stalled files from previous ghc as it was suggested to me. And I was told there is nothing strange in gtk2hs 0.9.13 to cause this. A version of gtk2hs 0.9.12.1 I compiled myself works with ghc 6.8.3. I did not try to compile 0.9.13. Any ideas? Peter. status:0 peter@dwarf [764] /c/tools/Gtk2Hs/demos/hello % ls Makefile World.hs status:0 peter@dwarf [765] /c/tools/Gtk2Hs/demos/hello % ghcii.sh World.hs GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( World.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1.1 ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. Loading package glib-0.9.13 ... : Unknown PEi386 section name `.reloc' (while processing: C:/tools/Gtk2Hs/HSglib.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> :quit Leaving GHCi. status:0 peter@dwarf [766] /c/tools/Gtk2Hs/demos/hello % From thomas.dubuisson at gmail.com Sun Jul 13 00:55:16 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sun Jul 13 00:45:45 2008 Subject: Weekly IRC meeting? In-Reply-To: <20080711173358.GC10273@scytale.galois.com> References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> Message-ID: <1215924916.9414.53.camel@tom-laptop> Don Stewart wrote: > marlowsd: > > Hi folks, > > > > I've been wondering whether it would be useful to have a weekly IRC > > meeting to discuss GHC. The idea would be that this is a scheduled time > > when the developers turn up on #ghc, we'll discuss current topics around > > GHC, and users can chime in with questions, points for discussion, > > complaints :-) and so on. I imagine making it completely informal to > > begin with, and later adding some structure (an agenda etc.) if necessary. > > > > Another option is a conference call, but personally I prefer the IRC > > medium for this kind of meeting. A conference call could work too, though. > > > > Thoughts? I'm thinking a time around 1600 UK time (currently UTC+1) would > > probably work best, does anyone have preferences for days? > > I think this is a good plan. 1600 UTC+1 is currently 8am Friday on the > USA west coast fwiw. ? ?I'd listen in if this plan comes to fruition. The 1600 UTC+1 time would work fine. Tom From jason.dusek at gmail.com Sun Jul 13 13:49:19 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Jul 13 13:39:49 2008 Subject: Weekly IRC meeting? In-Reply-To: <1215924916.9414.53.camel@tom-laptop> References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> <1215924916.9414.53.camel@tom-laptop> Message-ID: <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> Thomas M. DuBuisson wrote: > Don Stewart wrote: > > I think this is a good plan. 1600 UTC+1 is currently 8am Friday on the > > USA west coast fwiw. > > I'd listen in if this plan comes to fruition. The 1600 UTC+1 time > would work fine. I would listen in, as well. 1500 UTC is a little early in SF, but it's before work and that's just as well. -- _jsn From conal at conal.net Mon Jul 14 07:58:00 2008 From: conal at conal.net (Conal Elliott) Date: Mon Jul 14 07:48:30 2008 Subject: Advice sought for 6.9 and Arrow/Category Message-ID: I want to use ghc-6.9 for improved support of type families, but I see that the change to the Arrow interface breaks some of my libraries (since (>>>) is no longer a method of Arrow). Will this change really be in ghc-6.9? Does anyone have coping strategies for keeping libraries working in 6.8 *and* 6.9, particularly ones that define instances of Arrow? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080714/1b60b99e/attachment.htm From dons at galois.com Mon Jul 14 14:38:54 2008 From: dons at galois.com (Don Stewart) Date: Mon Jul 14 14:29:29 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: References: Message-ID: <20080714183854.GD23666@scytale.galois.com> conal: > I want to use ghc-6.9 for improved support of type families, but I see > that the change to the Arrow interface breaks some of my libraries (since > (>>>) is no longer a method of Arrow). Will this change really be in (>>>) has been reexported from Control.Category through Arrow for a few months. Does that fix things, or is your code still broken? -- Don From marlowsd at gmail.com Tue Jul 15 07:24:13 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 15 07:14:47 2008 Subject: Weekly IRC meeting? In-Reply-To: <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> <1215924916.9414.53.camel@tom-laptop> <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> Message-ID: <487C88DD.2040302@gmail.com> Ok, the first weekly IRC meeting is scheduled for Wednesday 16 July (tomorrow) at 1600 BST (UTC+1) 0800 PDT (UTC-7) 1100 EDT (UTC-4) 0100 Thursday in Sydney (sorry guys :-) If it turns out to be useful, we'll make it a regular thing. See you in #ghc on chat.freenode.net. More instructions for getting on IRC are here: http://haskell.org/haskellwiki/IRC_channel. Cheers, Simon From igloo at earth.li Tue Jul 15 08:38:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 15 08:28:51 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: References: Message-ID: <20080715123825.GA11373@matrix.chaos.earth.li> On Mon, Jul 14, 2008 at 01:58:00PM +0200, Conal Elliott wrote: > I want to use ghc-6.9 for improved support of type families, but I see that > the change to the Arrow interface breaks some of my libraries (since (>>>) > is no longer a method of Arrow). Will this change really be in ghc-6.9? Yes. It was changed with a library proposal: http://hackage.haskell.org/trac/ghc/ticket/1773 http://www.haskell.org/pipermail/libraries/2007-October/008291.html Thanks Ian From conal at conal.net Tue Jul 15 10:43:11 2008 From: conal at conal.net (Conal Elliott) Date: Tue Jul 15 10:33:37 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: <20080714183854.GD23666@scytale.galois.com> References: <20080714183854.GD23666@scytale.galois.com> Message-ID: All code that defines Arrow instance breaks, because (>>>) is not a method of Arrow. I have a lot of such instances, so I'm now adding #if directives to test for ghc-6.9 or later. - Conal On Mon, Jul 14, 2008 at 8:38 PM, Don Stewart wrote: > conal: > > I want to use ghc-6.9 for improved support of type families, but I see > > that the change to the Arrow interface breaks some of my libraries > (since > > (>>>) is no longer a method of Arrow). Will this change really be in > > (>>>) has been reexported from Control.Category through Arrow for a few > months. Does that fix things, or is your code still broken? > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080715/ea5f7a65/attachment.htm From conal at conal.net Tue Jul 15 10:59:25 2008 From: conal at conal.net (Conal Elliott) Date: Tue Jul 15 10:49:51 2008 Subject: Bug in type equality constraints? Message-ID: I'm converting some code from functionally dependencies to associated types, and I've run into a problem with equality constraints and subclasses. The classes: class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v class VectorSpace v => InnerSpace v where (<.>) :: v -> v -> Scalar v Products of vector spaces are vector spaces *if* over the same scalar field. Hence: instance ( VectorSpace u,VectorSpace v , Scalar u ~ Scalar v ) => VectorSpace (u,v) where type Scalar (u,v) = Scalar u s *^ (u,v) = (s*^u,s*^v) Similarly for inner product spaces: instance ( InnerSpace u,InnerSpace v, Scalar u ~ Scalar v , AdditiveGroup (Scalar v) ) => InnerSpace (u,v) where (u,v) <.> (u',v') = (u <.> u') ^+^ (v <.> v') But here's where ghc-6.9.20080622 balks: Data\VectorSpace.hs:106:0: Couldn't match expected type `Scalar v' against inferred type `Scalar u' When checking the super-classes of an instance declaration In the instance declaration for `InnerSpace (u, v)' Any ideas? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080715/67380455/attachment.htm From conal at conal.net Tue Jul 15 11:45:55 2008 From: conal at conal.net (Conal Elliott) Date: Tue Jul 15 11:36:22 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: References: <20080714183854.GD23666@scytale.galois.com> Message-ID: By the way, here's how I'm changing my code to work with the new and old arrow interface. I'd appreciate any suggested improvements. The old code (example): import Control.Arrow [...] instance Arrow (~>) => Arrow (Bijection (~>)) where Bi ab ba >>> Bi bc cb = Bi (ab >>> bc) (cb >>> ba) [...] The new code: #if __GLASGOW_HASKELL__ >= 609 import Control.Category import Prelude hiding ((.), id) #endif import Control.Arrow [...] #if __GLASGOW_HASKELL__ >= 609 instance Category (~>) => Category (Bijection (~>)) where id = Bi id id Bi bc cb . Bi ab ba = Bi (bc . ab) (ba . cb) #endif instance Arrow (~>) => Arrow (Bijection (~>)) where #if __GLASGOW_HASKELL__ < 609 Bi ab ba >>> Bi bc cb = Bi (ab >>> bc) (cb >>> ba) #endif [...] I'm testing for ghc version. Could I somehow test for the base-library version instead? - Conal On Tue, Jul 15, 2008 at 4:43 PM, Conal Elliott wrote: > All code that defines Arrow instance breaks, because (>>>) is not a method > of Arrow. I have a lot of such instances, so I'm now adding #if directives > to test for ghc-6.9 or later. - Conal > > > On Mon, Jul 14, 2008 at 8:38 PM, Don Stewart wrote: > >> conal: >> > I want to use ghc-6.9 for improved support of type families, but I >> see >> > that the change to the Arrow interface breaks some of my libraries >> (since >> > (>>>) is no longer a method of Arrow). Will this change really be in >> >> (>>>) has been reexported from Control.Category through Arrow for a few >> months. Does that fix things, or is your code still broken? >> >> -- Don >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080715/1e5c9a5a/attachment-0001.htm From dav.vire+haskell at gmail.com Wed Jul 16 04:25:41 2008 From: dav.vire+haskell at gmail.com (david48) Date: Wed Jul 16 04:20:27 2008 Subject: Weekly IRC meeting? References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> <1215924916.9414.53.camel@tom-laptop> <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> <487C88DD.2040302@gmail.com> Message-ID: Simon Marlow gmail.com> writes: > #ghc on chat.freenode.net. More instructions for getting on IRC are here: > http://haskell.org/haskellwiki/IRC_channel. (There is currently no text in this page) From haskell at list.mightyreason.com Wed Jul 16 06:01:59 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Jul 16 05:52:39 2008 Subject: [Haskell-cafe] Mutually recursive modules and google protocol-buffers In-Reply-To: <487CBDF5.8060601@di.unipi.it> References: <487C882C.2030505@list.mightyreason.com> <9d4d38820807150620j254bc4dax8a8a0e3e1cbd9c25@mail.gmail.com> <487CB79B.6020403@list.mightyreason.com> <487CBDF5.8060601@di.unipi.it> Message-ID: <487DC717.2000301@list.mightyreason.com> Thanks Roberto! Roberto Zunino wrote: > Chris Kuklewicz wrote: >> There is no way to create a "A.hs-boot" file that has all of >> (1) Allows A.hs-boot to be compiled without compiling B.hs first >> (2) Allows B.hs (with a {-# SOURCE #-} pragma) to be compiled after >> A.hs-boot >> (3) Allows A.hs to compiled after A.hs-boot with a consistent interface > > I thought the following A.hs-boot would suffice: > > module A(A) where > data A > > There's no need to provide the data constructors for type A. Does this > violate any of the goals above? > > Regards, > Zun. I tried that experiment. The failure is complicated, and triggers be a ghc bug. Hmmm... the bug for > module A(A) where > data A > deriving Show using "ghc -c -XGeneralizedNewtypeDeriving A.hs-boot" is > A.hs-boot:2:0:ghc-6.8.3: panic! (the 'impossible' happened) > (GHC version 6.8.3 for powerpc-apple-darwin): > newTyConEtadRhs main:A.A{tc r5z} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Is this a known bug? But now I see that > module A(A(..)) where > import B(B) > data A = A B | End > deriving Show > does work. And avoids the bug! -- Chris From ganesh.sittampalam at credit-suisse.com Wed Jul 16 07:03:07 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Jul 16 06:54:37 2008 Subject: [Haskell-cafe] Mutually recursive modules and google protocol-buffers In-Reply-To: <487DC717.2000301@list.mightyreason.com> References: <487C882C.2030505@list.mightyreason.com> <9d4d38820807150620j254bc4dax8a8a0e3e1cbd9c25@mail.gmail.com> <487CB79B.6020403@list.mightyreason.com> <487CBDF5.8060601@di.unipi.it> <487DC717.2000301@list.mightyreason.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B71C@ELON17P32002A.csfb.cs-group.com> Hi, > module A(A) where > data A > deriving Show I think you should use "instance Show A" rather than "deriving Show". All the boot file needs to do is say that the instance exists, not explain how it is constructed. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From igloo at earth.li Wed Jul 16 07:19:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jul 16 07:09:55 2008 Subject: Weekly IRC meeting? In-Reply-To: References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> <1215924916.9414.53.camel@tom-laptop> <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> <487C88DD.2040302@gmail.com> Message-ID: <20080716111932.GA17275@matrix.chaos.earth.li> On Wed, Jul 16, 2008 at 08:25:41AM +0000, david48 wrote: > Simon Marlow gmail.com> writes: > > > #ghc on chat.freenode.net. More instructions for getting on IRC are here: > > http://haskell.org/haskellwiki/IRC_channel. > > (There is currently no text in this page) The "." is not part of the URL: http://haskell.org/haskellwiki/IRC_channel Thanks Ian From ndmitchell at gmail.com Wed Jul 16 11:08:35 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jul 16 10:58:57 2008 Subject: Weekly IRC meeting? In-Reply-To: <1185138972.20080711132152@gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> Message-ID: <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> Hi > > Another option is a conference call, but personally I prefer the IRC medium > > for this kind of meeting. A conference call could work too, though. > > i propose to sent every meeting log into cvs-ghc I second this. The mibbit.com IRC client is currently blocked by freenode.net, so I am unable to participate, and would like to see a log :-) Thanks Neil From duncan.coutts at worc.ox.ac.uk Wed Jul 16 14:08:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 16 13:58:13 2008 Subject: Weekly IRC meeting? In-Reply-To: <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> Message-ID: <1216231714.6279.131.camel@localhost> On Wed, 2008-07-16 at 16:08 +0100, Neil Mitchell wrote: > Hi > > > > Another option is a conference call, but personally I prefer the IRC medium > > > for this kind of meeting. A conference call could work too, though. > > > > i propose to sent every meeting log into cvs-ghc > > I second this. The mibbit.com IRC client is currently blocked by > freenode.net, so I am unable to participate, and would like to see a > log :-) Log here: http://haskell.org/~duncan/ghc/%23ghc-2008-07-16.log Hopefully we can put them in some standard place as we go on. Duncan From simonpj at microsoft.com Wed Jul 16 15:51:57 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jul 16 15:42:21 2008 Subject: Bug in type equality constraints? In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE759893C@EA-EXMSG-C334.europe.corp.microsoft.com> Conal That looks like a bug, at least on the surface. You've clearly said that the instance for InnerSpace (u,v) can assume (Scalar u ~ Scalar v). Can you spare a moment submit a Trac report, with a reproducible test case (as small as possible, please!)? Manuel is actively working on associated types etc at the moment. Our goal is a pretty-much-fully-working implementation for release in 6.10 just before ICFP. thanks Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 15 July 2008 15:59 To: glasgow-haskell-users@haskell.org Subject: Bug in type equality constraints? I'm converting some code from functionally dependencies to associated types, and I've run into a problem with equality constraints and subclasses. The classes: class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v class VectorSpace v => InnerSpace v where (<.>) :: v -> v -> Scalar v Products of vector spaces are vector spaces *if* over the same scalar field. Hence: instance ( VectorSpace u,VectorSpace v , Scalar u ~ Scalar v ) => VectorSpace (u,v) where type Scalar (u,v) = Scalar u s *^ (u,v) = (s*^u,s*^v) Similarly for inner product spaces: instance ( InnerSpace u,InnerSpace v, Scalar u ~ Scalar v , AdditiveGroup (Scalar v) ) => InnerSpace (u,v) where (u,v) <.> (u',v') = (u <.> u') ^+^ (v <.> v') But here's where ghc-6.9.20080622 balks: Data\VectorSpace.hs:106:0: Couldn't match expected type `Scalar v' against inferred type `Scalar u' When checking the super-classes of an instance declaration In the instance declaration for `InnerSpace (u, v)' Any ideas? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080716/477c521d/attachment.htm From conal at conal.net Thu Jul 17 03:37:23 2008 From: conal at conal.net (Conal Elliott) Date: Thu Jul 17 03:27:44 2008 Subject: problem submitting ghc bug in trac Message-ID: I logged onto the ghc trac, am trying to submit a ghc bug report, and I get "TICKET_CREATE privileges are required to perform this operation". How do I get TICKET_CREATE privileges? I do see "logged in as conal". - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080717/56cc1d7b/attachment-0001.htm From peteg42 at gmail.com Thu Jul 17 03:53:07 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Jul 17 03:43:59 2008 Subject: GHC 6.8.3 in Debian? Message-ID: Ian - how long until GHC 6.8.3 makes it into Debian's unstable repository? (Just curious how long it takes, and flying the flag of interest.) BTW is there another .deb repository out there for bleeding-edge Haskell artefacts? I believe there used to be, but the URLs in those old (2004) emails seem dead now. cheers peter -- http://peteg.org/ From marlowsd at gmail.com Thu Jul 17 07:33:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 17 07:23:44 2008 Subject: Weekly IRC meeting? In-Reply-To: <1216231714.6279.131.camel@localhost> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> Message-ID: <487F2DFC.7020509@gmail.com> Duncan Coutts wrote: > On Wed, 2008-07-16 at 16:08 +0100, Neil Mitchell wrote: >> Hi >> >>> > Another option is a conference call, but personally I prefer the IRC medium >>> > for this kind of meeting. A conference call could work too, though. >>> >>> i propose to sent every meeting log into cvs-ghc >> I second this. The mibbit.com IRC client is currently blocked by >> freenode.net, so I am unable to participate, and would like to see a >> log :-) > > Log here: http://haskell.org/~duncan/ghc/%23ghc-2008-07-16.log > > Hopefully we can put them in some standard place as we go on. Thanks to everyone who turned up and joined in, we had an interesting discussion about the HLP. On this basis I think we should try making it a weekly event. Cheers, Simon From johan.tibell at gmail.com Thu Jul 17 07:44:01 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jul 17 07:34:20 2008 Subject: Weekly IRC meeting? In-Reply-To: <487F2DFC.7020509@gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> Message-ID: <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> On Thu, Jul 17, 2008 at 1:33 PM, Simon Marlow wrote: > Thanks to everyone who turned up and joined in, we had an interesting > discussion about the HLP. On this basis I think we should try making it a > weekly event. Thanks for arranging the meeting. I couldn't attend this time but I've read the logs and given the constructive discussion I definitely think it's worth making into a weekly event. Cheers, Johan From dav.vire+haskell at gmail.com Fri Jul 18 04:41:43 2008 From: dav.vire+haskell at gmail.com (david48) Date: Fri Jul 18 04:32:16 2008 Subject: Weekly IRC meeting? References: <48772324.5070304@gmail.com> <20080711173358.GC10273@scytale.galois.com> <1215924916.9414.53.camel@tom-laptop> <42784f260807131049i7df79c42o683df3b11e21710c@mail.gmail.com> <487C88DD.2040302@gmail.com> <20080716111932.GA17275@matrix.chaos.earth.li> Message-ID: Ian Lynagh earth.li> writes: > The "." is not part of the URL: > http://haskell.org/haskellwiki/IRC_channel I do feel dumb right now :) From ahunter at cs.hmc.edu Fri Jul 18 20:55:33 2008 From: ahunter at cs.hmc.edu (Andrew Hunter) Date: Fri Jul 18 20:45:46 2008 Subject: Building libraries with ticky-ticky Message-ID: <20080719005533.GQ2442@knuth.cs.hmc.edu> Hi, I have some code I want to use ticky-ticky profiling on (if it matters, I want some of the data ticky-ticky collects about frequency of updates and related matters.) However, I'm specifically interested in the code running with some modificiations I've made to the RTS, so I need to build GHC with ticky-ticky. That in itself isn't hard--the documentation said to just run "make way=t" in rts/, which seemed to work; but the documentation also said that to get meaningful numbers, I should make sure to build the libraries with ticky-ticky (which makes sense--I'm interested in the same data whether or not the updates happen in a function from List or one I wrote, &c.) The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another. So, any help or advice on how to tell the GHC build system to build a set of libraries with ticky-ticky profiling enabled would be greatly appreciated. (FWIW, I'm not distributing anything, so it'd be more than adequate for stuff to be broken for non ticky use, I just need to build some test executables and be sure they're logging the right data.) Thanks, AHH From catamorphism at gmail.com Mon Jul 21 00:08:58 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun Jul 20 23:59:05 2008 Subject: Building libraries with ticky-ticky In-Reply-To: <20080719005533.GQ2442@knuth.cs.hmc.edu> References: <20080719005533.GQ2442@knuth.cs.hmc.edu> Message-ID: <4683d9370807202108s158c5c8ek4682ac466f359aba@mail.gmail.com> On 7/18/08, Andrew Hunter wrote: > The documentation does *not*, however, say (anywhere I can find) how > to do this! My natural guess was to go into mk/build.mk, and add > -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I > had previously built a ticky rts, this produced a multitude of linker > errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this > didn't die, but I'm unclear if it...did anything at all, really. I > see no way to really tell one way or another. > Hi, Andrew-- I'm not surprised that building the libraries with ticky enabled doesn't work, because when I fixed ticky-ticky profiling a year and a half ago after it was bit-rotted, I hardly tested it and all and certainly didn't try building the ticky libraries. If I try "make way=t" in libraries/, which should be the proper way to build the ticky libraries, I get errors, so I'm surprised it succeeded for you (unless the build system thought that the libraries were up-to-date and didn't try building the ticky version.) The reason you got linker errors was because, I assume, you had compiled the libraries with -ticky but you weren't passing the -ticky flag to GHC when you compiled your program. If you don't pass the -ticky flag, GHC doesn't link with the ticky RTS, so the library code will include all sorts of undefined symbols. But since you said below that it's OK if things are broken for non-ticky use, you should just be able to do: $ cd libraries/ $ make clean $ make EXTRA_HC_OPTS=-ticky $ cd [wherever] $ ghc -o foo -ticky foo.hs $ ./foo +RTS -rfoo.ticky -RTS and foo.ticky will contain your profiling report. You just won't be able to compile any programs without -ticky this way. In the meantime, I'll look into making the "ticky" way work so that it'll be possible to have ticky and non-ticky libraries coexisting. If you have any more questions about ticky-ticky profiling, please CC both me and this list, since I don't always read the list carefully. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Faith, faith is an island in the setting sun / But proof, yes, proof is the bottom line for everyone."--Paul Simon From ronwalf at volus.net Mon Jul 21 01:35:05 2008 From: ronwalf at volus.net (Ron Alford) Date: Mon Jul 21 01:25:12 2008 Subject: GHC Error: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: References: Message-ID: I posted this to Haskell-Cafe, but it's more GHC specific. Anyone know what this is about? Removing parts makes problem go away, but it's not clear what parts to remove! (that, and I wrote those parts for a reason!). bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 bash-3.2$ uname -a Darwin silverback-wired.home 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 $ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) /var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0: FATAL:Symbol _XxG_srt already defined. -Ron Alford -------------- next part -------------- A non-text attachment was scrubbed... Name: DerivingError.hs Type: application/octet-stream Size: 2483 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080721/0e3a9eb3/DerivingError.obj From ahunter at cs.hmc.edu Mon Jul 21 02:35:21 2008 From: ahunter at cs.hmc.edu (Andrew Hunter) Date: Mon Jul 21 02:25:28 2008 Subject: Building libraries with ticky-ticky In-Reply-To: <4683d9370807202108s158c5c8ek4682ac466f359aba@mail.gmail.com> References: <20080719005533.GQ2442@knuth.cs.hmc.edu> <4683d9370807202108s158c5c8ek4682ac466f359aba@mail.gmail.com> Message-ID: <20080721063520.GS2442@knuth.cs.hmc.edu> On Sun, Jul 20, 2008 at 09:08:58PM -0700, Tim Chevalier wrote: > I'm not surprised that building the libraries with ticky enabled > doesn't work, because when I fixed ticky-ticky profiling a year and a > half ago after it was bit-rotted, I hardly tested it and all and > certainly didn't try building the ticky libraries. > I'm not surprised to see this answer--looking at tickets and mailing lists, it was clear that ticky-ticky wasn't in the best of shape, but I couldn't figure out what exactly the state of affairs was, so I figured I'd ask. > The reason you got linker errors was because, I assume, you had > compiled the libraries with -ticky but you weren't passing the -ticky > flag to GHC when you compiled your program. If you don't pass the > -ticky flag, GHC doesn't link with the ticky RTS, so the library code > will include all sorts of undefined symbols. > Right--thing is, it seemed I was getting linker errors on compiling the *libraries*--which seems weird, given that the libraries shouldn't be getting linked, should they? I'm not entirely sure this is what I was seeing, so, well, not a huge consideration, but it does seem weird. > But since you said below that it's OK if things are broken for > non-ticky use, you should just be able to do: > $ cd libraries/ > $ make clean > $ make EXTRA_HC_OPTS=-ticky > $ cd [wherever] > $ ghc -o foo -ticky foo.hs > $ ./foo +RTS -rfoo.ticky -RTS > and foo.ticky will contain your profiling report. You just won't be > able to compile any programs without -ticky this way. > After removing "p" from GhcLibWays, which makes sense--the docs make it clear we can't combine prof and ticky, though it also implies that it maybe *should* work; might someone what to look into this?--this worked great, thanks. My tests are running nicely and giving what seems like accurate data. Thanks for the very helpful response. > In the meantime, I'll look into making the "ticky" way work so that > it'll be possible to have ticky and non-ticky libraries coexisting. > Sweet. Admittedly I'm not yet a GHC wizard, but I'd love to help out by fixing this--do you have a rough idea of what would need to be done, or what in fact is the current problem? Thanks a lot, AHH From catamorphism at gmail.com Mon Jul 21 03:55:56 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Jul 21 03:46:03 2008 Subject: Building libraries with ticky-ticky In-Reply-To: <20080721063520.GS2442@knuth.cs.hmc.edu> References: <20080719005533.GQ2442@knuth.cs.hmc.edu> <4683d9370807202108s158c5c8ek4682ac466f359aba@mail.gmail.com> <20080721063520.GS2442@knuth.cs.hmc.edu> Message-ID: <4683d9370807210055j8dd545ak84cb4f7e86bf6119@mail.gmail.com> On 7/20/08, Andrew Hunter wrote: > > Right--thing is, it seemed I was getting linker errors on compiling > the *libraries*--which seems weird, given that the libraries shouldn't > be getting linked, should they? I'm not entirely sure this is what I > was seeing, so, well, not a huge consideration, but it does seem > weird. That is indeed weird, and I don't know why that would be happening. It didn't happen after you rebuilt in a clean directory, though, right? (Or at least that's what you seem to imply below.) > > After removing "p" from GhcLibWays, which makes sense--the docs make > it clear we can't combine prof and ticky, though it also implies that > it maybe *should* work; might someone what to look into this?--this > worked great, thanks. My tests are running nicely and giving what > seems like accurate data. Thanks for the very helpful response. > I think combining prof and ticky might be nontrivial, because the RTS has all sorts of conditional compilation in it that may be predicated on prof and ticky being mutually exclusive. At least, it's not something I would want to dive into implementing unless I had a good reason, and after all, you can just recompile the same code repeatedly with different options to get both prof and ticky results (although that could get annoying.) > > Sweet. Admittedly I'm not yet a GHC wizard, but I'd love to help out > by fixing this--do you have a rough idea of what would need to be > done, or what in fact is the current problem? I'm not a GHC wizard either, which is why the code that's there doesn't work so well. And I suspect that solving the problem will require some build system hacking, which is an area I'm not familiar with at all, so I can't give much advice about how to solve the problem. You're welcome to try, though. I added a ticket at: http://hackage.haskell.org/trac/ghc/ticket/2455 so if you make any progress, you should add a comment there. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "What doesn't kill you makes you look really, really bad." --Carrie Fisher From marlowsd at gmail.com Mon Jul 21 06:41:48 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 21 06:31:59 2008 Subject: Weekly IRC meeting? In-Reply-To: <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> Message-ID: <488467EC.7030704@gmail.com> Johan Tibell wrote: > On Thu, Jul 17, 2008 at 1:33 PM, Simon Marlow wrote: >> Thanks to everyone who turned up and joined in, we had an interesting >> discussion about the HLP. On this basis I think we should try making it a >> weekly event. > > Thanks for arranging the meeting. I couldn't attend this time but I've > read the logs and given the constructive discussion I definitely think > it's worth making into a weekly event. Ian and I talked about possibly trying a different time - 9pm UK time, which would be slightly less friendly to us in the UK (I have my work/life balance to think about you know :-) but more friendly to people in the US. For this week let's stick to the same time as last week (4pm UK), but let me know if 9pm UK would be better/worse for you (that's 1300 PDT, 1600 EDT). For this week's discussion, one topic on the table is whether to switch version control systems, which I'm sure will make for a lively debate :) Cheers, Simon From johan.tibell at gmail.com Mon Jul 21 14:24:38 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Jul 21 14:14:44 2008 Subject: Weekly IRC meeting? In-Reply-To: <488467EC.7030704@gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> <488467EC.7030704@gmail.com> Message-ID: <90889fe70807211124q561c2126o3f5767ccbb7fd6@mail.gmail.com> On Mon, Jul 21, 2008 at 12:41 PM, Simon Marlow wrote: > Ian and I talked about possibly trying a different time - 9pm UK time, which > would be slightly less friendly to us in the UK (I have my work/life balance > to think about you know :-) but more friendly to people in the US. I would have a hard time attending at this time since it's after work hours in Europe. One nice thing with having it during work hours is that I can have my IRC open in one window while I work. > For this week's discussion, one topic on the table is whether to switch > version control systems, which I'm sure will make for a lively debate :) Yes! Git please. Cheers, Johan darcs-ate-our-ICFP-submission Tibell From dagit at codersbase.com Mon Jul 21 15:43:59 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Jul 21 15:34:05 2008 Subject: GHC 6.6 GADT type unification vs GHC 6.8 Message-ID: Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952.html What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080721/cb3b8f03/attachment.htm From thomas.dubuisson at gmail.com Tue Jul 22 00:06:15 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Mon Jul 21 23:56:22 2008 Subject: Weekly IRC meeting? In-Reply-To: <488467EC.7030704@gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> <488467EC.7030704@gmail.com> Message-ID: <1216699575.6590.7.camel@tom-laptop> > Ian and I talked about possibly trying a different time - 9pm UK time, > which would be slightly less friendly to us in the UK (I have my work/life > balance to think about you know :-) but more friendly to people in the US. I, for one, am happy with the current time; changing it should always be an option though. > For this week's discussion, one topic on the table is whether to switch > version control systems, which I'm sure will make for a lively debate :) Perhaps we could have an ever evolving wiki page with the when/where/agenda/logs. I've started a rough one [1]; I put it in the general Haskell wiki because these topics certainly aren't confined to GHC. Thomas [1] http://haskell.org/haskellwiki/Weekly_Meeting From marlowsd at gmail.com Tue Jul 22 04:07:49 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 22 03:57:59 2008 Subject: Weekly IRC meeting? In-Reply-To: <1216699575.6590.7.camel@tom-laptop> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> <488467EC.7030704@gmail.com> <1216699575.6590.7.camel@tom-laptop> Message-ID: <48859555.1060909@gmail.com> Thomas M. DuBuisson wrote: >> Ian and I talked about possibly trying a different time - 9pm UK time, >> which would be slightly less friendly to us in the UK (I have my work/life >> balance to think about you know :-) but more friendly to people in the US. > I, for one, am happy with the current time; changing it should always be an option though. > >> For this week's discussion, one topic on the table is whether to switch >> version control systems, which I'm sure will make for a lively debate :) > Perhaps we could have an ever evolving wiki page with the > when/where/agenda/logs. I've started a rough one [1]; I put it in the > general Haskell wiki because these topics certainly aren't confined to > GHC. > > Thomas > > [1] http://haskell.org/haskellwiki/Weekly_Meeting Hmm, well I did intend these meetings to be focussed mainly on issues relating to GHC, rather than a general Haskell discussion which could be held on #haskell separately. By all means start a more general Haskell meeting too, but I want to keep this one for GHC. The VCS debate is about what system GHC should use, not the community as a whole. The HLP discussion is on topic because it is so closely related to how we release/package/ship GHC. Cheers, Simon From spencerjanssen at gmail.com Tue Jul 22 05:57:18 2008 From: spencerjanssen at gmail.com (Spencer Janssen) Date: Tue Jul 22 05:46:45 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: References: <20080714183854.GD23666@scytale.galois.com> Message-ID: <20080722095718.GA14768@celeborn> On Tue, Jul 15, 2008 at 05:45:55PM +0200, Conal Elliott wrote: > By the way, here's how I'm changing my code to work with the new and old > arrow interface. I'd appreciate any suggested improvements. > > The old code (example): > > import Control.Arrow > > [...] > > instance Arrow (~>) => Arrow (Bijection (~>)) where > Bi ab ba >>> Bi bc cb = Bi (ab >>> bc) (cb >>> ba) > [...] > > The new code: > > #if __GLASGOW_HASKELL__ >= 609 > import Control.Category > import Prelude hiding ((.), id) > #endif > import Control.Arrow > > [...] > > #if __GLASGOW_HASKELL__ >= 609 > instance Category (~>) => Category (Bijection (~>)) where > id = Bi id id > Bi bc cb . Bi ab ba = Bi (bc . ab) (ba . cb) > #endif > > instance Arrow (~>) => Arrow (Bijection (~>)) where > #if __GLASGOW_HASKELL__ < 609 > Bi ab ba >>> Bi bc cb = Bi (ab >>> bc) (cb >>> ba) > #endif > [...] > > I'm testing for ghc version. Could I somehow test for the base-library > version instead? - Conal Yes. Here is a snippet from binary.cabal: flag applicative-in-base library if flag(applicative-in-base) build-depends: base >= 2.0 cpp-options: -DAPPLICATIVE_IN_BASE else build-depends: base < 2.0 Cheers, Spencer Janssen From duncan.coutts at worc.ox.ac.uk Tue Jul 22 08:05:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 22 07:54:07 2008 Subject: Advice sought for 6.9 and Arrow/Category In-Reply-To: <20080722095718.GA14768@celeborn> References: <20080714183854.GD23666@scytale.galois.com> <20080722095718.GA14768@celeborn> Message-ID: <1216728319.6279.409.camel@localhost> On Tue, 2008-07-22 at 04:57 -0500, Spencer Janssen wrote: > > I'm testing for ghc version. Could I somehow test for the base-library > > version instead? - Conal > > Yes. Here is a snippet from binary.cabal: > > flag applicative-in-base > > library > if flag(applicative-in-base) > build-depends: base >= 2.0 > cpp-options: -DAPPLICATIVE_IN_BASE > else > build-depends: base < 2.0 This is the sort of example where our Cabal syntactic sugar proposal helps a bit: library if package(base >= 2.0) cpp-options: -DAPPLICATIVE_IN_BASE So two lines rather than six and you don't need to understand the relational semantics so clearly to make sense of it. Now if only we'd get round to implementing it. Duncan From thomas.dubuisson at gmail.com Tue Jul 22 08:43:31 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Tue Jul 22 08:33:34 2008 Subject: Weekly IRC meeting? In-Reply-To: <48859555.1060909@gmail.com> References: <48772324.5070304@gmail.com> <1185138972.20080711132152@gmail.com> <404396ef0807160808p329ee635g684e1b3ced2dc3a7@mail.gmail.com> <1216231714.6279.131.camel@localhost> <487F2DFC.7020509@gmail.com> <90889fe70807170444j17ad122av8037a2cdae072de3@mail.gmail.com> <488467EC.7030704@gmail.com> <1216699575.6590.7.camel@tom-laptop> <48859555.1060909@gmail.com> Message-ID: <1216730611.6590.13.camel@tom-laptop> > By all means start a more general Haskell meeting too, but I want to keep > this one for GHC. The VCS debate is about what system GHC should use, not > the community as a whole. The HLP discussion is on topic because it is so > closely related to how we release/package/ship GHC. Ah, I assumed this included Hackage. How presumptuous of me. Thomas From diyu60607 at yahoo.com Thu Jul 24 22:33:54 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Thu Jul 24 22:23:50 2008 Subject: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! Message-ID: <320997.36099.qm@web32205.mail.mud.yahoo.com> Hi, I am trying to build ghc 6.8.3 from source release, my currently installed version is ghc 6.4.2 (x86 linux binary release version), and I got: /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT -i../../compat -ignore-package Cabal -Rghc-timing -package unix -L../../compat -lghccompat Main.o Version.o CRT_noglob.o Main.o: In function `__stginit_ZCMain': ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main': ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main_': ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' Main.o:ghc13533.hc:(.text+0x3d): more undefined references to `__DISCARD__' follow collect2: ld returned 1 exit status <> Do you know how I can fix this problem? My ghc and gcc versions are: The Glorious Glasgow Haskell Compilation System, version 6.4.2 gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in the same error message) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080724/f803047c/attachment.htm From marlowsd at gmail.com Fri Jul 25 04:52:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 25 04:41:58 2008 Subject: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! In-Reply-To: <320997.36099.qm@web32205.mail.mud.yahoo.com> References: <320997.36099.qm@web32205.mail.mud.yahoo.com> Message-ID: <48899431.8060407@gmail.com> Yu Di wrote: > Hi, I am trying to build ghc 6.8.3 from source release, my currently > installed version is ghc 6.4.2 (x86 linux binary release version), and I > got: > > /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall > -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT > -i../../compat -ignore-package Cabal -Rghc-timing -package unix > -L../../compat -lghccompat Main.o Version.o CRT_noglob.o > Main.o: In function `__stginit_ZCMain': > ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main': > ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main_': > ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' > Main.o:ghc13533.hc:(.text+0x3d): more undefined references to > `__DISCARD__' follow > collect2: ld returned 1 exit status > < samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), > 0.01 GC (0.03 elapsed) :ghc>> > > Do you know how I can fix this problem? My ghc and gcc versions are: > > The Glorious Glasgow Haskell Compilation System, version 6.4.2 > gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) > > (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in > the same error message) The error is coming from your installed 6.4.2, and I strongly suspect that it is incompatible with the gcc version you have installed. You could try downgrading gcc, but your best bet is to just install a recent GHC binary distribution. Cheers, Simon From diyu60607 at yahoo.com Sat Jul 26 13:47:03 2008 From: diyu60607 at yahoo.com (Yu Di) Date: Sat Jul 26 13:36:53 2008 Subject: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! Message-ID: <243841.81898.qm@web32208.mail.mud.yahoo.com> Thanks! I installed 6.8.2 binary and that successfully compiled 6.8.3 source with gcc 4.1.1. (I am still not sure why a direct 6.8.3. binary installation did not work for me, but now I think everything is good). Thanks very much again! Di, Yu 7.26 ----- Original Message ---- From: Simon Marlow To: Yu Di Cc: glasgow-haskell-users@haskell.org Sent: Friday, July 25, 2008 3:52:01 AM Subject: Re: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! Yu Di wrote: > Hi, I am trying to build ghc 6.8.3 from source release, my currently > installed version is ghc 6.4.2 (x86 linux binary release version), and I > got: > > /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall > -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT > -i../../compat -ignore-package Cabal -Rghc-timing -package unix > -L../../compat -lghccompat Main.o Version.o CRT_noglob.o > Main.o: In function `__stginit_ZCMain': > ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main': > ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main_': > ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' > Main.o:ghc13533.hc:(.text+0x3d): more undefined references to > `__DISCARD__' follow > collect2: ld returned 1 exit status > < samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), > 0.01 GC (0.03 elapsed) :ghc>> > > Do you know how I can fix this problem? My ghc and gcc versions are: > > The Glorious Glasgow Haskell Compilation System, version 6.4.2 > gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) > > (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in > the same error message) The error is coming from your installed 6.4.2, and I strongly suspect that it is incompatible with the gcc version you have installed. You could try downgrading gcc, but your best bet is to just install a recent GHC binary distribution. Cheers, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080726/37d29c3e/attachment.htm From simonpj at microsoft.com Tue Jul 29 04:07:58 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 29 03:57:42 2008 Subject: GHC 6.6 GADT type unification vs GHC 6.8 In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B0FAF@EA-EXMSG-C334.europe.corp.microsoft.com> GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type, * the type of the scrutinee * the type of the result of the case * the types of any free variables used inside the case alternatives are all completely known ("rigid" in GHC's terminology) at the case expression. The easiest way to make a variable have a rigid type is to give it a type signature. I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that. I'll add these remarks to the user manual. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Jason Dagit Sent: 21 July 2008 20:44 To: glasgow-haskell-users@haskell.org Subject: GHC 6.6 GADT type unification vs GHC 6.8 Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952.html What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080729/7a8718b6/attachment-0001.htm From waldmann at imn.htwk-leipzig.de Tue Jul 29 10:12:17 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Jul 29 10:02:57 2008 Subject: ghci and source files Message-ID: <488F2541.9010607@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, how does ghci (actually, the ghc API functions) access the file system? (It needs to check whether source files had been updated.) Is it possible to insert an abstraction layer there? E.g. imagine the sources are not on the file system, but in Eclipse edit buffers. - Any hints appreciated. J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEUEARECAAYFAkiPJUEACgkQDqiTJ5Q4dm99LQCXcaCtKnvEsmoGdJ+UQ93A2x0Z 2ACbBfaSZsvU0xHeh/jQbZZjI5VAEdQ= =eQ4p -----END PGP SIGNATURE----- From dagit at codersbase.com Tue Jul 29 10:14:09 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Jul 29 10:03:50 2008 Subject: GHC 6.6 GADT type unification vs GHC 6.8 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B0FAF@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B0FAF@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Tue, Jul 29, 2008 at 1:07 AM, Simon Peyton-Jones wrote: > GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. > Specifically, GHC 6.8 and all subsequent versions require that when you > pattern match on a value of GADT type, > > ? the type of the scrutinee > > ? the type of the result of the case > > ? the types of any free variables used inside the case > alternatives > > are all completely known ("rigid" in GHC's terminology) at the case > expression. > Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. > > The easiest way to make a variable have a rigid type is to give it a type > signature. > > > > I don't expect to revert to GHC 6.6's behaviour because I don't know how to > do (robust, complete) type inference for that. > In that case, good thing I finally figured out what changes to make to darcs so that our type witness code compiles in both 6.6 and 6.8. My changes match what you describe. > > > I'll add these remarks to the user manual. > Great! Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080729/61a1d295/attachment.htm From simonpj at microsoft.com Tue Jul 29 10:40:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 29 10:30:15 2008 Subject: GHC 6.6 GADT type unification vs GHC 6.8 In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B0FAF@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B12BA@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. Excellent question. I believe that what I describe below is a restriction of the system described in the POPL'06 paper http://research.microsoft.com/%7Esimonpj/papers/gadt/gadt-icfp.pdf At this moment I can't remember when we changed to the additional restrictions below. I think the reason was that we wanted to avoid the complexity of "fresh" mgus described in the paper, but memory is failing me. Dimitrios or Stephanie may have a better memory. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Jason Dagit Sent: 29 July 2008 15:14 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: GHC 6.6 GADT type unification vs GHC 6.8 On Tue, Jul 29, 2008 at 1:07 AM, Simon Peyton-Jones > wrote: GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type, * the type of the scrutinee * the type of the result of the case * the types of any free variables used inside the case alternatives are all completely known ("rigid" in GHC's terminology) at the case expression. Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. The easiest way to make a variable have a rigid type is to give it a type signature. I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that. In that case, good thing I finally figured out what changes to make to darcs so that our type witness code compiles in both 6.6 and 6.8. My changes match what you describe. I'll add these remarks to the user manual. Great! Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080729/e392ea79/attachment.htm From dagit at codersbase.com Tue Jul 29 11:58:50 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Jul 29 11:48:30 2008 Subject: GHC 6.6 GADT type unification vs GHC 6.8 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B12BA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE76B0FAF@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE76B12BA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Tue, Jul 29, 2008 at 7:40 AM, Simon Peyton-Jones wrote: > Thanks, this makes sense and helps. Is this described in the wobbly > types paper, or is paper covering a different topics? I would like to have > a cite-able reference. > > Excellent question. I believe that what I describe below is a * > restriction* of the system described in the POPL'06 paper > > > http://research.microsoft.com/%7Esimonpj/papers/gadt/gadt-icfp.pdf > > > > At this moment I can't remember when we changed to the additional > restrictions below. I think the reason was that we wanted to avoid the > complexity of "fresh" mgus described in the paper, but memory is failing > me. Dimitrios or Stephanie may have a better memory. > Thank you. I'm reading it now, and I believe it will work just perfect for my needs. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080729/46da16ec/attachment.htm From igloo at earth.li Tue Jul 29 12:17:56 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 29 12:07:37 2008 Subject: GHC 6.8.3 in Debian? In-Reply-To: References: Message-ID: <20080729161756.GA7663@matrix.chaos.earth.li> On Thu, Jul 17, 2008 at 05:53:07PM +1000, Peter Gammie wrote: > Ian - how long until GHC 6.8.3 makes it into Debian's unstable > repository? Not for a while - doing it now would make it harder to do any fixes needed for the next Debian release, which will include 6.8.2. Thanks Ian From dgorin at dc.uba.ar Tue Jul 29 13:14:04 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Jul 29 13:04:06 2008 Subject: ghci and source files In-Reply-To: <488F2541.9010607@imn.htwk-leipzig.de> References: <488F2541.9010607@imn.htwk-leipzig.de> Message-ID: <23F00925-2E28-48B0-BC63-9D7C3AE534D0@dc.uba.ar> Hi If you just want to compile from (Eclipse) edit buffers instead of source files, I think you can do this with the ghc api. Look at the Target type. The following is pasted from main/HscTypes.lhs -- | A compilation target. -- -- A target may be supplied with the actual text of the -- module. If so, use this instead of the file contents (this -- is for use in an IDE where the file hasn't been saved by -- the user yet). data Target = Target TargetId (Maybe (StringBuffer,ClockTime)) Hope this helps Daniel On Jul 29, 2008, at 11:12 AM, Johannes Waldmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, how does ghci (actually, the ghc API functions) > access the file system? > (It needs to check whether source files had been updated.) > Is it possible to insert an abstraction layer there? > E.g. imagine the sources are not on the file system, > but in Eclipse edit buffers. - Any hints appreciated. J.W. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iEUEARECAAYFAkiPJUEACgkQDqiTJ5Q4dm99LQCXcaCtKnvEsmoGdJ+UQ93A2x0Z > 2ACbBfaSZsvU0xHeh/jQbZZjI5VAEdQ= > =eQ4p > -----END PGP SIGNATURE----- > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From waldmann at imn.htwk-leipzig.de Tue Jul 29 13:43:07 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Jul 29 13:33:47 2008 Subject: ghci and source files In-Reply-To: <23F00925-2E28-48B0-BC63-9D7C3AE534D0@dc.uba.ar> References: <488F2541.9010607@imn.htwk-leipzig.de> <23F00925-2E28-48B0-BC63-9D7C3AE534D0@dc.uba.ar> Message-ID: <488F56AB.4090008@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > data Target = Target TargetId (Maybe (StringBuffer,ClockTime)) looks great. How is this intended to be used, i.e. what should happen if there is an "edit/save" event in the IDE? Then the IDE constructs a new StringBuffer from the buffer contents and sends it to the GHC API? (what call?) thanks - J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkiPVqsACgkQDqiTJ5Q4dm9ZsgCfT/GqfQmqIkFx4a1vL0Bg44nM YnUAoKEK7PSnMVOIVOoaaCu6zzOHje3s =1c4v -----END PGP SIGNATURE----- From dgorin at dc.uba.ar Tue Jul 29 14:04:02 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Jul 29 13:54:01 2008 Subject: ghci and source files In-Reply-To: <488F56AB.4090008@imn.htwk-leipzig.de> References: <488F2541.9010607@imn.htwk-leipzig.de> <23F00925-2E28-48B0-BC63-9D7C3AE534D0@dc.uba.ar> <488F56AB.4090008@imn.htwk-leipzig.de> Message-ID: <50F70FED-43F0-42F5-8E68-59B88A48B094@dc.uba.ar> On Jul 29, 2008, at 2:43 PM, Johannes Waldmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> data Target = Target TargetId (Maybe (StringBuffer,ClockTime)) > > looks great. How is this intended to be used, > i.e. what should happen if there is an "edit/save" event in the IDE? > Then the IDE constructs a new StringBuffer from the buffer contents > and sends it to the GHC API? (what call?) IIRC,you first set (or add) targets (with GHC.setTargets or GHC.addTargets) and then run GHC.load indicating LoadAllTargets. I *think* it will chose to use the StringBuffer only if the ClockTime is newer than the file's timestamp. Thus, if the user updates and saves the file between the creation of the StringBuffer and the actual call to GHC.load, ghc will load the target from disk. But I'm mostly guessing here, so you should probably try it out and see if it works :) Daniel From catamorphism at gmail.com Tue Jul 29 22:00:09 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Jul 29 21:49:48 2008 Subject: Retainer profiling -- too slow? Message-ID: <4683d9370807291900k79e46adbrc779b2c014e7492@mail.gmail.com> Hi all, Are there any known problems with retainer profiling in GHC 6.8.2? I have a program that takes 3 minutes to run with "normal" profiling enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and counting. I can tell that progress is being made since the .hp file keeps getting bigger, but that seems like a lot of overhead. I can try to come up with a smaller test case if necessary; just wanted to see if there's any known problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The trouble with academia is that there's a lot of 'If you'll validate my program of Kumquat Studies I won't point out the uselessness of your doctorate in Nail File Studies.'" -- Sarah Barton From marlowsd at gmail.com Wed Jul 30 05:01:40 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 30 05:01:46 2008 Subject: Retainer profiling -- too slow? In-Reply-To: <4683d9370807291900k79e46adbrc779b2c014e7492@mail.gmail.com> References: <4683d9370807291900k79e46adbrc779b2c014e7492@mail.gmail.com> Message-ID: <48902DF4.7080803@gmail.com> Tim Chevalier wrote: > Hi all, > > Are there any known problems with retainer profiling in GHC 6.8.2? I > have a program that takes 3 minutes to run with "normal" profiling > enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and > counting. I can tell that progress is being made since the .hp file > keeps getting bigger, but that seems like a lot of overhead. > > I can try to come up with a smaller test case if necessary; just > wanted to see if there's any known problem. It certainly is slow, especially with large heaps, because IIRC it has to do multiple traversals of the heap. The +RTS -sstderr output will tell you how much time is spent doing retainer profiling. (also retainer profiling is often not terribly useful IMO). Cheers, Simon From marlowsd at gmail.com Wed Jul 30 05:07:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 30 05:07:39 2008 Subject: ghci and source files In-Reply-To: <50F70FED-43F0-42F5-8E68-59B88A48B094@dc.uba.ar> References: <488F2541.9010607@imn.htwk-leipzig.de> <23F00925-2E28-48B0-BC63-9D7C3AE534D0@dc.uba.ar> <488F56AB.4090008@imn.htwk-leipzig.de> <50F70FED-43F0-42F5-8E68-59B88A48B094@dc.uba.ar> Message-ID: <48902F52.5000401@gmail.com> Daniel Gor?n wrote: > On Jul 29, 2008, at 2:43 PM, Johannes Waldmann wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>> data Target = Target TargetId (Maybe (StringBuffer,ClockTime)) >> >> looks great. How is this intended to be used, >> i.e. what should happen if there is an "edit/save" event in the IDE? >> Then the IDE constructs a new StringBuffer from the buffer contents >> and sends it to the GHC API? (what call?) > > IIRC,you first set (or add) targets (with GHC.setTargets or > GHC.addTargets) and then run GHC.load indicating LoadAllTargets. I > *think* it will chose to use the StringBuffer only if the ClockTime is > newer than the file's timestamp. Thus, if the user updates and saves the > file between the creation of the StringBuffer and the actual call to > GHC.load, ghc will load the target from disk. When the file is edited, you should put the edited content into the Target (use GHC.removeTarget/GHC.addTarget). You can then load the program with GHC.load, or check a single module with GHC.checkModule. checkModule doesn't rebuild the dependency tree or load the dependent modules, so if you think you need to do this then use GHC.load (with LoadUpTo) first. When the file is saved, you should remove the StringBuffer from the Target, so that GHC will start using the on-disk source file again. Cheers, Simon From marlowsd at gmail.com Wed Jul 30 05:12:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 30 05:12:35 2008 Subject: Weekly IRC meeting? In-Reply-To: <48772324.5070304@gmail.com> References: <48772324.5070304@gmail.com> Message-ID: <4890307E.6090700@gmail.com> The IRC meeting will be held today at 16:00 UK time as usual (there wasn't any support for moving it to 21:00). Simon PJ is back from holiday and should make it this time. Any suggestions for discussion topics? One idea we have is to talk about the GHC API. Cheers, Simon From batterseapower at hotmail.com Wed Jul 30 06:49:10 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Jul 30 06:49:12 2008 Subject: Weekly IRC meeting? In-Reply-To: <4890307E.6090700@gmail.com> References: <48772324.5070304@gmail.com> <4890307E.6090700@gmail.com> Message-ID: <9d4d38820807300349v6116599bk6131c6394bb3777d@mail.gmail.com> It would be nice if we could make some more progress on the revision control issue from last week. I don't know if people are ready to actually make a choice of RCS at this stage, but I've tried to make all the information necessary to make a choice available at http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation, along with the URLs of the conversions of the GHC repo to all those formats. Concretely, a decision needs to be made on: 1) Choice of RCS, so we can start researching how to do the Trac integration / replace darcsweb, and start converting infrastructure ready for the changeover 2) A timetable for conversion to the new RCS All the best, Max 2008/7/30 Simon Marlow : > The IRC meeting will be held today at 16:00 UK time as usual (there wasn't > any support for moving it to 21:00). Simon PJ is back from holiday and > should make it this time. > > Any suggestions for discussion topics? One idea we have is to talk about > the GHC API. > > Cheers, > Simon > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From waldmann at imn.htwk-leipzig.de Wed Jul 30 06:58:04 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Jul 30 06:59:10 2008 Subject: Weekly IRC meeting? In-Reply-To: <9d4d38820807300349v6116599bk6131c6394bb3777d@mail.gmail.com> References: <48772324.5070304@gmail.com> <4890307E.6090700@gmail.com> <9d4d38820807300349v6116599bk6131c6394bb3777d@mail.gmail.com> Message-ID: <4890493C.6070406@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> One idea we have is to talk about the GHC API. I am generally interested in this, but cannot contribute much at the moment. Best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkiQSTwACgkQDqiTJ5Q4dm/SfwCcC+4wSMevyAMM+47qBSdBqkQL POAAoKyzP2QFwe5/pXrevxRmXWMJ3Hbk =B2k8 -----END PGP SIGNATURE----- From rl at cse.unsw.edu.au Wed Jul 30 08:22:36 2008 From: rl at cse.unsw.edu.au (Roman Leschinskiy) Date: Wed Jul 30 08:22:48 2008 Subject: Build system woes Message-ID: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> Hi all, SimonPJ asked me to summarise the problems I've been having with GHC's new build system with the idea that we could perhaps talk a bit about this during today's IRC meeting. The context is the Data Parallel Haskell project and in particular the dph packages which need a number of not quite straightforward things from the build system (this is only going to get worse in the future). A lot of the problems stem from Cabal's lack of extensibility. This means that whenever I need some new Cabal functionality for dph I have to ask Ian or Duncan to implement it. They both are very helpful but this just doesn't scale! IMO, at the moment Cabal is simply not mature enough for building complex projects. But wait, we do have those Setup.hs files which are customisable so why don't I just do what I want with them? Firstly, they aren't customisable enough. And secondly, I have no idea how to do what I want. The development version of Cabal changes on a daily basis and isn't documented. For instance, the black magic that Ian implemented in dph/dph/Setup.hs a month ago (and which I don't really understand) has been broken once already. Fortunately, I was able to fix that myself but if something more complex changes, I'll have to ask Ian again. In effect, I'm not able to properly maintain my own library! I don't think I understand how GHC itself is built any longer, either. What does cabal-bin do? What is runghc.wrapper? What is the difference between make.library.* and build.library.* and why do we need both (and why doesn't one of them work for dph)? It is important to have an idea how the build system works when hacking on a project but how do I find out? And finally, there is the problem of the HEAD being broken quite frequently. I have decided to pull as little as possible and it turns out that others have independently arrived at the same conclusion. This is bad! For instance, I would have spotted the OS X breakage much earlier if I pulled more frequently; now, I have to wade through a couple of weeks' worth of patches to find the culprit (that darcs unpull doesn't work in my repo doesn't help). IMO, the main issue is that we have two moving targets: the GHC build system and the tool it relies on (Cabal). Both change rapidly and there is just no chance, for me at least, to keep up. If I understand correctly, the situation is this: - Ultimately, Cabal will be used for building GHC. - At the moment, Cabal doesn't provide the necessary functionality. The current approach seems to be to gradually implement stuff in Cabal and to immediately use it in the build system. I think this just doesn't work for a highly collaborative project such as GHC. I have two suggestions how to improve things. 1. I think it would be better to implement, document and release all the necessary functionality in Cabal first and only then to modify GHC's build system to use this functionality. In effect, this means that the Cabal version used for building GHC would be frozen at the beginning of a development cycle and not at the end. Critical stuff could still be merged, perhaps, but that should happen very infrequently and be backwards compatible. 2. Ian, it would be great if you could add a couple of lines to build system patches explaining what they do and why. This could ultimately mean less work for you because I will bug you less often :-) Sorry for the long rant, I simply seem to spend too much time wrestling with the build system. Roman From claus.reinke at talk21.com Wed Jul 30 09:12:08 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jul 30 09:12:21 2008 Subject: Build system woes References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> Message-ID: <011f01c8f245$e454ff60$36168351@cr3lt> For infrequent updaters like myself, it would also be nice just to have a HEADS UP before and after periods of larger than usual instability (such as build system replacements). And, talking about #ghc, I've got the suspicion that this channel is partly to blame for the occasional disappearance of critical information: did I just miss the messages here on cvs-ghc or was the discussion on #ghc instead? With no logs for #ghc to browse, I've got no idea what useful information #ghc inhabitants assume to be widely known!-) Couldn't lambdabot or some other bot file daily logs for #ghc somewhere, similar to the logs for #haskell? Then I could check whether my issues are new or well-known. I used to bug folks here with my "head doesn't build" messages before it finally dawned on me that the system is in such a state of upheaval that it will simply take time for things to settle down (rendering my failure messages redundant). Now I'm just waiting for the HEADS UP that tells us that things are back to normal, and that 'make;make binary-dist' is supposed to work again (on windows): http://www.haskell.org/pipermail/cvs-ghc/2008-July/043797.html http://www.haskell.org/pipermail/cvs-ghc/2008-July/043798.html Claus ----- Original Message ----- From: "Roman Leschinskiy" To: "GHC Users Mailing List" Sent: Wednesday, July 30, 2008 1:22 PM Subject: Build system woes > Hi all, > > SimonPJ asked me to summarise the problems I've been having with GHC's > new build system with the idea that we could perhaps talk a bit about > this during today's IRC meeting. The context is the Data Parallel > Haskell project and in particular the dph packages which need a number > of not quite straightforward things from the build system (this is > only going to get worse in the future). > > A lot of the problems stem from Cabal's lack of extensibility. This > means that whenever I need some new Cabal functionality for dph I have > to ask Ian or Duncan to implement it. They both are very helpful but > this just doesn't scale! IMO, at the moment Cabal is simply not mature > enough for building complex projects. > > But wait, we do have those Setup.hs files which are customisable so > why don't I just do what I want with them? Firstly, they aren't > customisable enough. And secondly, I have no idea how to do what I > want. The development version of Cabal changes on a daily basis and > isn't documented. For instance, the black magic that Ian implemented > in dph/dph/Setup.hs a month ago (and which I don't really understand) > has been broken once already. Fortunately, I was able to fix that > myself but if something more complex changes, I'll have to ask Ian > again. In effect, I'm not able to properly maintain my own library! > > I don't think I understand how GHC itself is built any longer, either. > What does cabal-bin do? What is runghc.wrapper? What is the difference > between make.library.* and build.library.* and why do we need both > (and why doesn't one of them work for dph)? It is important to have an > idea how the build system works when hacking on a project but how do I > find out? > > And finally, there is the problem of the HEAD being broken quite > frequently. I have decided to pull as little as possible and it turns > out that others have independently arrived at the same conclusion. > This is bad! For instance, I would have spotted the OS X breakage much > earlier if I pulled more frequently; now, I have to wade through a > couple of weeks' worth of patches to find the culprit (that darcs > unpull doesn't work in my repo doesn't help). > > IMO, the main issue is that we have two moving targets: the GHC build > system and the tool it relies on (Cabal). Both change rapidly and > there is just no chance, for me at least, to keep up. If I understand > correctly, the situation is this: > > - Ultimately, Cabal will be used for building GHC. > > - At the moment, Cabal doesn't provide the necessary functionality. > > The current approach seems to be to gradually implement stuff in Cabal > and to immediately use it in the build system. I think this just > doesn't work for a highly collaborative project such as GHC. I have > two suggestions how to improve things. > > 1. I think it would be better to implement, document and release all > the necessary > functionality in Cabal first and only then to modify GHC's build > system to use this > functionality. In effect, this means that the Cabal version used > for building GHC > would be frozen at the beginning of a development cycle and not > at the end. Critical > stuff could still be merged, perhaps, but that should happen very > infrequently and > be backwards compatible. > > 2. Ian, it would be great if you could add a couple of lines to > build system patches > explaining what they do and why. This could ultimately mean less > work for you > because I will bug you less often :-) > > Sorry for the long rant, I simply seem to spend too much time > wrestling with the build system. > > Roman > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Wed Jul 30 09:46:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 30 09:46:50 2008 Subject: Build system woes In-Reply-To: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> Message-ID: <489070C1.3080102@gmail.com> We can talk about the general issues on IRC. But I thought I'd answer a few of the specific questions quickly: Roman Leschinskiy wrote: > I don't think I understand how GHC itself is built any longer, either. > What does cabal-bin do? It's effectively a pre-compiled Setup.hs for packages that have no need for a custom Setup.hs. cabal-install does the same job for end-users, but we can't rely on having cabal-install in the GHC build system. > What is runghc.wrapper? it's a template used to make a shell wrapper for a binary. There seems to be new functionality in Cabal to support this. > What is the difference > between make.library.* and build.library.* and why do we need both This one is my fault. build.* runs 'cabal-bin build', whereas make.* runs 'cabal-bin makefile' followed by 'make'. That is, build.* ends up using ghc --make, whereas make.* ends up using a traditional makefile with ghc -M for dependencies and individual single-module compilations. The latter was added so that we could (a) use make -j and (b) compile single modules for testing/debugging purposes. We don't *need* both - the build system normally only uses make.* (and it would also work perfectly well using build.*, except you'd get no parallelism). One day make.* will go away when Cabal provides the necessary functionality via 'cabal build'. > (and why doesn't one of them work for dph)? no idea about that, sorry. Cheers, Simon From marlowsd at gmail.com Wed Jul 30 09:54:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 30 09:54:48 2008 Subject: Build system woes In-Reply-To: <011f01c8f245$e454ff60$36168351@cr3lt> References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> <011f01c8f245$e454ff60$36168351@cr3lt> Message-ID: <489072A1.6050805@gmail.com> Claus Reinke wrote: > For infrequent updaters like myself, it would also be nice just to have > a HEADS UP before and after periods of larger than usual instability > (such as build system replacements). > And, talking about #ghc, I've got the suspicion that this channel is > partly to blame for the occasional disappearance of critical information: > did I just miss the messages here on cvs-ghc or was the discussion on > #ghc instead? We don't send announcements or "heads-up"-type messages to #ghc, so don't worry you're not missing anything by not watching the channel 24/7. > With no logs for #ghc to browse, I've got no idea what > useful information #ghc inhabitants assume to be widely known!-) > Couldn't lambdabot or some other bot file daily logs for #ghc somewhere, > similar to the logs for #haskell? Then I could check whether my issues > are new or well-known. Hmm, I thought we *did* have IRC logs, but I'm not sure where they're put. We certainly used to have them. Perhaps someone responsible for lambdabot knows? Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Jul 30 10:27:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 30 10:25:49 2008 Subject: Build system woes In-Reply-To: <489070C1.3080102@gmail.com> References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> <489070C1.3080102@gmail.com> Message-ID: <1217428061.12754.360.camel@localhost> On Wed, 2008-07-30 at 14:46 +0100, Simon Marlow wrote: > > I don't think I understand how GHC itself is built any longer, either. > > What does cabal-bin do? > > It's effectively a pre-compiled Setup.hs for packages that have no need for > a custom Setup.hs. cabal-install does the same job for end-users, but we > can't rely on having cabal-install in the GHC build system. The point being that linking default Setup.hs scripts all the time is a waste (especially since it doesn't parallelise). > > What is runghc.wrapper? > > it's a template used to make a shell wrapper for a binary. There seems to > be new functionality in Cabal to support this. Ian added this the other day. I can't say I understand it yet or if it's generally applicable to all packages. Obviously the intention is to allow relocatable binaries on unix systems by using wrapper scripts. Duncan From rl at cse.unsw.edu.au Wed Jul 30 10:55:09 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Jul 30 10:56:28 2008 Subject: Build system woes In-Reply-To: <489070C1.3080102@gmail.com> References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> <489070C1.3080102@gmail.com> Message-ID: On 30/07/2008, at 23:46, Simon Marlow wrote: > We can talk about the general issues on IRC. But I thought I'd > answer a few of the specific questions quickly: Thanks, Simon! > Roman Leschinskiy wrote: > >> I don't think I understand how GHC itself is built any longer, >> either. What does cabal-bin do? > > It's effectively a pre-compiled Setup.hs for packages that have no > need for a custom Setup.hs. cabal-install does the same job for end- > users, but we can't rely on having cabal-install in the GHC build > system. I see. So it looks at the Build-Type in the package description and calls the right defaultMain if it's not Custom. And if my Setup.hs isn't standard then it's my responsibility to set the Build-Type to Custom in the .cabal file and this isn't checked, right? I wonder, though. What exactly does this buy us? Duncan says: > The point being that linking default Setup.hs scripts all the time > is a > waste (especially since it doesn't parallelise). But the time spent in compiling those Setup.hs is negligible and don't understand the "it doesn't parallelise" bit. >> What is runghc.wrapper? > > it's a template used to make a shell wrapper for a binary. There > seems to be new functionality in Cabal to support this. I see. Is runghc the only program we do this for? Or will others be added gradually? >> What is the difference between make.library.* and build.library.* >> and why do we need both > > This one is my fault. build.* runs 'cabal-bin build', whereas make.* > runs 'cabal-bin makefile' followed by 'make'. That is, build.* ends > up using ghc --make, whereas make.* ends up using a traditional > makefile with ghc -M for dependencies and individual single-module > compilations. The latter was added so that we could (a) use make -j > and (b) compile single modules for testing/debugging purposes. Ok, this answers the following question: > > (and why doesn't one of them work for dph)? Because it does non-standard stuff in Setup.hs and hence no Makefile can be generated. Hence the SUBDIRS_BUILD hackery in libraries/ Makefile, I assume. Thanks again! Roman From igloo at earth.li Wed Jul 30 11:38:26 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jul 30 11:38:34 2008 Subject: Build system woes In-Reply-To: References: <138EACAA-220E-4E96-9BB9-B746ACBDB950@cse.unsw.edu.au> <489070C1.3080102@gmail.com> Message-ID: <20080730153826.GA10873@matrix.chaos.earth.li> On Thu, Jul 31, 2008 at 12:55:09AM +1000, Roman Leshchinskiy wrote: > > I see. So it looks at the Build-Type in the package description and > calls the right defaultMain if it's not Custom. And if my Setup.hs > isn't standard then it's my responsibility to set the Build-Type to > Custom in the .cabal file and this isn't checked, right? Nothing checks that Setup.hs behaves as the Build-Type claims it does, no. > I wonder, though. What exactly does this buy us? Duncan says: > > >The point being that linking default Setup.hs scripts all the time > >is a > >waste (especially since it doesn't parallelise). > > But the time spent in compiling those Setup.hs is negligible The time taken and disk space used weren't entirely negligible, especially on arches without object splitting. I think it also makes the Makefiles simpler overall. > >>What is runghc.wrapper? > > > >it's a template used to make a shell wrapper for a binary. There > >seems to be new functionality in Cabal to support this. > > I see. Is runghc the only program we do this for? Or will others be > added gradually? No, hsc2hs, ghc-pkg and ghc also have wrappers. I'm adding them as I move utils over to build with Cabal rather than the old build system. The reason there was a patch just adding a wrapper for runghc is that I forgot to "darcs add" it in an earlier patch. n.b. these wrappers are essentially the same as the old C and shell script wrappers that the old build system made. > >> (and why doesn't one of them work for dph)? > > Because it does non-standard stuff in Setup.hs and hence no Makefile > can be generated. Hence the SUBDIRS_BUILD hackery in libraries/ > Makefile, I assume. Exactly. Thanks Ian From claus.reinke at talk21.com Thu Jul 31 04:14:51 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jul 31 04:14:57 2008 Subject: tools for comparing ghc's debug outputs? Message-ID: <004501c8f2e5$82c54ca0$0b1b7ad5@cr3lt> What tools are there for facilitating comparisons of ghc's debug output? I have reduced a performance problem in my code to a case where switching two lines of code doubles or halves the performance (the results of those lines are stored in record fields that never get used in this reduced example.., see ghc trac ticket #2463). So it should be easy to take the outputs of -ddump-simpl, etc. for both variants and run them through a diff viewer, but there are way too many irrelevant differences and details. I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-) Also, it might be useful if one could translate the transformed code back to highlevel (ghc-)Haskell that would generate the same low-level code (ie, pretending that the source-to-source transformations actually happened at source level). Not only would that blend out irrelevant details, it would also give a direct indication of how to modify the source to get better performing code. What tools are there, and which do you use/recommend for tasks like this? Thanks, Claus From batterseapower at hotmail.com Thu Jul 31 07:42:25 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Jul 31 07:42:24 2008 Subject: tools for comparing ghc's debug outputs? In-Reply-To: <004501c8f2e5$82c54ca0$0b1b7ad5@cr3lt> References: <004501c8f2e5$82c54ca0$0b1b7ad5@cr3lt> Message-ID: <9d4d38820807310442g3dd3290fo5bf3c1115157e44a@mail.gmail.com> 2008/7/31 Claus Reinke : > What tools are there for facilitating comparisons of ghc's > debug output? I have reduced a performance problem in my code to a case > where switching two lines of code doubles > or halves the performance (the results of those lines are stored > in record fields that never get used in this reduced example.., > see ghc trac ticket #2463). > So it should be easy to take the outputs of -ddump-simpl, etc. for both > variants and run them through a diff viewer, > but there are way too many irrelevant differences and details. > > I seem to recall someone mentioning a tool for normalizing > the output of things like -ddump-simpl to make diffs easier > by reducing irrelevant differences due to gensym-generated > names. Was that just wishful thinking, or does such a thing exist?-) I would also find such a tool very useful, but to the best of my knowledge there's nothing out there yet. You can get quite far by using the -dsuppress-uniques flag, which removes irrelevant differences due solely to the unique numbers assigned to names. However, I've found that diff output from that is still hard to deal with because GHC reorders functions in the Core output under some circumstances. I've been meaning to find the time to try and fix this. Cheers, Max From claus.reinke at talk21.com Thu Jul 31 08:26:56 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jul 31 08:27:01 2008 Subject: tools for comparing ghc's debug outputs? References: <004501c8f2e5$82c54ca0$0b1b7ad5@cr3lt> <9d4d38820807310442g3dd3290fo5bf3c1115157e44a@mail.gmail.com> Message-ID: <00ad01c8f308$ba1a8fd0$0b1b7ad5@cr3lt> >> I seem to recall someone mentioning a tool for normalizing >> the output of things like -ddump-simpl to make diffs easier >> by reducing irrelevant differences due to gensym-generated >> names. Was that just wishful thinking, or does such a thing exist?-) > > I would also find such a tool very useful, but to the best of my > knowledge there's nothing out there yet. Surprising - how do all of you optimization tuners manage without? > You can get quite far by using the -dsuppress-uniques flag, which > removes irrelevant differences due solely to the unique numbers > assigned to names. However, I've found that diff output from that is > still hard to deal with because GHC reorders functions in the Core > output under some circumstances. I've been meaning to find the time to > try and fix this. Thanks. Simon PJ also mentioned that (undocumented?) flag, but I must be using it wrong, because ghc --make -O2 Main.hs -dsuppress-uniques -ddump-simpl >simpl-slow still gives me plenty of _labels in the output (6.9.20080514). How is this flag supposed to be used? I've had some success by simply doing a brute-force #s/_[^ _]*\>//g' over the files before diffing, to remove anything that looks like a final addon-label. That isn't quite right (__inline_me becomes __inline, etc), but at least it helps to fold away lots of unwanted detail. Claus From dons at galois.com Thu Jul 31 13:34:45 2008 From: dons at galois.com (Don Stewart) Date: Thu Jul 31 13:34:45 2008 Subject: tools for comparing ghc's debug outputs? In-Reply-To: <00ad01c8f308$ba1a8fd0$0b1b7ad5@cr3lt> References: <004501c8f2e5$82c54ca0$0b1b7ad5@cr3lt> <9d4d38820807310442g3dd3290fo5bf3c1115157e44a@mail.gmail.com> <00ad01c8f308$ba1a8fd0$0b1b7ad5@cr3lt> Message-ID: <20080731173445.GD9849@scytale.galois.com> claus.reinke: > >>I seem to recall someone mentioning a tool for normalizing > >>the output of things like -ddump-simpl to make diffs easier > >>by reducing irrelevant differences due to gensym-generated > >>names. Was that just wishful thinking, or does such a thing exist?-) > > > >I would also find such a tool very useful, but to the best of my > >knowledge there's nothing out there yet. > > Surprising - how do all of you optimization tuners manage without? I use the ghc-core tool, and occasionally piping code into vimdiff, particularly for assembly. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core