June 2007 - Glasgow-haskell-users

Build Systems (was: Re: 64-bit windows version?)
by Peter Tanski 25 Jun '07

25 Jun '07

Gour wrote: > Have you seen Aap (http://www.a-a-p.org/) ? I have A-A-P (or Aap) but I only did the basic hello-world build and read the manual. It has in fact been updated as late as Febuary 2007. The Make-like syntax is elegant. Maybe someone else could look at this and see if they want to do something big in it? One thing that would have to be done for Haskell is write special Aap modules. The builtin ability to grab sources from CVS and publish things to the web might be extended to darcs and Trac. My one gripe is that it requires both Python and Perl. Cheers, Pete

1 0

need help with 6.4.2 boot build for hpux 11.0
by Joe Buehler 25 Jun '07

25 Jun '07

I am attempting to get 6.4.2 booted under hpux 11.0 following the instructions for building from hc files generated on another machine. The target compiler builds but will not build a trivial test program. The error message indicates that it cannot import the Prelude module. Looking at the system calls that the compiler is making I am guessing that package.conf.inplace is not correct. The one produced by the target build is basically empty, as compared to the one on the host machine. Can this file just be copied from the host build machine to the target? Another question I have is this, is there a better version of GHC to try this with? The instructions don't match the 6.6 source tree layout so I went back to 6.4.x. I have had to install some patches though so am wondering if I would have an easier time of this with something even earlier? -- Joe Buehler

1 0

64-bit windows version?
by Bulat Ziganshin 24 Jun '07

24 Jun '07

Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

11 27

ghc6.6 on ps3 - compile error in StgCRun
by Tristan Allwood 24 Jun '07

24 Jun '07

Hi, I'm trying to build ghc-6.6 on a sony ps3, but have hit a problem: ------------------------------------------------------------------------ == make all -r; in /home/tora/ghc/ghc-6.6/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-fno-strict-aliasing -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o /tmp/ghc12557_0/ghc12557_0.s: Assembler messages: /tmp/ghc12557_0/ghc12557_0.s:12:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc12557_0/ghc12557_0.s:16:0: Error: junk at end of line, first unrecognized character is `@' make[1]: *** [StgCRun.o] Error 1 make: *** [stage1] Error 1 The ps3 is running YDL, and to bootstrap the ghc build I managed to install a powerpc ghc6.6 on the system (downloaded a deb from http://packages.debian.org/cgi-bin/download.pl?arch=powerpc&file=pool%2Fmai… then alien'ed it to get an rpm which seems to work - though ghci is non-functioning) The sources I'm trying to build are the standard ghc http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2 (and extralibs) >uname -a Linux ebony 2.6.16-20061110.ydl.2ps3 #1 SMP Tue Dec 5 12:35:42 EST 2006 ppc64 ppc64 ppc64 GNU/Linux Any tips / pointers / advice greatfully recieved; TIA, Tristan Allwood

3 5

ghc configure
by C.M.Brown 23 Jun '07

23 Jun '07

Hi, I've noticed that when you run ./configure on a ghc build lot's of repetition occurs. A lot of the time the same checks are being performed for each configure file in the ghc hierarchy. Could it be possible if some of these checks could be done once at a high level and then subsequent configures could refer to these checks to speed up configuration time? It's just configuring ghc on a mac G4 is a very time consuming process in it's own right! Thanks, Kind regards, Chris.

4 5

Re: 64-bit windows version? (Haskell is a scripting language too!)
by Peter Tanski 22 Jun '07

22 Jun '07

Brian Hulley wrote: > To port GHC to a completely new platform, you'd of course need a > Haskell > compiler or interpreter already. However to bootstrap the process > only a > slow interpreter would be needed so as long as a portable pre-built > bytecode version was available for download the only thing left to > port > would be a byte code interpreter which could just be a single file > of c > code. This was one void Yhc was designed to fill, especially by compiling to java bytecode. At the rate I work--if I'm the only one deconstructing the current build system--by the time I'm done the Yhc team will have everything running. Greg Fitzgerald wrote: > I was trying to build something like this recently but hit a > roadblock. > ... > Unfortunately, the imported module needs to have the line "module > X.Y.Zwhere", which means the file needs to be aware of its parent > directories. I > think that's too harsh a constraint, and makes it a pain to move > things > around (true in everyday Haskell projects with local modules too!). Have you looked at Neptune? It is a scriptable build system based on Jaskell, which allows dynamic imports. An example from the page at http://jaskell.codehaus.org/Jaskell+for +Neptune#JaskellforNeptune-90: //in script1.jsl 1+x where x = import {file="script2.jsl"}; end You may imagine that the string for "script2.jsl" may be computed. Of course this sort of thing breaks the type system in Haskell and the result is more Make-like, but that is the tradeoff. Now why did I not try a build system using Neptune? Probably because I had already spent the last three weeks learning CMake, the pecularities of SCons, WAF (weird bugs!), m4 (I never had to write tests in Autoconf before or debug my own configure files), and higher level Make (so it would do what I can do in Jam)--I guess it got lost by the wayside... I was looking at things most people would either already know or would want to learn and that should already be available on new platforms. skaller wrote: > The second is simply that dynamic typing is generally > better for build systems, because it allows code to > 'self-adapt'. There is a somewhat slow-going scheme-based-build-system project called Conjure, at http://home.gna.org/conjure/ but it only supports Linux and OS X. > An alternative is to implement the build system in, say, > Scheme, and then write a Scheme interpreter in Haskell. > Scheme can self-adapt internally because its compiler > is built-in. That is why I was looking into using SISC--it is self-contained and may even be distributed along with the source code (SISC itself is GPLv2 but that doesn't matter for _using_ it)--by default it looks in the current directory. The downside is the lack of a library with directed graphs. Cheers, Pete

1 0

Template Haskell [d| .. trouble
by Marc Weber 21 Jun '07

21 Jun '07

Hi. I've started using template haskell (replacing some preprocessor stuff) However I had real trouble when trying to convert instance (Show d) => Show (C d) where show _ = "C " ++ (show (undefined :: d)) into th. Why? It didn't compile (http://hpaste.org/289) Heffalump on #haskell suggested that the d is already in scope so I don't need the first list item of ForallT .. And that does work fine. So is this a bug in the [d| .. parser / to abstract syntax tree transformer ? Session showing this behviour: marc@localhost ~ $ cat ABC.hs {-# OPTIONS_GHC -fglasgow-exts #-} module ABC where data C d marc@localhost ~ $ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :l ABC [1 of 1] Compiling ABC ( ABC.hs, interpreted ) Ok, modules loaded: ABC. *ABC> :m +Language.Haskell.TH *ABC Language.Haskell.TH> runQ [d| instance (Show d) => Show (C d) where show _ = "C " ++ (show (undefined :: d)) |] >>= print Loading package template-haskell ... linking ... done. [InstanceD [AppT (ConT GHC.Show.Show) (VarT d_0)] (AppT (ConT GHC.Show.Show) (AppT (ConT ABC.C) (VarT d_0))) [FunD show [Clause [WildP] (NormalB (InfixE (Just (LitE (StringL "C "))) (VarE GHC.Base.++) (Just (AppE (VarE show) (SigE (VarE GHC.Err.undefined) (ForallT [d_1] [] (VarT d_1))))))) []]]] *ABC Language.Haskell.TH> Now (ForallT [d_1] [] (VarT d_1) should be (ForallT [] [] (VarT d_1) shouldn't it? Marc Weber

2 1

Re: 64-bit windows version?
by Peter Tanski 20 Jun '07

20 Jun '07

Simon Marlow wrote: > GHC *developers* wouldn't be any better off either. You'd still > need either > Cygwin or MSYS for the build environment. There's no way I'm using > MS build > tools, ugh. The way I have it set up (so far) is as simple as running configure and make--all from the command line, under DOS or Mingw, although someone with VS tools may open up the VSproject in the IDE. Would that be o.k.? I am not particularly enamored with VS, myself but that may be a consequence of having a small monitor for my Windows machine and constantly comparing it to the Xcode/Emacs combination I normally use. The VS debugger *is* very good and helped me pick out some bugs in Yasm quickly--when I only really know how to use gdb. Cheers, Pete

1 0

How to use qualified name ModuleName.(.!.) ?
by Marc Weber 20 Jun '07

20 Jun '07

Example: marc@localhost /tmp/qual $ ls; cat M.hs main.hs; ghc --make main.hs M.hi M.hs M.o main.hs -- module M ------------------ module M where import Data.List infixr 9 .!. f = "dummyf" (.!.) = (!!) -- module Main ------------------ module Main where import qualified M as M main = do print $ M.f -- (1) print $ M.(.!.) [1,2] 1 -- (2) -- ------------------------------- [2 of 2] Compiling Main ( main.hs, main.o ) main.hs:7:10: Not in scope: data constructor `M' (3) main.hs:7:12: Not in scope: `.!.' (4) Calling M.f (1) works fine whereas calling M.(.!.) results in the error messages. Is possible somehow? Can I find more information in the ghc docs? Marc Weber

2 1

Re: Locating shared libraries
by Peter Tanski 19 Jun '07

19 Jun '07

skaller wrote: > On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote: >> On Sat, 16 Jun 2007 08:21:50 +1000 >> skaller <skaller(a)users.sourceforge.net> wrote: >> >>> One way to measure this is: if you removed GHC and applications, >>> and there are (necessarily) no users of the remaining library >>> package .. the library package shouldn't be in the global public >>> place (/usr/lib+include etc). >>> >> >> As I understand it, the entire point of this effort (shared libraries >> in GHC) is to allow dynamically linked Haskell executables. In this >> case, applications outside the GHC toolchain will in fact depend on >> these shared objects. As a concrete case, a binary darcs package >> could >> be a user of libghc66-base.so and libghc66-mtl.so -- with no >> dependencies on the GHC compiler package itself. >> >> Does this pass your litmus test? >> > > Yes, it passes the separability test. My darcs wouldn't run otherwise! > And versioning the library filename as above is a good idea too. > > Felix adds _dynamic for shared libs and _static for static link > archives to ensure the Linux linker doesn't get confused. > > However, the libs still aren't fully public if the interfaces > are only private details of the GHC tool chain. Hmmm. Under the current system, darcs is linked statically so it is a self- contained executable. Under the proposed shared-library system versioning the shared libraries may pose a very big problem and I don't think it would pass your litmus test. As I mentioned previously, GHC is a fast-moving target and there are quite a few GHC- Haskell-based applications available that rely on different versions of the compiler. Here is an example: There are any number of GHC-Haskell-based programs, all built with different versions of GHC; GHC itself relies on some of these to build, such as Happy and Alex. (There are .rpm packages for Alex.) You already talked about the situation from there: several different programs relying on different versions of the shared libraries, located in /usr/local/lib--and they don't rely on just one library. As is, the GHC runtime system has more than a few base libraries, the minimum set of which is: HSrts HSbase HSbase_cbits With dynamically linked libraries on OS X, the convention was to have add the suffix _dyn, so we had: HSrts_dyn, HSbase_dyn and HSbase_cbits_dyn Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. Cheers, Pete

3 4