- Glasgow-haskell-users

New flag in GHC 7.0.1: --with-rtsopts
by Simon Marlow 09 Dec '10

09 Dec '10

It seems we forgot to mention in the 7.0.1 release notes that there's a new compile-time flag, --with-rtsopts. From the documentation: 4.16.8. Linker flags to change RTS behaviour GHC lets you exercise rudimentary control over the RTS settings for any given program, by using the -with-rtsopts linker flag. For example, to set -H128m -K1m, link with -with-rtsopts="-H128m -K1m". Cheers, Simon

1 0

How to develop on a (GHC) branch with darcs
by Iavor Diatchki 08 Dec '10

08 Dec '10

Hello, I am doing some work on a GHC branch and I am having a lot of troubles (and spending a lot of time) trying to keep my branch up to date with HEAD, so I would be very grateful for any suggestions by fellow developers of how I might improve the process. Here is what I have tried so far: First Attempt ~~~~~~~~~~~~~ My branch, called 'ghc-tn', was an ordinary darcs repo. I recorded my changes as needed, and every now and then would pull from the HEAD repo. If conflicts occurred, I would resolve them and record a patch. Very quickly I run into what, apparently, is a well-known darcs problem where trying to pull from HEAD would not terminate in a reasonable amount of time. Second Attempt ~~~~~~~~~~~~~~ Avoid "conflict patches" by constantly changing my patches. This is how I've been doing this: Initial state: ghc: a repository with an up-to-date version of GHC head ghc-tn: my feature repo based on a slightly out-of-date GHC HEAD. Goal: Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch) Process: 1. Create a temporary repository for the merge: darcs clone --lazy ghc ghc-tn-merge 2. Create a backup of the feature branch (strictly speaking not necessary but past experience shows that it is a good idea to have one of those). darcs clone --lazy ghc-tn ghc-tn-backup 3. Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time. darcs pull ghc-tn y d 3.1. If a feature patch causes a conflict, then resolve the conflict and create a new patch, obliterating the old one: darcs amend-record (creates a new patch, not a conflict patch, I think) After repeating this for all branch patches, I have an updated branch in 'ghc-tn-merge' with two caveats: 1. The new repository does not contain my previous build so I have to re-build the entire GHC and libraries from scratch. This is a problem because GHC is a large project and rebuilding everything takes a while, even on a pretty fast machine. I work around this problem like this: 1.1 Obliterate all branch patches from 'ghc-tn'. This, essentially, rewinds the repository to the last point when I synchronised with HEAD. To do this properly I need to know which patches belong to my branch, and which ones are from GHC. (I've been a bit sloppy about this--- I just use the e-mails of the branch developers to identify these and then look at the patches. A better way would be to have some kind of naming convention which marks all branch patches). 1.2 Pull from 'ghc-tn-merge' into 'ghc-tn'. By construction we know that this will succeed and reintroduce the feature changes, together with any new updates to GHC into 'ghc-tn'. Now 'ghc-tn-merge' and 'ghc-tn-backup' can be deleted. 2. The new repository contains rewritten versions of the branch patches so---if I understand correctly---it is not compatible with the old one (i.e., I cannot just push from my newly updated branch to the public repo for my branch as there will be confusion between the old feature patches and the new ones). I can think of only one solution to this problem, and it is not great: 2.1 Delete the original public repo, and publish the new updated repo, preferably with a new name. In this way, other developers who have the old patches can either just clone the new repo, or go through steps 1.1--1.2 but will not accidentally get in a confused state by mixing up the new feature patches with the old ones. For background, my solution is essentially a manual implementation of what is done by git's "rebase" command---except that there "branch patches" and various "repository states" are automatically managed by the system so there is no need to follow various naming conventions which tend to be error prone. Apologies for the longish e-mail but this seems like an important problem and I am hoping that there's a better way to do things. -Iavor

9 8

Parallel, Incremental Linking
by John Smith 07 Dec '10

07 Dec '10

The bottleneck for building on my multi-core machine is ld, which spends a considerable time consuming 100% of one core after ghc has finished generating object files. Moreover, GHC is largely IO bound, while ld is CPU bound; incremental linking would enable the two tasks to be performed in parallel (or am I being naive?) Gold in an incremental and multi-threaded linker, but can only output ELF (not Windows). Is there a cross-platform solution suitable for GHC?

4 3

ANNOUNCE: GHC version 7.0.1
by Ian Lynagh 07 Dec '10

