- Glasgow-haskell-users

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

os x 64-bit?
by John Lato 11 Nov '10

11 Nov '10

Hello, 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: 4263: http://hackage.haskell.org/trac/ghc/ticket/4163 2965: (not sure, trac says the database is locked when I try to look at this one) Is Ian working on this, or anyone else? I'd like to help if I can, and I was wondering where would be the best place to start? I probably won't actually contribute much, but this seems as good a way as any for me to start working with ghc. Cheers, John

4 4

Loop optimisation with identical counters
by Christian Höner zu Siederdissen 10 Nov '10

10 Nov '10

Hi, is the following problem a job for ghc or the code generation backend (llvm)? We are given this program: {-# LANGUAGE BangPatterns #-} module Main where f :: Int -> Int -> Int -> Int -> Int f !i !j !s !m | i == 0 = s+m | otherwise = f (i-1) (j-1) (s + i+1) (m + j*5) g :: Int -> Int g !k = f k k 0 0 ff :: Int -> Int -> Int -> Int ff !i !s !m | i == 0 = s+m | otherwise = ff (i-1) (s + i+1) (m + i*5) gg :: Int -> Int gg !k = ff k 0 0 main = do print $ g 20 print $ gg 20 Here, 'f' and 'g' are a representation of the code I have. Both counters 'i' and 'j' in 'f' count from the same value with the same step size and terminate at the same time but are not reduced to just one counter. Can I reasonably expect this to be done by the code generator? 'ff' represents what I would like to see. Btw. look at the core, to see that indeed 'f' keep four arguments. Functions like 'f' are a result of vector-fusion at work but can be written by oneself as well. The point is that if 'f' gets reduced to 'ff' then I can have this: fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k) which makes for nicer code sometimes; but before rewriting I wanted to ask if that kills performance. Thanks, Christian

9 20

Wadler space leak
by Jan Christiansen 09 Nov '10

09 Nov '10

Hi, I have a question regarding the famous Wadler space leak. The following program is a variation of Wadler's example. let (first,rest) = break (const False) input in print (length (first ++ rest)) When I compile this program using -O2 and use a large text file as input the code runs in constant space. If I understand correctly, the program runs in constant space because ghc uses an optimization similar to the one proposed by Wadler/Sparud. If I define the following function which is based on break splitBy :: (a -> Bool) -> [a] -> [[a]] splitBy _ [] = [] splitBy p xs = l : case ys of [] -> [] _:zs -> splitBy' p zs where (l,ys) = break p xs and compile the following program the behaviour is different. print (length (concat (splitBy (const False) input))) In this case the memory usage is not constant. However if I use a strict pattern matching instead of the lazy tuple matching the program runs in constant space. splitBy' :: (a -> Bool) -> [a] -> [[a]] splitBy' _ [] = [] splitBy' p xs = case break p xs of (l,ys) -> l : case ys of [] -> [] _:zs -> splitBy p zs To me this looks like another instance of the Wadler space leak. Is this correct? I do not understand why the Wadler example runs in constant space and this example does not. Can anyone explain me why these functions behave differently? I still get the same behaviour if I use the following simplified function. test :: (a -> Bool) -> [a] -> [[a]] test _ [] = [] test p xs = l : case ys of [] -> [] where (l,ys) = break p xs That is, the following program does not run in constant space. print (length (concat (test (const False) input))) On a related note if I do not use -O2 the following program runs in constant space let (first,rest) = break (const False) input in print (length (first ++ rest)) while it does not run in constant space if I add an application of id as follows. let (first,rest) = break (const False) input in print (length (first ++ id rest)) Thanks, Jan

6 9

Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
by Jeremy Shaw 09 Nov '10

09 Nov '10

Hello, I have narrowed this down further to a single file. And created a trac bug for it: http://hackage.haskell.org/trac/ghc/ticket/4485 This is (the only thing?) holding up HSP and happstack moving to GHC 7. - jeremy On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: > Hello, > > I have a module, XMLGenerator, which has some overlapping instances. > I have a second module, Test, which imports that module and also adds > some more overlapping instances. > > Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top. > > Under some old version of 6.13 (and probably 6.12), if I put both > modules in the same directory and try to load Test.hs, it gets the > error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' at Test.hs:16:15-21 > Matching instances: > instance (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined at XMLGenerator.hs:16:10-68 > instance (XML m ~ x, XMLGen m) => EmbedAsChild m x > -- Defined at XMLGenerator.hs:19:10-51 > In the first argument of `($)', namely `asChild' > In the expression: asChild $ (genElement "foo") > In the definition of `asChild': > asChild b = asChild $ (genElement "foo") > > If I put the XMLGenerator module in a separate package, dummy-hsx, and > the Test modules links against it, I still get the error. > > *but* if I add: > > Extensions: OverlappingInstances > > to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for > starters, I do not understand why that happens. > > Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I > always get the error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' > Matching instances: > instance [overlap ok] (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined in XMLGenerator > (The choice depends on the instantiation of `m' > To pick the first instance above, use -XIncoherentInstances > when compiling the other instance declarations) > > Adding the IncoherentInstances flag does make it compile -- but I have > never enabled that flag and not regretted it. > > What changed between GHC 6.12 and GHC 7.0? Is there a some solution > besides using IncoherentInstances in every module that imports > XMLGenerator? > > I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal. > > thanks! > - jeremy >

3 3

ANNOUNCE: GHC 7.0.1 Release Candidate 2
by Ian Lynagh 09 Nov '10

09 Nov '10

We are pleased to announce the second release candidate for GHC 7.0.1: http://new-www.haskell.org/ghc/dist/7.0.1-rc2/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Amongst the changes since RC 1 are: * -fglasgow-exts now gives a deprecated warning, and no longer enables GADTs or TypeFamilies. * The haskell98 packge is no longer automatically linked, although this often won't make a difference as --make is now enabled by default. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

5 6

new-www
by Serge D. Mechveliani 09 Nov '10

09 Nov '10

People, what is, in short, the relation between www.haskell.org and new-www.haskell.org ? Which one do I need to use for looking for the Haskell materials, for GHC materials? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Re: Loop optimisation with identical counters
by christian Hoener zu Siederdissen 06 Nov '10

06 Nov '10

Yes indeed, this is what some fusion code could look like. I deal with stuff like this: mk i j = enumFromN (i+1) (j-i-2) -- gen indices, sometimes index pairs f i j k = T!(i,k) + T!(k+1,j) -- table lookup using some 2d tables g i j k = fun i k + fun (k+1) j -- some funny calculation z i j = minimum $ zipWith (+) (map (f i j) $ mk i j) (map (g i j) $ mk i j) y i j = minimum (map (g i j) $ mk i j) So i would like to split my calculations into f and g as sometimes (in backtracking results) only g is needed. Furthermore, there are like 12 different f g z y mk each. Being able to seperate the worker into f g means cleaner code and that it is easier to change stuff. Note that mk in f is always called with the same borders, leading to things like my original problem. But Roman has already pointed out how often this duplication of counters can occur. Gruss, Christian PS: above is a bit pseudocode-like but captures the essentials and my thumbs are numb now... ;-) ----- Original message ----- > On 06/11/2010, at 02:27, Sebastian Fischer wrote: > > > Interesting. This approach requires `f` to be inlined into its call > > site in order to eliminate the redundant argument. This is different > > from the proposal to provide a specialized version of `f` (where the > > arguments are combined) which could be reused at different call sites. > > Which proposal do you mean? I'm not sure something like that is feasible > without knowing the call sites. You have to know which arguments to > combine. > > > How many call sites with identical arguments are there in the > > generated code that triggered this discussion and in the stream fusion > > code that would benefit from this optimization? > > In stream fusion code, there is normally exactly one call site. I > suspect that the Christian's example has also been derived from stream > fusion code. > > Roman > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0