February 2005 - Glasgow-haskell-users

RE: runInteractiveProcess is broken
by Simon Marlow 18 May '05

18 May '05

I can't repeat this, it works here: *Main> test1 ExitSuccess *Main> test2 Just ExitSuccess (after changing /usr/bin/sleep to /bin/sleep). The only thing I can think of is that you somehow have a SIGCHLD handler that calls wait(), but I don't see where that can be happening. GHC doesn't have any other mechanism for calling wait(), so I don't understand how the zombies are disappearing before waitForProcess is called. Maybe run it through strace and send us the output? Cheers, Simon On 26 October 2004 19:00, Peter Simons wrote: > Neither of these functions returns the return code of the > external process as promised: > > import System.IO hiding ( catch, try ) > import System.Process > import Control.Concurrent > > sleep :: Int -> IO () > sleep n = threadDelay (abs(n) * 1000000) > > test1 :: IO () > test1 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- waitForProcess pid > print rc > > -- *Main> test1 > -- *** Exception: waitForProcess: does not exist (No child > processes) > > test2 :: IO () > test2 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- getProcessExitCode pid > print rc > > -- *Main> test2 > -- Nothing > > I'm using the ghc from CVS-HEAD on Linux/x86. > > Peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

x86_64 port
by Kip Macy 02 Mar '05

02 Mar '05

Sorry if this is a RTFM type question - but what is the status of the x86_64 port?

3 5

GHC 6.4 release candidates available
by Simon Marlow 02 Mar '05

02 Mar '05

We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons & the GHC team

17 31

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
by Simon Marlow 02 Mar '05

02 Mar '05

On 23 February 2005 11:01, Brian Strand wrote: > Thanks a lot! For anyone who runs into the same problem, here is > what I did: > > 1. Converted to an rpm via "alien -r ghc6_6.2.2-3_amd64.deb" > 2. Installed the resulting rpm. > 3. When I tried to run ghc6, I got > > /usr/lib/ghc-6.2.2 # /usr/bin/ghc6 > ghc-6.2.2: Can't find package.conf as > /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace > > Other similar errors cropped up while trying to bootstrap. So, some > crude symlink hackery: > > cd /usr/lib/ghc-6.2.2 > ln -s . ghc > ln -s . driver > ln -s package.conf.shipped package.conf.inplace > # now we have a /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace > > mkdir utils > ln -s .. utils/unlit > # now we have a /usr/lib/ghc-6.2.2/utils/unlit/unlit > > ln -s ghc6 /usr/bin/ghc > # so ./configure finds ghc > > This has gotten me quite a ways into the 6.2.2 compile; I'm still > waiting to see if it completes successfully. Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Cheers, Simon

4 6

RE: readline fun
by Simon Marlow 01 Mar '05

01 Mar '05

