- Glasgow-haskell-users

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 18 July 2005 15:54, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> You might be picking up the wrong version of ghc here. My guess is >> that the -ignore-package option is being interpreted as a -i flag by >> an older version of GHC. > > Hm...I have 6.2.2 installed, which may qualify for being an "older > version," but how is it being the "wrong" one? Or are those options > intended specifically for the ghc currently being built? For that > matter, does, by chance, the current snapshot require 6.4 to build? You tried to compile a library file using the installed compiler, by cut-and-pasting the command line issued by the build system that was designed for the 6.4 compiler being built. There's nothing particularly strange here - the libraries are always built by the compiler in the tree, so the build system can assume that it only has to create command lines for that particular version of GHC. Cheers, Simon

1 0

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 16 July 2005 08:42, Dinko Tenev wrote: > BTW, I tried to compile the file with the installed ghc, and I am kind > of puzzled by the error message I get: > > > ghc -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports > -ignore-package haskell-src -package base -fgenerics -hisuf p_hi > -hcsuf p_hc -osuf p_o -prof -c Language/Haskell/Syntax.hs -o > Language/Haskell/Syntax.p_o -ohi Language/Haskell/Syntax.p_hi > ghc-6.2.2: -ohi can only be used when compiling a single source file > Usage: For basic information, try the `--help' option. > > > How am I trying to compile anything other than a single source file > here??? You might be picking up the wrong version of ghc here. My guess is that the -ignore-package option is being interpreted as a -i flag by an older version of GHC. Cheers, Simon

2 1

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 18 Jul '05

18 Jul '05

On 04 July 2005 12:44, Peter A Jonsson wrote: > dons(a)cse.unsw.edu.au (Donald Bruce Stewart) writes: >> pj: >>> I would like to use nativeCodeGen outside of GHC to generate code >>> from an IR. The IR would be produced by a third party program, not >>> the GHC frontend. >>> >>> Looking at CVS HEAD I can see that GHC.hs exports plenty of things >>> (for the GHC API I presume), but I can't find anything that lets me >>> input some sort of IR and have ASM in return. Am I missing it >>> somewhere or is there no way to input IR and get ASM in return? If >>> there isn't, is such a feature planned/wanted? >>> >>> If such a feature isn't planned, I would appreciate any ideas on how >>> to to accomplish the same thing. I have no problems with having a >>> build tree of GHC laying around if that makes things easier. It >>> would be a nice bonus if it made my maintenance burden low. >> >> You could use External Core with GHC, couldn't you? > > Thanks for the quick answer! > > Maybe it's my lack of understanding of the inner workings of GHC but > reading "An External Representation for the GHC Core Language" I get > the impression that the dumping of Core Language is basically targeted > at researchers writing their own optimization passes or backends for > Haskell/GHC so they can use the existing infrastructure of GHC. My > request is the other way around - I want to throw out the frontend but > use* ("low-level") parts of the backend of GHC. > > The Core Language seems to be translated into STG-machine code, which > according to my understanding is an abstract machine desinged to > support non-strict higher-order functional languages. I was hoping > that the laziness was in the STG-syntax, not in Cmm. Looking at output > of -ddump-cmm it resembles C-- quite closely (also implied by comments > in PprCmm.hs), which makes me believe that is the "correct" level of > abstraction for me. > > *) The reasons are two-fold, one is that it is written in Haskell, the > other is that it generates code for more than one architecture > today. If the language you want to generate code for is at the level of C--, then you could indeed use GHC's native code generator. There isn't an interface to it exposed by the GHC API, but you can use the interfaces directly: the AsmCodeGen module is the top-level of the native code generator, and basically takes Cmm (defined in module Cmm) and produces assembly code. However, if you want to do this, I wonder whether you would be better off just using the real C-- compiler. Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 16 July 2005 11:50, Dinko Tenev wrote: > I did a "devel" build this time, which produced some verbose output > for the last line. > > One thing that troubles me is that gcc still manages to kick-in - what > exactly is going on??? > > > ------------------------------------------------------------------------ > ==fptools== make all -wr; > in /home/shinobi/build/fptools/libraries/haskell-src > ------------------------------------------------------------------------ > ../../ghc/compiler/ghc-inplace -H32m -O0 -fasm -W > -fno-warn-unused-matches -fwarn-unused-imports -ignore-package > haskell-src -O -dcore-lint -W -fno-warn-unused-matches > -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c > Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.o -ohi > Language/Haskell/Syntax.hi Two reasons: one, -O implies -fvia-C and two, -keep-hc-files also implies -fvia-C (because otherwise you don't get any .hc files). You'll need to modify the definition of GhcLibHcOpts in build.mk to put -fasm after -O, and also to remove -keep-hc-files. Cheers, Simon

1 0

RE: Unicode in GHC 6.2.2 and 6.4.x (was: Re: [Haskell-cafe] Unicode.hs)
by Simon Marlow 18 Jul '05

18 Jul '05

On 17 July 2005 04:42, Dimitry Golubovsky wrote: > Dear List Subscribers, > > Simon Marlow wrote: >> On 30 June 2005 14:36, Dimitry Golubovsky wrote: >> >> >>> It is in CVS now, and I believe will be in 6.4.1 >> >> >> Not planned for 6.4.1, but definitely in 6.6. >> > > I have put those files that work for me in GHC 6.2.2 (Unicode support) > for download. Please read the Wiki page: > > http://haskell.org/hawiki/GhcUnicode > > for instructions. > > Any feedback will be appreciated. I believe, the code will work with > GHC > 6.4.x as well. Please let me know if there are any problems. I should mention that 6.4.1 will contain Dimitry's updated Unicode character-class support, albeit without the changes to library APIs that went along with it. The upshot is that all platforms should have consistent behaviour for the isXXX functions from Data.Char in 6.4.1. Cheers, Simon

1 0

Unicode in GHC 6.2.2 and 6.4.x (was: Re: [Haskell-cafe] Unicode.hs)
by Dimitry Golubovsky 17 Jul '05

17 Jul '05

Dear List Subscribers, Simon Marlow wrote: > On 30 June 2005 14:36, Dimitry Golubovsky wrote: > > >>It is in CVS now, and I believe will be in 6.4.1 > > > Not planned for 6.4.1, but definitely in 6.6. > I have put those files that work for me in GHC 6.2.2 (Unicode support) for download. Please read the Wiki page: http://haskell.org/hawiki/GhcUnicode for instructions. Any feedback will be appreciated. I believe, the code will work with GHC 6.4.x as well. Please let me know if there are any problems. Dimitry Golubovsky Middletown, CT

1 0

[ ghc-Feature Requests-1239439 ] O'Haskell
by SourceForge.net 16 Jul '05

16 Jul '05

Feature Requests item #1239439, was opened at 2005-07-16 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1239439&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Monique Louise de Barros Montei (mlbm) Assigned to: Nobody/Anonymous (nobody) Summary: O'Haskell Initial Comment: Is there any project for extending GHC with support to O'Haskell or any other object-oriented Haskell extesion? That could be very useful for improving Haskell interoperability with OO languages. Thanks in advance, Monique Monteiro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1239439&group_…

1 0

RE: Problem building GHC
by Simon Marlow 16 Jul '05

16 Jul '05

On 14 July 2005 22:02, Dinko Tenev wrote: > It turns out, ar couldn't quite handle building the symbol table for > the archive. I tried ar qS, then ranlib the archive, but ranlib turns > out to be exactly the same kind of brittle crap... > > I am currently looking for more robust binutils - I'll appreciate any > siggestions. I tried this experiment too, with the same results. As a workaround you can disable object splitting. Add the line "SplitObjs=NO" to mk/build.mk before building. Cheers, Simon

3 4

Documentation for GHC primops
by Simon Peyton-Jones 16 Jul '05

16 Jul '05

Dear GHC users This message is a request for help with a well-contained task that will improve GHC's Haddock documentation. GHC provides lots of primitive operations. They are described in a single ASCII files primpos.txt.pp; the description in that file gives types and English-language descriptions, as well as some other GHC-ish information. This description file is chomped up by a pre-processor (genprimopcode), which produces either (a) Haskell source code for data types describing the primops [these modules become part of GHC itself), or (b) Latex stuff which can be part of a document. You can see the output in Section 4.4 of the External Core document (http://www.haskell.org/ghc/docs/papers/core.ps.gz) However, there's no Haddock document describing all these primops!! Although they are all available through the module GHC.Exts, the Haddock documentation for GHC.Exts says nothing at all about them. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.Exts.html Reason: there is no Haskell source code for GHC.Prim, the pseudo-module that exports all the primops. What we want is to generate GHC.Prim.hs from primops.txt.pp. This .hs file would not be fed to GHC; rather it'd just be there so that Haddock could see it. For example: module GHC.Prim( ...list all primops... ) where (+#) :: Int# -> Int# -> Int# --| Adds two unboxed Ints ...etc... you get the idea. No Haskell code, only type signatures. Would someone cares to write this new backend to "genprimopcode". The latter is a Haskell program that can parse primops.txt.pp, and already has two back ends (a) and (b) above. What we want is to add (c) generate Haskell that Haddock can understand. Note that the documentation itself is already written -- it's in primpos.txt.pp. That's what's so tantalising. All that we need is to mangle it into Haddock. Any volunteers? It doesn't involve touching GHC itself. "gemprimopcode" is a completely standalone Haskell program, currently some 730 lines long. Simon

4 3

RE: C->Haskell 0.14.1 "Travelling Lightly"
by Simon Marlow 15 Jul '05

15 Jul '05

On 15 July 2005 14:32, Manuel M T Chakravarty wrote: > PS to GHC HQ: Can we please have the latest Cabal in GHC 6.4.1? Sorry, that would violate the "no API changes in patchelevels" invariant. But it'll be easy to upgrade Cabal separately. Cheers, Simon

1 0