> 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 g
> 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 li
> 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/
> \/\/ /_/\
> 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-has
> 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
> 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 htt
> 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>
> 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
> 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-de
> 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 HGe
> > 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.
>
> Regardles
> 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
> 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.
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 Mes
> 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.h
> > > 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) symbol
> 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
> namesp
> 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
> 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:
> 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,
gh
> 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 situatio
> 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")
> [
> 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 -
c
> 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 reprod
> 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.0
> 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 -
> >> 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
> 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
> > > l
> "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 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 t
> 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,
> 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 t
> (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 ... linkin
> 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 tr
> 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
> 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
unsu
> 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
> "gh
> 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
> 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 ...
> ig
> > 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 examp
> 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:
>
> 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
> 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 int
> 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
> 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 comp
> 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,
> 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
> 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
> ^
> her
> 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
> > 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 o
> 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 pa
> 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 ...
> 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
> Has
> 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 compi
> 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 #-}
> 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 -
> "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
> 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
> --
> 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 r
> 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
> 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).
> 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
> Compilin
> 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]
ht
> 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 tryin
> 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
> 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 GH
> [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 G
> 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
>
> > 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
> > 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
> 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#, acos
> 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-ha
> 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
> *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
> 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
tr
> 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 poin
> 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
> 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 c
> 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 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/S
> 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 re
> 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
> 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
> 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
>
> "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).
> 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:
> 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.di
> 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
> 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
>
> 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,
> 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,
> 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 PRO
> 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
>
> > 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
> 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 clo
> > 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
> 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 som
> 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
> 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
> 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 f
501 - 600 of 1401 matches
Mail list logo
