I just checked a fresh copy of ghc + hslibs out of CVS, and tried doing a vanilla build. It fell over doing "make boot" in hslibs. Here are the last few make messages: ... ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
You need to 'make all' in fptools/ghc before 'make boot' in hslibs. The top-level fptools Makefile will arrange this if you just say 'make' at the top level. Cheers, Simon
On Wed, 13 Feb 2002, Simon Marlow wrote:
../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
You need to 'make all' in fptools/ghc before 'make boot' in hslibs. The top-level fptools Makefile will arrange this if you just say 'make' at the top level.
That's what I did. It made ghc ok, but then when it tries the 'make boot' in hslibs it falls over. The same happens if I change into $(BUILD)/hslibs and do 'make boot'... -- Nick Nethercote njn25@cam.ac.uk
On Wed, 13 Feb 2002, Nicholas Nethercote wrote:
That's what I did. It made ghc ok, but then when it tries the 'make boot' in hslibs it falls over. The same happens if I change into $(BUILD)/hslibs and do 'make boot'...
Ok, I've worked out the problem: I just checked out the modules "ghc" and "hslibs". It seems that the standard library has just been moved into a new separate module "libraries". So my build was missing the standard library which was causing the problem. -- Nick Nethercote njn25@cam.ac.uk
Ah, thanks. I was having the same problem but was too shy to ask about it, figuring it must be my bad. This should probably be mentioend in the build documentation (hint, hint). - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Wed, 13 Feb 2002, Nicholas Nethercote wrote:
On Wed, 13 Feb 2002, Nicholas Nethercote wrote:
That's what I did. It made ghc ok, but then when it tries the 'make boot' in hslibs it falls over. The same happens if I change into $(BUILD)/hslibs and do 'make boot'...
Ok, I've worked out the problem: I just checked out the modules "ghc" and "hslibs". It seems that the standard library has just been moved into a new separate module "libraries". So my build was missing the standard library which was causing the problem.
-- Nick Nethercote njn25@cam.ac.uk
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi I'm building some stuff here that is basically a glorified and specialized version of quicksort. It is very quick, and works like a charm for my purposes, except that it consumes way too much space, about 100 bytes times the size of the input list. Which means that, for my data sets, the program exceeds available RAM and uses swap, which in turn kills performance. Is there any guideline how much space the various constructs use? E.g. how much for cons cells (or whatever that make up lists), how much for a data type with only nullary data constructors -- should I use Word8s instead? -- how much for tuples, and so on. I realize I can (and I do somewhat) use profiling to determine heap use, but it'd be nice to be able to do back-of-envelope calculations and have some idea of what's the right approach. So, any pointers or thoughts? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
While waiting for the gurus to bestow upon me fragments of their wisdom, I've stumbled further on my path to enligthenment: ketil@ii.uib.no (Ketil Z. Malde) writes:
E.g. how much [space] for [...] a data type with only nullary data constructors -- should I use Word8s instead?
From my superficial testing
data Alphabet = A | B | C | D is no worse than using Word8. Is this a correct observation? Would it change if I somehow managed to get things to work with Word8# instead, or will the compiler automatically unbox things when I stuff them in tuples, lists or arrays anyway? The GHC docs seem to discourage using unboxed types. (BTW, it took me a while to discover that Word8 hides in PrelWord. I may have missed some obvious place to look, but perhaps it could be better documented?)
I realize I can use profiling to determine heap use,
Actually, I can't. Binaries created with ghc -prof -auto-all segmentation fault on startup. This is GHC 5.02.1 installed from an RPM on a RH7.2 box. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (4)
-
Hal Daume III -
ketil＠ii.uib.no -
Nicholas Nethercote -
Simon Marlow