RE: 4.08 does not build on HPUX

> FWIW: > > I downloaded the src tarball, but had problems in building the > 4.08 compiler. > > 1) ghc/compiler/main/CodeOutput.lhs did not import hPutStrLn or >stderr from IO and failed to compile. > > 2) Building with 4.06 compiler, the build crashes in ghc/lib/std >while trying to

RE: First Bug in 4.08 - NCG handles floats as doubles in FFI

> BTW, if I am not mistaken, the FLOATS_AS_DOUBLES feature in > StgTypes.h will also lead to problems with the FFI if > invoked. On an architecture where > > sizeof (void *) == sizeof (double) > > but sizeof (float) < sizeof (double), we won't have a proper > representation for `CTypes.CFloa

RE: ghc-4.08 core dumps: probably parenthesis related

> Yesterday I downloaded ghc-4.08 (thanks again to Simon). > > When I ran ghc-4.08 today I got a > $ ghc geom.hs > Segmentation Fault - core dumped > > I think it is caused by the following contrived > list-comprehension. > >c' = [ e | e <- c, ((elem e ls) ] > > Note that the level of pare

RE: -fwarn-unused-imports message

> ghc-pre-4.07 -fwarn-unused-imports > > says to my ` import M () ' > > .../M.hs:42: > Warning: Module `M' is imported, but nothing from it is used > > > Should it add "except, maybe, instances" ? > Because removing this import may cause the error report about the > lack of some ins

RE: FIFO-woes solved

> Volker Stolz wrote: > > > > While thumbing through W.R.Stevens´ "Unix Network > Programming" I found > > the following which should explain everything (except the > > platform-differences): > > "What happens is the ´read´ returns zero (end of file) to the daemon > > every time a client porcess

RE: The Revenge Of The Obnoxious Time Module...

> I took a look (or maybe some more) at the well-known, totally buggy > Time module... > > > I think, I sorted out the main problems and fixed them: Comitted, thanks! Simon

RE: pre-4.07 inherits bug from 4.06

