- Glasgow-haskell-users

RE: Character index vs Column number in GHC error messages
by Simon Marlow 13 Sep '05

13 Sep '05

On 12 September 2005 22:39, Krasimir Angelov wrote: > 2005/9/12, Simon Marlow <simonmar(a)microsoft.com>: >> GNU CPP reports the column number, not the char index, AFAICT. Try >> the attached file. > > CPP returns the following error for the attached file: > > ctest22.c:3:13: macro "undefined" requires 2 arguments, but only 1 > given undefined; > > 13 is exactly the index of the closing paren. In the same time, with > tab size 4, the 13-nth column is at the character 'd' from > "undefined". > > I am using CPP version 3.4.4 > > $ cpp --version > cpp (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. Interesting - this behaviour changed around GCC 3.4 it seems. One other small piece of evidence is that Emacs' C-x = command returns a column number, not a char index. Ok, given that most of the world seems to want char indices (or doesn't care), I'm happy for GHC to report char indices. Cheers, Simon

1 0

RE: Profiling question
by Simon Marlow 13 Sep '05

13 Sep '05

On 12 September 2005 22:59, J. Garrett Morris wrote: > (apologies for the previous attempt at this message) > > I'm attempting to profile a project spread over four or five modules, > each compiled using cabal with the --enable-library-profiling and > --enable-executable-profiling switches. The resulting profiles > include all function calls for several of the modules, but one of the > others is mysteriously never mentioned, despite definitely having been > called. Is there some reason module (compiled with profiling) would > be excluded from the final report? Not that I can think of, unless for some reason that module didn't get compiled with -auto-all? Cheers, Simon

1 0

Profiling question
by J. Garrett Morris 12 Sep '05

12 Sep '05

(apologies for the previous attempt at this message) I'm attempting to profile a project spread over four or five modules, each compiled using cabal with the --enable-library-profiling and --enable-executable-profiling switches. The resulting profiles include all function calls for several of the modules, but one of the others is mysteriously never mentioned, despite definitely having been called. Is there some reason module (compiled with profiling) would be excluded from the final report? /g

1 0

Profiling question
by J. Garrett Morris 12 Sep '05

12 Sep '05

Hello, I'm attempting to track down time usage in a project, spread over four or five modules. I've compiled them all with profiling (using cabal with the --

1 0

RE: Character index vs Column number in GHC error messages
by Simon Marlow 12 Sep '05

12 Sep '05

On 31 August 2005 07:55, Krasimir Angelov wrote: > Quite recently GHC was changed to display the column number as well as > the line number in all error messages. This is useful feature but I > found the following difficulty with using it. All text editors that > have built-in support for compilers, expect to find the line number in > the reported error messages. Some of them support column number as > well, but actually this isn't the column number but the character > index in the current line. The difference comes from the tab > characters which can have different width depending from the editor > settings. For such reason all compilers, which I am aware of, display > the character index instead of column number. I tried this with C#, > Visual Basic and GNU CPP. GNU CPP reports the column number, not the char index, AFAICT. Try the attached file. > GCC, Sun's Java compiler and Visual C++ > compiler are displaying only the line number. Using the character > index the editor can unambiguously find the exact position where the > error is independently from the current tab setting. GHC displays the > column number instead and this confuses the editors. At least I tried > this with Visual Studio and TextPad editor. I have modified the GHC > parser so that it displays the character index instead of column > number, but I am curious whether this is the preferred behaviour of > the other compilers/editors. Any thoughts are appreciated. Can I see your patch? Remember that GHC has to calculate the column number for the purposes of implementing layout correctly, even if it only reports char indices in error messages. If possible, I'd like to make the behaviour configurable via a command-line switch. The neatest way to do this would be to confine the changes to the lexer, and to have all SrcLocs contain either column numbers or char indices from the parser onwards (instad of trying to retain enough information to provide both). This means the lexer will have to retain additional information about column positions, probably another integer representing the number of tabbed columns. Cheers, Simon

2 1

RE: Accessing new heap costs more than old?
by Simon Marlow 12 Sep '05

12 Sep '05

On 05 September 2005 19:38, Adrian Hey wrote: > On Monday 05 Sep 2005 5:42 pm, Jan-Willem Maessen wrote: >> This agrees with my theory. > > Thanks, I'm sure this must be the explanation. I guess the moral of > the story is that for comparative benchmarks you really do need to > make sure you're comparing like with like. Very small differences in > test method can have a significant impact on running time it seems. Can you confirm the hypotheses by inspecting the output from +RTS -sstderr, which tells you the breakdown of GC vs. mutator time? Cheers, Simon

2 1

RE: profile not showing it all?
by Simon Marlow 12 Sep '05

12 Sep '05

On 09 September 2005 15:58, Niels wrote: > Bulat Ziganshin wrote: >> i don't know what value shows the -xc oprion, but memory usage in >> ghc-compiled program are increased because by default used "copying" >> garbage collection algorithm. using option "+RTS -c" will >> significantly reduce memory usage, which will make program faster if >> it currently needs swapping. you can also force, for example, using >> of compacting algorithm when memory usage grows more than 200 mb with >> options "+RTS -M1G -c20". see "4.14.2. RTS options to control the >> garbage collector" in ghc docs for details > running the profilingbinary (that was compiled with -prof -auto-all) > with the -c option resulted in; > > top: showing a max of 161mb memory usage > profiled-graph: showing a peak at a little more than 80mb > > i guess these results are more or less normal? It does however mean > that my datastructures are pretty harsh on the garbage collector, > doesnt it? The difference between the residency displayed by the heap profiler and the actual memory residency can be attributed to several factors (some of which have already been mentioned, I thought I'd list them for completeness): - overhead of profiling itself, which currently runs at 2 extra words per heap object. At a guess, that probably results in about a 30% overhead. - generational garbage collection. A major GC in the standard copying collector will usually require 3L bytes of memory, where L is the amount of live data. This is because by default (see the +RTS -F option) we allow the old generation to grow to twice its size (2L) before collecting it, and we require additionally L bytes to copy the live data into. When using compacting collection, this is reduced to 2L, and can further be reduced by tweaking the -F option. Additionally the allocation area (generation 0) takes 512Kb by default. - The stack isn't counted in the heap profile by default. See the +RTS -xt option. - The program text itself, the C stack, any non-heap data (eg. data allocated by foreign libraries, and data allocated by the RTS), and mmap()'d memory are not counted in the heap profile. Cheers, Simon

