December 2010 - Glasgow-haskell-users

Re: [darcs-users] How to develop on a (GHC) branch with darcs
by Ganesh Sittampalam 10 Dec '10

10 Dec '10

On Wed, 8 Dec 2010, Stephen J. Turnbull wrote: > Ganesh Sittampalam writes: > > > I think there are three things that can help with this problem: > > > > 1) a darcs rebase command. This will give you a nice way to manage the > > workflow already discussed, and you won't have to squish everything > > through into a mega-patch. You'll still have to periodically abandon one > > branch for another though (but I think that's also the case with git > > rebase). > > I'm not sure what you mean by "abandon". I mean the same as in the git world. The rebased patches have new identities, and if my ideas for tracking the relationship don't work out, they will have no relationship to the old patches. [your very clear explanation of that snipped] > > I also have some hope, though this is more speculative, of offering > > a clean way of tracking the relationship between the old branch and > > the new branch so that any stray patches against the old branch can > > be cleanly rebased to the new branch later on. > > As explained above, DAG-based VCSes like git can't do this cleanly > (that is one way of expressing the reason why rebase is severely > deprecated in some circles), and I don't think git will be able to do > so in the near future. OTOH, if Darcs gets rebase but can't handle > this, I'd have to count that as a net minus. Recombinant patching is > really what Darcs is all about IMO. darcs rebase is essentially about giving up on the recombinant patching because that's not working out for whatever reason. It's primarily intended as an alternative to manually reapplying patches to new branches using diff-and-patch, which is something significant numbers of people have ended up having to do. People generally want/need to do this to avoid conflicts, because: (a) darcs conflict handling can blow up, both because of exponential merges (primarily with v1 patches) and because of bugs (b) the UI for dealing with conflicts isn't really that pleasant and in particular once you've resolved a conflict it's a little painful to see the overall effect of the conflict resolution together with the underlying patch > In practice, git rebase needs to be kept private to a single user, and > is impractical even if private, if the user has propagated the branch > to other local repositories. Because git branching is so lightweight, > nobody really sees this as a big problem; throwaway branches are used > all the time as interim steps in many operations (eg, git stash). > Darcs branches, on the other hand, are much more heavyweight (modulo > the work you propose on colocated branches, but that's farther away > than rebase is). > > IMHO YMMV. But I strongly recommend you think carefully about this. > Analogies to git rebase are a trap here. It's implemented differently > and used to solve different problems from the way rebase is proposed > for use in Darcs. My understanding is that one of the main uses for git rebase is for "cleaning up history" prior to submission. In that regard I think there's a substantial overlap with what darcs rebase is intended for. Thanks for the detailed comments. Ganesh

1 0

How to use llvm with ghc7?
by Magicloud Magiclouds 09 Dec '10

09 Dec '10

Hi, I just got ghc7 and compiled with ghc6.12.1 and default configuration. ghc works fine. So I tried to use llvm. I got: ghc -fllvm badge.hs [1 of 1] Compiling Main ( badge.hs, /tmp/Main.o ) opt: Bitcode stream should be a multiple of 4 bytes in length I am using debian 32bit system, llvm 2.6. -- 竹密岂妨流水过山高哪阻野云飞

2 2

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 07 Dec '10

07 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 06 Dec '10

06 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