- Glasgow-haskell-users

Re: packaging options for Mac OS X
by Ian Lynagh 29 Nov '10

29 Nov '10

On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote: > > Outstanding question is what should this framework be called? I would like to continue to call it GHC.framework, but change the version to something like 7.0.1+HP-i386, I think it ought to be called Haskell-Platform.framework. > [*] The binary GHC distribution could be > - built by the GHC team, and asking them for a tarball (as Duncan suggested) I do "make framework-pkg" to build the OS X installer, but it's essentially a black box to me. We're happy to accept patches that make this also produce a bindist, though. Now that we have the Haskell Platform, perhaps we should stop making GHC OS X installers, and only make plain old unix bindists. Thanks Ian

2 2

SpecConstr number of specializations (-fspec-constr-count)
by José Pedro Magalhães 29 Nov '10

29 Nov '10

Hi all, When compiling some program with -O2 using ghc-7.0.1, I got warnings like > SpecConstr > Function `$j_s7Xo{v} [lid]' > has three call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > SpecConstr > Function `$j_s7YI{v} [lid]' has 7 call patterns, but the limit is 3 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > I proceeded to compile with -fspec-constr-count=10, but I still got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > With -fspec-constr-count=55, I got > SpecConstr > Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 6 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > Finally, with -fspec-constr-count=56, the warnings disappear. Is this a bug, or is the value of spec-constr-count being manipulated in some way for certain passes? Thanks, Pedro

3 3

How to activate DEBUG in Data.HashTable?
by Wolfram Kahl 29 Nov '10

29 Nov '10

Hello, with a large Agda development, I have a reproducible segmentation fault that I have been able to localise to the serialisation (Agda.TypeChecking.Serialise.encode), which heavily relies on Data.HashTable. Now I find that Data.HashTable (from GHC-7.0.1) has a CPP-enabled DEBUG version --- is there a ``proper'' way to activate this? Possibly even so that it can be added ex-post to an existing installation? (So I don't have to re-install all packages.) mk/ways.mk says that the ``debug'' way only affects the RTS... Wolfram

2 1

Modifying functions in the typechecker?
by Nils Schweinsberg 29 Nov '10

29 Nov '10

Hi, I'm currently working on a GHC extension called "monad comprehensions" [1]. Typechecking for generators ("pat <- rhs") already works, but filters are a bit more tricky. Basicly, it works like that: A monad comprehension... [ body | E ] -- E :: Bool ...should desugar to: Control.Monad.guard E >> return body In the typechecker I typecheck E for type Bool, and see if we're in a MonadPlus by typechecking "guard". But I have to "pass" this guard-then-op function to the desugarer, so I created a new expression "then_op' = (>>) . guard" and pass this function to the ExprStmt constructor. The code in typecheck/TcMatches.lhs looks currently like this: tcMcStmt _ (ExprStmt rhs then_op _) res_ty thing_inside = do { -- Typecheck rhs on type Bool rhs' <- tcMonoExpr rhs boolTy -- Deal with rebindable syntax: -- then_op :: rhs_ty -> new_res_ty -> res_ty -- See notes in tcDoStmt. -- After this we redefine then_op to have the following type: -- then_op' :: Bool -> new_res_ty -> res_ty -- then_op' = (>>) . guard ; rhs_ty <- newFlexiTyVarTy liftedTypeKind ; new_res_ty <- newFlexiTyVarTy liftedTypeKind ; let then_ty = mkFunTys [rhs_ty, new_res_ty] res_ty guard_ty = mkFunTys [boolTy] rhs_ty comp_ty = mkFunTys [then_ty, guard_ty, boolTy, new_res_ty] res_ty ; then_op <- tcSyntaxOp MCompOrigin then_op then_ty ; guard_op <- tcSyntaxOp MCompOrigin (HsVar guardMName) guard_ty ; compose_op <- tcSyntaxOp MCompOrigin (HsVar composeName) comp_ty ; let then_op' = HsApp (nlHsApp (noLoc compose_op) (noLoc then_op)) (noLoc guard_op) ; thing <- thing_inside new_res_ty ; return (ExprStmt rhs' then_op' boolTy, thing) } Is this a valid approach? Should I move the "(>>) . guard" function somewhere else? I had a look at the renamer where "(>>)" is added to the statement "ExprStmt" the first time, but apparently you cannot call "tcSyntaxOp" in the typechecker on this function if you construct it with "HsApp (compose_op `HsApp` then_op) guard_op". Is there another function which could typecheck such a constructed expression without telling the user what functions we've used? I also had a look at the MDo typechecker, where they use this: ; let names = [mfixName, bindMName, thenMName, returnMName, failMName] ; insts <- mapM (\name -> newMethodFromName DoOrigin name m_ty) names ; return $ mkHsWrapCoI coi $ HsDo (MDoExpr (names `zip` insts)) stmts' body' res_ty' } So they can use these names with their typechecked versions in the desugarer. But if I do this for monad comprehensions and "guard", *every* monad comprehension will require a MonadPlus instance, which shouldn't be necessary if there are no filter expressions. Any advice on how this could be solved? Thanks, Nils [1]: http://hackage.haskell.org/trac/ghc/ticket/4370

