- Glasgow-haskell-users

Using GHC-as-a-library
by Martin Grabmueller 12 Oct '06

12 Oct '06

Hello all, I've been playing around with GHC-as-a-library a bit now, and using yesterday's snapshot of GHC (ghc-6.5.20061004, compiled from source), I ran into the following problem: When using the Haskell program at the end of this mail, it compiles fine (after exposing the ghc package with ghc-pkg), but when running it complains: Main: Can't find package.conf as /usr/local/ghc/lib/ghc-6.5.20061004/driver/package.conf.inplace So it seems to search for a package.conf file in the build tree instead of an installed one. Passing in the path to the build tree (commented out in the program) to GHC.newSession works. Has anyone else encountered this problem? There is probably only a small fix necessary, but I have not yet been able to figure it out by myself. Thanks, Martin module Main where import qualified GHC import DynFlags (defaultDynFlags) import Outputable (ppr, showSDoc, text, (<+>), ($$), empty) import BasicTypes import Data.List -- This should work, but compiler complains: -- Main: Can't find package.conf as -- /usr/local/ghc/lib/ghc-6.5.20061004/driver/package.conf.inplace my_ghc_root = "/usr/local/ghc/lib/ghc-6.5.20061004" -- This does work: --my_ghc_root = "/home/misc/src/ghc-6.5.20061004" main = GHC.defaultErrorHandler defaultDynFlags $ do let ghcMode = GHC.JustTypecheck -- Create GHC session, passing GHC installation directory session <- GHC.newSession ghcMode (Just my_ghc_root) dflags0 <- GHC.getSessionDynFlags session GHC.defaultCleanupHandler dflags0 $ do GHC.setSessionDynFlags session dflags0 putStrLn "New session defined" let testModule = (GHC.mkModuleName "Test") t <- GHC.guessTarget "Test.hs" Nothing GHC.setTargets session [t] ok <- GHC.load session GHC.LoadAllTargets if failed ok then putStrLn "Loading failed!" else putStrLn "Loading OK!" checked <- GHC.checkModule session testModule case checked of Nothing -> putStrLn "Couldn't check" Just (GHC.CheckedModule parsed renamed typechecked info) -> do putStrLn (showSDoc (ppr parsed)) putStrLn (showSDoc (ppr renamed)) putStrLn (showSDoc (ppr typechecked)) putStrLn (showSDoc (case info of Just cm | Just scope <- GHC.modInfoTopLevelScope cm -> let (local,global) = partition ((== testModule) . GHC.moduleName . GHC.nameModule) scope in (text "global names: " <+> ppr global) $$ (text "local names: " <+> ppr local) _ -> empty))

3 3

docs "not found" on GHC page
by Serge D. Mechveliani 12 Oct '06

12 Oct '06

I go by brouser to www.haskell.org/ghc, click at `Documentation', at `HTML.tar.gz' on The User's Guide ... Download: | HTML.tar.gz | PDF | A4 Postscript (gzipped) | And it responds The requested URL /ghc/docs/latest/users_guide.html.tar.gz was not found on this server. Is this a bug on the GHC page? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: [Haskell-cafe] GHC Core still supported?
by Simon Peyton-Jones 11 Oct '06

11 Oct '06

