September 2005 - Glasgow-haskell-users

FFI: calling Haskell from C++?
by Felix Breuer 13 Sep '05

13 Sep '05

Hello everyone, we have tried long and hard to call Haskell functions from C++ using the FFI mechanism but without success. Our problem is as follows: We tried the C case first. Taking the example code from Chapter 8.2 of the GHC User Guide, we created files Foo.hs and main.c and then did $ ghc -fffi -c Foo.hs /tmp/ghc28407.hc: In function `__stginit_Foo_': /tmp/ghc28407.hc:278: warning: implicit declaration of function `getStablePtr' $ ghc -fffi Foo. Foo.hi Foo.hs Foo.o $ mv main.cpp main.c $ ghc -fffi Foo.o Foo_stub.o main.c $ ./a.out 2500 2500 2500 2500 2500 which worked fine. But when we simply rename main.c -> main.cpp, then $ ghc -fffi Foo.o Foo_stub.o main.cpp main.o(.text+0x22): In function `main': main.cpp: undefined reference to `__stginit_Foo()' main.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status We tried many different options to ghc and also using g++ directly, all to no avail. It would be really great if someone could shed some light on this. For convenience, we have attached Foo.hs and main.cpp. Thanks, Felix

4 4

6.4.1 update
by Simon Marlow 13 Sep '05

13 Sep '05

Hi Folks, I'm back, and it's high time we released 6.4.1. The bug reports keep on rolling in, but I think there are only a few blockers and the rest can be pushed back to 6.4.2 (long gone are the days when we used to be able to claim that all outstanding bugs have been fixed!). I'll set a tentative release date for next Monday (19 Sept). If there's anything still broken in the release candidate that is really holding you up, please let us know (unless I've already sent an email about it in the last couple of days in which case it'll be paged in). Things I hope to look into before the release: - building GHC with an upgraded Cabal (Duncan Coutts) - crashes when compiling Pugs (Gaal Yahas) - scavenge_stack crash (Jason Dagit) Cheers, Simon

1 0

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