> ghc-pre-4.07-2613-i386-unknown-linux.tar.gz > > inherits this bug from ghc-4.06: > > main = > let xs = >[((1,[0,0,0,0,2,0,0,0,0,2]),(-5,[0,0,0,0,1,0,3,3,0,1])), > ((1,[0,1,0,0,0,1,0,0,0,1]),(-5,[0,1,0,0,0,1,0,0,0,1])), > ((1,[0,1,0,0,1,0,0,0,0,2]),(-

RE: strange Prelude.chr bug

> > chr :: Int -> Char > > chr (I# i) | i >=# 0# && i <=# 255# = C# (chr# i) > >| otherwise = error ("Prelude.chr: bad argument") > > So a Haskell program that (perhaps inadvertently) uses a > Unicode character > will fail with ghc. Our Char type is currently

RE: strange Prelude.chr bug

> > > Fail: Prelude.chr: bad argument > > > > nofib/real/compress2 fails with the same message, for us. > > We haven't investigated. Perhaps it's the same bug. > > With a quick grep through the two programs, my guess is that 'toEnum' > is being specialised at type Char to an internal function

RE: Heap overflow is not catched

> grepping through sources suggests that nobody tried to implement this, > only the exception constructor exists... OTOH stack overflow works. > > import Exception > main:: IO () > main = print (length (l++l)) `catchAllIO` print > where l = [0::Int ..] Yes, I know: heap overflow is somewhat

RE: bug in ghc, hugs, or green-card

> Simon Marlow <[EMAIL PROTECTED]> writes: > > > > So, the question is, "Should readFile on a directory throw an IO > > > error?" If so, then there is a bug in Hugs; if not, > there is a bug > > > (or at least a severe misfeature) in Green

RE: bug in ghc, hugs, or green-card

> So, the question is, "Should readFile on a directory throw an IO > error?" If so, then there is a bug in Hugs; if not, there is a bug > (or at least a severe misfeature) in Green Card (and a bug in the ghc > libraries, which do throw an IO error). I rather think that openning a directory fail,

RE:

> May I know what happened? > > Regards, > xu na > > PS: > panic! (the `impossible' happened): > Lex.popContext: empty context > > Please report it as a compiler bug to > [EMAIL PROTECTED] You probably have a parse error in your file. This error message has improved somewhat in rece

RE: ghc build on HP-UX

> > Hmm. I would guess that your gcc is using the native HP/UX > > assembler and not GNU as, so it doesn't understand the .file > > directive. If you sent us the output of > > > >make EXTRA_HC_OPTS=-optc-v > > > > we could check that hypothesis. However ... > > Here it is, hope it hel

RE:

> When compiling ghc-4.06 I get this error message: > > ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall > -optc-W > -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith > -optc-Wbad-func

RE: 4.07 branch failing to build w/ 4.06?

> I pulled down the 4.07 branch this morning and tried to build > it with 4.06. > Unfortunately, I get this: > > ../../driver/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C > -Rghc-timing -O > -package-name std -static -split-objs-c PrelIOBase.lhs -o > PrelIOBase.o > -osuf o > Warning: >

RE: underscore does not start a varid

> Hi, > > my program uses (data-) variables beginning with _. This is > legal Haskell > 98 and Hugs accepts it. GHC 4.06 thinks these are constructors. This was indeed a bug in 4.06, but we've fixed it since and the fix will be in the upcoming 4.07. Incedentally, the bug was that identifiers

RE: URI.relativeTo type signature in comment (URI -> URI -> URI)

> Tue, 23 May 2000 07:03:56 -0700, Simon Marlow > <[EMAIL PROTECTED]> pisze: > > > I believe I've fixed this one now. > > Erm, but there must be another bug. Its effect is > fatal error: evacuate: THUNK_SELECTOR: strange selectee 27 > > The best

RE: GHC crashes: the `impossible' happened

> I have a simple Haskell source file that uses unboxed tuples > and causes > GHC-4.07 (from the CVS repository last week) to crash, with or without > optimization. > > The source (Bug.hs) is: > > module Bug (scaleInt) where > > import PrelGHC > > scaleInt :: (# Int, Int #) -> Int -> Int > s

RE: URI.relativeTo type signature in comment (URI -> URI -> URI)

> Yes, although it's quite big as a bug report. > > http://qrczak.ids.net.pl/Haber-0.1.tar.gz > > It's Linux. > > $ make > $ COLUMNS=70 LINES=25 ./haber bug.html > > I could not find a repeatable example which fails on an 80x25 screen > now (this one fails on 128x48 too). It fails with "EVACUA

RE: URI.relativeTo type signature in comment (URI -> URI -> URI)

> I can't get this to fail, except with > > Fail: failed > Reason: clrtoeol failed > > after a few page-downs. We might need to synchronise termcap > entries (oh > BTW I had to compile with -ltermcap instead of -ltinfo > because this system > doesn't appear to have terminfo

RE: URI.relativeTo type signature in comment (URI -> URI -> URI)

> > Yes, although it's quite big as a bug report. > > http://qrczak.ids.net.pl/Haber-0.1.tar.gz > > It's Linux. > > $ make > $ COLUMNS=70 LINES=25 ./haber bug.html > > I could not find a repeatable example which fails on an 80x25 screen > now (this one fails on 128x48 too). It fails with "EVAC

RE: URI.relativeTo type signature in comment (URI -> URI -> URI)

> does not agree with reality (URI -> URI -> Maybe URI). Thanks; fixed. > > > PS. I am getting the following errors in my web browser written for > assignment. I'll prepare a test version soon. > > EVACUATED object entered! > fatal error: evacuate: THUNK_SELECTOR: strange selectee 27 > fatal

RE: Problem with happy

> ghc -cpp -fglasgow-exts -O-c IntSet.lhs -o IntSet.o -osuf o > > panic! (the `impossible' happened): > primCode:Word2IntegerOp > > Please report it as a compiler bug to > [EMAIL PROTECTED] > > Source: happy 1.6 downloaded from haskell.org last week. > Host: SPARCstation 5 running

RE: Blocking I/O & FIFOs

Grrr. This works: module Main (main) where import IO import Posix import PosixUtil import Concurrent main = do h <- openFile "/tmp/fifo" ReadMode fd <- handleToFd h threadWaitRead (fdToInt fd) line <- hGetLi

RE: Blocking I/O & FIFOs

> Testing under Linux showed that after opening a fifo with O_NONBLOCK > we should call select on it before read: it will not say we can read > from it until another process opens it for writing. > > And when another process opens it for writing and closes without > writing anything, select says

RE: Blocking I/O & FIFOs

> In fact, I think, the situation is - or should - be a little > different. Not reading from the FIFO should block, but > _opening_ it. Check out the documentation for glibc: > > http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_10.html#SEC178 Ah, that makes a *lot* more sense. I hadn

RE: ghc -v always makes gcc-2.95.1 dump core?

> "Signal 127"?! I don't understand this. Doesn't seem to happen here, but it may be a bug in your 'as'. GHC's native code generator is now used by default when GHC is invoked without -O, so the problem isn't your gcc, but more likely your binutils. Cheers, Simon

RE: Blocking I/O & FIFOs

> It is certainly better after a fix, at least for > single-threaded programs > which work perfectly. > > With native threads (BTW, are they expected to work soon?) it > would work > well too. Perhaps... but pthreads emulated in user-space would suffer from the same problems as GHC, because th

RE: Blocking I/O & FIFOs

> Thu, 11 May 2000 06:39:10 -0700, Simon Marlow > <[EMAIL PROTECTED]> pisze: > > > The solution, if you're interested, is to open the file in blocking > > mode and set O_NONBLOCK later on with an fcntl(). > > It means that waiting for the writer bloc

RE: Blocking I/O & FIFOs

I'm pretty sure I've fixed this one now. The solution, if you're interested, is to open the file in blocking mode and set O_NONBLOCK later on with an fcntl(). SO fd = open("filename", flags | O_NONBLOCK); behaves differently from fd = open("filename", flags)

RE: Blocking I/O & FIFOs

> On Wed, May 10, 2000 at 09:04:53AM -0700, Simon Marlow wrote: > > I bet this is because you're getting a SIGPIPE, where the > default behaviour > > of SIGPIPE is to exit the process without warning. You need to: > > ... > > > > and then you&

RE: Blocking I/O & FIFOs

> However I think I am getting exactly the same problem. (On > Solaris/Sparc, > using CVS GHC compiled by itself.) However instead of using > pipes I am > using sockets. > > Even worse, if the party of the second part closes the handle > attached to > the socket, and the Haskell process to w

RE: Blocking I/O & FIFOs

> I encountered the problem too a few days ago. It does not wait for > another process to open the fifo, but returns EOF immediately. > > It works only when another process opened the fifo for writing before > we opened it for reading. > > The problem happens in ghc-4.06 and 4.07. It worked OK i

RE: bug in foreign import (for floats)

> ghc-4.06 (downloaded from the ftp site; I haven't tried the current > CVS version) appears to have a bug in the FFI, demonstrated by the > following code using Floats. [ snip ] I believe this bug was fixed recently (foreign imports with non-IO return types weren't being handled properly). Chee

RE: Blocking I/O & FIFOs

> ghc-4.07 can´t read from Unix-FIFOs because a hGetLine will > throw an EOF. > > > module Main (main) where > > import IO > > main = do > > h <- openFile "/tmp/fifo" ReadMode > > line <- hGetLine h > > putStrLn line > > hClose h > > dhs@monster [15:46:31]> mkfifo /tmp/fifo; ./test >

RE: If this bug is important let me know

> Mike Jones wrote: > > I get this error with 4.05. If it is important, I can send source. > > > > c:/tmp/ghc5016.hc:30113: warning: `X1Z_closure' was declared > > `extern' and later `static' > > This is one of GHC's classics. But it isn't a real error, only a > warning from the C compiler, whi

RE: some targets are broken

> `make maintainer-clean' goes into an endless loop. `make > veryclean' dies in > `/home/chak/fptools/glafp-utils/mkdependC' and many of the > targets documented in `fpools/mk/target.mk' do not exist > anymore. > > [This is from CVS, checked out just now.] I think I've sorted this out now. ve

RE: profiling a faulty program produces a segfault (4.06)

> -davenant:~/junk> cat t.hs > main = error "bang!" > -davenant:~/junk> ghc t.hs > -davenant:~/junk> ./a.out > > Fail: bang! > -davenant:~/junk> ghc -prof -auto -auto-all t.hs > -davenant:~/junk> ./a.out > Segmentation fault (core dumped) > -davenant:~/junk> ghc --version > The Glorious Glasgow

RE: fixed Heap size??

> I got the following problem executing my program: > > >mpirun -np 52 truth.exe +RTS -H128m -M128m -RTS ... > >Heap exhausted; > >Current maximum heap size is 67108864 bytes; > >use `+RTS -M' to increase it. > > Although I increased manually the Heap-size, this option seems to be > ignored. I

RE: ghc/rts/RtsUtils.c

> ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall > -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith > -optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static > -O2 -opt

RE: Posix.FileMode

> hslibs/posix/doc/posix.sgml says that FileMode is an instance of Eq > and Integral, but in reality it is not. There is no way of examining > FileModes! I will have to reimplement an interface to stat() myself. Yes, it's a bit sad. The POSIX library needs a complete re-implementation, but I'd l

RE: PrelException.blockAsyncException

> Is it possible that you forgot to commit a new version of > `PrelException.lhs' yesterday? At least, `PrelHandle' and > `PrelIO' seem to expect a `PrelException.blockAsyncException'. > In particular, I get > > ../../driver/ghc-inplace -recomp -cpp -fglasgow-exts > -fvia-C -Rghc-timing -O -

RE: Unhelpful Haskell error messages

> I think > test9: fatal error: resurrectThreads: thread blocked in a > strange way > qualifies. hehe ;) Better send me that program. Simon

RE: Bootstrapping ghc with -O fails

> Building 4.07 with 4.06 works fine, but in a second bootstrapping > phase the fresh 4.07 can't compile itself, at least not with > "SRC_HC_OPTS += -O". Without -O everything seems to work... We know about this one. I'm about to commit a hack, and Simon will follow up with the Real Fix in due

RE: ghc/rts/RtsUtils.c

> OK, this is why I think it's happening. Stg.h (#include'd via Rts.h) > sets the macro _POSIX_C_SOURCE. This prevents Sparc/Solaris' > sys/time.h > defining "struct timeval" and gettimeofday. (Indeed if I add the line > #undef _POSIX_C_SOURCE to RtsUtils.c just before include sys/time.h > i

RE: compiled program loops

> In the real application I also get the error: > bingraph: fatal error: evacuate: THUNK_SELECTOR: strange selectee 27 > which I'm hoping is related, because I have no idea what it means and > I can't reproduce this in an example program. Any idea where I should > be looking for the cause of this

RE: Catching black holes

> Consider > > import Exception hiding ( catch ) > main = tryAll (let x = x in x :: ()) >>= print > > (Using current CVS; WinNT box). > > My understanding was that GHC exceptions could catch blackholes. > But the above program causes: > > bash% ../driver/ghc-inplace Blackhol

RE: Bug in GHC - black holing

> In GHC, 4.07: > > module Main where > main = print (let x = x in x :: ()) > > With the latest CVS srcs, on WinNT, crashes with > > main.exe: fatal error: schedule: invalid what_next field Hmm, it looks like a chunk of code got commented out when Hans committed his recent GR

RE: Profiling.h in the attic

> Simon Marlow wrote: > > Yes, I removed Profiling.h from ghc/includes and added it > to ghc/rts. You > > might need to 'make boot' > Actually it was gmake boot that was falling over. However I > seem to have > fixed that by doing "gmake depend"

RE: Profiling.h in the attic

> ==fptools== gmake boot --no-print-directory -r; > in /usr/local/pub-bkb/ghc/fptools/ghc/includes > -- > -- > gmake[2]: *** No rule to make target `Profiling.h', needed by > `mkNativeHdr.o'. Stop. > gmake[1]: *** [boot] Error

RE: happy/LALR.hs doesn't compile

> With sources (and GHC) as checked out at 3am BST today: > > /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts > -O -H12m -c LALR.lhs -o LALR.o -osuf o > > LALR.lhs:314: Variable not in scope: `newArray' > > LALR.lhs:316: Variable not in scope: `freezeArray' > > LALR.lhs:336:

RE: rename/ParseIface doesn't compile with -O

> With GHC compiled from the night-before-last's CVS, compiling > last-night's > CVS, I get > > ==fptools== gmake all --no-print-directory -r; > in /usr/local/pub-bkb/ghc/fptools/ghc/compiler > -- > -- > /usr/local/pub-bkb/ghc/

RE: ghc/lib/cbits/system.c doesn't compile

> ==fptools== gmake all --no-print-directory -r; > in /usr/local/pub-bkb/ghc/fptools/ghc/lib/std/cbits > -- > -- > ../../../driver/ghc-inplace -O -I../../../includes > -I../../../rts -Wall -static-c system.c -o system.o >

RE: threadWaitRead & signals broken

> It seems that Ctrl-C triggers a ´threadWaitRead´ (I have a > sigInt-handler > installed, which gets triggered, too). > > If I use > > _ <- installHandler sigINT (Catch (putStrLn "test" >> > putMVar haltMVar () )) > Nothing -- Ctrl-C > > muxCh <- newChan > > forkIO (takeMVar hvar >> wr

RE: standard library conformance

> As I discovered, ghc doesn't implement the standard library > function "doesFileExist" > correctly. I can't repeat this problem on Linux, so it may be a HP-specific bug. Can anyone with an HP box verify it? Cheers, Simon

RE: ghc/compiler/utils/FastString.lhs won't compile (suspect version skew)

> Er, has this bug report been lost? It doesn't seem to have > been dealt with . . . There may be bootstrapping problems when building GHC with a snapshot (post-4.06) build, because we only support the following scenarios: - bootstrapping GHC with a released version - bootstr

RE: FreeBSD port of 4.06

> At Fri, 17 Mar 2000 04:02:43 -0800, > Simon Marlow <[EMAIL PROTECTED]> wrote: > > > > Really? Does the supplied patch not fix the problem for you? > > It worked on my box. > > Sorry, it's my misunderstanding. I can build by only your patch. &g

RE: Fail: thread killed

> IMHO this program should not print "Fail: thread killed". Removing > the first threadDelay causes the message to disappear. It can be > worked around by catching the exception in the thread to be killed. > > import Concurrent > > kill:: IO () > kill = do > result <- newEmptyMVar > f

RE: FreeBSD port of 4.06

> At Mon, 06 Mar 2000 18:43:34 +0900, > Yoshiyuki ONOUE <[EMAIL PROTECTED]> wrote: > > > See . > > Same error happened in our 3.3-RELEASE environment. > > Thank you for updating a freebsd port of ghc-4.06 and > I saw "Problem Report port

RE: GMP compilation blues.

> `/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp/mpz' > ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall > -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return -optc-Wpointer-arith > -optc-Wbad-function-ca

RE: virtual timers and System.system

> The correct handling would be: > - block SIGALRM/SIGVTALRM/SIGPROF > - *then* fork() (else you have a race condition where the child could > receive *and handle* the signal) This race condition is harmless, I think. The VTALRM handler just increments a counter, and we're about to blow away t

RE: virtual timers and System.system

> I don't get it - execve() and friends are supposed to reset > all the signal > handlers back to the default state, aren't they? And I can't seem to > construct an example to demonstrate the problem. Ah, I get it finally :) It's the itimer, not the signal handler that's causing the problem.

RE: virtual timers and System.system

> On FreeBSD using ghc 4.04, long running commands executed with > System.system are being interrupted by virtual alarms leading to > errors such as: > > o Fail: interrupted > Action: system > Reason: system command interrupted rm -f xxx yyy > > o Virtual timer expired > > o gcc: Inter

RE: building from .hc files

> I've just tried to build GHC 4.06 from the ix86 .hc file distribution. > It all went swimmingly until near the end when I got the > following error: > > $ autoconf > $ configure --enable-hc-boot > $ make boot > $ make all > [...] > ./driver/ghc-inplace -o hsc -cpp -fglasgow-exts -Rghc-timing

RE: gmp configure (fwd)

> Simon Marlow wrote: > > It builds fine for me here with autoconf 2.13 on Solaris. > Perhaps you have > > some old configure files lying around in ghc/rts/gmp/*. > Try blowing away > > your gmp subtree and starting again. > After deleting the whole of ghc, re

RE: gmp configure (fwd)

> Simon Marlow wrote: > > What version of autoconf is this, just out of interest? > > autoconf --version > > Autoconf version 2.13 > Oh no, don't tell me I've got to install a private copy of > yet another bit of > software to compile GHC . . . It build

RE: gmp configure (fwd)

> Reuben Thomas wrote: > > > > I already came across this, and Sigbjørn sent me a fix, > which should soon > > be in CVS. Just in case it's not, it follows below. I found > that I also > > needed to change rts/gmp/configure.in so that the first > call to AC_INIT > > occurred after the setting

RE: hsc crashes when compiling GHC 4.06 sources

> I downloaded the sources from GHC 4.06, made the shallow tree, added a > build.mk in mk/ with -H80, later with -H80 -O2, made > ./configure in ghc/ > and ./configure in the main tree, (copied both .y files because happy > doesn't work on links done with lndir -- it's only NT), said > make boot

RE: make all -> SocketPrim error

> When making ghc from cvs, make all fails due to a > SocketPrim -syslib lang -syslib text > -optc-DNON_POSIX_SOURCE -c SocketPrim.lhs -o SocketPrim.o -osuf o > > does not exist > Action: getDirectoryContents > Reason: no such file or directory > /newdisk/dongen/CVS/fptools/hslibs/

RE: threadWaitRead on a closed Fd - - -

> causes the entire program to crash. (Not just the thread > that is doing the > threadWaitRead.) Is this not a little drastic? To run the > attached code use > > ghc -syslib posix -syslib concurrent -cpp ThreadWaitFail.hs -o TWF > ./TWF You're right, this is a bug. But I'm not sure what t

RE: Signals once again.

> The following code does nothing one sent a -USR1 but "succeeds" (i.e. > fails with "User defined signal 2") on -USR2. > I'd be happy if someone could point me to the important thing I'm > constantly missing. Oh dear. It looks like signal handling support has been broken for some time. A patch

RE: gmp configure (fwd)

> On the subject of bugs for which fixes are found which don't > seem to make > it into the CVS repository for a while, why exactly does RtsUtil.h > still contain the line > extern StgStablePtr errorHandler; > when "errorHandler" isn't actually defined anywhere? > ("extern" of course doesn't

RE: bug report

> Compiling the following with ghc-4.06 produces an erroneous > error message: > > module O where > > a :: Int > a = 1 > > b :: Int > b = 2 > > c :: Int > c = 3 > > f :: Int -> Bool > f i = case i of >a -> True >b -> True >c -> True > > > The compiler complains: > > o.hs:14: P

RE: lex "1x23" == [("123","")] && reads "1x23" == [(123,"")]

> They should not. Thanks, this is now fixed (well partially, we don't attempt to lex hexadecimal literals any more). Cheers, Simon

RE: missing Native?

> It appears that the library Native has disappeared between 4.04 and > 4.06, in the big hslibs reorganisation. Can we expect it to return, > and if so, when will it come back? I don't think it's going to return, but if there is something you rely on from it, then we should attempt to support i

RE: bug in layout parsing

> ghc 4.06, solaris 5.7, distributed binaries. > > the extra closing brace isn't caught in time... > > > main > > = do > > putStr "hello" } > > hence: > > panic! (the `impossible' happened): > Lex.popContext: empty context Thanks for the report. This one was fixed recently i

RE: cvs: make all -> error PackedString.lhs

> I've already fixed that one (and a related bug in ghc itself) > yesterday evening. But I don't know when exactly these changes > are mirrored in the anonCVS. > > A note for GHC-from-CVS afficionados: Due to versionitis which is not > reflected in GHC's version number, you probably have to tempo

RE: hslibs/tools/DtdToHaskll

> (when doing gmake in the fptools directory.) > ../../../ghc/driver/ghc-inplace -o DtdToHaskell -cpp > -fglasgow-exts -syslib text-H40m -OnotDtdToHaskell.o > DtdToTypeDefPP.o > /usr/local/pub-bkb/ghc/fptools/hslibs/data/libHSdata.a(FiniteM > ap__1.o)(.text+0x38): undefined reference t

RE: -O2 == crash

> 2.95.1 > > With -O -O2-for-C it still crashes. With -O it does not. > With -O2-for-C it does not. > > (gdb) bt > #0 0x804932a in Main_zn_fast2 () > #1 0x500c0444 in ?? () > #2 0x500c1fa4 in ?? () > #3 0x468bfc45 in ?? () > Cannot access memory at address 0x8908468b. We could investigate f

RE: -O2 == crash

> The following code crashes when compiled with -O2. With -O it does > not crash. Some trivial modifications make the crash go away. Sorry, I can't repeat this one. As far as I can tell, using -O2 does three things - it forces -fvia-C (on by default anyway) - it passes -O2 to g

RE: _ is not always small (syntactically :-)

> GHC's lexer (function Lex.mk_var_token) treats names starting with > an underscore followed by an uppercase letter as a constructor (conid) > and not as a variable (varid): > >module Foo where >data T = _ThisWorksAlthoughItShouldNot >_ThisShouldWorkButItDoesNot = '?' > > A comment

RE: StablePtr Integer == crash

I believe I've fixed the foreign export problems now, at least the examples I've tried now work. However, this is a fairly large change so it may need a couple of days to settle down. Cheers, Simon

RE: hdirect server example

Sigbjorn Finne writes: > Looks like a ghc problem (with 4.04, at least) - Cc'ing the > ghc-bugs list in case anyone there wants to track down why > (nfib 20) crashes when called via 'foreign export' (the > program in question can be found in hdirect/examples/server/.) This one is the same bug as

RE: StablePtr Integer == crash

Martin Kowalczyk writes: > $ ghc -fglasgow-exts -c Crash.hs > $ ghc -c crash.c > $ ghc -fglasgow-exts Crash.o Crash_stub.o crash.o -o crash > $ ./crash > 10302 > zsh: segmentation fault ./crash > $ ghc --version > The Glorious Glasgow Haske

RE: GHC Bug on NT 4.0, threading problem?

> > You mean this one: > > > > subl $RESERVED_C_STACK_BYTES + 4*SIZEOF_LONG,%esp > > > > subracting from %esp caused the program to exit? Surely not! > > Specifically, anything after the subl ,%esp > did not happen. Perhaps causing an uncaught page fault? > (I dont think that the subl

RE: GHC Bug on NT 4.0, threading problem?

> > A strange bug indeed, but what brings you to this conclusion? > > Because > (1) I hacked the *.S code that start STG execution to call > printf after each instruction, and the allocate stack > space *instruction* caused the problem. You mean this one: subl $RESERVED_C_S

RE: This could be a bug

> Hello lovely GHC people. I may have found a bug. > > If I leave a hanging right brace where one might have been for a 'let' > expression, eg: > > let env' = extendVarEnvList rho env } > > I then receive the message: > > panic! (the `impossible' happened): > Lex.popContext: empty co

RE: GHC Bug on NT 4.0, threading problem?

> Bug (1): A totally clean, top of the CVS tree does not work on NT 4.0. > > Behavior: returns with no result, any program. > Strange: Adding '+RTS -s' makes things work fine. > I think that there is not enough stack space on the C stack, > and the "change %esp register is failing us". The alloca

RE: Profiling.c:462: parse error before `<'

> Hello again, > > When making cvs it halts because of a > Profiling.c:462: parse error before `<' > I have appended a log. It looks like you had a conflict when you cvs updated. Check Profiling.c for the telltale ''. If you didn't make any changes to Profiling.c that you want to keep (I

RE: How to handle hi-file versionitis/a possible library scheme

> > Will ghc change interface format with each version? > > This is the biggest problem (and, interestingly, the least > addressed :-)). > Especially for binary distribution builders, it's quite > inconvenient to > rebuild every GHC-library on the system to match with the > latest compiler > v

RE: Strange crashes with ForeignObj + foreign export dynamic

I believe this bug is the weak ptr bug I fixed last week. In any case, the example works with the latest sources (and I verified that it indeed crashes under ghc-4.06). > The story (not part of the bug report). > > I've made most of a Haskell<->Perl interface for fun. Closures > are convertible

RE: make boot fails: mkdependHS-inplace: can't open directory haxml/lib

> When carrying out a make boot with cvs this caused a problem > because of the following: > mkdependHS-inplace: can't open directory haxml/lib Maybe you need to 'cvs update -Pd'. The haxml directory just appeared yesterday. Cheers, Simon

RE: Profiling.c:462: strucuture has no member named `emitted'

> I just updated cvs and now make fails because of a > Profiling.c:462: strucuture has no member named `emitted' > thingy. Log appended. my bad; now fixed. Cheers, Simon

RE: cvs 4.07 arithmetic errors in Integer arithmetic

> I am trying to fix some errors in the Integer arithmetic > Simon Marlow and I spotted. > > I just reinstalled cvs from scratch yesterday and build ghc-4.07 > from it. I then noticed that one of my programs resulted in > completely different output than it did with ghc-4.06 (o

bug reports

That pretty much completes my sweep over the outstanding bug reports today. Thanks everyone for bearing with us. I've got the following left to deal with: - Ralf Hinze's "Misleading error message" (Simon - looks like your domain this one) - Marcin Kowalczyk's result type signatures, wh

RE: Documentation of MVars

George Russell writes: > I find the documentation of takeMVar and readMVar in section > 1.4.1 confusing > if not non-existent. Thanks, I've updated the documentation on MVars to be a little closer to reality. Cheers, Simon

RE: Weak pointers, finalizers and SIGSEGV

> But testing this showed another strange phenomenon: The heap grows > infinitely. :-( A cut-down version, which has the same effect: > > > import Addr > import Foreign > > main:: IO () > main = do >fo <- mkForeignObj nullAd

RE: Weak pointers, finalizers and SIGSEGV

> The following program causes SIGSEGV after a few thousands of > iterations. > > I compile with 'ghc test2.hs -o test2 -fglasgow-exts' by ghc-4.06 on > Linux, gcc-2.95.1, glibc-2.1.2. With ghc-4.04 it crashes too. > > -- > -- >

RE: DocBook again / other patches

> The Long Version(TM): > re DocBook: > Firstly, I have to admit, I did not completely discover how > and why DocBook > handles things like it does, but hardcoded paths are always evil. > > I have a file /etc/sgml.catalog on my system which handles the mapping > DTD<->filename, so I replaced the

<    5   6   7   8   9   10   11   12   13   14   >