June 2005 - Glasgow-haskell-users

References to the Rts in unregisterised first build of ghc 6.4
by Michiel Buddingh' 26 Jun '05

26 Jun '05

Hello, I wanted to run ghc on netbsd-alpha, so I thought I'd build an unregisterised ghc following the instructions in chapter 10 of the build manual. I was able to generate a set of .hc files on a linux-i386 host, but (as was expected) the rtc failed to build. However, attempting to compile these .hc files on alpha yields lots of unresolvable references to stg_ap_0_ret (and other similarly named functions), which, a quick search revealed, are exported by the rtc. Is this a configuration error on my Alpha (say, I don't need files like libraries/base/Control/Arrow.hc for a first unregistered build) or rather an error on the Linux host that generated the .hc files? I've noticed that mk/config.mk seems to contain several variables that seem to relate to unregisterised builds (such as BootingFromUnregisteredHc) that are neither specified in the hc-build script or the manual. Tuning these on the target machine has no effect. I'd be grateful for any helpful hints. -- -- Michiel

1 0

Parse error on '#'
by Remko Troncon 25 Jun '05

25 Jun '05

Hi, I'm trying to get GHC working on Mac OS X 10.2. I downloaded and installed the binary distribution of GHC 6.0.1, and it seems to compile the 'hello world' application. However, when i try to compile another program (e.g. GHC 6.0.1 itself), it seems that GHC doesn't recognize '#ifdef' statements in code, and reports back with the error: Package.hs:1: parse error on input `#' Can anyone tell what's going on here ? thanks, Remko

2 2

Faster IO
by Jim Apple 24 Jun '05

24 Jun '05

I'm having an IO speed problem. I need to input a long string of known length and process it with a foldl. getLine and foldl take way too long; is there a known faster way? Jim

4 3

GHC 6.2.2 Compile problem on Mac OS X 10.4
by Remko Troncon 23 Jun '05

23 Jun '05

Hi, I am trying to make an unregisterised build. As my host machine, i use a Mac running Mac OS X 10.4. When building ghc 6.2.2 on the host machine (also running GHC 6.2.2), i get the error attached below when doing 'make all' in ghc/. Does anyone have an idea how to solve this ? thanks, Remko ** /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/absCSyn -istage1/main - istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ compMan -istage1/ndpFlatten -istage1/cbits -DOMIT_NATIVE_CODEGEN - cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser - recomp -Rghc-timing -O -H32m -fasm -H16M '-#include "hschooks.h"' - no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o - ohi stage1/prelude/PrimOp.hi primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... /tmp/ghc6793.s:83646:Fixup of 78156 too large for field width of 16 bits /tmp/ghc6793.s:83644:Fixup of 78164 too large for field width of 16 bits <<ghc: 1305569372 bytes, 47 GCs, 14631871/36633452 avg/max bytes residency (6 samples), 86M in use, 0.00 INIT (0.00 elapsed), 13.81 MUT (17.74 elapsed), 4.61 GC (5.65 elapsed) :ghc>> make: *** [stage1/prelude/PrimOp.o] Error 1

2 1

unofficial pre-6.4.1 snapshot build for x86-64 linux
by Jens Petersen 23 Jun '05

23 Jun '05

I build a recent 6.4 stable branch snapshot on Linux/x86-64 (ie amd64) today. Since several people expressed interest in it I just uploaded it as binary dist tarball to: http://haskell.org/~petersen/ghc-6.4.1.20050620-x86_64-unknown-linux.tar.gz I'm happy to say with this gtk2hs now works well on x86-64. :-) Rpms of it and gtk2hs are also available on request. Cheers, Jens

1 0

hierarchical module names
by Serge D. Mechveliani 23 Jun '05

23 Jun '05

Who knows, please, where there are explained hierarchical module names? Is this a matter of Haskell-98 or of GHC ? I looked into both of them (and also a bit into libraries(a)haskell.org) but could not find a basic explanation of the point, somehow missed. Suppose that my user package called dumatel exports a module of kind --------------------------- module List (union) where import Data.List import qualified List union xs ys = f (Data.List.union xs (List.union ys ys)) f = ... --------------------------- First, the module name List conflicts with such of the base package of GHC. So, I change this to --------------------------- module Dumatel.List (union) where where import Data.List import qualified List union xs ys = f (Data.List.union xs (List.union ys ys)) f = ... --------------------------- Second, -v key in ghc --make shows that GHC decides to search for the module Dumatel.List only in the files ./Dumatel/*.hs and ./Dumatel/*.lhs So, I create a directory and put the above module to the file ./Dumatel/List.hs Does this all mean "to use hierarchical module names"? Does the module name "Dumatel.List" agree with Haskell-98 ? What is the currently most convenient way to resolve module name clashes between the packages? Is this the above arrangement with subdirectories and module names with dots (and with "qualified-as" import) ? Thank you in advance for explanation. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: Bignums in Haskell
by Simon Peyton-Jones 22 Jun '05

22 Jun '05

| >> Do any of you have insight into why GHC uses GMP as opposed to | >> another library for arbitrary precision numbers? | > ... | | Right - that's three reasons to use it. Some reasons *not* to use it | are: it has an awkward license, it's big, it needs updating, and we run | into problems when the Haskell program wants to use GMP itself via the | FFI (it's possible by essentially renaming everything in our local copy | of GMP so it doesn't conflict, but we haven't done that). In fact, we have long wanted to replace GMP with another library for exactly these reasons. It's a nice, well-specified, self-contained project, which is just waiting for someone to step up and do it. Of course, we'd only want to replace GMP if the alternative was also fast and reliable. If anyone is interested in tackling this, let us know! Simon

4 5

bignum libraries
by Serge D. Mechveliani 22 Jun '05

22 Jun '05

People, When intending to write a library for large numbers, it worths to keep in mind the following. 1. Efficient multiplication, division and gcd methods may occur rather involved mathematically. 2. It is natural for `arithmetics' to include factorization. Suppose, GHC would like to include such ... 3. It is natural to extend further the library to algebraic numbers. (2) and (3) are definitely very involved mathematically. (2) and (3) are supported by existing libraries (by Lenstra or other experts), -- as I recall, written in C, -- with various wise methods for (1),(2),(3), so that efficient arithmetics for integers is extended to algebraic numbers. (I never looked into all this, only have seen the announcements). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

