- Glasgow-haskell-users

Using GHC API to generate STG
by Mark Wassell 15 Apr '08

15 Apr '08

Hello, I am looking at how GHC generates STG and I am finding with a very simple piece of Haskell my usage of the API is not generating as much STG as I see when using -dump-stg option. In particular it isn't generating a binding for the nullary constructor LNull (I hope that's the correct terminology) The code is module Ex2 where data List a = LCon a (List a) | LNull -- deriving Show main :: List Int main = LCon 1 LNull Using the API I get [sat_s1pdQ = NO_CCS GHC.Base.I#! [1]; Ex2.main = NO_CCS Ex2.LCon! [sat_s1pdQ Ex2.LNull]; main = \u srt:SRT:[(s1pdS, Ex2.main)] [] Ex2.main;] with -ddump-stg I get a_r5Y = NO_CCS GHC.Base.I#! [1]; SRT(a_r5Y): [] Ex2.main = NO_CCS Ex2.LCon! [a_r5Y Ex2.LNull]; SRT(Ex2.main): [] Ex2.LCon = \r [eta_s67 eta_s68] Ex2.LCon [eta_s67 eta_s68]; SRT(Ex2.LCon): [] Ex2.LNull = NO_CCS Ex2.LNull! []; <---- This is missing SRT(Ex2.LNull): [] (in particular the Ex2.LNull is missing from the API STG) My thrown together API code is session <- GHC.newSession $ Just path (dflags,_) <- GHC.getSessionDynFlags session >>= Packages.initPackages GHC.setSessionDynFlags session dflags {GHC.hscTarget=GHC.HscAsm} core <- GHC.compileToCore session fp case core of Just core' -> do core'' <- corePrepPgm dflags core' [] stg <- coreToStg (PackageConfig.stringToPackageId "Ex2") core'' putStrLn $ (show $ (ppr stg) defaultDumpStyle) Nothing -> return () Mark

2 1

GHC API (parsing)
by Johannes Waldmann 15 Apr '08

15 Apr '08

Dear all, how can I convince the Language.Haskell.Parser to accept "GHC Haskell" (i.e., -fglasgow-exts, e.g. for existential types) or: how can I convince the GHC API loader to parse a module from a string (not from a file)? Any hints appreciated, Johannes.

5 9

Sending binary files through a socket
by Ivan Salazar 15 Apr '08

15 Apr '08

Hello, I'm having a lot of trouble sending binary files through a socket (I'm trying to program a very minimalistic webserver) but I just can't find a way to read and send binary files, even though, plain text and html documents are sent correctly. My code looks something like this: sendResource handle name = do exist <- doesFileExist name isFile <- liftM not (doesDirectoryExist name) if exist && isFile then do resource <- Data.ByteString.readFile name hPutStr handle (header ++ fileType ++ "\n") hSetBinaryMode handle True hPutStr handle resource else do hPutStr handle page404 where fileType = maybe ("text/plain") (flip const []) (lookup (takeExtension name) extensions) Thanks for your help in advance. PS: Yes, I'm terribly newbie to Haskell.

1 0

Re: GHC API (parsing)
by Johannes Waldmann 14 Apr '08

14 Apr '08

> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts… interesting, I'll look into that. * it's not exactly a drop-in replacement for Language.Haskell.* ? (HsNewTypeDecl is different?) * for the others, number of constructor arguments does not match, e.g. `HsConDecl' should have 2 arguments, but has been given 3 * how is your parser tied to ghc? I.e. what happens if the next ghc release introduces new syntax? general question * is there any parser that keeps comments (i.e. makes AST nodes from them)? what parser does Haddock use? Best regards, J.W.

4 4

Re: [Haskell-cafe] more on my ghc package issues
by Duncan Coutts 13 Apr '08

13 Apr '08

On Sat, 2008-04-12 at 23:33 -0500, Galchin, Vasili wrote: > 2) This strongly looks like the package database manager, i.e. > ghc-pkg. Source please so I can understand where this d*amn "unknown > package: unix-2.3.0.0" message is coming from and why? Yes, ghc/ghc-pkg is giving this message because you're trying to use a package that depends on a package that you unregistered. In your case, you unregistered unix-2.3.0.0 but process-1.0.0.0 depended on that. Cabal depends on process-1.0.0.0 which means you now cannot runghc Setup.hs scripts because they all import Cabal. Look at the output of ghc-pkg list. It marks in {} the packages that are broken due to missing dependencies. Remember you also have two package databases, the per-user one and the global one. The per-user one is stored under ~/.ghc You can see the exact path in the ghc-pkg list output. The packages from the user db mask those from the global db, so if you have messed up the per-user one then you will still get problems even if you reset the global one to default. If you're just trying to get back to a known state then you can delete the per-user ghc package db. ghc-pkg will re-create it next time you register a package as a user. > 3) Serious rant mode on ... I am a computer industry veteran(decades) > who is trying to convince, coggle, etc. younger colleagues about the > usefulness of FPLs for correctness, etc, and then => "unknown > package ....". The error messages from ghc-pkg are not very helpful and it does not prevent you from removing packages which other packages still depend on. The best advice at the moment is, don't un-register packages, at least not without considering what other packages still depend on them. There's no easy way of doing a reverse dependency lookup I think yet via ghc-pkg. You can see direct dependencies, eg $ ghc-pkg field containers depends depends: base-3.0.1.0 array-0.1.0.0 As it happens, the latest version of Cabal gives a much better error message in the case that you try to configure a package that depends on a broken package. It says exactly which package is broken due to which missing dependency. In this case we'd get a message like: The following installed packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. package process-1.0.0.0 is broken due to missing package unix-2.3.0.0 It would be nice if ghc/ghci/runghc could give a similarly helpful error message. Duncan

1 0

Wrong Answer Computing Graph Dominators
by Denis Bueno 12 Apr '08

12 Apr '08

I'm using the Data.Graph.Inductive.Query.Dominators library (http://haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Inductive-…) The library is a bit spare on comments, so I may or may not be using it correctly. My goal is to compute the set of nodes that dominate two different nodes of a DAG, with respect to one initial node. My approach is: import qualified Data.Graph.Inductive.Graph as Graph import qualified Data.Graph.Inductive.Query.Dominators as Dom uips = intersect domConfl domAssigned :: [Graph.Node] -- my goal domConfl = fromJust $ lookup conflNode domFromLastd -- dominators of first node domAssigned = fromJust $ lookup (negate conflNode) domFromLastd -- dominators of second node domFromLastd = Dom.dom conflGraph lastd -- source node I compute the dominators individually and my answer is their intersection. When I call the dom function, my assumption is that I need to pass it the source node, and it tells me, for any node x to which there is a path from the source, the list of nodes for which *any path* from source to x must touch, i.e., the list of dominators of x. The DAG in question is attached as a postscript file, which is generated by `dot -Tps` using the output of the Graphviz module directly from the graph object. The nodes for which I'm computing dominators are labeled -2 and 2 (that is, conflNode = 2). The problem is that I think the answer is wrong. In particular I think the set of dominators for -2 is {20, -2}, and the set for 2 is {20, 2}. Their intersection is {20}, which is what I expect. But what I am getting is: --> uips = [-9,20] --> domConfl = [2,-9,20] --> domAssigned = [-2,-9,-12,20] --> lastd = 20 But -9 is not a dominator for 2, since 20,-7,8,6,2 is a path from 20 to 2 that does not touch 9. -9 is also not a dominator for -2, since 20,-7,8,6,-2 is a path from 20 to -2 not touching 9. Am I missing something? I've simplified the code above slightly from the original code in order to ignore some irrelevancies. The original code is for computing a learned clause in a SAT solver. The code in the state that will reproduce the error above is available via a git clone: git clone http://fid.stygian.net/dpllsat Build via cabal, using the --disable-optimization option to configure in order to enable assertions, then run: ./dist/build/dsat/dsat ./tests/problems/uf20/uf20-0226.cnf The graph should be saved in conflict.dot and with `dot -Tps -o conflict.ps conflict.dot` you should be able to turn it into the ps file attached. The problematic code referenced above starts on line 759. -- Denis

1 0

Unexpected lack of optimisation in -O0
by Neil Mitchell 10 Apr '08

10 Apr '08

Hi, I just tried compiling the following program: foo = (1 :: Int) == (2 :: Int) with ghc --ddump-simpl, and no optimisation flags, in GHC 6.6.1 The resultant code is: Test.foo = case GHC.Base.$f2 of tpl_X8 { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> tpl1_B2 (GHC.Base.I# 1) (GHC.Base.I# 2) } GHC has introduced dictionaries in this example. In comparison, Yhc and nhc wouldn't introduce dictionaries here, as the type class desugaring knows the type of the item is fixed, and makes a direct call to the appropriate function. If the desugaring was changed, it would make programs in GHCi run faster, would reduce the size of programs, and would speed up the optimiser, as it would have less to do. I am not sure how much additional work this would require in the simplifier, but if it was minimal, the gains would probably be worth it. I was just reading the Monad.Reader, where a Yhc based Haskell Interpreter states that comparisons against GHCi are "unfair", because Yhc gains too much benefit from this desguaring. Thanks Neil

2 1

RE: [GHC] #2153: GHCi does not have a :source command to load further .ghci files
by Simon Peyton-Jones 09 Apr '08

09 Apr '08

| Wow, that simple??? | | What needs to be done to get this in ":?" output? (It should be in the | manual, at least...) Indeed! But it's more application-note than user manual. Fortunately, we have a place for such material, namely GHC's "collaborative documentation" (a wiki) http://haskell.org/haskellwiki/GHC Would someone like to copy Claus's excellent message http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html to the Wiki documentation on GHCi, here: http://haskell.org/haskellwiki/GHC/GHCi (with his permission of course). That's the right place for it. Sam, you'd be an ideal person to do this, because you know what you wanted in the first place, so you could make sure the answer is easy to find. But anyone else would do fine! Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On | Behalf Of GHC | Sent: 07 April 2008 02:46 | Cc: glasgow-haskell-bugs(a)haskell.org | Subject: Re: [GHC] #2153: GHCi does not have a :source command to load further .ghci files | | #2153: GHCi does not have a :source command to load further .ghci files | ---------------------+------------------------------------------------------ | Reporter: SamB | Owner: | Type: bug | Status: closed | Priority: normal | Milestone: | Component: GHCi | Version: 6.8.2 | Severity: normal | Resolution: wontfix | Keywords: | Difficulty: Unknown | Testcase: | Architecture: Unknown | Os: Unknown | | ---------------------+------------------------------------------------------ | Comment (by SamB): | | Wow, that simple??? | | What needs to be done to get this in ":?" output? (It should be in the | manual, at least...) | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2153#comment:3> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler

3 2

Re: Wanted: migration guide from ghc-6.6 to ghc-6.8
by Johannes Waldmann 07 Apr '08

07 Apr '08

>> list of things to watch out for >> when converting Haskell sources written for ghc-6.6 >> for compilation with ghc-6.8. Thanks for the pointers. Luckily, only a few changes were needed, http://leiffrenzel.de/eclipse/wiki/doku.php?id=hare_with_gh-6.8 (sic). and most of them related to GHC API. I'm not completely sure whether it's semantically correct but at least it compiles. Best regards, J.W.

1 0

Wanted: migration guide from ghc-6.6 to ghc-6.8
by Johannes Waldmann 04 Apr '08

04 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I could use a list of things to watch out for when converting Haskell sources written for ghc-6.6 for compilation with ghc-6.8. Of course I'll try write down some items while I find them but I'd hope not to start at zero... Is there an easy way to get a "library API diff" (automatically, say, from full 6.6 and 6.8 installations)? Best regards, Johannes Waldmann. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9hn73ZnXZuOVyMIRAk1nAKDEteU/FHMHz4yDgL936r/rRfLy5gCfTTFz 0fv7U+nP4ELZ9xZT/qicODc= =B50t -----END PGP SIGNATURE-----

2 1