Jim, and others (I'm ccing GHC users) External Core is a feature of GHC that is lonely and unloved. External Core longs to have someone to look after it, tell it that it is a Truly Useful Feature, and keep it working. Seriously, External Core has a strong tendency to bit-rot because (so far as I can tell) few people seem to use it, and hence it can lag behind changes in the rest of the compiler. Yes, in principle we at GHC HQ should push the entire compiler along in sync, but there are just too few hours in the day. Another contributory factor is that some of the things you might use External Core for can now be done by using the GHC API. So the true answer to your title line "Is External Core still supported?" is "there is no reason it can't be, but in fact at the moment it probably doesn't work right". I think this is a pity because External Core is a pretty good way for people interested in analyses and back ends to use GHC as a front end that translates all of Haskell into a small intermediate language. But all is not lost. External Core is a good example of a feature that doesn't require deep knowledge of GHC's internals to understand and maintain, so it's perfect for someone else to undertake. Is anyone (or a group of people) interested? We'd give plenty of support to such an effort. Meanwhile, if you want to use External Core, but can't because it doesn't work properly for you, don't be afraid to yell. (E.g. File a Trac bug report.) I don't want to promise an immediate fix, but the more people that use it the keener we are to get it done. thanks Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jim | Apple | Sent: 11 October 2006 02:35 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] GHC Core still supported? | | In http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html | , I see two notes that I can't verify: | | 1. I don't see any CORE pragma on | http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html | | 2. Using GHC 6.5.20060920, I compile | | module Core where | data Foo = Bar | | with -fext-core to get | | %module main:Core | %data main:Core.Foo = | {Bar}; | | I then compile the resulting hcr file with no flags to get | | <no location info>: | 1: Parse error | : | %data main:Core.Foo = | {Bar}; | | Jim | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

UTF-8 decoding error
by Christian Maeder 10 Oct '06

10 Oct '06

How can I convince ghc version 6.5.20060919 to accept latin1 characters in literals? I wish to keep source files (containing umlauts in strings) that can be compiled by either ghc-6.4.2 and ghc-6.6. Christian

6 15

RE: [Haskell] Expecting more inlining for bit shifting
by Simon Peyton-Jones 09 Oct '06

09 Oct '06

For small functions, GHC inlines them rather readily. For big functions GHC doesn't inline them. For medium-sized functions, GHC looks at the arguments; if they look interesting (e.g. are a constant) then it inlines the function. So the behaviour you want will happen for certain settings of the unfolding-use-threshold. But at the moment there is no way to add a pragma saying "inline if my second argument is a constant". One could imagine such a thing, but it's not there today, I'm afraid. Simon | -----Original Message----- | From: roconnor(a)theorem.ca [mailto:roconnor@theorem.ca] | Sent: 09 October 2006 15:08 | To: Simon Peyton-Jones | Cc: GHC users | Subject: RE: [Haskell] Expecting more inlining for bit shifting | | On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: | | > Turns out that 'shift' is just too big to be inlined. (It's only called | > once, but you have exported it too.) | > | > You can see GHC's inlining decisions by saying -ddump-inlinings. | > | > To make GHC keener to inline, use an INLINE pragma, or increase the | > inlining size threshold e.g. -funfolding-threshold=12 | | Okay, when I force inlining for shift, (and I even need to do it for | shiftR!) then the code is inlined in C. However this isn't the behaviour | I want. Ideally the inlining should only happen when/because the second | argument of shift is constant and the system knows that it can evaluate | the case analysis away and that makes the function small. | | Am I being too naive on what to expect from my complier or is this | reasonable? | | PS, is there a way to mark an imported instance of a class function | (Data.Bits.shift for Data.Word.Word32) to be inlined? | | -- | Russell O'Connor <http://r6.ca/> | ``All talk about `theft,''' the general counsel of the American Graphophone | Company wrote, ``is the merest claptrap, for there exists no property in | ideas musical, literary or artistic, except as defined by statute.''

1 0

Keyword foreign
by Christian Maeder 09 Oct '06

09 Oct '06

Could some add to the user guide at: http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-featur… that -ffi and -fffi is (currently) implied by -fglasgow-exts? (as stated in the flag reference) in the same way as it is stated under -fimplicit-params or -fth in section 7.1. Language options? Therefore the keyword "foreign" gets into scope by -fglasgow-exts. And maybe this word and others should be added to http://haskell.org/haskellwiki/Keywords, because "forall" is listed and only available with -fglasgow-exts? Christian

2 1

ANNOUNCE: GHC 6.6 Second Release Candidate
by Ian Lynagh 09 Oct '06

09 Oct '06

We are pleased to announce the Second Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20061001 are release candidates for 6.6 We would be particularly interested to hear whether or not the 6.6 RC works for people who were having trouble with 6.4.2. Also, please note that the GHC API has changed since the last RC as a result of some feedback from the Hackathon, so you may want to check that any applications using it still work. Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src-extralibs… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! We expect to release in about a week's time. Thanks Ian

8 15

RE: [Haskell] Expecting more inlining for bit shifting
by Simon Peyton-Jones 09 Oct '06

09 Oct '06

[Redirecting to GHC users.] Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | roconnor(a)theorem.ca | Sent: 09 October 2006 00:41 | To: haskell(a)haskell.org | Subject: [Haskell] Expecting more inlining for bit shifting | | Consider the following GHC code: | | module Main where | | import GHC.Word | import GHC.Base | import GHC.Prim | import Random | | a `shiftRLT` b | b >=# 32# = int2Word# 0# | | otherwise = a `uncheckedShiftRL#` b | | (W32# x#) `shift` (I# i#) | | i# >=# 0# = W32# (narrow32Word# (x# `shiftL#` i#)) | | otherwise = W32# (x# `shiftRLT` negateInt# i#) | | x `shiftR` i = x `shift` (-i) | | shift7 x = x `shiftR` 7 | shift6 (W32# x) = (W32# (x `uncheckedShiftRL#` 6#)) | | main = do | xs <- sequence (replicate 1000000 | (fmap (shift7 . fromIntegral) (randomIO::IO Int))) | print (sum xs) | | I have copied the definition of `shiftR` for Word32 into this file. | | Suppose we want to shift a series of numbers by 7 bits. One would expect | GHC's inliner to notice that (-7) is indeed not greater than 0, and | eliminate the branch in the definition of `shift`. Further one would | expect GHC to notice that 7 is indeed not gtreater than 32, and eliminate | the branch in shiftRLT. Thus one would expect the code generated by using | shift7 to be identical to that being generated by shfit6 (with 7 replaced | by 6). | | But this appears not to be the case. The code generated for shift7 (if I | can read the C code correctly) is: | Sp[-1] = (-0x7U); | Sp[-2] = R1.p[1]; | *Sp = (W_)&s2za_info; | Sp=Sp-2; | JMP_((W_)&Main_zdwshift_info); | | while the code generated for shift6 is the lovely: | | Hp=Hp+2; | if ((W_)Hp > (W_)HpLim) goto _c2Aa; | _s2xq = (R1.p[1]) >> 0x6U; | Hp[-1] = (W_)&GHCziWord_W32zh_con_info; | *Hp = _s2xq; | R1.p=Hp-1; | Sp=Sp+1; | JMP_(*Sp); | _c2Aa: | HpAlloc = 0x8U; | JMP_(stg_gc_enter_1); | | My question is, why the discrepency? | | -- | Russell O'Connor <http://r6.ca/> | ``All talk about `theft,''' the general counsel of the American Graphophone | Company wrote, ``is the merest claptrap, for there exists no property in | ideas musical, literary or artistic, except as defined by statute.'' | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

