Hi,
Is this bug the same as the one I reported on 25 March (Nit with 6.2.1)?
The original report:
Hi,
I built 6.2.1 on Mac OS X 10.3.3 from source with OpenGL support.
I built the Cube.hs demo program and it compiles and runs fine, but if
I
terminate it with crtl-C instead of hitting q
Is this bug the same as the one I reported on 25 March (Nit
with 6.2.1)?
Hmm... it might be related, but I haven't looked into it yet.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman
./a.out[21:57]
# Now hit Ctrl-C
a.out: internal error: main thread has been GC'd
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Thanks, that's a bug. I've fixed it in CVS.
As far as I can
PROTECTED] On Behalf Of Duncan Coutts
| Sent: 07 March 2004 23:47
| To: [EMAIL PROTECTED]
| Subject: TH quasi-quoting bug - fails on quoting where clause in let
declcontext
|
|
| In ghc 6.2 and 6.3 (CVS as of early March) evaluating the following in
| ghci gives an impossible happened error
On Fri, 26 Mar 2004 09:46:53 +0100, Robert Will [EMAIL PROTECTED] wrote:
The precondition-problem is not easy to fix. However, I ackknowledge that
your balancing-checks are really good evidence for the correctness of the
algorithm. (I didn't notice them first, because you checked via an
Started getting:
ghc-6.2.1.20040313: panic! (the `impossible' happened, GHC version 6.2.1.20040313):
mkTyVar a1 {- tv a75q -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
today... definitely a but to do with class inference
On Fri, 19 Mar 2004 09:00:22 +0100, Robert Will [EMAIL PROTECTED] wrote:
both of the data structures are based on Adams' balancing algorithm
which contains a bug -- at least in its proof. (Perhaps it is
correct, but I don't know anyone that knows if.)
I have been redoing proofs of Adam's
Hello,
I'm trying to use the -caf-all flag with ghc-6.02, in conjunction with -O
(which means going via C...)
But in a few modules of a large program, the .hc files contain duplicate
definitions of MODsat_CAF_cc_ccs (where MOD = a particular module)
I can't see an obvious pattern to the number
hi,
both of the data structures are based on Adams' balancing algorithm
which contains a bug -- at least in its proof. (Perhaps it is
correct, but I don't know anyone that knows if.)
Instead of fixing the bug I have re-derived the algorithm from the
invariant together with a (now hopefully
Sorry to trouble you with an already known bug.
Don's mail has answered my question.
In case you are curious, here is a link to a previous
mention of the bug/problem:
http://www.mail-archive.com/[EMAIL PROTECTED]/m
sg05854.html
Incedentally, GCC 3.4 will make this situation
I can't see a workaround, so it might be that string gaps will not be
useable with CPP from now on.
Maybe there is a small, simple KR-era cpp implementation we could use instead
of relying on the gcc one. Anyone know of one? Features used are probably:
#define
__LINE__
#undef
#ifdef
#if
Simon Marlow [EMAIL PROTECTED] writes:
Incedentally, GCC 3.4 will make this situation even worse. They have
now taken the approach that a backslash followed by whitespace at the
end of the line should be interpreted as a line continuation (and a
warning is emitted). So the hack from the
Incedentally, GCC 3.4 will make this situation even worse.
They have
now taken the approach that a backslash followed by
whitespace at the
end of the line should be interpreted as a line continuation (and a
warning is emitted). So the hack from the Users' Guide for
string gaps
On Mon, Mar 15, 2004 at 02:14:31PM +, Alastair Reid wrote:
I can't see a workaround, so it might be that string gaps will not be
useable with CPP from now on.
Maybe there is a small, simple KR-era cpp implementation we could use instead
of relying on the gcc one. Anyone know of
Hi,
Something very mysterious is happening when buddha is built with
GHC 6.2 on machines that have gcc 3.3.x
This bug has occurred on these two machines so far:
Gentoo linux with gcc 3.3.2
FreeBSD with gcc 3.3.3
Both x86 machines.
Note however, that the bug does not appear on machines
bjpop:
Hi,
Something very mysterious is happening when buddha is built with
GHC 6.2 on machines that have gcc 3.3.x
This bug has occurred on these two machines so far:
Gentoo linux with gcc 3.3.2
FreeBSD with gcc 3.3.3
Both x86 machines.
Note however, that the bug does
Hi all,
Sorry to trouble you with an already known bug.
Don's mail has answered my question.
In case you are curious, here is a link to a previous
mention of the bug/problem:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05854.html
Cheers,
Bernie
Hello,
I just installed ghc on Mandrake Linux 10, from the file
[EMAIL PROTECTED]
I was getting an error when I ran ghc and ghci:
Hsc static flags: -static
*** Parser:
interactive:1:
Could not find interface file for `GHC.Exception'
locations searched:
GHC/Exception.hs
I just installed ghc on Mandrake Linux 10, from the file
[EMAIL PROTECTED]
[EMAIL PROTECTED] is a mailing list; which distribution
did you use to install GHC?
I've been able to solve it with
cd /usr/local/lib/ghc-6.2/imports/System
ln -s io IO
cd /usr/local/lib/ghc-6.2/imports/
On Thursday 11 March 2004 13:01, Simon Marlow wrote:
I just installed ghc on Mandrake Linux 10, from the file
[EMAIL PROTECTED]
[EMAIL PROTECTED] is a mailing list; which distribution
did you use to install GHC?
Sorry, I had a problem with cut paste. :-)
The file I used to install is
I've been able to solve it with
cd /usr/local/lib/ghc-6.2/imports/System
ln -s io IO
cd /usr/local/lib/ghc-6.2/imports/
ln -s ghc GHC
You mean these directories were present but lower case?
Yes.
ghci -v and ghc -v were giving a very clear output that they
In ghc 6.2 and 6.3 (CVS as of early March) evaluating the following in
ghci gives an impossible happened error.
do {d - runQ $ [| let foo = bar where bar = 3 in foo |]; print d}
The bit that causes the problem is the where in the declaration context
introduced by the let.
ghci-6.2 says:
I have the following code:
it inserts a label pair into list of list, which contains label pairs
sharing the common label.
I run it with ghci -fglasglow-exts -fallow-undecidable-instances
*Test ins a Nil
Cons (Cons (LAB A [],[]) Nil) Nil
*Test ins a (ins a Nil)
Cons (Cons (LAB A [],[]) (Cons
Priority: 5
Submitted By: Simon Marlow (simonmar)
Assigned to: Simon Marlow (simonmar)
Summary: Directory.setPermissions bug
Initial Comment:
Directory.setPermissions doesn't preserve group/other
permissions on Unix.
--
Comment
: None
Priority: 5
Submitted By: Simon Marlow (simonmar)
Assigned to: Simon Marlow (simonmar)
Summary: Directory.setPermissions bug
Initial Comment:
Directory.setPermissions doesn't preserve group/other
permissions on Unix.
--
You
Good point. I've fixed GHC's online documentation as you suggest. For
the H98 report I'll put it in the bug list.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Andy Moran
| Sent: 11 February 2004 19:13
| To: [EMAIL
The library report doesn't seem to mention this, but giving floatToDigits a
negative number leads to nonsensical answers:
Prelude Numeric.floatToDigits 10 (-3.1415)
([-32,5,8,5],0)
Now, this probably makes perfect sense, but shouldn't the doco mention the
fact that floatToDigits requires a
The following program gives a weird type inference error for me in
ghc-6.2, but compiles perfectly fine in ghc-5.04.2, ghc-6.0, nhc98,
Hugs, etc.
module Bug ( mkRational ) where
import Ratio
data Lex = L_RATIONAL Rational
mkRational :: Integer - Integer - Integer - Integer
On Fri, Feb 06, 2004 at 11:13:57AM +, Malcolm Wallace wrote:
* -fglasgow-exts makes perfectly reasonable Haskell'98 code
invalid, throws up a totally misleading error unrelated to the
cause of the problem, and gives no clue as to what particular
extension is
me stumped for three days.
You can report this as a bug if you like :-)
I thought I just did :-)
- gives no clue as to what extension is responsible: hmm, this is
a really hard problem too, isn't it?
For syntactic extensions perhaps, but for type extensions
for three days.
You can report this as a bug if you like :-)
I thought I just did :-)
Simon: one complaint about a confusing type error message for you...
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED
Is this a known TH bug?
import Language.Haskell.THSyntax
foo e = $( [| e |] )
$ ghc -fglasgow-exts AlternateTH.hs
ghc-6.2: panic! (the `impossible' happened, GHC version 6.2):
nameModule e {- v a8 -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net
Yes, it's a known bug. You need the HEAD, I'm afraid, where it's been
fixed for some time.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Duncan Coutts
| Sent: 03 February 2004 20:56
| To: [EMAIL PROTECTED]
| Subject
On Wed, 2004-02-04 at 09:51, Simon Peyton-Jones wrote:
Yes, it's a known bug. You need the HEAD, I'm afraid, where it's been
fixed for some time.
Ok, trying to build from cvs...
I (think I've) followed the instuctions at
http://haskell.org/ghc/docs/latest/html/building/sec-cvs.html#CVS-FIRST
: Is this a known bug?
|
| On Wed, 2004-02-04 at 09:51, Simon Peyton-Jones wrote:
| Yes, it's a known bug. You need the HEAD, I'm afraid, where it's
been
| fixed for some time.
|
| Ok, trying to build from cvs...
|
| I (think I've) followed the instuctions at
|
http://haskell.org/ghc/docs/latest/html
while trying to adapt the local bootstrap-from-scratch script
that allows
us to install a somewhat customized GHC onto our systems starting from
nothing but an installed GCC 2.95, I noticed a bug in the
documentation
accompanying the GHC 6.2 release. On
http://www.haskell.org/ghc
Hello,
while trying to adapt the local bootstrap-from-scratch script that allows
us to install a somewhat customized GHC onto our systems starting from
nothing but an installed GCC 2.95, I noticed a bug in the documentation
accompanying the GHC 6.2 release. On
http://www.haskell.org/ghc
Hello!
In my opinion there is a bug in the emptySampleVar-function in
Control.Concurrent.SampleVar.
emptySampleVar :: SampleVar a - IO ()
emptySampleVar v = do
(readers, var) - takeMVar v
if readers = 0 then
takeMVar var - I think this
line
Hello!
In my opinion there is a bug in the emptySampleVar-function in
Control.Concurrent.SampleVar.
emptySampleVar :: SampleVar a - IO ()
emptySampleVar v = do
(readers, var) - takeMVar v
if readers = 0 then
takeMVar var - I think this line is missing
It's a bug. Now fixed. Test is should_compile/tc174
Thanks for finding it
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Sean Seefried
| Sent: 30 November 2003 04:01
| To: [EMAIL PROTECTED]
| Subject: Possible
Shouldn't the attached patch be applied to the file package.mk
in the GHC 6.2 build system?
Explanation:
I think that for the generation of the documentation the new
ghc should be used, not the old one. I got the following error
while compiling GHC 6.2 with OpenGL support, using the binary
Andres Loeh wrote:
Shouldn't the attached patch be applied to the file package.mk
in the GHC 6.2 build system? [...]
Thank for the patch, I've just applied it to the CVS version. I thought
I fixed this some time ago, but OTOH I have been building my GHC including
the OpenGL package for ages now...
Yesterday while I was mucking around in GHCi I discovered the following
anomaly. (The same holds for compiled code.)
I typed
:t (# 2, 3 #)
and got back
(# 2, 3 #) :: forall t t1. (Num t, Num t1) = (# t, t1 #)
But when I typed
:t (# 2, 3 #) :: (# Int, Int #)
I got the following
Illegal
#)
Is this correct behaviour?
Hi,
This is __pure speculation__, but it looks like a possible bug
in TcMType.checkValidType and friends.
The error message says that you can't have an unboxed tuple as an argument
to a function. However, this is not an argument.
In
check_tau_type rank ubx_tup ty@(TyConApp tc
-Original Message-
From: Simon Marlow [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 7:03 AM
To: Wojtek Moczydlowski; [EMAIL PROTECTED]
Subject: RE: A bug
The attached program, after compilation under ghc 6.0.1
with -O2 -package
wx under Windows, after
The attached program, after compilation under ghc 6.0.1 with -O2 -package
wx under Windows, after about 1 minute running on 2Ghz computer crashes
with the message: Internal error: RHS exhausted max heap size (...) report
this as a bug.
Wojtek
SG.hs
Description: Binary data
Main.hs
On Mon, 10 Nov 2003, Simon Peyton-Jones wrote:
| Also, I tried to update and rebuild, but the makefiles seem to have
the
| dependencies wrong or something. I compiles THSyntax.hs by hand, then
ran
| into some trouble with files that needed some modules from GHCI trying
| (and dying) to
A bug thank you; now fixed.
Please send bug reports about GHC to [EMAIL PROTECTED],
not to the Haskell mailing list.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Brandon
| Michael Moore
| Sent: 08 November 2003 13:20
| To: [EMAIL PROTECTED
When I load HToolkit 1.2 into GHC 6.0.1 I get the following:
--8
mettw ghci -package gio
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0.1,
for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/
/
\/\/ /_/\/|_| Type :? for help.
Loading package port ... linking ... /usr/lib/ghc-6.0.1/HSport.o: unknown symbol
`__stginit_GHCziWord_'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
can't load package `port'
Please report it as a compiler bug to [EMAIL PROTECTED],
or http
This was a grevious bug in 6.0, fixed in 6.0.1. I believe
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Till Mossakowski
| Sent: 15 October 2003 17:21
| To: [EMAIL PROTECTED]
| Subject: GHC 6.0 (Sparc-Solaris) bug
. I
also tried to put both the files in a separate directory without the
makefiles, but they work well. I also found that deactivating the -O2
switch makes the bug disappear, this is somewhat connected with the
various flags given to ghc in the makefile.
They are coded with shar so just chmod
version 6.0):
coreSyn/CoreUtils.lhs:1188: Non-exhaustive patterns in function isCrossDllArg
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
perl utils/create_sources.pl hetcats-make sources_hetcats.mk
Error: Couldn't create sources!!
gmake
-
| [EMAIL PROTECTED] On Behalf Of Nick Name
| Sent: 16 September 2003 01:22
| To: [EMAIL PROTECTED]
| Subject: Bug compiling with -fglasgow-exts
|
| I have a bug, here's the error from the compiler.
|
| ghc -fglasgow-exts -o build/Graphics/UI/GIO/Bitmap.o -package-name gio
| -ohi build/Graphics/UI/GIO
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug ghc --make
Initial Comment:
Using ghc-6.0 with
ghc --make mimico.hs
gives:
ghc: panic! (the 'impossible' happened, GHC 6.0):
coreSyn/coreUtils.lhs: 1188: Non-exaustive patterns
in function
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug ghc --make
Initial Comment:
Using ghc-6.0 with
ghc --make mimico.hs
gives:
ghc: panic! (the 'impossible' happened, GHC 6.0):
coreSyn/coreUtils.lhs: 1188: Non-exaustive patterns
in function
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug ghc --make
Initial Comment:
Using ghc-6.0 with
ghc --make mimico.hs
gives:
ghc: panic! (the 'impossible' happened, GHC 6.0):
coreSyn/coreUtils.lhs: 1188: Non-exaustive patterns
I was playing around with GHC and my compiled
dll-library of wxHaskell(see sourceForge for details).
The compilation was done with the last versions of
msys and MinGW.
In the GHC usersguide, I saw that it was possible to
link libraries with GHCi. So I thought, ok lets try
that.
I have a bug, here's the error from the compiler.
ghc -fglasgow-exts -o build/Graphics/UI/GIO/Bitmap.o -package-name gio
-ohi build/Graphics/UI/GIO/Bitmap.hi -odir build/Graphics/UI/GIO -c
src/Graphics/UI/GIO/Bitmap.hs -package port -O2 -ibuild
ghc-6.0.1: panic! (the `impossible' happened, GHC
In local.glasgow-haskell-bugs, you wrote:
and the some for the precompiled version,
i getting the following error.
Loading package unix ... linking ... /home/xxx/local/lib/HSunix.o: unknown symbol
`sendfile'
Hrmph. Sorry for the hassle. Please try adding sendfile to the list
of
original, g is actually a method in a class, and its definition is in
an instance declaration. Its type is actually given, not annotated. For
instance:
Ah, g is meant to be a method. Well, ...
-- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
module WeirdInsts
On Monday, Sep 8, 2003, at 03:53 US/Pacific, Simon Peyton-Jones wrote:
Consider an instance decl like:
instance (Lte a b l,If l b a c) = Max a b c
(This is a real example.) Notice that l is used on the LHS of the
= but not the RHS. The idea is that l will get unified by a
functional
Simon said
This is a tricky one. Here's what is going on.
I believe there's nothing tricky going on.
Your type annotation
g :: (F a b,D b (T r)) = (a,T r)
g = f
is simply incorrect. Keep in mind that GHC does NOT improve
type annotations. For example,
g :: (F a b, C (T r)) = (a,T r)
g =
On Tuesday, Sep 9, 2003, at 00:40 US/Pacific, Martin Sulzmann wrote:
Your type annotation
g :: (F a b,D b (T r)) = (a,T r)
g = f
is simply incorrect.
I must say I don't understand. I need a value of that type. In the
original, g is actually a method in a class, and its definition is in
an
This fails to compile. Oddly enough, if you remove the instance
declaration (1), or if you remove the r parameter to T, or if you do any
of the other simplifications I've tried, it compiles successfully.
-- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
module WeirdInsts
ghc -c Ghcbug.hs
c:\ghc\ghc-5.04\bin\ghc.exe: panic! (the `impossible' happened, GHC
version 5.04):
expectJust tyConDataCons
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Ghcbug.hs:
--
module O where
type O a = Ord
ghc -c Ghcbug.hs
c:\ghc\ghc-5.04\bin\ghc.exe: panic! (the `impossible' happened, GHC
version 5.04):
expectJust tyConDataCons
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Ghcbug.hs:
--
module O where
.
Prelude
Prelude let sieve (x:xs) = x : filter ((/= 0).(`mod` x)) (sieve xs) in sieve
[2 ..]
ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
getLinkDeps No iface for [pkg]GHCziErr
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc
You need 6.0.1 This bug is a famous problem with 6.0
I'm glad it's otherwise solid!
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Julian Seward
| Sent: 03 September 2003 16:35
| To: [EMAIL PROTECTED]
| Subject: A bug in GHC 6.0 (unbelieveable, I
: 5
Submitted By: Martin Norbäck (norpan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode bug in toUpper/toLower
Initial Comment:
Since GHC now does full unicode, toUpper ought to be
full Unicode also. According to the Haskell 98 Library
Report, section 9:
Function toUpper converts a letter
Hi,
I found a bug in hp2ps: if you use MARKs, it seems to assume the x-axis
starts at zero. So if your x-axis starts at, say, 5, then all the marks
get shifted to the right by 5 x-units. See attached file for an example.
This is with GHC 5.04.2, but judging from CVS most of hp2ps hasn't been
Greetings, y'all.
I've got a small 17000 line Haskell program which works fine
under the following sets of flags (also uses -package data
-package text), which are not shown:
ghc -o main --make Main.hs -fasm-x86
ghc -o main --make Main.hs -O -fasm-x86
ghc -o main --make Main.hs -O
In article [EMAIL PROTECTED],
I wrote:
$ ghc -fno-implicit-prelude -prof -c M.hs
/tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function)
/tmp/ghc4124.hc:5: initializer element is not constant
/tmp/ghc4124.hc:5: (near initialization for `M_CAFs_cc_ccs[0].prevStack')
/tmp/ghc4124.hc:5:
In article [EMAIL PROTECTED],
I wrote:
$ ghc -fno-implicit-prelude -prof -c M.hs
/tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function)
/tmp/ghc4124.hc:5: initializer element is not constant
/tmp/ghc4124.hc:5: (near initialization for
`M_CAFs_cc_ccs[0].prevStack')
GHC 6.0 fails to compile this on x86 Linux with -fno-implicit-prelude
-prof:
module M where {}
$ ghc -fno-implicit-prelude -prof -c M.hs
/tmp/ghc4124.hc:5: `NULL' undeclared here (not in a function)
/tmp/ghc4124.hc:5: initializer element is not constant
/tmp/ghc4124.hc:5: (near initialization
Fixed thank you.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Hal Daume
| Sent: 30 June 2003 18:09
| To: [EMAIL PROTECTED]
| Subject: small bug with :info and ids beginning with _
|
| :info treats _a as an infix operator in ghci.
|
| Prelude
.
Loading package base ... linking ... done.
Prelude case a of a - True
True
Prelude case b of b - True
True
Prelude case ab of ab - True
ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
getLinkDeps No iface for [pkg]GHCziErr
Please report it as a compiler bug to [EMAIL PROTECTED
:info treats _a as an infix operator in ghci.
Prelude let _a = 'a'
Prelude :i _a
-- _a is a variable, defined at interactive:1
(_a) :: Char
should have not enclosed _a in parens.
--
Hal Daume III | [EMAIL PROTECTED]
Arrest this man, he talks in maths.
in TclCompatibilityGhcSupportsConcurrency.hs
hth
--sigbjorn
- Original Message -
From: Simon Peyton-Jones [EMAIL PROTECTED]
To: GHC bugs [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Meurig Sage [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 02:32
Subject: RE: GHCi bug - the impossible happened loading FranTk
Sigh, this time with an attachement..
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: Simon Peyton-Jones [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:53
Subject: Re: GHCi bug - the impossible happened loading
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
___
the workaround for the other GHCi bug, but this apparently different, as shown
below.
Full disclosure requires me to highlight the following text from the FranTk makefile:
# Ununcomment this line to support concurrency.
# This support does NOT work with ghci. It does not currently export
# the special
[orff:tools/hc/dev] atze% ghci -package data
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking
I just try this
Prelude> let f 0 = 1
ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
getLinkDeps No iface for [pkg>]GHCziErr
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
--
Pierre Val
it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
--
Hal Daume III | [EMAIL PROTECTED]
Arrest this man, he talks in maths. | www.isi.edu/~hdaume
___
Glasgow-haskell-bugs mailing list
]GHCziErr
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Regards,
Terje
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Prelude
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Hi,
playing around with partial evaluation,
I encountered the following bug:
65 ghc --make -fglasgow-exts -package haskell-src Main.hs -o Main -ddump-splices
Chasing modules from: Main.hs
Compiling Power( Power.hs, ./Power.o )
Compiling Main ( Main.hs, ./Main.o )
ghc-6.0
Hi all,
I seem to remember reading about this before, but I can't
find it, so I'm sorry if I'm repeating a known bug report.
It seems that -fglasgow-exts has trouble with (##) as an
operator:
module Main where
f ## x = f x
main = print $ (##) id True
It doesn't like the prefix use
On Fri, Jun 06, 2003 at 08:00:00PM +1000, Bernard James POPE wrote:
Hi all,
I seem to remember reading about this before, but I can't
find it, so I'm sorry if I'm repeating a known bug report.
It seems that -fglasgow-exts has trouble with (##) as an
operator:
module Main where
f
Yes, this is a known bug, but thank you for reporting it anyway. I'm
going to fix it as part of my next sweep though.
I enclose a message that gives a workaround.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Ch. A. Herrmann
| Sent: 05
Hi Simon
Simon Yes, this is a known bug,
Sorry that I'm not perfectly aware of everything going
on with Template Haskell.
Simon but thank you for reporting it
Simon anyway. I'm going to fix it as part of my next sweep though.
Thank you very much. I'm happy to know
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: -odir bug
Initial Comment:
hello,
there seems to be a problem when compiling modules
using the hirarchical-namespace and using the -odir flag:
(in A/A.hs)
module A.A where
import A.B
(in A/B.hs)
module A.B
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: -odir bug
Initial Comment:
hello,
there seems to be a problem when compiling modules
using the hirarchical-namespace and using the -odir flag:
(in A/A.hs)
module A.A where
import A.B
(in A/B.hs
glasgow-haskell-bugs
I use GHC5.04.3 on windows XP.
I want to getCPUTime function to get a number used as a random seed.
The getCPUTime works well in GHCi(always increasing), but when
compiled by ghc, the return value of getCPUTime is fixed to two
values.This can be demonstrated by:
Marlow (simonmar)
Summary: x86 NCG bug with stdcall f.i. wrapper
Initial Comment:
Original message from Sven Panne:
HOpenGL did it once again... :-} The NCG for x86
doesn't honour the calling convention for wrappers:
-- example module
module CB where
import
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
Hi,
Apologies for the sloppiness of this bug report.
in ghc 5.04.2 I get this message:
ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2):
coreSyn/Subst.lhs:385: Non-exhaustive patterns in function zip_ty_env
I would love to try and give you a simple test case, but I
If you compile the lambda nofib benchmark with -fext-core, GHC won't
compile the resulting .hcr file:
[EMAIL PROTECTED] lambda]$ ghc -fext-core Main.hs
[EMAIL PROTECTED] lambda]$ ghc Main.hcr
Illegal data constructor name `Main.StateMonad2'
This is using GHC 5.05.
--
Kirsten Chevalier *
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
701 - 800 of 1266 matches
Mail list logo