07 Dec '10

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC. Since the 6.12 branch we are delighted that more than 60 people have contributed patches to GHC or the accompanying libraries and utilities. There have been a number of significant changes since the last major release, including: * GHC now defaults to the Haskell 2010 language standard * -fglasgow-exts is now deprecated, in favour of the individual extension flags * On POSIX platforms, there is a new I/O manager based on epoll/kqueue/poll, which allows multithreaded I/O code to scale to a much larger number (100k+) of threads * GHC now includes an LLVM code generator which, for certain code, can bring some nice performance improvements * The type checker has been overhauled, which means it is now able to correctly handle interactions between the type systemextensions * The inliner has been overhauled, which should in general give better performance while reducing unnecessary code-size explosion * Large parts of the runtime system have been overhauled, including fixing several instances of pathological performance when there are large numbers of threads * Due to changes in the runtime system, if you are using Control.Parallel.Strategies from the parallel package, please upgrade to at least version 2 (preferably version 3) * The full Haskell import syntax can now been used to bring modules into scope in GHCi * GHC now comes with a more recent mingw bundled on Windows, which includes a fix for windres on Windows 7 * There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread; in particular, this works around an issue running GLUT from GHCi on OS X The full release notes are here: http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.ht… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

6 13

Re: [Haskell-cafe] Trying out GHC 7
by Antoine Latter 06 Dec '10

06 Dec '10

