- Glasgow-haskell-users

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

SpecConstr number of specializations (-fspec-constr-count)
by José Pedro Magalhães 29 Nov '10

29 Nov '10

Hi all, When compiling some program with -O2 using ghc-7.0.1, I got warnings like > SpecConstr > Function `$j_s7Xo{v} [lid]' > has three call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > SpecConstr > Function `$j_s7YI{v} [lid]' has 7 call patterns, but the limit is 3 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > I proceeded to compile with -fspec-constr-count=10, but I still got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > With -fspec-constr-count=55, I got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 6 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > Finally, with -fspec-constr-count=56, the warnings disappear. Is this a bug, or is the value of spec-constr-count being manipulated in some way for certain passes? Thanks, Pedro

3 3

How to activate DEBUG in Data.HashTable?
by Wolfram Kahl 29 Nov '10

29 Nov '10

Hello, with a large Agda development, I have a reproducible segmentation fault that I have been able to localise to the serialisation (Agda.TypeChecking.Serialise.encode), which heavily relies on Data.HashTable. Now I find that Data.HashTable (from GHC-7.0.1) has a CPP-enabled DEBUG version --- is there a ``proper'' way to activate this? Possibly even so that it can be added ex-post to an existing installation? (So I don't have to re-install all packages.) mk/ways.mk says that the ``debug'' way only affects the RTS... Wolfram

2 1

Modifying functions in the typechecker?
by Nils Schweinsberg 29 Nov '10

29 Nov '10

Hi, I'm currently working on a GHC extension called "monad comprehensions" [1]. Typechecking for generators ("pat <- rhs") already works, but filters are a bit more tricky. Basicly, it works like that: A monad comprehension... [ body | E ] -- E :: Bool ...should desugar to: Control.Monad.guard E >> return body In the typechecker I typecheck E for type Bool, and see if we're in a MonadPlus by typechecking "guard". But I have to "pass" this guard-then-op function to the desugarer, so I created a new expression "then_op' = (>>) . guard" and pass this function to the ExprStmt constructor. The code in typecheck/TcMatches.lhs looks currently like this: tcMcStmt _ (ExprStmt rhs then_op _) res_ty thing_inside = do { -- Typecheck rhs on type Bool rhs' <- tcMonoExpr rhs boolTy -- Deal with rebindable syntax: -- then_op :: rhs_ty -> new_res_ty -> res_ty -- See notes in tcDoStmt. -- After this we redefine then_op to have the following type: -- then_op' :: Bool -> new_res_ty -> res_ty -- then_op' = (>>) . guard ; rhs_ty <- newFlexiTyVarTy liftedTypeKind ; new_res_ty <- newFlexiTyVarTy liftedTypeKind ; let then_ty = mkFunTys [rhs_ty, new_res_ty] res_ty guard_ty = mkFunTys [boolTy] rhs_ty comp_ty = mkFunTys [then_ty, guard_ty, boolTy, new_res_ty] res_ty ; then_op <- tcSyntaxOp MCompOrigin then_op then_ty ; guard_op <- tcSyntaxOp MCompOrigin (HsVar guardMName) guard_ty ; compose_op <- tcSyntaxOp MCompOrigin (HsVar composeName) comp_ty ; let then_op' = HsApp (nlHsApp (noLoc compose_op) (noLoc then_op)) (noLoc guard_op) ; thing <- thing_inside new_res_ty ; return (ExprStmt rhs' then_op' boolTy, thing) } Is this a valid approach? Should I move the "(>>) . guard" function somewhere else? I had a look at the renamer where "(>>)" is added to the statement "ExprStmt" the first time, but apparently you cannot call "tcSyntaxOp" in the typechecker on this function if you construct it with "HsApp (compose_op `HsApp` then_op) guard_op". Is there another function which could typecheck such a constructed expression without telling the user what functions we've used? I also had a look at the MDo typechecker, where they use this: ; let names = [mfixName, bindMName, thenMName, returnMName, failMName] ; insts <- mapM (\name -> newMethodFromName DoOrigin name m_ty) names ; return $ mkHsWrapCoI coi $ HsDo (MDoExpr (names `zip` insts)) stmts' body' res_ty' } So they can use these names with their typechecked versions in the desugarer. But if I do this for monad comprehensions and "guard", *every* monad comprehension will require a MonadPlus instance, which shouldn't be necessary if there are no filter expressions. Any advice on how this could be solved? Thanks, Nils [1]: http://hackage.haskell.org/trac/ghc/ticket/4370

2 1