- Glasgow-haskell-users

RE: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by Simon Marlow 25 Jan '05

25 Jan '05

They're already tagged with [ ghc-Feature ..... ]. Is that ok? Cheers, Simon ________________________________ From: Seth Kurtzberg [mailto:seth@cql.com] Sent: 24 January 2005 23:45 To: Simon Marlow Cc: Ketil Malde; glasgow-haskell-users(a)haskell.org Subject: Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage I would prefer to keep them on the list. There are already a number of different lists, and (of course IMO) I can't see a need to read _only_ feature requests, so why separate them? Adding a tag to the email that would let maildrop or procmail deliver it to a different folder would be a nice solution; those who want the current situation would do nothing, and those who would prefer not to see those messages can add a simple rule to maildrop. (I hesitate to use "procmail" and "simple" in the same sentence, but it presumably wouldn't be terribly difficult there either.) Simon Marlow wrote: On 18 January 2005 14:42, Ketil Malde wrote: I seem to be getting messages from Sourceforge from this mailing list. Is that an intended use for ghc-users? It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, cvs-ghc@haskell.org? Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:41f13d8a187771680466285!

1 0

RE: profiling usage
by Simon Marlow 25 Jan '05

25 Jan '05

On 24 January 2005 09:11, Serge D. Mechveliani wrote: > --------------------------------------------------------------------- > Mon Jan 24 10:30 2005 Time and Allocation Profiling Report (Final) > > a.out +RTS -M40m -p -RTS > > total time = 9.04 secs (452 ticks @ 20 ms) > total alloc = 1,047,303,220 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > > nubCommut Prelude5 90.0 88.8 > isReducibleAtTop Reduce 9.1 9.8 > > individual inherited > COST CENTRE MODULE no. entries %time %alloc %time %alloc > > MAIN MAIN 1 0 0.0 0.0 100.0 100.0 > CAF Main 242 3 0.0 0.0 0.0 0.0 > ... > ... > operatorOccurs Prelude3 250 19526 0.0 0.2 0.0 0.2 > concat in nextTermLevel Prelude5 249 183 0.0 0.2 98.7 98.1 > isReducibleAtTop Reduce 257 4525 8.4 9.0 8.4 9.0 > orderIfCommut Prelude5 256 7052 0.2 0.1 0.2 0.1 > nubCommut Prelude5 255 4582 90.0 88.8 90.0 88.8 > vectorsOfDepthOfSorts Prelude5 251 379 0.0 0.0 0.0 0.0 > vectorsUnderDepthOfSorts Prelude5 254 260 0.0 0.0 0.0 0.0 > isReducibleAtTop Reduce 248 314 0.6 0.8 0.6 0.8 > ------------------------------------------------------------------------ - > > 1. There was set a single point of {-# SCC "isReducibleAtTop" #-}. > Why the report prints the two different lines for it? > What is the meaning of such duplication? You removed the indentation, which was there to indicate the call nesting. A cost centre that appears more than once indicates that it was called in two places in your program (or called with two different lexical call stacks, to be precise). > 2. It prints six number columns instead of 5 explained in the > User Guide 5.00 (I am looking into now). > The second column looks new. What does it mean? The first column is the new one. It is just an integer identifier for each cost centre stack. I can't remember why we added it to the profile (probably something to do with relating this output to heap profiles). > 3. Consider the line > "concat in nextTermLevel" Prelude5 249 183 0.0 0.2 98.7 98.1 > > This center was set in the following style: > ... > Just class_s -> {-# SCC "concat in nextTermLevel" #-} > concat > [ofTop f | f <- ops, coarity f == s .. ] > where > ofTop f = ... > ... > nubCommut (t:ts) = {-# SCC "nubCommut" #-} ... > > Now, the line meaning is as follows. > (a) This center was entered 249 times. > (b) What does this mean 183 ? entered 183 times, I think. > (c) This very point itself takes almost zero time. > (d) The computation tree below this point (caused by this call) > takes 98.7% of the total time. > Right? Yes > The `nubCommut' call is the part of the tree below > "concat in nextTermLevel". And its line shows that it takes 90% > by itself. > So, the main expense is by nubCommut, and the rest of > "concat in nextTermLevel" adds about 9% to it. These 9% include, > in particular, the cost of the (++) calls. > Right? Yes, I think so (but you removed the indentation, so I can't tell for sure). Cheers, Simon

1 0

RE: Problem with handles in GHC from CVS
by Simon Marlow 25 Jan '05

25 Jan '05

On 24 January 2005 04:31, Wolfgang Thaller wrote: >> It seems they should always be flushed. certainly if a program fails >> via 'fail' in IO or 'error' as these are common ways for programs to >> report an error and losing output would definitly be counter >> intuitive and make it quite tricky to debug. especially when you >> can't flush stdout before calling error. I would think it should >> flush all buffers on any type of exit. > > I agree (after thinking about it again). Done. They were supposed to be flushed always; it was a braino on my part. Thanks for fixing it. Cheers, Simon

1 0

GHC on Arm
by John Goerzen 25 Jan '05

25 Jan '05

Hello, I would like to port GHC to Arm so that I can compile Haskell programs for use on my Zaurus or in Debian's ARM port. I have talked to Ian Lynagh about this, and he believes that there was some sort of problems with floats. I don't know exactly that was, if it was in gcc or ghc, or if it has been fixed. Does anybody have some light to shed on this? Also, does anybody have any ARM binaries of ghc to ease the bootstrapping pain? Thanks!

2 2

RE: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by Simon Marlow 24 Jan '05

24 Jan '05

On 18 January 2005 14:42, Ketil Malde wrote: > I seem to be getting messages from Sourceforge from this mailing > list. Is that an intended use for ghc-users? It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, cvs-ghc@haskell.org? Cheers, Simon

3 2

Re:'ghc --version' problem
by Alson Kemp 24 Jan '05

24 Jan '05

># ghc-6.3.3 --version > conftest ># cat conftest > [conftest is empty] Just updated my source and this works now. This was a dup of Krasimir's problem anyway. - Alson

1 0

'ghc --version' problem
by Alson Kemp 24 Jan '05

24 Jan '05

I was just trying to compile a package using ghc-6.3.3 and came up against a problem with the '--version'flag. Specifically, I don't think that 'ghc-6.3.3 --version' doesn't report the version to stdout. # ghc-6.3.3 --version > conftest # cat conftest [conftest is empty] #ghc-6.2 --version > conftest # cat conftest The Glorious Glasgow Haskell Compilation System, version 6.2.2 I've looked through ghc/compiler/main/DriverFlags.hs, but both older and newer versions seem to report --version through stdout, so I'm not sure where the problem is. - Alson

1 0

adventure with profiling
by Serge D. Mechveliani 24 Jan '05

24 Jan '05

The pro-filing has proved its power once more. My complex program has a fragment which generates many arithmetical expressions, filtering out `reducible' ones and nub-bing them with respect to the commutativity of some operators. I expected the `reducible' test to take most of the cost. But the whole program has taken suspiciousely long. The profiling showed that nub_by_commutatitvity (nub) takes 10 times more than the `reducible' test. It was hard to discover this without profiling, because the program has many places to suspect. Then, I tried for this fragment (setToList . mkSet) instead of nub ! The whole test has become faster 8 times! `nub-like' reduced to 0.01; the `reducible' test takes 3/4, as it was initially expected. Quite an adventure. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

profiling usage
by Serge D. Mechveliani 24 Jan '05

24 Jan '05

Dear GHC experts, I have questions about the profiling usage in ghc-6.2.2. I have set {-# SCC .. #-} at several points in my large program. The report in a.out.prof is (I have re-formatted it, for the lines were too long) --------------------------------------------------------------------- Mon Jan 24 10:30 2005 Time and Allocation Profiling Report (Final) a.out +RTS -M40m -p -RTS total time = 9.04 secs (452 ticks @ 20 ms) total alloc = 1,047,303,220 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc nubCommut Prelude5 90.0 88.8 isReducibleAtTop Reduce 9.1 9.8 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 CAF Main 242 3 0.0 0.0 0.0 0.0 ... ... operatorOccurs Prelude3 250 19526 0.0 0.2 0.0 0.2 concat in nextTermLevel Prelude5 249 183 0.0 0.2 98.7 98.1 isReducibleAtTop Reduce 257 4525 8.4 9.0 8.4 9.0 orderIfCommut Prelude5 256 7052 0.2 0.1 0.2 0.1 nubCommut Prelude5 255 4582 90.0 88.8 90.0 88.8 vectorsOfDepthOfSorts Prelude5 251 379 0.0 0.0 0.0 0.0 vectorsUnderDepthOfSorts Prelude5 254 260 0.0 0.0 0.0 0.0 isReducibleAtTop Reduce 248 314 0.6 0.8 0.6 0.8 ------------------------------------------------------------------------- 1. There was set a single point of {-# SCC "isReducibleAtTop" #-}. Why the report prints the two different lines for it? What is the meaning of such duplication? 2. It prints six number columns instead of 5 explained in the User Guide 5.00 (I am looking into now). The second column looks new. What does it mean? 3. Consider the line "concat in nextTermLevel" Prelude5 249 183 0.0 0.2 98.7 98.1 This center was set in the following style: ... Just class_s -> {-# SCC "concat in nextTermLevel" #-} concat [ofTop f | f <- ops, coarity f == s .. ] where ofTop f = ... ... nubCommut (t:ts) = {-# SCC "nubCommut" #-} ... Now, the line meaning is as follows. (a) This center was entered 249 times. (b) What does this mean 183 ? (c) This very point itself takes almost zero time. (d) The computation tree below this point (caused by this call) takes 98.7% of the total time. Right? The `nubCommut' call is the part of the tree below "concat in nextTermLevel". And its line shows that it takes 90% by itself. So, the main expense is by nubCommut, and the rest of "concat in nextTermLevel" adds about 9% to it. These 9% include, in particular, the cost of the (++) calls. Right? Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Problem with handles in GHC from CVS
by Krasimir Angelov 23 Jan '05

23 Jan '05

Cabal uses something like system "ghc --version >tmp" in order to determine the version of GHC. After the last changes in CVS the above line no longer produces the right result. The temporary file is created but it is empty. It seems like the stdout/stderr handles are flushed in GHC.TopHandler.runMainIO but only if the program terminates without exception. I tried to flush handles in the catch clause but this doesn't help. Any ideas? Cheers, Krasimir

3 3