June 2003 - Glasgow-haskell-users

RE: signal handling and optimisation
by Simon Marlow 23 Jun '03

23 Jun '03

> I'm trying to write some code that catches unix signals and turns them > into GHC exceptions, GHC version 6.0, debian linux > > Heres my code: > > ------ > module Main where > > import Control.Concurrent > import Control.Exception > import System.Posix > import IO > > catchCtrlC :: IO Handler > catchCtrlC > = do main_thread <- myThreadId > installHandler sigINT (Catch (handler main_thread)) Nothing > where > handler :: ThreadId -> IO () > handler main_thread = throwTo main_thread > (ErrorCall "Kaboom") > > main :: IO () > main = do catchCtrlC > print (f 1) > > f :: Int -> Int > f x = f (x + 1) > ------ > > The function "f" is intentionally bogus, I want it to loop so > I have enough time to hit cntrl-C. You've hit a known bug with concurrency, described in the Control.Concurrent documentation. The problem is that context switches only happen when some allocation is going on: in your f function above, the optimiser turns it into a loop that does no allocation, so no context switches can happen and the exception is never delivered. You probably won't run into this bug in a real program ;-) Cheers, Simon

1 0

HEADS UP: GCC 3.x and Sparc
by Simon Marlow 23 Jun '03

23 Jun '03

I've been tracking down some issues with GCC 3.2/3.3 on Sparc, and it turns out that there's a known bug in these compilers which affects us. See my bug report here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11252 which is a duplicate of the original bug, here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7871 The upshot appears to be that global register variables are broken on GCC 3.2+. So far this hasn't affected us on x86 (fingers crossed), but it certainly shows up on Sparc. If you're on a Sparc box, stick to GCC 2.95 for now. I'll try to get an idea from the gcc folks of when this might be fixed. Cheers, Simon

1 0

RE: Changes in the Core language file syntax since GHC5.02?
by Simon Peyton-Jones 23 Jun '03

23 Jun '03

Don pointed to the source code, but the human-readable document really should be updated too. Would anyone like to volunteer? Preferably someone who's been using Core a bit. (I think the changes are only minor, though.) I'm always interested to know what you are using it for, too! Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dimitry Golubovsky | Sent: 22 June 2003 19:15 | To: glasgow-haskell-users(a)haskell.org | Subject: Changes in the Core language file syntax since GHC5.02? | | Hi, | | I asked this in the fa.haskell newsgroup, but since this is more | GHC-specific, maybe this list is a better place to ask. | | I am trying to learn the syntax of Core language files using the paper | by Andrew Tolmach named "An External Representation for the GHC Core | Language". This was a draft for the version 5.02. Have there been any | improvements to the Core language definitions since that version and | during the v6.0 implementation? Are they summarized in a document? Or | maybe a fresher version of the paper is available? | | Thanks, | | -- | Dmitry M. Golubovsky | South Lyon, MI | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: state of ghc6 on sparc
by Simon Marlow 23 Jun '03

23 Jun '03

> | > often...). The problem around this is in my opinion to make a > | > Haskell98 > | > compliant trimmed down readline library which doesn't > depend on the c > | > library. It shouldn't be too difficult. I don't expect > that people are > | > using the full power of readline anyway. > | > | Making a working readline isn't that simple - you need to > know something > | about the terminal properties for one, which means being able to use > | termcap or terminfo. > > But if someone produced an adequate one that did the job, and > that we could distribute with GHC, we'd surely use it, right? > To avoid these perpetual readline problems. That would probably be a good idea, yes. Cheers, Simon

5 5

Changes in the Core language file syntax since GHC5.02?
by Dimitry Golubovsky 22 Jun '03

22 Jun '03

Hi, I asked this in the fa.haskell newsgroup, but since this is more GHC-specific, maybe this list is a better place to ask. I am trying to learn the syntax of Core language files using the paper by Andrew Tolmach named "An External Representation for the GHC Core Language". This was a draft for the version 5.02. Have there been any improvements to the Core language definitions since that version and during the v6.0 implementation? Are they summarized in a document? Or maybe a fresher version of the paper is available? Thanks, -- Dmitry M. Golubovsky South Lyon, MI

2 1

RE: isEmptyChan blocks?
by Simon Peyton-Jones 20 Jun '03

20 Jun '03

| > I noticed that isEmptyChan blocks if the channel is already | > waited on by readChan, is this the intended behaviour? | > At least I was a bit surprised by a blocking predicate.. | | I agree this doesn't seem right. Looking at the implementation though, | I can't see an easy way to fix it - any suggestions? Just to clarify. The offending module is Control.Concurrent.Chan, and I reproduce the key code below. The channel is represented by a pair of MVars, which point to head and tail (respectively) of a list composed of MVars. The difficulty is that a blocked reader will own the read-end MVar, so isEmptyChan blocks. That makes isEmptyChan essentially useless. Either it should be removed, or the implementation of Chan needs to be elaborated to support isEmptyChan. Volunteers? Simon -- A channel is represented by two @MVar@s keeping track of the two ends -- of the channel contents,i.e., the read- and write ends. Empty @MVar@s -- are used to handle consumers trying to read from an empty channel. -- |'Chan' is an abstract type representing an unbounded FIFO channel. data Chan a = Chan (MVar (Stream a)) (MVar (Stream a)) type Stream a = MVar (ChItem a) data ChItem a = ChItem a (Stream a) -- See the Concurrent Haskell paper for a diagram explaining the -- how the different channel operations proceed. -- |Build and returns a new instance of 'Chan'. newChan :: IO (Chan a) newChan = do hole <- newEmptyMVar read <- newMVar hole write <- newMVar hole return (Chan read write) -- To put an element on a channel, a new hole at the write end is created. -- What was previously the empty @MVar@ at the back of the channel is then -- filled in with a new stream element holding the entered value and the -- new hole. -- |Write a value to a 'Chan'. writeChan :: Chan a -> a -> IO () writeChan (Chan _read write) val = do new_hole <- newEmptyMVar modifyMVar_ write $ \old_hole -> do putMVar old_hole (ChItem val new_hole) return new_hole -- |Read the next value from the 'Chan'. readChan :: Chan a -> IO a readChan (Chan read _write) = do modifyMVar read $ \read_end -> do (ChItem val new_read_end) <- readMVar read_end -- Use readMVar here, not takeMVar, -- else dupChan doesn't work return (new_read_end, val) -- |Returns 'True' if the supplied 'Chan' is empty. isEmptyChan :: Chan a -> IO Bool isEmptyChan (Chan read write) = do withMVar read $ \r -> do w <- readMVar write let eq = r == w eq `seq` return eq

