- Glasgow-haskell-users

Haggis
by Tom Bevan 05 Jan '02

05 Jan '02

Has anyone had any success compiling Haggis for linux. I've tried but get the response, Configuring for a i386-debian-linux host. checking how to run the C preprocessor... gcc -E checking for flex... flex checking for -lfl... yes checking whether ln -s works... yes checking whether make sets ${MAKE}... yes ./configure: .: filename argument required .: usage: . filename Any ideas what this might mean? Tom

2 1

weird compiler bug/failed to load interface
by Hal Daume III 04 Jan '02

04 Jan '02

There's one module I wrote that I use in a lot of my programs and for some reason, whenever I compile a program using this module with -O or -O2, make changes to the Main, and then recompile, I get the following error from ghc: Skipping Pattern ( Pattern.hs, Pattern.o ) failed to load interface for `Pattern': Could not find interface file for `Pattern' Failed to find interface decl for `Pattern.a' from module `Pattern' if I "ls Pattern.*" I get Pattern.hi, Pattern.hs and Pattern.o. In order to get it to compile correctly, I have to rm Pattern.o and then rerun ghc on the Main module. I've attached the Pattern.hs fyi. If anyone has any suggestions, please let me know. (btw, I'm using --make) Thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: Setting up ghc for GPH and GranSim
by Simon Peyton-Jones 04 Jan '02

04 Jan '02

You can't use any old GHC for GpH, I'm afraid. (GpH modifies GHC internally.) Best thing to do is to go to the GpH website and get your GHC from there. http://www.cee.hw.ac.uk/~dsg/gph/ There's a GpH mailing list, which I'm ccing. Perhaps they are planning a new release? Simon | -----Original Message----- | From: matthew_bentham(a)yahoo.com [mailto:matthew_bentham@yahoo.com] | Sent: 21 December 2001 17:52 | To: glasgow-haskell-users(a)haskell.org | Subject: Setting up ghc for GPH and GranSim | | | Hi all, | | I'm new to both this list and Haskell, so apologies if these | questions have been answered before or seem obvious. I've | trawled the website and my suspicion is that I'm using a 'too | new' version of the compiler that doesn't support GranSim. Anyway: | | I'm trying to set up a ghc. I want to compile GPH programs | and run them on GranSim. | | With my current setup (details at the bottom of the mail) I | get the following error when I try to compile a GPH program: | [mjb67@mjb67 mjb67]$ ghc -gransim -fvia-c -fglasgow-exts | --make parfib.hs | ghc-5.02.1: can't find module `Prelude' | | Does anyone have any idea what I might be doing wrong? The | error is reported even when the program is normal Haskell, | whenever I use the -gransim or -parallel options to the | compiler. I presume this is some sort of library issue? | | My compiler was set up in the following way: | | I installed the binary RPMs: | http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.i386. rpm http://www.haskell.org/happy/dist/1.11/happy-1.11-1.i386.rpm I downloaded the source RPM from: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.src.rpm I unpacked the source. I then typed (in the source root directory) ./configure --enable-gransim make make install Thanks in advance, Matthew _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Socket library ghc 5.02.1
by Sven Eric Panitz 30 Dec '01

30 Dec '01

It seems that the Socket library does still not work with ghc 5.02.1. I tried the simple test: > main = > do > d <- connectTo "localhost" (PortNumber 80) > hPutStr d "GET / HTTP/1.0\n\n" > hFlush d > c <- hGetContents d > putStr c On Windows2000 I get the known error: *** Exception: does not exist Action: getProtocolByName Reason: no such protocol entry whereas on Linux I get the following error: *** Exception: failed Action: connect Reason: Unknown error 142731264 The error number changes for every invocation and every 20th time or so it works on the linux machine. Can anyone recommend me, how to get a working Socket library with ghc 5.02. (I really need it now...) Sven Eric

6 6

Next ghc
by senganb＠ia.nsc.com 27 Dec '01

27 Dec '01

Will the next version of ghc use libgmp 4.0? I would like to use its new gmp_sscanf. Thanks, Sengan

1 0

simple program crash (GHC 5.02, Hugs)
by Oleg Galbert 22 Dec '01

22 Dec '01

I'm a newbie in Haskell. I tryed to compare performance of GHC compiled code and Ocaml compiled code on a small example: test n cosx | n==0 = cosx | otherwise = test (n-1) (cosx+cos(cosx)) main = print ( test 10000000 0.0 ) I compiled it on Win NT : ghc -o test_haskell.exe test_haskell.hs When I run the program I got the following message: Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. Hugs 98 (December 2001) version just fails with "Application Error" message. Does a stack usage depends on number of recursive calls? Is there a tail recursion optimization? In Ocaml version of this program everything goes well. The program produced the result without any complains. Oleg Galbert

3 2

Re: simple program crash (GHC 5.02, Hugs)
by matthew_bentham＠yahoo.com 21 Dec '01

21 Dec '01