On 02 February 2005 15:51, Ian Lynagh wrote: > The Debian ghc6 package curently has both a build-dependency and a > normal dependency on libreadline4-dev. The former is so the readline > library (and ghci) can be built, and the latter so compiling programs > with the readline package behaves correctly. > > Now I want to move over to libreadline5-dev instead. Clearly, to build > the new ghc6, I need the old ghc6 installed, and thus need > libreadline4-dev installed (as it's a dependency). However, > libreadline4-dev and libreadline5-dev can't be installed > simultaneously. > > I believe this isn't a /real/ problem because the readline package of > the old GHC isn't actually needed to compile a new GHC, so > libreadline4-dev isn't actually needed. Thus I can solve this problem > by doing a build by hand on each arch. However, it would make my life > a lot easier if things weren't so entangled in the first place. I bet the old GHC will work fine with the new readline. Can't you solve it that way? (apologies if I'm just being naïve... I've never used a Debian system). > While I could just split the readline package off into a separate > ghc6-readline package for Debian, I fear this may cause confusion for > users, and it would mean satisfying cabal package deps was not > necessarily sufficient for Debian systems. So what would be really > useful for me is if the split were done by ghc itself, in much the > same way as how the opengl libraries can be split off. Then, in > particular, cabal packages using readline would have to explicit > state it rather than assuming it'll be there by default. Not sure what you're asking for here. The OpenGL libraries can't easily be split off. You want us to ship the readline package separately, say as a Cabal package? That's a possibility, but we like to keep the GHC sources as self-contained as possible, and adding another dependency just makes it harder to build GHC. Sure, readline would be optional, but mostly you want it ("why doesn't up-arrow work in the GHCi I just built?"). Ideally, we would have a home-grown readline replacement (System.Console.SimpleLineEditor doesn't count: it depends on your terminal using ANSI escape sequences). Cheers, Simon

2 1

RE: new ghc under solaris
by Simon Marlow 01 Mar '05

01 Mar '05

On 24 February 2005 11:35, Christian Maeder wrote: > I've made progress with ghc HEAD under solaris 8. In fact I could > successfully install a ghc-6.5 compiler that was able to compile a > couple of files (including "Hello World") > > But on one file (by chance HughesPJ.hs with an unqualified module > name) > I got a "Bus Error" (see below) I'll try now if "gmake bootstrap3" > fails, too. > > During "gmake" also the _FILE_OFFSET_BITS warning was not entirely > gone: > > In file included from ../includes/ghcconfig.h:4, > from ../includes/Stg.h:42, > from ../includes/Rts.h:19, > from RetainerSet.c:14: > ../includes/ghcautoconf.h:364: warning: `_FILE_OFFSET_BITS' redefined > /usr/include/sys/feature_tests.h:96: warning: this is the location of > the previous definition. > > (There were numerous other warnings, too many to post here.) I don't think the _FILE_OFFSET_BITS warnings have anything to do with the bus error, but if you send me the whole log I'll look into eliminating them. What version of gcc are you using? Cheers, Simon

3 2

segfault/massive memory use when using Data.Bits.shiftL
by Ganesh Sittampalam 28 Feb '05

28 Feb '05

Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh

3 4

Re: GHC 6.4 release candidates available
by Malcolm Wallace 28 Feb '05

28 Feb '05

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > I think I've fixed this (on the head anyway; simon will merge to branch > shortly). Care to try again? Yup, the toplevel rigid type-variable problem seems to have been fixed, thanks. nhc98 now builds as expected with ghc-6.4. BTW, there seems to be a small documentation-packaging fault in the linux binary distribution. You may be aware of it already. $ make install ... if test -d share/html; \ then cp -r share/html/* /usr/malcolm/local/share/ghc-6.4.20050227/html; \ fi for i in share/*.ps; do \ cp $i /usr/malcolm/local/share/ghc-6.4.20050227 ; \ done cp: cannot stat `share/*.ps': No such file or directory $ Regards, Malcolm

1 0

RE: ghc HEAD and tee
by Simon Marlow 28 Feb '05

28 Feb '05

On 25 February 2005 15:48, Christian Maeder wrote: > we used redirect output of ghc via "tee" (within a Makefile). With the > new ghc this randomly fails now. Does anyone have an explanation for > this? > > ghc <<omitted args>> 2>&1 | tee log > > yields: > > Skipping Main ( hets.hs, hets.o ) > Linking ... > tee: write error > > > The linked binary and the log file are ok afterwards (and the mere > size of the log is also no problem). Hmm, I can't reproduce this behaviour, and I can't imagine what the problem is: the error message claims a write error, so that would seem to indicate some kind of problem writing the log file, which can't be affected by GHC. Or perhaps that's just a generic error message from tee. Can you give any more details that might help us to reproduce it? Cheers, Simon

1 0

RE: 6.2.2 x86_64 build failing
by Simon Marlow 28 Feb '05

28 Feb '05

On 28 February 2005 05:38, Kip Macy wrote: > In a clean tree I configured: > ./configure --prefix=/u/kmacy/usr/x86_64 > --with-ghc=/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64/ghc/compiler/ghc -inplace > > where the ghc-inplace is unregisterised, points to stage1, and is > known to compile "Hello World" > > > gcc -E -undef -traditional -P -I../includes -x c > prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl > < prelude/primops.txt > primop-data-decl.hs-incl > /bin/sh: line 1: 14846 Segmentation fault (core dumped) > ../utils/genprimopcode/genprimopcode --data-decl <prelude/primops.txt >> primop-data-decl.hs-incl > gmake[2]: *** [primop-data-decl.hs-incl] Error 139 > gmake[2]: *** Deleting file `primop-data-decl.hs-incl' > gmake[1]: *** [boot] Error 1 > gmake[1]: Leaving directory > `/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64-clean/ghc' > gmake: *** [build] Error 1 It looks like genprimopcode is crashing. This is significant, because genprimopcode is the first Haskell program to be compiled and run by the compiler that you are bootstrapping with, so this indicates that even though your unregisterised stage1 is known to compile "hello world", it still has some problems. Try adding -debug when compiling genprimopcode, and run it with gdb to get a backtrace. Cheers, Simon

1 0