ghc 6.6 user guide on haskell.org
by Bulat Ziganshin 09 Oct '06

09 Oct '06

Hello glasgow-haskell-users, i don't see updates in ghc 6.6 users guide on the haskell.org (for example, http://www.haskell.org/ghc/dist/current/docs/users_guide/ghc-language-featu… still contains "-fno-monomorphism-restriction,-fno-monomorphism-restriction" line). can you please restore automatic updates of these pages with current changes in users guide? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

GHC API: Problems with implementing ":reload" for "ghc --make"
by Brian Smith 09 Oct '06

09 Oct '06

Hello all, My goal is to write a program GhcRemake that works like "ghc --make." However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit <ENTER>. When I hit <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc --make" again with the same arguments. The benefit of such a program is that GhcRemake should be able to cache a lot of data in memory between invocations and hopefully be able to do the subsequent re-makes much faster. I tried to do this by using the GHC API, and doing the initial build and all subsequent builds in the same session. My program seems to work fine when run on itself and when run on Cabal. But, these two packages seem to be too small to notice any reduction of building time. So, I decided to test my program by building the GHC API with it. Unfortunately, it seems like every build after the first one in the session does the dependency analysis badly, and things get recompiled unnecessarily. In the tests below, you can tell when things get recompiled because you will see a lot of warning messages (due to the -W parameter). Probably this is due to a mistake on my part but I can't figure out what it is. I would be very grateful if somebody could point out what I am doing wrong or what the problem is. I basically copied 90% of the code for the program from GHC's Main.hs, so it should be familiar to people on the GHC team. You need to be using a recent GHC 6.5. snapshot for everything described below. Here is the test procedure: 1. I run the program and it will do the intial make, just like ghc --make does. 2. I quit the program (type "quit" <ENTER>). 3. I run the program. It notices that nothing needs to be recompiled. 4. I quit the program. 5. I run ghc --make. It notices that nothing needs to be recompiled. 6. I run the program again, and it notices that nothing needs to be recompiled. 7. Instead of quitting, I hit <ENTER> to re-make the library. But now, GhcRemake thinks that a lot of things need to be recompiled. It should notice that nothing needs to be recompiled. 8. After I let it recompile, I hit <ENTER> to re-make the library again. But, again, it things a lot of things need to be recompiled. Again, it should notice that nothing needs to be recompiled. 9. I quit the program (type "quit" <ENTER>). 10. now I run a ghc --make. But, ghc --make things things need to be recompiled too. It should have noticed that nothing needs to be recompiled. 11. If I run the program again, it notices that nothing needs to be recompiled. 12. But, if I hit <ENTER> to re-make the program, it suddenly thinks that many source files need to be compiled. It should have noticed that nothing needs to be recompiled. The ghc --make command I am using to build the GHC API is: cd ghc/compiler ghc --make GHC -package-name ghc -package base -package template-haskell -package Cabal -package Win32 -package regex-compat -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -fglasgow-exts -fno-generics -DBREAKPOINT -DDEBUG -recomp -cpp -include"cutils.h" -Istage2 -I. -Iparser -keep-tmp-files -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -icoreSyn -ispecialise -isimplCore -istranal -isimplStg -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -ighci -ideSugar -icodeGen -inativeGen -icmm -istgSyn To build my program, you just need to change the pathToGHC variable in its source code, and then use ghc --make: ghc --make -fffi GhcRemake -package ghc -package Cabal or you can use Cabal: runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install Then, to run my program, just give it the same arguments as you gave "ghc --make" (without "--make"): cd ghc/compiler path/to/GhcRemake.exe GHC -package-name ghc -package base -package template-haskell -package Cabal -package Win32 -package regex-compat -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -fglasgow-exts -fno-generics -DBREAKPOINT -DDEBUG -recomp -cpp -include"cutils.h" -Istage2 -I. -Iparser -keep-tmp-files -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -icoreSyn -ispecialise -isimplCore -istranal -isimplStg -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -ighci -ideSugar -icodeGen -inativeGen -icmm -istgSyn BTW, I am planning to extend this program in many ways in the future, including a ":make" command for GHCi, an "--interactive --make" mode for GHC itself. Eventually, I would like to implement a "quick error checking with automatic background compilation" mode as well. Thanks, Brian Smith

1 0