- Glasgow-haskell-users

RE: CVS Repository
by Simon Marlow 14 Sep '05

14 Sep '05

On 14 September 2005 11:51, Peter Simons wrote: > I understand the GHC CVS repository has moved recently? It > appears that the document > > http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html > > hasn't been updated accordingly; could someone with CVS > commit access please fix that? I've updated it in CVS, a new version will get uploaded with the 6.4.1 release. Cheers, Simon

1 0

CVS Repository
by Peter Simons 14 Sep '05

14 Sep '05

Hi, I understand the GHC CVS repository has moved recently? It appears that the document http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html hasn't been updated accordingly; could someone with CVS commit access please fix that? Thanks, Peter

1 0

Strictness annotations question
by Adrian Hey 14 Sep '05

14 Sep '05

Hello, One thing I discovered a while ago when fiddling about with optimisting the AVL library was that making the AVL constructors strict in left and right sub-tree fields resulted in slower code than using no strictness annotation and explicit forcing of evaluation with `seq`. I hope it isn't too presumptious of me to hazard a guess as to what might cause this :-) My guess is that it's because the AVL code contains a lot of stuff like this.. -- With strictness annotations case blah of N l e r -> N l e (f r) -- l and r are left and right sub-trees or -- Without strictness annotations case blah of N l e r -> let r' = f r in r' `seq` N l e r' Now if the compiler wasn't smart enough to figure out that in the first example l was already reduced (because it's from a strict field) then it would get diverted trying to reduce it again (pointlessly accessing heap record it didn't need, disrupting the cache etc), so the net result would be slower code. But in truth I understand precious little about what analyses and optimisations ghc is capable of, so this could all be complete nonsense. So is this explanation plausible? Also (persuing this a little further) it occurs to me that the if this hypothesis is correct there could be other bad effects. For example, if in an expression I have a constructor with a strict field, but the constructor is used in a non-strict context. Presumably the compiler won't generate this constructor in it's "reduced form" (whatever that might be for ghc :-) because this would force evaluation of the field value. So it must construct some kind of thunk instead. But there's no reason it should be so inhibited if the constructor was non-strict (or if the compiler could figure out the field value was already reduced). Thanks -- Adrian Hey

1 0

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