July 2003 - Glasgow-haskell-users

ANNOUNCE: GHC version 6.0.1
by Simon Marlow 04 Aug '03

04 Aug '03

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 ============================================================= We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.0.1. This is a bug-fix release relative to 6.0. The most important bugfixes are: * Fixes to make GHC work with GCC 3.3 * Fix for the "GHC deletes source files" bug * :cd now unloads any loaded modules in GHCi. * -mk-dll should work better on Windows. in addition to various other bugfixes. The release notes lists the changes in the 6.0 line relative to 5.04: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998, and revised in December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (Mac OS X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

6 6

RE: Strange Building problem...
by Simon Marlow 31 Jul '03

31 Jul '03

> On Wed, 30 Jul 2003 18:01:22 +0100, you wrote: > > >GHCziBase_True_closure is a symbol that should be coming > from the base > >package, the GHC.Base module in particular. You could check that > >libraries/base/libHSbase.a looks reasonable: it should be on > the order > >of 17Mb. Try 'nm' on it, look for some of the missing symbols. > > Hi, > > Thanks very much for your reply. > > I looked and the libraries/base/libHSbase.a file is there, is the > correct size, and does contain the missing references. The only > problem is that the compiler doesn't seem to be seeing it. > > I tried looking in the makefile to see if I could insert a path > directive somewhere, but I'm not very experienced with UNIX makefiles > so I couldn't find where I ought to put such a thing. > > What is odd is that ghc-inplace is invoked by the make process several > times before this big one (which appears to be the start of stage 2?) > and works fine... Do the errors really refer to "GHCziBase_True_Closure", or is it "GHCziBase_True_closure"? (with lower-case 'c')? Cheers, Simon

2 1

ghc-6.0.1 --make -O (linking errors)
by Jan Scheffczyk 31 Jul '03

31 Jul '03

Hi all, I recently switched to ghc 6.0.1 running on a debian linux box. When compiling a program using ghc --make -O or ghc --make -O2 I get lots of errors while linking. The linker concerns about undefined references to Data.FiniteMap, which I frequently use. For example, the linker says: ../Options.o(.text+0xc0d): In function `s4m5T_ret': : undefined reference to `DataziFiniteMap_lvl4_closure' Without optimizing my code, doing a plain ghc --make everything goes fine. Similarly, compiling the same program with the older ghc 6.0 I do not get any linking errors, whether I optimize or not. Any ideas, how I can get rid of the linking errors, except for switching back to ghc 6.0? Best Regards, Jan

2 2

RE: Strange Building problem...
by Simon Marlow 31 Jul '03

31 Jul '03

> I am presently trying to build GHC on an i386 Linux box running > debian/sid. (Yea, I know there's a .deb - in fact, I have it > installed - but I need to be able to compile my own.) > > I've run configure and make, and stage 1 went quite well although > there were a few syntax problems (usually due to #ifdef's in the > source .hs files apparantly overrunning or underrunning; easily fixed > by just deleting the problematic #ifdef chunks for other > architectures). > > Stage 2, however, seems to have a problem: make runs "make -C > ghc/compiler stage=2", which then runs > "../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.0 -H16m -O > -i<lots of stage2/ paths> -DGHCI -package haskell-src -package unix > -package readline -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen > -IativeGen -Iparser -recomp -Rghc-timingn -H16m `#include > "hschooks.h"` -no-link-chk <lots of .o files>" > > This then produces: > stage2/utils/Util.o(.text+0xb8): In funtion "r4c8_entry": undefined > reference to "GHCziBase_True_Closure" > > ... and roughly 40,000 errors of the same form. "Something has gone wrong" :-) GHCziBase_True_closure is a symbol that should be coming from the base package, the GHC.Base module in particular. You could check that libraries/base/libHSbase.a looks reasonable: it should be on the order of 17Mb. Try 'nm' on it, look for some of the missing symbols. Cheers, Simon

3 2

RE: Lost output in multithreaded program
by Simon Marlow 31 Jul '03

31 Jul '03

I haven't investigated in detail, but I believe your problem might be caused by a known bug in the implementation of forkProcess, namely that when forking from a child thread it doesn't kill the main thread. The workaround is to fork (in your case call popen) from the main thread, not a child thread. Cheers, Simon > I am puzzled by the behaviour of this (stripped-down, > uglified) program. > It is supposed to run a bunch of shell commands simultaneously, > collate their standard output and error, and print their output as > though they had run sequentially. > > module Main where > > import Control.Concurrent > import Data.Maybe > import GHC.Handle > import GHC.IO > import Posix (popen) > > main = do > cmds <- getContents >>= return.lines > outCh <- newChan > mainThr <- myThreadId > forkIO $ do > mapM_ (startCommand outCh) cmds > writeChan outCh $ killThread mainThr > getChanContents outCh >>= sequence_ > > startCommand :: Chan (IO ()) -> String -> IO () > startCommand ch cmd = do > -- Prevent lazy reads after forking > length cmd `seq` return () > (out,err,pid) <- popen "/bin/sh" ["-c",cmd] Nothing > -- Prevent deadlock (waiting to read stdout > -- while the child waits to write stderr). > forkIO $ length err `seq` return () -- culprit line? > writeChan ch $ hPutStr stdout out > writeChan ch $ hFlush stdout > writeChan ch $ hPutStr stderr err > writeChan ch $ hFlush stderr > > Most of the time it works but every so often a chunk of child output > gets lost. (I'm sure I've seen it duplicating chunks of > output too, but > I haven't been able to isolate a test case.) Corruption of > stderr seems > more common than corruption of stdout. The corruption > doesn't get more > predictable if I generate a list of commands with fixed > 'random' sleeps > and use that (so I don't think it's a gross timing issue). The lost > data is not necessarily a prefix of the output string, nor a suffix. > The lost data does not reappear later in the program's > output. The lost > data *does* appear to correspond to byte sequences that are > written in a > single write() by the child process. > > Example: > > $ cat test.sh > #!/bin/sh > echo -n "std" ; sleep 1 > echo -n "STD" >&2 ; sleep 1 > echo "out" ; sleep 1 > echo "ERR" >&2 ; sleep 1 > $ for i in `seq 100`; do echo "sleep $((RANDOM % 10)); > ./test.sh"; > done | ./a.out > <snip> > stdout > STDERR > stdout > ERR > stdout > STDERR > <snip> > stdout > STDERR > stdout > STDstdout > STDERR > stdout > STDERR > <snip> > > If I comment the 'culprit line' above then the program runs without > error. This confounds me: I believe that that line should have no > effect except to suck the child's stderr into the program as soon as > possible. (Am I wrong? And is there a better way of doing this?) > > Platform: ghc-6.0-7 / RedHat 8.0 / x86. > Compilation: ghc -package posix test.hs > > Where did my output go? Have I run into some gotcha like the 'lazy > reads after forking' thing? Can someone tell me what I'm doing wrong? > > Hopeful thanks, > // David > -- > David Hughes > UNIX sysadmin, Serco SA -+- Tel.: +41 22 767 8997 > Computing Centre, CERN -+- David.W.Hughes(a)cern.ch > > This message expresses my own opinions and should not be construed > as the opinions of Serco (who employ me) or of CERN (where I work). > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

1 0

RE: ghc-6.0.1 --make -O (linking errors)
by Simon Marlow 31 Jul '03

31 Jul '03

> I recently switched to ghc 6.0.1 running on a debian linux box. > > When compiling a program using > ghc --make -O > or > ghc --make -O2 > I get lots of errors while linking. > The linker concerns about undefined references to > Data.FiniteMap, which I > frequently use. > For example, the linker says: > > ../Options.o(.text+0xc0d): In function `s4m5T_ret': > : undefined reference to `DataziFiniteMap_lvl4_closure' > > Without optimizing my code, doing a plain > ghc --make > everything goes fine. > Similarly, compiling the same program with the older ghc 6.0 > I do not get any > linking errors, whether I optimize or not. > > Any ideas, how I can get rid of the linking errors, except > for switching back to ghc 6.0? It could be a problem with your build of ghc-6.0.1. Where did it come from? Cheers, Simon

1 0

NICE TO MEET YOU.
by TAFIQ MOHAMMED. 30 Jul '03

30 Jul '03

FROM: TAFIQ MOHAMMED. AMMAN JORDAN DEAR:Sir, My Name is TAFIQ MOHAMMED, an Iraqis National from the Kurds an Accountant in Oil refinery in Durra. I am presently in Amman, Jordan Capital since U.S.strike Iraqi, few days to the expiration of the 48 hours Ultimatum before the strike. I moved $45.5M dollars call-deposit to Security Company in Iran for safe-keeping.In my capacity as the accountant to the oil refinery in durra, I was the only person aware of this financial transaction call-deposit with the security company in Iran to be released to whom I will introduce to the security company as the beneficiary of the call- deposit of $45.5M, whom the oil installation company is been owed since I can not be able to go to Iran because of the war. Now that the situation is not condusive for me to go to Iran, I am appealing to you if i can present you as the beneficiary of the call- deposit to the security company for the release of the deposit to your Account or any of your destination as part of the money being owed to you by Durra oil Refinery Company Iraq. As soon as this deposit is released to your Account by the security company in Iran or any of your destination,I will come over to meet you for disbursement 30%-70%. On your acceptance on this transaction I will send to you the deposit slip Certificate for the call deposit to you as the beneficiary to be release to you as part of the refunds owed to you by Durra Oil Refinery company Iraq.Or contact me through my alternative E-mailaddress:mohatafiq@o2.pl Awaiting your quick response, Best Regards, TAFIQ MOHAMMED,

1 0

Strange Building problem...
by Mark Green 30 Jul '03

30 Jul '03

Hi folks, I am presently trying to build GHC on an i386 Linux box running debian/sid. (Yea, I know there's a .deb - in fact, I have it installed - but I need to be able to compile my own.) I've run configure and make, and stage 1 went quite well although there were a few syntax problems (usually due to #ifdef's in the source .hs files apparantly overrunning or underrunning; easily fixed by just deleting the problematic #ifdef chunks for other architectures). Stage 2, however, seems to have a problem: make runs "make -C ghc/compiler stage=2", which then runs "../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.0 -H16m -O -i<lots of stage2/ paths> -DGHCI -package haskell-src -package unix -package readline -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -IativeGen -Iparser -recomp -Rghc-timingn -H16m `#include "hschooks.h"` -no-link-chk <lots of .o files>" This then produces: stage2/utils/Util.o(.text+0xb8): In funtion "r4c8_entry": undefined reference to "GHCziBase_True_Closure" ... and roughly 40,000 errors of the same form. Can anyone let me know what I'm doing wrong here? Any help greatly appreciated. Mark

1 0

RE: GHC and Mingw32 (cont.)
by Simon Marlow 30 Jul '03

30 Jul '03

> Ok, I got GHC compiled but running it is a tricky. It > has trouble finding package.conf. It looks like you've done 'make install'. On Windows, we don't support doing that, because it conflicts with the way we layout binary distributions. If you build GHC from source, just run it from the source tree, as ghc/compiler/stage2/ghc-inplace. Cheers, Simon

1 0

Lost output in multithreaded program
by David Hughes 29 Jul '03

29 Jul '03

Dear list, I am puzzled by the behaviour of this (stripped-down, uglified) program. It is supposed to run a bunch of shell commands simultaneously, collate their standard output and error, and print their output as though they had run sequentially. module Main where import Control.Concurrent import Data.Maybe import GHC.Handle import GHC.IO import Posix (popen) main = do cmds <- getContents >>= return.lines outCh <- newChan mainThr <- myThreadId forkIO $ do mapM_ (startCommand outCh) cmds writeChan outCh $ killThread mainThr getChanContents outCh >>= sequence_ startCommand :: Chan (IO ()) -> String -> IO () startCommand ch cmd = do -- Prevent lazy reads after forking length cmd `seq` return () (out,err,pid) <- popen "/bin/sh" ["-c",cmd] Nothing -- Prevent deadlock (waiting to read stdout -- while the child waits to write stderr). forkIO $ length err `seq` return () -- culprit line? writeChan ch $ hPutStr stdout out writeChan ch $ hFlush stdout writeChan ch $ hPutStr stderr err writeChan ch $ hFlush stderr Most of the time it works but every so often a chunk of child output gets lost. (I'm sure I've seen it duplicating chunks of output too, but I haven't been able to isolate a test case.) Corruption of stderr seems more common than corruption of stdout. The corruption doesn't get more predictable if I generate a list of commands with fixed 'random' sleeps and use that (so I don't think it's a gross timing issue). The lost data is not necessarily a prefix of the output string, nor a suffix. The lost data does not reappear later in the program's output. The lost data *does* appear to correspond to byte sequences that are written in a single write() by the child process. Example: $ cat test.sh #!/bin/sh echo -n "std" ; sleep 1 echo -n "STD" >&2 ; sleep 1 echo "out" ; sleep 1 echo "ERR" >&2 ; sleep 1 $ for i in `seq 100`; do echo "sleep $((RANDOM % 10)); ./test.sh"; done | ./a.out <snip> stdout STDERR stdout ERR stdout STDERR <snip> stdout STDERR stdout STDstdout STDERR stdout STDERR <snip> If I comment the 'culprit line' above then the program runs without error. This confounds me: I believe that that line should have no effect except to suck the child's stderr into the program as soon as possible. (Am I wrong? And is there a better way of doing this?) Platform: ghc-6.0-7 / RedHat 8.0 / x86. Compilation: ghc -package posix test.hs Where did my output go? Have I run into some gotcha like the 'lazy reads after forking' thing? Can someone tell me what I'm doing wrong? Hopeful thanks, // David -- David Hughes UNIX sysadmin, Serco SA -+- Tel.: +41 22 767 8997 Computing Centre, CERN -+- David.W.Hughes(a)cern.ch This message expresses my own opinions and should not be construed as the opinions of Serco (who employ me) or of CERN (where I work).

1 0