- Glasgow-haskell-users

Faster checkout times under Git
by Don Stewart 12 Aug '08

12 Aug '08

Eric Mertens kindly did some experiments on the various git repos, and servers, and approaches to serving. * We're looking at >45 mins for a full history darcs get of ghc, over http, from darcs.haskell.org. * git clone of full ghc over http, from darcs.haskell.org, completes in the range of 6-7 minutes (roughly 150KiB/s) * git clone over git protocol, using github's bandwidth, completes in 2.1 minutes. (roughly 560KiB/s) So that indicates a significant improvment by switching to the git:// server protocol. Can we get that on darcs.haskell.org? In general git is doing a good job here addressing slow 'darcs get ' times, which are now way way down. This will make life easier for some of us. Mirroring automatically to github could also address some of our redundancy concerns. -- Don

2 1

Confusing flags for RULES in GHC
by Simon Peyton-Jones 11 Aug '08

11 Aug '08

Friends The use of flags to control rewrite rules in GHC is very confusing. Several bug reports arise from this. There is a summary here: http://hackage.haskell.org/trac/ghc/ticket/2497 The final comment is a proposal, which I append below. This email is just to allow others to comment on the proposed change. It's all minor and tiresome, but I don't want to change it and then find it's still awkward. NB: please read the whole ticket if you want to comment on these proposals. And add your comments to the ticket. Simon * Do not add -XRewriteRules. A RULE is in a pragma, and so is silently ignored by other compilers anyway. Other pragmas like SPECIALISE do not have a language extension flag. They will generate errors if they are plain wrong (e.g. variables out of scope). But adding a language flag would be inconsistent. * Inside a RULE, switch on the forall-as-keyword in the lexer, unconditionally. Simon M will do this, and send a patch to Simon PJ for validation. * Merge the -XScopedTypeVariables and -XPatternSignatures flags. Distinguishing them isn't senseless, but it's jolly confusing. * Inside a RULE, switch on -XScopedTypeVariables unconditionally. * Change -frewrite-rules to -fuse-rewrite-rules; deprecate the former.

1 0

git and sync-all: Why not merge in libraries?
by Bryan Donlan 07 Aug '08

07 Aug '08

Hi all, With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree (eliminating the need for a 'git-all')? git can merge two histories with no common ancestor, so no history would be lost - though you'd have to ask greater gurus than I the proper procedure. It's been done a few times on git itself to fold in externally developed tools. As I understand it, you could even continue development of the libraries on a seperate tree, as long as you don't try merging changes on ghc.git to $library.git, unless you filter out the GHC-only changes first somehow (merging $library.git back into ghc.git, as I understand it, should work...). Not sure if I'm missing something here, or if it's impractical for some reason... Thanks, Bryan Donlan

2 1

IRC meeting
by Simon Marlow 06 Aug '08

06 Aug '08

IRC Meeting today at 1600 UK time as usual (1500 UTC, 0800 PDT, 1100 EDT). A couple of suggestions for topics; - HEAD stability (re previous disccusion on cvs-ghc) - mechanics of the git switchover Cheers, Simon

1 0

Re: Version control systems
by Felix Martini 06 Aug '08

06 Aug '08

> and Windows support is less of an issue: git appears to work reasonably well on Windows these days. Congratulations on the switch, but isn't the decision a bit premature? I have read the log of last week's GHC meeting on IRC and nobody seemed to know if Git runs well on Windows with a large project like GHC. I also prefer Git to Darcs or Mercurial on Linux, but this rather quick decision makes it look like Windows support of GHC is an afterthought. Regards, Felix

3 2

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