package treating
I wrote recently about `strange' package management in ghc-6.0.1. I thank Swenn Pan, who explained the effect to me: about List from haskell98 package and data depending on haskell98. I missed the point because I am a bit stupid and also because the package treating changes rapidy from version to version. I presumed that, as the ghci command loads all usable libraries, then ghci -package-conf myPackage.conf -package myPackage will load all that `ghci' loads + what is specified in myPackage.conf. But, probably, this is not (should not be?) so: the option -package-conf myPackage.conf fully replaces the configuration, and the package search is done only according to what is specified in myPackage.conf , right? The program needs to link module List. List is of haskell98 package (right?), and myPackage does not mention any package dependency which could lead haskell98. Therefore the linker does not find in the loaded libraries some needed item for List. Then, ghci reports of `panic'. Maybe, it should report instead library item Foo not found, List items are of haskell98 package, do you have it on package dependecies? , something like this. Also there remains a question about concrete usage of ghc-pkg -g . Please, explain this (to [EMAIL PROTECTED]). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Wildly inaccurate profiling results
I have a program, compiled with cost-center profiling on, that takes about 5 minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof file reports the total time as 34 seconds. I know that this number doesn't include overhead due to profiling, but surely the overhead can't be that much! (Also, the program runs about as long when run without -P.) I'm using a copy of GHC built from sources checked out around July 1. I'd include the program, but it's very large and I'm not sure how to minimize it and preserve the same behavior. Any ideas as to what the problem might be? Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-827485 ] Heap profile w/ debugging RTS dumps core
Bugs item #827485, was opened at 2003-10-21 14:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=827485group_id=8032
Category: Compiler
Group: 6.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Volker Stolz (volkersf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Heap profile w/ debugging RTS dumps core
Initial Comment:
[EMAIL PROTECTED] [14:41:59] ~/a.out +RTS -h
Segmentation fault (core dumped)
[EMAIL PROTECTED] [14:42:00] ~/a.out +RTS -hL
Segmentation fault (core dumped)
[EMAIL PROTECTED] [14:42:55] ~/a.out +RTS -hT
Segmentation fault (core dumped)
Relevant section from RtsFlags.c:
case 'h': /* serial heap profile */
#if !defined(PROFILING) defined(DEBUG)
switch (rts_argv[arg][2]) {
case '\0':
case 'L':
RtsFlags.ProfFlags.doHeapProfile = HEAP_BY_INFOPTR;
break;
case 'T':
RtsFlags.ProfFlags.doHeapProfile =
HEAP_BY_CLOSURE_TYPE;
break;
[I don't need profiling, I just thought I'd get a list of all available
RTS-flags on -h]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=827485group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: LD_LIBRARY_PATH, ghc and Solaris
I have to do a similar thing on OpenBSD, to use an external libgmp residing in /usr/local/lib. But no real hacking is required! When compiling GHC, before you start, add something like: , -L, /usr/local/lib to somewhere down around line 137 of ghc/rts/package.conf.in. More correctly, the directory should be added to the 'library_dirs' field of the package configuration for the appropriate package (readline, in the case of the original report). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: user package blocks standard ones
Question on ghc-pkg -g === User guide for packages does not explain this precisely. I suspect that ghc-pkg -g may help to replace the messy line ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o in the above Makefile, but cannot guess how to use here this ghc-pkg -g. Yes, that's exactly what ghc-pkg -g does. It's usage is straightforward. Could you elaborate on what you find unclear? Did you try just adding -g to the ghc-pkg command line? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: package treating
I presumed that, as the ghci command loads all usable libraries, then ghci -package-conf myPackage.conf -package myPackage will load all that `ghci' loads + what is specified in myPackage.conf. But, probably, this is not (should not be?) so: the option -package-conf myPackage.conf fully replaces the configuration, and the package search is done only according to what is specified in myPackage.conf , right? No, packages are loaded on a demand-driven basis. Packages must have correct dependencies specified, so that GHC can ensure that they are loaded in dependency order. The -package-conf flag does not cause the configuration to be fully replaced. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: user package blocks standard ones
On Tue, Oct 21, 2003 at 01:56:38PM +0100, Simon Marlow wrote: I suspect that ghc-pkg -g may help to replace the messy line ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o in the above Makefile, but cannot guess how to use here this ghc-pkg -g. Yes, that's exactly what ghc-pkg -g does. It's usage is straightforward. Could you elaborate on what you find unclear? Did you try just adding -g to the ghc-pkg command line? I tried earlier -- without success. And now it works. Probably, I confused something. I am sorry. My bug reports mostly turn false. But there remains the interpreter crash, let us see. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Wildly inaccurate profiling results
I have a program, compiled with cost-center profiling on, that takes about 5 minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof file reports the total time as 34 seconds. I know that this number doesn't include overhead due to profiling, but surely the overhead can't be that much! (Also, the program runs about as long when run without -P.) I'm using a copy of GHC built from sources checked out around July 1. I'd include the program, but it's very large and I'm not sure how to minimize it and preserve the same behavior. Any ideas as to what the problem might be? I think the profiler only measures CPU time, so if the program is waiting for I/O or sleeping a lot of the time, that won't be included in the profile. Also, the overhead due to heap rofiling can sometimes be a lot, because it includes the time to scan the heap and collect the census data. Retainer profiling (+RTS -hr) is also especially expensive. You should see the profiling overheads drop considerably when not doing heap profiling, though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Wildly inaccurate profiling results
On Tue, Oct 21, 2003 at 05:21:37PM +0100, Simon Marlow wrote: I think the profiler only measures CPU time, so if the program is waiting for I/O or sleeping a lot of the time, that won't be included in the profile. I don't think that's the issue -- when I run the program with debugging flags on that print out what it's doing, I can tell that it spends at most the first minute reading in files, and at most the last minute writing files (out of 5.5 minutes). Also, top shows that the program is using around 97% of the CPU for most of its run. Also, the overhead due to heap rofiling can sometimes be a lot, because it includes the time to scan the heap and collect the census data. Retainer profiling (+RTS -hr) is also especially expensive. You should see the profiling overheads drop considerably when not doing heap profiling, though. I'm not doing any heap profiling -- the only profiling flag I'm using is -P. When I recompiled the program without any profiling and ran it again, it took about 4 minutes as opposed to 5.5, suggesting that the 34 seconds reported by profiling really is inaccurate. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt I wish people weren't so set on being themselves, when that means being a bastard. -- Robertson Davies http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Wildly inaccurate profiling results
I think I understand what's going on: GC time isn't counted as part of the time reported by profiling. This seems misleading to me, since if your program is spending 4 times as much time doing GC as doing actual work (such as mine is), you'd want to know about it... but I suppose you can always just get the GC stats with -t anyway. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt There is no such thing as a weird human being. It's just that some people require more understanding than others.--Tom Robbins http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
