Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On 10/11/2010 17:52, Mitar wrote: Hi! On Wed, Nov 10, 2010 at 4:16 PM, Simon Marlowmarlo...@gmail.com wrote: The right way to fix it is like this: Optimist. ;-) let run = unblock doSomething `catches` [ Handler (\(_ :: MyTerminateException) - return ()), Handler (\(e :: SomeException) - putStrLn $ Exception: ++ show e) ] `finally` (putMVar terminated ()) nid- block $ forkIO run In 6.12.3 this does not work (it does not change anything, I hope I tested it correctly) because finally is defined as: a `finally` sequel = block (do r- unblock a `onException` sequel _- sequel return r ) Oh, good point! I must have tested it with 7.0. So this is indeed something that is fixed by the new async exceptions API: finally itself doesn't raise async exceptions inside a mask. To fix this with GHC 6.12.3 you'd have to avoid finally and do it manually: let run = do r - (unblock doSomething `catches` [ Handler (\(_ :: MyTerminateException) - return ()), Handler (\(e :: SomeException) - putStrLn $ Exception: ++ show e) ]) `onException` sequel sequel where sequel = putMVar terminated () Now *that* works - I tested it with 6.12.3 this time. Cheers, Simon You see that unblock there? So it still unblocks so that second exception is delivered immediately after catches handles the first exception? But I agree that your explanation for what is happening is the correct one. Better than my hanging threads at the end. And with my throwIO approach I just override MyTerminateException with ThreadKilled. Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Glasgow-haskell-users] os x 64-bit?
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 gwri...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Glasgow-haskell-users] os x 64-bit?
On 11/11/2010 11:17, John Lato wrote: 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! FYI, GHC 7.0.1 has -msse2 which makes floating-point arithmetic quite a lot faster on x86. For best results, compile the base package with it too. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Glasgow-haskell-users] os x 64-bit?
Hi John, I'll take a look at trac #2965. You should be able to build the 7.0.1-rc2 tarball simply by unpacking it and following the instructions in the README. (In short, configure, make then make install ought to work.) If it doesn't build properly out of the box, I'd be interested in hearing about it. AFAIK, only 6.10.4 has been tested as bootstrap compiler for 7.0.1-rc2, although I expect 6.12.3 should work too. There is always the possibility of some hiccup, however. Best Wishes, Greg On 11/11/10 6:17 AM, John Lato wrote: 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 gwri...@antiope.com mailto:gwri...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Signal handler scheduling on single-threaded RTS
Relatedly, it seems that it takes a nontrivial amount of time for the multithreaded RTS to realize that a thread has emitted a signal. I wonder if there's a more direct way an FFI call can say when I get back to Haskell, immediately start propagating an exception. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Odd behavior of ncurses with -threaded
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Quoth Simon Hengel simon.hen...@wiktory.org, ... 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 I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. A very casual scrutiny of an ncurses source I have at hand shows no EINTR handling on select() in lib_getch.c. That could be the problem, or something like it - select() is interrupted by GHC's SIGALRM, aborting the timeout. Or they could both be using SIGALRM, and GHC's signal is mistaken for the application library's, but I don't see any sign of that and select() is a more obvious way to do the timeout anyway. 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 Someone probably should. It's tempting to conclude that the bug is in ncurses, and perhaps it is, and maybe there's nothing to be done about it anyway, but a language runtime that's spewing SIGALRMs is going to crash into this kind of thing a lot. I could comment a couple of other cases to the ticket that I've seen here or on Haskell-cafe. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
ghc --make -threaded -lcurses Main.hs I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. That helped, thanks! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Excerpts from Donn Cave's message of Thu Nov 11 17:07:20 -0500 2010: ghc: 6.12.1 linux: 2.6.32 ncurses: 5.7 Someone probably should. It's tempting to conclude that the bug is in ncurses, and perhaps it is, and maybe there's nothing to be done about it anyway, but a language runtime that's spewing SIGALRMs is going to crash into this kind of thing a lot. I could comment a couple of other cases to the ticket that I've seen here or on Haskell-cafe. I was under the impression we fixed this: http://hackage.haskell.org/trac/ghc/ticket/850 That is, we should be using SIGVTALRM, not SIGALRM, these days, except under certain conditions when your operating system doesn't support the proper timer (which Linux most assuredly does). Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
On Thu, Nov 11, 2010 at 2:32 PM, Edward Z. Yang ezy...@mit.edu wrote: I was under the impression we fixed this: http://hackage.haskell.org/trac/ghc/ticket/850 That is, we should be using SIGVTALRM, not SIGALRM, these days, except under certain conditions when your operating system doesn't support the proper timer (which Linux most assuredly does). It's still a pretty common problem with all kinds of libraries. http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Quoth Simon Hengel simon.hen...@wiktory.org, ghc --make -threaded -lcurses Main.hs I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. That helped, thanks! Great, but, beware - I am not fully informed on what it does, beyond the SIGALRM difference. I run my own application this way without apparent serious harm, but it could be failing to reclaim memory for example, due to missed garbage collections. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
Hi! On Wed, Nov 10, 2010 at 4:48 PM, Simon Marlow marlo...@gmail.com wrote: You can use maskUninterruptible in GHC 7, but that is not generally recommended, Maybe there should be some function like maskUninterruptibleExceptUser which would mask everything except UserInterrupt exception. Or maybe UserInterrupt and some additional exception meant for use by programs, like InterruptMaskException. Or we could make two new type classes: HiddenException -- for those exceptions which should not print anything if not caught UninterruptibleExceptException -- for those exceptions which should not be masked with maskUninterruptibleExcept function Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
