- Glasgow-haskell-users

RE: Waiting on Sockets or File Descriptors
by Simon Marlow 03 Feb '05

03 Feb '05

On 02 February 2005 19:48, Peter Simons wrote: > Wolfgang Thaller writes: > > > a) poll() is not supported on Mac OS X and (at least some > > popular versions of) BSD. > > Are you certain? Just tried "man poll" on one of the MacOS X > machines the SourceForge compile farm offers, and that one > had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5". > > > > b) 'forkIO' in the threaded RTS would suffice in this > > case, as the poll() or select() system calls don't use > > any thread-local state. In the threaded RTS, "safe" > > foreign imports never affect other threads [...]. > > That would be really good news! I assumed that GHC's runtime > system used one thread for _all_ FFI invocations? (Unless > you start new ones.) So I thought calling poll() would block > all other FFI invocations until it returned? > > Or is that only for "unsafe" FFI calls? When you compile your program with -threaded, "safe" FFI calls don't block other threads, but "unsafe" calls still do. Basically a "safe" FFI call releases the lock on the RTS so other Haskell threads can continue to run (and that at least partly explains why we have the distinction: releasing and re-acquiring a lock is expensive). > Do you have an URL for me where I can find out more about > this, by any chance? There's not much, but the -threaded option is documented here: http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.h tml#OPTIONS-LINKER and the Control.Concurrent documentation explains what "bound" threads are. Cheers, Simon

4 3

RE: debugging memory allocations
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 00:41, Duncan Coutts wrote: > On Wed, 2005-02-02 at 13:30 -0700, Seth Kurtzberg wrote: >> Duncan Coutts wrote: >>> In these cases we cannot turn on traditional profiling since that >>> would interfere with the optimisations we are relying on to >>> eliminate most of the other memory allocations. >>> >> I don't understand why you can't use profiling as a debugging tool. >> How would profileing, ifor test purposes, cause other things to >> break? > > The problem is that profiling add in extra parameters and extra code > to each function (each SCC). This can interfere with optimisations > like inlining and unboxing I believe. Simon could explain it better. Yes. Those pesky SCC annotations get in the way of optimisations. It's possible (likely even) that we could do a better job here, profiling is long overdue for an overhaul. Cheers, Simon

1 0

Waiting on Sockets or File Descriptors
by Peter Simons 02 Feb '05

02 Feb '05

Hi, I have the following problem: I use an external library through the foreign function interface which gives me _several_ sockets and expects me to call it again when any of those sockets becomes readable or writable. Since I know that the Haskell run-time system has all the required functionality in place, I wonder whether there is any way to register these sockets in the internal scheduler and have it call an 'IO ()' function in case of such an event? What makes matters more complicated is that the _library_ owns these sockets -- not me. So I cannot really touch them or lift them into a 'Handle'. Any ideas? Peter

4 7

RE: debugging memory allocations
by Simon Marlow 02 Feb '05

02 Feb '05

On 02 February 2005 13:38, Duncan Coutts wrote: > I'm looking for advice on how to figure out why some piece of code is > allocating memory when I think it ought to be able to work in constant > space. > > In these cases we cannot turn on traditional profiling since that > would > interfere with the optimisations we are relying on to eliminate most > of > the other memory allocations. > > Would looking at the core files help? What would I be looking for? > > Here's a simple version that I would expect to run in constance space. > > pixbufSetGreen :: Pixbuf -> IO () > pixbufSetGreen pixbuf = do > ptr <- pixbufGetPixels pixbuf > sequence_ > [ do pokeByteOff ptr (y*384+3*x) (0 ::Word8) > pokeByteOff ptr (y*384+3*x+1) (128::Word8) > pokeByteOff ptr (y*384+3*x+2) (96 ::Word8) > | y <- [0..127] > , x <- [0..127] ] > > (Don't worry about all those random constants, it's just test code!) Yes, let's see the core. Since you're interested in allocation, you might be better off with -ddump-prep rather than -ddump-simpl: the former has all the allocation made into explicit 'let' expressions ready for code generation. Cheers, Simon

2 1

readline fun
by Ian Lynagh 02 Feb '05

02 Feb '05