2 1

Re: [Haskell-cafe] Re: Eq instance for Chan
by Mitar 25 Nov '10

25 Nov '10

Hi! On Thu, Nov 25, 2010 at 5:37 PM, Bas van Dijk <v.dijk.bas(a)gmail.com> wrote: > Officially your patch has to go through the "Library submission" process: A bit overkill for one line but OK. ;-) > Since you already have a ticket the only thing left to do is convert > your patch to a darcs patch and send a proposal to the libraries list. I just have. I attached your patch to the ticket. Thanks. Mitar

1 0

Eq instance for Chan
by Mitar 25 Nov '10

25 Nov '10

Hi! Why is there no Eq instance for Chan? There is Eq for MVar so it is quite possible to define also Eq for Chan? What I would like to do is keep track how many consumers I have for each Chan so duplicating them with dupChan as necessary. So I was thinking of storing a list of Chans which already have a consumer and then duplicating it if another (and every additional) consumer would be added. But without Eq it is not possible to check if there is Chan already in a list (and I hope Eq would compare just Chan and not its content). Is there some other way to achieve this? Mitar

2 2

Implementation of "Scalable Event Handling for GHC"
by tsuraan 23 Nov '10

23 Nov '10

I just read the article "Scalable Event Handling for GHC" by Sullivan and Tibell, and I was wondering if its implementation has been incorporated into the mainline GHC yet. I'm sure the information is out there, but I'm having a bit of trouble searching on it. If it has been integrated into mainline GHC, what version would I need to run to try it out, and is there any documentation on what sort of things I need to do to ensure that the new IO core is being used?

4 5

make tags in GHC build
by John Pybus 20 Nov '10

20 Nov '10

Hi, The documentation suggests that I should be able to do "make tags" to get a vim tags file for the GHC code. http://hackage.haskell.org/trac/ghc/wiki/Building/StandardTargets When doing this on a recent GHC checkout I get: ghctags: user error (You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.9999, now Cabal-1.11.0). Additionally the compiler is different (was ghc-6.12, now ghc-7.1) which is probably the cause of the problem.) make[1]: *** [tags_compiler] Error 1 make: *** [tags] Error 2 rerunning ./configure doesn't make any difference. (building on Ubuntu 10.04 amd64, with haskell platform packages) Does anyone know how to get make tags to work? Thanks, John

1 0

Re: Support for compiler plugins in GHC HEAD
by austin seipp 20 Nov '10

20 Nov '10

