Subject: Wildly inaccurate profiling results - msg#00041

Previous Message by Date: click to view message preview

Re: user package blocks standard ones

Serge D. Mechveliani wrote: [...] /home/mechvel/test/export/HSdocon.o: unknown symbol `__stginit_List_' [...] Then, occasionally, tried to set package_deps = ["data"] , even though my contrived user package does not use "data". And it started to work, to load everything needed! Then I try package_deps = ["base"] And here ghci -package-conf docon.conf reports again the `panic'. [...] I don't have your sources at hand, but it looks like they depend on the "haskell98" package. Package "data" depends on "haskell98", BTW. Cheers, S.

Next Message by Date: click to view message preview

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 mechvel@xxxxxxxx). Regards, ----------------- Serge Mechveliani mechvel@xxxxxxxx

Previous Message by Thread: click to view message preview

<interactive>: internal error, ghc-6.0.1

I suspect that may previous bug report on interactive interpreter should be replaced with the following one, which is simple to analyse. This is on ghc-6.0.1 installed from RPM on Red Hat Linux release 7.3 (Valhalla), i-386 unknown. Probably, you can reduce the example several times more. ghci Main +RTS -M1m -RTS ..> : Main ..> main ... (<interactive>: internal error: thread_stack: weird activation record found on stack: 1564 Please report this as a bug to glasgow-haskell-bugs@xxxxxxxxxxx .. Probably, the interpreter manages memory in a wrong way. Can you reproduce the effect? Regards, ----------------- Serge Mechveliani mechvel@xxxxxxxx ------------------------------------------------------------------- main = let xs = [1..9000] -- change this number -- and see the message from ghc (x's, s1) = sortE compare xs in putStr $ shows s1 "\n" type CompValue = Ordering type Comparison a = a -> a -> CompValue mergeE :: Comparison a -> [a] -> [a] -> ([a],Char) -- Extended merge: -- the transposition sign '+' | '-' is also accumulated. mergeE cp xs ys = m xs ys $ evenL xs where m [] ys _ = (ys,'+') m xs [] _ = (xs,'+') m (x:xs) (y:ys) ev = case cp x y of GT -> (y:zs, mulSign s ev) where (zs,s) = m (x:xs) ys ev _ -> (x:zs, s) where (zs,s) = m xs (y:ys) (invSign ev) ortE :: Comparison a -> [a] -> ([a],Char) -- Extended sort: -- the permutation sign '+' | '-' also accumulates. sortE _ [] = ([] , '+') sortE _ [x] = ([x], '+') sortE cp xs = let (ys ,zs) = halve xs (ys',s1) = sortE cp ys (zs',s2) = sortE cp zs (us ,s3) = mergeE cp ys' zs' in (us, mulSign s3 $ mulSign s1 s2) halve :: [a] -> ([a],[a]) halve xs = h [] xs xs where h ls (x:rs) (_:_:ys) = h (x:ls) rs ys h ls rs _ = (reverse ls, rs) mulSign :: Char -> Char -> Char mulSign x y = if x==y then '+' else '-' invSign :: Char -> Char invSign '+' = '-' invSign '-' = '+' evenL :: [a] -> Char evenL [] = '+' evenL (_:xs) = invSign $ evenL xs -------------------------------------------------------------------

Next Message by Thread: click to view message preview

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 * krc@xxxxxxxxxxxxxxxxxxx * Often in error, never in doubt