installHandler, sleep, and interrupts.
When interrupting this program, the signal handler does not get called: module Main where import Posix main = do installHandler 2 (Catch (putStrLn "Hello, world!")) Nothing sleep 600 -- putStr "" Curiously, if the last line is uncommented, the program works as expected: % ./program ^C Hello, world! This is for GHC version 5.02, run on Linux 2.2.5-15. Anders Lau Olsen ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Problem with xargs and ar
> Hello. Just a nasty build bug with 5.02 that I encountered. > > When building the prelude library, the individual object files are > turned to an archive with "xargs ar q libHSstd.a". Now, for > some reason, > on this system, GNU ar fails at some point during this process. The > standard solaris ar works all right. > > Ar is not the issue here. I've probably blundered something with the > installation of gnu ar, or it's buggy, or something. > > The problem is that once ar has failed, and the xargs has failed, and > make has halted, an _incomplete_ libHSstd.a has been created. > So one can > just run make again, and compilation proceeds, since the libHSstd.a > dependency has been satisfied. > > The way to fix this is of course just to build the archive to a > temporary file, and once the xargs has completed > successfully, rename it > to libHSstd.a. Ok, I've made that change. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Changed behaviour when reading from FIFOs!
> On Mon, Oct 29, 2001 at 02:08:23PM -, Simon Marlow wrote: > > This appears to be because the dummy Handle opened in > WriteMode is being > > garbage collected and closed, which leaves the FIFO with no > writers so > > you get EOF. 5.02 is behaving correctly here. You can add an extra > > 'hClose dummy' at the end of 'main' to prevent the EOF exception. > > Argh, that was exactly what I feared when I read the file-handles > discussion on the list. Only I didn't realize that the feature > got indeed introduced into ghc-5.02. Just to clarify: this isn't really new behaviour, but there might be a difference in the timing of GC and the scheduling of finalizers which means the observable behaviour between 5.02 and 5.00.2 is different. Of course, there might also have been a bug in 5.00.2's IO implementation. > > You have some extra blocking in there: just comment out the > first two > > lines of fifoReadLoop, and everything should be fine. > This also fixes > > the other problem you mentioned above ("varying numbers of last"). > > The blocking is essential since I need to be able to use MVars > between the threadWaitRead & the hGetLine (remember the note I > sent about fork()ing). Sorry, I can't remember that - could you remind me? The hGetLine already blocks if there's no data in the FIFO, the extra threadWaitRead will only work if the Handle is in NoBuffering mode, because otherwise there might be data in the handle buffer waiting to be read which threadWaitRead would be unable to detect. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Changed behaviour when reading from FIFOs!
On Mon, Oct 29, 2001 at 02:08:23PM -, Simon Marlow wrote: > This appears to be because the dummy Handle opened in WriteMode is being > garbage collected and closed, which leaves the FIFO with no writers so > you get EOF. 5.02 is behaving correctly here. You can add an extra > 'hClose dummy' at the end of 'main' to prevent the EOF exception. Argh, that was exactly what I feared when I read the file-handles discussion on the list. Only I didn't realize that the feature got indeed introduced into ghc-5.02. > You have some extra blocking in there: just comment out the first two > lines of fifoReadLoop, and everything should be fine. This also fixes > the other problem you mentioned above ("varying numbers of last"). The blocking is essential since I need to be able to use MVars between the threadWaitRead & the hGetLine (remember the note I sent about fork()ing). -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Changed behaviour when reading from FIFOs!
Volker Stolz writes: > Something broke when reading from FIFOs in the transition from > 5.00 to 5.02. The following program behaves as it should in > 5.00, but with 5.02 it fails after printing the last line > (strangely for varying numbers of "last"!) with > > Fail: end of file > Action: hGetChar > Handle: {loc=foo,type=readable,binary=False,buffering=none} > File: foo This appears to be because the dummy Handle opened in WriteMode is being garbage collected and closed, which leaves the FIFO with no writers so you get EOF. 5.02 is behaving correctly here. You can add an extra 'hClose dummy' at the end of 'main' to prevent the EOF exception. > Another issue is that it won't work at all with LineBuffering: > It will just print one line and then sit around doing nothing. You have some extra blocking in there: just comment out the first two lines of fifoReadLoop, and everything should be fine. This also fixes the other problem you mentioned above ("varying numbers of last"). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Changed behaviour when reading from FIFOs!
Something broke when reading from FIFOs in the transition from 5.00 to 5.02. The following program behaves as it should in 5.00, but with 5.02 it fails after printing the last line (strangely for varying numbers of "last"!) with Fail: end of file Action: hGetChar Handle: {loc=foo,type=readable,binary=False,buffering=none} File: foo Another issue is that it won't work at all with LineBuffering: It will just print one line and then sit around doing nothing. The program will create a FIFO named "foo" and simply echo everything back to you, so you'd probably want to try > ./t & > ls -1 >foo Sometimes, if you just pipe the 'head' of something, it will work without terminating, so you can try repeated invocations of 'ls'. Looks like somethings wrong in the IO/buffering code. ghc -package posix -package concurrent -o t t.lhs \begin{code} module Main where import IO import Posix import Monad import Maybe import Concurrent import System main :: IO () main = do let fifoname = "foo" h <- openFIFO fifoname hSetBuffering h NoBuffering dummy <- openFile fifoname WriteMode fifoReadLoop h where fifoReadLoop h = do fd <- handleToFd h threadWaitRead (fdToInt fd) msg <- hGetLine h print msg fifoReadLoop h openFIFO :: String -> IO Handle openFIFO fifoname = do catch (openFile fifoname ReadMode) (\e -> if (isDoesNotExistError e) then do putStrLn $ "Creating FIFO " ++ fifoname system $ "/usr/bin/mkfifo " ++ fifoname openFile fifoname ReadMode else error $ "CanĀ“t create FIFO " ++ fifoname ) \end{code} -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Building GHC 5.02 on Solaris x86
> Doh, I have several times got further than I thought but > didn't realise > it as I didn't notice it had made a ghc-5.02 binary! > > Here's my latest problem, anyway - I don't suppose it could > be caused by > the hc files being generated under a different OS with different magic > numbers could it? Ah yes, I forgot about that. Ken Shan came across the same problem when porting to Alpha. To generate a Solaris-friendly set of hc files for the libraries you need to do this: for each .hsc file, take the C output from hsc2hs on a Linux box (use --no-compile to get the _hsc_make.c file), and compile/run it on your Solaris box to get the .hs file. Take the .hs file back to Linux to generate the .hc file. You will probably have to generate a full set of .hc files, including the compiler. That means doing a 2-stage build on Linux using the .hs files generated on Solaris as above. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs