- Glasgow-haskell-users

profiling,-O in 6.12.1
by Serge D. Mechveliani 04 Feb '10

04 Feb '10

Dear GHC team, It looks like ghc-6.12.1 reports erroneous time profiling -- when the Main module of the project is made under -O. This is for ghc-6.12.1 made from source for Debian Linux and i386-like. Main.main calls for Complete.complete, `complete' calls for eLoop inside its source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But for ghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 4

question about hsc2hs
by Jose A. Ortega Ruiz 04 Feb '10

04 Feb '10

Hi. I'm copying below a question i sent to another list about hsc2hs (and for which i got no response), in the hopes that it will be not be OT here. My apologies if it is! I'm trying to write a simple C binding for statfs(2). Simplifying, writing an hsc file that contains the following snippet: #include <sys/vfs.h> data CStatfs foreign import ccall unsafe "sys/vfs.h statfs" c_statfs :: CString -> Ptr CStatfs -> IO CInt getFileSystemStats :: String -> IO CLong getFileSystemStats path = allocaBytes (#size struct statfs) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- (#peek struct statfs, f_bsize) vfs bcount <- (#peek struct statfs, f_blocks) vfs bfree <- (#peek struct statfs, f_bfree) vfs bavail <- (#peek struct statfs, f_bavail) vfs -- Just for demonstration: the original code creates a data structure return $ bsize + bcount + bavail + bfree gives rise, when using hsc2hs, to this translation: getFileSystemStats path = allocaBytes ((84)) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) vfs bcount <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) vfs bfree <- ((\hsc_ptr -> peekByteOff hsc_ptr 16)) vfs bavail <- ((\hsc_ptr -> peekByteOff hsc_ptr 24)) vfs return $ bsize + bcount + bavail + bfree (where i have deleted LINE directives). The problem is that the size and some of the offsets of the C struct statfs computed by hsc2c are wrong: i'm in a 32bit linux system, and i've checked, using a C program, that sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps Haskell needs additional space for housekeeping?), and that the offsets of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). Also, i know that 12 and 16 are the right values because putting them by hand gives me the correct statfs values. (This is ghc 6.10.4 on a debian/sid system) What am i doing wrong? TIA! jao -- It is hard enough to remember my opinions, without also remembering my reasons for them. -Friedrich Wilhelm Nietzsche, philosopher (1844-1900)

2 3

Question regarding combinator call convention
by Tyson Whitehead 01 Feb '10

01 Feb '10

I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&ty… It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The thing I'm confused with is I would expect this would require treating combinators special, and yet I don't see an combinator specific stuff (in either ClosureTypes.h or the generated AutoApply.cmm) to treat them special. Ive also looking at functions like plusInt and a few of my own, but, apart from internal functions like stg_app_*, I'm not finding any code using the the combinator passing convention. Am I missing something? Thanks! -Tyson

2 2

building 6.12.1 with itself
by Nicolas Martyanoff 01 Feb '10

01 Feb '10

Hi, By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC 6.12.1. GHC 6.10.4 didn't build: g Lexer.x gmake[2]: g: Command not found gmake[2]: [Lexer.hs] Error 127 (ignored) RTS -K2m -RTS -agc --strict Parser.y gmake[2]: RTS: Command not found gmake[2]: *** [Parser.hs] Error 127 Failed making boot in genprimopcode: 1 gmake[1]: *** [boot] Error 1 gmake: *** [stage1] Error 1 But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the build process doesn't find the iconv lib when it's installed in /usr/local, so the lib/include paths have to be specified when running ./configure. I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I used cabal to install hscolour, xmonad and xmonad-contrib, it worked perfectly. I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

2 1

Language extensions - backwards compatibility
by Iain Alexander 30 Jan '10

30 Jan '10

I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander ia(a)stryx.demon.co.uk

5 8

cross-compiling ghc to openbsd
by Nicolas Martyanoff 30 Jan '10

30 Jan '10

Hi, I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd gmake bootstrapping-files The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Does someone what's going on with this build ? Is there something I can to to help on these issues ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

4 6

Re: GHC core plugins
by José Pedro Magalhães 29 Jan '10

29 Jan '10

Hi Max, 2010/1/27 Max Bolingbroke <batterseapower(a)hotmail.com> > 2010/1/27 José Pedro Magalhães <jpm(a)cs.uu.nl>: > > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > > > In any case, for now I am willing to hard-code a new core-to-core pass on > > the compiler. Any pointers for where I have to look at? > > I recommend you look at compiler/simplCore/CSE.lhs. It is a simple > example of a core-to-core pass. > > However, in short you'll need to: > 1) Create a function which implements your core to core pass, of a > type such as [CoreBind] -> [CoreBind] > *) If that function lives in a new module, edit ghc.cabal.in to tell > the build system about the module > 2) Add a constructor to the CoreToDo data type in > compiler/simplCore/CoreMonad.lhs > 3) Add a case for it to the coreDumpFlag and Outputable instance > 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The > order of the list is the order the passes will be run in. > *) If you want the pass to be under the control of a new flag, you'll > need to add a new dynflag - add a constructor to the DOpt data type in > compiler/main/DynFlags.lhs, and add something to build that > constructor to one of the lists that get fed to the command line > handling code in the same module. It should be fairly obvious how to > do this. > 5) Add a handler for the new constructor to > compiler/simplCore/SimplCore.lhs, in the doCorePass function which > calls into the core pass function you wrote > > Hope that helps, > Max > Yes, that helped quite a lot. One last thing: currently it takes me about 6 minutes to rebuild the compiler after I change the core pass. Are there any tricks of the build system I can use to speed this up? I'm already using a fast build without optimizations and docs... Thanks, Pedro

3 3

bug in template haskell (with recursion?)
by Jake Wheat 28 Jan '10

28 Jan '10

Hello All, I'm trying to write a splice to make HList type signatures a bit more concise, I don't know whether this is a good idea or not. I wrote a small function to do '[(Type,Type)] -> Q Type' for this, and got the following from GHC. Should I add this to the bug tracker? Details: THBug1.hs: {-# LANGUAGE TemplateHaskell #-} module THBug1 where import Data.HList import Language.Haskell.TH mhlt :: [(Type,Type)] -> Q Type mhlt x = [t| Record $(foldThing x)|] where foldThing ((f,t):xs) = [t|HCons (LVPair (Proxy $f) $t) $(foldThing xs)|] foldThing [] = [t|HNil|] ---- $ ghc -c THBug1.hs THBug1.hs:12:61: GHC internal error: `foldThing' is not in scope during type checking, but it passed the renamer tcg_type_env of environment: [] In the expression: foldThing xs In the Template Haskell quotation [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] In the expression: [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] I'm using GHC 6.12.1 from debian experimental: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ ghc-pkg list |grep template template-haskell-2.4.0.0 To get HList to install with GHC 6.12, I downloaded the latest version from http://old-darcs.well-typed.com/HList/ and altered it slightly, updated package here: http://launchpad.net/hssqlppp/prealpha/environment/+download/HList-0.2.tar.… the changes I made are: diff -rN old-HList/Data/HList/GhcSyntax.hs new-HList/Data/HList/GhcSyntax.hs 2c2 < {-# LANGUAGE FlexibleContexts #-} --- > {-# LANGUAGE FlexibleContexts, TypeOperators #-} diff -rN old-HList/Data/HList/Label2.hs new-HList/Data/HList/Label2.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 36c37 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities diff -rN old-HList/Data/HList/Label3.hs new-HList/Data/HList/Label3.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 37c38 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities (If it's not obvious, I have no idea what I'm doing..., but my small amount of code which uses HList worked fine with this altered package.) Thanks, Jake Wheat

