RE: Trouble installing ghc 6.0 on Solaris
> I've tried installing ghc 6.0 on Solaris under /opt/ghc. The > files that get created include a bunch with references to Hal > Daume's home directory (e.g., /opt/ghc/bin/ghci-6.0 needed to > be changed). We have some problems with the Solaris binary tarball at the moment. Hopefully we'll get them straightened out soon. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Problems installing ghc 6.0 on freebsd
> We've been trying to install ghc 6.0 on our freebsd boxes > using the port at > freshports: > > http://www.freshports.org/lang/ghc6/ > > And following the advice on the ghc download page > (http://www.haskell.org/ghc/download_ghc_600.html). > > Sadly, it dies when it tries to build the libraries (partial > transcript attached) > > The existing ghc version seems fresh enough and seems to work. > Any thoughts on what might be going wrong? It looks like you're trying to do a parallel make (make -jN). We have some known problems in this area. I'm not sure exactly where the -j flag would be coming from, but I'm fairly sure it's not the default. Check your /etc/make.conf. The port should probably turn off -j if it finds it. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC running out of memory, surprisingly.
> Yes, I know functional languages are memory hogs, but really! > > The following is on linux > > # ghci > ___ ___ _ >/ _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.0, for Hask > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > Loading package base ... linking ... done. > Prelude> :module + Foreign.Marshal.Alloc > Prelude Foreign.Marshal.Alloc> b1 <- mallocBytes 1000 > Prelude Foreign.Marshal.Alloc> b2 <- reallocBytes b1 0 > *** Exception: resource exhausted > Action: realloc > Reason: out of memory Fixed, thanks for the report. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC bug on MacOSX 10.2.6
> Question to "the bosses": should I rename HsReadline.c to > HsReadline_cbits.c by cvs-removing it and then cvs-adding it? > Do I just have to do that separately for the HEAD and STABLE branches? Yes, and yes. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: locating package.conf
> Simon Marlow wrote: > > [...] but 'make install' on Windows is very rare anyway > (most people > > just install from the .msi or run it from the build tree). > > But a 'make install' is not so rare if you took the trouble of > installing half a dozen utilities to do a successful 'make'. :-) > > > I'd only be guessing at the right way to fix this. > Perhaps SysTools > > should look for $prefix/lib/package.conf in addition to > > > $prefix/package.conf? > > Hmmm, I'm not sure how to fix this correctly (probably the 'make > install' logic on WinDoze is simply broken), but a quick workaround > would be a shell script / batch file adding > > -Bc:\Programme\cygwin\usr\local\lib\ghc-6.1 > > to the commandline for ghc.exe and ghci.exe (if your prefix was > /usr/local and your Cygwin is installed in c:\Programme\cygwin). After looking at this, the conclusion seems to be that 'make install' on Windows is not supported. With some effort it could perhaps be made to work: you're welcome to tackle it, but I doubt that we will. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Problem when compiling with -prof -fasm
> when compiling anything with -prof -fasm, I get the following > response: > > ghc-6.0: panic! (the `impossible' happened, GHC version 6.0): > AbsCStixGen.gencode > CC_DECLARE(CGI_CAFs_cc,"CAF","CGI",CC_IS_CAF,); > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. Using -prof with -fasm is not supported. The error message is clearly bogus, though - I'll see what I can do about it. > (without -fasm I get > > Prologue junk?: .globl __stginit_CGI > .type __stginit_CGI,@function > __stginit_CGI: > pushl %ebp > movl%esp, %ebp > > instead, which is probably caused by non-supported version of > gas or gcc?) You probably have a version of gcc that isn't supported by the version of GHC you have installed. We usually recommend gcc 2.95, but later versions may work depending on your version of GHC. Cheers, SImon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Strange ghci :def failure
> This is an embarrassing bug in 6.0. Alas. We need more regression > tests for ghci. > > Workaround: do not write expressions in ghci with pattern matches that > may fail. There's a slightly less intrusive workaround: Prelude> :t GHC.Err.error GHC.Err.error :: forall a. [Char] -> a Prelude> let [x] = [] Prelude> Leaving GHCi. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Package Main
> I'm running into a strange problem when I build the X11 > library using current > ghc (built from repository yesterday using gcc 3.2). The > error message I get > is: > >ghc-6.1: unknown package name: Main > > The puzzling bit here is that I am compiling a part of a > library using -c, I > don't mention a package called Main and package.conf doesn't > mention the word > Main. So why does the error message mention Main? 'Main' is the name of the default package. That is, when you don't give a -package-name flag, the module being compiled is assumed to belong to package 'Main'. The 'Main' package usually contains the 'Main' module. I can't tell exactly what's gone wrong, but perhaps you managed to compile a module without a -package-name flag somewhere? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: locating package.conf
> After building GHC6.1 from CVS a few days old now, on Win2k with MinGW > 3.2, I tested it in the build tree and it worked fine. After > performing > make install, the GHC completely stopped working because it couldn't > find package.conf(.inplace). I eventually tracked it down to a > self-described "hack" in SysTools.lhs that decides if it's > installed or in the build tree by whether package.conf can be found in > TopDir (which I'm assuming is (usu.) $prefix). Sometime in the past > couple months all the files in $prefix got moved to $prefix/lib, the > result being the installed GHC thinks it's in the build tree and dies > when it can't find $prefix/driver/package.conf.inplace. I'm not sure > where in the build system this was changed or what's the best thing to > do about it (in general; moving lib to $prefix and copying gcc to > $prefix [though that's probably due to the way I configured] seems to > get it working for me.) This change was made to remove some special Windows-only cases in the build system. We weren't sure exactly what it might break, but 'make install' on Windows is very rare anyway (most people just install from the .msi or run it from the build tree). I'd only be guessing at the right way to fix this. Perhaps SysTools should look for $prefix/lib/package.conf in addition to $prefix/package.conf? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc --make and missing interface files
> Hello all, I have a file BinaryIO. This used to import a module > HGetCharHack to work around an annoying problem with ghc5.04 which > meant that hGetChar was blocking unexpectedly. However I see that > this problem has now been fixed in ghc6 (ta very much, Simon) so I > deleted the files HGetCharHack.*, modified BinaryIO to stop importing > it, and then tried to compile it using ghc --make. However the thing > fell over, as follows: > > > Skipping ... (lots of files) ... > > Skipping UnionFind > > > > Could not find interface file for `HGetCharHack' > > (use -v to see a list of the files searched for) Yes, this is a known bug (it's been on my whiteboard for a few months). We will get around to fixing it at some point. In the meantime, deleting the offending .hi file is the easy workaround. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: problem compiling OpenGL/.../Extensions.hs with GHC version 6.0
> > But in any case, just removing the double quotes from your > -D option > > should be enough to fix it. > > Well, fixing my humble Makefile is not the point, I'm more concerned > about this gratuitous change in the handling of quoting which breaks > other people's Makefiles. > > Regardless of the solution, th quoting issue should be documented in > the GHC docs somehow. AFAICT, GHC on Windows has always done this quoting, the change was to make GHC on Unix do it too. I think the reasoning behind it was to fix some bugs related to filenames with spaces in. We now consistently surround all arguments to external commands in quotes, which on the face of it seems like a reasonable thing to do, no? It could be made more bulletproof, by quoting each character individually I suppose. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: problem compiling OpenGL/.../Extensions.hs with GHC version 6.0
> Andres Loeh wrote: > > [...] The problem (that can be witnessed by calling ghc with the > > option -v) is that in calling the C preprocessor, the double quotes > > around the value of GET_PROC_ADDRESS, which are syntactically > > necessary, are no longer present. The problem can be fixed by > > quoting the double quotes once more, i.e. by saying > > > > SRC_HC_OPTS += -DCALLCONV=ccall > '-DGET_PROC_ADDRESS=\"glXGetProcAddressARB\"' > > > > However, this is a change in behaviour compared to earlier versions > > of ghc that seems undesireable to me ... [...] > > I'm currently developing within the build tree of the HEAD from May > 24th, and the double quotes *do* come through. If newer GHCs changed > that behaviour, that would truly suck and probably breaks lots of > Makefiles out there. I guess I'll have to build a new GHC to > investigate this further... >:-( GHC now adds double quotes around all the arguments to gcc. It *doesn't* add any extra quotes to the -D and -U arguments any more. Perhaps we should be using single quotes instead. But in any case, just removing the double quotes from your -D option should be enough to fix it. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Removing greencard from project list
> I'd like to remove greencard from the list of projects that > can get built if > you 'make' in fptools. > > I see a list AllProjects which include 'green-card' in > fptools/mk/config.mk.in > Is this the bit I need to edit? > It looks plausible but I'm not certain. Yes, that should work. Why would you want to do that, though? Is it just the difficulty of maintaining two parallel Makefile setups? I found it useful to be able to build greencard in my source tree when I was testing your X11 library the other day. I did have to fiddle around quite a bit to make it work though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC *is* resource hungry
As far as I know, Hugs doesn't hash-cons types, yet it manages to typecheck these pathalogical examples in reasonable time/space. I vaguely recall there being a specific modification to Hugs's typechecker to handle this, but I can't remember what it was. Cheers, Simon > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Simon Peyton-Jones > Sent: 28 May 2003 15:57 > To: Ralf Hinze > Cc: GHC bugs > Subject: RE: GHC *is* resource hungry > > I bet it's massive types. Translate the program into system > F and see. > (I remember this came up when looking at Okasaki's sequences of code > combinators.) > > GHC doesn't try to hash-cons types, because it usually doesn't matter, > but I bet it does here. > > S > > | -Original Message- > | From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > | Behalf Of Ralf Hinze > | Sent: 28 May 2003 15:32 > | To: [EMAIL PROTECTED] > | Subject: GHC *is* resource hungry > | > | Here is a harmless little program (no recursion, no data types) > | which GHC doesn't manage to compile (well, the kernel kills GHC > | after a while on a machine with generous 512MB of main memory > | and 1GB of swap space). > | > | > begin next = next id > | > leaf k i next = next (k i) > | > fork k next = next (\ t u -> k (t + u)) > | > end x = x > | > main = print (begin fork fork fork fork fork fork fork fork fork > fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 > | leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) > | > | Both Hugs and nhc98 accept it almost immediately. > | > | Cheers, Ralf > | > | ___ > | Glasgow-haskell-bugs mailing list > | [EMAIL PROTECTED] > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > ___ > Glasgow-haskell-bugs mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: freeBSD problem with Network library
> p.s. How do I compile ghci from source ? What problem are you having? With what version of the GHC sources? The building guide should contain all the required information. If not, please let us know where it is lacking. http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: build of GHCi 5.04.3 fails to work (libgcc.a)
> > > If you call the linker through gcc, I would expect it to > > > automatically add libgcc.a when necessary, unless told not to. I > > > assume you have your reasons for linking the way you do, however. > > > > Yes, the problem is our dynamic linker which can only get access to > > (a) symbols it knows about from objects it loaded and (b) symbols > > from other dynamic libraries. These libgcc symbols are statically > > linked, so they need to be listed explicitly in the linker's symbol > > table. This is kind of an ugly wart, but there doesn't seem to be > > an easy way around it. > > So my question is: why aren't HSBase_cbits.o, etc., _statically_ > linked with libgcc? Then you wouldn't have to worry at all about > this, right? I don't know how to do that! HSbase_cbits.o is linked by invoking ld directly, as: ld -r -x foo.o bar.o ... -o HSbase_cbits.o so we'd have to do something like ld -r -x foo.o bar.o ... -o HSbase_cbits.o \ -L/usr/lib/gcc-lib/... -lgcc which means knowing where libgcc.a lives (possible to figure it out, I suppose). Anyway, I just tried this and it results in an HSbase_cbits.o which *exports* __umoddi3, which inevitably leads to problems when linking. Alternatively, to avoid the portability problems, we could try gcc -o HSbase_cbits.o foo.o bar.o -Wl,-r -Wl,-x but that doesn't seem to work here (results in a 6M HSbase_cbits.o). Any ideas? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: build of GHCi 5.04.3 fails to work (libgcc.a)
> On Mon, Mar 31, 2003 at 11:43:46AM +0100, Simon Marlow wrote: > > The boxes I have access to all have __umoddi3 in libc > > That's rather odd; AIUI it really shouldn't be in libc. It's part of > how gcc implements 64 bit division, and pollutes the > namespace for other > compilers (including other gcc versions) that want to link > against libc. > A gcc compiled libc should have those routines, but they shouldn't > be exported. > > Of course, I just checked and three of the systems I have access to do > export it from libc, a redhat 7 (glibc 2.2.5), a redhat 8, > (glibc 2.2.93) > and a debian stable "woody" (also glibc 2.2.5), while two > other systems, > debian unstable "sid" (glibc 2.3.1), and a "homebrew" with glibc 2.3.2 > don't export it. I've only checked for this bug on the > debian unstable > system though, which is also using a prerelease gcc-3.2.3 > > I can try building it with gcc 2.95.4 if that would help get another > data point, but it will take a while to do. > > > libgcc, presumably). Perhaps it wouldn't do any harm to always add > > these symbols to the Linker's symbol table (on Linux, at least). > > It shouldn't, but I think the relevant test is probably "am I > compiling > with gcc on a platform that isn't 64-bit." Ok, I've done that. I'd be interested to know if GHCi on the HEAD now works for people with this problem. > If you call the linker > through gcc, I would expect it to automatically add libgcc.a when > necessary, unless told not to. I assume you have your reasons > for linking the way you do, however. Yes, the problem is our dynamic linker which can only get access to (a) symbols it knows about from objects it loaded and (b) symbols from other dynamic libraries. These libgcc symbols are statically linked, so they need to be listed explicitly in the linker's symbol table. This is kind of an ugly wart, but there doesn't seem to be an easy way around it. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Uninformative error message from getModificationTime
> If I run the program > > main = print =<< readFile "god" > > and god doesn't exist, I get the following informative error message > > Fail: does not exist > Action: openFile > Reason: No such file or directory > File: god > > However, if I run the program > > import Directory > main = print =<< getModificationTime "god" > > I get the message > > Fail: does not exist > Action: withFileStatus > Reason: No such file or directory Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: build of GHCi 5.04.3 fails to work (libgcc.a)
> Downloaded, unpacked GHC release 5.04.3, > ./configure > echo "GhcWithInterpreter=YES" > mk/build.mk > make > make install > > ghci >___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.04.3, > for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > Loading package base ... linking ... > /usr/local/lib/ghc-5.04.3/HSbase_cbits.o: unknown symbol `__umoddi3' > ghc-5.04.3: panic! (the `impossible' happened, GHC version 5.04.3): > can't load package `base' > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. > > which looks like HSbase_cbits.o isn't getting linked with libgcc.a for > some reason. Thanks. Several other people have reported the same thing. We know how to fix it - it's a case of expanding the symbol table built into the dynamic linker, but what I don't know is under what conditions we should do this (i.e. what configure tests do we need to add). I really need to get my hands on a box that displays the bug. The boxes I have access to all have __umoddi3 in libc (as well as libgcc, presumably). Perhaps it wouldn't do any harm to always add these symbols to the Linker's symbol table (on Linux, at least). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -fwarn-unused-matches
> Dear ghc-5.02.2, > > ghc -c -fwarn-unused-matches > says > Warning: Defined but not used: x > > when compiling the function > > f :: Eq a => [(a, a)] -> (a, a) -> [(a, a)] > fps (x, y) = [(z, y) | (z, x) <- ps] > > Is it a bug? No. Cheers, ghc-5.02.2 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: changing configure --prefix later?
> OK, I'm building ghc-5.04.3 freshly from source, but when running > ./configure initially, I forgot to use the --prefix= option to set the > final installation location. Now, after fourteen hours of building, > I use `make install' and discover the mistake. :-( How can I recover > the situation? As it happens, I did this myself the other day, so I know the best way to recover without 'make clean'. This should do the trick: cd ghc/driver; make clean boot; make cd ghc/utils; make clean boot; make cd libraries; make boot cd hslibs; make boot The last two steps are needed to rebuild package.conf which was killed in step 1. > I tried re-running ./configure with the intended --prefix option. > No joy. I tried deleting config.cache first, then re-running > configure, and then `make install'. In all cases, the installed > ghc driver script still points to the wrong place (/usr/local/...) > If I edit the installed driver script to point to the right location, > I get errors later in the installation that the pointed-to binary > doesn't exist. And indeed it doesn't, because the scripts are > installed *before* the binaries they point to, but the installation > process itself seems to call GHC to build something. In this case, > the error is: > > > -- > -- > ==fptools== make install -wr; > in /grp/haskell/ghc-5.04.3/ghc/compiler > > -- > -- > /export/home/malcolm/bin/ghc -ldl -cpp -fglasgow-exts > -Rghc-timing -I. -IcodeGen -InativeGen -Iparser > -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSuga > r:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen > :absCSyn:main:profiling:parser:usageSP:cprAnalysis:compMan:ndp > Flatten:nativeGen -package concurrent -package posix -package > util -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -O > -c main/Config.hs -o main/Config.o > > /export/home/malcolm/bin/ghc: > /usr/local/lib/ghc-5.04.3/ghc-5.04.3: > not found I'm not sure what's happened here. Probably Config.hs is being rebuilt because you re-configured and it picked up a dependency, but it should be using the compiler you originally built with. Perhaps the act of re-configuring has reset that to point to a compiler which doesn't exist, in which case you should configure again and specify an explicit --with-ghc option. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug with splitPS in Data.PackedString
> there's a bug in Data.PackedString that doesn't exist in PackedString:
>
> Prelude> :m PackedString
> Prelude PackedString> splitPS ('\t') (packString "Foo\tBar")
> ["Foo","Bar"]
> Prelude PackedString> :m Data.PackedString
> Prelude Data.PackedString> splitPS ('\t') (packString "Foo\tBar")
> ["Foo"*** Exception: Ix{Int}.index: Index (7) out of range ((0,6))
(catching up on some old bug reports)
This was fixed in 5.04.3, BTW.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: building 5.04.3 on sparc-solaris-2.6
> OK, rebuilding from scratch, I discovered that I should > really have defined > #define HAVE_ALTZONE 1 > #define HAVE_TIMEZONE 1 > I still wonder why configure got this setting wrong in the > first place. I don't know. The test in question is FPTOOLS_ALTZONE in aclocal.m4 - could you try the test program there by itself and see if you get the expected results? Also, does config.log say anything helpful? > Anyway, rebuilding from scratch yet again (it seems impossible to > change config.h and keep going successfully), You should be able to 'cd ghc/includes && make' to carry on after changing config.h, unless the new config.h affects anything you already built (it shouldn't in the case of the timezone defines). > This time, the culprit is our slightly aging version of 'find': with > only the -name option, it does not report any filenames; you need to > add the -print option as well. Ok, adding that shouldn't do any harm. > So the second part of the solution is > to add the following fix to hslibs/util/Makefile: > > ifneq "$(ReadlineIncludePath)" "" > SRC_HC_OPTS += -I$(ReadlineIncludePath) > + SRC_HSC2HS_OPTS += -I$(ReadlineIncludePath) > endif Fixed, thanks. > Then, discovering that the installed version of readline is too old > to support all the operations in Readline.hsc, I have to upgrade > readline and start all over again... What version of readline do you have? The configure script checks for version 4 and does the right thing (by the looks of it). > ... finally getting a complete build, after a mere four working days > of attempts. But now, in order to install it, I need to know the > properties of `make clean'. The problem is that, after building ghc > on the local disc, my Sparc machine now only has 43Mb of disc space > left, which is clearly insufficient to install it. So, if I do a > `make clean', will I be throwing away my freshly built compiler > and libraries? Or will it just clean up the intermediate files, > leaving the important stuff in place, meanwhile hopefully freeing > enough space for installation to become possible? We don't have a variant of make clean that leaves the binaries and libraries in place, unfortunately. You can go around by hand and delete objects, but bear in mind that if you then do a 'make install' it will probably try to rebuild them. I don't think there's a solution to this one without plugging in some more disk space, sorry! Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: unused import not always reported
> How is it possible that an unused import warning is not > always emitted? > > Below I get a warning when I recompile everything, but no > warning when I > only recompile the Main module (that contains the unused import). In > fact Main.hi changes. It could be a bug, but we'll need to reproduce it here to be sure. Could you send the sources please? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Symbol referencing problem in GHC HEAD.
> I recently had some trouble trying to compile a simple > Template Haskell > program > > main = putStrLn (show ($[| 20 |])) > > The following output was generated: > > /home/sseefried/local/lib/ghc-5.05/HSbase_cbits.o: unknown symbol > `__umoddi3' > Loading package base ... linking ... ghc-5.05: panic! (the > `impossible' > happened, GHC version 5.05): > can't load package `base' I've had a quick look into this, and here's what I've discovered: GCC has __umoddi3 in libgcc.a. It generates calls to that function and others for some 64-bit operations. On our RedHat box here, __umoddi3 is also exported by libc.so, which is why we don't get any link errors. Perhaps on your box it isn't? It looks like the same problem crops up on MacOS/X, because there's code in the linker to add these symbols to the symbol table, surrounded by #ifdef powerpc_TARGET_OS. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: HEAD: the `impossible' happened, MacOS X
> This is yesterdays HEAD:
>
> ../../ghc/compiler/ghc-inplace -H32m -O0 -W
> -fno-warn-unused-matches -fwarn-unused-imports -L/sw/lib
> -fglasgow-exts -cpp -Iinclude -#include HsBase.h
> -funbox-strict-fields -package-name base -dcore-lint -W
> -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files
> -c System/Random.hs -o System/Random.o -ohi System/Random.hi
>
> System/Random.hs:15:
> Warning: Module `GHC.IOBase' is imported, but nothing
> from it is used
>(except perhaps instances visible in `GHC.IOBase')
> ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
> ASSERT failed! file stgSyn/CoreToStg.lhs line 188
> randomIvalDouble1 {- v s2Im -}
Compiling the libraries without -O is not usually a good idea, but
nevertheless the compiler shouldn't crash. I'll take a look.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: building 5.04.3 on sparc-solaris-2.6
> >> I'm trying to build ghc-5.04.3 from source on a sparc-solaris-2.6
> >> machine, using 5.02.3. It throws up the following build error.
> >> Any ideas what might be going wrong?
>
> >> /tmp/ghc11170.hc: In function `SystemziTime_zdLrpHVeta_entry':
> >> /tmp/ghc11170.hc:10508: called object is not a function
>
> If it helps, here is the relevant section of the .hc file.
> Line 10508 is marked with a comment.
>
> System/Time.hc
>
> INFO_TABLE(SystemziTime_zdLrpHVeta_info,SystemziTime_zdLrpHVet
> a_entry,0,2,THUNK_STATIC,,EF_,0,0);
> FN_(SystemziTime_zdLrpHVeta_entry) {
> StgAddr _B2_;
> FB_
> HP_STK_CHK_NP(4,3,1,);
> SET_HDR_(Hp-2,(P_)&stg_CAF_BLACKHOLE_info,0,0);
> UPD_CAF(R1.p,Hp-2);
> PUSH_UPD_FRAME(Hp-2,0);
> Sp[-4]=(W_)((P_)&srBl_info);
> Sp=Sp-4;
> {
> StgAddr _ccall_result;
> CALLER_SAVE_SYSTEM
> _ccall_result = (timezone()); /* line 10508 */
> CALLER_RESTORE_SYSTEM
> _B2_=_ccall_result;
> }
> R1.a=_B2_;
> JMP_(ENTRY_CODE((P_)(*Sp)));
> FE_
> }
Hmm, looks like the Time library has got the timezone stuff wrong for
your system.
What does mk/config.h say about HAVE_ALTZONE? On a Solaris 8 box I'm
looking at it says HAVE_ALTZONE is defined.
> My guess is that timezone() is not a function on Solaris 2.6. Indeed,
> grepping through /usr/include shows that defines
> extern long timezone;
Does it also define altzone?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: floating point literals
> Simon Marlow wrote: > > > > On Mon, Mar 17, 2003 at 10:33:47AM +, Ross Paterson wrote: > > > > GHC doesn't recognize literals like 9e2, and nor does lex. > > > > > > Correction: > > > GHC doesn't recognize 9e2 > > > lex is confused by 0xy, 0oy, 9e+y and 9.0e+y > > > > Fixed GHC, I'll leave lex to someone more familiar with the code... > > > > Cheers, > > Simon > > Forgive me if I'm confused, but I thought "9e2" was supposed to be > parsed as two lexemes, "9" and "e2". This changed in the revised version of Haskell 98. I hadn't noticed, hence GHC was still parsing the old H98 syntax. The change dates back to November 2001, and is listed on Simon's Errata page, here: http://research.microsoft.com/Users/simonpj/haskell98-revised/haskell98- bugs.html Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: building 5.04.3 on sparc-solaris-2.6
> "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > > I'm trying to build ghc-5.04.3 from source on a sparc-solaris-2.6 > > > machine, using 5.02.3. It throws up the following build error. > > > Any ideas what might be going wrong? > > > > I'm not sure, and I'm afraid our one and only Sparc box has > just died, > > probably permanently :-( The 5.04.3 build *did* go through > prior to the > > box dying, though. > > I wonder if the following warnings (very early in the build) > might have anything to do with it? No, those are harmless. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: building 5.04.3 on sparc-solaris-2.6
> I'm trying to build ghc-5.04.3 from source on a sparc-solaris-2.6 > machine, using 5.02.3. It throws up the following build error. > Any ideas what might be going wrong? I'm not sure, and I'm afraid our one and only Sparc box has just died, probably permanently :-( The 5.04.3 build *did* go through prior to the box dying, though. I'm going to try and get up and running on the SourceForge compile farm, but that's Solaris 8. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: floating point literals
> On Mon, Mar 17, 2003 at 10:33:47AM +, Ross Paterson wrote: > > GHC doesn't recognize literals like 9e2, and nor does lex. > > Correction: > GHC doesn't recognize 9e2 > lex is confused by 0xy, 0oy, 9e+y and 9.0e+y Fixed GHC, I'll leave lex to someone more familiar with the code... Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: 5.04.2: hp2ps -c no longer works
> The colours in postscript generated by 5.04.2's hp2ps are > stuffed. I suspect the attached complaints are related, but > I haven't followed this up. Is this a known bug? Is there > any patch available for it? It's been reported before, and 5.04.3 (due to be released momentarily) will have the fix. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Posix.getFileStatus
> (1) I think Posix.getFileStatus should respond to a file > which isn't there with something rather more helpful than > "system error". For example, a "No such file or directory" message. With today's CVS sources: Prelude> System.Posix.getFileStatus "/tmp/foo" Loading package unix ... linking ... done. *** Exception: does not exist Action: getFileStatus Reason: No such file or directory The posix library is undergoing a rewrite, which is about 80-90% done so far. I'd appreciate any testing you can subject the new System.Posix library to, though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: profiling problems
> I have this code which compiles and runs normally, but gives > bus errors or > segfaults at run time when compiled with -prof -auto-all. ghc-5.04 > SunOS cownose.cs.indiana.edu 5.8 Generic_108528-18 sun4u > sparc SUNW,Ultra-5_10 If that's really 5.04, and not 5.04.2, you should upgrade and try again. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: "no input files"
> buzzard(150)% cat Two-part.hs > main = return () > buzzard(151)% ghc --make Two-part.hs > ghc-5.04.2: chasing modules from: Two-part.hs > Compiling Main ( Two-part.hs, ./Two-part.o ) > ghc: linking ... > buzzard(152)% ghc --make Two-part > ghc-5.04.2: no input files > Usage: For basic information, try the `--help' option. > > GHC usually has no problem when I leave off the ".hs" extension. Why > should it matter that there's a '-' in the file name? This will be fixed in 5.04.3. The compiler has to figure out which arguments refer to source files, and which are object files or libraries. Traditionally the way this is done is to recognise sources rather than objects/libraries, so that we don't have to know the full range of file types that the linker accepts. So, the rule is that anything which looks like a module name, or has a .hs or .lhs extension, or doesn't contain a dot at all is assumed to refer to a source (things without dots are assumed to be filenames without the .hs or .lhs extension). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: thread blocked indefinitely
> I'm now `GHC.Conc.forkProcess`ing only from the initial > thread, and all > seems well. Thanks for the suggestion! > > Any idea when `forkProcess` might get fixed? Don't hurry on my > account; I'm just curious. There's a comment in the code from Sigbjorn who tried to fix it and was unsuccessful, so it's probably a non-trivial fix. I'll take a look next time I'm in the area, unless it's a complete show-stopper for anyone. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: thread blocked indefinitely
> Something like the following seems to be occurring. > > The program `Concurrent.forkIO`s several threads. Two of > these auxiliary > threads each fork a process (with `GHC.Conc.forkProcess`). > Just as the > second forked process is about to `Posix.executeFile`, it > appears that the > "ghost" of the original thread (with ID 1) in that > process--which is not > supposed to exist in the new process--suffers the "thread blocked > indefinitely" exception. (Each of my threads protects itself with > `Exception.catch` and tags caught exceptions with process and > thread IDs.) > It is likely that, in the original process, the original thread was > waiting on a `readChan` at the time of the `forkProcess`. Looking at the code for forkProcess, it appears that "main threads" are not killed in the child process. Thread 1 is almost certainly a main thread, which explains why it isn't being killed. This is a deficiency in forkProcess (which I wasn't aware of, or had forgotten). It looks like the right thing to do is to make the current thread into the (one and only) main thread in the child process at fork time. In the meantime, could you perhaps fork from the main thread instead? > What I describe above happens nearly all the time. However, > one time I > observed something superficially quite different. One of the > processes (I > suspect the second forked one, as above, though since the > message comes > from the RTS it isn't tagged with a process ID) reports: > > Test: main thread exited (uncaught exception) > > and then a bit later: > > Test: fatal error: schedule: invalid what_next field > > That process then exits with `ExitFailure 254`. That looks like a bug. If you see it again, could you capture the sources and send them to us? (even if it isn't 100% repeatable). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: unexpected thread blocking
> Actually I am not sure if this is really a bug, but anyway
> the following
> program
> behaves in different manners between with and without -O.
> Interestingly, ghci provides the same (expected) behavior as -O.
>
> \begin{code}
>
> import Control.Concurrent
> import Control.Concurrent.MVar
> import IO(hPutStrLn, stderr)
>
> main = do
> mvar <-newEmptyMVar hPutStrLn stderr "forking..."
> thread <-forkIO (undef `seq` (putMVar mvar hoge))
> isEmpty <-isEmptyMVar mvar
> hPutStrLn stderr ("isEmpty = " ++ show isEmpty)
>
> undef = undef
> hoge = "hoge"
>
> \end{code}
>
> Results:
> $ ghc testConcurrent.lhs -o tto.exe
> $ tto.exe
> forking...
> isEmpt<<>>
>
> $ ghc testConcurrent.lhs -o tto.exe -O
> $ tto.exe
> forking...
> isEmpty = True
I suspect, without running the program, that you've run into a known
problem with the way GHC implements concurrency.
In GHC, context switches are triggered by memory allocation. If the
computation is doing no allocation, then it will never context switch,
which is why you get an infinite loop in your example (undef is a
recursive function which never allocates). When -O is turned on, the
compiler probably spots that undef is equal to _|_ and uses that fact to
eliminate undef.
The workaround is simple: use Prelude.undefined or Prelude.error instead
of undef.
We should really fix this problem, but it's never been a high priority
because it happens so rarely and the workaround is usually easy.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: biographical profiling bug
> In a fairly recent CVS (I don't have 5.04* easily available > to check it): > > igloo@userpc15:bug$ ghc --make Foo -o Foo -prof -auto-all -O > Chasing modules from: Foo > Compiling Inflate ( Inflate.lhs, ./Inflate.o ) > Compiling Main ( Foo.lhs, ./Foo.o ) > Linking ... > igloo@userpc15:bug$ ./Foo +RTS -hb > Foo: internal error: Invalid object in > processHeapClosureForDead(): 17260 > Please report this as a bug to [EMAIL PROTECTED], > or http://www.sourceforge.net/projects/ghc/ > igloo@userpc15:bug$ Found and fixed, thanks for the report. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Build error
> > Could you try with EXTRA_HC_OPTS=-v, and send us the > output? Thanks. > > > > Also, what compiler are you building GHC with? Installed > from where? > The compiler was ghc 5.04.1, installed from the rpm on > haskell.org; I've updated to 5.04.2 (same source): no change. > In the example below, I'm using gcc 3.2.1, but the problem > occurs with the Redhat supplied 2.96 (?) as well, and I've > successfully built on another machine with 3.2.1 so I think > that's irrelevant. > The output with EXTRA_HC_OPTS=-v is: [ snipped -v output, which shows that GHC executed gcc which just failed with no error message ] > Again, the generated gcc command succeeds by itself. Next thing to try: strace on that ghc command-line. I now have a vague recollection of what the problem might be. Aha! Found it. See this message, and the followup: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2002-September/002 694.html You did install the RedHat 7.2 RPM, and not the 7.3/8.0 RPM, right? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bizarre Haskell Problem
> I am having a bizarre Haskell problem that I am having difficulty > debugging. I am not positive this is a compiler problem, but > my results > are not making any sense. > > I have attached a few source files which compiled with ghc-5.04.2 > running under Win95. The files were compiled as: > > ghc -c DFT.lhs > ghc -c FFT1.lhs > ghc -c FFT2.lhs > ghc -c Main1.hs > ghc -c Mail2.hs > ghc -o test1 Main1.o FFT1.o DFT.o > ghc -o test2 Main2.o FFT2.o DFT.o > > Running test1 gives the following results (the last line is wrong): > > foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] > rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] > foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] > rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,1,4,8,18,22,6,19,2] > > Running test2 gives the following results (these are the results I > expect): > > foo 19:[1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] > rader1 19: [1,2,4,8,16,13,7,14,9,18,17,15,11,3,6,12,5,10] > foo 23:[1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] > rader1 23: [1,5,2,10,4,20,8,17,16,11,9,22,18,21,13,19,3,15,6,7,12,14] Your problem is that rader1 has different types in FFT1 and FFT2: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. :Prelude> :l FFT1 Skipping DFT ( DFT.lhs, DFT.o ) Skipping FFT1 ( FFT1.lhs, ./FFT1.o ) Ok, modules loaded: FFT1, DFT. Prelude FFT1> :t rader1 forall a b. (Integral a, GHC.Arr.Ix a, Num (Data.Complex.Complex b), RealFloat b) => GHC.Arr.Array a (Data.Complex.Complex b) -> a -> [a] Prelude FFT1> :t rader1 (gendata 23) 23 [Int] Prelude FFT1> :l FFT2 Skipping DFT ( DFT.lhs, DFT.o ) Skipping FFT2 ( FFT2.lhs, ./FFT2.o ) Ok, modules loaded: FFT2, DFT. Prelude FFT2> :t rader1 forall a t. (Integral a, GHC.Arr.Ix a) => t -> a -> [a] Prelude FFT2> :t rader1 (gendata 23) 23 forall a. (Integral a, GHC.Arr.Ix a) => [a] So in FFT2, defaulting will force the type variable a to Integer, whereas in FFT1 the type has already been forced to Int. I imagine that with Int you're getting some overflow, leading to the incorrect results. Moral of this story: type signatures can help to avoid unexpected behaviour... Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug with -O -ffi and multiple module
> Okay, here's a weird one. There's something wrong with the > ffi when using > -O and the foreign imports are from another module. For example, our > foreign module, foo.c contains functions: > >void* openFile(char*fn); >void closeFile(void*f); >float readFloat(void*f); > > which are interfaced from foo.h. We have a FooIntr.hs interface file, > which looks like: > >foreign import ccall "foo.h openFile" c__openFile :: Ptr > CChar -> IO >(Ptr ()) >foreign import ccall "foo.h closeFile" c__closeFile :: Ptr > () -> IO () >foreign import ccall "foo.h readFloat" c__readFloat :: Ptr () -> IO >CFloat I think what you're seeing here is an instance of this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=655400&group_id =8032&atid=108032 Workaround: use -#include instead of including the header file in the FFI spec. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: evaluation fault in ghci.
> The interactive loop of ghci displays an interesting evaluation fault > to do with derived equality. In the attached source file, there is > a simple guard which tests some equalities, and basically the same > value is given on the left and right of the (==). Yet, it evaluates > to False in interactive mode, whereas it (correctly) evaluates to True > when compiled. > > > $ ghci >___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.04.2, > for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Prelude> :l Small > Compiling Main ( Small.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > "*** Exception: Four.bceFour: precondition fails:arrows not parallel > f = E > g = E Nice bug. We've fixed it in CVS, but I fear the changes are too large to backport. The workaround is to define your own instance of Eq. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: foreign import label with polymorphic type
> GHC (5.04 and CVS) rejects the following, saying "Unacceptable type": > > foreign import ccall unsafe "stdlib.h &free" pFree :: FunPtr > (Ptr a -> IO ()) Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc 5.04.2 and seg fault
> I have a bug which I'm having trouble reproducing on a small scale, so > I'm not sure how to proceed to get more information to you. > > When I use ghc --make to recompile a group of files, I sometimes get a > segfault when running the target program. If I remove all of the .o > files and compile again, I do not get the segfault. If I remove just > the changed .o files and the executable and recompile, I still get the > segfault. > > I'm not using any unsafe IO as far as I know, though I am using Happy > and Alex. > > I searched around for a while about methods for debugging ghc, but > didn't find much. It doesn't look like its a gc bug since I tried > giving a big heap size and had no effect. Can I rebuild ghc or my > target program in some way to get more debugging information to you? > Unfortunately, I can't post my entire program. Could be a problem with the recompilation checking. We know of one such bug: if you compile first with -O, then later without -O, inconsistencies can arise. If your problem is not of this form, then it would help greatly if you could provide us with a repeatable example (indeed, it will probably be impossible to track down without one). The next time it happens, just tar up the tree and send it to us, and if you can provide a description of which changes were made recently to the tree that would help too. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Compile problems
> I'm still trying to compile ghc, but it's getting worse: > > Running make results in the following error message: Do you have GHC installed? It looks like you either don't have GHC, or configure didn't detect it. Could you send the output of ./configure at the top of the tree? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug report
> I am reporting a bug in the GHCi Haskell interpreter as requested by > the program itself. GHC is 5.04.2 running on SunOS 5.8. > > The interpreter encountered a panic condition when trying to load a > parser produced by Happy the parser generator. Yes, this is a known bug in 5.04.2 (although I don't think it was reported on the lists, so you can be forgiven for not having seen it!). The workaround is to avoid using the 'a' and 'g' flags to Happy, or to compile the parser using GHC before loading it into GHCi. The bug was fixed in the HEAD, but was deemed to difficult to fix in the 5.04.x branch too. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Small bug in Data.PackedString.splitWithPS
> In GHC 5.04.2 this fails: wordsPS (packString "a") > > Cause: typical off-by-one error in libraries/base/Data/PackedString.hs > line 289 > > first_pos_that_satisfies pred ps len n = >case [ m | m <- [n..len], pred (ps ! m) ] of > ^ > here > > Probably should be: >case [ m | m <- [n..len-1], pred (ps ! m) ] of Thanks; fixed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Error messages when mixing profiled and unprofiled code
> I just went through an interesting (== painful) remote debugging > session with one of my clients which could be avoided by improving > an error message. > > If you compile a program for profiling but don't have profiling > versions of the standard libraries, then the linker generates reports > like: > > ghc-5.04.1: can't find module `List' (while processing > "./../Flattener.hs") > > This is utterly baffling since: > > 1) It is unthinkable that a standard GHC installation would > lack 'List' > 2) The code compiles fine on other machines (which I later realised >had the profiling libs installed). > > A much better error message would be: > > ghc-5.04.1: can't find profiling version of module `List' > (while ...) > It wasn't convenient to do exactly what you wanted here, but we agree there's a problem. So I added the option to print out all the filenames that the compiler was searching for in the event that it can't find an interface file or source file. To get this information you just add the -v option (the error message mentions this if you don't add -v). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug
> > it only happens when i try to compile with profiling enabled. > > Profiling (-prof) is incompatible with the native code generator > (-fasm). Leave out -fasm if you want profiling. (Compiling will be > slower without -fasm) > > It is only a tiny bug: GHC should complain about incompatible options > instead of panicking. Fixed: GHC will now switch to -fvia-C mode for profiling and other non-vanilla ways. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: BCO entry code - parameter passing on RISC
> After a day of running gdb in parallel on my MacOS X and Linux [quite > annoying because of different keyboard layouts ;-) ], I've > come to the following conclusion: > > The entry code for BCOs expects all parameters to be on the > stack, but > on non-x86 machines, the stg_ap_*_ret pass parameters to it in > registers (as for function objects). This leads to frequent > crashes in GHCi on PowerPC, but not on Intel. Ach! Good point. I haven't tested the newest GHC on our Sparc yet, which is why I hadn't noticed this. > My first attempt at fixing this (by making stg_BCO_entry push the > parameters onto the stack) is attached below, but I'm not > committing it > as I'm not sure it's the right way to do it. Are the stg_ap_*_ret > functions the only places where a BCO is entered? It might be a nicer > solution to modify GenApply to pass parameters to BCOs on the stack. It's not quite right, because there might be other regs in use apart from the vanilla regs. I think that stg_BCO_entry can only be entered via the stg_ap_*_ret functions, but we shouldn't rely on this. The annoying thing is that the code for PAPs is *almost* right (i.e. in each stg_ap_*_ret, just move the apply_fun label to the PAP case instead), but it ends up jumping to stg_PAP_entry instead of stg_BCO_entry. So I've merged these two cases by storing the jump target in a variable instead. Try the new version and let me know if it fixes the problem. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci and unboxed types
> ralf/tmp> ghci -fglasgow-exts Arr.lhs >___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.04, for > Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Compiling Arr ( Arr.lhs, interpreted ) > ghc-5.04: panic! (the `impossible' happened, GHC version 5.04): > ByteCodeGen.schemeE P_ > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. Thanks. This bug is now fixed in CVS. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Strict Word64 Compiler Panic
> Let Crash.hs be:
>
> module Crash where
> import Data.Word (Word64)
> data S = S { a :: ! Word64 }
> s :: S
> s = S { a = 0 }
>
> Then:
>
> (mbs@emae) ghci-5.04 -fglasgow-exts
>___ ___ _
> / _ \ /\ /\/ __(_)
> / /_\// /_/ / / | | GHC Interactive, version 5.04, for
> Haskell 98.
> / /_\\/ __ / /___| | http://www.haskell.org/ghc/
> \/\/ /_/\/|_| Type :? for help.
>
> Loading package base ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Prelude> :l Crash
> Compiling Crash( Crash.hs, interpreted )
> ghc-5.04: panic! (the `impossible' happened, GHC version 5.04):
> ByteCodeGen.mkUnpackCode LW_
Thanks for the report. This is now fixed in CVS, but the fixes are too
difficult to unpick from other changes in GHCi so we probably won't
back-port the fix to the 5.04 branch.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bug#171518: ghc --make does not play nice with FFI wrapper
> Package: ghc5 > Version: 5.04-1 > Severity: normal > > I have a module SDL.Bare.Audio with this declaration: > > foreign import ccall safe "wrapper" > mkSDL_AudioSpec_Callback :: SDL_AudioSpec_Callback u -> > IO (FunPtr (SDL_AudioSpec_Callback u)) > > When compiling Audio.hs, this results in the creation and compilation > of Audio_stub.c. > > Unfortunately, if I'm using ghc --make, if it decides to skip > compilation > of Audio.hs, it never realizes that it also needs to link in > Audio_stub.o, > causing this failure at the end: > > ghc: linking ... > build/Audio.o(.text+0x89): In function `s3Fk_ret': > : undefined reference to `SDLziBareziAudio_d3K2' > collect2: ld returned 1 exit status Thanks, this is indeed a bug. The code to look for the stub file exists, but it was looking for foo.stub_o rather than foo_stub.o (d'oh!). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: RULES/SPECIALIZE not parsing:
> Rules.hs:
>
> module Rules where
>
> my_id :: a -> a
> my_id a = a
>
> my_int_id :: Int -> Int
> my_int_id a = a
>
> {-# RULES my_id = my_int_id #-}
Each rule should begin with a string, like:
{-# RULES "my_id" my_id = my_int_id #-}
> {-# SPECIALIZE my_id :: Int -> Int = my_int_id #-}
These kind of specialise pragmas aren't supported any more, because the
same effect can be achieved using RULES (it looks like that's what you
were trying to do).
The docs have some bogusness, which I'll fix.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: build of ghc-5.05.20021118 fails
> From time to time I try out one of the development snapshots. > Does it make sense to report errors? Anyway, the the build of > ghc-5.05.20021118 fails with the following error message ... > > -- > -- > ==fptools== make html - --no-print-directory -r; > in > /var/tmp/portage/ghc-5.05.20021118/work/stage3-build/ghc/docs/ users_guide > -- > -- > ../../../glafp-utils/docbook/db2html -d > /var/tmp/portage/ghc-5.05.20021118/work/stage3-build/docs/fpto > ols-both.dsl users_guide.sgml > CATALOG file not set up; see installation guide for details. > make[3]: *** [users_guide.html] Fehler 1 > make[2]: *** [html] Fehler 1 > make[1]: *** [html] Fehler 1 > make: *** [html] Fehler 1 Hmm, I thought the docs weren't built by default. Did you ask for the docs to be built by setting anything in your build.mk file? The error means that the configure script couldn't detect the right way to process DocBook documents on your system. Since you're on Gentoo (right?) I can tell you that the Gentoo DocBook setup works perfectly: just 'emerge docbook-sgml', and re-configure your GHC build (remove config.cache first) and you should be able to build the HTML docs. To build the printed documentation you'll need to install more stuff (TeX & JadeTeX at least). Oh, and BTW you can do a 3-stage build in a single tree these days. Just 'make bootstrap3' from the top level. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Running make
> "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > > You also need libreadline.so, which here is just a link to > > libreadline.so.4.2. The "right" way to get this, if you're on an > > RPM-based Linux system, is to install the appropriate readline-devel > > RPM. > > Thanks, it worked, but now a longer error occured, which > confuses me much more: > > -- > -- > ==fptools== make boot - --no-print-directory -r; > in /root/ghc-5.04.1/ghc/utils/ghc-pkg > -- > -- > /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-ldl -cpp > -DPKG_TOOL -DWANT > _PRETTY -package lang -package util -package text -O Main.hs > Package.hs ParsePkg > ConfLite.hs > make all > /usr/bin/ghc -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package > util -pac > kage text -O-c Package.hs -o Package.o > /usr/bin/ghc -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package > util -pac > kage text -O-c ParsePkgConfLite.hs -o ParsePkgConfLite.o > > ParsePkgConfLite.hs:300: Warning: Pattern match(es) are overlapped > In a case alternative ITocurly: _ -> ... > /usr/bin/ghc -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package > util -package text -O-c Main.hs -o Main.o > /usr/bin/ghc -o ghc-pkg.bin -ldl -cpp -DPKG_TOOL -DWANT_PRETTY > -package lang -package util -package text -O Main.o > Package.o ParsePkgConfLite.o > /usr/lib/ghc-5.04.1/libHSrts.a(Storage.o): In function `initStorage': > Storage.o(.text+0x4cb): undefined reference to > `__gmp_set_memory_functions' > /usr/lib/ghc-5.04.1/libHSrts.a(PrimOps.o): In function > `plusIntegerzh_fast': > PrimOps.o(.text+0x586): undefined reference to `__gmpz_init' > PrimOps.o(.text+0x59c): undefined reference to `__gmpz_add' [ etc. ] Did you also upgrade libgmp at the same time? It looks like the version of libgmp on your system doesn't match the one that GHC was built with. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Running make
> While running make, following error occurred: > > -- > -- > ==fptools== make boot - --no-print-directory -r; > in /home/sonja/uni/work/e8/ghc-5.04.1Mod/ghc/utils/ghc-pkg > -- > -- > > /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-ldl -cpp > -DPKG_TOOL -DWANT_PRETTY -package lang -package util -package text -O > Main.hs Package.hs ParsePkgConfLite.hs > make all > /usr/bin/ghc -o ghc-pkg.bin -ldl -cpp -DPKG_TOOL -DWANT_PRETTY > -package lang -package util -package text -O Main.o Package.o > ParsePkgConfLite.o > /usr/bin/ld: cannot find -lreadline > collect2: ld returned 1 exit status > make[4]: *** [ghc-pkg.bin] Error 1 > make[3]: *** [boot] Error 2 > make[2]: *** [boot] Error 1 > make[1]: *** [boot] Error 1 > make[1]: Leaving directory `/home/sonja/uni/work/e8/ghc-5.04.1Mod/ghc' > make: *** [all] Error 1 > > libreadline.so.4.3 is installed, a link libreadline.so.3 to > libreadline.so.4.3 exists... You also need libreadline.so, which here is just a link to libreadline.so.4.2. The "right" way to get this, if you're on an RPM-based Linux system, is to install the appropriate readline-devel RPM. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Can't load package 'util'
> Typing 'ghci -package util' caused an error. > Error message: ... panic!(...)can't load package 'util' What version of the readline library do you have installed? I suspect you need version 4.2 (that's what is installed on the machine used to build the binaries). Could you do 'rpm -qa | grep readline' and 'ls -l /usr/lib/*readline*' and send us the output? Thanks. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: additional to earlier mail Can't load package util
> I forgot to say which version und operating system: > ghc 5.04.1 linux Suse Could you please post the full error report? Preferably also add the -v flag to ghci. I have seen a problem with loading package util before, and I think it was also on a SuSE system. Anyone else on SuSE get an error for 'ghci -package util'? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: interrupted system calls
> Does anyone know what might be causing the following error from a > program that uses System.system? > > Fail: interrupted > Action: system > Reason: Interrupted system call > > The shell command given to System.system runs and terminates with a > non-zero exit code (actually 8). I expected to bind the exit result > of the shell command and display it, but I did not expect the entire > program to terminate instead. > > Unfortunately, small examples do not seem to trigger the problem. > The application in which I noticed the problem is 'hi', the Haskell > pseudo-interpreter. To demonstrate the behaviour, download and > build hmake-3.06 (http://www.haskell.org/hmake) with any ghc from > 4.08.2 to 5.04.1. (I can't test 4.06 or earlier.) There is no need > to install anything: just type script/hi, then at the prompt enter > any Haskell expression that throws a runtime error, such as 4`mod`0. > The running "interpreter" is exited, whereas I expected the > interpreter > to continue (and on some platforms it does!) > > The fault is observed on Linux, but curiously not on Solaris, so maybe > it is environment-related? hi doesn't work for me, the error is attached at the end of this message. I'm confused by the bug report, because our implementation of System.system has extra code to disable the timer interrupts before invoking the sub-process, so while Alastair's fix may have been required at some time in the past, I don't think it should be any more. Maybe it's related to the choice of expression: 4 `mod` 0 will cause a divide-by-zero crash (a SIGFPE) with current versions of GHC, but in 5.04.2 it will generate an exception as it should. Do you get the same behaviour just calling 'error'? Cheers, Simon ~/tmp/hmake-3.06 > ./script/hi __ __ __ _ || || _____ || _ hmake interactive (hi): ||___|| || || || ___|| ||/ ||__|| Copyright (c) May 2000 ||---|| || || || ||__|| ||\_ ||__ http://www.cs.york.ac.uk/fp/hmake/ || ||Report bugs to: [EMAIL PROTECTED] || || Version: 3.06 (2002-08-09) - ... Using compiler ghc ... Type :? for help [Std module... /home/simonmar/fp/lib/i386-unknown-linux/ghc-5.04.1/imports/base/Prelude .hi] Prelude> 1 `mod` 0 [Compiling... Fail: Can't find module PrelGHC in user directories . . Or in installed libraries/packages at /home/simonmar/fp/lib/i386-unknown-linux/ghc-5.04.1/imports/base /home/simonmar/fp/lib/i386-unknown-linux/ghc-5.04.1/imports/haskell98 Asked for by: /tmp/Main22523.hs Fix using the -I, -P, or -package flags. Stop - hmake dependency error. ...failed] Prelude> > ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: glibc 2.3.1
> some days ago I upgraded the GNU libc6 (also called glibc2) C library > to version 2.3.1. It's only now that I notice that this wasn't a very > good idea as it breaks GHC (version 5.04.1). > > basilisk Software/Haskell > ghc --make Hello.hs > ghc-5.04.1: chasing modules from: Hello.hs > Compiling Main ( Hello.hs, ./Hello.o ) > ghc: linking ... > /usr/lib/ghc-5.04.1/libHSrts.a(RtsFlags.o)(.text+0xcf): In > function `splitRtsFlags': > : undefined reference to `__ctype_b' > /usr/lib/ghc-5.04.1/libHSrts.a(RtsFlags.o)(.text+0xfb): In > function `splitRtsFlags': > : undefined reference to `__ctype_b' > /usr/lib/ghc-5.04.1/libHSrts.a(RtsFlags.o)(.text+0x114): In > function `splitRtsFlags': > : undefined reference to `__ctype_b' > collect2: ld returned 1 exit status > > I guess that the GNU library is broken, so this is not exactly a GHC > bug report but more a word of warning. Upgrading libc isn't safe in general, without recompiling everything that depends on it. In this case it looks like libHSrts.a has captured some inline code from the old header files, which refers to things which don't exist in the new libc. Even if you still have the old libc installed, it still doesn't work because -lc tends to pick the latest version. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: mod 0 results in core dump
> Prelude> 4 `mod` 0 > Floating exception (core dumped) > > 'nuf said. ghc 5.04.1, solaris. It now raises an exception, and the fix is scheduled to be merged into 5.04.2. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GetMBlock
> Hello, > I am getting the the folowing error message with ghc-5.04 > > meegpar: fatal error: GetMBlock: misaligned block 0x401d1000 > returned when allocating 1 megablock(s) at 0x5080 > > I saw on the mailing list that the problem exists since long time. > I would think that trying different addresses if the initial one does > not succeed would not be a bad idea and not too difficult to do. > I would implement it myself if I could find a way to compile the ghc. > I am attaching the different memory maps as produced by cat > /proc/PID/maps. It's actually slightly more complicated than just trying different addresses, because there's a corresponding predicate which discriminates between heap addresses and static data. Fortunately, however, I've now fixed the bug and the fix will be in the upcoming 5.04.2. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Object Splitting and the Base Package Makefile
> In a related issue, it seems that in ghc-5.04 libraries *_hsc.o files > are left out when linking with SplitObjs=YES. Yes. Actually it's better to not use #def in .hsc files at all, so that the *_hsc.o files are empty, and rather put auxiliary definitions in the appropriate header files. I've fixed Socket.hsc to do just this. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: System.Cmd.system tries to execve("n/sh", ...)
> I find it hard to see how a bug like this could get into a GHC > release, since it appears to break the build. But, I don't know of > anything wrong with the platform I'm running it on, and in general my > setup looks okay (rpm --verify, etc). So, does anyone reproduce this? > > I'm running GHC 5.04-1 installed from RPM on a RedHat 7.2 x86 box. This turns out to be an incompatibility between RedHat 7.2 and 7.3. If you previously installed the 7.3 RPMs, then you might have more luck with the 7.2 RPMs which are now available from the GHC download page. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHCi 5.04.1] the `impossible' happened
> [Indented text is me; unindented text is GHCi] > > Initial experience with the bug: > > *Autoexi> let x e = do putStrLn "hmm..."; return 'c' > *Autoexi> y <- catch (getChar) (x) > > here, I hit ^C several times, hoping to catch that as an exception. > This didn't seem to happen, and GHCi appeared to still be waiting > for a key, so I pressed 'h' > > hInterrupted. > *Autoexi> y > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule y > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. > > With a fresh GHCi: > > Prelude> let x e = return 'c' > Prelude> y <- catch (getChar) (x) > > GHCi responded immediately to my first ^C, here. > > Interrupted. > Prelude> y > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule y There are two issues here: - the 'rdrNameModule' crash has been reported before, and the fix will be in 5.04.2 - the reason that ^C is not responded to immediately appears to be due to a bad interaction with readline. The readline library puts the input descriptor into blocking mode if it finds it in non-blocking mode, whereas GHC's IO library expects it to be in non-blocking mode all the time. We might be able to work around this by placing stdin back into non-blocking mode after each call to readline... I'll look into it. Cheers, Simon > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. > > > Prelude> y <- catch (getChar) (x) > > This time I hit ^C several times, but only got a response when I > pressed a key. > > iInterrupted. > Prelude> y > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule y > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. > > > _ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > ___ > Glasgow-haskell-bugs mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug/feature/? of ghci with concurrency
> Maybe this is by design, but in case it isn't: I was a little > suprprised when I came across this behavior of ghci: > >ghci >... GHC Interactive, version 5.04.1, for Haskell 98. ... > >Prelude> :m Concurrent >Prelude Concurrent> let loop c = putChar c >> loop c >in forkIO (loop 'a') >> (loop 'z') > > zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza > zazazazazazaza > > zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza > zazazazazazaza > > zazazazazazazazazazazazazazazazazazazazazazazazazazazazazazaza > zazazazazazaza >Interrupted. >aPrelude Concurrent> sum [1..100] >a5050 >aPrelude Concurrent> 1+2 >3 This is really a design choice: there is no inter-thread structure other than what you program yourself, there are no "process groups", and pressing ^C sends an exception to the main thread only. We don't currently have a way for a Haskell program to get access to *all* the current threads running, so there's no easy way for GHCi to stop extraneous threads when ^C is received. It's really a bug that the other threads are suspended when the prompt appears (but it might also be called a feature: terminating GHCi after your example might be difficult otherwise!). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: typo in unboxed types section + feature request
> > There shouldn't be any difference, as far as I can tell. > The two types > > have the same representation. But strange things do happen. If you > > have an example where it makes a difference, we can take a look. > > If I can manage to get a small example, I'll let you know > (adds this to > his list of things to get small examples of). > > Also, I'm curious about something. You obviously can't do: > > 5.0# < 6.0# > > because they aren't instances of Ord (they can't be, as the > have the wrong kind). But you can do 5.0# `ltFloat#` 6.0# (where ltFloat# :: Float# -> Float# -> Bool) > Yet somehow: > > data Log = Log Float# deriving (Eq, Ord) I believe the deriving mechanism knows how to do comparisons for the various primitive types. You can check that the code being generated looks reasonable by dumping out the intermediate code (-ddump-simpl is a good choice). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: typo in unboxed types section + feature request
> > You can use the FFI for all these operations, just import the C > > versions. You can even use unboxed types if you really > want (mostly it > > shouldn't be necessary, though). > > Ah, yes, that works too :). I only suggested it because all the other > Float# functions seem to be exactly what is found in the > RealFloat class and these were "missing"...foreign works too, though. I think it's just this way due to hysterical raisins. There are few reasons to make something into a primitive instead of a foreign call; the main one is that you get constant folding. Another reason is if it can be implemented inline by both the C code generator and the native code generator. Neither of these seem particularly important for asinhDouble# and friends, but there are existing primops you could make the same argument for. > Out of curiousity, why would I get better performance when using: > > data Log = Log Float# > > instead of > > newtype Log = Log Float > > ? GHC should be removing the newtype constructor anyway, so I don't > understand the difference. There shouldn't be any difference, as far as I can tell. The two types have the same representation. But strange things do happen. If you have an example where it makes a difference, we can take a look. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: typo in unboxed types section + feature request
> First off, in section 7.2.7 "Primitive-Double and Float
> operations" there's a typo. It says "minux" instead of "minux" on the
> line reading: "{plus,minux,times,divide}Float# :: ...".
>
> For the feature request, could we get the rest of the trig functions,
> namely:
>
> asinhFloat#, acoshFloat#, atanhFloat# and the Double# versions
>
> as well as the corresponding function to the
>
> isInfinite :: (RealFloat a) => a -> Bool
>
> function on Float# and Double#? I suggest the following names:
>
> isInfiniteFloat#, isInfiniteDouble#
>
> :)
You can use the FFI for all these operations, just import the C
versions. You can even use unboxed types if you really want (mostly it
shouldn't be necessary, though).
For isInfinite, just use:
foreign import ccall unsafe "isDoubleInfinite"
isDoubleInfinite# :: Double# -> Int#
and similarly for Float#.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Newbie building GHC
> May I suggest the GHC downloads page drops the claim > that the 5.04.1 RPMs will work under RH7.2? Ok, will do. Thanks for looking into this one. Does anyone have a set of RedHat 7.2 RPMs we can make available? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: dead link
> On http://www.haskell.org/ghc/ > > the link to the Users' Guide is missing. Thanks, fixed. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: uh oh, another bug report :) (it and big computations)
> *Foo> it > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule it Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Haskell 98
> Out of curiousity, it's a bit strange that
>
> > data D = D !Int
> > myD = D {}
>
> in invalid, but
>
> > newtype N = N !Int
> > myN = N {}
>
> is not.
The second example is also invalid: the newtype declaration is
disallowed by the grammar. (incedentally, it looks like this example
triggers a bug in nhc98).
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Main Thread Evacuated
> I've found a bug in the scheduler: > > When a main thread finishes (e.g. returning from a ffi callback), the > GC might be run before it is removed from the main_threads list. If a > major collection happens, the thread will be garbage > collected and the > GC barfs when it updates the pointers in the main_threads list. > This scenario is quite unlikely during normal operation, but when > heap-profiling a HOpenGL program it leads to certain death > after a few > seconds. > I don't know how to fix it in a clean way (I have no idea how my > changes would affect the threaded rts or the other "ways") --- so can > someone else please fix this? Hmm, yes that looks like a bug. I've put together a patch (enclosed), could you tell me if it helps? Cheers, Simon patch Description: Binary data
RE: Generating docs
> BTW, why did you separate Haddock from GHC? I love these vicious > circles: to build GHC with docs you need Haddock, to build Haddock > you need GHC ... You can either use an installed Haddock, or use Haddock from the same tree (./configure --enable-src-tree-haddock). It's not really a cyclic dependency: Haddock isn't required to build GHC itself, so you can build GHC, use it to build Haddock, and then build GHC's docs. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Generating docs
> What is the approved way of generating and installing docs? > I tried (from source) > > ./configure ... > make all > make install > make html > make dvi > make ps > make install-docs > > The latter command fails with (as usual with a bit of German :-) Do you have Haddock installed? Did the configure script detect it? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -xc and stack overflow
> I'm suffering stack overflow in a program that uses both multiple > processes and multiple threads. Can anyone help me interpret the > following -xc output? In particular, which "<...>" reports relate to > the stack overflow? (I've added a newline following each '>' to > increase readability.) I think most (if not all) of the reports > preceding the "stack overflow" line reflect EOF exceptions that are > expected. > > Also, how can I tell which thread in which process is suffering the > stack overflow? The -xc hack was never really designed to do this. However, you could improve matters by modifying the code (PrimOps.hc:359 in the 5.04.1 sources), to include the process pid and perhaps the thread ID (CurrentTSO->id). If you're using Volker Stolz's labelled threads, then you could print out the thread label too. I think perhaps at least we ought to print a newline after the cost centre stack :) Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bus Error when profiled
> I compiled a program with "ghc --make -prof -auto-all -H100M > -fglasgow-exts -i.. -iHUnit -package data -package util -package posix > -syslib concurrent ...". When I run it, it evokes a "Bus > Error" (with or > without "+RTS -p"). Any ideas what's wrong? > > I'm using GHC 5.02.3 on Sparc/Solaris. Try upgrading to 5.04.1. I fixed a problem that could cause this with profiling on Sparc. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc --make
> We are having a problem with ghc --make. We have a standard > set of libraries > that we build and install in a shared area and then use with > ghc --make. The > problem is that ghc then (sometimes) tries to rebuild the > libraries: something > that is doomed to fail for a variety of reasons. > > (We think that it might be prone to do this if it doesn't > have write permission > for the library .hi and .o files.) > > Why would ghc do this? Nothing has changed in the libraries > obviously, and the > libraries are quite self-contained, not referring back to > anything else that has changed. This isn't supposed to happen. However, finding a test case might be a different matter. Can you give us any more clues? If it decides to recompile a library module, does it do that repeatedly? Can you send us the output from 'ghc --make -v4 -ddump-rn-trace' when it happens. What version of GHC is this, BTW? > We don't build the libraries with ghc --make, itself but use > a makefile. > > Would it be possible/sensible to provide a means of telling > ghc --make not to > try and rebuild any modules in a given directory? The mechanism we have for doing this is packages. GHC will never try to recompile anything in another package. To work around you problem you could make a package out of the library (this is recommended anyhow), but we'd still like to track down the recompilation problem. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Division by 0 exits ghci
> George Russell <[EMAIL PROTECTED]> wrote, > > > In fact the problem is more drastic than I mentioned in my > last message; division by 0 > > doesn't seem to be catchable at all. From this program > > --- cut here --- > > import Exception > > > > main = > >do > > excep <- Exception.try (seq (1 `div` 0) (return ())) > > putStrLn "Survived" > > --- cut here -- > > I get the output "Arithmetic Exception" on Solaris and > "Floating point exception" on Linux, > > while I think I ought to get "Survived". > > AFAIK, this is a known bug. Maybe you should enter it into > the bug tracker, so that it remains known ;-) Thanks for the reminder... i've now fixed division by zero to raise the proper exception. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Posix.executeFile having problems with unevaluated argumnets
> Sorry, I haven't got time to narrow this down to a test case, > but here are what I hope are the key factors: > > (1) We start up applications in a child process (forked with > Posix.forkProcess) > by calling Posix.executeFile, wrapped in an Exception.catch > handler (to detect errors). > (2) Both the third (arguments) and fourth argument > (environment) of Posix.executeFile > are non-empty. The environment at least requires some > computation, being obtained > by prepending another setting to the result of Posix.getEnvironment. > (3) The second argument of Posix.executeFile is True. > (4) The executable of the whole compiled Haskell program is > pretty big (13.6MB). > This may be relevant because the problem I am about to > describe developed quite > suddenly yesterday afternoon, after I'd made some small > changes to completely unrelated > areas of the program, and the only explanation I can > think of is that in some way > the slightly increased size of the executable triggered > the problem. > > What happens is that the arguments and environment are > somehow garbled. This is surprising, > but I have good evidence for it, obtained by putting a small > proxy binary between > Haskell and the environment. I suspect this is due to a bug in executeFile in the posix library. Currently, executeFile uses CString.vectorize to make a C array of the arguments. CString.vectorize is totally bogus, and will result in garbage if a GC happens in the middle of marshalling - hence it only happens for you when the arguments are unevaluated. Try the enclosed version of executeFile instead, it should solve the problem. Cheers, Simon execfile.hs Description: execfile.hs
RE: ghc5.04.1 deriving Read/Show broken
> Luckily, there is a workaround (discovered by Tom Moertel on
> #haskell). If you include field names in the data
> definition for which you derive Show and Read, it seems to
> work fine.
>
> So, in George's example
>
> module GHCBug where
>
> data Command =
> NewLocation
> | Commit {a :: Int, b :: String, c :: (Maybe String)}
> | Retrieve String String
> | ListVersions String
> deriving (Read,Show)
>
> should be all that is needed.
>
> It seems that as soon as the value of the Maybe type is
> delimited by a punctuation symbol or bracket, all is fine.
Thanks. I've added a note to the download page for 5.04.1 about this
bug.
Given that there's a workaround, we won't do 5.04.2 immediately but
we'll certainly move along to 5.04.2 quicker than we would have
otherwise.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GetMBlock: misaligned block
> "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > The problem is that GHC is asking for memory at a particular address > > (0x5000) and the kernel is returning memory elsewhere > that doesn't > > satisfy our aligment constraints (1M aligned). We don't > particularly > > care where we get memory from, but it must be properly aligned. > > Can you just mmap more memory than you need (an extra megabyte) and > unmap the portions that aren't correctly aligned? (To avoid the > overhead, you could do this only when a correctly-sized mmap gave you > unaligned memory.) Yes, we should do something like that. I still need a test case though... Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bug in ghc-pkg on SunOS
> I am using ghc-pkg on SunOS4 and get the following behavior
> when using 'ghc-pkg -g':
>
> >>>
> ld: illegal option -- x
> ld: illegal option -- -
> ld: illegal option -- w
> ld: illegal option -- x
> ld: illegal option -- -
> ld: illegal option -- w
> <<<
The relevant line from ghc-pkg is:
system("ld -r -x -o " ++ ghci_lib_file ++
" --whole-archive " ++ batch_lib_file)
which is completely non-portable; neither the -x option nor the
--whole-archive option could be considered "standard". However, fixing
this properly might be more trouble than it's worth. Unless your ld
supports --whole-archive, there's no easy way to do this, I think. You
need to break out all the .o files from the archive first, and then use
'ld -r' to build a new .o file from the bits.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: FFI: passing 6 FD arguments doesn't work
> This was a bug in GHC's native code generator for SPARC, > which sometimes > misaligned the stack pointer. This has already been fixed in CVS (HEAD > and branch), but it didn't make it into 5.04, see: > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/nativeGen /MachCode.lhs.diff?r1=1.100&r2=1.101 I was just getting around to having a look at this one. George, can you verify that your test case works fine if you use -fvia-C? If so, I'll assume it's this NCG bug. The fix has been merged into the forthcoming 5.04.1. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: docs bug
> In local.glasgow-haskell-bugs, you wrote: > > > http://www.mirror.ac.uk/sites/www.haskell.org/ghc/docs/latest/ > html/base/Data.Bits.html > > The description of each method of the Bits class seems to > be attached > > to the signature of a different method. > > The documentation generated by haddock 0.4 looks fine (the web pages > were generated by 0.3). Could somebody please put up a fixed version > of the file from their cvs? Yes, this was caused by a bug in Haddock. When the 5.04.1 docs go up this will be fixed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GetMBlock: misaligned block
> after baking a new kernel for my Linux box I got this > funny error message: > > basilisk /home/ralf > ghci > ghc-5.04: fatal error: GetMBlock: misaligned block 0x15745000 > returned when allocating 1 megablock(s) at 0x5000 > > (There is a 4 year old entry on the mailing list reporting > the same problem.) > > Is there any workaround? Does recompiling ghc help? Any pointers > are greatly appreciated. Can you try this and send us the output: $ cat /proc//maps where is the PID of your shell (find it with ps). The problem is that GHC is asking for memory at a particular address (0x5000) and the kernel is returning memory elsewhere that doesn't satisfy our aligment constraints (1M aligned). We don't particularly care where we get memory from, but it must be properly aligned. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-5.02.3: fatal error: getStablePtr: too light
> I'm sporadically seeing the following error: > > ghc-5.02.3: fatal error: getStablePtr: too light > > Any ideas what it means or how to avoid it? > > I'm running on Linux. This is fixed in 5.04. I believe it was triggered by making too many stable pointers to the same object. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Priority of % (Ratio)
> If I load ratio and type 2^3%5 into Hugs I get "8 % 5" as > I'd expect. > > If I do the same for ghci, I get an error message, because > it's parsed it as 2^(3%5). Prelude Ratio ought to have > >infixl 7 % > > (or maybe it should be in GHC.Real), but I can't find it (in either) Fixed, thanks. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: takeMVar causes 'Segentation fault' when called from C
> Following example causes 'Segentation fault' under > Linux (Mandrake). Under Windows it works well. This is a known bug in 5.04; the fix will be in 5.04.1. Thanks for the report. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: killThread doc bug
> In local.glasgow-haskell-bugs, you wrote: > > I think it should be: > > killThread tid = throwTo tid (AsyncException ThreadKilled) > > Yes, that's right. > > I just noticed that 'killThread' in fact isn't implemented by > means of 'throwTo', but uses the 'killThread#' primop...wouldn't > it be cleaner to follow the above advice? Yes. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: select() failure
> > This can arise if you do one of the operations threadWaitRead or > > threadWaitWrite on a file descriptor that is closed. > Sigbjorn recently > > modified the select() code so that it wouldn't fail in such > an ugly way; > > now it just wakes up all the threads that were doing select() in the > > hope that the one with a bad file descriptor in its hands > will discover > > it some other way (the real problem is that select() doesn't tell us > > which file desriptors were bad/closed when it fails). > > > > Anyway, you should avoid this scenario if at all possible, since the > > current fall-back method of waking up all the threads could be quite > > expensive. > > I use `threadWaitRead` in one place and `threadWaitWrite` nowhere. I > added a check before the use of `threadWaitRead` that I've > not closed the > file descriptor. The check never detects a closed file > descriptor, yet I still get the select() failure. Hmm, then I don't know what is going wrong. Perhaps you could reduce it to a small example and post it? > I'm assuming that the RTS's select() is done on the sets of file > descriptors involved in current `threadWaitRead` and `threadWaitWrite` > calls. Is that true? Are there other uses of select() in the RTS? No, that's the only select() call. > > > Unfortunately, select() (and hence the GHC RTS) doesn't > > > identify the bad > > > descriptor(s). Here's where I suspect my program may be > > > going awry. The > > > main process creates a pipe. The process then forks. The > > > parent closes > > > the pipe's read descriptor immediately. The child soon goes > > > to read from > > > the pipe, using threadWaitRead followed by fdRead. The > child process > > > suffers the select failure shown above. > > > > So.. I take it the child shouldn't really be reading from a > closed file > > descriptor? > > The file descriptor is the read end of a pipe used to send > data from the > parent to the child. The parent closes it because it will > never use it, > but only after the parent forks. So the child's copy of the file > descriptor should still be open, n'est-ce pas? Yes, seems reasonable to me. Are there any other file descriptors that you are closing? Are you doing any lazy I/O? > > > By the way, why shouldn't such a "fatal error" in the RTS raise an > > > exception that I can catch in my program? I could then > > > determine at least > > > which thread in which process suffered the error. > > > > A 'fatal error' in the RTS usually means some kind of internal error > > which it isn't possible to recover from. Hence the term "fatal" :-) > > I've changed the wording in my copy to make it more clear that these > > errors are internal and normally indicate a bug. > > Is recovering from this error really not possible, as opposed to not > likely to be useful? Recovery is possible; as I mentioned the latest code in the HEAD does recover. Reporting an error is somewhat impractical, however, because select() doesn't tell us which of the file descriptors was bad. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: select() failure
> I have a program that is suffering a select() failure. It prints: > > 9 > select: Bad file descriptor > Fed: fatal error: select failed > > From looking at some RTS sources, the 9 apparently represents > errno EBADF > (bad file descriptor). Does that mean that my program is > somehow closing > one or more file descriptors between when the select() starts > and when it > finishes? This can arise if you do one of the operations threadWaitRead or threadWaitWrite on a file descriptor that is closed. Sigbjorn recently modified the select() code so that it wouldn't fail in such an ugly way; now it just wakes up all the threads that were doing select() in the hope that the one with a bad file descriptor in its hands will discover it some other way (the real problem is that select() doesn't tell us which file desriptors were bad/closed when it fails). Anyway, you should avoid this scenario if at all possible, since the current fall-back method of waking up all the threads could be quite expensive. > Unfortunately, select() (and hence the GHC RTS) doesn't > identify the bad > descriptor(s). Here's where I suspect my program may be > going awry. The > main process creates a pipe. The process then forks. The > parent closes > the pipe's read descriptor immediately. The child soon goes > to read from > the pipe, using threadWaitRead followed by fdRead. The child process > suffers the select failure shown above. So.. I take it the child shouldn't really be reading from a closed file descriptor? > By the way, why shouldn't such a "fatal error" in the RTS raise an > exception that I can catch in my program? I could then > determine at least > which thread in which process suffered the error. A 'fatal error' in the RTS usually means some kind of internal error which it isn't possible to recover from. Hence the term "fatal" :-) I've changed the wording in my copy to make it more clear that these errors are internal and normally indicate a bug. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: funPtrToAddr and addrToFunPtr
> > Well, we don't like to encourage the use of deprecated APIs, and I > > had intended to remove it for the next major release (it's been > > deprecated for well over 12 months). Do you still need Addr for > > something? > > Old Greencard interfaces use it. In fact, I don't think we've added > Ptr and FunPtr support to the StdDIS.gc files yet so even shiny new > greencard interfaces will use it > > For now I'm casting the funptr to a ptr and then casting that to addr. In that case I would just add these to StdDIS.gc. You already have ptrToAddr and addrToPtr in there, for GHC <= 5.02. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Funny global things
> One of the joys of using a compiler for a long time is the recognition > of old, familiar error messages like: > > Funny global thing?: _ErrorWithCode: > > It will seem like heresy then when I suggest that it might be time to > replace this with a meaningful error message. Ok, how about something like this: Warning: unknown top-level function in output from gcc: 'ErrorWithCode' ? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: funPtrToAddr and addrToFunPtr
> How about adding these to Addr.lhs? > > funPtrToAddr :: FunPtr a -> Addr > addrToFunPtr :: Addr -> FunPtr a > > They serve the same purpose as the existing ptrToAddr/addrToPtr Well, we don't like to encourage the use of deprecated APIs, and I had intended to remove it for the next major release (it's been deprecated for well over 12 months). Do you still need Addr for something? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: orphan modules
> in the ghc docs, section 4.9.8, it says > > You can identify an orphan module by looking in its interface file, > M.hi. If there is a ``!'' on the first line, GHC > considers it an orphan module. > > which i don't think is true anymore since .hi files are binary now... Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc/ghci version 5.04 under SunOS 5.8
> ghci seems to use a lot of cpu-time without doing something at the > prompt. Hmmm, you're right. I hadn't noticed that. I'll look into it for 5.04.1. > Furthermore "ghc -O2 ..." still creates binaries that yield a "Bus > Error" with gcc-3.1. > > Can't that be fixed? It has already been fixed, and the fix will be in 5.04.1. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
