- Glasgow-haskell-users

ANNOUNCE: GHC version 6.12.3
by Ian Lynagh 15 Jun '10

15 Jun '10

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.2, so we recommend upgrading. Release notes are here: http://darcs.haskell.org/download/docs/6.12.3/html/users_guide/release-6-12… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://darcs.haskell.org/download/download_ghc_6_12_3.html 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

3 2

Segmentation fault in non-dynamically linked binaries?
by austin seipp 15 Jun '10

15 Jun '10

Hello, I am running GHC on x86_64 debian linux, and recently I have discovered that the executables generated by my GHC segfault when the linking step is not dynamic. I discovered this while attempting to install haskell-src-exts, which requires a linked version of Setup.hs when cabal builds it (and which would fail inexplicably until I did further investigation.) Example: link ~/t » cat hi.hs main :: IO () main = putStrLn "hi" link ~/t » ghc -dynamic hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 => (0x00007fffbadff000) libHShaskell98-1.0.1.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so (0x00007fab3a4c4000) libHSrandom-1.0.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so (0x00007fab3a2af000) libHStime-1.1.4-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so (0x00007fab39fad000) libHSprocess-1.0.1.3-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so (0x00007fab39d93000) libHSdirectory-1.0.1.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so (0x00007fab39b77000) libHSunix-2.4.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so (0x00007fab398c6000) librt.so.1 => /lib/librt.so.1 (0x00007fab396a2000) libutil.so.1 => /lib/libutil.so.1 (0x00007fab3949f000) libdl.so.2 => /lib/libdl.so.2 (0x00007fab3929b000) libHSold-time-1.0.0.5-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so (0x00007fab3903c000) libHSold-locale-1.0.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so (0x00007fab38e28000) libHSfilepath-1.1.0.4-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so (0x00007fab38c07000) libHSarray-0.3.0.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so (0x00007fab38992000) libHSbase-4.2.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so (0x00007fab381f2000) libHSinteger-gmp-0.2.0.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so (0x00007fab37fe1000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fab37da1000) libHSghc-prim-0.2.0.0-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so (0x00007fab37b1c000) libHSrts-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x00007fab378ba000) libm.so.6 => /lib/libm.so.6 (0x00007fab37637000) libHSffi-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x00007fab3742a000) libc.so.6 => /lib/libc.so.6 (0x00007fab370c9000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fab36eac000) /lib64/ld-linux-x86-64.so.2 (0x00007fab3a6cb000) link ~/t » ./a.out hi link ~/t » rm ./a.out *.hi *.o link ~/t » ghc hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 => (0x00007fffaafff000) librt.so.1 => /lib/librt.so.1 (0x00007fdf83d77000) libutil.so.1 => /lib/libutil.so.1 (0x00007fdf83b74000) libdl.so.2 => /lib/libdl.so.2 (0x00007fdf8396f000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fdf83730000) libm.so.6 => /lib/libm.so.6 (0x00007fdf834ae000) libc.so.6 => /lib/libc.so.6 (0x00007fdf8314c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fdf82f30000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf83f9c000) link ~/t » ./a.out [1] 7850 segmentation fault ./a.out link ~/t » gdb7.0 ./a.out 139 ↵ GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/a/t/a.out...done. (gdb) r Starting program: /home/a/t/a.out [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () (gdb) bt #0 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () #1 0x0000000000432dd7 in setFullProgArgv () #2 0x000000000043464d in hs_init () #3 0x000000000043478d in startupHaskell () #4 0x0000000000433d59 in real_main () #5 0x0000000000433e87 in hs_main () #6 0x00007ffff6fccc4d in __libc_start_main () from /lib/libc.so.6 #7 0x0000000000402d49 in _start () (gdb) What's interesting is that this occurs with all versions of GHC on my machine, which include: * GHC 6.12.1 * GHC 6.12.3 * GHC 6.13.20100426 Executables that were statically linked with GHC before this strange behavior started occurring appear to still work, i.e. xmonad & xmobar. I recently did an update of my machine with aptitude, but I would not think this would interfere with GHC. Does anybody have any ideas?

2 1

Re: How easy is it to build a GHC cross compiler targeting Windows?
by Simon Marlow 15 Jun '10

15 Jun '10

[ glasgow-haskell-users CC'd, as requested ] Hi Hamish, Sorry for the delay in replying, things have been busy over the last few days with paper deadlines and suchlike. On 05/06/2010 15:14, Hamish Mackenzie wrote: > We want to try to add Haskell to TakeoffGW (a new Windows > distribution like cygwin, but using MinGW). TakeoffGW is built using > SUSE's mingw32 cross compiling system, so I figured the first step > would be to add GHC to that if possible. > > I figure we will need to two new GHC packages * mingw32-cross-ghc > (GHC cross compiler for building Haskell packages) * mingw32-ghc > (Windows GHC compiler to install on users machines) > > I am a bit concerned that making a cross compiler to build the > Haskell packages might not be practical. So before we spend to much > time on this I thought I should ask how hard it is to build a cross > compiler like this? Is it just a matter of setting the correct > configure flags? We will have the SUSE's mingw32 available > (including binutils and gcc cross compiler), but will this be > enough? First of all, I think TakeoffGW is a great idea, I've been hoping that something like this would emerge. In principle cross-compiling GHC ought to be possible, but actually making it work could be difficult. It's hard to predict without trying. Much of our build system is structured to make cross-compiling work: we have separate build/host/target platforms and generally try to check the correct one, but we almost never actually cross-compile GHC, only when porting GHC to a new platform and there it's a fairly involved manual process. If I had to guess, I'd say you'll probably run into quite a few things that need fixing in the build system to make this work. Probably nothing fatal, but lots of fiddling around. It would be worth doing, and we'll help as much as we can along the way if you want to try. > If we can build the cross compiler will we be able to use it to build > the Windows ghc with it? > > If there are parts that can't be done we may need to resort to using > Wine or a Windows machine. > > I wanted to CC the GHC developers mailing list, but haskell.org is > down. Could you please CC the appropriate list in your reply? Done! Cheers, Simon

1 0

hsc2hs on Mac OS 10.6 unreliable?
by Axel Simon 09 Jun '10

09 Jun '10

Hi all, we're facing serious problems (the seg'faulting kind) with Gtk2Hs on Mac OS 10.6. Chris has tracked this down to incorrect structure offsets that hsc2hs calculates. The offsets that hsc2hs calculates are too large, so it is probably in x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so it must have been compiled with something like -arch i386. My question is the following: What is the right way to compile unixy software on Mac OS 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not producing its C file in the correct way? It seems that a C Gtk+ program works correctly when compiled with no special flags. The only thing we could do is to pass some magic option to hsc2hs when it creates the C program that calculates the offsets. Detecting how Gtk + was compiled would require some sort of autoconf magic which is beyond a simple cabal file. So I probably cannot hope for an easy fix. Any comments or experience appreciated, cheers, Axel

4 5

Re: ANNOUNCE: MonadCatchIO-foreign
by Antoine Latter 09 Jun '10

09 Jun '10

Hi GHC, Is there a reason that Foreign.Marshall.Array.allocaArray calls into allocaBytes instead of allocaBytesAligned? Since alloca needs the alignment, wouldn't allocaArray also need it? I'm not too up on how memory access is supposed to work, it was just something that jump out at me. Thanks, Antoine On Sun, May 30, 2010 at 7:10 PM, Antoine Latter <aslatter(a)gmail.com> wrote: > Hello Haskell, > > I'd like to announce a very small library in two flavors. > > The problem I'm trying to solve is that we have some capabilities for > writing functions which are polymorphic over monad but still use IO > capabilities - liftIO :: (IO a -> m a) from the packages transformers > and mtl. The packages[1,2] MonadCatchIO offer similar polymorphism for > the exception capabilities of the IO monad. > > The package MonadCatchIO-foreign offers similar polymorphism for the > following functions: > > alloca, allocaBytes, allocaArray, allocaArray0 and withForeignPtr. > > It's a small thing, but I don't see why it should be written twice. > > Links on hackage: > > http://hackage.haskell.org/package/MonadCatchIO-mtl-foreign > http://hackage.haskell.org/package/MonadCatchIO-transformers-foreign > > GitHub link: > > http://github.com/aslatter/MonadCatchIO-foreign > > Feedback, praise and adulation welcome. > > Antoine >

3 3

Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
by Ian Lynagh 31 May '10

31 May '10

On Mon, May 31, 2010 at 12:38:56PM +0100, Barney Stratford wrote: > > Any ideas? Have you tried running the testsuite, to see if you can find a small failing program? I'd try the ffi tests first, e.g.: cd testsuite/tests/ghc-regress/ffi make CLEANUP=1 SKIPWAY=ghci Thanks Ian

1 0

Memory use blowup with -O1 (versus -O0) in GHC 6.12.1/6.12.2
by Robert Greayer 25 May '10

25 May '10

Hi, I've encountered an interesting issue with GHC 6.12.1 and 2 in which a small program compiles quickly without using loads of memory with optimization turned off, but with optimization (-O1) turned on, GHC's memory usage becomes very high (and compilation takes much much longer). $ time ghc -c -O0 Tst.hs real 0m0.107s user 0m0.073s sys 0m0.035s $ time ghc -c -O1 Tst.hs real 0m38.605s user 0m36.669s sys 0m1.923s Memory used by GHC looks like it tops out at 3G (in the -O1 case). Constraining the heap size to 1G causes compilation to fail: $ ghc +RTS -M1g -RTS -c -O1 Tst.hs Heap exhausted; Current maximum heap size is 1073741824 bytes (1024 MB); use `+RTS -M<size>' to increase it. (whereas, without optimization, a heap of 16m is sufficient) The module being compiled is (probably deceptively) simple: module Tst where import Merge data Rec1 = Rec1 !Int mkRec1 v = mk $ merge v () where mk (Tagged i :* ()) = Rec1 i but the devil is in the details of 'merge' (attached) which merges heterogeneous lists of values, using a lot of type level programming with type families. Does this sound like an known, open issue? I was unable to find anything in GHC Trac that looked similar. Thanks, Rob

3 2

RE: [Haskell-cafe] Re: Data instance for a GADT
by Simon Peyton-Jones 25 May '10

25 May '10

There have been a couple of emails about Template Haskell support for · GADTs · View patterns · Reifying instances There’s a ticket for this already http://hackage.haskell.org/trac/ghc/ticket/3497 It’s mainly a library design question, in this case the design of the Template Haskell data types in Language.Haskell.TH.Syntax. It needs some motivated person to propose a design, get a consensus, and write some boilerplate code. Just use the standard libraries process An issue is the extent to which it’s ok to change the Template Haskell data types (and thereby break people’s code), but that’s something the interested parties can work out together. If you evolve a consensus design I’m more than happy to make it part of GHC. I just don’t want to drive the consensus building! Simon From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ozgur Akgun Sent: 14 April 2010 10:53 To: Haskell cafe Subject: [Haskell-cafe] Re: Data instance for a GADT Seeing this old thread[1], I hope something happened towards enabling this. Does anybody know the current status about using TH on GADTs? [1] http://www.haskell.org/pipermail/template-haskell/2006-August/000567.html On 14 April 2010 10:32, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: answering to myself: I guess this is related: http://hackage.haskell.org/trac/ghc/ticket/3497 On 14 April 2010 10:13, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: Cafe, How can I provide a Data instance for a GADT? I am trying to TH on it, and Uniplate requires Data. I tried StandaloneDeriving, but it seems not to work.

1 0

6.12.3-candidate
by Serge D. Mechveliani 24 May '10

24 May '10

Dear GHC developers, I have tested ghc-6.12.3-candidate of 6.12.2.20100521 on Debian Linux, i386-family on making it by ghc-6.12.2, on making it by itself on the DoCon test, on the Dumatel test -- with skipping profiling. It looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: Dynamic libraries and GHCi
by John Lato 20 May '10

20 May '10

> From: Simon Marlow <marlowsd(a)gmail.com> >> > >> But currently there is one problem with "GhcShared=YES": with this >> option, the stage-2 compiler gets linked dynamically but the >> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, >> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around >> this by manually symlinking all the dynamic libraries to ./inplace/lib >> and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should >> be a solution better than this. > > On Linux we link the binary using -rpath (I know OS X doesn't have > -rpath). This is another issue we need to resolve before we can switch > to a dynamically-linked GHCi. > > Basically there's a fair bit to do to make a dynamic GHCi a reality, and > before we can do anything there are some tricky decisions to make. > When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1. John

3 5