Good plan!
Ian Lynagh i...@well-typed.com:
Hi all,
Following a recent discussion, we propose to reorganise the GHC-related
mailing lists so that we end up with:
glasgow-haskell-users
For user discussions
ghc-devs
For developer discussions
ghc-commits
Ashley Yakeley:
On Mon, 2009-09-14 at 00:40 +1000, Manuel M T Chakravarty wrote:
I don't see what the problem is. instance C (Fam Int) has an
unambiguous, and logically acceptable, meaning to the compiler. Why
do we force the programmer to make an ugly workaround involving
introducing a type
Ashley Yakeley:
GHC wrote:
#3485: Illegal type synonym family application in instance error
is unnecessary,
should be removed
-
+--
Reporter: Ashley Yakeley |
Owner: Type: bug
David Waern:
2008/7/13 GHC [EMAIL PROTECTED]:
#2436: Bad warning when exporting data families
-
+--
Reporter: rl|Owner: chak
Type: bug | Status: new
Priority: normal|
Stefan Holdermans:
Peter,
I've run into a bug that looks to be the same as the one described
here:
http://hackage.haskell.org/trac/ghc/ticket/1897
It does not seem like a bug, although the type-error message may be
a bit confusing as is the fact that GHC happily infers a type for
the
Peter Gavin:
The problem seems to be that ranlib isn't being run from the cabal-
generated makefiles after each libHS.a under libraries/ is built. At
some point the build fails when trying to link to libHShaskell98.a,
complaining about a missing index, so I ran ranlib on the library,
and
Simon Marlow wrote,
GHC wrote:
#1738: GADT3 test failure
-+--
Reporter: simonmar |Owner: Type:
bug | Status: closed Priority: normal|
Milestone: 6.10
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
Simon Marlow [EMAIL PROTECTED] wrote,
With the attached file, on both Linux and Solaris, I get the following
Cut here ---
# ghci --interactive
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.04.1,
for Haskell 98.
/
Jimmy Ng [EMAIL PROTECTED] wrote,
bash-2.03$ ghc --make Main.hs -o game
ghc-5.00.2: chasing modules from: Main.hs
Compiling GameWorld( GameWorld.hs, GameWorld.o )
Compiling GameMessages ( GameMessages.hs, GameMessages.o )
Compiling GameFrontEnd ( GameFrontEnd.hs,
Koen Claessen [EMAIL PROTECTED] wrote,
When I load tha Yahu package [1] in GHCi 5.02 on a SParc
running Solaris, I get the following message:
scooter bin/yahu.new Resources/YahuNew/Examples/Balls.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive,
Rahul Bhargava [EMAIL PROTECTED] wrote,
The unsafeIOToST definition in the ghc-5.00.2 libs doesn't appear to
achieve the following,
unsafeIOToST :: IO a - ST s a
unsafeIOToST (IO io) = ST $ \ s - (unsafeCoerce# io) s
I have already changed that after Gabi told me about the
problem you
William Chesters [EMAIL PROTECTED] wrote,
Simon Marlow writes:
Hi William,
It's not your day, is it? :) You seem to have tripped over just about
all the nasty bugs in 5.00.
Think so, but Ralf Hinze helped me out by sending me RPMs he's made
for SuSE 7.1, from Manuel's SRPM
Thomas Hallock [EMAIL PROTECTED] wrote,
I get these crazy link errors whenever ghc tried to
link its object files:
[localhost:Documents/minimax/hs] root# ghc simple.hs
/usr/bin/ld: Undefined symbols:
_Main_main_closure
___init_Main
__udivdi3
__umoddi3
__cmpdi2
__fixunsdfdi
Armin Groesslinger [EMAIL PROTECTED] wrote,
---
module Main where
import CForeign
foreign import puts puts :: CString - IO ()
main :: IO ()
main = return ()
---
to ghci-5.00 (with ghci -package lang -fglasgow-exts Main.hs
on x86/Linux)
"Jeffrey R. Lewis" [EMAIL PROTECTED] wrote,
"Manuel M. T. Chakravarty" wrote:
"Jeffrey R. Lewis" [EMAIL PROTECTED] wrote,
Lack of consensus = the status quo stays.
My order of preference:
1. [happy]. Use 'let'
2. [consent]. Use 'dlet
Jeffrey R. Lewis [EMAIL PROTECTED] wrote,
Lack of consensus = the status quo stays.
My order of preference:
1. [happy]. Use 'let'
2. [consent]. Use 'dlet' or 'with'
3. [hate] Use both 'dlet' and 'with'
Would the Hugs folk be willing to adopt (2)?
That would certainly be
"Manuel M. T. Chakravarty" [EMAIL PROTECTED] wrote,
I am just building rpms as we speak and have attached the
revised .spec file below (which also evades the two
mentioned bugs).
The file still had a bug (more precisely, something else
changed in the GHC's makefiles, which I had
to have disappeared
since the 5.00 release. I think, I am going to resurrect it
as part of the GHC Commentary.
Cheers,
Manuel
# RPM spec file for GHC
#
# Copyright [1998..2000] Manuel M. T. Chakravarty [EMAIL PROTECTED]
# Thanks to Zoltan Vorosbaranyi [EMAIL PROTECTED] for suggestions in
"Simon Marlow" [EMAIL PROTECTED] wrote,
Thanks, the debugging hints helped a lot (which tutorial did I miss
this time? :)
No tutorials, but it has been posted a couple of times on the GHC lists.
The material should really go in the GHC commentary
Tim Sauerwein [EMAIL PROTECTED] wrote,
[..]
panic! (the `impossible' happened):
tcLookupGlobalValue: THIS.PrelIOBase.returnIO{-0B,s-}
The problem seems neither to appear in the CVS HEAD (4.11)
nor in the forthcoming 4.08.2 release.
So, you may either want to wait for the release of 4.08.2
Keith Wansbrough [EMAIL PROTECTED] wrote,
Just downloaded
http://www.haskell.org/ghc/dist/4.08.1/ghc-4.08.1-i386-unknown-linux.t
ar.gz
did configure, make, make install-docs. The latter yields an error:
astrocyte:ghc-4.08.1$ make install-docs
./mkdirhier
Hi!
GHC doesn't spot link-time conflicts between explicitly
given .o files and modules contained in packages. For
example, if we compile the module
module Main (main)
where
import Pretty
main :: IO ()
main = putStr (render (nest 2 (text "text")))
with `ghc -c -package text
It seems, as if I have the questionable pleasure of
reporting the first bug in GHC 4.08: The NCG passes floats
as doubles in foreign exports.
If the appended code is compiled with the NCG (ie, without
optimisation), the programs prints 0.0 instead of 101.0. If
the C code is changed to use
Sigbjorn Finne [EMAIL PROTECTED] wrote,
-Original Message-
From: Sven Kuenzler [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 08:13
To: Sigbjorn Finne
Cc: Christoph Lueth
Subject: Re: Sigbjorn Finne: RE: H/Direct Contact
I am one of Christophs students who a
Mark Utting [EMAIL PROTECTED] wrote,
Summary: I'm trying to build GHC, but cannot find fptools/ghc/configure
[..]
But upon reading the Makefile, I found I could generate ./configure by:
make -f Makefile.config ./configure
Done.
But then ./configure stops with:
Simon Marlow [EMAIL PROTECTED] wrote,
An inefficient solution is to fork a process that will block
and then feed
us through a pipe. Probably too bad to make it built-in, but at least
should work if somebody desperately needs the functionality.
I would be surprised if POSIX
`make maintainer-clean' goes into an endless loop. `make
veryclean' dies in
`/home/chak/fptools/glafp-utils/mkdependC' and many of the
targets documented in `fpools/mk/target.mk' do not exist
anymore.
[This is from CVS, checked out just now.]
Manuel
I am not sure whether that issues was discussed already, but
I just noticed that when a module containing foreign import
declarations is compiled with -O, it may bring some of its
`__ccall's into the .hi file for inlining purposes. As, for
example, in the following excerpt of one of my .hi
We are just trying to get GHC 4.x running on
`i386-unknown-solaris2'. The first problem seems to be that
gcc uses the Solaris assembler on our machines, which
doesn't grok the assembly GHC feeds it. Does GHC need `gas'
on all platforms? If so, we would add a corresponding test
to `configure'.
Sven Panne [EMAIL PROTECTED] wrote,
Simon Marlow wrote:
If you can #include the header file into the Haskell source, then
you can get away without litlits.
Of course, in the general (and in the OpenGL/GLUT) case you can't.
If your header file contains extra gumph like prototypes and
Simon Marlow [EMAIL PROTECTED] wrote,
We currently have read and index for 9 different types (Char, Int, Word,
Addr, Float, Double, StablePtr, Int64, Word64). I suppose you could get
away with
{read,write,index}{Int8,Int32,Int64}OffAddr
and do type casts to get the rest.
[EMAIL PROTECTED] wrote,
Me:
However, it is definitely wrong for 'foreign' to be treated as a
keyword. Instead, it is a special identifier
Simon:
Tricky, at least in LALR(1).
Yes, you are right of course. Backtracking parser combinators had me
blinded to the sad realities of
Simon Marlow [EMAIL PROTECTED] wrote,
Simon Marlow [EMAIL PROTECTED] wrote,
for future distributions, I'll switch back to supplying our own
statically-linked libgmp.a for Linux, I think.
This is not required for package-manager managed binaries
for systems that have a package
Simon Marlow [EMAIL PROTECTED] wrote,
I think there is still a problem with non-blocking I/O
hosing some shells on abnormal program termination. This is
on Linux, using bash and the latest sources from CVS.
Yep, you're probably right. I think I'm going to back off on this one and
Sven Panne [EMAIL PROTECTED] wrote,
It works if the two spaces after -#include are replaced by a single
space, but the "real" Haskell sources are created by Green Card, so
I can't change that easily.
Come one, Sven, this is an _absolutely_ lame excuse: if you
are running cpp over your
Ian Jackson [EMAIL PROTECTED] wrote,
I wrote:
I have a program (no doubt pretty grotty - I'm still messing around
learning Haskell) which causes GHC (4.04.19990916) to produce an
executable which coredumps.
...
I'm using a GHC binary package from Debian GNU/Linux, binary package
Simon Marlow [EMAIL PROTECTED] wrote,
for future distributions, I'll switch back to supplying our own
statically-linked libgmp.a for Linux, I think.
This is not required for package-manager managed binaries
for systems that have a package containing `libgmp.so' (like
RedHat, but not SuSE).
Mark Utting [EMAIL PROTECTED] wrote,
Manuel,
You wrote:
/usr/bin/ld: cannot open -lgmp: No such file or directory
(RedHat 6.1 has libgmp.so.2*, but not libgmp.a -- you have to
install the gmp-devel*.rpm package to get libgmp.a).
In fact, it is not necessary to
I have a problem with interface files generated for modules
that make use of existential quantification when compiling
with -O. This is - again - Linux with latest ghc sources
from cvs. When compiling a module that _imports_ these
interface files, I get messages, such as,
Main.hs:1: Failed
I compiled up the attached set of files using Tuesday's cvs ghc. It's
compiled with -prof -auto-all -caf-all. It runs fine without heap profiling,
but core dumps with it. This was running on windows NT.
I just checked a profiling fix into CVS. There was a
variable not initialised, which on
Mark Utting [EMAIL PROTECTED] wrote,
I just installed GHC 4.04 patchlevel 1 from Manuel Chakravarty's
binary RPM package: ghc-4.04-3.i386.rpm, under RedHat Linux 6.1
Installation went perfectly!
I have some questions and comments and possible errors.
1. I got the usual error when
Armin Größlinger [EMAIL PROTECTED] wrote,
I've been trying literally a dozen times to build a GHC from CVS, but
have not yet succeeded. The problem is to find a "right" compiler which
runs on my SuSE 6.2 system *and* compiles the sources. I won't go into
the very sad and depressing
Meurig Sage [EMAIL PROTECTED] wrote,
I got round yesterday's compilation problem (panic on interface file), by
compiling the module Widgets.lhs without -O.
The demo program now compiles.
It runs normally and will happily give a time profile.
./demos +RTS -pT
However, when run with heap
Simon Peyton-Jones [EMAIL PROTECTED] wrote,
Ah, but that was with my editor's hat on!
Somehow I forgot to apply the change to GHC.
Thanks; it'll be in 4.04 patchlevel 1.
Thanks, but please note that GHC misses both `enumFromThen'
and `enumFrom'. Only the former was missing in the
GHC 4.04 thinks that
data MyEnum = ATag
instance Enum MyEnum where
fromEnum ATag = 42
toEnum 42 = ATag
justifies these warnings
Main.hs:3:
Warning: No explicit method nor default method for `enumFrom'
in an instance declaration for `Enum'
Main.hs:3:
For
foo = let
x = (1, 2
y = 3
in
fst x + y
GHC 4.04 gives me
Main.hs:3: parse error on input `'
Interesting, but not very informative ;-)
I also have the feeling that GHC is sometimes off by a
couple of lines when reporting errors in bigger modules -
Both GHC 4.04 and Hugs 98 agree on violating the Haskell 98
definition by including `fromInt' into `Num' and `toInt'
into `Integral'. GHC's `Prelude.lhs' says in the export list
Num((+), (-), (*), negate, abs, signum, fromInteger, fromInt{-glaExt-}),
[...]
Integral(quot, rem, div, mod,
"Jeffrey R. Lewis" [EMAIL PROTECTED] wrote,
Mark Utting wrote:
Simon wrote:
Can anyone help with this? Simon and Sigbjorn are both
on holiday, and I am wonderfully ignorant about such things.
John McCarten wrote:
I recently emailed you concerning the installation of GHC,
I
Michael Hobbs [EMAIL PROTECTED] wrote,
I wouldn't mind working on this, but I know very little about the SPARC
architecture, or the calling conventions. (I don't even know if the
stack grows up or down.) I took a look at the assembly output of gcc and
got an idea of what's going on, but I
Sven Panne [EMAIL PROTECTED] wrote,
[ Aaaargl, 2nd try: The ancient mailer at Glasgow didn't like my
MIME-attachment. :-( ]
Why does it care at all about attachments?
as I am still in the middle of compiling it. It seems as if - at
least for Linux - the heap size is too small for
I encountered a problem with existentially quantified type
variables (yes, they can really be useful ;-) when they
appear in a .hi file in GHC 4.01.
Taking the following module
module T (T)
where
data T = forall a. T a (a - Int)
which is imported by
import T
main = putStr "oops"
"Sigbjorn Finne (Intl Vendor)" [EMAIL PROTECTED] wrote,
Thanks for the report. Yep, the 4.01 code generator doesn't
generate correct code for _casm_GC_ expressions. This bug
was fixed some time ago (and will be included in 4.02)
It's available via the CVS repository should you depend
on
"Sigbjorn Finne (Intl Vendor)" [EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty writes:
...
Unfortunately, the implementation in GHC 4.01 is still a bit
buggy. Two bugs are reproduced by the following program
import Int (Int8, intToInt8, Int16, intToIn
"Manuel M. T. Chakravarty" [EMAIL PROTECTED] wrote,
"Sigbjorn Finne (Intl Vendor)" [EMAIL PROTECTED] wrote,
Thanks for the report. Yep, the 4.01 code generator doesn't
generate correct code for _casm_GC_ expressions. This bug
was fixed some time ago (and will be incl
"Sigbjorn Finne (Intl Vendor)" [EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes:
--(2) foreign import ccall "" "bar" bar :: IO Int64
this can be reduced to
foreign import "bar" bar ::
"Manuel M. T. Chakravarty" [EMAIL PROTECTED] wrote,
If I link
import Addr (Addr, nullAddr)
foreign import ccall "foo" foo :: Int - Addr - IO ()
main = foo (id 32) nullAddr
with
void foo (int x, char *y)
{
printf ("foo: x = %d; y = %xl\n&
Two more FFI bugs (maybe they have the same reason). If I
put
module Main
where
import Addr (Addr)
foreign export ccall dynamic mk :: (Addr - IO ()) - IO Addr
foo :: Addr - IO ()
foo _ = print "bla\n"
main = do
fooHdl - mk foo
return ()
into a file
If I link
import Addr (Addr, nullAddr)
foreign import ccall "foo" foo :: Int - Addr - IO ()
main = foo (id 32) nullAddr
with
void foo (int x, char *y)
{
printf ("foo: x = %d; y = %xl\n", x, (long) y);
}
I get
foo: x = 134516888; y = 0l
It is the combination of there
First of all, let me say that I like the new FFI (as
outlined in `A Primitive Foreign Function Interface') very
much :-) I really hope that this eventually makes it into
the Haskell standard - although, there are still some things
to smooth out.
Unfortunately, the implementation in GHC 4.01 is
Sven Panne [EMAIL PROTECTED] wrote,
Using the highly recommendable debugging tools ddd and Knockando (13yrs %-},
I was finally able to track down the problems with the 'foreign export ccall
dynamic' construct for constructing Haskell callbacks. The dynamically built
adjustor thunks for the
A while ago, I read that GHC is supposed to work with egcs.
However, GHC 3.02 doesn't work for me with egcs 1.1b. The
latter complaint about illegally spilled registers when
compiling some module with -fglasgow-exts, and an attempt to
compile 4.01 from source produced a compiler that couldn't
Simon Marlow [EMAIL PROTECTED] wrote,
Hi. I have just downloaded and installed (in-place)
ghc-4.01. I tried testing it by compiling the sample program
main = putStr "Hello, world!\n"
with
ghc -o hello Main.hs
This compiles without complaint (only an observation that
Ralf Comtesse [EMAIL PROTECTED] wrote,
I have problems using hdirect-current on my system. I have the
ghc-4.00 as an rpm-Distribution on a Debian Linux system and used alien
to install it.
Wenn I try to compile hdirect. 'make boot' and 'make' work fine but
'make lib' gives a
I like to report two bugs that are causing problems during
installation of GHC and Happy, but are *not* a problem in
the fptools, but rather in some other software used during
the install:
I. GHC seems to have problems with pgcc (Pentium gcc).
Situation: Trying to compile GHC 3.02 on
Sigbjorn Finne [EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes:
Thanks, Sigbjorn, the patch worked fine. However, I
immediately ran into another problem:
nomi chak 3 (~/haskell): ghc-4.00 -o hello_world hello_world.hs
ghc-4.00: module version unchanged
Sigbjorn Finne [EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty writes:
Strange...it compiled on my Linux box with the same
compilers. But, I get
nomi chak 13 (~/haskell): ghc-4.00 -o hello_world hello_world.hs
ghc-4.00: module version changed to 18; reason: usages changed
[EMAIL PROTECTED] wrote,
The following problem occurred while compiling GHC-4.00/2
on a Linux platform, using ghc-3.02(apr.14 version) and gcc2.7.2.3
Any idea what it means when the compiler can not find the suitable *.hi
file. It is physically there. Viewing PrelMaybe.hi shows no apparent
I hit some problems when trying to format the documentation
contained in the 4.00 source bundle -- however, I think,
this is not 4.00-specific. I am not sure whether this is a
bug or just a stupid-operator error.
I am working on a 2.0.33 Linux system that has the LinuxDoc
tools 1.5 and teTeX
From: [EMAIL PROTECTED] (Shin-Cheng Mu)
Compiling GHC 3.02 for i386 Linux, the make process stops
at the point when compiling ghc/lib/posix/PosixProcPrim.lhs.
The error message generated is attached below.
I tried the patch suggested by Carl R. Witty (I'm not sure
whether it was to my
70 matches
Mail list logo
