November 2010 - Glasgow-haskell-users

Non-exhaustive pattern match(es) warning in lambda functions
by Mitar 18 Nov '10

18 Nov '10

Hi! Why GHC does not warn (with -Wall) about non-exhaustive pattern match(es) warning in lambda functions? For example, this code: data Foo = Bar | Baz test1 :: Foo -> IO () test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK test2 :: Foo -> IO () test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD I think it would be quite useful to also catch such situations and issue a warning. Mitar

4 9

Terminate unused worker threads
by Edward Z. Yang 18 Nov '10

18 Nov '10

I finally got some spare time to do some GHC hacking, and after feeling my way around http://hackage.haskell.org/trac/ghc/ticket/4262 I came up with the following patch, which appears to work (that is, bound the number of worker threads hanging around after FFI calls): diff -rN -u old-ghc-clean/rts/Capability.c new-ghc-clean/rts/Capability.c --- old-ghc-clean/rts/Capability.c 2010-11-07 14:21:53.000000000 +0000 +++ new-ghc-clean/rts/Capability.c 2010-11-07 14:21:54.000000000 +0000 @@ -461,6 +461,16 @@ // This happens when the system is shutting down (see // Schedule.c:workerStart()). if (!isBoundTask(task) && !task->stopped) { + int i; + Task *t = cap->spare_workers; + // arbitrarily picked six spare workers as a good number + for (i = 1; t != NULL && i < 6; t = t->next, i++) {} + if (i >= 6) { + debugTrace(DEBUG_sched, "Lots of spare workers hanging around, terminating this thread"); + releaseCapability_(cap,rtsFalse); + RELEASE_LOCK(&cap->lock); + pthread_exit(NULL); + } task->next = cap->spare_workers; cap->spare_workers = task; } There are a few obvious questions with this patch: - We're doing a walk (albeit constant bounded) of the spare workers list; if we're actually not going to ever exceed X number maybe we should use a circular buffer or store the number of items in the queue. - It's not 100% clear to me if I've done enough cleanup (i.e. maybe other locks to release, items to free, etc?) - Of course, POSIX only, for now. Fortunately Windows is nice enough to give us ExitThread() so porting should be not a problem. Edward

3 5

Re: Proposal: Require OverlappingInstances for the most specific instance only
by Christian Höner zu Siederdissen 16 Nov '10

16 Nov '10

The change should not affect working programs, as it just allows you to define further places where you say that you want an overlapping instance. Gruss, Christian * Serge D. Mechveliani <mechvel(a)botik.ru> [16.11.2010 16:47]: > On Tue, Oct 26, 2010 at 09:41:58PM +0200, John Smith wrote: > > In the case of overlapping instance declarations, GHC currently requires > > the less specific instance to be compiled with OverlappingInstances for the > > more specific instance to be usable. This means that, for example, if you > > write > > > > type ChessBoard = Array (Int,Int) Piece > > > > there is no way to > > > > instance Show ChessBoard where > > show board = ... > > > > because Array is already an instance of Show, and was not compiled with > > OverlappingInstances. > > > > http://hackage.haskell.org/trac/ghc/ticket/3877 requests that > > OverlappingInstances be required for only the most specific instance > > declarations, as suggested in the documentation. "Perhaps the rule should > > instead say that the overlapping instance declaration should be compiled in > > this way, rather than the overlapped one ... We are interested to receive > > feedback on these points." > > > > SPJ offered to make this change, if the list users agree. (See comment 6.) > > Proposed deadline for discussion is 16th November. > > > > I always expected that such programs as above must be valid. > On the other hand, I do not understand these possible ways of compilation, > these words about "compiled in this way, rather than the overlapped one". > Now, as I already have overlapping instances work in my programs, for a > long time, it is difficult for me to predict the consequences of the > change. > Can the team issue the corresponding GHC pre-release for testing, > without making a decision for future before the users report their > impression? > > With kind regards, > > ----------------- > Serge Mechveliani > mechvel(a)botik.ru > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Proposal: Require OverlappingInstances for the most specific instance only
by John Smith 16 Nov '10

