- Glasgow-haskell-users

A type not inferred with RankNTypes
by Akio Takano 13 May '13

13 May '13

Hi, The attached program does not typecheck if I don't include a type signature for 'bar' (the line C). I can't figure out if this is a limitation in the type system or a bug in GHC. One thing that confuses me is that replacing the line (B) with (A) makes the program typecheck. Could anyone help me figuring out what is going on? I'm using GHC 7.6.2. The error was: % ghc forall.hs [1 of 1] Compiling Foo ( forall.hs, forall.o ) forall.hs:18:11: Could not deduce (Fractional a) arising from the literal `0.1' from the context (Num (Scalar t), Scalar t ~ a) bound by a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t at forall.hs:18:7-13 Possible fix: add (Fractional a) to the context of a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t or the inferred type of bar :: a In the first argument of `foo', namely `0.1' In the expression: foo 0.1 In an equation for `bar': bar = foo 0.1 Regards, Takano Akio

3 2

Missing snapshots
by Mateusz Kowalczyk 13 May '13

13 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, On the GHC download page [1], there are no available snapshots. Both HEAD and STABLE branch dist directories are empty. Any idea what the deal is? [1] - http://www.haskell.org/ghc/download - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5 eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA 973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/ q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+ +OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyMworGJU89aWkaKG+Bjlf2xWOS mqVoJArrZCv7tkYoLdN2 =rENI -----END PGP SIGNATURE-----

4 3

Why do remaining HECs busy-wait during unsafe-FFI calls?
by Herbert Valerio Riedel 06 May '13

06 May '13

Hello, Recently, I stumbled over E.Z.Yang's "Safety first: FFI and threading"[1] post and then while experimenting with unsafe-imported FFI functions I've noticed a somewhat surprising behaviour: Consider the following contrived program: --8<---------------cut here---------------start------------->8--- import Foreign.C import Control.Concurrent import Control.Monad import Data.Time.Clock.POSIX (getPOSIXTime) foreign import ccall unsafe "unistd.h sleep" c_sleep_unsafe :: CUInt -> IO CUInt main :: IO () main = do putStrLnTime "main started" _ <- forkIO (sleepLoop 10 >> putStrLnTime "sleepLoop finished") yield putStrLnTime "after forkIO" threadDelay (11*1000*1000) -- 11 seconds putStrLnTime "end of main" where putStrLnTime s = do t <- getPOSIXTime putStrLn $ init (show t) ++ "\t" ++ s sleepLoop n = do n' <- c_sleep_unsafe n unless (n' == 0) $ do putStrLnTime "c_sleep_unsafe got interrupted" sleepLoop n' --8<---------------cut here---------------end--------------->8--- When compiled with GHC-7.6.3/linux/amd64 with "-O2 -threaded" and executed with "+RTS -N4", the following output is emitted: 1367838802.137419 main started 1367838812.137727 after forkIO 1367838812.137783 sleepLoop finished 1367838823.148733 end of main which shows that the forkIO of the unsafe ccall effectively blocks the main thread; Moreover, when looking at the process table, I saw that 3 threads were occupying 100% CPU time each for 10 seconds until the 'after forkIO' was emitted. So what is happening here exactly, why do the 3 remaining HECs busy-wait during that FFI call instead of continuing the execution of the main thread? Do *all* foreign unsafe ccalls (even short ones) cause N-1 HECs to spend time in some kind of busy looping? [1]: http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/ Cheers, hvr

2 2

Simplifying Core pretty-printing via GHC API?
by Conal Elliott 02 May '13

02 May '13

