- Glasgow-haskell-users

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. 31 Jul '03

31 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

RE: case-identity
by Simon Peyton-Jones 29 Jul '03

29 Jul '03

Ahem. What I should have said is that the list of alternatives always covers all cases that can occur. For example in data Foo = Red | Green | Blue ...case x of Red -> True other -> ...(case x of Green -> ... Blue -> ... ) ... The inner case is considered exhaustive because Red can't occur. Any Red alternative in the inner case will be considered dead, and removed. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of David Sabel | Sent: 28 July 2003 21:43 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: case-identity | | > In Core, the list of alternatives is always exhaustive. | | Ok, thanks. | So I assume the "dead alternative elimination" is no longer done in | the simplifier? | | ( | The dead alternative elimination is defined as: | | case x of ===> case x of | P1 -> E1 P1 -> E1 | ... ... | ci a1 ... an -> Ei Pn -> En | ... [without ci a1 ... an -> Ei] | Pn -> En | | if x is not of constructor c_i | ) | | David | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0