16 Nov '10

In the case of overlapping instance declarations, GHC currently requires the less specific instance to be compiled with OverlappingInstances for the more specific instance to be usable. This means that, for example, if you write type ChessBoard = Array (Int,Int) Piece there is no way to instance Show ChessBoard where show board = ... because Array is already an instance of Show, and was not compiled with OverlappingInstances. http://hackage.haskell.org/trac/ghc/ticket/3877 requests that OverlappingInstances be required for only the most specific instance declarations, as suggested in the documentation. "Perhaps the rule should instead say that the overlapping instance declaration should be compiled in this way, rather than the overlapped one ... We are interested to receive feedback on these points." SPJ offered to make this change, if the list users agree. (See comment 6.) Proposed deadline for discussion is 16th November.

2 1

multiple module program fails compile
by Larry Evans 15 Nov '10

15 Nov '10

The attached program fails to compile despite it being a close copy of that shown in the Reference: comments. The ghci invocation results in: ================================ ~/prog_dev/haskell/my-code $ ghci Modules.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. [1 of 1] Compiling Test ( Modules.hs, interpreted ) Modules.hs:12:0: parse error on input `module' Failed, modules loaded: none. Prelude> :q Leaving GHCi. ================================== What should change to allow compilation? TIA. -Larry

3 2

Can't pull http://darcs.haskell.org/ghc
by David Fox 15 Nov '10

15 Nov '10

I can neither darcs pull nor darcs get the repository at http://darcs.haskell.org/ghc - it just hangs indefinitely. Anyone else having this problem? -david

2 1

6.12.3: hs_add_root crashes
by Bulat Ziganshin 15 Nov '10

15 Nov '10

Hello , ghc 6.12.3. i use the following code to initialize my haskell dll: extern "C" { #include "HsFFI.h" void __stginit_Main(); void haskell_init (void) { static bool initialized = FALSE; if (!initialized) { initialized = TRUE; hs_init(NULL, NULL); hs_add_root(__stginit_Main); } } } but it crashes on hs_add_root call. what may be source of problem? without hs_add_root, it works ok, but crashes on multiple calls from C to haskell functions, probably due to GC of "unused" code :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1

Odd behavior of ncurses with -threaded
by Simon Hengel 15 Nov '10

15 Nov '10

Hello, the following program should wait 3 seconds for user input before. If now user input occurs within that time, it just prints -1. {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign import Foreign.C.String import Foreign.C.Types import Foreign.C.Error foreign import ccall unsafe initscr :: IO (Ptr ()) foreign import ccall unsafe endwin :: IO CInt foreign import ccall unsafe getch :: IO CInt foreign import ccall unsafe timeout :: CInt -> IO () main = do initscr timeout 3000 c <- getch endwin print c This works just fine if I do not use the threaded RTS, say: ghc --make -lcurses Main.hs However, with ghc --make -threaded -lcurses Main.hs it prints -1 immediately without awaiting the 3 seconds. Is that considered a bug? Should I open a ticket? ghc: 6.12.1 linux: 2.6.32 ncurses: 5.7 Cheers, Simon

5 9

Signal handler scheduling on single-threaded RTS
by Edward Z. Yang 13 Nov '10

13 Nov '10

I've been poking the bad behavior Brian described here: http://blog.ezyang.com/2010/08/interrupting-ghc/comment-page-1/#comment-1334 and in the process noticed something kind of interesting about thread scheduling in non-multithreaded mode (i.e. without -threaded). When the single-threaded RTS receives a signal, it writes it to pending_handler_buf, and hopes that eventually startSignalHandlers creates the threads to handle the signal. This doesn't happen instantaneously, which is /really/ obvious if you're looping on an FFI call (like a program might use readline). Here's an example (with some extra debug statements from me): installing Haskell signal handler cap 0: thread 1 stopped (suspended while making a foreign call) > ^Cstoring pending signal cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) Just "" cap 0: thread 1 stopped (suspended while making a foreign call) > cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: thread 1 appended to run queue starting signal handlers scheduling a thread to handle signal (signo=2) cap 0: created thread 2 cap 0: thread 2 appended to run queue cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) As you can see, the signal is stored immediately, but thread 1 gets another crack at running the FFI call before it yields and we start signal handlers. Then, it turns out, thread 1 /never/ yields to anyone else, unless I add this following patch: hunk ./rts/posix/Signals.c 432 &base_GHCziConcziSignal_runHandlers_closure, rts_mkPtr(cap, info)), rts_mkInt(cap, info->si_signo)))); + contextSwitchCapability(&MainCapability); } unblockUserSignals(); In which case the program finally realizes that there's a signal and handles it about seven <ENTER> presses later. I wonder if we should make it so that contextSwitchCapability(..) works more instantly; possibly by checking for it before we start a safe FFI call and yielding before we go into the FFI. Cheers, Edward P.S. -threaded execution is broken in a different way: the ^C doesn't get handled until the FFI call returns to Haskell. But that's another issue entirely, and one in which readline is partially to blame. :-)

1 2

Re: [Glasgow-haskell-users] os x 64-bit?
by John Lato 11 Nov '10

11 Nov '10

Hi Greg, Thanks very much for all your work on this, and Barney Stratford too. This is great news. I'm doing a lot of numerical work with Doubles at the moment, so progress is quite welcome! I can try building 7.0.1-RC using a 32-bit 6.12.3, although probably not until the weekend. I'll let you know how it goes. If there are any special build instructions for this, maybe you could update trac #2965 with details? Cheers, John From: Gregory Wright <gwright(a)antiope.com> > > Hi, > > I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard. Much of the work > in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts > ghc 6.10.4 has built successfully in 64 bit mode for a number of months. > > Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because > of changes in ghci. These changes were in part to remove the limitation > that modules > loaded by ghci had to be located below the 2 GB address boundary. > Unfortunately, > they revealed code paths in ghc's Mach-O linker that were never tested. > (See > bug #4318. Other bugs may be partial duplicates; the tickets probably need > to be examined to check which ones are distinct.) > > The good news is that the linker patches were done just in time for 7.0.1. > You should be all set to try the release candidates on Snow Leopard 64-bit. > > I built my 7.0.1-rc2 using a 64 bit 6.10.4. My original 64-bit 6.10.4 > was bootstrapped > using a 32-bit 6.10.4 compiled on Leopard. Reports of trouble building the > 7.0.1 release candidates using a 32-bit bootstrap compiler would be > especially > useful. > > Best Wishes, > Greg > > > On 11/9/10 12:48 PM, Brian Bloniarz wrote: > > On 11/09/2010 02:36 AM, John Lato wrote: > >> I was wondering if there is a status report anywhere of progress towards > >> making ghc compile 64-bit on Snow Leopard. There are a few trac tickets > >> that seem related: > > I think http://hackage.haskell.org/trac/ghc/ticket/3472 > > is related if you haven't seen it. > > > > I'm not working on this, though I am interested in helping enable > > cross-compilation of GHC in general. I have been working on one facet > > though: hsc2hs. hsc2hs is one of barriers to cross-compilation because > > it requires compiling and running a .c file on the target machine > > (because it needs target-specific information like the layout of > > structures; GHC's mkDerivedConstants also has the same problem). > > > > I have a proof-of-concept patch which can do hsc2hs codegeneration > > without running anything. This uses the same approach that autoconf > > uses for cross-compilation. I'll try to post it within the next few > > days -- if anybody finds this approach interesting please let me know. > > > > Thanks, > > -Brian >

3 2