March 2002 - Glasgow-haskell-users

GHC for MacOS X: Success!
by Wolfgang Thaller 21 Mar '02

21 Mar '02

After weeks of wrestling with Apple's buggy version of gdb, registerized compilation on MacOS X finally works! I've tested it on GHC itself and on my own (H)OpenGL program, VOP, and it seems to work now. I'm attaching my patches. I've had trouble compiling the newest version from CVS. Instead, I've stayed behind by one week (13th of March, to be exact). Bootstrapping from the old ghc 5.00.2 binary version seems to work only up to around 4th of March (Binary IO doesn't work properly with GHC 5.00.2/MacOS X). If I find enough webspace, I'll upload a binary version, too, to save other people the work of recompiling GHC twice in a row. Profiling doesn't work, I just get some segfaults. Is there anything specific that needs to be done to get profiling to work, or should I just go on another long bug-hunt? So, Mac users, please try it out and tell me if it works for your programs, too! Cheers, Wolfgang P.S. to Simon Marlow: You were right, those segfaults _are_ fun! Who would have thought that the PowerPC has so many registers that a clobbered callee-save only shows up _seconds_ later?

1 0

RE: Measuring memory usage of Glasgow Haskell programs
by Simon Marlow 21 Mar '02

21 Mar '02

> Judging from the source (rts/Stats.c), the "10 Mb total memory in use" > figure here counts the number of megablocks allocated... but what does > this actually mean? > > It's fairly straightforward to determine a program's maximum > stack size by > fiddling with the -K runtime option and using a binary search. > > Is there a similarly easy way to find a program's maximum > heap size? I > don't think fiddling the -M option will work, because that affects the > execution (it can cause extra GCs). You can find an approximation to the maximum instantaneous resident data size by switching to 2-space collection (+RTS -G1) and fixing the allocation area size to some arbitrarily small value (eg. +RTS -A256k). The program will take a long time to run, because it will do a major GC every time the allocation area is full up. You can decrease the run time (and the accuracy) by increasing the size of the allocation area. The stats output will then tell you both the maximum and average residency of the program. > And is there a way to measure static memory usage? And then the > maximum combination of stack+heap+static? (I guess that is > the "maximum > residency" above)? The residency only takes into account heap-resident data, static data isn't included. I think the stack is excluded from this figure, though. Cheers, Simon

1 0

Measuring memory usage of Glasgow Haskell programs
by Nicholas Nethercote 21 Mar '02

21 Mar '02

Hi, I'm interested in determining the amount of memory used by various Glasgow Haskell programs. The -s runtime option produces information like this: 222,447,136 bytes allocated in the heap 30,327,124 bytes copied during GC 4,625,052 bytes maximum residency (12 sample(s)) 847 collections in generation 0 ( 0.24s) 12 collections in generation 1 ( 0.19s) 10 Mb total memory in use INIT time 0.01s ( 0.02s elapsed) MUT time 1.28s ( 1.31s elapsed) GC time 0.43s ( 0.45s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.72s ( 1.78s elapsed) %GC time 25.0% (25.3% elapsed) Alloc rate 172,439,640 bytes per MUT second Productivity 74.4% of total user, 71.9% of total elapsed Judging from the source (rts/Stats.c), the "10 Mb total memory in use" figure here counts the number of megablocks allocated... but what does this actually mean? It's fairly straightforward to determine a program's maximum stack size by fiddling with the -K runtime option and using a binary search. Is there a similarly easy way to find a program's maximum heap size? I don't think fiddling the -M option will work, because that affects the execution (it can cause extra GCs). And is there a way to measure static memory usage? And then the maximum combination of stack+heap+static? (I guess that is the "maximum residency" above)? Thanks. -- Nick Nethercote njn25(a)cam.ac.uk

1 0

Farewell from an old friend.
by Marc van Dongen 21 Mar '02

21 Mar '02

Hi there, I've been using Haskell since about 1995-ish and would like to thank the ghc-team (in particular SPJ and SM) for their support. Also I would like to thank all those on the list for interesting contributions and help. Thanks again. Regards, Marc van Dongen -- M.R.C. van Dongen | CS Dept University College Cork | () dongen(a)cs.ucc.ie | Cork Constraint Computation Centre | /\ +353(0)21 4903578 | Western Road | ASCII ribbon | Cork, Ireland | against html mail

1 0

RE: Makefile tricks
by Simon Marlow 20 Mar '02

20 Mar '02

