If I load ratio and type 2^3%5 into Hugs I get 8 % 5 as
I'd expect.
If I do the same for ghci, I get an error message, because
it's parsed it as 2^(3%5). Prelude Ratio ought to have
infixl 7 %
(or maybe it should be in GHC.Real), but I can't find it (in either)
Fixed, thanks.
In local.glasgow-haskell-bugs, you wrote:
I think it should be:
killThread tid = throwTo tid (AsyncException ThreadKilled)
Yes, that's right.
I just noticed that 'killThread' in fact isn't implemented by
means of 'throwTo', but uses the 'killThread#' primop...wouldn't
it be
This can arise if you do one of the operations threadWaitRead or
threadWaitWrite on a file descriptor that is closed.
Sigbjorn recently
modified the select() code so that it wouldn't fail in such
an ugly way;
now it just wakes up all the threads that were doing select() in the
I have a program that is suffering a select() failure. It prints:
9
select: Bad file descriptor
Fed: fatal error: select failed
From looking at some RTS sources, the 9 apparently represents
errno EBADF
(bad file descriptor). Does that mean that my program is
somehow closing
one
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 fixed, and
I had to kill ghci-5.02 for the following expression and
ghci-5.04 is not
much better:
~/source/gtk2hs/gtk:$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.02.2,
for Haskell
98.
/ /_\\/ __ / /___| |
ghc-pkg has become a lot pickier about directories and files
which are not
there (which is probably the Right Thing, except that it
becomes annoying when using things like pkg-config gtk+-2.0 --cflags
--libs).
However, if I add a package that depends on, say, data to a
local
I had thought of having the signal handler reap as many
terminated child
processes as possible, but had been concerned about a possible race
condition. After you suggested that approach, I thought some more and
decided that no race problem should exist. So I've
implemented multiple
I then upgraded my version to
5.02.3 and now ObjectIO doesn't work anywhere anymore. The linker
complains in literally thousands of errors like the ones shown below.
This is a shame because we did like the ObjectIO library. Ah, my
colleague has just installed 5.02.1 and now it works on his
The fine points of Unix signal semantics have always been somewhat
mysterious to me. However, after digging around in man pages
for a while,
I have a theory as to what's going wrong...
Yes, your diagnosis looks very plausible.
The right way, I believe, to handle this in your signal
I have some GHC-compiled programs that run OK under Sparc/Solaris but
hang under x86/Linux. I'm using GHC 5.02.3 on both systems (although
I've tried GHC 5.03.20020410 on Linux with the same failures). I'm
debugging to narrow the problem down. My current suspicion is that
closing the
After much study I have a new theory. It appears that the
pipe machinery
is working fine, but that sometimes my program fails to
reap all of its
terminated child processes. I'm using a `sigCHLD` signal handler that
does `getAnyProcessStatus True False` each time it's invoked.
It
Exploring the idea that the problem might be some bugs in GreenCard
which have been fixed recently, I tried compiling an up to date
version of the Win32 library - which brings me to my reports of
apparent non-conformance of GHC to the ffi (release candidate 4) spec.
Yes, GHC 5.02 predates a
Send us improved testsuites and we'll happily add them to our suites.
The most relevant Hugs testsuites are:
intTest.{hs,input,output}
This one appears to have a common ancestry with arith011 in
fptools/testsuite/tests/ghc-regress/numeric/should_run. However
arith011 has grown a bit
ghci does not find GHC.Prim, but ghc does:
::
A.lhs
::
module A
where
import GHC.Prim
a# i# j# = i# +# j#
ralf/tmp ghc -c -fglasgow-exts A.lhs
ralf/tmp ghci -fglasgow-exts A.lhs
___ ___ _
/ _ \ /\ /\/ __(_)
/
After a looking a little more, there seem to be other problems
(including errors in my proposed solution). I don't know where the
code for quotRem is, but it is also buggy. For instance,
Prelude 9 `quotRem` (-5)
(-1,4)
(The correct answer is (-1,-4).) I'm frankly astonished: has
GHC (5.03.20020410) wrongly accepts the following:
::
C.lhs
::
module C
where
class A a where
a :: a - Int
::
X.lhs
::
module X
where
import qualified C
instance C.A Int where
C.a = id
This has been fixed, and
I'm shocked that non of the three Haskell implementations had a test
suite that caught this problem.
Take a look at
fptools/testsuite/tests/ghc-regress/numeric/should_run/arith0011.hs.
There may be one or two wrong answers lurking in there, but
that's a lot
of results to check by
And try tweaking the GC options to keep the residency down (preferably
within the limits of real memory on your machine). Use '+RTS -c' to
enable the compacting collector, and possibly use a -M switch to set the
maximum heap size to the amount of real memory - unless you need more
than that, of
Hi,
I'm trying to compile the latest version of GHC (snarfed from
CVS today),
and I got the following errors:
../../ghc/compiler/ghc-inplace -ldl -fglasgow-exts -cpp
-Iinclude -funbox-strict-fields -package-name base -O
-Rghc-timing -spli\t-objs-c GHC/IOBase.lhs -o GHC/IOBase.o
The documentation URL:
http://www.haskell.org/ghc/docs/latest/set/finitemap.html
doesn't say whether fmToList et al are /defined/ to return a
list in Ord order of the keys.
I think it should.
Agreed. The docs for this library are now in Haddock format in the
source itself: see
7.2. Binary Dependencies - `Depends', `Recommends', `Suggests',
`Enhances', `Pre-Depends'
--
--
[...]
The meaning of the five dependency fields is as follows:
`Depends'
[...]
The
I have tried installing the binary package of
GHC 5.02.3 for solaris.
we do have libcurses.so.1 installed but in some other directory than
/usr/lib. The ghc complaint that the libcurses cannot be found.
You probably need to set LD_LIBRARY_PATH to point to the location of
libncurses.so (you
maybe you need to rebuild the compiler you are compiling *with*?
That's exactly what I'm trying to do with the latest CVS
Head, so I assume
you mean to try switching back to the Glasgow team's 5.02 or
5.03 releases
to build. As the compiler I am using was built with the GHC team 5.03
Simon Marlow wrote:
George Russell wrote:
[snip]
Personally I suspect multi-parameter type-classes
[snip]
I've changed my mind and now think it's because GHC was upset
it couldn't find the
.hi file for GUIValue.hs in a directory on the import list.
(Of course
in our (latest) installation (ghc-5.02.3 on solaris) the module Pretty
(from the package text) did not export Style-related
functions due to an
(old/wrong) interface file ../imports/text/Pretty.hi (with
size 10909).
When translating Pretty.lhs ourselves it seems to work correctly (and
compiling the example ModuleTest.hs from the
Gtk+HS distribution produces the following
error message:
84 ghc `gtkhs-config --cflags --libs` ModuleTest.hs
ghc-5.02.3: panic! (the `impossible' happened, GHC version 5.02.3):
AbsCStixGen.gencode typedef void ( *_ccall_fun_tys1ku)
I think this is a bug in ghc 5.03 (whatever is in the CVS).
Please excuse me if I'm wrong.
file:ghc/rts/Stable.c
symptom: seg faults sometimes (tricky to reproduce, but occurs when
you have more than one live stable pointer to the same value,
and a bunch of other
Wolfgang Thaller wrote:
[...] Can anyone with sparc experience think of a reason
why cache flushing
should _not_ be necessary here?
Synchronizing the data/instruction caches *and* the caches of
different
processors (most people forget the latter) is necessary for
both PowerPC
I'm using memoized copying functions to maximize sharing in a
tree/dag. It works under Hugs but not GHCi 5.03 on Windows
XP. I'm stuck here and so would sure appreciate some help.
I've attached a simple demo module with examples that
illustrate the problem.
There are some differences
Sounds bad. I'm getting it under ghc-5.03.20020208 on WinXP.
My program uses stable names but is otherwise fairly tame.
Any pointers on what this message means and what causes
it? - Conal
It indicates a bug, possibly related to garbage collection. Could you
send us the
The INSTALL file of the GHC 5.02.2 Linux Binary Dist contains a note
that the compiler has been linked against Readline 3 and that this
might cause problems on newer Linux distributions, which use
Readline 4.
Let me first remark that the same problem occurs with NCurses: GHC ist
linked
I should have followed your suggestion to to rebuild gcc for
Solaris 2.7
right away. After rebuilding gcc, the source build and
install of 5.02.2 had no problems.
It looks from your earlier message as if Perl was dumping core when
running the script ghc-split.prl. The rebuilt gcc might
Conal,
Could you remind us what you're using unsafePtrEq for? Perhaps there's
another way to do what you want, or we could maybe reinstate
unsafePtrEq.
Cheers,
Simon
-Original Message-
From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]]
Sent: 17 April 2002 04:09
To: Conal
ghci doesn't seem to be picking up the .ghci settings in the
current directory, though it does in my $HOME directory. I'm
using 5.03 under Windows XP. Is this known behavior?
Looking at the code, there appears to be a bug in the Windows
implementation of .ghci file loading that would
Sounds bad. I'm getting it under ghc-5.03.20020208 on WinXP.
My program uses stable names but is otherwise fairly tame.
Any pointers on what this message means and what causes it? - Conal
It indicates a bug, possibly related to garbage collection. Could you
send us the code?
I've just finished building 5.02.3 on sparc-solaris, and
didn't get any
core dumps, so there must be something different about your
setup. What
version of
gcc are you using? What version of GHC are you bootstrapping with?
$ gcc -v
Reading specs from
the following instance declaration doesn't work any
more with ghc-5.02.3, it worked before.
newtype ST state a = ST { unST :: state - (a,state) }
instance Monad (ST c) where
return x = ST (\state - (x,state))
(m = f) = ST (\state - let (x,state1) = unST m state
[Everything on Linux-x86]
Maybe you're heading in the wrong direction:
stolz@kastor:~/test/resources $HC5 --make -fglasgow-exts *.hs
ghc-5.03: chasing modules from: Colour.hs,GUIValue.hs
Compiling GUIValue ( GUIValue.hs, ./GUIValue.o )
Compiling Colour ( Colour.hs,
If I do the following ...
I think these bugs (the illegal -x option to ld, and the messed up
installation directories) were fixed in 5.02.2. Could you try building
that version instead?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
The binary package of ghc-5.02.2 for sparc-sun-solaris2.7
seems to have
a small problem on my Solaris 2.6 machine. The compiler works fine
on most source modules, but it has trouble with one using the FFI.
A previous version of the compiler (4.08.2) worked fine on the same
module, and
I think it is probably due to the ancient version 2.7.2 of gcc we
have by default on Solaris 2.6 here. The sigset_t type is guarded
by #ifdefs as follows:
#if defined(__EXTENSIONS__) || (__STDC__ - 0 == 0) || \
defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) || \
I don't think mmap() provides exactly the right behaviour.
It lets you
specify that modifications made by the current process
aren't committed
to the file, but what we want is to snapshot the file so
that subsequent
modifications by *other* processes aren't seen by the local
On Mon, 2002-03-18 at 18:30, Simon Marlow wrote:
The spec could perhaps *require* that it was a pure value,
so that the
file contents is snapshotted at the time of the hGetContents and you
always get the same result regardless of subsequent or
concurrent I/O
operations. This can
* When we fork(), we lose sharing. *Any* lazy computation which
passes to both children is going to penalize you, sometimes in very
surprising ways.
I'm not sure I understand why loss of sharing is the problem - losing
sharing for pure computations is by no means a disaster, it just
We're groping around in the dark here
Sorry, yes we are. It is a bit cheeky of me to always punt and say
I'll bet it is a GHC problem when I haven't even seen the bug myself
on a machine whose configuration I know. Sorry about that.
No problem :)
In fact, it turns out that you've
On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin
immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
Yes, it's a NOP (just to be sure). The difference is in child.hs:
callIO (\ps - Kommando fehlgeschlagen mit ++ show ps
++ :\n ++ kommando prog par)
(executeFile' prog True par Nothing)
-- instead, to avoid bug:
-- (hClose stdin executeFile' prog True
In local.glasgow-haskell-bugs, you wrote:
I've stripped down my program to produce an example. In the
process, the
problem disappeard a few times. I hope it shows up on your
machine. The
attached files reproduce it on my machine, but the exact
results vary
from run to run.
[ redirected to [EMAIL PROTECTED] ]
Good day everyone, I was fiddling around with this tiny echo
client/server haskell program from 'The Great Language Shootout'
site (http://www.bagley.org/~doug/shootout/) and got stuck.
The code (attached) has been reformatted with minimal API tweak
When I compile a HEAD version from this morning with GHC
5.02.2, there is
a deprecated warning for the use of 'tryAllIO' by
compiler/rename/RnHiFiles.lhs.
But when I compile it with a HEAD version, it gives an error
and says that
Exception doesn't export 'tryAllIO' any more. When I
It seems to me that the -i command line argument is ignored when used
together with --make. GHC reports that the modules can't be found.
Is there any way to use a library (lib*.a + *.hi files) that
is not compiled
as a package with ghc --make?
Not at the moment, no. If you have a library
Ah no, I've changed my mind. This is problematic. You
probably weren't hitting the right bit of code in your tests
to show up the problem.
In -monly-3-regs, the mangler must insert code to re-load
the contents of %edi before doing a jump, and if the jump
involves %edi itself then
I had a Pretty.hs from the CTK, a version that comes with
hugs and the ghc
text package one. I was including the CTK directory and that
version was being
used in preference to the text package one.
This I presume is the intended behaviour.
The other thing that bit me was that I
I'm running in to a problem using ghc -M to generate
dependencies when
there are embedded spaces in the path name to a dependency.
If I run ghc -M using something like:
$ ghc -M -optdep-f -optdep.hs_dependences
-iC:/Program Files/GreenCard/lib/ghc JNI.hs
it correctly
I commented out this block at line 1312:
#if ($StolenX86Regs = 3 ) { # spurious uses of edi?
# s/^\tmovl\s+(.*),\s*\%edi\n\tjmp\s+\*%edi\n/\tmovl
$1,\%eax\n\tjmp
\*\%e
ax\n/g;
# s/^\tjmp\s+\*(-?\d*\(.*\%edi.*\))\n/\tmovl $1,\%eax\n\tjmp
\*\%eax\n/g;
#
There is a difference between hugs and ghc in how they treat
imports with the
'(..)' notation. Here's my example:
module CTree(
--other stuff
Const(..)
) where
import ATree (Const)
--const has constructors CInt, CChar, CStr
under hugs this module exports CInt,
used to read -H14m ... (might make the faster, especially on
large...)
fixed to -H14m ... (might make the compilation faster,
especially...)
Fixed; thanks.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
What does it mean when you get the fatal error PAP_Entry:
CATCH_FRAME. I
am using ghc version 5.03.20020204. I looked in the ghc
source code and the
comment next to this error message says that it cannot happen.
Well, you must be imagining it then :-)
Seriously, I've seen this error too.
I'll just add that we added a test to the configure script to check whether the local
ld supports -x after the 5.02 tree was branched, and it looks like it got overlooked
in the merge, sorry about that.
To work around the problem, you can either just remove the -x's from invocations of ld
in
On a slightly related topic: I was a bit surprised to notice that
5.02.2 appears to produce binaries that are incompatible with 5.02.1,
given that it was only a minor version number change. It's
not a huge
deal (since this at least produced link errors), but it was a bit
surprising.
Certainly.
We've just spent lots of time trying to get this stuff to be utterly
painless to compile, so please let us know if the instructions below
give you any trouble.
The problem is that you didn't compile the whole program with -prof: the
BareBonesArrows library was compiled the
I tried this under Linux (debian, using ghc 5.02.2). It compiled OK,
but produced an executable that dumped core immediately on
startup. :-(
For what it's worth, here is as much info. as I could glean from gdb:
Starting program: /home/frp/afrp/src/testST
Program received signal
According to the GHC libraries manual, 6.2.1: The Handle
returned by connectTo and
accept is unbuffered by default. However, with such a
handle and hPutStrLn,
I am getting buffering, even when use IO.hSetBuffering to
NoBuffering. When I
put in an explicit hFlush after the
I realize that my use of the API was incredibly naïve and
that I should
have been using h* methods with the handle returned from
connectTo. But
it is connectTo that is failing as described.
It fails interactively too with ghci, and regardless of using Server
http or PortNumber 80.
--with-hc only configures what's used to compile 'generic' Haskell
code (i.e., not the contens of ghc/compiler). (As Simon suggests),
use --with-ghc to control what GHC to to use to compile the
compiler bits, i.e.,
./configure --with-ghc=/usr/local/bin/ghc-5.02.2 \
Dear ghc-5.02.2 (linux-i386-unknown, binary snapshot for libc-2.1),
For the program main = putStr $ show $ (2+3 :: Int)
ghc --make Main
`makes' it all right.
And ghci -package docon Main
also works.
docon is my user package, with
On Thu, Jan 03, 2002 at 05:27:43PM -, Simon Marlow wrote:
'(' exp(i+1) op(a,i) ')'
'(' op(a,i) exp(i+1) ')'
'(' lexp(i) op(l,i) ')'
'(' op(r,i) rexp(i) ')'
And for the sake of fewer ambiguities, replace each op(a,i)
with op(n,i)
in the existing two
This program:
module Main where
f = map (++a++b)
g = map (a++b++)
main = do print (f [x,y,z])
print (g [x,y,z])
gives the following error messages with ghc (versions 4.08.2
and 5.02):
plusplus.hs:3:
The operator `++' [infixr 5] of a
With the module
data Foo = Foo {}
ghc tells me
tt.lhs:2: parse error on input `}'
while the report allows this.
Fixed; thanks.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
HsParser miscalculates column-positions if qualified names are used.
The problem seems to be the lexer forgetting to count the '.' in the
qualified name when deciding how much to move forward. In this
function, for instance,
f M.A M.B M.C = 0
^
HsParser reports that
Hi GHC people,
I think there is a bug in hslibs/hssource/HsLexer.lhs
For the following code:
foo = 1 Prelude.: []
The lexer mistakes the qualified constructor Prelude.: as a
variable.
The problem is due to the use of the variable 'c' instead of the
variable 'c1' on line 290
Given a file test of size 2342.
The program Bug.hs behaves correctly (the result is
(2048,384)), but when uncommenting the seemingly innocent
line, the program behaves incorrectly (result is
(2048,2048)), and the buffer is filled with garbage.
main =
do han - openFile test ReadMode
I have a very basic (and naive, probably) question:
What does one use to unpack a *.bz2 file?
I tried to find this information in the on-line installation
guide, but
could not find it. Might be a good idea to put it there.
A quick response would be much appreciated.
bzip2:
While trying to compile qforeign cvs with ghc-5.02.1, I get
the following error.
/usr/bin/ghc -c -O -Wall -fglasgow-exts -package lang
-package data -package concurrent -package posix -iexamples
-ilib -Iexamples -Ilib examples/Libgr_hsc.c
programs/hsc2hs-inplace --cc=/usr/bin/ghc
If `installHandler' is called more than a few times in a row, the
run-time system terminates with an error message.
The program:
main =
sequence_ $
replicate 33 $
installHandler sigINT (Catch (return ())) Nothing
The shell output:
%
A small program (which I haven't been able to strip down to a
minimal *failing* version ;) repeatedly opens sockets and does the
following (I tested with all permutations of hSetBuffering):
Socket.connectTo ...
hPutStrLn h Data
hPutStr h d
debug Io Reading..:
c - hGetContents
Am 14. Nov 2001 um 12:46 MET schrieb Simon Marlow:
Thanks, but I think I've fixed this now. If you have a
local GHC build,
could you try out the patch included and let me know if it
fixed things?
Looks like it works. Does your previous comment about filehandles not
being closed
Using ghc-5.03, getArgs only returns the first command line argument.
main = do putStrLn version
args - getArgs
putStrLn (show args)
...
I can't repeat this bug - it works for me with last night's sources both
in batch mode and in GHCi.
Cheers,
HsParser does not allow method declarations to follow a default
implementation of a method.
class G a where
f :: a - a
f x = x
g :: a - a
Optional semicolons or empty statements are not permitted in
do-expressions.
f x = do ;; x ;
That is probably
I really like your work and personally I do not have to complain,
but ghc urges me to report it as a compiler bug:
ghc-c -o LinkBase.o LinkBase.hs
panic! (the `impossible' happened):
Oversize heap check detected. Please try compiling with -O.
Please report it as a
The setting of 'libdir' in mk/config.mk in the ghc source
is infelicitous. It
is set using both '=' and ':=' - AFAIK this combination,
besides being bad
practice, does not have a defined meaning.
Thanks, I've fixed this.
Cheers,
Simon
Yuck. If this isn't enough to convince people that hsc2hs is not
an appropriate tool (at least in the context of the Prelude
and hslibs/), than I don't know what is.
It commits to a particular platform at too early a stage -- details
of C header files are often best left toC source
So, bringing back the solution of having manually written C wrapper
functions which platform-independent Haskell source files will call
out to, would be preferable (in short, avoid the use of hsc2hs *or
any other extra tool* alltogether). I'm willing to make the
necessary changes.
Simon Marlow [EMAIL PROTECTED] writes:
Having just looked at the code, it seems we could recover the
platform-independentness in the I/O library with just a
small amount of
wrapperage: most of the offending code is in PrelPosix.hsc,
with a few
#const's scattered around PrelHandle
I'm not sure this is a bug, or merely an undocumented feature. :-)
Anyway, putStr in GHC has different buffer semantics than
putStr in Hugs.
stdout/stderr are line-bufferred in 5.02. We've changed them to be
unbuffered for 5.02.1.
Cheers,
Simon
I later ran into another problem that may or may not be
related with the
first. This is the program I am running:
module Main where
import Posix
main = do
installHandler sigCONT (Catch (putStrLn - resumed
-)) Nothing
forever $ do
c -
I discovered two bugs in GHCi. I am using GHC5.02 on
Linux.
The first bug has been there for some time now. If I start
GHCi with a module `A.hs', which either does not exist
itself, or which includes modules that not exist, then GHCi
terminates with an error message. This is rather
When interrupting this program, the signal handler does not
get called:
module Main where
import Posix
main = do
installHandler 2 (Catch (putStrLn Hello, world!)) Nothing
sleep 600
-- putStr
Try using Concurrent.threadDelay instead of
I discovered a minor cosmetic bug today. After my
undescribable hapiness about the fact that GHCi now has the
:i command, I started playing around, and discovered the
following ugly output:
Prelude :i []
-- [] is a data constructor
[] :: forall t_12. [t_12]
Thanks, I've fixed
Hi, I got the following error message:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.02, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package std ... linking
Doh, I have several times got further than I thought but
didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem, anyway - I don't suppose it could
be caused by
the hc files being generated under a different OS with different magic
numbers could
On Mon, Oct 29, 2001 at 02:08:23PM -, Simon Marlow wrote:
This appears to be because the dummy Handle opened in
WriteMode is being
garbage collected and closed, which leaves the FIFO with no
writers so
you get EOF. 5.02 is behaving correctly here. You can add an extra
'hClose
Hello. Just a nasty build bug with 5.02 that I encountered.
When building the prelude library, the individual object files are
turned to an archive with xargs ar q libHSstd.a. Now, for
some reason,
on this system, GNU ar fails at some point during this process. The
standard solaris ar
And note that no compiler/interpreter currently rejects a string
containing a literal tab character.
My working version of GHC does :-)
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
module Test where
chars =
foo
bar
this line is in error and it is line 7
ghc test.lhs
test.lhs:5: parse error on input `in'
It turns out that in the script I am writing
(semi-automatic generation of a grammar file)
being able to use the above notation for multilined
I've attached a diff of the changes I've made so far - they
are changes
to make it work rather than the correct way to fix it, though.
Thanks. I've fixed the 'ld -x' problem. You also appear to need an
extra -L path to find the readline library - we don't have proper
provision for this at
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, GameFrontEnd.o )
ghc-5.00.2: panic! (the
I am trying to build GHC 5.02 on an x86 Solaris machine (with
the x86 HC
stuff) and I am getting this error:
gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop
-fomit-frame-pointer -DDONT_WANT_WIN32_DLL_SUPPORT
-D__GLASGOW_HASKELL__=502 -O
501 - 600 of 1053 matches
Mail list logo
