September 2005 - Glasgow-haskell-users

RE: progress on Freebsd-amd64 (Was: .hc files for buildingghc-6.4.1 onamd64 ?)
by Simon Marlow 22 Sep '05

22 Sep '05

On 22 September 2005 09:49, Simon Marlow wrote: > On 21 September 2005 21:14, Wilhelm B. Kloke wrote: > >> Simon Marlow <simonmar(a)microsoft.com> schrieb: >>> >>> Int64# primitive type (it's the same as Int#). You might want to >>> make sure that ghc/includes/ghcautoconf.h on the host machine is the >>> right one - it should have been copied from the target machine. >>> >> Yes. ghcautoconf.h had been rebuilt accidentally. >> >> Now I have an unregisterised ghc-inplace. What is the fastest way to >> test its usability? > > congratulations! > > You should be able to build a simple Haskell program and run it, like > so: > > $ cat >hello.hs > main = putStrLn "hello world!" > ^D > $ $target/ghc/compiler/ghc-inplace hello.hs > $ ./a.out > hello world! oops, I lied. You need to build the libraries before you can use this GHC to build a program. Cheers, Simon

1 0

RE: .hc files for building ghc-6.4.1 on amd64 ?
by Simon Marlow 22 Sep '05

22 Sep '05

On 20 September 2005 12:24, Wilhelm B. Kloke wrote: > Deletion of Linker.c and manual build of some AutoApply files make > the crossbuild work on i386 side. I have a copy of the > resulting hc-bundle ready. If anybody wants them, send me a mail. > They don't work on the amd64 side, though. Here is the error message: > > gcc -x c GHC/Int.hc -o GHC/Int.o -c -O -DNO_REGS > -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=604 -O > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/inclu de > -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` GHC/Int.hc: In > function `s83O_ret': > GHC/Int.hc:2522: error: `int64ToIntegerzh_fast' undeclared (first use > in this function) > GHC/Int.hc:2522: error: (Each undeclared identifier is reported only > once > GHC/Int.hc:2522: error: for each function it appears in.) > GHC/Int.hc: In function `s83J_ret': > GHC/Int.hc:2583: error: `int64ToIntegerzh_fast' undeclared (first use > in this function) > gmake[1]: *** [GHC/Int.o] Fehler 1 > gmake: *** [all] Fehler 1 > gmake: Leaving directory > `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries' I think this means that something has gone wrong during the generation of the .hc files on the host machine. GHC/Int.hc is not supposed to refer to int64ToIntegerzh_fast, because on a 64-bit machine there is no Int64# primitive type (it's the same as Int#). You might want to make sure that ghc/includes/ghcautoconf.h on the host machine is the right one - it should have been copied from the target machine. > I notices that the evil mangler was replaced after my build. I don't > have > an idea whether this would make it work. > > BTW. FreeBSD-amd64 does not seem to support "small memory model". Is > this essential? If that's true, it means the port is going to require more work. But I'd be surprised, because FreeBSD is using the same compiler toolchain as everyone else. Cheers, Simon

3 2

RE: progress on Freebsd-amd64 (Was: .hc files for building ghc-6.4.1 onamd64 ?)
by Simon Marlow 22 Sep '05

22 Sep '05

On 21 September 2005 21:14, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> Int64# primitive type (it's the same as Int#). You might want to >> make sure that ghc/includes/ghcautoconf.h on the host machine is the >> right one - it should have been copied from the target machine. >> > Yes. ghcautoconf.h had been rebuilt accidentally. > > Now I have an unregisterised ghc-inplace. What is the fastest way to > test its usability? congratulations! You should be able to build a simple Haskell program and run it, like so: $ cat >hello.hs main = putStrLn "hello world!" ^D $ $target/ghc/compiler/ghc-inplace hello.hs $ ./a.out hello world! > The next failure is at Control/Arrow.hc after reconfiguration in > hc-build: > > ==fptools== gmake all -wr; > in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base > ------------------------------------------------------------------------ > gcc -x c Control/Arrow.hc -o Control/Arrow.raw_s -S -O > -D__GLASGOW_HASKELL__=604 -O > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include > -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/inclu de > -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` Control/Arrow.hc: In > function `s39r_entry': > Control/Arrow.hc:25: error: `stg_ap_p_ret' undeclared (first use in > this function) > Control/Arrow.hc:25: error: (Each undeclared identifier is reported > only once > Control/Arrow.hc:25: error: for each function it appears in.) > Control/Arrow.hc: In function `s39v_entry': > Control/Arrow.hc:46: error: `stg_ap_p_ret' undeclared (first use in > this function) ... Just to confirm - this is at the stage after "*** Building libraries..." in hc-build? I don't think the reconfigure step has worked properly. It still seems to be attempting to compile the .hc file, when in fact it should be using ghc-inplace to compile the .hs file. Check that mk/config.mk has BootingFromUnregisterisedHc=NO and BootingFromHc=NO. Cheers, Simon

1 0

RE: `make' for profiling
by Simon Marlow 21 Sep '05

21 Sep '05

