- Glasgow-haskell-users

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

RE: Readline (was Re: state of ghc6 on sparc)
by Simon Marlow 20 Jun '03

20 Jun '03

> Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> writes: > > > It would be nice to have those bindings but just having > backspace and > > left-right cursors work would already be a huge improvement > over nothing. > > OK, here is my contribution. The attached module SimpleLineEditor > is API-compatible with readline, and is a slight elaboration of > the line editor currently distributed as part of hmake interactive. It seems to behave strangely here: I can delete the prompt, and if I move the cursor to the left and delete some characters, the characters to the right of the cursor don't move. Also, the backspace key doesn't work, although C-Backspace does work (backspace works fine with readline). This is in an xterm; in a cygwin shell window different strange things happen. Cheers, Simon

1 0

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

20 Jun '03

> 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. Cheers, Simon

2 1

state of ghc6 on sparc
by Isaac Jones 19 Jun '03

19 Jun '03

Hello :) Can anyone enlighten me as to the state of the ghc6 sparc distribution? The file on Hal's web page mentioned some time back is not the same file as on the GHC web page (I note that the filenames are different also). Are any of them known to work if installed in a non-standard place? peace, isaac

3 2