- Glasgow-haskell-users

RE: [Haskell-cafe] Haskell garbage collector notes?
by Bayley, Alistair 06 Aug '08

06 Aug '08

> From: haskell-cafe-bounces(a)haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Galchin, Vasili > > Is > http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes > a reliable source of info on the ghc garbage collector? Depends which version of GHC... the next release (6.10) will include the new parallel GC: http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm http://hackage.haskell.org/trac/ghc/wiki/Status/Releases Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

ANN: prof2dot, version 0.4.1
by Gregory Wright 05 Aug '08

05 Aug '08

I am pleased to announce the release of prof2dot version 0.4.1, a graphical profiling tool for use with GHC. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the "+RTS -px -RTS" option and turns it into a dot file. (The "dot" format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. The new release fixes a number of bugs and has some significant improvements in its internal organization over the previous 0.3.1 ("Premature Optimizations 'r' Us") release. Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating a call graph colored by number of entries into each call center. There is now an option to annotate the graph edges with the triple of (cost center entries, ticks, allocations). Module names are also given in each cost center. The latest version has been tested on the profiling output of some moderately large programs, e.g., the profile produced by a "darcs get" of the entire ghc repository: $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS There is also better error reporting of parser errors and consistency checking of the internal graph data structure. If anyone comes across a parse failure or an assertion failure, please report it to the author. The "dot" program from the graphviz tools is required to render the output of prof2dot. Very large graphs, or graphs with extensive annotations, can exceed the capabilities of dot. Prof2dot is available from Hackage in the "development" category. -Greg

3 3

Need help with GHC API and GHC internals
by Mark Tullsen 04 Aug '08

04 Aug '08

I'm attempting to write a call-graph generator for Haskell using the GHC API. I.e., for each top level value definition, I want a list of the top-level names used in the definition. Using GHC API, once I have a 'CheckedModule', I have a dilemma: a) If I use this field parsedSource :: ParsedSource I've got a giant AST that I need to traverse for names, there being no help in the compiler to do so, AFAIK. b) If I use this field coreBinds :: Maybe [CoreBind] although I've got a simpler type to deal with, and some useful functions (e.g. exprFreeNames), I believe I'm now swimming in waters a bit deep for me or maybe this is just a flawed approach: - the core bindings created do not correspond exactly to the bindings in the source and 'exprFreeNames' is acting in surprising ways. - etc, etc. Does anyone have any advice for me here? Is there some way I can get approach (b) to work without becoming a wizard in GHC internals? Is there anything I'm missing? Thanks, Mark

3 2

tools for comparing ghc's debug outputs?
by Claus Reinke 31 Jul '08

31 Jul '08

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

3 3

Build system woes
by Roman Leschinskiy 30 Jul '08

30 Jul '08

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

6 6

Weekly IRC meeting?
by Simon Marlow 30 Jul '08

30 Jul '08

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

12 21

ghci and source files
by Johannes Waldmann 30 Jul '08

30 Jul '08

-----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-----

3 4

Retainer profiling -- too slow?
by Tim Chevalier 30 Jul '08

30 Jul '08

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

2 1

GHC 6.8.3 in Debian?
by Peter Gammie 29 Jul '08

29 Jul '08

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/

2 1

GHC 6.6 GADT type unification vs GHC 6.8
by Jason Dagit 29 Jul '08

29 Jul '08

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… 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

2 4