> (RedHat-6.1 Linux machine, libc-2.1.2), > > Can you, please explain the following effect > > Main.hs: main = putStr "hello\n" > > Makefile: > --------- > obj: > ghc -c -O Main.hs +RTS -M10m -RTS > > -- Running -------------------- > $ tcsh > > make obj > ghc -c -O Main.hs +RTS -M10m -RTS > ghc: input file doesn't exist: +RTS > ghc: unrecognised option: -M10m > ghc: unrecognised option: -RTS It looks like 'make' is using a different PATH setting than the one in effect at the shell prompt, and hence getting a different 'ghc'. Cheers, Simon

1 0

RE: Makefile, Linux versions
by Simon Marlow 20 Mar '02

20 Mar '02

> > make docon > ghc -fglasgow-exts -fallow-overlapping-instances > -fallow-undecidable-instances -fno-warn-overlapping-patterns > -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports > -syslib data -ddump-hi-diffs -package-name docon > --make DExport > ghc: input file doesn't exist: docon > ghc: input file doesn't exist: DExport > ghc: no such system library (-syslib): data > ghc: unrecognised option: -package-name > ghc: unrecognised option: --make It looks like you're invoking the wrong version of GHC (perhaps the 4.04 version you mentioned earlier)? Cheers, Simon

1 0

warning: `RLIM_INFINITY' redefined
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear ghc-5.02.2-i386-unknown-linux, When compiling with -O, you report sometimes things like In file included from /usr/include/sys/resource.h:25, from /share/nfs/users/internat/mechvel/ghc/5.02.2/inst/lib/ghc-5.02.2/ include/HsStd.h:65, from /tmp/ghc29631.hc:2: /usr/include/bits/resource.h:109: warning: `RLIM_INFINITY' redefined /usr/include/asm/resource.h:26: warning: this is the location of the previous definition Is this harmless? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

sorry for false alarm
by S.D.Mechveliani 20 Mar '02

20 Mar '02

I am sorry. It was a false alarm. I wrote recently about Makefile faults when applying ghc. The is also old ghc on this machine in the system area. I set alias to new ghc (in my user directory), but `make' does not know about alias and applies old ghc, which does not understand some options, like +RTS. This is not a problem. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Makefile tricks
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear ghc-5.02.2-i386-unknown-linux, (RedHat-6.1 Linux machine, libc-2.1.2), Can you, please explain the following effect Main.hs: main = putStr "hello\n" Makefile: --------- obj: ghc -c -O Main.hs +RTS -M10m -RTS -- Running -------------------- $ tcsh > make obj ghc -c -O Main.hs +RTS -M10m -RTS ghc: input file doesn't exist: +RTS ghc: unrecognised option: -M10m ghc: unrecognised option: -RTS Now, type this to command line: > ghc -c -O Main.hs +RTS -M10m -RTS And it works. This is so for the lstcsh shell too. > make -v GNU Make version 3.77, by Richard Stallman and Roland McGrath. And it works correct under Debian Linux, GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i586-pc-linux-gnu I do not know, whether it is essential, but this RedHat machine is a claster: for any job started, the system chooses itself appropriate machine to run this job on. But I was told that tcsh switches off this clastering. Also I am not sure, that this refers to GHC. I tried to set obj: ls -la and it works. Maybe, the new ssh version bug? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Makefile, Linux versions
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear GHC, I have installed ghc-5.02.2-i386-unknown-linux in my user directory on RedHat-6.1 Linux machine, libc-2.1.2 to which I have ssh access. My DoCon program was tested on Debian Linux. Now, it fails to `make' under RedHat in the following way. 1. It loads some shell wich shows the $ prompt. $ echo $shell /bin/lstcsh DoCon `make' was tested under tcsh. Also this RedHat machine is a claster: for any job started, the system chooses itself appropriate machine to run this job on. But I was told that tcsh switches off this clastering. So, for these two reasons, I command tcsh before `making' DoCon. 2. And it fails as follows: > make docon ghc -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -syslib data -ddump-hi-diffs -package-name docon --make DExport ghc: input file doesn't exist: docon ghc: input file doesn't exist: DExport ghc: no such system library (-syslib): data ghc: unrecognised option: -package-name ghc: unrecognised option: --make Under lstcsh, it reports the same thing. If I copy this command by mouse and run it not via Makefile but from the command line, then it works. The strings like -ddump-hi-diffs -package-name docon are kept in the varibles defined and used in Makefile like this: o1 = -ddump-hi-diffs -package-name docon obj: ghc $(o1) ... I wonder about this effect. How can one fix this Makefile business? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0