Oleg Galbert wrote: > I'm a newbie in Haskell. > I tryed to compare performance of GHC compiled code and Ocaml compiled > code > on a small example: > > test n cosx > | n==0 = cosx > | otherwise = test (n-1) (cosx+cos(cosx)) > > main = print ( test 10000000 0.0 ) > > I compiled it on Win NT : > > ghc -o test_haskell.exe test_haskell.hs > <snip> > Does a stack usage depends on number of recursive calls? Is there a tail > recursion optimization? <snip> Yes and yes. To turn on the optimiser, add -O or -O2 to the compiler command line: [mjb67@mjb67 mjb67]$ ghc -o test_haskell test_haskell.hs [mjb67@mjb67 mjb67]$ ./test_haskell Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. [mjb67@mjb67 mjb67]$ ghc -O2 -o test_haskell test_haskell.hs [mjb67@mjb67 mjb67]$ ./test_haskell 1.5707963267948966 [mjb67@mjb67 mjb67]$ Hope this helps, Matthew (fellow Haskell newbie :-) )

1 0

Re: ghc image size
by Mike Gunter 21 Dec '01

21 Dec '01

You may not like this argument but its kind are essential to the strategic part of engineering. Since you bring it up, let's consider whether it's worthwhile to optimize code for time. I'm less familiar with the costs of labour but around here (Silicon Valley) labor costs are well in excess of a cent per second. When last I checked, good generalist engineering consultants were charging more than $150/hour (specialists cost more.) (And remember that, like for disk space, their costs are higher than their price.) The rates may have come down somewhat lately but I'm quite sure costs are still well in excess of one cent per second. Moreover, lots of programs take many, many seconds to run and get run many times. So, optimization for time can save you a lot of expensive people time over the long haul. It's worth putting some effort there. One can make a case for reducing executable size in certain contexts. For instance, it's not unreasonable to work to make code loaded by web browsers smaller -- those executables have to be repeatedly moved over slow links while people are waiting. In my environment, though, I don't see much benefit in smaller GHC executables. Are there contexts where it matters more? GHC's resources (the implementation team, the constructive criticism of users, etc.) are limited. I'd hate to see them spent on unimportant things. mike > Mike Gunter <m(a)ryangunter.com> writes: > > > Why is executable size a barrier? 1.64 megabytes (that's the size of > > the executable I built with GHC most recently) of disk space costs less > > than half a cent. > > I don't like this argument. Can I go to a computer store, pay a cent, > and get a hard disk with space 1.64 megabytes or more? Until then, I > can't believe that 1.64 megabytes of disk space costs less than half a > cent. > > When a compiler does not perform as good as other compilers (e.g., in > terms of generated code size), it is important to ask: Why does it > happen? Is there anything we can do to improve it? Being critical is > the first step towards progress. (Of course these questions should be > asked in a constructive rather than whining way.) Why would anyone > optimize code for time --- a second of electricity and labour cost > less than a cent... > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Setting up ghc for GPH and GranSim
by matthew_bentham＠yahoo.com 21 Dec '01

21 Dec '01

Hi all, I'm new to both this list and Haskell, so apologies if these questions have been answered before or seem obvious. I've trawled the website and my suspicion is that I'm using a 'too new' version of the compiler that doesn't support GranSim. Anyway: I'm trying to set up a ghc. I want to compile GPH programs and run them on GranSim. With my current setup (details at the bottom of the mail) I get the following error when I try to compile a GPH program: [mjb67@mjb67 mjb67]$ ghc -gransim -fvia-c -fglasgow-exts --make parfib.hs ghc-5.02.1: can't find module `Prelude' Does anyone have any idea what I might be doing wrong? The error is reported even when the program is normal Haskell, whenever I use the -gransim or -parallel options to the compiler. I presume this is some sort of library issue? My compiler was set up in the following way: I installed the binary RPMs: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.i386.rpm http://www.haskell.org/happy/dist/1.11/happy-1.11-1.i386.rpm I downloaded the source RPM from: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-rh71-1.src.rpm I unpacked the source. I then typed (in the source root directory) ./configure --enable-gransim make make install Thanks in advance, Matthew

1 0

RE: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
by Simon Marlow 21 Dec '01

21 Dec '01

> This example raises a general problem (which, as it turns > out, is relevant > to my current work). How can one mix multithreading with > multiprocessing? In particular, how can a threaded process > safely create > another process to run a program? Put another way, how can the > combination of `forkProcess` and `executeFile` be done > "atomically enough" > so that existing threads in the forking process don't "get in > the way". > > I read something on this topic (involving some sort of > pervasive locking > strategy) recently, but can't recall where. Anybody remember? I can't think of a good way to do this at the Haskell level, because you'd need to halt all the running threads except for the one doing the fork. But one hack which will work is to call out to a C function which does the fork/exec, since foreign calls will be atomic from the point of view of the Haskell RTS. However, one caveat which might be relevant in the future is that if the Haskell program is running in a multi-threaded environment (i.e. OS threads, not Haskell threads), then the C function must be marked 'unsafe' for it to be treated as atomic by the Haskell RTS. The OS thread support in the RTS isn't fully implemented yet, though. Cheers, Simon

1 0