Hello, I've updated the patch with a few validate fixes (failings due to -Werror) and a few other things. I've instead uploaded the patch here (to avoid g-h-u and cvs-ghc from blocking me due to a large message so people can see): http://hacks.yi.org/~as/code/ghc/ghc_plugins_support_2010_11_19.dpatch and updated it on the trac page. I'll continue updating the patch on my server to reflect the most recent changes as they come in. Original message below. Regards, Austin On Fri, Nov 19, 2010 at 8:06 PM, austin seipp <as(a)hacks.yi.org> wrote: > Hello everybody, > > (CC'ing max and cvs-ghc in case people lurk in different spots.) > > I have spent the past day and taken the liberty of updating Max > Bolingbroke's original patches for supporting compiler plugins in GHC, > and making > them work with the latest version of GHC HEAD (7.1.x.) > > It is very sad IMO that this work went by so long without being merged > mainline, but the CoreM and Annotations code was merged into mainline > long > long ago before the advent of dynamic linking (and many other things) > in GHC. This part of the task floundered around and so I decided to do > something about it. > > I would like to see this code merged mainline and supported in future > major releases of GHC. I am willing to take responsibility for > updating and maintaining it > and bringing it up to the code quality standards the GHC team expects > (which I'm sure which will be necessary.) It is early in the GHC 7.2 > development cycle, so ideally > it could be merged soon so we have as long as possible to fix bugs and > change things if necessary until the 7.2 release. > > Most of the code is written by Max originally and perhaps slightly > modified by me to update it with changes to the simplifier and linker > interface. Most of it was untouched, actually. > > It has been tested only on my linux machine (debian x86_64, kernel > 2.6.34,) with GHC 7.1.x x86_64. I also have a macbook I can test the > patches on (x86_64 darwin, snow leopard, i386 ghc 7.1.x) but I > have yet to get around to it. > > The patch is quite small actually (smaller than max's original, > although I intentionally left out things that were unnecessary or > refactorings) so hopefully reviewing it is not much of a burden on you > guys at > GHC HQ. > > Caveat: I have not yet ported over Max's testsuite patches, which just > build a plugin and expect some output when run. I'm getting around to > it although I have to figure out the test suite infrastructure a > little > first I guess. > > ============================================== > == Getting the patch and using it > > I have uploaded the patch onto the relevant trac ticket here: > http://hackage.haskell.org/trac/ghc/ticket/3843 > > It is also attached to this email. In the future I might put up a GHC > repo on my webserver so you can just directly pull patches from it (I > like this more than emailing patches around, personally) with darcs. > > After you download the patch and apply it with darcs, go ahead and > build the regular stage2 compiler (do "perl boot; ./configure; make > -j3" for dual core, etc.) > > Then, download this CSE plugin from github, load it and compile the > example (again, originally written by Max and slightly modified to > work by myself): > > https://github.com/thoughtpolice/cse-ghc-plugin > > Like so: > > $ pwd > /home/a/ > $ cd src > $ git clone git://github.com/thoughtpolice/cse-ghc-plugin.git > $ cd cse-ghc-plugin > > # assumes your GHC build is in ~/src/ghc-head+plugins/ > $ cabal install -w ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 > ... > > #plugin now installed, we can use it: > $ cd tests > $ pwd > /home/a/src/cse-ghc-plugin/tests/ > $ ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 -fforce-recomp > -fno-cse Traced.hs > [1 of 1] Compiling Main ( Traced.hs, Traced.o ) > Linking Traced ... > $ ./Traced > The test is successful if the word 'Evaluated' appears only once below: > Evaluated > Evaluated > # now do CSE through the plugin we installed > $ ~/src/ghc-head+plugins/inplace/bin/ghc-stage2 -fforce-recomp > -fno-cse Traced.hs -fplugin=CSE.Plugin > [1 of 1] Compiling Main ( Traced.hs, Traced.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Loading package array-0.3.0.2 ... linking ... done. > Loading package containers-0.4.0.0 ... linking ... done. > Loading package filepath-1.2.0.0 ... linking ... done. > Loading package old-locale-1.0.0.2 ... linking ... done. > Loading package old-time-1.0.0.6 ... linking ... done. > Loading package unix-2.4.1.0 ... linking ... done. > Loading package directory-1.1.0.0 ... linking ... done. > Loading package pretty-1.0.1.2 ... linking ... done. > Loading package process-1.0.1.4 ... linking ... done. > Loading package Cabal-1.11.0 ... linking ... done. > Loading package bytestring-0.9.1.8 ... linking ... done. > Loading package binary-0.5.0.2 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hpc-0.5.0.6 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package ghc-7.1.20101120 ... linking ... done. > Loading package cse-plugin-1.0 ... linking ... done. > Linking Traced ... > $ ./Traced > The test is successful if the word 'Evaluated' appears only once below: > Evaluated > $ > > I'm currently validating my patch against the HEAD tree, but I > speculate there won't be any problems (nothing huge has really changed > honestly, and nothing happens when you don't invoke a plugin.) > > Max also wrote 2 other plugins, a strictifier (transforms haskell into > a strict language) and a loop unroller, but I have yet to update them. > > All comments are welcome (here or in trac.) > > Regards, > Austin >

1 0

How to optimize the memory usage of "linking"?
by Magicloud Magiclouds 19 Nov '10

19 Nov '10

Hi, When I use ghc to make large project, the almost-final step of linking takes a lot of memory. This is horrible on host with little memory (i.e. 512MB). Is there any way I can optimize this? Thanks. -- 竹密岂妨流水过山高哪阻野云飞

2 1