November 2010 - Glasgow-haskell-users

Re: [Haskell-cafe] Re: Eq instance for Chan
by Mitar 25 Nov '10

25 Nov '10

Hi! On Thu, Nov 25, 2010 at 5:37 PM, Bas van Dijk <v.dijk.bas(a)gmail.com> wrote: > Officially your patch has to go through the "Library submission" process: A bit overkill for one line but OK. ;-) > Since you already have a ticket the only thing left to do is convert > your patch to a darcs patch and send a proposal to the libraries list. I just have. I attached your patch to the ticket. Thanks. Mitar

1 0

Eq instance for Chan
by Mitar 25 Nov '10

25 Nov '10

Hi! Why is there no Eq instance for Chan? There is Eq for MVar so it is quite possible to define also Eq for Chan? What I would like to do is keep track how many consumers I have for each Chan so duplicating them with dupChan as necessary. So I was thinking of storing a list of Chans which already have a consumer and then duplicating it if another (and every additional) consumer would be added. But without Eq it is not possible to check if there is Chan already in a list (and I hope Eq would compare just Chan and not its content). Is there some other way to achieve this? Mitar

2 2

Implementation of "Scalable Event Handling for GHC"
by tsuraan 23 Nov '10

23 Nov '10

I just read the article "Scalable Event Handling for GHC" by Sullivan and Tibell, and I was wondering if its implementation has been incorporated into the mainline GHC yet. I'm sure the information is out there, but I'm having a bit of trouble searching on it. If it has been integrated into mainline GHC, what version would I need to run to try it out, and is there any documentation on what sort of things I need to do to ensure that the new IO core is being used?

4 5

make tags in GHC build
by John Pybus 20 Nov '10

20 Nov '10

Hi, The documentation suggests that I should be able to do "make tags" to get a vim tags file for the GHC code. http://hackage.haskell.org/trac/ghc/wiki/Building/StandardTargets When doing this on a recent GHC checkout I get: ghctags: user error (You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.9999, now Cabal-1.11.0). Additionally the compiler is different (was ghc-6.12, now ghc-7.1) which is probably the cause of the problem.) make[1]: *** [tags_compiler] Error 1 make: *** [tags] Error 2 rerunning ./configure doesn't make any difference. (building on Ubuntu 10.04 amd64, with haskell platform packages) Does anyone know how to get make tags to work? Thanks, John

1 0

Re: Support for compiler plugins in GHC HEAD
by austin seipp 20 Nov '10

20 Nov '10

