August 2004 - Glasgow-haskell-users

overzealous defaulting?
by Abraham Egnor 23 Aug '04

23 Aug '04

I'm not sure if this is an actual bug, as opposed to an odd instance of defaulting: *GUI.Parser> let printQ q = runQ q >>= print *GUI.Parser> :t printQ printQ :: forall a. (Show a) => Q a -> IO () *GUI.Parser> let p = printQ *GUI.Parser> :t p p :: Q Integer -> IO () ...but I'm not sure when that would ever be the correct behavior. Abe

1 0

RE: profiling for 6.2.2
by Simon Marlow 23 Aug '04

23 Aug '04

On 21 August 2004 11:59, Serge D. Mechveliani wrote: > Dear GHC developers, > > I recall that there is also desirable to have in the official > ghc-6.2.2 > a reliable pro-filing > (for the time cost centers, for -O). Do you have outstanding bug reports for profiling in 6.2.1? I'm not aware of any, apart from one report that possibly retainer profiling has some problems, which I plan to look into. If you know of any specific issues, please let us know. Profiling is quite a large subsystem, and just saying "it's not reliable" doesn't give us much to go on. Cheers, Simon

1 0

profiling for 6.2.2
by Serge D. Mechveliani 21 Aug '04

21 Aug '04

Dear GHC developers, I recall that there is also desirable to have in the official ghc-6.2.2 a reliable pro-filing (for the time cost centers, for -O). Although I do not test it right now, and skipping it would not cause a tragedy for me, it still will be nice if you arrange this in ghc-6.2.2. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: cvsweb back up
by Simon Marlow 20 Aug '04

20 Aug '04

On 20 August 2004 14:08, Gracjan Polak wrote: > > On 20 August 2004 12:04, Gracjan Polak wrote: > > > > > >>Is there any haddoc documentation for GHC (compiler part, not > >>libraries)? I still have trouble finding my way through the > source... > > > > > Sorry, no. You could probably run Haddock on the source, although > we've > never tried and there isn't any actual documentation. > > I did want to do this myself, but I did not manage to compile haddoc > under Windows :(. > > Is there anybody having pre-build haddoc for windows? Or guide how to > do this myself? The 0.6 release wasn't particularly easy to build/use on Windows, but improvements have been made since then. The next release will be better. Cheers, Simon

1 0

RE: getDirectoryContents fails under Windows
by Simon Marlow 20 Aug '04

20 Aug '04

On 07 August 2004 12:20, Krasimir Angelov wrote: > The getDirectoryContents function from CVS sources > fails under Windows. It seems like in the > __hscore_end_of_dir function from HsBase.h should > return 0 under Windows and ENOENT under other > platforms. Could you elaborate? getDirectoryContents appears to work fine on my HEAD build, and __hscore_end_of_dir does indeed work as you suggest. Cheers, Simon

1 0

RE: prebuilt Haddock for Windows
by Bayley, Alistair 20 Aug '04

20 Aug '04

I have one, although I'm not sure how best to get it to you. I don't have a website, but if you point me to an ftp site I could upload it. Or I could try emailing you a zip file... It's not hard to build, but I did it with Cygwin installed - I don't know if you have this. > -----Original Message----- > From: Gracjan Polak [mailto:gracjan@student.uci.agh.edu.pl] > Sent: 20 August 2004 14:08 > To: Simon Marlow > Cc: glasgow-haskell-users(a)haskell.org > Subject: Re: cvsweb back up > > > > Simon Marlow wrote: > > > On 20 August 2004 12:04, Gracjan Polak wrote: > > > > > >>Is there any haddoc documentation for GHC (compiler part, > not >>libraries)? I still have trouble finding my way > through the source... > > > > > > Sorry, no. You could probably run Haddock on the source, > although we've > never tried and there isn't any actual > documentation. > > I did want to do this myself, but I did not manage to compile > haddoc under Windows :(. > > Is there anybody having pre-build haddoc for windows? Or > guide how to do this myself? > > > There's the > > commentary which may help: > > > > http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ > > > > Thanks, I'm going to read it :) > > > Cheers, > > Simon ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

cvsweb back up
by Simon Marlow 20 Aug '04

20 Aug '04

Thanks to Jeff Lewis, we now have cvsweb back up again. Browse on over to http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ and enjoy! Cheers, Simon

3 2

RE: cvsweb back up
by Simon Marlow 20 Aug '04

20 Aug '04

On 20 August 2004 12:04, Gracjan Polak wrote: > Is there any haddoc documentation for GHC (compiler part, not > libraries)? I still have trouble finding my way through the source... Sorry, no. You could probably run Haddock on the source, although we've never tried and there isn't any actual documentation. There's the commentary which may help: http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ Cheers, Simon

2 1

RE: Space usage
by Simon Peyton-Jones 20 Aug '04

20 Aug '04

I had a look at this. It's an old chestnut: lazy pattern matching. You have let ((commands, s), x) = run (read iters) 5 in do ...do something with commands... print x Trouble is, the 'x' hangs onto both components of the pair, even though it only needs one. It's not enough to force the pair earlier, which you probably tried, because the state monad you are using is itself lazy, and uses masses of lazy pattern matching. You could return the state paired with each item, rather than just the state at the end, perhaps, or use a stricter state monad. This lazy-pattern-matching leak is a well-known problem, to which I do not know a good solution. There was a paper from Chalmers about 8 years ago about building more cleverness into the compiler, but it amounted to extending Core with a lazy tuple binding. Fair enough, but quite a big addition to Core and one I've never done. better ideas welcome simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 12 June 2004 18:54 | To: glasgow-haskell-users(a)haskell.org | Subject: Space usage | | | Hi all, | | My intuition tells me that the code in | | http://urchin.earth.li/~ian/Mem.hs | | should have the same space usage regardless of whether USESMEM is | defined. However, when compiling with | | ghc -Wall -O2 -cpp --make Mem -o mem | | and running | | ./mem True 100000 > /dev/null | | it runs in constant space but compiling with | | ghc -Wall -O2 -cpp -DUSESMEM --make Mem -o mem | | and running in the same way it increases up to >100M. | | Is this an instance of GHC not being as smart as it could? | | Or is it a case in which I need to give it additional strictness | annotations in order to get it to run in constant space (and if so, | what annotations would be best?)? | | | Thanks | Ian | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 4

RE: [Haskell] GHC writes to stderr
by Simon Marlow 19 Aug '04

19 Aug '04

[ redirected to glasgow-haskell-users(a)haskell.org ] On 19 August 2004 08:32, Georg Martius wrote: > I am just wondering why ghc writes its output to stderr instead of > stdout. In case of an error it might be reasonably but all the > ordinary information about chaising and stuff should go to a buffered > stream I think. > > Why do I care? > I start ghc from emacs in a compile window. The output gets displayed > and in the case of an unbuffered output the display gets updated for > every single character. I don't have to tell you how slow that is. Yes, at some point we need to clean up GHC's messages and make sure they're all going to the right place. One issue is that if you write some messages to stdout and some to stderr, the order gets permuted randomly, which sometimes isn't what you want. Cheers, Simon

1 0