comparing 5.02.3 and 6-4-branch
by Serge D. Mechveliani 22 Jun '05

22 Jun '05

I have installed ghc-5.02.3 and ghc-cvs-6-4-branch-June-15 on the same Linux machine, ported DoCon to 6-4-branch, and compared DoCon-2.06 - ghc-5.02.3 to DoCon-2.09 - ghc-cvs-6-4-branch-June-15 on computer algebra (the CA algorithms are the same). 1. They work correct. 2. The performance and memory eagerness difference is within about 5 %. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Bignums in Haskell
by Simon Marlow 22 Jun '05

22 Jun '05

On 21 June 2005 22:52, John Meacham wrote: > On Tue, Jun 21, 2005 at 03:48:44PM +0100, Simon Peyton-Jones wrote: >> >>>>> Do any of you have insight into why GHC uses GMP as opposed to >>>>> another library for arbitrary precision numbers? >>>> >> ... >>> >>> Right - that's three reasons to use it. Some reasons *not* to use >>> it are: it has an awkward license, it's big, it needs updating, and >>> we run into problems when the Haskell program wants to use GMP >>> itself via the FFI (it's possible by essentially renaming >>> everything in our local copy of GMP so it doesn't conflict, but we >>> haven't done that). >> >> In fact, we have long wanted to replace GMP with another library for >> exactly these reasons. It's a nice, well-specified, self-contained >> project, which is just waiting for someone to step up and do it. Of >> course, we'd only want to replace GMP if the alternative was also >> fast and reliable. >> >> If anyone is interested in tackling this, let us know! > > I wonder if it would be feasable to implement arbitrary precision > integers in pure haskell. unboxed values would probably want to be > used in some places for speed and it would be very motivating to > improve ghc's optimizer. There should be no reason manually unboxed > haskell code should compile slower than C. GHC currently lacks some of the primitives that you'd need to build an efficient bignum library (eg. add with carry), but you could add these. Also, the fact that GMP contains hand-tuned assembly versions of several operations makes me skeptical that you could get the same performance from GHC-compiled Haskell. However, getting close might be good enough. Cheers, Simon

1 0