- Glasgow-haskell-users

moving from ghc-6.2 to 6.4
by Johannes Waldmann 29 Mar '05

29 Mar '05

I am trying to bring a larger heap of code (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder stories about faster compilation, faster execution, Data.Map, and so on ...) Here are a few observations and questions that may be useful to others as well. * what is the situation with ghc-6.4 for sparc/solaris? I don't see a binary package in the download area. I started to build from source - can this be successful? (The rest of this report refers to i386/linux) * Cabal is very nice! - The only thing that was confusing me is that I have to list all modules in the *.cabal file: if I don't, it still happily builds and installs the package but it cannot be used, giving linker errors. Couldn't this be checked earlier? Or better, couldn't it infer the needed hidden modules? Anyway I can generate the module list by a shell script but that does not feel right. - How do I build and install a profiling version of a package, how does Cabal support this? * (when building HSQL-1.4) CTime is no longer an instance of Integral, so I replaced fromIntegral by fromIntegral . fromEnum, is this OK? * the name of mkAppTy changed to mkTyConApp (I hope it's only the name that changed) * I don't see "dramatic" improvements in execution times - are there some magic ghc options I missed? I used -O -fvia-C. Still, executables are maybe 2 .. 5 % smaller and faster than they were with 6.2 - and compilation without -O is really fast. Best regards, and thanks to the GHC team. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

Kind of StableName
by Nicolas Oury 28 Mar '05

28 Mar '05

Hello, I try to use StableNames for hash consing on complex types - I have to mix in a same table StableNames of different types - and I wonder why StableName is of kind * -> * and not *. Best regards, Nicolas Oury

1 0

static linking with ghc
by Patrick Scheibe 27 Mar '05

27 Mar '05

Hi, I have a programm which is linked against some shared object libraries. Now I want to run my prog on a different machine (but same type, x86 linux). So I took the compiled prog and the needed .so files, put both in one directory and tried it on the other machine. That worked fine. Is it possible to tell ghc to take all stuff out of the .so libs and compile my source to a "all-including" executable? I know that ghc just calls the linker which is doing this part. The --static flag for the linker just says: "take the static library if possible for linking...". But I don't have a static version of these libs and I don't want to recompile all libraries. Am I totally wrong? Is this possible in general? Are there some good papers except of the "man ld"?? Cheers Patrick

2 1

Biographical Profiling
by Andreas Marth 25 Mar '05

25 Mar '05

Hallo! The ghc user guide says that there are 4 states a heap object may be in. Unfortunately in my program there are 5 states (inherent_use, use, drag, lag, void) with inherent_use being the biggest part (many MBs) and the one not mentioned in the users guide. My question is what does it mean? What can I do to get rid of it? Thanks, Andreas

1 0

Problem starting GHC 6.4 on windows 98
by J L Russell 25 Mar '05

25 Mar '05

When trying to run GHC 6.4 (from the installer) on Windows 98, I get the following error message: "The GHC.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA" >From what I've been able to determine, on Windows version prior to Windows 2000, this function was instead exported from shfolder.dll, which is retained in later versions of Windows for backward compatibility, and on newer version of Windows, simply calls the version in shell32.dll. So it looks to me like GHC 6.4 from the installer won't be able to run on Windows 98 unless the executable in the installer is updated to link this function from shfolder.dll instead. -James

3 2

Re: [Haskell] Haskell 6.4 perfomance
by Keean Schupke 25 Mar '05

25 Mar '05

Think this should really go to glasgow-haskell-users... If this is true - how do I get ghc to use C--, and is it really faster than using gcc as a backend with all the bells & whistles turned on (for a pentium-III) something like "-O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 -ffast-math -fsched-spec-load -fprefetch-loop-arrays -maccumulate-outgoing-args -fmove-all-movables -freduce-all-givs" Keean. Alexandre wrote: > As I heard, 6.4 version of the Haskell using C-- backend and make lots > of the resulting code perfomance (programs executed faster). > If so, does any test/comparison with other languages available? > > Thank you in advance, > Regards, > /Alexandre. >

2 1

RE: comments on the GHC API
by Simon Marlow 23 Mar '05

23 Mar '05

On 22 March 2005 17:49, Matthias Neubauer wrote: > ... we also need the state after renaming, but we then have to stop, I > suppose! Yes, the HaRE folks also want the renamed abstract syntax too. We haven't quite figured out how best to make it available: renaming is intertwined with typechecking a bit. > Because we want to do do our own typechecking, stopping after ghc's > typechecking would be to late: in case of a type error, ghc falls back > into the wrong context (at least that's what's happening right now > when doing a :load inside ghci ...). > >>> We, for our part, would need parts of the intermediate result >>> (that is, the type environment and class declarations) existing >>> either before parsing A, after parsing A, or, even better, after >>> renaming A. Other users may be interested in other intermediate >>> results. > > Is there a way to get access to all the identifiers that are > *imported* into the current module? Having that piece of information > at hand, we could then use *lookupThing* to cumulate the initial type > environment and the initial class environment for our analysis. > > Or do you see another/better way of doing that? The ModIface contains the usages, which includes everything that is *used* by the current module (not quite the same as everything that is imported, because this is a list of original names, not imported names). There is also the mi_globals list (in ModIface), which contains everything in scope at the top level of the module. From that I guess you could find everything that is imported by subtracting things that are defined in the local module. Cheers, Simon

1 0

RE: porting ghc-6.4 to x86_64
by Simon Marlow 23 Mar '05

23 Mar '05

On 23 March 2005 09:18, Andrei A. Voropaev wrote: > Sorry. Forgot to ask the next question on this process. Now that I > have unregistered compiler, how do I build the registered one? > > I've tried to start with new tree and then run > > ./configure --with-ghc=T/ghc/compiler/ghc-inplace > make Yes, that should do it. Except that x86_64 doesn't have support for object splitting yet, so you need to add a file mk/build.mk with the line: SplitObjs=NO to turn off splitting. For some reason that I don't quite understand, it seems from the error message that you posted the compiler is attempting to generate code for -split-objs, which is causing the assembler to fall over. Turning off splitting should fix that anyway. Cheers, Simon

2 1

RE: porting ghc-6.4 to x86_64
by Simon Marlow 23 Mar '05

23 Mar '05

On 22 March 2005 10:10, Andrei A. Voropaev wrote: > Well, looking at the makefile it becomes clear, that it must do so. > ------------------------------------- > # Make DerivedConstants.h for the compiler > > all :: DerivedConstants.h > > mkDerivedConstants.c : $(H_CONFIG) > > mkDerivedConstantsHdr : mkDerivedConstants.o > $(CC) -o $@ $(CC_OPTS) $(LD_OPTS) mkDerivedConstants.o > > DerivedConstants.h : mkDerivedConstantsHdr > ./mkDerivedConstantsHdr >$@ > > CLEAN_FILES += mkDerivedConstantsHdr$(exeext) DerivedConstants.h > ------------------------------------ > > Since ghcautoconf.h is new this triggers update for > mkDerivedConstants.c which in turn updates mkDerivedConstantsHdr > which in turn updates DerivedConstants.h. I guess I should also touch > the mkDerivedConstants.c to avoid the updates. Am I correct? Duh, sorry about that. The full list of things you need to touch are: $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o I must have avoided making in ghc/includes when I did the bootstrap myself. Thanks for highlighting the problem. Cheers, Simon

2 2

RE: comments on the GHC API
by Simon Marlow 22 Mar '05

22 Mar '05

Hi Matthias, I think most of what you're asking for is planned... On 17 March 2005 16:59, Matthias Neubauer wrote: > I just had a first look at the sketch for the planned GHC API > (ghc/compiler/main/GHC.hs), since we are very keen on using it ... > > Our group would mostly like to make use of a compilation > manager/module system implementation for Haskell---so these are the > parts I concentrated on for now. More specifically, the scenario how > we would like to use a GHC library is the following: > > So far, we've implemented a static analysis for (single) Haskell > modules. To make our tool ready for a wider use, we would like extend > it to full Haskell 98 (plus extensions). What we therefore would like > to ask a GHC library is, given a specific module A, to compile all the > other modules that A is dependent on, load them into a context for A, > and start processing A up to the point where the actual type-checking > of A would commence. After that, we would like to query the library > about the initial (type) environment of A (that is, get out a complete > summary of all the imported bindings, classes, methods, etc) to then > proceed with our own analysis instead of using GHC's type inferencer. > > I see two basic ways how a GHC library could help us to achieve this: > > - The library both offers a separate module dependency analysis and > also lets us use the compiler in one-shot mode. We then could first > calculate the dependencies of A, compile them separately, and > calculate the initial environment of A manually by combining the > interfaces of the imported modules. Of course, we would also need > the possibility to access the imports of A (including renamings and > such) without the need to compile A as a whole. > > - Loading a set of targets (using *load*) can be controlled in a more > fine-grained way. Instead of just offering the possibility to > compile a set of targets either completely or not at all, there is > an option to compile targets only up to a certain compilation phase > (or alternatively, to optionally keep intermediate results occurring > between the phases to be able to retrieve them afterwards.) The 'load' function lets you load only up to a certain module, and the JustTypecheck mode stops before code generation and lets you inspect the typechecked code. Using this, you can compile one module at a time and get the typechecked code out - does that sound ok? There are some areas to do with getting access to the typechecked class declarations and some other parts of the module that we have still to sort out. The refactoring folks also want access to the renamed code (before typechecking), which includes more of the original declarations. > We, for our part, would need parts of the intermediate result (that > is, the type environment and class declarations) existing either > before parsing A, after parsing A, or, even better, after renaming > A. Other users may be interested in other intermediate results. > > What do others think? > > Some more, rather random, remarks: > > - I guess v_CmdLineMode and friends are iorefs that are supposed to > live globally in GHC.hs. Couldn't you also pack them into a separate > data type created by *init* and later share them between several > sessions. The CmdLineMode will be private to the front end only, but there's a related GhcMode that now lives in the DynFlags. Take a look at the HEAD as it is now (I just commmitted some big changes in this area in preparation for the GHC API). > Maybe we could even introduce a Session monad? Looking at all the > functions again, they all seem to have Session arguments ... > > - I guess the exported name *GhcSession* should read *Session* (or > better the other way around) > > - Same for *GhcMode* vs. *GhciMode* > > - What's the purpose of having a mode argument for "newSession"? As I > read the rest of the API, *load* is the only way to trigger the > compilation of targets. And *load* seems to be intended to work > similar to the interactive mode only. load might compile and link object code in --make mode, or compile and dynamically-link bytecode in --interactive mode. > - What are Module, ModSummary, ModIface, HsTypecheckedGroup, HsGroup, > TyThing, and Type standing for (I know of course ...)? How > complicated would it be to return already existing (TH) data types > instead of exposing/specifying more of GHC's internals? The TH types aren't really rich enough for all the purposes we expect this interface to be used for. In particular, the data type needs to include the full GHC language, it needs to include full source location information (the refactoring folks need this, and so does Visual Studio), and it needs to include type information for identifiers. Only HsSyn includes all this. Cheers, Simon

2 1