Re: Dynamic libraries by default and GHC 7.8
On 27 November 2012 17:00, Ian Lynagh i...@well-typed.com wrote: We would love for Windows to be one of the platforms, but currently we can't do it on Windows. So unless that changes, Windows will not be one of the platforms, correct. So if I understand correctly, the problem here arises because you can't import from a DLL by *absolute path* but only by *relative path*? The tragedy here is that the Windows loader actually supports loading from absolute paths natively, as an undocumented feature. If you build a EXE and then hexedit the references to library.dll to absolute paths C:\library.dll then your EXE will run completely correctly. I'm not sure how to convince GNU ld to link us such a DLL, though. It might be possible to hack it in by linking against verylongdummydllname.dll and then having GHC search for that string in DLL/EXE returned by LD and replace it by the null-terminated absolute path. Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 6 December 2012 09:27, Max Bolingbroke batterseapo...@hotmail.com wrote: I'm not sure how to convince GNU ld to link us such a DLL, though. It might be possible to hack it in by linking against verylongdummydllname.dll and then having GHC search for that string in DLL/EXE returned by LD and replace it by the null-terminated absolute path. While I was in the shower I figured out how to make this work: 1. We need to create an *import library* for every Haskell DLL. This import library will export all the functions exported by the normal DLL, but we will ensure that it has an absolute path name in the .idata section 2. To create the import library, there are two methods: a) If we know all the object files that went into linking the DLL (we don't care about other linker flags like the DLLs that the current DLL depends on), we can just use dlltool --output-lib foo.lib object files to generate the library. b) If we don't know the object files, we will instead have to create a .def file using mingw's pexports utility/nm/dumpbin, and then run dlltool --output-lib foo.lib -d foo.def 3. In ether case, we should create the object file with --dllname verylongdummymodulename.dll 4. After dlltool returns, we simply go into the import library and replace the dummy module name with the absolute path 5. When linking against Haskell DLLs later on, simply link against the import library rather than the DLL itself I've tested this by hand and it seems like it works: the absolute paths you hack into the import library are not messed with by the later link step. The resulting executables run flawlessly. Job done. Seem plausible? Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC still support x87 floating point math?
On 06/12/2012, at 12:12 , Johan Tibell wrote: I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? It's on by default unless you use the -sse2 flag. The x87 support is horribly slow though. I don't think anyone would notice if you deleted the x87 code and made SSE the default, especially now that we have the LLVM code generator. SSE has been the way to go for over 10 years now. Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On 06/12/2012, at 3:56 , Simon Peyton-Jones wrote: Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. The LLVM project has recently come to the same point. The codebase has become too large for Chris Lattner to keep track of it all, so they've moved to a formal Code Ownership model. People own particular directories of the code base, and the code owners are expected to review patches for those directories. The GHC project doesn't have a formal patch review process, I think because the people with commit access on d.h.o generally know who owns what. Up until last week I think it was SPJ owns the type checker and simplifier, and SM owns everything else. :-) At this stage, I think it would help if we followed the LLVM approach of having a formal CODE_OWNERS file in the root path of the repo explicitly listing the code owners. That way GHC HQ knows what's covered and what still needs a maintainer. The LLVM version is here [1]. Code owners would: 1) Be the go-to person when other developers have questions about that code. 2) Fix bugs in it that no-one else has claimed. 3) Generally keep the code tidy, documented and well-maintained. Simon: do you want a CODE_OWNERS file? If so then I can start it. I think it's better to have it directly in the repo than on the wiki, that way no-one that works on the code can miss it. I suppose I'm the default owner of the register allocators and non-LLVM native code generators. Ben. [1] http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC still support x87 floating point math?
Ben Lippmeier b...@ouroborus.net writes: On 06/12/2012, at 12:12 , Johan Tibell wrote: I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? It's on by default unless you use the -sse2 flag. The x87 support is horribly slow though. I don't think anyone would notice if you deleted the x87 code and made SSE the default, especially now that we have the LLVM code generator. SSE has been the way to go for over 10 years now. btw, iirc GHC uses SSE2 for x86-64 code generation by default, and that the -msse2 option has only an effect when generating x86(-32) code ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting * cvs-ghc: for GHC *developers* I don't think we want to confuse users with developers. If we flood users with dev-related conversations they'll get fed up. I don't see a very useful distinction between glasgow-haskell-users and glasgow-haskell-bugs. The distinction was very important before we had a bug tracker, but it doesn't seem useful now. I can see a perhaps-useful distinction between two *developer* lists (A) human email about implementation aspects of GHC (B) machine-generated email from buildbots etc I rather think that (A) could usefully include Trac ticket creation and Git commit messages, since both are really human-generated. So that would leave only buildbot logs on (B). So I would be content to * Abolish glasgow-haskell-bugs in favour of glasgow-haskell-users * Split out cvs-ghc into two in some way; details to be agreed. But for me the issue is not a pressing one. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Austin Seipp | Sent: 06 December 2012 03:21 | To: Carter Schonwald | Cc: GHC Users List | Subject: Re: proposal: separate lists for ghc-cvs commits and ghc-dev | chatter | | I think we already mostly have this. The separation (remembering | something I read off Trac I think,) was something like: | | * cvs-ghc mailing list: Prospective patches, automatically generated | build/commit emails, etc. | * glasgow-haskell-users mailing list: Developers and users of GHC | discussing issues of design, process, bugs or fielding questions et | cetera | | Doing some counting: looking at my email (which is gmail,) I have the | last 100 most recent email *threads* open from cvs-ghc. The 100th dates | to Nov 30th. I count about ~7 instances of non-build-or-commit-generated | discussions in this timeframe (that is, | ~7 email threads where the content wasn't just a build email, but a | follow up, or it was actually it's own thread.) Almost all of these | instances are related to patches or patches that were committed and some | talk happened about them. One (maybe two) were about build/test | failures. | | In contrast, for glasgow-haskell-users, for the past 100 threads: the | 100th thread dates to July 12th. However, the structure of all these | conversations is far, far more rich: just about every single thread | contains far more discussion, almost 100% of them containing at least | 2-3 emails. Some go as far as 20-70 emails deep, and many have several | handfuls of responses. This is just for the past few months but I've | been subscribed to both for years, so I'd say that sounds about right. | | From this, I would infer that most of the interesting discussion does, | in fact, happen on glasgow-haskell-users. There are perhaps fewer topics | at a less regular pace, but it's really here. In contrast, cvs-ghc is | mostly autogenerated stuff regular developers etc care about, with the | sprinkling of discussion, almost all of it for patches or failures it | seems. | | The thing is, I would think that most people who are trying to get into | routinely hacking on GHC would want to be subscribed to both anyway. | Personally I think commits are the most valuable asset I can see at a | glance. But Johan has discussed having Jenkins performance regressions | sent out in light of the recent performance Tsar work, and (some of) the | bots do report success nightly here. So for people who aren't submitting | a benign patch or doing one-off-work, you are probably at least going to | want that stuff on your radar. But even just looking at the work others | are doing can give you ideas, or give you familiarity with something | (it's even exciting to read patches | sometimes!) | | Overall I think the current separation is actually pretty good. Most of | the real meaty questions are asked here, and the developers routinely | sit on cvs-ghc to talk about patches or build failures and the like. | However, I do agree that sometimes you can miss out on interesting | discussion that happens there. Perhaps the rules could be changed so | that: | | * cvs-ghc is only for automatically-generated content like build emails, | regressions, and commits. | * glasgow-haskell-users is for everything else, including patch review | (which also happens on trac) or discussing failures/regressions. | | I don't know how attached I am to the current scheme, but perhaps this | sounds better to some, and I thought I could offer .02c having been | listening here for a while. :) | | On Wed, Dec 5, 2012 at 8:31 PM, Carter Schonwald | carter.schonw...@gmail.com
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 6, 2012 at 1:29 PM, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting * cvs-ghc: for GHC *developers* I don't think we want to confuse users with developers. If we flood users with dev-related conversations they'll get fed up. I don't see a very useful distinction between glasgow-haskell-users and glasgow-haskell-bugs. The distinction was very important before we had a bug tracker, but it doesn't seem useful now. I can see a perhaps-useful distinction between two *developer* lists (A) human email about implementation aspects of GHC (B) machine-generated email from buildbots etc I rather think that (A) could usefully include Trac ticket creation and Git commit messages, since both are really human-generated. I think the last two things (tickets and commit messages) should be separate from a mailing that is intended for (email-only) discussion. The content may be human-generated, but: (1) The number of messages is overwhelming. Alternatively stated, if you consider each ticket or commit message a different thread (which many email clients do), the number of different threads is large. (2) The commit messages do not all lead to conversations, and most of the discussion on tickets takes place on Trac with every message duplicated to the list. Consequently, any email-only discussion threads on the mailing list can easily get lost among all the other threads. So that would leave only buildbot logs on (B). So I would be content to * Abolish glasgow-haskell-bugs in favour of glasgow-haskell-users * Split out cvs-ghc into two in some way; details to be agreed. But for me the issue is not a pressing one. I identify the following different needs: (1) User email discussion (2) Developer email discussion (3) Buildbot reports (4) Trac reports (5) Commit messages Users will be interested in (1). Developers or followers of GHC development are probably interested in (1) and (2) but not necessarily (3 - 5). Maintainers or serious developers are probably interested in some combination of the above, including (1) and (2). People who track bugs (in general or for fun) would be interested in (4). Since Trac tickets have a CC option, many people probably don't need to subscribe to this list. Developers who police development would be interested in (3 - 5). By having a separate mailing list for each of (1) and (2), the email-only discussion does not get overwhelmed by the traffic of (3 - 5). And a separate mailing for each of (3 - 5) would allow the interested parties to subscribe to only what they want. Also, if you want to respond to an email on (3 - 5), then you are probably already subscribed to (2), so you can CC (2) in your response, thus bringing more developers into the conversation. (Personally, I've been using filters in Gmail to mark-read stuff that I'm not interested in, but I would be even happier to have the mailing lists further segmented.) Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 6 December 2012 10:05, Max Bolingbroke batterseapo...@hotmail.com wrote: I've tested this by hand and it seems like it works: the absolute paths you hack into the import library are not messed with by the later link step. The resulting executables run flawlessly. Job done. To continue spamming the list, I'd just like to advertise my blog post explaining the proposed technique, with a worked example: http://blog.omega-prime.co.uk/?p=138 Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
Somebody claiming to be Erik de Castro Lopo wrote: This is a good idea, one that I have solved at my end using Procmail. I was planning to do this soon (as I get deeper into GHC hacking because of my port, but don't want the high-email-volume of the comitt and build emails). Procmail is awesome. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Performance Tsar
I'm particularly interested in parallel performance in the 8 core space. (In fact, we saw some regressions from 7.2-7.4 that we never tracked down properly, but maybe can now.) If the buildbot can make it easy to add a new slave machine that runs and uploads its result to a central location, then I would be happy to donate a few hours of dedicated time (no other logins) on a 32 core westmere machine, and hopefully other architectures soon. Maybe, this use case is well-covered by creating a jenkins/travis slave and letting it move the data around? (CodeSpeed looks pretty nice too.) Cheers, -Ryan On Wed, Dec 5, 2012 at 12:40 AM, Ben Lippmeier b...@ouroborus.net wrote: On 01/12/2012, at 1:42 AM, Simon Peyton-Jones wrote: | While writing a new nofib benchmark today I found myself wondering | whether all the nofib benchmarks are run just before each release, I think we could do with a GHC Performance Tsar. Especially now that Simon has changed jobs, we need to try even harder to broaden the base of people who help with GHC. It would be amazing to have someone who was willing to: * Run nofib benchmarks regularly, and publish the results * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep track of regressions * Investigate regressions to see where they come from; ideally propose fixes. * Extend nofib to contain more representative programs (as Johan is currently doing). That would help keep us on the straight and narrow. I was running a performance regression buildbot for a while a year ago, but gave it up because I didn't have time to chase down the breakages. At the time we were primarily worried about the asymptotic performance of DPH, and fretting about a few percent absolute performance was too much of a distraction. However: if someone wants to pick this up then they may get some use out of the code I wrote for it. The dph-buildbot package in the DPH repository should still compile. This package uses http://hackage.haskell.org/package/buildbox-1.5.3.1 which includes code for running tests, collecting the timings, comparing against a baseline, making pretty reports etc. There is then a second package buildbox-tools which has a command line tool for listing the benchmarks that have deviated from the baseline by a particular amount. Here is an example of a report that dph-buildbot made: http://log.ouroborus.net/limitingfactor/dph/nightly-20110809_000147.txt Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
* Sean Leather leat...@cs.uu.nl [2012-12-06 14:23:27+0100] I think the last two things (tickets and commit messages) should be separate from a mailing that is intended for (email-only) discussion. The content may be human-generated, but: (1) The number of messages is overwhelming. Alternatively stated, if you consider each ticket or commit message a different thread (which many email clients do), the number of different threads is large. (2) The commit messages do not all lead to conversations, and most of the discussion on tickets takes place on Trac with every message duplicated to the list. +1. I'd like to follow GHC development discussions, but getting all the commits is too much. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
I have the same opinion as Ian; I'm happy with the current setup, but if things change I'll just subscribe to everything anyway. Cheers, Pedro On Thu, Dec 6, 2012 at 4:55 PM, Ian Lynagh i...@well-typed.com wrote: On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting I see glasgow-haskell-bugs as being mainly for developers, who want to see what bugs are coming in. It's true that we do give e-mailing it as a (less preferred) way for users to submit a bug on http://hackage.haskell.org/trac/ghc/wiki/ReportABug but I wonder if we shouldn't change that. It's rare that we get a bug report e-mailed, and normally we ultimately end up creating a trac ticket for it anyway. I'm sure that people who really want to submit a bug report and for whatever reason can't use trac will e-mail it somewhere sensible. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote: I suppose I'm the default owner of the register allocators and non-LLVM native code generators. Great, thanks! By the way, if you feel like doing some hacking this holiday season, then you might be interested in http://hackage.haskell.org/trac/ghc/ticket/7063 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Wed, Dec 05, 2012 at 12:42:33PM -0800, Johan Tibell wrote: I will maintain the I/O manager as per usual Excellent, thanks! There are a couple of tickets that are currently assigned to me that look like they might be IO manager bugs: http://hackage.haskell.org/trac/ghc/ticket/4245 http://hackage.haskell.org/trac/ghc/ticket/7133 I'm unlikely to have time to look at either of them in the near future, so please feel free to reassign them to yourself and take a look. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Wed, Dec 05, 2012 at 12:37:22PM -0800, David Terei wrote: I have always considered the LLVM code generator my responsibility and will continue to do so. Great, thanks! I don't seem to find the time to make improvements to it but make sure to keep it bug free and working with the latest LLVM releases. So if others want are interested in working on it then there is plenty of room for that but I'll continue to maintain it and be responsible for it at the least. And of course, if anyone does find themselves looking for an LLVM-related ticket to fix, there's a component for them in trac: http://hackage.haskell.org/trac/ghc/query?status=infoneededstatus=newstatus=patchcomponent=Compiler+%28LLVM%29 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Patch to enable GHC runtime system with thr_debug_p options...
On Mon, Dec 03, 2012 at 09:11:07PM +0100, Joachim Breitner wrote: Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? The main reasons not to add RTS ways are that they take time to build, and use disk space once built. For a distribution, it probably makes sense to build all of them (even if some are put in a separate ghc-rts-extra-ways package) as the compile-time is shared amongst many users, and it is harder for the user to build extra ways. It's also true that non-default ways are less-well-tested, but that doesn't necessarily mean they are buggier. And building them certainly shouldn't cause any bugs when not using those extra ways. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
Hello, I also sometimes wish that GHC developer discussions happened in a single place, separate from the commits and ticket lists (at present they are sometimes on ghc-users and sometimes on cvs-ghc). For what it's worth, I don't follow the commit and build-bot messages closely, instead I use various git tools to catch up on what's going on with the development (mostly I use gitk, git-gub, and our own git-web instance on darcs.haskell.org). I do find the trac bug messages useful though, both as a GHC user and a GHC developer. -Iavor On Thu, Dec 6, 2012 at 9:04 AM, Ian Lynagh i...@well-typed.com wrote: On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting I see glasgow-haskell-bugs as being mainly for developers, who want to see what bugs are coming in. It's true that we do give e-mailing it as a (less preferred) way for users to submit a bug on http://hackage.haskell.org/trac/ghc/wiki/ReportABug but I wonder if we shouldn't change that. It's rare that we get a bug report e-mailed, and normally we ultimately end up creating a trac ticket for it anyway. I'm sure that people who really want to submit a bug report and for whatever reason can't use trac will e-mail it somewhere sensible. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 6, 2012 at 5:55 PM, Ian Lynagh wrote: On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, Indeed, it can be. But I can't keep up with the huge number of commits everyday, and I'm not interested in the large majority of them. while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. I find these things (both examples, actually) more interesting. I'm more likely to follow such threads than I am to skim the commits. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) I'm not too fussed about it, either, but I wouldn't mind a restructuring. I might even subscribe to them all as well, but then it will be easier to follow the commits at a different pace from the rest (without having to create a new filter, which I've been so far too lazy to do). Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
I'd also like to follow discussions, but unsubscribed from cvs-ghc due to the volume. Maybe the reply-to field on cvs-ghc emails could be set to glasgow-haskell-bugs? (or whatever the agreed upon dev list is called) Then if someone replies to a bot/commit message on cvs-ghc, it automatically goes to the place where active discussion happens, and those of us that don't want so many emails won't have to dig through cvs-ghc to find the interesting bits. Andrew On Thu, Dec 6, 2012 at 11:48 AM, Sean Leather leat...@cs.uu.nl wrote: On Thu, Dec 6, 2012 at 5:55 PM, Ian Lynagh wrote: On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, Indeed, it can be. But I can't keep up with the huge number of commits everyday, and I'm not interested in the large majority of them. while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. I find these things (both examples, actually) more interesting. I'm more likely to follow such threads than I am to skim the commits. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) I'm not too fussed about it, either, but I wouldn't mind a restructuring. I might even subscribe to them all as well, but then it will be easier to follow the commits at a different pace from the rest (without having to create a new filter, which I've been so far too lazy to do). Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Generating a C call from a MachOp
Hi, I'm trying to implement word2Double#, which I represent as a MachOp I call MO_UF_Conv (which is very similar to MO_SF_Conv). On some platform I need to implement this MachOp as a call to a C function. Here's what I did in the PPC backend (PPC/CodeGen.hs) for example: getRegister' dflags (CmmMachOp mop [x]) -- unary MachOps = case mop of MO_UF_Conv from to - coerceWord2FP from to x coerceWord2FP :: Width - Width - CmmExpr - NatM Register coerceWord2FP fromRep toRep x = do dflags - getDynFlags (src, src_code) - getSomeReg x -- This is not the type of register I need! dst - getNewRegNat (floatSize toRep) targetExpr - cmmMakeDynamicReference dflags addImportNat CallReference lbl let target = ForeignTarget targetExpr (ForeignConvention CCallConv [NoHint] [NoHint] CmmMayReturn) call_code - genCCall target [src] [dst] let code' = src_code `appOL` call_code return (Fixed (floatSize toRep) dst code') where lbl = mkCmmCodeLabel primPackageId (fsLit $ word2FloatLabel toRep) This doesn't work. The issue is that to make a C call I need CmmFormals and CmmActuals. I cannot figure out how to get the former, as I need to get hold of a LocalReg, which I don't see any way of creating. I could try to make MO_UF_Conv a CallishMachOp, but then I'll have a more difficult time implementing this MachOp in e.g. the LLVM backend, where I don't want to generate a C call but instead output some instructions. I could use some pointers. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extending GHCi
On Tue, Dec 04, 2012 at 04:23:02PM +0100, Dennis Felsing wrote: Is there a way to extend GHCi without copying some of its source code? Someone was looking at moving the ghci code into a library, which may mean you need to copy less code, at least. I'm not sure what the status of that is, though. Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? Sure, providing the complexity is not disproportionately high for the functionality. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 05/12/12 15:17, Brandon Allbery wrote: On Wed, Dec 5, 2012 at 12:03 AM, Chris Smith cdsm...@gmail.com mailto:cdsm...@gmail.com wrote: I'm curious how much of the compile twice situation for static and dynamic libraries could actually be shared. Probably none; on most platforms you're actually generating different code (dynamic libraries require generation of position-independent code). That said, the PPC ABI uses position-independent code even for static libraries and I think Apple decided to go that route on Intel as well rather than change their build system ... but if you do this then linking to other platform-native libraries may be more difficult. Not a problem for Apple since they control the ABI, but not something ghc can force on libc or random libraries someone might want to use FFI with. Sure there's a lot of differences in the generated code, but inside GHC these differences only appear at the very last stage of the pipeline, native code generation (or LLVM). All the stages up to that can be shared, which accounts for roughly 80% of compilation time (IIRC). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On 06/12/12 17:04, Ian Lynagh wrote: On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting I see glasgow-haskell-bugs as being mainly for developers, who want to see what bugs are coming in. It's true that we do give e-mailing it as a (less preferred) way for users to submit a bug on http://hackage.haskell.org/trac/ghc/wiki/ReportABug but I wonder if we shouldn't change that. It's rare that we get a bug report e-mailed, and normally we ultimately end up creating a trac ticket for it anyway. I'm sure that people who really want to submit a bug report and for whatever reason can't use trac will e-mail it somewhere sensible. +1. ghc-bugs used to be for user-generated bug reports, but now it is almost exclusively Trac-generated emails. I don't think anything is gained by suggesting that people email bug reports any more. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On 06/12/12 13:23, Sean Leather wrote: On Thu, Dec 6, 2012 at 1:29 PM, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting * cvs-ghc: for GHC *developers* I don't think we want to confuse users with developers. If we flood users with dev-related conversations they'll get fed up. I don't see a very useful distinction between glasgow-haskell-users and glasgow-haskell-bugs. The distinction was very important before we had a bug tracker, but it doesn't seem useful now. I can see a perhaps-useful distinction between two *developer* lists (A) human email about implementation aspects of GHC (B) machine-generated email from buildbots etc I rather think that (A) could usefully include Trac ticket creation and Git commit messages, since both are really human-generated. I think the last two things (tickets and commit messages) should be separate from a mailing that is intended for (email-only) discussion. The content may be human-generated, but: (1) The number of messages is overwhelming. Alternatively stated, if you consider each ticket or commit message a different thread (which many email clients do), the number of different threads is large. (2) The commit messages do not all lead to conversations, and most of the discussion on tickets takes place on Trac with every message duplicated to the list. Consequently, any email-only discussion threads on the mailing list can easily get lost among all the other threads. So that would leave only buildbot logs on (B). So I would be content to * Abolish glasgow-haskell-bugs in favour of glasgow-haskell-users * Split out cvs-ghc into two in some way; details to be agreed. But for me the issue is not a pressing one. I identify the following different needs: (1) User email discussion (2) Developer email discussion (3) Buildbot reports (4) Trac reports (5) Commit messages Sounds good to me. I like the idea of separating out the buildbot reports too, because there tends to be little signal in those (I typically only look at one per day, just to check whether there's anything really broken). Although that problem could be solved a different way, by having the build server emit a single email with a good summary once per day. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC still support x87 floating point math?
On 06/12/12 11:01, Herbert Valerio Riedel wrote: Ben Lippmeier b...@ouroborus.net writes: On 06/12/2012, at 12:12 , Johan Tibell wrote: I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? It's on by default unless you use the -sse2 flag. The x87 support is horribly slow though. I don't think anyone would notice if you deleted the x87 code and made SSE the default, especially now that we have the LLVM code generator. SSE has been the way to go for over 10 years now. btw, iirc GHC uses SSE2 for x86-64 code generation by default, and that the -msse2 option has only an effect when generating x86(-32) code Yes, because all x86_64 CPUs support SSE2. Chips older than P4 don't support it. I imagine there aren't too many of those around that people want to run GHC on, and as Ben says, there's always -fllvm. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting constants to the .data section from the NatM monad
On 06/12/12 00:29, Johan Tibell wrote: Hi! I'm trying to implement word2Double# and I've looked at how e.g. LLVM does it. LLVM outputs quite clever branchless code that uses two predefined constants in the .data section. Is it possible to add contents to the current .data section from a function in the NatM monad e.g. coerceWord2FP :: Width - Width - CmmExpr - NatM Register ? Yes, you can emit data. Look at the LDATA instruction in the X86 backend, for example, and see how we generate things like table jumps. So are you going to add the two missing MachOps, MO_UF_Conv MO_FU_Conv? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Thu, Dec 6, 2012 at 4:04 PM, Simon Marlow marlo...@gmail.com wrote: On 05/12/12 15:17, Brandon Allbery wrote: Probably none; on most platforms you're actually generating different code (dynamic libraries require generation of position-independent Sure there's a lot of differences in the generated code, but inside GHC these differences only appear at the very last stage of the pipeline, native code generation (or LLVM). All the stages up to that can be shared, which accounts for roughly 80% of compilation time (IIRC). I was assuming it would be difficult to separate those stages of the internal compilation pipeline out, given previous discussions of how said pipeline works. (In particular I was under the impression saving/restoring state in the pipeline to rerun the final phase with multiple code generators was not really possible, and multithreading them concurrently even less so.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 06/12/12 21:35, Brandon Allbery wrote: On Thu, Dec 6, 2012 at 4:04 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 05/12/12 15:17, Brandon Allbery wrote: Probably none; on most platforms you're actually generating different code (dynamic libraries require generation of position-independent Sure there's a lot of differences in the generated code, but inside GHC these differences only appear at the very last stage of the pipeline, native code generation (or LLVM). All the stages up to that can be shared, which accounts for roughly 80% of compilation time (IIRC). I was assuming it would be difficult to separate those stages of the internal compilation pipeline out, given previous discussions of how said pipeline works. (In particular I was under the impression saving/restoring state in the pipeline to rerun the final phase with multiple code generators was not really possible, and multithreading them concurrently even less so.) I don't think there's any problem (unless I've forgotten something). In fact, the current architecture should let us compile one function at a time both ways, so we don't get a space leak by retaining all the Cmm code. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting constants to the .data section from the NatM monad
On Thu, Dec 6, 2012 at 1:34 PM, Simon Marlow marlo...@gmail.com wrote: So are you going to add the two missing MachOps, MO_UF_Conv MO_FU_Conv? I'm trying to add those. I'm now thinking that I will use C calls (which is still much faster than going via Integer) instead of emitting some assembly, as the former is much easier but still allows us to do the latter later. The LLVM backend will use the dedicated LLVM instruction for conversions so it will generate really good code. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Which of the following PrimTyCons have a pointer-sized representations
Hi, As part of some work I'm doing I need to classify all PrimTyCons by the size of their representation as fields*. I need to classify them into two classes: pointer-sized (or smaller) and larger-than-pointer-sized. I've managed to figure out a bunch of them myself: Pointer-sized: addrPrimTyCon arrayPrimTyCon byteArrayPrimTyCon -- Represented as a pointer to heap object arrayArrayPrimTyCon -- Represented as a pointer to heap object charPrimTyCon doublePrimTyCon -- Only on 64-bit floatPrimTyCon intPrimTyCon int32PrimTyCon int64PrimTyCon -- Only on 64-bit mutableArrayPrimTyCon -- Represented as a pointer to heap object mutableByteArrayPrimTyCon -- Represented as a pointer to heap object mutableArrayArrayPrimTyCon -- Represented as a pointer to heap object wordPrimTyCon word32PrimTyCon word64PrimTyCon -- Only on 64-bit These ones I need help with: bcoPrimTyCon weakPrimTyCon mVarPrimTyCon tVarPrimTyCon mutVarPrimTyCon realWorldTyCon stablePtrPrimTyCon stableNamePrimTyCon statePrimTyCon threadIdPrimTyCon anyTyCon eqPrimTyCon liftedTypeKindTyCon unliftedTypeKindTyCon openTypeKindTyCon constraintKindTyCon superKindTyCon anyKindTyCon I would appreciate any help classifying the bottom half. I will use this to implement -funbox-strict-primitive-fields * For example: while the StgArrWords heap object is a multi-byte object its representation as a field e.g. in data T = C ByteArray# is one pointer (to the StgArrWords heap object). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On 07/12/2012, at 4:21 , Ian Lynagh wrote: On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote: I suppose I'm the default owner of the register allocators and non-LLVM native code generators. Great, thanks! By the way, if you feel like doing some hacking this holiday season, then you might be interested in http://hackage.haskell.org/trac/ghc/ticket/7063 Ah, holidays. Finally I'll have time to get some work done... :-) Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Would the SxS loader (with associated manifests, etc) work? I've used it to support similar scenarios in a former job without any PE32 hacking. Unless things have changed recently, the APIs aren't super well documented but they are supported and there are a handful of tools for tracing the loader through various activation contexts. On Thu, Dec 6, 2012 at 5:34 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 6 December 2012 10:05, Max Bolingbroke batterseapo...@hotmail.com wrote: I've tested this by hand and it seems like it works: the absolute paths you hack into the import library are not messed with by the later link step. The resulting executables run flawlessly. Job done. To continue spamming the list, I'd just like to advertise my blog post explaining the proposed technique, with a worked example: http://blog.omega-prime.co.uk/?p=138 Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
validate fails: No rule to make target `fast'
I'm getting this build failure from a: make maintainer clean perl boot; ./configure CPUS=2 sh validate ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final validate_build_transformers cd libraries/transformers /Users/tibell/src/ghc/bindisttest/install dir/bin/ghc --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/transformers ./Setup configure --with-ghc=/Users/tibell/src/ghc/bindisttest/install dir/bin/ghc --with-haddock=/Users/tibell/src/ghc/bindisttest/install dir/bin/haddock --enable-library-vanilla --disable-shared --disable-library-prof --global --builddir=dist-bindist --prefix=/Users/tibell/src/ghc/bindisttest/install dir Configuring transformers-0.3.0.0... cd libraries/transformers ./Setup build --builddir=dist-bindist Building transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... [ 1 of 24] Compiling Data.Functor.Product ( Data/Functor/Product.hs, dist-bindist/build/Data/Functor/Product.o ) [ 2 of 24] Compiling Data.Functor.Compose ( Data/Functor/Compose.hs, dist-bindist/build/Data/Functor/Compose.o ) [ 3 of 24] Compiling Data.Functor.Identity ( Data/Functor/Identity.hs, dist-bindist/build/Data/Functor/Identity.o ) [ 4 of 24] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist-bindist/build/Control/Monad/Trans/Class.o ) [ 5 of 24] Compiling Control.Monad.IO.Class ( Control/Monad/IO/Class.hs, dist-bindist/build/Control/Monad/IO/Class.o ) [ 6 of 24] Compiling Control.Monad.Trans.Cont ( Control/Monad/Trans/Cont.hs, dist-bindist/build/Control/Monad/Trans/Cont.o ) [ 7 of 24] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist-bindist/build/Control/Monad/Trans/Error.o ) [ 8 of 24] Compiling Control.Monad.Trans.Identity ( Control/Monad/Trans/Identity.hs, dist-bindist/build/Control/Monad/Trans/Identity.o ) [ 9 of 24] Compiling Control.Monad.Trans.List ( Control/Monad/Trans/List.hs, dist-bindist/build/Control/Monad/Trans/List.o ) [10 of 24] Compiling Control.Monad.Trans.Maybe ( Control/Monad/Trans/Maybe.hs, dist-bindist/build/Control/Monad/Trans/Maybe.o ) [11 of 24] Compiling Control.Monad.Trans.Reader ( Control/Monad/Trans/Reader.hs, dist-bindist/build/Control/Monad/Trans/Reader.o ) [12 of 24] Compiling Control.Monad.Trans.RWS.Lazy ( Control/Monad/Trans/RWS/Lazy.hs, dist-bindist/build/Control/Monad/Trans/RWS/Lazy.o ) [13 of 24] Compiling Control.Monad.Trans.RWS ( Control/Monad/Trans/RWS.hs, dist-bindist/build/Control/Monad/Trans/RWS.o ) [14 of 24] Compiling Control.Monad.Trans.RWS.Strict ( Control/Monad/Trans/RWS/Strict.hs, dist-bindist/build/Control/Monad/Trans/RWS/Strict.o ) [15 of 24] Compiling Control.Monad.Trans.State.Lazy ( Control/Monad/Trans/State/Lazy.hs, dist-bindist/build/Control/Monad/Trans/State/Lazy.o ) [16 of 24] Compiling Control.Monad.Trans.State ( Control/Monad/Trans/State.hs, dist-bindist/build/Control/Monad/Trans/State.o ) [17 of 24] Compiling Control.Monad.Trans.State.Strict ( Control/Monad/Trans/State/Strict.hs, dist-bindist/build/Control/Monad/Trans/State/Strict.o ) [18 of 24] Compiling Control.Monad.Trans.Writer.Lazy ( Control/Monad/Trans/Writer/Lazy.hs, dist-bindist/build/Control/Monad/Trans/Writer/Lazy.o ) [19 of 24] Compiling Control.Monad.Trans.Writer ( Control/Monad/Trans/Writer.hs, dist-bindist/build/Control/Monad/Trans/Writer.o ) [20 of 24] Compiling Control.Monad.Trans.Writer.Strict ( Control/Monad/Trans/Writer/Strict.hs, dist-bindist/build/Control/Monad/Trans/Writer/Strict.o ) [21 of 24] Compiling Data.Functor.Constant ( Data/Functor/Constant.hs, dist-bindist/build/Data/Functor/Constant.o ) [22 of 24] Compiling Control.Applicative.Lift ( Control/Applicative/Lift.hs, dist-bindist/build/Control/Applicative/Lift.o ) [23 of 24] Compiling Control.Applicative.Backwards ( Control/Applicative/Backwards.hs, dist-bindist/build/Control/Applicative/Backwards.o ) [24 of 24] Compiling Data.Functor.Reverse ( Data/Functor/Reverse.hs, dist-bindist/build/Data/Functor/Reverse.o ) In-place registering transformers-0.3.0.0... cd libraries/transformers ./Setup haddock --builddir=dist-bindist Running Haddock for transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Haddock coverage: 100% ( 2 / 2) in 'Data.Functor.Product' 100% ( 2 / 2) in 'Data.Functor.Compose' 100% ( 2 / 2) in 'Data.Functor.Identity' 100% ( 8 / 8) in 'Control.Monad.Trans.Class' 100% ( 2 / 2) in 'Control.Monad.IO.Class' 100% ( 14 / 14) in 'Control.Monad.Trans.Cont' 100% ( 15 / 15) in 'Control.Monad.Trans.Error' 100% ( 7 / 7) in 'Control.Monad.Trans.Identity' 100% ( 7 / 7) in 'Control.Monad.Trans.List' 100% ( 9 / 9) in 'Control.Monad.Trans.Maybe' 100% ( 18 / 18) in 'Control.Monad.Trans.Reader' 100% ( 37 / 37) in 'Control.Monad.Trans.RWS.Lazy' 100% ( 2 / 2) in 'Control.Monad.Trans.RWS' 100% ( 37 / 37) in