Hi all, The Debian ghc6 package curently has both a build-dependency and a normal dependency on libreadline4-dev. The former is so the readline library (and ghci) can be built, and the latter so compiling programs with the readline package behaves correctly. Now I want to move over to libreadline5-dev instead. Clearly, to build the new ghc6, I need the old ghc6 installed, and thus need libreadline4-dev installed (as it's a dependency). However, libreadline4-dev and libreadline5-dev can't be installed simultaneously. I believe this isn't a /real/ problem because the readline package of the old GHC isn't actually needed to compile a new GHC, so libreadline4-dev isn't actually needed. Thus I can solve this problem by doing a build by hand on each arch. However, it would make my life a lot easier if things weren't so entangled in the first place. While I could just split the readline package off into a separate ghc6-readline package for Debian, I fear this may cause confusion for users, and it would mean satisfying cabal package deps was not necessarily sufficient for Debian systems. So what would be really useful for me is if the split were done by ghc itself, in much the same way as how the opengl libraries can be split off. Then, in particular, cabal packages using readline would have to explicit state it rather than assuming it'll be there by default. Does that sounds reasonable? Of course, I still have the same problem with libgmp, but I can't see any way around that one :-( Thanks Ian

1 0

RE: Process library and signals
by Simon Marlow 02 Feb '05

02 Feb '05

On 27 October 2004 15:08, Glynn Clements wrote: > Simon Marlow wrote: > >> So basically you're saying that if runProcess is to be used in a >> system()-like way, that is the parent is going to wait synchronously >> for the child, then the parent should be ignoring SIGQUIT/SIGINT. >> On the other hand, if runProcess is going to be used in a >> popen()-like way, then the parent should not be ignoring >> SIGQUIT/SIGINT. > > Exactly. > >> The current >> interface doesn't allow for controlling the behaviour in this way. > > Yep. > >> So the current signal handling in runProcess is wrong, and should >> probably be removed. What should we have instead? We could >> implement the system()-like signal handling for System.Cmd.system >> only, perhaps. > > Well, probably for system and rawSystem. I've now fixed system and rawSystem to do something more appropriate on POSIX systems: they now disable SIGINT and SIGQUIT in the parent, and reset these signals to SIG_DFL in the child. This isn't completely correct, but it's better than before. runProcess and friends don't do any signal handling. I think this covers most of the useful situations. If you want to do the same thing in both parent and child, or handle in the parent and SIG_DFL in the child: use runProcess. If you want to ignore in the parent and SIG_DFL in the child: use System.Cmd.{system,rawSystem}. To handle in the parent and ignore in the child: unfortunately not directly supported. I realise this doesn't address the library design issues you raised, but as you pointed out there doesn't seem to be a good platform-independent solution here. Cheers, Simon

2 1

-K switch
by Santoemma Enrico 02 Feb '05

02 Feb '05

Hello, I'm getting this error: Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. The application is compiled under ghc 6.2.1 I've increased it and everything works, but before I begin to look for the way to pass an environment variable to a cgi app on apache under windows... I'd like to ask whether the error means that the stack must be bigger, or that someone is doing a wrong recursion in the haskell code. After all, I'm just retrieving 40 records from a DB. It doesn't look a big amount, does it? Well, the records are not that little, but my experience on haskell still is :) Enrico

1 0

RE: ghc HEAD 'make html' problems
by Simon Marlow 02 Feb '05

02 Feb '05

On 01 February 2005 23:59, Peter Simons wrote: > Simon Marlow writes: > > > This was due to a bug in GHC introduced a few days ago > > and fixed yesterday. Please try again. > > I have tried again moments ago: same problem. Sorry, should be fixed now. Cheers, Simon

1 0

RE: ghc HEAD 'make html' problems
by Simon Marlow 01 Feb '05

01 Feb '05

On 01 February 2005 10:33, Ben Horsfall wrote: > On 01 Feb 2005 10:32:14 +0100, Peter Simons <simons(a)cryp.to> wrote: >> I can't build the library's Haddock documentation anymore: >> the process fails claiming that Control/Arrow-raw.hs would >> be missing. I've had this problem for a while now. Does >> anybody else see this? > > Yes, I do too. No solution, but observe that if you do this: > > cd libraries/base > make Control/Arrow-raw.hs > > No Arrow-raw.hs file is created, although there is no error either. This was due to a bug in GHC introduced a few days ago and fixed yesterday. Please try again. Cheers, Simon

2 1

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 01 Feb '05

01 Feb '05

On 01 February 2005 11:31, ross(a)soi.city.ac.uk wrote: > On Tue, Feb 01, 2005 at 11:02:45AM -0000, Simon Marlow wrote: >> I'm making some changes to the way Haddock creates links, and I'd >> like to solicit comments on possible alternatives. >> >> The existing approach is for each non-locally-defined identifier in >> the current module, we hyperlink to a module that it was imported >> from, and that (a) actually documents the identifer, and (b) isn't >> hidden. >> >> [...] >> >> So the new approach is to try to build up a global table of the >> "best" destinations to link to for each entity. The question is how >> to determine "best". Here's my first stab: >> >> - A is better than B if A directly or indirectly imports B > > Perhaps it should be the other way round: the lowest non-hidden module > that exports the name (if more than one such, fix on one). This would > need most of GHC.* hidden, which is desirable anyway. Yes, maybe that's better, but it's not enough on its own. For example, GHC.Exts exports Int, but there's no relationship between Prelude and GHC.Exts in the import hierarchy - so how do we determine which one is better? (GHC.Exts shouldn't be hidden, BTW. The rest of GHC.* probably should.) Cheers, Simon

2 1