October 2002 - Glasgow-haskell-users

Debugging Haskell: the stack
by Christoph Lueth 25 Oct '02

25 Oct '02

Dear Haskell people, when I call from Haskell into C, stop it there, and use a debugger (e.g gdb) to look at the stack, it looks all broken. Here is an example: #0 c_init () at c.c:5 #1 0x08048f14 in ssM_fast1 () #2 0x0804a248 in sakt_ret () #3 0x04c58308 in ?? () (c_init is a C function on which I've set a breakpoint). Now, I don't expect to see meaningful stack frames from Haskell, but I am calling into Haskell from C, and I would expect the C functions calling into Haskell to appear on the stack frame. What is happening? How does Haskell manage to still return to C when the stack looks like that? Best regards, --C.

1 0

RE: 5.04.2 schedule?
by Simon Marlow 25 Oct '02

25 Oct '02

> > We're wondering here whether we should push out 5.04.2 > soon, or wait a > > while and see what other bugs turn up. > > > > Opinions, anyone? > > Release often, release soon! Why not put out a source distribution > on a regular basis, say, every month or so (I realize that binary > distributions are a lot of work). I'm a big fan of "release early, release often" too, but we have to balance that against stability and putting out releases that people can actually use. In the past we used to have a distinction between source and binary releases, but it didn't work too well: people used to make packages of the source releases, blurring the distinction, and in any case binary packages always pop out of the end of the nightly build, so building them isn't any extra hassle. Other packages, RPMs and so on are built by others. What really takes time is all the things that have to be done for a release: testing, updating bits with the new version number, updating web pages, uploading documentation, and so on. It takes about a day of my time to do a release, more if it's a major release (because then we have to do release notes). So I think the current situation is a good compromise: those who want the bleeding edge can get CVS and watch cvs-ghc(a)haskell.org so they can see when the compiler is stable, and we put out stable releases every couple of months or so. Cheers, Simon

3 2

RE: EVACUATED object entered! (when doing FFI)
by Simon Marlow 25 Oct '02

25 Oct '02

> Good morning again, > > Thank you for answering. > > I am using ghc 5.04.1 I compiled myself on a linux box > (Mandrake 8.2) . > > I'm sending you the source code. Compiled it with the > following commands : > > ghc -ffi -c GetFNamesBckp.hs -o GetFNamesBckp.o > > gcc -I/opt/installed/ghc-5.04.1/lib/ghc-5.04.1/include -c > cGetFNamesBckp.c -o > cGetFNamesBckp.o > > ghc -no-hs-main GetFNamesBckp_stub.o GetFNamesBckp.o cGetFNamesBckp.o Good bug! In fact, it has nothing to do with the FFI, but it is a bug in the garbage collector introduced in 5.04.1. The fix will be in 5.04.2. BTW, an easier way to compile your program is ghc -ffi -no-hs-main cGetFNamesBckp.c GetFNamesBckp.hs Cheers, Simon

1 0

Problem with Data.Dynamic
by Martin Sjögren 25 Oct '02

25 Oct '02

Hello list. I have a problem with Data.Dynamic. The problem is probably that I don't understand it. From my understanding, the following program should work: -8<------------------------ import Data.Dynamic data Foo = Foo { x :: Int } deriving Show instance Typeable Foo where typeOf _ = mkAppTy (mkTyCon "Foo.Foo") [] main = do let dynObj = toDyn $ Foo 42 print dynObj let Just obj = fromDynamic dynObj :: Maybe Foo print obj -8<------------------------ But when I compile it (ghc Foo.hs) and run it (./a.out) I get: <<Foo.Foo>> Fail: Foo.hs:13: Irrefutable pattern failed for pattern (Data.Maybe.Just obj) Which indicates that fromDynamic returned Nothing. What is the problem here? Do I have to employ special trickery to use Dynamic with records? I'm using ghc 5.04, as packaged by Debian. Regards, Martin Sjögren

3 2

RE: Haskell code coverage tool?
by Simon Marlow 25 Oct '02

25 Oct '02

> Is anyone aware of a code-coverage tool for Haskell, specifically one > that works/uses the ghc? > > I've been trying to use the profiling information for my purpose but > would much prefer there to be a specialized tool that: > > (i) provides "line" coverage information in the sense that it > distinguishes e.g. case handling and if/then/else. > (ii) projects the coverage information onto the source code There isn't such a tool that I know of. Building one would make a good student project, though! The profiling system could be persuaded to do coarse code coverage analysis without too much difficulty. With -auto-all we get cost centres attached to every top-level function, and it's simply a matter of comparing the full set of cost centres against the profile generated by running the program. The complete set of cost centres could be obtained in a hacky way by examining object files. Cheers, Simon

