February 2005 - Glasgow-haskell-users

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

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

01 Feb '05

On 01 February 2005 12:48, Ketil Malde wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> There are some problems with the existing approach. It doesn't cope >> well with instances: instances might refer to types/classes not below >> the current module in the hierarchy. Also you might import an entity >> from a "hidden" module, but actually want to hyperlink to another >> module > >> Thoughts? Better ideas? > > If it turns out to be difficult to determine where to link, one option > could be to link to a separate table on the same page, listing the > candidates? Hmm, I'm not sure that would be practical. Lots of entities are exported from more than one place, especially Prelude entities. You'd have a table on almost every single page listing Bool, Maybe, Int, etc. You could link to the index, I suppose - that lists all the places you can get a particular entity. I'm not sure you want to make two clicks to follow a link every time though. Cheers, Simon

2 1

ghc HEAD 'make html' problems
by Peter Simons 01 Feb '05

01 Feb '05

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? Peter

2 1