Inlcuding the ghc-users list. On Mon, Dec 6, 2010 at 10:10 AM, Andrew Coppin <andrewcoppin(a)btinternet.com> wrote: > OK, so the other day I decided to take GHC 7.0.1 for a spin. > > Suffice it to say, it definitely compiles stuff. So far, I've only tried > running it in a Windows XP virtual machine with a single core, so I haven't > been able to test what multicore performance is like. > > One thing that did interest me is the conflicting information about whether > or not dynamic linking is supported on Windows. Half the User Guide claims > that this /is/ supported, and the other half still contains statements that > it is /not/ supported. So I thought I'd just go physically try it and see if > it works. > > Well... it compiles stuff. Hello World goes from being 518KB to being a > piffling 13KB. Which is nice. > > I almost didn't bother actually trying to /run/ the resulting binary... But > when I did, I discovered that it immediately crashes, whining that it can't > find the DLL it wants. So, out of the box, the Windows setup is broken. > (Obviously the Windows section of the User Guide makes no mention of how > DLLs are located; it only explains the situation for Linux and Mac OS. I > especially liked the bit where it says that there are "three modes", and > then proceeds to list only two...) > > In the interests of science, I wanted to see if I could make it run by just > putting the necessary DLLs into the same folder as the binary. But first I > had to /find/ them. I had expected to find a folder somewhere with all the > DLLs in it... but no, the installer appears to have sprinkled them around > the filesystem more or less at random. Some of them are in folders named for > the package, some of them just sit in the root folder. > > After about 20 minutes of searching, I found the RTS DLL. Running the > program, it now instantly crashes because of a /different/ DLL. This one > didn't take quite so long to find (now that I know roughly where to look). I > fixed that, and now the binary crashes with yet another missing DLL. And so > on and so forth. In the end, Hello World required 5 DLLs. Better still, > together these totalled 8MB of data. (!) So the distribution package is now > about 16x bigger than with static linking. Oh joy. > > Clearly if you just want to distribute one executable binary, you're going > to use static linking. (E.g., darcs.exe will hopefully remain statically > linked.) But I suppose if I had a whole heap of Haskell programs then the > extra complexity of delivering half a dozen DLLs might may off in terms of > space reductions. And of course, on /my/ development box, I don't need a > zillion redundant copies of the RTS code, etc. (Or at least, I won't if I > can figure out how to make the programs able to actually /find/ the > necessary DLLs...) > > Actually, of all the DLLs, only "base" is actually large - it's > approximately 6MB on its own. GHC-Prim is 0.5MB, and the others are all > relatively tiny. It feels slightly irritating that I need to inclide the FFI > DLL when I'm not doing and FFI - but of course, the entire Haskell I/O > subsystem /is/ doing FFI. Similarly, I'm not using arbitrary-precision > integers, but various I/O operations return file sizes as Integer, so GMP > must also be included. Neither of these things are actually especially > large. > > It's rather confusing that the User Guide is out of date in so many places. > (And not just regarding dynamic linking on Windows. For example, one section > claims that "+RTS -f" will tell you what options are supported, but that > actually yields "unknown RTS opion: -f". It seems that "-?" is the correct > option name.) If I can get a suitable Linux VM going, I might have a go at > contributing some updates. > > Just for completeness, I tried asking for dynamic linking with an older > version of GHC (6.10, IIRC) - one that supports it on Linux but not Windows. > I was expecting to get either "dynamic linking is not supported on this > platform", or at worst "unknown option -dynamic". In fact, what I got was > "gcc: cannot find file Main.dyn_hi". Oh, that's graceful failure then. >_< > > I did also briefly see if the LLVM backend would work under Windows. I > wasn't entirely sure if LLVM comes with the installer binary or you need to > get it seperately. (You might say "obviously it's seperate", but the > installer already contains the entire GCC system, for example.) Attempting > to use this resulted in a summary error message ("cannot run: opt") which > doesn't make it especially clear that the problem is that LLVM isn't > installed. Perhaps there's no better way of detecting this condition, I > don't know, but something more illuminating would be nice. > > I briefly had a look at how to install LLVM, but it appears that you have to > build it from source. This is not my idea of a fun time, so given the > minimal speed difference, I just won't bother. > > I haven't had time to play with any of the other new good stuff in GHC 7. > (The multicore performance, the new GC stuff, etc.) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Problems with openFd and -threaded
by wren ng thornton 03 Dec '10

03 Dec '10

So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. In the previous thread Simon confirmed that it's a bug and said he'd fix it, but I didn't see any ticket mentioned. Does anyone know if there's a ticket for it, or when it will be/has been fixed? [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018147… -- Live well, ~wren

4 6

doesDirectoryExist always returns False on Mac OS X
by Yitzchak Gale 01 Dec '10

01 Dec '10

Just after upgrading some basic packages from Hackage, doesDirectoryExist began always returning False. I suspect that this is related to the unix package, and/or its strange interaction with the directory package. See: http://hackage.haskell.org/trac/ghc/ticket/4812 Thanks, Yitz

1 0

ANN: HaLVM 1.0: the Haskell Lightweight Virtual Machine
by Adam Wick 30 Nov '10

30 Nov '10

Galois, Inc. is pleased to announce the immediate release of the Haskell Lightweight Virtual Machine (or HaLVM), version 1.0. The HaLVM is a port of the GHC runtime system to the Xen hypervisor, allowing programmers to create Haskell programs that run directly on Xen's "bare metal." Internally, Galois has used this system in several projects with much success, and we hope y'all will have an equally great time with it. What might you do with a HaLVM? Pretty much anything you want. :) Explore designs for operating system decomposition, examine new notions of mobile computation with the HaLVM and Xen migration, or find interesting network services and lock them inside small, cheap, single-purpose VMs. The HaLVM is the result of many years of effort, by many people inside Galois. Although it is not yet totally bug-free, we have decided that broad adoption wins over perfection and thus we are releasing it for general review. As such, there will be some rough edges, and we urge you to read the documentation to understand the platforms we test on. We are releasing the HaLVM under a non-restrictive BSD3 license. You can find it here: http://halvm.org We welcome user feedback, feature requests, bug notices, patches, and feature additions; see the page above for guidelines on getting involved. Finally, we'd like to give many things to the GHC and Xen communities, without which this work would not be possible. If you have any questions or concerns, please don't hesitate to contact the HaLVM's maintainers at halvm-devel(a)community.galois.com. Have a lovely day! - Adam

2 1

Documentation of System.Process
by Jean-Marie Gaillourdet 30 Nov '10

30 Nov '10

Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? 2. Could you add that information to the haddock docs? Is their some other place where I could have found this? Thanks for your great work! Regards, Jean

2 2

Re: packaging options for Mac OS X
by Ian Lynagh 29 Nov '10

29 Nov '10

On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote: > > Outstanding question is what should this framework be called? I would like to continue to call it GHC.framework, but change the version to something like 7.0.1+HP-i386, I think it ought to be called Haskell-Platform.framework. > [*] The binary GHC distribution could be > - built by the GHC team, and asking them for a tarball (as Duncan suggested) I do "make framework-pkg" to build the OS X installer, but it's essentially a black box to me. We're happy to accept patches that make this also produce a bindist, though. Now that we have the Haskell Platform, perhaps we should stop making GHC OS X installers, and only make plain old unix bindists. Thanks Ian

2 2