I'm using the GHC API to compile Haskell source code to Core. I'd like to pretty-print the result with the sort of simplifications I get with -dsuppress-type-applications, -dsuppress-uniques, etc (used in combination with -ddump-simpl on ghc's command line). How can I set these options via the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)? Thanks. - Conal

2 2

ANNOUNCE: GHC version 7.6.3
by Ian Lynagh 25 Apr '13

25 Apr '13

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.6.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3. This is a bugfix release relative to 7.6.2, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html 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. 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

Re: porting to uClibc-based 686 Linux
by Dubiousjim 21 Apr '13

21 Apr '13

On Wed, Apr 17, 2013 at 11:18:52PM +0100, Ian Lynagh wrote: > On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote: > > target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs > > [1 of 1] Compiling Main ( hello.hs, hello.o ) > > Linking hello-cross ... > > target$ ./hello-cross > > Can't modify application's text section; use the GCC option -fPIE > > for position-independent executables. > > You can pass -fPIE to gcc by using the -optc-fPIE flag. > > Thanks > Ian Thanks Ian. There's much I don't fully understand about ghc, but I read somewhere that the -optc-* options would only be applied when building via intermediate C files, which isn't happening in the compilation process specified above. Is this incorrect, or have I misunderstood something? In any event, adding -optc-fPIE doesn't remove the error message. That error message is kicked up by uclibc, on account of the hello-cross binary having a TEXTREL section, which I understand it shouldn't have if we're generating PIE or PIC code. The instruction to "use the GCC option -fPIE" is just uclibc's suggestion as to how to avoid this. I also tried adding -fPIE or -fPIC to the "C compiler flags" section in inplace/lib/settings, but this didn't resolve the issue. I also tried using "BuildFlavour = unreg" in mk/build.mk, but this didn't resolve the issue. What I thought to try next is to add llvm/clang to my cross-compiler toolchain, and try building with the -fllvm flag in SRC_HC_OPTS. Other suggestions will be much welcomed. Thanks. -- dubiousjim(a)gmail.com

2 1

Re: Why is GHC so much worse than JHC when computing the Ackermann function?
by Edward Z. Yang 20 Apr '13

20 Apr '13

I don't seem to get the leak on latest GHC head. Running the program in GC debug mode in 7.6.2 is quite telling; the program is allocating *a lot* of megablocks. We probably fixed it though? Edward Excerpts from Mikhail Glushenkov's message of Sat Apr 20 01:55:10 -0700 2013: > Hi all, > > This came up on StackOverflow [1]. When compiled with GHC (7.4.2 & > 7.6.2), this simple program: > > main = print $ ack 4 1 > where ack :: Int -> Int -> Int > ack 0 n = n+1 > ack m 0 = ack (m-1) 1 > ack m n = ack (m-1) (ack m (n-1)) > > consumes all available memory on my machine and slows down to a crawl. > However, when compiled with JHC it runs in constant space and is about > as fast as the straightforward Ocaml version (see the SO question for > benchmark numbers). > > I was able to fix the space leak by using CPS-conversion, but the > CPS-converted version is still about 10 times slower than the naive > version compiled with JHC. > > I looked both at the Core and Cmm, but couldn't find anything > obviously wrong with the generated code - 'ack' is compiled to a > simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is > that running the program with +RTS -hc makes the space leak > mysteriously vanish. > > Can someone please explain where the space leak comes from and if it's > possible to further improve the runtime of this program with GHC? > Apparently it's somehow connected to the stack management strategy, > since running the program with a larger stack chunk size (+RTS -kc1M) > makes the space leak go away. Interestingly, choosing smaller stack > chunk sizes (256K, 512K) causes it to die with an OOM exception: > > $ time ./Test +RTS -kc256K > Test: out of memory (requested 2097152 bytes) > > > [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with… >

3 2

Why is GHC so much worse than JHC when computing the Ackermann function?
by Mikhail Glushenkov 20 Apr '13

20 Apr '13

Hi all, This came up on StackOverflow [1]. When compiled with GHC (7.4.2 & 7.6.2), this simple program: main = print $ ack 4 1 where ack :: Int -> Int -> Int ack 0 n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) (ack m (n-1)) consumes all available memory on my machine and slows down to a crawl. However, when compiled with JHC it runs in constant space and is about as fast as the straightforward Ocaml version (see the SO question for benchmark numbers). I was able to fix the space leak by using CPS-conversion, but the CPS-converted version is still about 10 times slower than the naive version compiled with JHC. I looked both at the Core and Cmm, but couldn't find anything obviously wrong with the generated code - 'ack' is compiled to a simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is that running the program with +RTS -hc makes the space leak mysteriously vanish. Can someone please explain where the space leak comes from and if it's possible to further improve the runtime of this program with GHC? Apparently it's somehow connected to the stack management strategy, since running the program with a larger stack chunk size (+RTS -kc1M) makes the space leak go away. Interestingly, choosing smaller stack chunk sizes (256K, 512K) causes it to die with an OOM exception: $ time ./Test +RTS -kc256K Test: out of memory (requested 2097152 bytes) [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with… -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 5

