#647: Socket bug on Mac OS X, with patch
--+-
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone
#661: Serious Data.HashTable bug
---+
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: high|Milestone
#370: possible compacting GC bug in 6.4.x
-+--
Reporter: zooko | Owner: simonmar
Type: bug | Status: assigned
Priority: high| Milestone: 6.4.2
Frederik Eaton wrote:
Template Haskell doesn't work with profiling, I'm afraid (for the
same reason that you can't load profiled object code into GHCi). I
thought we had an open bug on this, but I couldn't find one, so I
just created one:
http://cvs.haskell.org/trac/ghc/ticket/651
Writing
#482: 'Bug' when installing GHC 6.4.1
---+
Reporter: nobody| Owner: wolfgang
Type: bug | Status: assigned
Priority: normal| Milestone:
Component: Build
Simon Marlow wrote:
For now, this query gets you all the bugs in 6.4.1,
open or closed:
http://cvs.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedstatus=closedversion=6.4.1order=priority
A slightly better URL:
Hello Simon,
Wednesday, January 04, 2006, 11:22:50 AM, you wrote:
Simon, look at [EMAIL PROTECTED]
part of this SimonM's letter:
If anyone is interested, this turned out to be a bug in the Network.BSD
module, namely that getHostByName isn't thread safe because it is based
on the C library
#342: GHC: panic! (compiler bug?)
---+
Reporter: nobody| Owner: nobody
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler
| Subject: Bug in cvs head ghci
|
| HI,
|
| Typing
|Prelude :b GHC.Base
|
| I get
| [snip]
| data Addr#
| data Array# a
| data Bool = False | True
| data ByteArray#
| data Char#
| data Char = C# Char#
| data Double#
| data Float#*** Exception: No match in record selector
Yep, reproducible with last night's HEAD build on mingw
(but not STABLE.)
--sigbjorn
- Original Message -
From: Simon Peyton-Jones [EMAIL PROTECTED]
To: wld [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org
Sent: Friday, December 16, 2005 08:13
Subject: RE: Bug in cvs head ghci
#629: IO library locking bug
--+-
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: lowest| Milestone:
Component: Compiler |Version
HI,
Typing
Prelude :b GHC.Base
I get
[snip]
data Addr#
data Array# a
data Bool = False | True
data ByteArray#
data Char#
data Char = C# Char#
data Double#
data Float#*** Exception: No match in record selector TyCon.tyConTyVars
Prelude
ghc built on Linux with
- ghc 6.4.1
-
./randomplay +RTS -hr
... - some time passes and then
randomplay: internal error: Invalid object in isRetainer(): 67
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
The combination of this and the failure with -hc -hbdrag,void
Hello ghc folks,
The following GADT program fails to typecheck, although I think it really
should be fine, so I'm reporting this as a bug. I'm sorry, but I haven't
been able to simplify the foo function any more without causing the error
to go away. :(
{-# OPTIONS_GHC -fglasgow-exts
{-# OPTIONS_GHC -fglasgow-exts #-}
module Main where
data Foo a b where
Foo :: Int - Foo a b
data Patch a b where
PP :: Foo a b - Patch a b
Lis :: PL a b - Patch a b
data PL a b where
U :: Patch a b - PL a b
Nil :: PL x x
(:-) :: PL c d - PL d
Andres Loeh [EMAIL PROTECTED] writes:
Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC
version 6.4
FWIW, same error with ghc-6.5 from a few weeks ago.
Same error from a ghc-cvs build from two days ago.
--
Shae Matijs Erisson - http://www.ScannedInAvian.com/ -
This indicates a bug in GHC 6.2.2,
which we don't support any more. Does the same problem occur with a more
recent version of GHC?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry
NewmanSent: 24 November 2005 23:18To:
glasgow-haskell-bugs@haskell.orgSubject: Bug
of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build System
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Bug' when installing GHC
Hi Baltasar,
maybe it's GHC's inliner. See
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc
and the russel example is similar enough to yours. (I have not
checked, though.)
I apologize, again, for the wrong spelling, It must be Russell with
two l!
Cheers
, GHC version 6.5):
unknown exception
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Results of ghc-pkg list:
c:/Program Files/Visual Haskell\package.conf:
rts-1.0, haskell98-1.0, template-haskell-1.0, Cabal-1.0
Tuesday, October 18, 2005, 12:25:32 PM, napisał(a)eś:
SM On 17 October 2005 15:58, Piotr Wilkin wrote:
Can you try with -v and send us the output, also the output from
'ghc-pkg list', and 'ghc-pkg describe wxcore', 'ghc-pkg describe wx'.
All with the versions of these tools that came with
no location info:no location info:
ghc.exe: panic! (the 'impossible' happened, GHC version 6.5):
unknown exception
Is this one of those hidden bugs due to the bundled version being a
prerelease, or am I missing something obvious?
There's a bug in the error message, and I'm
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Results of ghc-pkg list:
c:/Program Files/Visual Haskell\package.conf:
rts-1.0, haskell98-1.0, template-haskell-1.0, Cabal-1.0,
parsec-2.0, haskell-src-1.0, network-1.0
-files are processed correctly (except for the weaknesses inherent in
the code) when the code is compiled not for profiling or with
ghc-6.2.2 -prof -auto-all, so I'm rather convinced, it's a 6.4-bug.
If you could explain this behaviour, I'd be grateful.
Cheers,
Daniel Fischer
lpp.tar.gz
this bug is fixed in ghc-6.4.1 (see my attached profile)
Christian
Daniel Fischer wrote:
Hello,
I have encountered some strange behaviour with David Tweeds LaTeX-preprocessor
(slightly modified code attached).
When I compile it for profiling (-prof -auto-all) and run it on a .tex-file
! (the `impossible'
happened, GHC version 6.4):
hsSyn/Convert.lhs:(339,8)-(350,91): Non-exhaustive patterns in
function trans
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
I attached the two (short) source files.
Ben
module
succeeds!
Correct me if I'm wrong, but shouldn't a properly working compiler
either fail or succeed on a given package, and not fail one time, and
then succeed the next? I mean, this is the whole referential
transparency deal right? :)
I can reproduce this bug on ghc 6.4 and 6.4.1.20050812 on two
Section 7.6.1 reads:
_expression_
quotation is written in Oxford brackets, thus:
[| ... |], where the "..." is
an _expression_; the quotation has type Expr.
On the other hand GHCi 6.4behaves as
follows:
Prelude V02pIL :type
[|"foo"|][|"foo"|] ::
Quite right. The documentation should
say Q Exp instead of Expr. Ill fix that.
(ExpQ is a synonym for Q Exp)
Simon
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Allen Brown
Sent: 24 July 2005 02:08
To:
glasgow-haskell-bugs@haskell.org
Subject: Bug
I've also found this annoying in the past, but never quite enough so to
get around to e-mailing about it :-)
Thanks
Ian
---BeginMessage---
Package: ghc6
Version: 6.4-4
Severity: minor
It's a little annoying that ghc6 sends its (voluminous) --help output to
stderr, thus requiring extra
On 07 July 2005 19:57, Bulat Ziganshin wrote:
bug in ghc-6.4-src\libraries\base\Data\Version.hs:
instance Eq Version where
v1 == v2 = versionBranch v1 == versionBranch v2
all (`elem` (versionTags v2)) (versionTags v1)
-- tags may be in any order
bug in ghc-6.4-src\libraries\base\Data\Version.hs:
instance Eq Version where
v1 == v2 = versionBranch v1 == versionBranch v2
all (`elem` (versionTags v2)) (versionTags v1)
-- tags may be in any order
this really checks that v1.tags is subset
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: GHC: panic! (compiler bug?)
Initial Comment:
I just
/lib/ghc-6.2.2/HSbase.o: unknown
architecture
ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2):
loadObj: failed
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
uname -a gives:
Linux ollie 2.6.10-5-amd64-k8 #1
/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... /usr/lib/ghc-6.2.2/HSbase.o: unknown
architecture
ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2):
loadObj: failed
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org, or
http
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
AlamSent: 03 June 2005 13:26To:
glasgow-haskell-bugs@haskell.orgSubject: compiler
bug
To Whom It May Concern,
while working with GHCi on xemacs, I tried running the program
but come up with this error
"*Main maingNo
To Whom It May Concern,
while working with GHCi on xemacs, I tried running the program but come up with this error
"*Main maingNot x86 PEi386hc.exe: panic! (the `impossible' happened, GHC version 6.2.2):loadObj: failed
Please report it as a compiler bug to glasgow-haskell-bugs@haskel
If I simply try the following:
genCG.hs
{-# OPTIONS -fglasgow-exts #-}
module GenCG where
gdecls pbname pbniname = [d|
valGetter pbname = Get ++ pbniname
valSetter pbname = Set ++ pbniname
fldGetter pbname = Get ++ pbniname ++ Field
fldSetter pbname = Set ++ pbniname ++ Field
arrGetter
I realize that my previous TH programs were incorrect.
But my compiant is about GHC not reporting something like Multiple
declarations... but panics or plainly crashes.
Sorry.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
Hi,
I've tried to run the command ghc -c ikosaeder.hs and got the
following:
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.Neighbor{tc r15r} []
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc
On 23 April 2005 16:44, Henning Günther wrote:
I've tried to run the command ghc -c ikosaeder.hs and got the
following:
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.Neighbor{tc r15r} []
Please report it as a compiler bug to
glasgow-haskell-bugs
I get the following bug when trying to build hsql with GHC 6.4, on Mac
OS X. I am using the binary release of GHC from the GHC website.
$ runhaskell Setup.lhs build
Preprocessing library hsql-1.2...
Building hsql-1.2...
Setup.lhs: internal error: stg_ap_v_ret
Please report this as a bug
Hello.
The following program demonstrates the bug:
import GHC.Handle
import GHC.IOBase
import GHC.Conc
import IO
main = do
h - openFile /tmp/out WriteMode
hDuplicateTo h stdout
fdh - getfd h
fdstdout - getfd stdout
hPutStrLn stderr (h: ++ show fdh ++ \nstdout: ++ show
On 06 April 2005 16:16, Volker Wysk wrote:
The following program demonstrates the bug:
import GHC.Handle
import GHC.IOBase
import GHC.Conc
import IO
main = do
h - openFile /tmp/out WriteMode
hDuplicateTo h stdout
fdh - getfd h
fdstdout - getfd stdout
hPutStrLn
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: GHC: panic! (compiler bug?)
Initial Comment:
I just tried to compile the most recent version of Pugs
( www.pugscode.org ), and I got this:
Compiling Prim
/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... /usr/lib/ghc-6.2.2/HSbase.o: unknown architecture
ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2):
loadObj: failed
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net
. / /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... /usr/lib/ghc-6.2.2/HSbase.o: unknown
architecture ghc-6.2.2: panic! (the `impossible' happened, GHC
version 6.2.2): loadObj: failed
Please report it as a compiler bug to
glasgow-haskell
are produced and consumed with good
producers and consumers (as in section 7.10.3 in the User's Guide)
they should really go away. This seems to be a real bug.
This is what Simon M thought when I brought this up previously. He
suggested I use explicit recursion (which I thought I was doing with my
ailed
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
*Main main
Loading package Win32-1.0 ... linking ...
c:\temp
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
ht
Hi,
This sort of code runs very slowly when compared to the equivalent in C:
{-# OPTIONS -fglasgow-exts #-}
module Main where
import Data.Array.MArray
import Data.Array.IO
data Pos = Pos !Int !Int
deriving (Eq, Ord, Ix)
main = test1
test1 :: IO ()
test1 = do
(arr ::
On Mon, 2005-03-14 at 13:41 +, Duncan Coutts wrote:
Hi,
This sort of code runs very slowly when compared to the equivalent in C:
[snip]
BTW These timings were for ghc 6.2.2
My version of ghc 6.3 (CVS from about a month or two ago) gave slightly
beter timings on both loop version.
My
are produced and consumed with good
producers and consumers (as in section 7.10.3 in the User's Guide)
they should really go away. This seems to be a real bug.
[C program deleted]
{-# INLINE doFromTo #-}
-- do the action for [from..to] ,ie it's inclusive.
doFromTo :: Int - Int - (Int - IO ()) - IO
We can make it a little faster by not doing bound checks:
test4 :: IO ()
test4 = do
(arr :: IOUArray Int Bool) - newArray_ (0,100*100-1)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
unsafeWrite arr (x*(y+1)) False
Timings (compiled with -O2):
On Tue, 15 Mar 2005 02:06:06 +0100, Lemmih [EMAIL PROTECTED] wrote:
We can make it a little faster by not doing bound checks:
test4 :: IO ()
test4 = do
(arr :: IOUArray Int Bool) - newArray_ (0,100*100-1)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
This one might go even faster again.
Essentially due to Don Stewart but removes the bound checks and uses
Int as an index.
-
module Main
where
import Data.Array.MArray
import Data.Array.IO
import Data.Array.Base
import GHC.Base
import GHC.IOBase
forn a n | n =# 1# = return ()
and consumers (as in section 7.10.3 in the User's Guide)
they should really go away. This seems to be a real bug.
This is what Simon M thought when I brought this up previously. He
suggested I use explicit recursion (which I thought I was doing with my
second version though it doesn't do much
test2 style loops). It can now generate enough X traffic to
make the X server take 25% cpu time whereas previously it only got X
doing 15-20%.
I realised there was a performance bug when I commented out the Sim.step
from the inner loop and found that the visuliser speed only doubled, but
sommenting out
duncan.coutts:
This sort of code runs very slowly when compared to the equivalent in C:
This example uses unboxing and primops over Lemmih's and seems to run a bit
faster:
Lemmih's loops:
./a.out 1.35s user 0.00s system 99% cpu 1.359 total
This code:
./a.out 0.99s user 0.00s
Prelude let x = 1
Prelude $([|x|])
ghc.exe: panic! (the `impossible' happened, GHC version 6.2.2):
nameModule x {- v a6XY -}
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Prelude
-W-M
Brian
Thanks for reporting this grievous bug. It's now fixed and there's a
test in the regression suite for it (cg055). Particular thanks for
boiling it down to such a small case.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED
everything works fine. Finally, the bug
only shows up when the -O flag is used.
Plenty more details (including a self contained test case) are below.
-Brian
transam:~/tmp$ cat GHCBug.lhs
\begin{code}
import System (getArgs)
-- NOTE: When if you remove Eight (or any other constructor) everything
).
Compiling Exponent to a .o file did work, so there is no real problem.
However, ghci said 'Please report it as a compiler bug', so I am doing it.
Besides, there are no tuples at all in module Exponent, module TheLog, where
there are a couple of tuples (are they unboxed though?) was compiled
not much about such things, so I can only hope
that is helpful for you).
Compiling Exponent to a .o file did work, so there is no real problem.
However, ghci said 'Please report it as a compiler bug', so I am
doing it. Besides, there are no tuples at all in module Exponent,
module TheLog, where
Thanks very much for fixing this, Simon.
I will try and build hsjni either against HEAD orthe next release and
let you know how it goes.
Kind Regards,
-Antony
Simon Marlow wrote:
On 19 December 2004 16:35, Sven Panne wrote:
Antony Courtney wrote:
I'm trying to upgrade my Java/Haskell
On 19 December 2004 16:35, Sven Panne wrote:
Antony Courtney wrote:
I'm trying to upgrade my Java/Haskell interoperability framework to
the latest Java version. Unfortunately, however, it appears that
hsc2hs can't deal with embedded spaces in command line
arguments.[...]
Both of your
On Dec 15, 2004, at 8:30 AM, Simon Peyton-Jones wrote:
OK, I understand this.
1. You really do have overlapping instances, exactly as reported in
the error message.
2. The instance in Data.Graph.Inductive.Graph looks like this
instance ... = Eq (gr a b)
This is, as you say, crazy,
Oops. Looks like I sent this to the wrong list...
-Antony
Original Message
Subject: bug in argument processing in hsc2hs
Date: Sun, 19 Dec 2004 09:50:19 -0500
From: Antony Courtney [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I'm trying to upgrade my Java/Haskell
Antony Courtney wrote:
I'm trying to upgrade my Java/Haskell interoperability framework to the
latest Java version. Unfortunately, however, it appears that hsc2hs
can't deal with embedded spaces in command line arguments.[...]
Both of your problems look like the usual problems with the broken
Lüttich; [EMAIL PROTECTED]
| Subject: visibility of instances (was: Bug in compiling large projects ?)
|
| Simon Peyton-Jones wrote:
| I remember this one from before.
|
| We're not planning to do significant more work on the 6.2 branch, so I'm
not inclined to hunt this
| one down unless
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor bug in rpm (x86 linux)
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN=/usr/lib/ghc
: None
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor bug in rpm (x86 linux)
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
Is there any hope for the glitch in
http://www.haskell.org//pipermail/glasgow-haskell-users/2004-June/006874.html ?
I have an application that would benefit from a fix.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
Good day. I'm using GHC 6.2.1, and have had much
success with it. However, yesterday I got a strange
error I've never before seen.
Mosaic: internal error: stg_ap_p_ret
Please report this as a bug to glasgow-haskell-
[EMAIL PROTECTED], or
http://www.sourceforge.net/projects
,
Simon
On 07 December 2004 15:37, oriel maxime wrote:
Good day. I'm using GHC 6.2.1, and have had much
success with it. However, yesterday I got a strange
error I've never before seen.
Mosaic: internal error: stg_ap_p_ret
Please report this as a bug to glasgow-haskell-
[EMAIL
I think I've fixed this one. Would you like to update and try again?
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Laszlo Nemeth
| Sent: 01 December 2004 16:35
| To: [EMAIL PROTECTED]
| Subject: Bug in specialise
[re-sending because I got no response yet]
On Tuesday 23 November 2004 13:06, Simon Marlow wrote:
On 22 November 2004 17:28, Benjamin Franksen wrote:
However, what I don't understand is why touchForeignPtr is not
honored in my example program: Note that the output text lines from
the
Hi,
Take a look at the following program, making use of
derivable type classes.
module Bug where
import Data.Generics
class Foo a where
foo :: a - Int
foo{| Unit |}_ = 1
foo{| a :*: b |} _ = 2
foo{| a :+: b |} _ = 3
instance Foo [a]
GHC 6.2.2 produces the following error
] On Behalf Of Koen Claessen
| Sent: 16 November 2004 17:17
| To: [EMAIL PROTECTED]
| Subject: Derivable type classes bug?
|
| Hi,
|
| Take a look at the following program, making use of
| derivable type classes.
|
|
| module Bug where
|
| import Data.Generics
|
| class Foo a where
| foo :: a - Int
| But there remains another one: a DoCon `making' bug.
| If it occurs, for example, due to a bug in the garbage collection,
| then any computation is damaged.
|
Yes, Simon M is looking into that in due course; it seems to be a bug in
the 1-space compacting.
Simon
Dear GHC team,
My investigation of why a certain list field in a record
does not print lazily has lead to something like a bug report
for ghc-6.2.2.
The program example of kind
let f = ...
mbPair = ...
in
f $ case mbPair of Just _ - error Lemma found\n
Yes, please, withdraw my last `bug' report on ghc-6.2.2.
The next day after I sent a `bug report' I also discovered that the
program behavior looks natural.
Because most of the functions in the presented module call each
other in a complex recursive way.
But there remains another one: a DoCon
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: Bug in compiling large projects ?
|
| Hello,
|
| I have send a message to these lists a weak ago with almost the same
| topic, but I have now additional observations: The problem is not
| related to option -O in GHC 6.2.1 ! We use
Hello,
we are working on a very large project called Hets (heterogenous tool
set) where we encounterd two related errors in ghc, which disappear when
we start over the compilation at that point where the compilation
stopped
due to one of that errors. We certainly use the current version 6.2.1 of
You will have to give both the errors and the source code...
I have done quite a bit with classes and GHC's constraint
inferance is pretty good.
The chances are you really do need to add some extra
constraints...
(by the way if you are working with heterogeneous collections,
you may be
Using the glibc-2.2 (RedHat 7) Linux binary package of ghc-6.2.1,
the following program:
import System.Cmd
main = do v - system(ghc --version 21)
print v
incorrectly gives
ExitFailure 127
whereas with the glibc-2.3 Linux binary package of ghc-6.2.1, the
same program
On 20 July 2004 13:39, Malcolm Wallace wrote:
Using the glibc-2.2 (RedHat 7) Linux binary package of ghc-6.2.1,
the following program:
import System.Cmd
main = do v - system(ghc --version 21)
print v
incorrectly gives
ExitFailure 127
Are you sure your shell
Simon Marlow [EMAIL PROTECTED] writes:
import System.Cmd
main = do v - system(ghc --version 21)
print v
Are you sure your shell understands the '' syntax? Not all do.
Yes, on RH7.2, /bin/sh is bash.
Assuming you're using the same shell in both cases, this could
On 20 July 2004 14:26, Malcolm Wallace wrote:
There doesn't seem to be much significant difference. Here are the
relevant
chunks of strace output, first for the working 6.2.1 on glibc-2.3:
vfork() = 3552
wait4(3552, The Glorious Glasgow Haskell
Windows XP
D:\Tools\ghcghc-6.2.1\bin\ghc.exe -fglasgow-exts foo.hs
ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1):
deSugar/DsMeta.hs:286: Non-exhaustive patterns in function repC
module Foo where
import Language.Haskell.THSyntax
class MyInterface a where
foo
Windows XP
D:\Tools\ghcghc-6.2.1\bin\ghc.exe -fglasgow-exts --make foo.hs
Chasing modules from: foo.hs
Compiling Any ( ./Any.hs, ./Any.o )
Compiling Foo ( foo.hs, foo.o )
Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading
(Char.chr (read 0x2B :: Int))
'+'
Prelude
Ghc's behaviour seems entirely reasonable, but it does not conform
to the Report. Should we regard this as a bug in the definition
therefore? Is there an on-going errata list for the final Revised
Report?
I think we class
: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Malcolm Wallace
| Sent: 31 May 2004 11:24
| To: [EMAIL PROTECTED]
| Subject: bug in instance Read Int
|
| The Haskell'98 Report specifies that 'read'ing an Int should accept
| only decimal notation
|
| instance Read
behaviour seems entirely reasonable, but it does not conform
to the Report. Should we regard this as a bug in the definition
therefore? Is there an on-going errata list for the final Revised
Report?
Regards,
Malcolm
___
Glasgow-haskell-bugs mailing
Hello,
I dont know if it has been reported, this looks like a bug in TH. The
program goes into infinite loop.
Saswat
-
instance Lift (a - b) where
lift f = [| f |]
compile :: (a - b) - ExpQ
compile p = lift p
printE :: ExpQ - IO ()
printE expQ = do exp - unQ expQ
On 15 April 2004 05:20, Stefan Ljungstrand wrote:
The code is a small modification of mine to the attribute-grammar-like
(multi-pass lazy) example with recursive IO at
http://www.cse.ogi.edu/PacSoft/projects/rmb/repMin.html
The original code replaces every (leaf) elements in a tree by the
On 25 March 2004 09:06, MR K P SCHUPKE wrote:
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
The code is a small modification of mine to the attribute-grammar-like
(multi-pass lazy) example with recursive IO at
http://www.cse.ogi.edu/PacSoft/projects/rmb/repMin.html
The original code replaces every (leaf) elements in a tree by the minimum
of them all, returning the new tree, while
...
./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/
Ben
___
Glasgow-haskell-bugs mailing
On Friday 02 April 2004 22:01, Benjamin Franksen wrote:
This is the program:
import Control.Concurrent
[...]
I should have said that this happens on a SuSE 7.3, i386 architecture (AMD K7)
and that i compiled ghc6.2.1 from sources (because all the binary packages
assume a newer version of
)
Linking ...
./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
601 - 700 of 1266 matches
Mail list logo
