January 2003 - Glasgow-haskell-users

problem using ffi with profiling
by Hal Daume III 26 Jan '03

26 Jan '03

Hi all, I'm having difficulty compiling something with profiling which uses ffi. It compiles fine without profiling, but not with: % rm CMU_LM.hi CMU_LM.o % ghc -c CMU_LM.hs -fglasgow-exts -ffi -package data -cpp this works fine. % rm CMU_LM.hi CMU_LM.o % ghc -c CMU_LM.hs -fglasgow-exts -ffi -package data -cpp -prof -auto-all In file included from /tmp/ghc5638.hc:6: lm_bridge.h:4:32: pc_libs/pc_general.h: No such file or directory lm_bridge.h:5:29: rr_libs/general.h: No such file or directory lm_bridge.h:6:19: ngram.h: No such file or directory lm_bridge.h:7:21: toolkit.h: No such file or directory In file included from /tmp/ghc5638.hc:6: lm_bridge.h:10: parse error before "word" lm_bridge.h:11: parse error before "word" lm_bridge.h:12: parse error before "word" Any idea why there would be a difference? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: incremental linking?
by Simon Marlow 25 Jan '03

25 Jan '03

> I too am getting link times in the several minutes range for > my modestly > sized project, I am on a standalone dual-cpu redhat linux box with > 5.04.1 (no nfs, no nuttin') > > the project is available at > http://repetae.net/john/computer/ginsu/ > > I think there is definatly something fishy going on. I don't remember > linking always taking this long, I just assumed I added a > bunch of code > to my project or something but linking takes longer than all the > other compilation stages combined. That's bizarre. I just compiled your program on my laptop (Gentoo Linux, gcc 3.2) and linking took 6-7 seconds. John, what version of gcc/binutils is on your RedHat box? I haven't been able to discern any pattern among those experiencing long link times so far, except that -export-dynamic flag used by the dynamic loader stuff seems to cause the linker to go off into space for a while. Cheers, Simon

3 4

Problem with --split-objs on windoze (when building HOpenGL)
by Peter Smith 24 Jan '03

24 Jan '03

I'm having some difficulties with the --split-objs parameter when building HOpenGL on win xp ine with --disable-split-objs. Tried uninstalling my 'normal' copy of perl & upgrading GHC to 5.04.2 but am still getting the same error. Couldn't find anything in the archives, so anyone got any ideas?? $ make ------------------------------------------------------------------------ Recursively making `all' in lib examples ... PWD = /usr/local/HOpenGL-1.04 ------------------------------------------------------------------------ ------------------------------------------------------------------------ make all - --unix; in /usr/local/HOpenGL-1.04/lib ------------------------------------------------------------------------ rm -f GL_Marshal.o ; if [ ! -d GL_Marshal_split ]; then mkdir GL_Marshal_split; else find GL_Marshal_split -name '*.o' -print | xargs -s 8000 rm -f __rm_food ; fi ; "/cygdrive/c/ghc/ghc-5.04.1/bin/ghc" -package lang -package-name HOpenGL -i../GL UT -I../GLUT/include -cpp -DCALLCONV=stdcall -split-objs -odir GL_Marshal_split -fglasgow-exts "-#include <GL/glut.h>" -O -c GL_Marshal.hs -o GL_Marshal.o Can't locate utf8.pm in @INC (@INC contains: .) at c:\ghc\ghc-5.04.1\ghc-split l ine 50, <TMPI> line 7. BEGIN failed--compilation aborted, <TMPI> line 7. make[1]: *** [GL_Marshal.o] Error 1make: *** [all] Error 1 Peter At 01:10 PM 24/01/2003 +0100, Sven Panne wrote: Peter Smith wrote: > I'm getting the following error when running make all/make install (make > depend worked fine). > > I'm building on windoze xp home, GHC5.04.1, cygwin. Any ideas? [...] Hmmm, this looks like a GHC/Perl installation problem (GHC uses Perl e.g. for -split-objs). A few questions: * Can you compile and link a simple HelloWorld.hs with -O? * Can you do the same with -O *and* -split-objs? * Does HOpenGL work when configure is called with --disable-split-objs? Cheers, S.

1 0

Profiling trouble
by Ferenc Wagner 24 Jan '03

24 Jan '03

Hello, Please help me understanding GHC 5.02.2 profiling output! Here is the root of my program (Show.hs): \begin{code} showData :: BaseVector a => Params -> Operator a -> String showData params pot = unlines ["Version 3.1", "", showParams pot params, "tcsdim: " ++ tcsDim, "", "conformal energies:", diagonals, "perturbation matrix:"] ++ matrixElements where cutStates = {-# SCC "showData1" #-} getStates params tcsDim = {-# SCC "showData2" #-} show (length cutStates) diagonals = {-# SCC "showData3" #-} unlines $ map (show . energy) cutStates matrixElements = {-# SCC "showData4" #-} unlines $ map unwords off off = {-# SCC "showData5" #-} [map (myShow . pot outV) (take i cutStates) | (outV,i) <- zip cutStates [1..]] main = do params <- option putStr $ showData params (superPot params) \end{code} If I compile it via ghc -package util -o show --make Show.hs -prof -auto-all I get in show.prof: Fri Jan 24 17:46 2003 Time and Allocation Profiling Report (Final) show +RTS -p -RTS -c 5 -s R -p 0 -t 0 -r 3 total time = 94.54 secs (4727 ticks @ 20 ms) total alloc = 2,313,980,136 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc showData1 Main 86.1 88.5 cutAbove4 Tcsa 3.6 1.5 ncEps Epsilon 3.3 3.1 GC GC 2.2 0.0 vopMode Boson 1.5 1.1 ncVop Boson 1.2 1.0 getStates Tcsa 0.6 1.2 individual inherited COST CENTRE MODULE entries %time %alloc %time %alloc MAIN MAIN 0 0.0 0.0 100.0 100.0 main Main 0 0.1 0.0 100.0 100.0 [...] showData Main 1 0.0 0.0 91.1 91.9 showData5 Main 1 0.0 0.0 0.3 0.4 myShow Main 9453 0.3 0.3 0.3 0.3 showData4 Main 1 0.0 0.1 0.0 0.1 showData3 Main 1 0.1 0.1 0.1 0.1 showData1 Main 1 86.1 88.5 90.8 91.4 cutAbove Tcsa 28 0.0 0.0 3.6 1.5 cutAbove2 Tcsa 1 0.0 0.0 0.0 0.0 cutAbove3 Tcsa 27 0.0 0.0 0.0 0.0 cutAbove4 Tcsa 28 3.6 1.5 3.6 1.5 spinSelect Tcsa 1 0.0 0.0 0.0 0.0 getStates Tcsa 1 0.6 1.2 1.0 1.4 incrementalBase Fermion 1 0.3 0.2 0.4 0.2 fermionNumber Fermion 77664 0.1 0.0 0.1 0.0 allTowers Boson 1 0.0 0.0 0.0 0.0 inModule Boson 17 0.0 0.0 0.0 0.0 mergeUp Boson 6 0.0 0.0 0.0 0.0 showData2 Main 1 0.0 0.0 0.0 0.0 [...] My question: showData1 is a single function call, how can it still have such a big individual share? Where is the program spending its time? Sorry if it is a trivial question, functional profiling is new to me. Thanks: Feri.

1 0

RE: Porting mips-sgi-irix65 [help]
by Simon Marlow 24 Jan '03

24 Jan '03

> As pointed Michael Weber in a sparc-unknown-linux porting,the > key point is > > "gcc on sparc-linux (mips-irix) doesn't mark the beginning of > .data(like "data_start" on i386-linux) . Using etext is > definitely wrong > here, since .rodata comes afterwards and therefore etext > doesn't cover the infotables for > static-closures" You may be interested to know that recent CVS versions of GHC don't have the requirement that the section boundaries need to be known. You'll undoubtedly find it easier to port newer versions (although in order to bootstrap you might need to start from an older version...). Cheers, Simon

1 0

RE: Porting mips-sgi-irix65 [help]
by Rafael Martínez Torres 23 Jan '03

23 Jan '03

On Fri, 13 Dec 2002, Simon Marlow wrote: > > > > 59 59 > > 59 59 > > 10 (CONST_NOCAF_STATIC) 10 > > 10 10 > > 33 (IND_STATIC) 4137 (zzz! Max number 64 !) > > 17 (FUN_STATIC) > > 33 > > 29 > > Something is wrong with the heap layout perhaps, or maybe the info tables. I can't tell much more from the information above; you'll need to fire up gdb on the executable and dig into the contents of the heap and info tables at the point of the crash. > > Cheers, > Simon > Well, the bug is bounded ( not fixed at all). RTS::Scheduler.c GarbageCollect() get_roots() "GetRoots()" MarkRoot() evacuate() LOOKS_LIKE_GHC_INFO(q) IS_CODE_PTR(q) ClosureMacros.h::TEXT_END_SECTION_MARKER_DCL ClosureMacros.h::TEXT_END_SECTION_MARKER As pointed Michael Weber in a sparc-unknown-linux porting,the key point is "gcc on sparc-linux (mips-irix) doesn't mark the beginning of .data(like "data_start" on i386-linux) . Using etext is definitely wrong here, since .rodata comes afterwards and therefore etext doesn't cover the infotables for static-closures" bash-2.04$ size nfibI Section Size Physical Virtual Address Address .MIPS.options 128 268435760 268435760 .MIPS.stubs 1188 269119080 269119080 .text 1722540 269120272 269120272 .init 80 270842812 270842812 .fini 56 270842892 270842892 .rodata 266108 270909440 270909440 ===> .data 39236 271175552 271175552 <== ... bash-2.04$ nm nfibI [7387] | 270842948| 0|SECT |GLOB |DEFAULT |MIPS_TEXT|etext <== ... [22] | 270909440| 266108|SECT |LOCL |DEFAULT |MIPS_DATA|.rodata [23] | 271175552| 39236|SECT |LOCL |DEFAULT |MIPS_DATA|.data -border- [136] | 270909440| 0|SECT |GLOB |DEFAULT |MIPS_DATA|fdata <== [137] | 270909440| 0|SECT |GLOB |DEFAULT |MIPS_DATA|_fdata <== No symbol cover ".rodata" section, i.e some info-static closures... I'll think a *patch*. Michael Weber's (linker script) doesn't semm useful because I can't use GNU ld. It May be useful for further designs of Ghc , in order to get a cleaner portability... (To Mr. Marlow ) Any idea ? By hardwiring (code lit. 271175552) the code each compilation, I could run nfibI(35), so I'm in the rigth way.

1 0

RE: Avoiding "No explicit method ..." warnings
by Simon Peyton-Jones 23 Jan '03

23 Jan '03

Done! | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 21 January 2003 15:43 | To: Simon Peyton-Jones | Cc: Dean Herington; glasgow-haskell-users(a)haskell.org | Subject: Re: Avoiding "No explicit method ..." warnings | | Simon Peyton-Jones wrote: | [snip] | > One other idea though. Suppose you say | > | > class ComplicatedClass x where | > _simpleTitleFn :: x -> String | > muchMoreComplicatedTitleFn :: extra arguments -> x -> IO ... | > | > In general GHC doesn't report "warning unused" for variables whose name | > begin with an underscore. In the case of class methods, I don't think | > it suppresses the warning, but that would be an easy change to make. | > Indeed, it would arguably be more consistent to do so anyway | > | > > #-}) which compiles exactly as normal except that (1) no warning is | > > given for instances which don't define it; (2) a warning is given | > > whenever anyone outside the class declaration *uses* simpleTitleFn. | > | > The "_" idea would achieve (1). You could get (2) by not exporting the | > "_" method from the module defining ComplicatedClasss. | > | > How would that be? | [snip] | Yes, this looks just as good as my original idea, if not better. Especially | as it "would be an easy change to make". | | In fact there are some cases where I might want to use "simpleTitleFn" on a | "Trust me, it's defined for this type" basis, but that could be achieved by | exporting an equivalent, but deprecated, function.

1 0

HTk for ghc-5.04.2
by George Russell 23 Jan '03

23 Jan '03

I've compiled HTk for ghc-5.04.2 on Solaris, Linux and Windows, and put binary bundles at http://www.informatik.uni-bremen.de/htk/ So you can write portable graphical user interfaces using the latest release of your favorite Haskell compiler. Sorry it's a bit late; it's not that it's difficult, it's just that I am a shortage of manpower. I hope I produce binaries for ghc-5.04.3 a bit faster.

1 0

RE: Ambiguous type variable
by Simon Peyton-Jones 23 Jan '03

23 Jan '03

I've been working on improving this error message. Here's the current version: R.hs:1: Ambiguous type variable `a' in constraints `Random a' arising from use of `randomRs' at R.hs:4 `Num a' arising from the literal `0' at R.hs:4 Possible cause: the monomorphism restriction applied to the following: f :: Int -> [a] (bound at R.hs:4) better, eh? | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 22 January 2003 18:28 | To: GHC Users Mailing List | Subject: Ambiguous type variable | | Hi all, | | This works fine, as expected | > f :: (Num a, Random a) => Int -> [a] | > f = randomRs (0,1).mkStdGen | | If I skip the type signature, though, I get the following error messages: | Main.hs:14: | Ambiguous type variable(s) `a' in the constraint `Random a' | arising from use of `randomRs' at Main.hs:14 | In the first argument of `(.)', namely `randomRs (0, 1)' | In the definition of `f': (randomRs (0, 1)) . mkStdGen | | Main.hs:14: | Ambiguous type variable(s) `a' in the constraint `Num a' | arising from the literal `1' at Main.hs:14 | In the first argument of `randomRs', namely `(0, 1)' | In the first argument of `(.)', namely `randomRs (0, 1)' | | Why exctly can't ghci figure how the type of f? | | This just happens when loading the code from a file, | > :t randomRs (0,1).mkStdGen | in ghci works fine. | | J.A. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Ambiguous type variable
by Jorge Adriano 22 Jan '03

22 Jan '03

Hi all, This works fine, as expected > f :: (Num a, Random a) => Int -> [a] > f = randomRs (0,1).mkStdGen If I skip the type signature, though, I get the following error messages: Main.hs:14: Ambiguous type variable(s) `a' in the constraint `Random a' arising from use of `randomRs' at Main.hs:14 In the first argument of `(.)', namely `randomRs (0, 1)' In the definition of `f': (randomRs (0, 1)) . mkStdGen Main.hs:14: Ambiguous type variable(s) `a' in the constraint `Num a' arising from the literal `1' at Main.hs:14 In the first argument of `randomRs', namely `(0, 1)' In the first argument of `(.)', namely `randomRs (0, 1)' Why exctly can't ghci figure how the type of f? This just happens when loading the code from a file, > :t randomRs (0,1).mkStdGen in ghci works fine. J.A.

2 2