GHC 7.8 release redux
by Ben Gamari 18 Apr '13

18 Apr '13

Recently I tried to parse the flurry of activity in the "GHC 7.8 release?" thread which started in early February[1]. This was quite a long thread with a number of different facets. To avoid losing points in the noise, I thought it might be useful to summarize the major points (please comment if I've missed something major), * More steeping time was necessary for a stable 7.8 release * Core APIs change too quickly, we need to try harder to decouple API-breaking releases from releases with core compiler functionality * The solution for this might be the three channel approach proposed by Mark[2] * Splitting base further might help the reduce unnecessary breakages[3]. Work has continued in this direction since the thread concluded[4]. * Tracking performance regression with periodic runs of nofib would be useful[5] Quite a productive thread for a week of wallclock time. That being said, if I'm not mistaken one matter is notably absent: what is the plan for 7.8? Will it admit API breakage? Should we establish a timeframe for getting work in before a formal release candidate is cut? Of course, "let's just wait and see" is a perfectly reasonable response but it would be nice to see it clearly set down in writing to avoid future confusion. Cheers, - Ben [1] http://www.haskell.org/pipermail/ghc-devs/2013-February/000309.html [2] http://www.haskell.org/pipermail/ghc-devs/2013-February/000386.html [3] http://www.haskell.org/pipermail/ghc-devs/2013-February/000451.html [4] http://hackage.haskell.org/trac/ghc/wiki/SplitBase [5] http://www.haskell.org/pipermail/ghc-devs/2013-February/000332.html

2 1

Re: porting to uClibc-based 686 Linux
by Dubiousjim 18 Apr '13

18 Apr '13

Am posting this follow-up to two mailing lists, because I've inquired about it on both. Previous messages are at: * http://www.haskell.org/pipermail/glasgow-haskell-users/2013-April/023912.ht… * http://lists.alpinelinux.org/alpine-devel/1699.html I have seemed to successfully cross-compile a stage2 ghc for my target system, an i686 Linux based on uClibc. One issue I don't think I've mentioned before is that the target system uses a kernel with grsecurity and PaX, and that involves patching the toolchain as well. However my cross-compiling toolchain doesn't have any such tweaks applied. This will be relevant below. Another potential issue is that my host system, a different i686 Linux based on glibc, is running inside a chroot on my target system. I don't think this is in fact responsible for any problems, but I thought I should mention it. So I last wrote on the glasgow-haskell mailing list: On Wed, Apr 03, 2013 at 10:55:14AM -0400, Dubiousjim wrote: > But there's still something funny with the binaries generated by the > compiler. That means I can't yet use this ghc to directly recompile ghc > on my target system. > > $ cat ~/hello.hs > main = putStrLn "Hello World!\n" > $ rm -f hello > $ inplace/bin/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello > [1 of 1] Compiling Main ( /home/jim/hello.hs, > /home/jim/hello.o ) [flags changed] > Linking hello ... > $ ./hello > Can't modify application's text section; use the GCC option -fPIE > for > position-independent executables. > > Seems like I'm close, but not quite there yet. > > Supplying the flag -fPIE to ghc when building hello says: > > ghc-stage2: unrecognised flags: -fPIE > > The flag -fPIC on the other hand is accepted, but then the generated > binary hello still fails with the same error. Krzysztof replied to me offline (thanks Krzysztof!), but I still haven't managed to get this to work. I started thinking the difficulty came from the grsecurity or PaX features of my target system. Maybe the toolchain on the target system had been configured in a way to build binaries that would work ok on that system, but ghc wasn't yet so configured, and that's why the binaries compiled by ghc don't work. I wrote to my target system's mailing list (alpine-devel(a)lists.alpinelinux.org) expressing this fear. There was also some evidence against this hypothesis. (Test binaries I built using the cross-compiling toolchain, which hadn't been tweaked in the way the toolchain on the target system had, did build binaries that executed fine on the target; but perhaps this was just because the test programs were too simple.) But since I didn't know what was going on, this seemed worth exploring. However, I'm pretty confident I've now ruled this explanation out. Even if I build and boot from a vanilla kernel, binaries generated by the ghc-stage2 in question still fail with the error message I reported. So then I started trying to track down the error message in any sources or binaries on my system. Couldn't find it kernel or ghc sources. I did find it though in the source code for the uClibc library. It's from lines 614-681 of the file uClibc-0.9.33.2/ldso/ldso/ldso.c: ----------------------------- start ----------------------------------- /* At this point we are now free to examine the user application, * and figure out which libraries are supposed to be called. Until * we have this list, we will not be completely ready for dynamic * linking. */ /* Find the runtime load address of the main executable. This may be * different from what the ELF header says for ET_DYN/PIE executables. */ { unsigned int idx; ElfW(Phdr) *phdr = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (idx = 0; idx < auxvt[AT_PHNUM].a_un.a_val; idx++, phdr++) if (phdr->p_type == PT_PHDR) { DL_INIT_LOADADDR_PROG(app_tpnt->loadaddr, auxvt[AT_PHDR].a_un.a_val - phdr->p_vaddr); break; } if (DL_LOADADDR_BASE(app_tpnt->loadaddr)) _dl_debug_early("Position Independent Executable: " "app_tpnt->loadaddr=%x\n", DL_LOADADDR_BASE(app_tpnt->loadaddr)); } /* * This is used by gdb to locate the chain of shared libraries that are * currently loaded. */ debug_addr = _dl_zalloc(sizeof(struct r_debug)); ppnt = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) { if (ppnt->p_type == PT_GNU_RELRO) { relro_addr = ppnt->p_vaddr; relro_size = ppnt->p_memsz; } if (!app_mapaddr && (ppnt->p_type == PT_LOAD)) { app_mapaddr = DL_RELOC_ADDR (app_tpnt->loadaddr, ppnt->p_vaddr); } if (ppnt->p_type == PT_DYNAMIC) { dpnt = (ElfW(Dyn) *) DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr); _dl_parse_dynamic_info(dpnt, app_tpnt->dynamic_info, debug_addr, app_tpnt->loadaddr); #ifndef __FORCE_SHAREABLE_TEXT_SEGMENTS__ /* Ugly, ugly. We need to call mprotect to change the * protection of the text pages so that we can do the * dynamic linking. We can set the protection back * again once we are done. */ _dl_debug_early("calling mprotect on the application program\n"); /* Now cover the application program. */ if (app_tpnt->dynamic_info[DT_TEXTREL]) { ElfW(Phdr) *ppnt_outer = ppnt; ppnt = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) { if (ppnt->p_type == PT_LOAD && !(ppnt->p_flags & PF_W)) _dl_mprotect((void *) (DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr) & PAGE_ALIGN), (DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr) & ADDR_ALIGN) + (unsigned long) ppnt->p_filesz, PROT_READ | PROT_WRITE | PROT_EXEC); } ppnt = ppnt_outer; } #else if (app_tpnt->dynamic_info[DT_TEXTREL]) { _dl_dprintf(_dl_debug_file, "Can't modify application's text section; use the GCC option -fPIE for position-independent executables.\n"); _dl_exit(1); } #endif ----------------------------- end ----------------------------------- and indeed, the ghc-stage2 I built does seem to be generating position-dependent code, EVEN WHEN I TELL IT -fPIC. Whereas the native ghc on my host system doesn't do so, even when -fPIC is omitted. Witness: host$ which ghc /usr/bin/ghc host$ cat hello.hs main = putStrLn "Hello World!\n" host$ /usr/bin/ghc -o hello-host hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-host ... There we've compiled hello-host using the host's native ghc. Now we switch over to the target system (sharing the same filesystem, and cding to the same directory): target$ rm -f hello.o hello.hi target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. target$ rm -f hello.o hello.hi hello-cross target$ inplace/bin/ghc-stage2 -fPIC -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. target$ readelf -d hello-host | fgrep TEXTREL target$ readelf -d hello-cross | fgrep TEXTREL 0x00000016 (TEXTREL) 0x0 So something has gone wrong with the way I cross-compiled or have configured this ghc-stage2. It won't build position-independent code whereas the native ghc running on my host system will. So I come back to the ghc folks for advice. I hope some readers might make it this far and have suggestions or advice about things I might try. -- dubiousjim(a)gmail.com

2 1