1 0

RE: EVACUATED object entered! (when doing FFI)
by Simon Peyton-Jones 24 Oct '02

24 Oct '02

It's certainly a bug of some kind. Please say what version of GHC you are using. If it's the latest one (5.04.1), please send us the source code. Thanks Simon | -----Original Message----- | From: Francis Girard [mailto:francis.girard@free.fr] | Sent: 24 October 2002 04:02 | To: glasgow-haskell-users(a)haskell.org | Subject: EVACUATED object entered! (when doing FFI) | | Good morning, | | I wrote a very small program, and it executed ok. | I wanted to export a function in "C", and therefore wrote a "C" wrapper | function over it to invoke peekCString and peekArray on the input; newCString | and newArray on the output. | | I then did a small "C" driver program. Everything compiled and linked | correctly. | | But at execution the program prints : | | EVACUATED object entered! | | as soon as "startupHaskell" is invoked (i.e. even before I call my foreign | exported function !) | | What is the meaning of this message ? | | Thank you | | Francis Girard | Le Conquet | France | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Haskell code coverage tool?
by Reto Kramer 24 Oct '02

24 Oct '02

Is anyone aware of a code-coverage tool for Haskell, specifically one that works/uses the ghc? I've been trying to use the profiling information for my purpose but would much prefer there to be a specialized tool that: (i) provides "line" coverage information in the sense that it distinguishes e.g. case handling and if/then/else. (ii) projects the coverage information onto the source code Thanks, - Reto

1 0

standalone core parser
by Hal Daume III 24 Oct '02

24 Oct '02

There's ParserCore.y in the ghc sources, but this relies on a bunch of other stuff. Does anyone have a Core language library, such as one which might be found in the std libs at Language.GHCCore, or something like that? If not, I'll probably try to create something myself. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

(no subject)
by C.Reinke 24 Oct '02

24 Oct '02

> I'd argue that -package is a global option and should stay that way. > The only reason you might want to disable -package for certain > modules and not others is if you want to do some tricks with module > shadowing - and this definitely isn't supported in GHC. You should > pass the same -package to every compilation. Funny, I wasn't actually thinking of hiding -package (effectively giving it a scope) when I wrote that. AFAIC, it would be fine for GHC to collect all the -package options from the source files it wants to compile and then use the same superset of package options for all of them (*). But it would be helpful if each source collection could include the information ghc needs to compile it. So if I have sources A that happen to need -package HOpenGL and sources B that happen to need -package lang, etc., I could simply document those dependencies in the sources in a way ghc would understand. And if I have a project C using both A and B, and I need to modify anything in A or B, I could still simply let "ghc --make C" figure out what to do by just telling it where to find A and B. Whereas currently, I have to go back and figure out what packages A or B need to be compiled with.. (or not use ghc --make, before anyone else suggests that;-). > I think -i is a global option in the same sense as -package, though. > The library options -l and -L don't really matter, since they're > only used at link time and you wouldn't want to put them in OPTIONS > anyhow. Same here, for non-package dependencies. Claus (*) I didn't want to have global supersets of options for language extension flags, but those seem to be dynamic anyway, and often, their effects spill over to anything wanting to use the modules that use language extensions.

1 0

5.04.2 schedule?
by Simon Marlow 24 Oct '02

24 Oct '02

Folks, We're wondering here whether we should push out 5.04.2 soon, or wait a while and see what other bugs turn up. Opinions, anyone? Are any of the bugs in 5.04.1 really holding you up? Here's a list of the bugfixes in 5.04.2 relative to 5.04.1: - Control.Exception.userErrors was wrong - derived Read with Maybe fixed - export TimeLocale constructor from Locale - network package fix for Network.Socket.inet_ntoa - GHCi: rdrNameModule panic - GHCi: getChar not interruptible with ^C - --make: unknown filenames on the command line are now passed to the linker - PowerPC/Darwin support is now up to date (?) - foreign exporting infix operators now works - missing strict fields in a record construction now works according to the report - memory allocator fix: eliminates the getMBlock panic - panics when using signals (signal handlers not being retained by the garbage collector). - main threads not retained long enough (HOpenGL panic) and I'm hot on the trail of the heapCensus panic. Cheers, Simon

2 1