Re: parser/hschooks.c on linux
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 sCSyn:main:reader:profiling:parser:nativeGen -recomp -DDEBUG -dcore-lint parser/hschooks.c from parser/hschooks.c:10, /usr/local/lib/ghc-3.02/includes/StgMacros.h:1698: parse error before `sigset_t' make: *** [parser/hschooks.o] Error 1 Hmm, could be a glibc problem. Thanks for the report, I'll look into it. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
parser/hschooks.c on linux
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 -iutils:basicTypes:types:hsSyn:prelude:rename:ty pecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:ab sCSyn:main:reader:profiling:parser:nativeGen -recomp -DDEBUG -dcore-lint parser/hschooks.c from parser/hschooks.c:10, /usr/local/lib/ghc-3.02/includes/StgMacros.h:1698: parse error before `sigset_t' make: *** [parser/hschooks.o] Error 1 I tried adding #include signal.h to this file - but no luck. I'm not needing ghc right now - but I'm hoping you guys are gonna hack some new stuff (iface file, extra closures, new closure naming convention, etc) into ghc for me soon and I'll need it then. Alastair
Re: Sorry for the questions.
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 --no-print-directory -r; in /home/tim/ghc/work/fptools/ghc/lib/std gmake[3]: *** No rule to make target `Array.o', needed by `libHS.a'. Stop. oh well. This must be a real bug. I'll probably be able to fix this and include a patch. If you're interested in the FreeBSD portsfile, let me know. Hmm..looks as if you're dependencies are a bit off. Try doing a 'make boot' in ghc/lib to see if that clears it up. --Sigbjorn
Sorry for the questions.
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 /home/tim/ghc/work/fptools/ghc/lib/std gmake[3]: *** No rule to make target `Array.o', needed by `libHS.a'. Stop. oh well. This must be a real bug. I'll probably be able to fix this and include a patch. If you're interested in the FreeBSD portsfile, let me know. Tim -- ,.---. | Tim Hemel -- TimeWaster [EMAIL PROTECTED] | Out of my mind. | |http://cuba.xs4all.nl/~tim/ |Back in five minutes. | `'---'
Small problems with the GHC port
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 will complain. My port contains a patch for this. Then, when building the storage directory, some header files are not present. These have to be generated with unlit from the corresponding .lh files. It appears that something is missing in one of the Makefiles. What is the right form of the statement I should insert, and where in which file should it be inserted? With so many Makefiles, it is hard to figure out. Thanks, Tim -- ,.---. | Tim Hemel -- TimeWaster [EMAIL PROTECTED] | Out of my mind. | |http://cuba.xs4all.nl/~tim/ |Back in five minutes. | `'---'
problem building pre-GHC-4.00/2 (PrimPacked.lhs)
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
ghc-3.03 -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:spe
cialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profil
ing:parser:nativeGen -recomp -fvia-C -monly-3-regs -optC-funfolding-interf
ace-threshold10 -v -c utils/PrimPacked.lhs -o utils/PrimPacked.o -osuf o
The Glorious Glasgow Haskell Compilation System, version 3.03, patchlevel 0
literate pre-processor:
echo '#line 1 "utils/PrimPacked.lhs"' /tmp/ghc1016.lpp
/gw19/usr/lib/ghc-3.03/unlit utils/PrimPacked.lhs - /tmp/ghc1016.lpp
0.04user 0.03system 0:00.22elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
Effective command
line: -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -i
utils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specia
lise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:reader:profiling
:parser:nativeGen -recomp -fvia-C -monly-3-regs -optC-funfolding-interface-t
hreshold10 -v -c -o utils/PrimPacked.o -osuf o
Haskellised C pre-processor:
echo '{-# LINE 1 "utils/PrimPacked.lhs" -}' /tmp/ghc1016.cpp
/gw19/usr/lib/ghc-3.03/hscpp -v -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=303
-I. -I. -IcodeGen -InativeGen -Iparser -I/gw19/usr/lib/ghc-3.03/includes -I/
gw19/usr/lib/ghc-3.03/includes /tmp/ghc1016.lpp /tmp/ghc1016.cpp
0.04user 0.06system 0:00.17elapsed 58%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
hscpp:CPP invoked:
/gw19/H-i386-cygwin32/lib/gcc-lib/i386-cygwin32/2.7-B19/cpp.exe -traditional
-D__HASKELL1__=4 -D__GLASGOW_HASKELL__=303 -I. -I. -IcodeGen -InativeGen -I
parser -I/gw19/usr/lib/ghc-3.03/includes -I/gw19/usr/lib/ghc-3.03/includes
/tmp/ghc1016.lpp
ghc-3.03:compile:Output file utils/PrimPacked.o doesn't exist
ghc-3.03:compile:Interface file utils/PrimPacked.hi doesn't exist
ghc-3.03:recompile:Input file utils/PrimPacked.lhs newer than
utils/PrimPacked.o
Haskell compiler:
/gw19/usr/lib/ghc-3.03/hsc ,-N ,-W
,/tmp/ghc1016.cpp -fglasgow-exts -funfolding-interface-threshold10 -fignore
-interface-pragmas -fomit-interface-pragmas -fsimplify
-ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -fdo-case-elim
-freuse-con -fpedantic-bottoms -fclone-binds -fmax-simplifier-iterations4
] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-duplicate-expo
rts -fhi-version=303 -himap=utils%.hi:basicTypes%.hi:types%.hi:hsSyn%.hi:pre
lude%.hi:rename%.hi:typecheck%.hi:deSugar%.hi:coreSyn%.hi:specialise%.hi:sim
plCore%.hi:stranal%.hi:stgSyn%.hi:simplStg%.hi:codeGen%.hi:absCSyn%.hi:main%
.hi:reader%.hi:profiling%.hi:parser%.hi:nativeGen%.hi:.%.hi:/gw19/usr/lib/gh
c-3.03/imports/exts%.hi:/gw19/usr/lib/ghc-3.03/imports/exts%.hi:/gw19/usr/li
b/ghc-3.03/imports/std%.hi -v -hifile=/tmp/ghc1016.hi -C=/tmp/ghc1016.hc -
F=/tmp/ghc1016_stb.c -FH=/tmp/ghc1016_stb.h
+RTS -H600 -K100 -s/tmp/ghc1016.stat
Glasgow Haskell Compiler, version3.03, for Haskell 1.4
PrimPacked.lhs:135: Data constructor not in scope: `ForeignObj'
PrimPacked.lhs:256: Data constructor not in scope: `ForeignObj'
Compilation had errors
Command exited with non-zero status 1
5.56user 0.82system 0:09.22elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
deleting... /tmp/ghc1016.lpp /tmp/ghc1016.cpp /tmp/ghc1016.hi
/tmp/ghc1016.hc /tmp/ghc1016_stb.c /tmp/ghc1016_stb.h /tmp/ghc1016.stat
rm -f /tmp/ghc1016*
make[2]: *** [utils/PrimPacked.o] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
I guess that PrimPached.lhs need Prelude from ghc-4.00 but get it from 3.03.
Am i right?
Any hints?
Thanks a lot,
Alex
RE: problem building pre-GHC-4.00/2 (PrimPacked.lhs)
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 constructor not in scope: `ForeignObj' Compilation had errors Yep, the pre-4.00 sources are not compatible with 3.03 in a couple of minor (but crucial) ways, I'm afraid. The release of ghc-4.00, which fixes this prob., is only days away though. --Sigbjorn
Re: parser/hschooks.c on linux
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 sCSyn:main:reader:profiling:parser:nativeGen -recomp -DDEBUG -dcore-lint parser/hschooks.c from parser/hschooks.c:10, /usr/local/lib/ghc-3.02/includes/StgMacros.h:1698: parse error before `sigset_t' make: *** [parser/hschooks.o] Error 1 Fixed, as of 5 minutes ago. I'm now happily building on a glibc box (and hoping the owners of said glib box don't mind too much :-) Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: accumArray stack and heap usage
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 association list. I notice the definition in PrelArr.lhs uses foldr over the list, so from that alone I'd expect problems, but I'm sure there's much more to it. I didn't look into it in great detail, but it looks to be a combination of the use of foldr and the call writeArray arr i (f old_v new_v) in zap_with_f. This just updates the array entry with a new thunk which refers to the old thunk, so any use of this function will by definition require linear heap space. ... Thanks for the quick response. You're right about the accumulation of thunks. I was wrong to suspect foldr; it's threading the array updates so it's exactly the form of fold it should be. ... Perhaps we need a strict version of accumArray. Yes please. There are also occasions when a strict version of array would be beneficial. Eg.: building a large lookup table as an array where associations are independent, or ordered with no forward dependencies. The initialising thunks can require many times the space needed for the reduced values, and the big peak in heap usage can cause horrible thrashing in a program which would otherwise run comfortably in much less memory. TWP
Int vs. Integer
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 explain? I'm not arguing to change the decision, I just want to know what problems (if any) you spotted. Cheers, -- P
Re: Int vs Integer
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 everywhere in their programs. The libraries
provide types Int{8,16,32,64} and Word{8,16,32,64}, instances of all
the integer numeric classes and a full range of bit operations. (The
library interface is due to Alastair Reid).
I looked brifely at this a long time ago, which was part of the reason I
suggested that all those should be replaced by a single type Binary, if
possible.
Hans Aberg
* Email: Hans Aberg mailto:[EMAIL PROTECTED]
* Home Page: http://www.matematik.su.se/~haberg/
* AMS member listing: http://www.ams.org/cml/
ANNOUNCE: Haskell Mode for Emacs, Version 1.2
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: Colours keywords, comments, strings, etc. This allows more information to be passed to the user about the visible text and aids the programmer significantly. * Declaration Scanning: Scans declarations and places them in a menu. This makes it quick and easy to find function declarations, type declarations, etc. * Documentation: Echoes types of functions or syntax of keywords when the cursor is idle. This saves a lot of time when you cannot remember the type of a function, or the syntax of a declaration. * Indentation: Provides semi-automatic intelligent indentation. The first successful attempt at automatic indentation of Haskell, and will soon appear as an article in JFP! * Simple Indentation: Provides simple indentation. This is a lightweight alternative to the more intelligent indentation above. * Hugs Interaction: Allows interaction with the Hugs interpreter. A simplified version of the Hugs interaction mode of Chris Van Humbeeck. We hope to extend this functionality in future versions. Contributions are welcome! Current contributors: Graeme Moss, Tommy Thorn, Hans-Wolfgang Loidl, and Guy Lapalme. See the following home page: http://www.haskell.org/haskell-mode/ for a demonstration of the mode in action and instructions for downloading and installation. Any problems, please email using the address on the web page. Cheers, Graeme.
Int vs Integer
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 libraries which need to be niggled over. It therefore seems likely that whatever decision is taken now, it will be substantially changed in Haskell 2, and so we should stick with what we have and try to get it right for Haskell 2. 2. About the proposal to generalise signatures, I am uneasy. This is because in an earlier version of the language length and friends *did* have more general types, but the current specific types which involve Int result from unhappiness with these functions having generic types. It seems unfortunate to go back on that decision, particularly in the light of the proposed changes to make the types of map and comprehensions more specific for similar reasons to those which prompted the original narrowing of type for length and friends. 3. From a teaching point of view it is substantially easier to deal with non-overloaded types for length, take and drop, and I think this advantage more than outweighs a slight niggle that it would be better to talk about Integer than Int: given the choice between Int and (Integral a), Int is much to be favoured from a teaching point of view. Simon Thompson