Hello, I've updated the patch with a few validate fixes (failings due to -Werror) and a few other things. I've instead uploaded the patch here (to avoid g-h-u and cvs-ghc from blocking me due to a large message so people can see): http://hacks.yi.org/~as/code/ghc/ghc_plugins_support_2010_11_19.dpatch and updated it on the trac page. I'll continue updating the patch on my server to reflect the most recent changes as they come in. Original message below. Regards, Austin On Fri, Nov 19, 2010 at 8:06 PM, austin seipp <as(a)hacks.yi.org> wrote: > Hello everybody, > > (CC'ing max and cvs-ghc in case people lurk in different spots.) > > I have spent the past day and taken the liberty of updating Max > Bolingbroke's original patches for supporting compiler plugins in GHC, > and making > them work with the latest version of GHC HEAD (7.1.x.) > > It is very sad IMO that this work went by so long without being merged > mainline, but the CoreM and Annotations code was merged into mainline > long > long ago before the advent of dynamic linking (and many other things) > in GHC. This part of the task floundered around and so I decided to do > something about it. > > I would like to see this code merged mainline and supported in future > major releases of GHC. I am willing to take responsibility for > updating and maintaining it > and bringing it up to the code quality standards the GHC team expects > (which I'm sure which will be necessary.) It is early in the GHC 7.2 > development cycle, so ideally > it could be merged soon so we have as long as possible to fix bugs and > change things if necessary until the 7.2 release. > > Most of the code is written by Max originally and perhaps slightly > modified by me to update it with changes to the simplifier and linker > interface. Most of it was untouched, actually. > > It has been tested only on my linux machine (debian x86_64, kernel > 2.6.34,) with GHC 7.1.x x86_64. I also have a macbook I can test the > patches on (x86_64 darwin, snow leopard, i386 ghc 7.1.x) but I > have yet to get around to it. > > The patch is quite small actually (smaller than max's original, > although I intentionally left out things that were unnecessary or > refactorings) so hopefully reviewing it is not much of a burden on you > guys at > GHC HQ. > > Caveat: I have not yet ported over Max's testsuite patches, which just > build a plugin and expect some output when run. I'm getting around to > it although I have to figure out the test suite infrastructure a > little > first I guess. > > ============================================== > == Getting the patch and using it > > I have uploaded the patch onto the relevant trac ticket here: > http://hackage.haskell.org/trac/ghc/ticket/3843 > > It is also attached to this email. In the future I might put up a GHC > repo on my webserver so you can just directly pull patches from it (I > like this more than emailing patches around, personally) with darcs. > > After you download the patch and apply it with darcs, go ahead and > build the regular stage2 compiler (do "perl boot; ./configure; make > -j3" for dual core, etc.) > > Then, download this CSE plugin from github, load it and compile the > example (again, originally written by Max and slightly modified to > work by myself): > > https://github.com/thoughtpolice/cse-ghc-plugin > > Like so: > > $ pwd > /home/a/ > $ cd src > $ git clone git://github.com/thoughtpolice/cse-ghc-plugin.git > $ cd cse-ghc-plugin > > # assumes your GHC build is in ~/src/ghc-head+plugins/ > $ cabal install -w ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 > ... > > #plugin now installed, we can use it: > $ cd tests > $ pwd > /home/a/src/cse-ghc-plugin/tests/ > $ ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 -fforce-recomp > -fno-cse Traced.hs > [1 of 1] Compiling Main ( Traced.hs, Traced.o ) > Linking Traced ... > $ ./Traced > The test is successful if the word 'Evaluated' appears only once below: > Evaluated > Evaluated > # now do CSE through the plugin we installed > $ ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 -fforce-recomp > -fno-cse Traced.hs -fplugin=CSE.Plugin > [1 of 1] Compiling Main ( Traced.hs, Traced.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Loading package array-0.3.0.2 ... linking ... done. > Loading package containers-0.4.0.0 ... linking ... done. > Loading package filepath-1.2.0.0 ... linking ... done. > Loading package old-locale-1.0.0.2 ... linking ... done. > Loading package old-time-1.0.0.6 ... linking ... done. > Loading package unix-2.4.1.0 ... linking ... done. > Loading package directory-1.1.0.0 ... linking ... done. > Loading package pretty-1.0.1.2 ... linking ... done. > Loading package process-1.0.1.4 ... linking ... done. > Loading package Cabal-1.11.0 ... linking ... done. > Loading package bytestring-0.9.1.8 ... linking ... done. > Loading package binary-0.5.0.2 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hpc-0.5.0.6 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package ghc-7.1.20101120 ... linking ... done. > Loading package cse-plugin-1.0 ... linking ... done. > Linking Traced ... > $ ./Traced > The test is successful if the word 'Evaluated' appears only once below: > Evaluated > $ > > I'm currently validating my patch against the HEAD tree, but I > speculate there won't be any problems (nothing huge has really changed > honestly, and nothing happens when you don't invoke a plugin.) > > Max also wrote 2 other plugins, a strictifier (transforms haskell into > a strict language) and a loop unroller, but I have yet to update them. > > All comments are welcome (here or in trac.) > > Regards, > Austin >

1 0

How to optimize the memory usage of "linking"?
by Magicloud Magiclouds 19 Nov '10

19 Nov '10

Hi, When I use ghc to make large project, the almost-final step of linking takes a lot of memory. This is horrible on host with little memory (i.e. 512MB). Is there any way I can optimize this? Thanks. -- 竹密岂妨流水过山高哪阻野云飞

2 1

RE: [Haskell-cafe] Impredicative Types
by Simon Peyton-Jones 19 Nov '10

19 Nov '10