2 2

GHC 6.4 for a Debian distro
by Iavor Diatchki 12 Sep '05

12 Sep '05

Hello, I would like to install the following tools on a Debian Linux distribution (testing flavor): GHC 6.4, alex, happy, darcs (I use Hugs from CVS, so I don't want to install the Debian version) I would also like to be able to update/remove any one of these tools independently (I know enough about the tools to know that they do not need each other to work). Can I achieve this by using debian packages? I can get darcs, happy, and alex to work, but the only GHC 6.4 package I could find (in unstable) conflicts with the others. It also seems to depend on Hugs for some reason. I was able to get a working GHC 6.4 by using "alien" on the Fedora RPMs, but this seems like a rather embarassing (for the Debian distro) solution. Am I doing something wrong here? -Iavor

2 1

RE: .hc files for building ghc-6.4 on amd64 ?
by Simon Marlow 12 Sep '05

12 Sep '05

On 06 September 2005 15:33, Wilhelm B. Kloke wrote: > I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who > can give me a set of .hc files (probably from linux x86_64) to build > GHC? I tried to follow the instructions to crossbuild from > FreeBSD-i386, > but my attempts failed for reasons I don't understand. I have an account on a box, but haven't yet had time to do the port. If you let us know where your build got stuck, we might be able to help you out. Cheers, Simon

2 1

RE: Profiling and analysing space usage
by Simon Marlow 12 Sep '05

12 Sep '05

On 02 September 2005 17:09, Bulat Ziganshin wrote: > Hello Alistair, > > Thursday, September 01, 2005, 6:36:09 PM, you wrote: > >> The heap profile graph for this program shows an initial peak, and >> then the graph is flat at 8Mbytes, which I think is the space >> allocated to the two STArrays (2 arrays, 1 million chars each, 4 >> bytes per char?). So it looks as though any allocation for the loop >> function is GC'd very soon after it's allocated. > > Char uses 4 bytes because it must hold any Unicode character, which is > about 1 million :) use Word8 or CChar STArray is a lazy array, which means that each element of the array is a pointer to another closure. However, the reason you only see 4 bytes per character is because GHC has a static table for Char values < 256, so all the characters end up being shared, and you're left with 4 bytes per char for the pointers, at least when all the array elements are evaluated. Interestingly, a fully evaluated STArray Char takes the same amount of dynamic space as an STUArray Char. It is slower to access, though. Cheers, Simon

1 0