Alastair Reid [EMAIL PROTECTED] writes:
ghc-3.02 -c -o parser/hschooks.o -cpp -fglasgow-exts -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:ty
pecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:ab
Hi Si*o*n,
A couple of weeks I could build the current cvs snapshot using ghc-3.02
on my linux box (redhat 5.0?, gcc 2.7.2.3, linux 2.0.31) - now I'm
dead in the water:
ghc-3.02 -c -o parser/hschooks.o -cpp -fglasgow-exts -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser
Tim Hemel writes:
Hi,
It's me again. I found out I forgot a make boot before make all. You can ignore
my previous questions, as ghc seems to be building fine now. Uhh well, until
now:
==fptools== gmake all
Hi,
It's me again. I found out I forgot a make boot before make all. You can ignore
my previous questions, as ghc seems to be building fine now. Uhh well, until
now:
==fptools== gmake all --no-print-directory -r;
in
Hi,
Yesterday I have sent you a mail about cyclic compilation dependencies in
ghc-3.02. Right after I sent that mail I discovered how to fix it. I have
gotten a little further and discovered some errors.
First of all, line 230 of mk/config.mk.in should be changed to
GhcLibWays=
otherwise make
I'm trying to build pre-GHC-4.00/2 on Cygwin B19 with GHC-3.03.
I get the following error:
==fptools== make all --unix --no-print-directory -r;
in /install/ghc-pre-4.00.2/fptools/ghc/compiler
Alex Verbitsky [EMAIL PROTECTED] writes:
I'm trying to build pre-GHC-4.00/2 on Cygwin B19 with GHC-3.03.
I get the following error:
...
Glasgow Haskell Compiler, version3.03, for Haskell 1.4
PrimPacked.lhs:135: Data constructor not in scope: `ForeignObj'
PrimPacked.lhs:256: Data
Alastair Reid [EMAIL PROTECTED] writes:
ghc-3.02 -c -o parser/hschooks.o -cpp -fglasgow-exts -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:ty
pecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:ab
Simon Marlow wrote:
Tim Pollitt [EMAIL PROTECTED] writes:
"If the accumulating function is strict, then accumArray is strict in the
values, as well as the indices, in the association list. ..."
...
In fact, both stack and heap reqirements seem to be linear in the size of the
Hi Simon, This really seems to have touched off a firestorm! I think
the meta-argument made by Simon T (and by you) is sensible, so I don't
object to maintaining the status quo. But you implied that changing
the libraries led to `a ball of spaghetti', and I don't see that, can
you please
At 15:47 +0100 98/10/07, Simon Marlow wrote:
On the subject of Int vs. Integer, have folk actually looked at the
GHC/Hugs libraries for fixed-size integers and words, namely Int and
Word respectively?
...
If Int were to disappear, most people could just 'import Int' and
replace Int with Int32
Haskell Mode for Emacs, Version 1.2
---
The ubiquitous editor Emacs allows modes specific to a particular
language or task. We present a mode for editing Haskell scripts that
provides the following features:
* Font Locking:
I would like to support Simon PJ's suggestion about Ints and Integers for
three reasons.
1. There is a meta argument that we simply have not reached a consensus on
this issue: there are options -- such as a `word' view of Int -- which need
to be looked at, and there are details to do with
13 matches
Mail list logo
