- Glasgow-haskell-users

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

07 Feb '05

On 02 February 2005 14:39, Glynn Clements wrote: > Simon Marlow wrote: >> 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. > > As it stands, you can have whatever behaviour you want in the parent: > set the desired handling before calling system/rawSystem/runProcess > then set it back afterwards. > > However, this will cease to be true for system/rawSystem if you change > them so that the child restores the handlers to their state upon > entry. I don't understand... is there a typo somewhere above? Perhaps you meant "child" in the first paragraph? system/rawSystem now behave almost exactly like system() in C. The only difference is that you can't ignore SIGINT/SIGQUIT in the child, but I can fix that if necessary. Cheers, Simon

2 1

RE: Unboxed Tuples
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

| Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? It depends if the "..." is strict in 'p' or 'q'. If not, no it won't get optimised away, and rightly so. Exmape f x = let (p,q) = case h x of (# p,q #) -> (p,q) in (q,p) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Adrian Hey | Sent: 07 February 2005 13:03 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: Re: Unboxed Tuples | | On Monday 07 Feb 2005 9:28 am, Simon Peyton-Jones wrote: | > Good point. Yes you can rely on it; but the binding is lazy. So for | > this | > | > h :: Int -> (# String, String #) | > h = ... | > | > | > f x = let (# p,q #) = h x in ... | > | > you'll get | > | > f x = let (p,q) = case h x of (# p,q #) -> (p,q) | > in ... | > | > So the call to h only happens when either p or q is used. | > | > On the other hand, if any of the binders in a let-pattern has an | > unlifted type (e.g. Int#) then the whole pattern match becomes strict. | > So if p or q had an unlifted type, the match would be strict. | > | > I'll add a note to the usre manual. | | Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? | | I guess the answer must be yes in the second case because AFAIK | you can't build an ordinary tuple containing an Int#. (But maybe | I'm wrong.) | | Regards | -- | Adrian Hey | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Unboxed Tuples
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

Good point. Yes you can rely on it; but the binding is lazy. So for this h :: Int -> (# String, String #) h = ... f x = let (# p,q #) = h x in ... you'll get f x = let (p,q) = case h x of (# p,q #) -> (p,q) in ... So the call to h only happens when either p or q is used. On the other hand, if any of the binders in a let-pattern has an unlifted type (e.g. Int#) then the whole pattern match becomes strict. So if p or q had an unlifted type, the match would be strict. I'll add a note to the usre manual. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Adrian Hey | Sent: 13 January 2005 11:55 | To: glasgow-haskell-users(a)haskell.org | Subject: Unboxed Tuples | | Hello, | | Does the user guide documentation for these reflect current ghc compiler? | | Para. 7.2.2 says they can only be deconstructed using case expressions | but by accident I've found they seem to work fine in let bindings too | (with ghc version 6.2.2). | | Not that I'm complaining (I always thought using case expressions was | just too painful :-). I just wanted to check that this is a feature | I can rely on in future (and if so suggest the user guide should be | ammended to reflect this). | | Regards | -- | Adrian Hey | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: STM check/MonadPlus
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

Thanks for the typo. Yes, for Haskell guys 'guard' is fine; but the main audience for the paper is non-haskell folk, so we have to spell out the defn. S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Remi Turk | Sent: 06 February 2005 20:25 | To: glasgow-haskell-users(a)haskell.org | Subject: STM check/MonadPlus | | Hi, | | I have a few questions about the `check' function from | Control.Concurrent.STM. | | First, in the paper its definition contains a (type) error: | | check :: Bool -> STM a | check True = return () | check False = retry | | in fptools, however, it is defined as follows: | | check :: Bool -> STM a | check b = if b then return undefined else retry | | As we already have guard, and STM is an instance of MonadPlus, | I wonder why such a simple utility function as check is wanted | at all. | | guard :: (MonadPlus m) => Bool -> m () | guard True = return () | guard False = mzero | | Greetings, | Remi | | -- | Nobody can be exactly like me. Even I have trouble doing it. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

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

07 Feb '05

On 02 February 2005 18:42, Duncan Coutts wrote: > On Wed, 2005-02-02 at 17:01 +0000, Simon Marlow wrote: >> On 02 February 2005 13:38, Duncan Coutts wrote: >>> 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] ] >>> >> >> 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. > > Ok, attached it the -ddump-prep for the version using pixbufSetGreen, > and another file for the longer more complicated one which is using > setWierdColour. Both versions do contain 'let's. > > I've also attached the original code. (which you won't be able to > build without hacking the gtk bits out of it) I took a quick look at this, and one thing I noticed is that some deforestation isn't happening. There is still an explicit [0..127] being constructed/deconstructed. I don't think we'll be able to investigate this right now, so if you need performance immediately I suggest you rewrite the code using explicit recursion. Cheers, Simon

1 0

STM check/MonadPlus
by Remi Turk 06 Feb '05

06 Feb '05

Hi, I have a few questions about the `check' function from Control.Concurrent.STM. First, in the paper its definition contains a (type) error: check :: Bool -> STM a check True = return () check False = retry in fptools, however, it is defined as follows: check :: Bool -> STM a check b = if b then return undefined else retry As we already have guard, and STM is an instance of MonadPlus, I wonder why such a simple utility function as check is wanted at all. guard :: (MonadPlus m) => Bool -> m () guard True = return () guard False = mzero Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it.

1 0

installing current binary distribution
by Alain Cremieux 04 Feb '05

04 Feb '05

> > >Hi, > >I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to find >out that gcc-3.4.1 seems to be hard-wired into this ghc: > >ghc-6.3.20050202: could not execute: gcc-3.4.1 > >Why is this so. Do I need to install from sources? My current gcc >version is: > >gcc (GCC) 3.3.1 (SuSE Linux) > >Cheers Christian > > > I had this problem once, and solved it simply by creating a symbolic link gcc-3.4.1 towards my version of gcc (3.2.2), and everything worked OK. Alain > ------------------------------------------------------------------------

1 0

RE: installing current binary distribution
by Simon Marlow 04 Feb '05

04 Feb '05

On 04 February 2005 12:23, Christian Maeder wrote: > I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to > find out that gcc-3.4.1 seems to be hard-wired into this ghc: > > ghc-6.3.20050202: could not execute: gcc-3.4.1 > > Why is this so. Do I need to install from sources? My current gcc > version is: > > gcc (GCC) 3.3.1 (SuSE Linux) This is because we currently configure the nightly builds to use gcc-3.4.1, and unfortunately that gets baked into the GHC binary. You can compile from source to get around this. The STABLE snapshots don't have this problem. Cheers, Simon

2 2

installing current binary distribution
by Christian Maeder 04 Feb '05

04 Feb '05

Hi, I've installed ghc-6.3.20050202-i386-unknown-linux.tar.bz2 only to find out that gcc-3.4.1 seems to be hard-wired into this ghc: ghc-6.3.20050202: could not execute: gcc-3.4.1 Why is this so. Do I need to install from sources? My current gcc version is: gcc (GCC) 3.3.1 (SuSE Linux) Cheers Christian

1 0

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

04 Feb '05

On 02 February 2005 12:22, Ross Paterson wrote: > On Tue, Feb 01, 2005 at 11:02:45AM -0000, Simon Marlow wrote: >> So the new approach is to try to build up a global table of the >> "best" destinations to link to for each entity. > > Having a canonical home location for each entity might also help with > another bugbear with Haddock: determining whether two unqualified > names refer to the same entity. This is impossible at present > because Haddock doesn't show qualified names (because doing so would > be too cumbersome) and anyway the defining module is often hidden. > It's not clear which of the documented catch functions are > Control.Cuncurrent.catch, and which are System.IOError.catch. With > the new scheme, documentation for an entity in a module other than > its home could include a cross-reference to its home. This is a good idea, I've put it on the TODO list. Cheers, Simon

1 0