make in-place broken?
Hi! It seems, `make in-place' on a binary distribution (gen'ed with `make binary-dist Project=Ghc', CVS 2000/01/09) doesn't produce a working system, because: ghc/drivers/ghc-inplace (which I believe is copied to bin/arch/ghc-4.06.prl in the binary dist) contains the following lines: [...] $libdir="/usr/local/lib"; $libexecdir="/usr/local/lib"; $datadir="/usr/local/share"; $bindir="/usr/local/bin"; $TMPDIR="/tmp"; $TOP_PWD="/usr/local"; [...] The `in-place' $*dir variables are cat'ed to the _top_ of ghc-4.06.prl, with the consequence that the variables are overridden with the lines listed above... Is this true, or did I miss an important step? Cheers, Michael -- Lehrstuhl-BeleuchtungMichael Weber [EMAIL PROTECTED] Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
RE: problem with -split-objs and _stub.c files
The driver script bails out, if using option `-split-objs' on a Haskell source that also produces a source_stub.c (like hslibs/util/Readline.lhs does, for example). The obvious fix to me was checking `$ifileroot' against /stub\.s$/ in `runAsm()' and then not using split-objs on the file, but there is surely a better solution (maybe in ghc-split.prl?) ... I've incorporated your patch for now. As you say, there's probably a better solution, but as far as I'm concerned the less time I have to spend looking at ghc.lprl the better :-) Cheers, Simon
Re: make in-place broken?
On Tue, Jan 18, 2000 at 03:49:35 -0800, Simon Marlow wrote: BIN_DIST=1 in your build.mk file in order to build a binary distribution. I bet that's the problem. In fact, that fixed the problem... thanks cheers, Michael -- Lehrstuhl-BeleuchtungMichael Weber [EMAIL PROTECTED] Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
RE: compilation fails when -O flag specified
Thanks for reporting this bug. It is indeed a bug in GHC 4.04,
but the current working version of the compiler compiles and
runs it fine.
So for now, just compile without -O. We plan to release 4.06 in the
next fortnight.
I hope the process of elimination didn't take too long.
Simon
| -Original Message-
| From: Louis Madon [mailto:[EMAIL PROTECTED]]
| Sent: 18 January 2000 17:12
| To: [EMAIL PROTECTED]
| Subject: compilation fails when -O flag specified
|
|
| Hi,
|
| I've been having problems getting GHC to compile some code I'm working
| on with optimisation (-O) turned on. Compilation is fine without -O
| specified. Through a process of elimination I've managed to reproduce
| the problem
| in the following (much simpler) piece of code:
|
|
|
|
|
| module Main where
|
| import List
|
| test es =
| concat (groupBy eq (zip [0..(length es) - 1] es))
| where
| eq a b = (fst a) == (fst b)
|
| main = putStr (show (test [1,2,3,4]))
|
|
|
|
|
|
| When compiled with -O the compiler produces the following output:
|
|
|
| panic! (the `impossible' happened):
| funResultTy t{-r1Gm-}
|
| Please report it as a compiler bug to
| [EMAIL PROTECTED]
|
|
| Additional information:
|
| uname -a gives:
| FreeBSD Gatekeeper.quillan.com 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Sun
| Jul 18 09:22:18 EST 1999
| [EMAIL PROTECTED]:/usr/src/sys/compile/GATEKEEPER i386
|
| gcc version is 2.7.2.1
|
|
| Here is a recorded shell session:
|
|
| ---
|
| Script started on Tue Jan 18 11:01:18 2000
| sh-2.03$ ls -l
| total 2
| -rw-r--r-- 1 madonl wheel 172 Jan 18 10:40 Main.hs
| -rw-r--r-- 1 madonl wheel 43 Jan 18 11:01 typescript
| sh-2.03$ cat Main.hs
| module Main where
|
| import List
|
| test es =
| concat (groupBy eq (zip [0..(length es) - 1] es))
| where
| eq a b = (fst a) == (fst b)
|
| main = putStr (show (test [1,2,3,4]))
| sh-2.03$ ghc -v -O Main.hs
| The Glorious Glasgow Haskell Compilation System, version 4.04,
| patchlevel 1
|
| Effective command line: -v -O
|
| Ineffective C pre-processor:
| echo '{-# LINE 1 "Main.hs" -}' /tmp/ghc962.cpp cat
| Main.hs
| /tmp/ghc962.cpp
| 0.00 real 0.00 user 0.00 sys
| ghc:compile:Output file Main.o doesn't exist
| ghc:compile:Interface file Main.hi doesn't exist
| ghc:recompile:Input file Main.hs newer than Main.o
|
| Haskell compiler:
| /usr/local/lib/ghc/hsc /tmp/ghc962.cpp -ffoldr-build-on
| -fdo-eta-reduction -fdo-lambda-eta-expansion -fcase-of-case
| -fcase-merge
| -flet-to-case -fpedantic-bottoms -fsimplify [ -finline-phase0
| -fmax-simplifier-iterations2 ] -fspecialise -ffull-laziness
| -ffloat-inwards -fsimplify [ -finline-phase1
| -fmax-simplifier-iterations4 ] -fsimplify [ -finline-phase2
| -fmax-simplifier-iterations4 ] -fstrictness -fcpr-analyse
| -fworker-wrapper -fsimplify [ -fmax-simplifier-iterations4 ] -fcse
| -ffull-laziness -ffloat-inwards -fsimplify [
| -fmax-simplifier-iterations4 ] -flet-no-escape
| -fwarn-overlapping-patterns -fwarn-missing-methods
| -fwarn-duplicate-exports -fhi-version=404 -static
| -himap=.%.hi:/usr/local/lib/ghc/imports/std%.hi-v
| -hifile=/tmp/ghc962.hi -C=/tmp/ghc962.hc -F=/tmp/ghc962_stb.c
| -FH=/tmp/ghc962_stb.h +RTS -H600 -K100
| Glasgow Haskell Compiler, version 4.04, for Haskell 98,
| compiled by GHC
| version 4.04
|
| panic! (the `impossible' happened):
| funResultTy t{-r1Gm-}
|
| Please report it as a compiler bug to
| [EMAIL PROTECTED]
|
|
| 2.31 real 2.27 user 0.03 sys
| deleting... /tmp/ghc962.cpp /tmp/ghc962.hi /tmp/ghc962.hc
| /tmp/ghc962_stb.c /tmp/ghc962_stb.h
|
| rm -f /tmp/ghc962*
| sh-2.03$ exit
| exit
|
| Script done on Tue Jan 18 11:02:01 2000
|
|
| --
|
|
| If you know how I can fix or work around this please let me
| know as I'd
| really like to be able to do optimised builds of my project.
|
| Thanks,
| Louis Madon
| [EMAIL PROTECTED]
|
ghc -parallel ...
Hi,
I've been trying to compile a toy example with GHC's parallel option.
The `impossible' happened ...
How do I get the parallel machinery working?
Best,
Dirk
Here is the verbose compiler report:
(the program code follows after that)
droog:~/Hacks/haskell/Equations/src/test ghc -parallel
-i/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std
-v parFact.hs
The Glorious Glasgow Haskell Compilation System, version 4.04, patchlevel 1
Effective command line: -parallel
-i/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std
-v
ghc: unrecognised option: -fstack-check
Ineffective C pre-processor:
echo '{-# LINE 1 "parFact.hs" -}' /tmp/ghc21755.cpp cat parFact.hs
/tmp/ghc21755.cpp
real0.0
user0.0
sys 0.0
ghc:compile:Output file parFact.o doesn't exist
ghc:compile:Interface file parFact.hi doesn't exist
ghc:recompile:Input file parFact.hs newer than parFact.o
Haskell compiler:
/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/hsc /tmp/ghc21755.cpp
-fparallel -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [
-finline-phase2 -fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns
-fwarn-missing-methods -fwarn-duplicate-exports -fhi-version=404 -static
-himap=/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent%.hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std%.hi:.%.hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent%.mp_hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/concurrent%.mp_hi:/softa/zeus/prg/fptools/lib/sparc-sun-solaris2/ghc-4.04/imports/std%.mp_hi
-v -hifile=/tmp/ghc21755.hi -C=/tmp/ghc21755.hc -F=/tmp/ghc21755_stb.c
-FH=/tmp/ghc21755_stb.h +RTS -H600 -K100
Glasgow Haskell Compiler, version 4.04, for Haskell 98, compiled by GHC version 4.04
panic! (the `impossible' happened):
closureCodeBody:arg_regs
Please report it as a compiler bug to [EMAIL PROTECTED]
real2.5
user2.3
sys 0.1
deleting... /tmp/ghc21755.cpp /tmp/ghc21755.hi /tmp/ghc21755.hc /tmp/ghc21755_stb.c
/tmp/ghc21755_stb.h
rm -f /tmp/ghc21755*
parFact.hs:
module Main(main) where
import IO
import Parallel
pfc :: Int - Int - Int - Int
pfc x y c
| y - x c = f1 `par` (f2 `seq` (f1+f2))
| x == y= x
| otherwise = pf x m + pf (m+1) y
where
m = (x+y) `div` 2
f1 = pfc x m c
f2 = pfc (m+1) y c
pf :: Int - Int - Int
pf x y
| x y = pf x m + pf (m+1) y
| otherwise = x
where
m = (x+y) `div` 2
parfact x c = pfc 1 x c
mk_num :: String - Int
mk_num s = (fst . head) (reads s :: [(Int,String)])
main = do putStr "argument 1: "
arg1 - getLine
putStr "argument 2: "
arg2 - getLine
putStrLn (show (parfact (mk_num arg1) (mk_num arg2)))
Re: RegexString: was it really meant to be that way ?
Tue, 11 Jan 2000 07:36:22 -0800, Simon Marlow [EMAIL PROTECTED] pisze:
I'm tempted to junk the whole Regex library and replace it with
one based on pcre, actually.
http://www.dcs.gla.ac.uk/~meurig/regexp/ looks interesting, is
written in Haskell, but is quite big and seems to be not maintained
anymore... I've given up trying to compile it with current GHC version.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Segmentation Fault
Simon Marlow wrote: Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris system successfully ~/builds uname -a SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10 uname -a SunOS titania 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-1 ~/builds gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) gcc -v Reading specs from /usr/local/lang/gnu/lib/gcc-lib/sparcv9-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) Stage 1 was build with 4.04pl1 (make sure you have pl1!), and stage 2 was cksum ghc-4.04-sparc-sun-solaris2.tar.gz 2269644928 6114825 ghc-4.04-sparc-sun-solaris2.tar.gz bootstrapped. I've just done a stage 3 build too, which went through without a hitch. Was the stage 2 build installed in a separate directory as it was here, or eas it in place? So I'm at a loss now: Marc reported that downgrading his gcc fixed the problem. That suggests that it's a gcc bug, but we're using 2.95.2 here without any difficulties. There's also the outstanding build problem related to sigset_t, which I also can't reproduce. Any insight appreciated. OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: Glasgow Haskell Compiler, version 4.06, for Haskell 98, compiled by GHC version 4.06 Program received signal SIGSEGV, Segmentation fault. 0x90062010 in ?? () (gdb) bt #0 0x90062010 in ?? () #1 0xa7db74 in schedule () #2 0xa7e080 in waitThread () #3 0xa7c8a8 in rts_evalIO () #4 0xa7c2b8 in main () I'll keep the gdb session alive for the rest of today if you have any more queries.
Re: Segmentation Fault
On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Cheers, Michael -- Lehrstuhl-Gärtnerei Michael Weber [EMAIL PROTECTED] Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: Segmentation Fault
Michael Weber wrote: On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Yes, both those options exist but they keep the products of hsc, not what goes into it. In this case, the cpp'd unlit'd source. I would like a -keep-everything flag to actually keep everything . . .
RE: Segmentation Fault
Michael Weber wrote: On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Yes, both those options exist but they keep the products of hsc, not what goes into it. In this case, the cpp'd unlit'd source. I would like a -keep-everything flag to actually keep everything . . . The "standard hack" here is to run 'ghc -v' and hit Ctrl-Z at the right moment. This is a trick that's been passed down from previous generations of GHC hackers, I guess no-one has ever been bothered enough to fix it properly... Cheers, Simon
Forthcoming 4.06
Hi Folks, The CVS repository is being branched for 4.06 as I type this mail. In a day or two, after final testing and any last-minute tweaks, we'll call it 4.06 and crank the release handle once more. We're fairly optimistic about this release: there have been some performance improvements and the usual truckload of bugfixes, the new library reorganisation is a step in the right direction, and the docs are all converted to DocBook format now. Anyone that wants to try the current release candidate, there's a source snapshot here: http://research.microsoft.com/~simonmar/ghc/snapshot/ghc-pre-4.06-2117-s rc.tar.gz Any last minute bug reports or feature requests? Cheers, Simon
Re: Forthcoming 4.06
Simon Marlow wrote: [...] Any last minute bug reports or feature requests? Of course... :-) After a monstrous fight against the versionitis of jadetex and the DocBook tools, I've finally managed to build the installation guide and the user's guide. But there were tons of warnings like: jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported Should they simply be ignored? Another one: How is the library documentation supposed to be generated? Simply doing a `make dvi ps html' in fptools/hslibs does nothing. And finally: The documentation for Green Card and HDirect (probably Happy, too, can't remember) can't be built currently. Fixing this rather soon would be nice, because this would improve the chances of getting those into the next SuSE release. (= Hint! :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: Forthcoming 4.06
After a monstrous fight against the versionitis of jadetex and the DocBook tools, I've finally managed to build the installation guide and the user's guide. But there were tons of warnings like: jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported Should they simply be ignored? Yeah, you can probably ignore that, if that's the only kind of warning you get. The purpose of it is to read in a particular SGML declaration when it sees a certain DTD so, in particular, if jade gets passed the declaration explicitly like this: jade -c /var/lib/sgml/CATALOG.docbk31 /var/lib/sgml/docbook.dcl other stuff there is no problem. Or you can use OpenJade 1.3 (http://peano.mathematik.uni-freiburg.de/jade-cvs/), which I think supports DTDDECL. --FAC
RE: Forthcoming 4.06
Or you can use OpenJade 1.3 (http://peano.mathematik.uni-freiburg.de/jade-cvs/), which I think supports DTDDECL. Oops, I take it back. The OpenSP 1.4 prerelease supports DTDDECL, but not 1.3, and OpenJade 1.4 hasn't been released in any form yet (except CVS). --FAC
standard function requirements
Tom Pledger [EMAIL PROTECTED] writes [..] lazinessTest = head $ fst $ partition (==1) [0..] lazinessTest' = head $ fst $ partition' (==1) [0..] Main lazinessTest (35927 reductions, 63879 cells) ERROR: Control stack overflow Main lazinessTest' 1 (36 reductions, 73 cells) Any ideas about why this happens, please? By the way, the List.partition definition \p xs - (filter p xs, filter (not .p) xs) is not it the simplest and the best implementation? It looks like the existing implementations do not use it. Correctness question The implementations optimize the standard functions in various ways. But what about correctness, what the standard says? For example, the definition from the List.partition _document_ implies that head $ fst $ partition (==1) [0..]= 1 And some implementations get into infinite loop at this (may this loop be called `undefined', is it equivalent ?). What freedom the language and library description allows with this respect? -- Sergey Mechveliani [EMAIL PROTECTED]
Re: standard function requirements
Tue, 18 Jan 2000 12:44:57 +0300 (MSK), S.D.Mechveliani [EMAIL PROTECTED] pisze:
By the way, the List.partition definition
\p xs - (filter p xs, filter (not .p) xs)
is not it the simplest and the best implementation?
It evaluates p twice on each element.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Haskell Clean
Am Fri, Jan 14, 2000 at 02:23:00PM +0800 schrieb Nguyen Phan Dung: So what are the important differences between Clean Haskell? What are the pros and cons of unique typing with multiple environments vs. the IO monad? Thanks, -- Stefan Karrmann.
prelude drop and take
Hi, This minor inconsistency has been bothering me for some time: Prelude drop 10 "test" "" Prelude drop (-1) "" "" Prelude drop (-1) "a" " Program error: Prelude.drop: negative argument I got these results from Hugs, but the code is identical to that specified in the Haskell98 standard. Why not an error for the negative argument on an empty list ? Secondly, why not an error for an argument that's too big ? What I would like is this: drop 0 xs = xs drop n (_:xs) | n0 = drop (n-1) xs drop n _ | n0 = error "Prelude.drop: argument too big" | otherwise = error "Prelude.drop: negative argument" Or is there a good reason for drop being able to drop more elements than the list is long ? In which case I would like: drop 0 xs= xs drop n [] | n0 = [] drop n (_:xs) | n0 = drop (n-1) xs drop _ _ = error "Prelude.drop: negative argument" I doubt the second solution would be much less efficient. The first solution should be just as efficient as the one in Haskell98. The same goes for take and splitAt. Regards, Jan
`partition'
To my By the way, the List.partition definition \p xs - (filter p xs, filter (not .p) xs) is not it the simplest and the best implementation? Marcin Qrczak Kowalczyk [EMAIL PROTECTED] replies on 18 Jan 2000 It evaluates p twice on each element. But "filter-filter" implementation needs a constant space for head $ fst $ partition (==1) [0..n]. And some recent implementations take heap+stack proportional to n. -- Sergey Mechveliani [EMAIL PROTECTED]
Re: prelude drop and take
Tue, 18 Jan 2000 13:46:27 +0100, Jan Kort [EMAIL PROTECTED] pisze:
This minor inconsistency has been bothering me for some time:
Prelude drop 10 "test"
""
Prelude drop (-1) ""
""
Prelude drop (-1) "a"
"
Program error: Prelude.drop: negative argument
Hmm, right...
We could argue what should be evaluated first: the beginning of the
list or the count. The count seems to be more natural, because the rest
of the list is certainly evaluated later. This yields your version.
Secondly, why not an error for an argument that's too big ?
The current behavior can be useful and could not be simulated well
using your version. Trivial example: you want to see what remains
from a text file after scrolling left a few columns and clipping the
right margin to the window width. Present versions of both drop and
take are needed. drop and take mean "drop/take at most that many".
So I would propose failing immediately on negative argument, but
keeping current semantics when the count is too big (or the list
is too short).
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
