Has anyone found a problem with (erroneously, in my case) knot-tied
structed pattern matching? I got a bus error (eek) from a fragment
of the form:
blah b = ... x ...
where
[x] = ... [x] ...
While I'm fairly sure this is what caused the problem, (I did a clean
rebuild, so I
The following erroneous fragment erroneously compiles.
data Token
= TokNewline
2.03ish make depend seems to provoke errors like:
mkdependHS: can't open directory /usr/local/lib/ghc-2.03/hslibs/ghc/imports
make: *** [depend] Error 2
I haven't checked back with exactly what the makefiles do, so this is
partly conjectural, but my diagnosis, and the basis on which I hacked
a
Here's a much simpler instance of my previous bug report:
data A = T | T
is missed by ghc-2.02 error-checking, but caught in 2.03. Problem
solved in advance, then, really.
Alex.
Oops, missing the obvious!
Vladimiro Sassone types:
gmake configure
That should be just
./configure
no? Or have you tried that already?
Cheers,
Alex.
Hi again, Vladimiro.
VS:
Exactly. It fails compiling the parser. I'm trying to compile using (the
binaries of) ghc-2.02. Is there something intrinsecally wrong with this?
Ah-hah! Yes. You need ghc-0.29 as the builder, I believe. I don't
know why this might be "instrinsically" wrong, but
VS:
gmake[2]: execvp: ghc-0.29: Arg list too long
gmake[2]: *** [hsc] Error 127
Further to my last message, here are the Collected Sayings of the
Prophet Finne on the matter:
you're fighting with ARG_MAX, try invoking make as follows:
foo% env PATH=$PATH make
(the Makefile has
Sven Panne notes:
The interface files for the system libraries ghc, hbc, posix and
contrib seem to be installed in the wrong place: The lib directory
(containing hsc and friends) does not contain a hslibs subdirectory.
I noticed (and already reported: is this fixed in the new install script,
SPJ, quoting Marc:
| Could somebody tell me how to disambiguate the following program
|
| module Tmp( g ) where
| data A p q = A
| g :: (Num p,Ord q) = (A p q) - Bool
| g A = g A
I don't understand this. "g" always returns bottom.
If only! The above example looks pathological
Greetings, fellow buggees. Building 2.04 (on a sun/sparc/solaris2.5 box)
seemed to go relatively smoothly, up until I tried to do "make install",
whereupon the fun really started. Running into some problems, I decided
to resort to (gasp!) checking the installation guide, only to discover
it
Some darn fool wrote:
libHSposix.a:error reading file
Any clues as to what the diagnostic means?
Oops! Apparently, "file system full". embarrassed cough My excuses
are a confusing error message, and a disk partitioning system no one
here seems to understand.
BTW, isn't it Canonical GHC
Hi all. Some problems I had recently with ghc opts, while trying to
twiddle the heap usage of ghc on happy output (see ghc-users, passim).
Pedantic observation: contra the user guide, -funfolding-use-threshold0
isn't recognized, though -funfolding-use-threshold-0 is. (The minus/hyphen
isn't
Sergey, I'm afraid I can't help you with your main problem. None
of the (pre-crash) diagnostics looked too bad to me. But until
someone competent turns up, here's my best stab at some of your others:
I placed 2 in .build.mk - is this right?
I suspect it doesn't actually matter,
Neither -optCrts-Sstderr nor -Rgc-stats seem to do anything useful;
the file created by the latter contains only a ghc command line, and
the former seems to do nothing at all.
Hmm..need more details, I'm not able to reproduce this behaviour.
Transcript below. Maybe the option is
Josh Burdick writes:
ghc-0.29 -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I.
-IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn
-iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore
-istranal -istgSyn -isimplStg -icodeGen -iabsCSyn
Just in case the following throws any light on Josh Burdick's build
problems on an alpha, I got the following message, when my build
here eventually got as far as hsc. I'm using OSF 3.2, however, so
your kilometerage may vary considerably...
Good luck,
Alex.
Spam alert: but honest, it's only
Sven Panne on:
Warning: Linking some objects which contain exception information sections
and some which do not. This may cause fatal runtime exception
handling
problems (last obj encountered without exceptions was
main/LoopHack.o).
I don't speak DECish too fluently,
Hi Josh, I'm afraid I can't help directly with any of your main problems,
though if I'm feeling brave I may try a build-from-source on an alpha
shortly. On some of your other points:
Also, could anyone post here a "build.mk" file for building 2.04-pl2
using an 0.29 binary distribution,
Only one problem with 2.05, so far: while building the compiler,
gnumake all seems to just lose interest after simplCore/ConFold.lhs,
and then start trying to build the libraries, with predictably little
success. Is this just an oddity of our flakey machines, or is there
some makefile oddity?
Ian Collier gets the notorious:
"parser/U_binding.hs", line 6, column 22: can't find interface (.hi) file for
module "FastString" on input: "FastString"
make: *** [parser/U_binding.o] Error 1
I had something much the same happen; some generic Makefile peccadilo
I assume, which is causing it
Hi again Ian. Look on the bright side: this time the actual compiler
got build successfully... Now there's just the small matter of the
libraries...
[in the middle of a 2.05 build on a SunOS4 box]
==fptools== make way=p all;
PWD =
To partially answer my own question...
Big problems with some output from Happy 1.2-alpha [...] I'm quite keen
to get it sorted out and/or worked around.
Easiest work-around is not to use "happy -g" output, which I neglected
to mention I was using. Evidently some sort of type-checking
Haven't properly investigated this myself yet, but just in case this
looks familiar to anyone, I get the following, trying to build
2.08 on an alpha, with ghc-0.29.
Unix assembler:
gcc -o absCSyn/PprAbsC.o -c /usr/tmp/ghc10102.s
as1: Internal: /usr/tmp/ghc10102.s, line 32:
Simon M:
We have a new set of Web pages at http://www.dcs.gla.ac.uk/fp/software/ghc/,
there will probably be a few glitches for a while so bear with us.
Binaries: I've made binaries for [...] sparc-sun-solaris2.
Here's one for starters... The above binary archive file seems not to
exist.
Well, works for me on sparc-solaris2, anyhow (after hacking around each
of the above snafus). Parthian shot complaint, though: the install
script _still_ doesn't install a ghc-version link to the driver, which
was acclaimed as a jolly good idea and promised for future releases
any number of
Hi all. More configuration irritations... I ran configure on a machine
with version 3.7.2.3 of gcc, then later tried to make on a different
machine, with only version 3.7.2. It crunched looking for cpp in the wrong
place, unsurprising. However, even after deleting config.cache,
rerunning
Hi all. More configuration irritations... I ran configure on a machine
with version 3.7.2.3 of gcc, then later tried to make on a different
machine, with only version 3.7.2.
Oops, that's 2.7.2, of course. (C compilers from the future...)
To answer my own question, apparently said paths
Hi, Alex. Your problem sounds not entirely dissimiliar to one I
encountered with ghc-2.08 on Digital UNIX V4.0B, though I'm not sure
it's exactly the same -- see ghc-bugs, _passim_. ;-)
Anyway, we are now trying to compile the GHC with -fvia-C.
That's what worked for me. In fact, I only had
Byron Cook:
does anyone have binary distribution of ghc-2.09 for the Alpha/Digital
UNIX?
I'm trying to help someone else via email, he's having a bad ghc
experience.
I have a build of 2.0_8_ on an Alpha, but no 2.09 currently. It went
fairly smoothly for me, though, so I'm help to help
Simon M. sez:
GHC 2.07 definitely does compile with 0.29,
including the happy-related bits. The happy sources in the tree will
compile with 0.29, and Happy can be told to generate 0.29-compatible
parsers by giving it the -1.2 flag (this flag is used automatically by
ghc/compiler/Makefile
Juan Jose Quintela quotes me quoting Simon...
GHC 2.07 definitely does compile with 0.29,
including the happy-related bits. The happy sources in the tree will
compile with 0.29, and Happy can be told to generate 0.29-compatible
parsers by giving it the -1.2 flag (this flag is used
Hi there. Peering at the Posix stuff on process handling, I wrote the
following program:
import Posix
main
= do installHandler sigINT Ignore Nothing
loop
loop = do putStr ""
loop
This ought to loop forever (yup), ignoring any SIG_INT's (nup). Is the
above
The Sender field should be ignored (as per RFC 822) by mail software
if there's a From field. The first From field is not legal as it is
not delimited by a ':'
I'd say the Pine setup is wrong.
--Sigbjorn
Anyone got any bright ideas on this on? hsc seems to build OK on a
HPUX box, but as soon as it tries to compile PrelBase:
wilde.ucc.ie:~/ghc-2.07/fptools/ghc/lib: ../driver/ghc -H20M -cpp -fglasgow-exts
-fvia-C -Rghc-timing -c ghc/PrelBase.lhs -dshow-passes
-fmax-simplifier-iterations4
Has anyone noticed anything flakey about the 2.07 recompilation system?
I've noticed several unnecessary-looking version changes and the like since
switching over. Any chance it might be confused by hi's left around from
version version (2.05), or some such?
Sorry to be so vague, but I fear
Another non-killing, but rather annoying error message: this one is
provoked by duplicate _scc_ labels. I don't see the sense in this
restriction, myself, but at any rate this wouldn't seem to be the
handiest way of detecting same...
Cheers,
Alex.
--
ghc-2.09 -c Intervals.hs -H30m -K2M
Tina Yu:
/bin/sh: Syntax error at line 1: `;' unexpected
make[1]: *** [config-pkgs] Error 2
make[1]: Leaving directory
`/tmp_mnt/cs/research/isrg/croissant/etg/var/src/ghc-2.10/fptools'
make: *** [in-place] Error 2
I ran into this one too! It's a shell problem -- or depending how you
look
Hi again. I note in passing that ghc still installs itself as "ghc",
not as "ghc-[version]" (with ghc as a link). At least two of the
Si*o*n-Squad -- that was a regular expression, not an expletive deleted ;-)
-- have been promising that this will be/has been fixed in the next
version for
install-sh does a fine line in unhelpful error messages: well, error
message singular, at any rate...
for i in hp2ps; do \
/export/home/ferguson/ghc-3.00/build/install-sh -c -g ghc-admin -s $i
/usr/local/bin; \
done
hp2ps:error reading file
This seems to be its catch-all for
New feature of ghc-3.00 under Solaris 2.5: a broken native code generator?
duck! -fvia-C makes the above go away. Will canonicalise and report
back after I finish fighting some other fires...
Slainte,
Alex.
--
ghc-3.00 -c RTE.hs -H30m -K2M -recomp -fglasgow-exts -cpp -syslib ghc
SOF:
install-sh is the fallback script used if the configure script is
unable to find an OK looking `install' somewhere along your PATH.
Oops, I confess to not knowing this. Configure doesn't seem to moan too
loudly about the lack of an "install", so I assumed that it was The
Real Program.
The configure for ghc does the following:
checking how to run the C preprocessor... (cached) gcc -E
checking how to invoke GNU cpp directly... (cached)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.3/cpp
Why the latter? And does it only look in the gcc installation
for cpp, or does it
Did you do 'make install' in ghc, instead of using the binary
distribution?
I did make install from a build from source, yes, not least as there was
no binary distrib. available at that point. ;-)
Hard links are a pain for several reasons - if you install a new ghc
over the existing one,
From [EMAIL PROTECTED] Fri Nov 28 11:48:59
1997
This is another file missing from the source distribution. The new
one is now up, and it contains all the necessary files.
Can you put this up as a patch, too?
It does for me - but the sense of the link is reversed (i.e. now ghc
points to
We don't have direct access to any HPs here at Glasgow right now,
but I recall running into this way back with 2.02.
Hrm. 2.02 built fine for me, though. In fact, 2.07 actually _built_:
and then crashed, as per Sven's experiences. I'll look into your
suggestion, tomorrow... when I'm sober.
Is this an Actual Bug, or a Ferguson Foulup? Looks like it's looking for
readline stuff that isn't there, and which it _knows_ isn't there. Do
I need to disable Readline as a config option? This all worked swimmingly
in ghc-3.00...
Slainte.
Alex.
_
oconnor.ucc.ie:~/ghc-3.01/build:
Hi all. My prior whines about version-numbered binaries have been answered,
I see: thanks, esp. to Simon M. However, I have yet another in this series
of moans...
When I do a gnumake install from the source tree, it flumps, with:
ln -s ghc-3.01 /usr/local/bin/ghc
ln: cannot create
From [EMAIL PROTECTED] Fri Feb 27 04:36:53
1998
Resent-Message-Id: [EMAIL PROTECTED]
Old-Received: from mail1.realtime.net by vanuata with SMTP (MMTA);
Fri, 27 Feb 1998 04:35:57 +
Old-Received: (qmail 29032 invoked from network); 27 Feb 1998 04:35:47 -
Hi there. Trying to rebuild 3.01 with some additional "ways", and it
falls over at the following point:
oconnor.ucc.ie:~/ghc-3.01/build/ghc/lib/exts: gnumake all
===fptools== Recursively making `all' for ways: p mc mr mp
Sigbjorn:
-himap=./%.mc_hi:/usr/local/ghc-3.01/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.0
1/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.01/lib/imports/exts/%.mc_hi:/usr/loc
al/ghc-3.01/lib/imports/conc/%.mc_hi:/usr/local/ghc-3.01/lib/imports/exts/%.mc_h
This is a re-send, apologies if it turns up twice.
Ghc builds and sinstalls smoother than other, apart from one _leetle_
glitch, which still requires (minimal) manual intervention:
ln -s ghc-3.02 /usr/local/bin/ghc
ln: cannot create /usr/local/bin/ghc: File exists
gnumake[2]: *** [install]
Sigbjorn Finne replies to me:
Wouldn't it be a little neater for the installation script to relink or
remove the "old" ghc, at least in the case that it really is just a
symbolic link?
(I'm assuming you're talking about binary distributions, since the
"install" Makefile rules in the
Not a bug, but not really ghc-users fare either (I think).
I realise this is "damned if you do, otherwise, damned", but the
following error message confused me:
Intervals.hs:207:
Type signature doesn't match inferred type
Signature: Limit n - Limit n
Inferred : Limit Bool
Hi Simon:
What's wrong with using 'ghc-3.02 -M' for dependencies
I didn't think of it, that's what. ;-)
and 'ghc-2.01' for compiling, if you really want to keep 2.10 around?
I don't, and as soon as I convince everyone else around here of the
same... I don't think the above combination
Ghc builds and sinstalls smoother than other, apart from one _leetle_
glitch, which still requires (minimal) manual intervention:
ln -s ghc-3.02 /usr/local/bin/ghc
ln: cannot create /usr/local/bin/ghc: File exists
gnumake[2]: *** [install] Error 2
gnumake[1]: *** [install] Error 1
gnumake: ***
Hi all. Some build gotchas which I haven't seen reported (which
makes me wonder what stupid thing I did that others have not).
Setup is Solaris 2.5, ghc-3.02.
Firstly: gnumake all fails in build gmp, thusly:
gnumake -C gmp MAKEFLAGS=
cd mpn; gnumake "CC=../../ghc/driver/ghc " "CFLAGS=-O"
I hate this error. Whilst arguably this is an "untested" extension
to Standard Haskell, it seemed pretty sound in practice. Can't
we at least have it back as a GlaExt? (MSExt?) I'm starting to
feel more than a little Quaint having to use ghc-3.01, just to get
my programs to compile... (If
Sergey writes:
Is not this due to omitting
-optC-fallow-undecidable-instances -optC-fallow-overlapping-instances
?
Sorry, if i am missing the point.
No, I was! ;-) And thanks to Simon(s) for pointing this out, too.
Mind you, I somewhat object to the "undecidable" bit: I
Still can't build 4.00 from source (see bug report, elselist), and it's
also not yet on the ftp site in binary form.
*whinge!*
Slainte,
Alex.
Here's a very cut down version of the bug-exhibiting program mentioned
earlier. Sorry, if I cut it down any more, it compiles!
Slan,
Alex.
_
swift.ucc.ie:~/filt4: ghc M.lhs
MachRegs.lhs:563: Non-exhaustive patterns in function baseRegOffset
swift.ucc.ie:~/filt4: cat M.lhs
module M
Or you may have picked up a dodgy binary dist.
That was the one... One last (?) problem... This program:
module Main where
import IOExts
main = trace "Boogger" print 1
ain't playin', as follows (maxi-spam version).
Slainte,
Alex.
_
oconnor.ucc.ie:~/filt4: ghc -v -syslib misc
Note the Strange behaviour below... Module in question compiles
without -O, but not with...
Slainte,
Alex.
_
oconnor.ucc.ie:~/filt4: make OPT=-O
ghc-4.00 -c GalileoModules.lhs -H30m -K2M -recomp -fglasgow-exts -cpp
-syslib misc -Rgc-stats -dshow-passes
Very strange - either/both of you fans of autoheader?
Dunno about Jan or Keith, but I certainly amn't! And yet, I get the
same error, and what's worse, on my first (attempted) build of the
compiler. However, I did re-run configure at one point; is that the
root of this particular evil?
Has anyone out there tried to install ghc (any version whatsoever) on
a PC running Solaris 2.n? Results of keen interest.
Slan,
Alex.
An unsuspecting little program of mine crunches out the binary distrib
of 4.01, with "library -lgmp: not found" (full output appended).
Any clues as to what's up here? (Apologies if this is blitheringly
obvious, or just a shoddy report, about to fall into bed...)
Slan,
Alex.
_
Picking up the wrong "ghc", perhaps?
Hard to tell - what does 'ghc --version' report?
4.01 (which wasn't what I had intended, btw, and Simon has already
avised is a Bad Idea -- more inter-machine configuration confusion
on my part, sorry).
What puzzled me was that it was just invoking
Is there as yet any way to "compile in" particular RTS flags (or
particular defaults), when invoking ghc? Most obviously, heap size...
Slan,
Alex.
Thanks Simon, though I'm still a tad at sea...
Of course you can! Take a look at the User Guide, section 2.12:
http://www.dcs.gla.ac.uk/fp/software/ghc/4.01/users_guide/users_guide-2.html
#ss2.12
(under "RTS options for hackers...")
That says it all, I have a nasty feeling... For a
Not a typechecker bug; more a bizarre consequence of
overlapping instance decls.
OK, a typechecker misfeature, then, so I'll cross-reply to ghc-users. ;-)
The instance decl
instance Holidays a = Eq a
overlaps with absolutely every other instance decl for Eq.
In order to make
Discern that the following program is apparently well-typed:
module M2 where
class Eq a = Lattice a where
bottom :: a
data Inv a = INV a
deriving Eq
instance Lattice a = Lattice (Inv a)
class Holidays a where
holCode :: a - Int
-- instance Holidays a = Eq a
Now,
The following is a genuine type error, but the first message appears
to be rather 'parasitic', not to mention not making any actual sense.
It's caused by having a spurious type context around a type with no
type vriables (as per the second error message, which is immaculate...)
Case.hs:378:
'getEnv "PATH"' returns, not the value of PATH, but the
whole environment.
Which is also handy, but not what I understood the report
to specify,
and not what ghc-4.02 does on this 'ere Sun.
Can someone comment on (esp.) the second of these? Is this
reproducible, is it the
Two oddities I've noticed with ghc-4.03, win+cygnus binary build:
The -ansi flag makes gcc go berserk on the generated code. I stopped.
'getEnv "PATH"' returns, not the value of PATH, but the whole environment.
Which is also handy, but not what I understood the report to specify,
and not
Mircea Draghicescu:
The other question still remains: is this 4.03 or 4.04?
Having recently dl'd the same thing, looks a lot like ghc-4.03 to me...
I presume there's not a binary build for 4.04 (at least, not yet).
Program won't compile in default max heap;
-H objects that I should instead use -M, to raise same;
-M isn't a recognised option.
Fixing any one of these would do. ;-) (If it's fixed in 4.04 or 4.05,
extra credit for a binary build: I've just about maxed out on Windows
tinkering for the
yeats.ucc.ie:~/ghc44/build/ghc/rts: gnumake all
../../ghc/driver/ghc -I../includes -I. -Igum -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith
-optc-Wbad-function-cast -O2
In order to install ghc-4.04, I need to install the binary v. of 2.10
(this should be OK for doing that, right?) Immediately I come a cropper,
thus:
wisdom.ucc.ie:~/ghc210/fptools: gnumake in-place
gnumake config-pkgs bindir=`pwd`/bin/alpha-dec-osf1/ghc-2.10
libdir=`pwd`/lib/alpha-dec-osf1
From UNKNOWN
Received: from joyce.ucc.ie by vanuata with SMTP (MMTA) with ESMTP;
Tue, 12 Oct 1999 15:45:59 +0100
Received: (from abf@localhost) by joyce.ucc.ie (8.7.3/8.7.3)
id PAA11955 for [EMAIL PROTECTED];
Tue, 12 Oct 1999 15:45:02 +0100 (BST)
[This
enumerate :: (Enum a, Bounded a) = [a]
enumerate = [minBound .. maxBound]
data Test = Foo | Bar | Blah | Nonsense
deriving (Show, Enum, Bounded)
main = print (enumerate :: [Test])
BASH.EXE-2.02$ ghc-4.03 -static Enum.o
BASH.EXE-2.02$ ./a.exe
[Foo,Foo,Foo,Foo]
To be a tad
It's a bug, which is fixed in 4.04
Ah-hah... (I could likely have tested this myself, had I had the
gumption...)
(a Win32 version of which is due out shortly.)
Excellent. For one scary moment thoughts like 'Windoze build from
source' were going through my head.
Cheers,
Alex.
I whinged about:
[stuff]
Other people seem to have got further than I did in sun-sparc builds
-- is there a workaround that I could be using, pending an actual
fix? [ Or enough ftp space for the binary version. ;-) ]
Slan,
Alex.
I wrote:
syntax error at ../../ghc/driver/ghc line 1855, near "sub runLinker("
Execution of ../../ghc/driver/ghc aborted due to compilation errors.
gnumake: *** [Adjustor.o] Error 255
Evidently Perl versionitis. 5.001 no like; 5.005 likum plenty fine.
(This seems familiar, but I didn't
Sigbjorn:
I'm assuming this is ghc-2.04-pl2 ..
It is, or rather ghc-2.04, pacthed to that level. Mind you, I did have
to struggle somewhat in applying the patches, as different versions of
"patch" seemed to take a varying, and occassionally highly dim viw of
how to apply them. So a foul-up
bowen.ucc.ie:~/filter: galileo -dE
Fail: You tried to evaluate voidbowen.ucc.ie:~/filter:
This error decided to go away, pretty much of its own accord. Maybe
caused by an out of date (2.07) .o lying around someplace, or some such...
Cheers,
Alex.
Sigbjorn:
This sounds plausible, if the above msg had printed out the Id including
its module qualifier, it would have been a little bit easier to debug
this (Maybe moved from PrelBase to PrelMaybe with 2.09.)
Well actually, what would have been more helpful is knowing which
interface file
From [EMAIL PROTECTED] Thu Dec 4 01:29:20
1997
Resent-Message-Id: [EMAIL PROTECTED]
Old-Received: from optima.cs.arizona.edu by vanuata with SMTP (MMTA) with
ESMTP; Thu, 4 Dec 1997 01:27:09 +
Old-Received: from baskerville.CS.Arizona.EDU
Just run into the following in 2.09, didn't seem to happen with 2.07.
bowen.ucc.ie:~/filter: galileo -dE
Fail: You tried to evaluate voidbowen.ucc.ie:~/filter:
Seems to correspond to doing case analysis on a non-empty getArgs.
Any ideas?
Cheers,
Alex.
Hi all. Has anyone else had problems building one-or-other version of
ghc-2.0[5678] on the HPPA with ghc-0.29, and the HP linker? And if so,
have you found a workaround, either by a ghc tweak or by using a
different linker? I've been thrashing around in a number of such
avenues, so far
Hi all. Since compiling ghc-2.0[678] on an HP with 0.29 seems to be
terminally broken (see ghc-bugs, _passim_), I'm trying to build 2.0_5_
by that route, as seems to have worked for Sven. Alas: not for me:
it gets as far as the final link for hsc, (spam deleted), and then says:
collect2: ld
Further to my previous message: What it looks like is that I have a
cycle of module deps, and whenever any of them are changed, -recomp
gets very confused and recompiles them all. This seems to be because
each of them becomes a new version because its usages
because its predecessor in the
swift.ucc.ie:~/filter: cat cwd.hs
import Directory
main = getCurrentDirectory return ()
swift.ucc.ie:~/filter: ghc-2.05 cwd.hs
Module version unchanged at 1
swift.ucc.ie:~/filter: a.out
swift.ucc.ie:~/filter: ghc-2.07 cwd.hs
Module version unchanged at 1
swift.ucc.ie:~/filter: a.out
ghc-4.04 and ghc-4.08 both complain about the following:
No instance for `Show HandlePosn'
But according to the report, they should be showable (if precious
little else).
Haven't a version of 5.00 to hand (but will be installing 5.02,
promise!) so I haven't checked if this has changed
92 matches
Mail list logo