read the QML paper! that's the trick. simpler, but with a heavier annotation burden than the more sophisticated approaches | -----Original Message----- | From: Gregory Crosswhite [mailto:gcross@phys.washington.edu] | Sent: 19 November 2010 19:59 | To: Simon Peyton-Jones | Cc: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Re: [Haskell-cafe] Impredicative Types | | Awesome, thank you. :-) One more question out of pure curiosity, if | you have the time: What is allowing you to keep them in? I thought | that the problem was that they made a mess that touched every party of | the type checker rather than being centralized in one place. Was there | a trick you discovered that now allows you to support them without | creating such a mess? | | Cheers, | Greg | | On 11/19/10 11:45 AM, Simon Peyton-Jones wrote: | > Yes, impredicative types are still in, but in a simpler form than before, along the | lines of QML | > http://research.microsoft.com/en-us/um/people/crusso/qml/ | > | > I have been too busy with getting the new type checker working to describe or | document it. Notably, I have not yet added syntax for QML's rigid type annotations, | which leads to a loss of expressive power. | > | > too much to do! | > | > Bottom line: if you are interested in impredicative polymorphism, let me know. A | good way to do so would be to register your interest on | > http://hackage.haskell.org/trac/ghc/ticket/4295 | > Just add your email address to the cc list, *and* write a comment giving an example | of how you are using impredicative poly, and pointing to any further info. That'll help | motivate me to do the remaining work! | > | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- | bounces(a)haskell.org] | > | On Behalf Of Gregory Crosswhite | > | Sent: 19 November 2010 19:23 | > | To: Haskell Cafe | > | Subject: [Haskell-cafe] Impredicative Types | > | | > | Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw | > | in the documentation that Impredicative Types are still supported. Is | > | this true? I thought that they were on their way out because they | > | overcomplicated type checking; has this plan been changed? | > | | > | Cheers, | > | Greg | > | _______________________________________________ | > | Haskell-Cafe mailing list | > | Haskell-Cafe(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/haskell-cafe | > |

1 0

RE: [Haskell-cafe] Impredicative Types
by Simon Peyton-Jones 19 Nov '10

19 Nov '10

Yes, impredicative types are still in, but in a simpler form than before, along the lines of QML http://research.microsoft.com/en-us/um/people/crusso/qml/ I have been too busy with getting the new type checker working to describe or document it. Notably, I have not yet added syntax for QML's rigid type annotations, which leads to a loss of expressive power. too much to do! Bottom line: if you are interested in impredicative polymorphism, let me know. A good way to do so would be to register your interest on http://hackage.haskell.org/trac/ghc/ticket/4295 Just add your email address to the cc list, *and* write a comment giving an example of how you are using impredicative poly, and pointing to any further info. That'll help motivate me to do the remaining work! Thanks Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] | On Behalf Of Gregory Crosswhite | Sent: 19 November 2010 19:23 | To: Haskell Cafe | Subject: [Haskell-cafe] Impredicative Types | | Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw | in the documentation that Impredicative Types are still supported. Is | this true? I thought that they were on their way out because they | overcomplicated type checking; has this plan been changed? | | Cheers, | Greg | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Using the GHC API: pretty printing with qualified names
by JP Moresmau 19 Nov '10

19 Nov '10

Hello, I'm the maintainer for EclipseFP, which involves using the scion library and the GHC API to provide IDE functionality. I have a little issue that no doubt stems from me not understanding the GHC API well, and I would be grateful for any light on the matter. I'm trying to give the user the possibility to jump to the definition of a symbol in the source file. You click on the name of a function and you're send to the module where it's defined. So I have an AST, and somewhere down the line I have an Id object representing that function call. Then I just use ppr alwaysQualify id to get the fully qualified name of the function, and I can then use the module name to retrieve the source file etc. This works well in cases, but not in others. It will sound silly to the gurus on the list, but it's when the function has generics that it doesn't work. So a function with a type class in its type signature will never be printed qualified. It kinda like makes sense because I suppose some work has been done so that it represents the function with proper types, etc., but how can I get back to the original Id? How can I get back from that unqualified Id to the qualified Id representing the function in the original module? I've been looking round Name and OccName and all that but I'm not sure really what I'm looking for. Hope I'm making sense!! Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

5 9

List vs Data.List
by Serge D. Mechveliani 18 Nov '10

18 Nov '10

In ghc-7.0.1, to import `partition', it is sufficient the line import List (partition), but to import `intercalate', it is needed import Data.List (intercalate). Does Haskell-2010 differ between List and Data.List import? Thank you in advance for explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1