- Glasgow-haskell-users

What does interruptibility mean exactly?
by Bas van Dijk 16 Jun '10

16 Jun '10

Hello, I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked? newEmptyMVar >>= \mv -> block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: "Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..." Do I need to interpret this as: 1) 'putMVar' is always interruptible because it's an operation that has the ability to block. For example when applied to a full MVar. or: 2) 'putMVar' is only interruptible when it actually blocks and not interruptible when it is sure that it will not block. For example when applied to an empty MVar like in the given program. The reason I'm asking is that in my threads library[2] I previously applied 'putMVar' to an empty MVar to signal the termination of a thread. However due to some comments in the topic about "Asynchronous Exception Wormholes" I got a bit scared that 'putMVar' might throw exceptions even in the scope of a block. Because this could cause dead-locks in my threads library, I rewrote it using TMVars which don't have interruptible operations. However, I'm still not sure about the exact semantics so I would like to clear this up. Regards, Bas [1] http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exce… [2] darcs get http://code.haskell.org/~basvandijk/code/threads/

4 5

laziness in `length'
by Serge D. Mechveliani 15 Jun '10

15 Jun '10

Dear people and GHC team, I have a naive question about the compiler and library of ghc-6.12.3. Consider the program import List (genericLength) main = putStr $ shows (genericLength [1 .. n]) "\n" where n = -- 10^6, 10^7, 10^8 ... (1) When it is compiled under -O, it runs in a small constant space in n and in a time approximately proportional to n. (2) When it is compiled without -O, it takes at the run-time the stack proportional to n, and it takes enormousely large time for n >= 10^7. (3) In the interpreter mode ghci, `genericLength [1 .. n]' takes as much resource as (2). Are the points (2) and (3) natural for an Haskell implementation? Independently on whether lng is inlined or not, its lazy evaluation is, probably, like this: lng [1 .. n] = lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) = 1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = 2 + (lng (3: (list 4 n))) -- because this "+" is of Integer = 2 + 1 + (lng $ list 4 n) = 3 + (lng $ list 4 n) ... And this takes a small constant space. Thank you in advance for your explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 5

Unexpected NoImplicitPrelude behaviour in GHCi (bug?)
by Philip K.F. Hölzenspies 15 Jun '10

15 Jun '10

Dear GHCers, I have been experimenting some more with environments for lab work for an FP intro course. One thing students tend to have difficulty with in the initial labs are the error messages including type classes, or any kind of more general type than they expected. I am trying to work around this, by supplying a "Number" type for the first lab and gradually increasing the complexity over the next few labs. To let all error messages be in terms of my type, I use the NoImplicitPrelude option in a LANGUAGE pragma. However, I find the behaviour of GHCi unexpected. I have reduced the problem to a small case that reproduces the bug. Here is my BugDemo module: {-# LANGUAGE NoImplicitPrelude #-} module BugDemo where import qualified Prelude as P newtype Number = N P.Integer fromInteger = N Look at the following sessions: [holzensp@ewi1043:work/FPPrac]% ghci BugDemo.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling BugDemo ( BugDemo.hs, interpreted ) Ok, modules loaded: BugDemo. *BugDemo> 5 5 *BugDemo> :t 5 5 :: (P.Num t) => t *BugDemo> :q Leaving GHCi. [holzensp@ewi1043:work/FPPrac]% ghci -fno-implicit-prelude BugDemo.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling BugDemo ( BugDemo.hs, interpreted ) on the commandline: Warning: -fno-implicit-prelude is deprecated: use -XNoImplicitPrelude or pragma {-# LANGUAGE NoImplicitPrelude #-} instead Ok, modules loaded: BugDemo. *BugDemo> 5 <interactive>:1:0: Not in scope: `>>' *BugDemo> :t 5 5 :: Number *BugDemo> It's a bit awkward that I get an explicit warning about -fno-implicit-prelude being deprecated, while the behaviour is actually different. Obviously, when leaving out the definition for fromInteger, the second session fails whenever I type a number, whereas the first session behaves the same way. This seems to be me to be a bug. Kind regards, Philip

5 6

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