On 21 September 2005 11:12, Serge D. Mechveliani wrote: > On Wed, Sep 21, 2005 at 10:11:46AM +0100, Simon Marlow wrote: >> On 20 September 2005 12:03, Serge D. Mechveliani wrote: >> >>> Dear GHC developers, >>> >>> I have a user's wish for the versions > 6.4.1: >>> >>> the possibility to `make' a project with profiling, >>> without user play with the Cabal version substitution. >> >> It's possible, but unlikely that we'll do it. It requires porting >> the required changes from the new Cabal version to the old version >> witout changing any library APIs. Of course, if someone were to >> send us a patch... > > > Does this mean that ghc-6.4.1, and further versions too, > will be without profiling? Of course not! Profiling works in 6.4.1 just like it has in previous versions. What is missing is profiling support in Cabal as shipped with 6.4.1, which is what I thought you were asking for. Newer versions of Cabal support profiling, and all you have to do is upgrade Cabal. Cheers, Simon

3 2

RE: `make' for profiling
by Simon Marlow 21 Sep '05

21 Sep '05

On 20 September 2005 12:03, Serge D. Mechveliani wrote: > Dear GHC developers, > > I have a user's wish for the versions > 6.4.1: > > the possibility to `make' a project with profiling, > without user play with the Cabal version substitution. It's possible, but unlikely that we'll do it. It requires porting the required changes from the new Cabal version to the old version witout changing any library APIs. Of course, if someone were to send us a patch... Cheers, Simon

2 1

Garbage collecting CAFs
by John Meacham 20 Sep '05

20 Sep '05

I have seen numerous references to CAFs not used to being garbage collected in ghc leading to various contortions of the optimizer to keep from generating them and possible space leaks... then "something" was done and they are now collected.. I am curious what paper (or list message?) describes what that "something" is and what it entails in terms of tradeoffs. thanks. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

ghc 6.4.1 for OS X from darwinports
by Gregory Wright 20 Sep '05

20 Sep '05

Hi, GHC 6.4.1 is now available for OS X via the darwinports system. The compiler is built from source, using a binary bootstrap compilier. Both 10.3 (Panther) and 10.4 (TIger) are supported. For more information on darwinports, see: http://darwinports.opendarwin.org Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

2 3

RE: .hc files for building ghc-6.4.1 on amd64 ?
by Simon Marlow 20 Sep '05

20 Sep '05

On 17 September 2005 22:05, Wilhelm B. Kloke wrote: > I tried it again today. One of my problems was related to gmake > version. > The configure script should warn, if gmake is older than 3.80 (I had > 3.78). I'm using 3.79.1. I do vaguely remember a problem with older versions of gmake - what goes wrong for you? > The building of the .hc bundle fails wirth the following messages: > > ... > tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat > hc-files-to-go` > tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs: > Cannot stat: No such file or directory gmake: *** [hc-file-bundle] > Fehler 1 Yes, you do actually need to generate these .hc files on the host system. What happened to the build in ghc/rts - could you post the error message? Possibly a 'make -k' in ghc/rts will be enough to get these files. > I tried to go back to ghc/rts to build more files following the > ipattern of the last steps before, but this destroys genapply. Don't quite understand this - could you elaborate? > Further, there are some hsc.c files of length 0 like: > ~/Haskell/fptools-i386amd64/ghc-6.4.1 0$ ls -l > libraries/base/System/*hsc.c > -rw-r--r-- 1 wb ifado 0 17 Sep 21:31 > libraries/base/System/CPUTime_hsc.c > -rw-r--r-- 1 wb ifado 0 17 Sep 21:31 > libraries/base/System/Time_hsc.c This is correct (the C compiler should generate an empty object file when compiling them). It was easier to avoid the special case in the build system when the _hsc.c file is empty. > The building process on the target system fails with messages that > there is no rule to build those files. Also, I needed to have happy > and alex > on the target system, because make boot fails without them (catch 22). When things are working properly, you don't need Happy or Alex on the target system. I suspect things have gone wrong earlier. > A final glitch is that (at least, my) FreeBSD-amd64-6.0 gcc does not > include -I/usr/local/include and -L/usr/local/lib in the search path. > So libgmp is not found. Ok. You can use the libgmp in the tree (this should happen automatically), or you can add the -I/-L flags to the relevant places. This is something we don't handle very well right now, though. Cheers, Simon

2 2

`make' for profiling
by Serge D. Mechveliani 20 Sep '05

20 Sep '05

Dear GHC developers, I have a user's wish for the versions > 6.4.1: the possibility to `make' a project with profiling, without user play with the Cabal version substitution. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

C/Haskell speed comparisons
by Ian Lynagh 19 Sep '05

19 Sep '05

Hi all, Quite often in darcs we want to do a simple loop over a chunk of memory, looking for the first whitespace character or somesuch. Historically this has been done by writing a small snippet of C, but this has a number of downsides (less type safety in the C code, Int/int/HsInt/CInt mismatches, code artificially separated, complicates the Makefiles, have to write C code), so I'd like to replace them with little bits of Haskell. However, it would be easier to convince people that this is the right thing to do if there was no slow-down involved, so I've put some benchmarks together. Hopefully this will help find some cases where ghc is generating poor code, and perhaps help to spot regressions (although it's hard to spot that automatically currently). Essentially each test has n modules, each of which (are supposed to) do the same thing, and it compares certain pairs and it works out how much slower one is than the other on various test sizes. I arbitrarily declared x1.1 to be too slow. The code is at http://urchin.earth.li/~ian/bench/ and the results I get for ghc 6.4.1 are at http://urchin.earth.li/~ian/bench/all.html (interestingly some of the slowdowns I was trying to measure turned out to be speed/ups/). Thanks Ian

1 0