1 1

tracing messages
by Serge D. Mechveliani 28 Jan '10

28 Jan '10

Dear GHC team, this is on tracing in ghc-6.12.1 (made from source on Debian Linux i-386-like machine). I wonder what is the reason for this tracing message (starting with `Step1 ...' ): ---------------------------- ... equations calc = [j < i -> true, m <= p -> true, p <= q -> true, q <= n -> true, (A p) <= (A q) -> false, (X <= Y) | (Y < X) -> true, | {not (Y <= n), not (m <= X), not (X < i), not (j < Y), (A X) <= (A Y)} -> true, | {not (X <= Y), not (Y <= j), not (m <= X), (A X) <= (A Y)} -> true, | {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25. Pre-reduction done. Initial numbers of equations is 9, after reduction: 9, the pre-reduction cost is 484. ... ... ---------------------------- The main program does the following in succession: 1) finds eqs, 2) prints "equations calc =\n", shows eqs "\n\n", "Starting completion.\n", "remaining goals = ", 3) finds res by completion (`complete'), 4) prints shows (completionGoalRem res) "\n" The trace calls are set only in the function `complete'. The above message Step 1. Starting mutual pre-reduction. The number of rules is 25. Pre-reduction done. Initial numbers of equations is 9, occurs the first message of this tracing. But the main program must have printed the full last equation in eqs, and only after this any tracing message could appear. Instead, it breaks the last equation printing with the tracing messages. The further evaluation is long, so I interrupted it, without seeing the final result. But this printing break looks strange, because eqs does not depend on the results of `complete', the reverse holds: the latter applies to eqs. Generally, I often observe an effect of this kind; it is harmless, but I wonder, what might be the reason. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

FW: GHC core plugins
by Simon Peyton-Jones 28 Jan '10

28 Jan '10

-----Original Message----- From: Simon Peyton-Jones Sent: 28 January 2010 07:50 To: 'austin s' Subject: RE: GHC core plugins compiler/cmm/ZipDataFlow.hs But we have great ideas for making it much simpler and more modular. In progress.. S | -----Original Message----- | From: mad.one(a)gmail.com [mailto:mad.one@gmail.com] On Behalf Of austin s | Sent: 27 January 2010 16:24 | To: Simon Peyton-Jones | Subject: Re: GHC core plugins | | 2010/1/27 Simon Peyton-Jones <simonpj(a)microsoft.com>: | > | Also, is Hoopl expected to be used on core -> core plugins, and, if so, | is | > | the | > | infrastructure in place for this? | > | > no, Hoopl works on imperative control flow graphs, the C-- part of the back | end, not on Core. | > | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | Quick Question, even if it is OT: Is the Hoopl code available anywhere? | | -- | - Austin

1 0