2 1

RE: [Gtk2hs-users] ghci-5.04.3 and ghc-6.0
by Simon Marlow 20 Jun '03

20 Jun '03

> 2003年06月17日(火)の20時15分に Simon Marlow 曰く: > > > What seems to be happening is that the Arrow module in gtk2hs is > > > clashing with the Arrow module in the lang package. As far as > > > I can tell > > > this all looks perfectly normal, so why don't we this > kind of problem > > > all the time? What's special about Arrow? > > > > > > How does it get resolved in the libHS*.a case? How does the > > > system linker resolve the ambiguity when ghci's linker cannot? > > > > The static linker will simply pick the first > __stginit_Arrow it finds > > when searching libraries. In actual fact, you're better > off with the > > linking error, because the static linking behaviour is > likely to result > > in crashes at runtime. > > I see, interesting. > > In this case gtk2hs.o was generated by ghc-pkg, but naively, > can I ask, > is it not possible to detect this claiming of module names at > buildtime? Yes, in theory, but it would mean searching the entire search path to find all the .hi files for a module, rather than stopping as soon as you've found one. Cheers, Simon

2 1

Missing 'ErrorHdrHook' in GHC 6.0
by Kevin S. Millikin 20 Jun '03

20 Jun '03

I just switched to GHC 6.0 for a project where I have "plugins" that are written in Haskell and reside in a Win32 DLL. I can make everything work with 6.0, except I get this when building the DLL: d:/ghc/ghc-6.0/libHSbase.a(TopHandler__7.o)(.text+0xc8):ghc7504.hc: undefined reference to `ErrorHdrHook' dllwrap: gcc exited with status 1 I wonder why it's just ErrorHdrHook that can't be found? My solution is to include this: void ErrorHdrHook(FILE *where) { fprintf(where, "\n"); } in the DLL. ---- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x162 http://www.atcorp.com

1 0

signal handling and optimisation
by Bernard James POPE 20 Jun '03

20 Jun '03

Hi All, I'm trying to write some code that catches unix signals and turns them into GHC exceptions, GHC version 6.0, debian linux Heres my code: ------ module Main where import Control.Concurrent import Control.Exception import System.Posix import IO catchCtrlC :: IO Handler catchCtrlC = do main_thread <- myThreadId installHandler sigINT (Catch (handler main_thread)) Nothing where handler :: ThreadId -> IO () handler main_thread = throwTo main_thread (ErrorCall "Kaboom") main :: IO () main = do catchCtrlC print (f 1) f :: Int -> Int f x = f (x + 1) ------ The function "f" is intentionally bogus, I want it to loop so I have enough time to hit cntrl-C. When I compile this with no optimisations: ghc --make Sig.hs I get the desired behaviour, that is soon after I hit cntrl-C I get: Fail: Kaboom However, when I compile with -O: touch Sig.hs && ghc --make -O Sig.hs Now the exception does not appear to be caught. Indeed the program just keeps on looping. If a give the program a lot of cntrl-Cs then eventually I get this message: a.out: too many pending signals And the program dies. Commenting out the call to "catchCtrlC" from within "main" seems to let GHC's default signal handling mechanism work properly, that is after (strangley 2) cntrl-Cs the program dies (no message). Cheers, Bernie.

1 0

RE: ghc6.0 and ghc5.04.3 i386 rpms available
by Simon Marlow 20 Jun '03

20 Jun '03

> 2003年06月13日(金)の17時53分に Jens Petersen 曰く: > > The latest package is named > > ghc6.0-6.0-1 and there is also a ghc5.04.3-5.04.3-2 package[...] The > > ghc5.04.3 and ghc6.0 can be installed in parallel without conflicts, > > Thinking about it more, I realised that of course what is really being > numbered here is the interface version number of the hi files > (the "ABI" > version if you like), so perhaps it would be better to name > the packages > ghc6000 and ghc5043? These names also seems a little more seemly... The reason for including the version number in the name is so you can have side-by-side installation of several different versions of GHC, right? Is there really a demand for having several different patchlevel releases installed at the same time? On FreeBSD, for example, we currently allow both GHC 6.x and 5.x to be installed side-by-side, but nothing finer grained than that. There doesn't seem to be a precedent for doing this in RPMs - there are only a few cases where I have multiple versions of the same package installed together, and they tend to be confined to major releases (eg. python & python2). Cheers, Simon

3 2