- Glasgow-haskell-users

GHC 5.02.2 installation/compilation problems
by Nicholas Nethercote 25 Jan '02

25 Jan '02

Hi, I just installed GHC 5.02.2 (actually, the latest version from CVS), and had a strange problem. My first attempt worked ok, but I screwed something up, so I junked it and started again from scratch. This time, it died part-way through the "make boot" step for ghc itself, because glafp-utils/mkdependC/mkdependC had not been built. To fix the problem I just went to that directory and made mkdependC myself first, and then recompiled from $(BUILD), which worked. Does anyone have any idea why mkdependC may not have been built in the first place? Also, when I try to compile for ticky-ticky profiling by setting GhcCompilerWays=t and GhcLibWays=t in $(BUILD)/mk/build.mk, and then running "make all" in $(BUILD), it compiles for a short time and then dies with this error message: <lots of stuff...> ------------------------------------------------------------------------ ==fptools== make way=t all; PWD = /local/scratch-1/njn25/ws/build/ghc/compiler ------------------------------------------------------------------------ /homes/njn25/local/bin/ghc-5.02.2 -o ghc_t-5.03 -ldl -cpp ... <many files> /usr/bin/ld: cannot find -lHSutil_t collect2: ld returned 1 exit status <<ghc: 4187340 bytes, 2 GCs, 126260/126260 avg/max bytes residency (1 samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (0.32 elapsed), 0.03 GC (0.03 elapsed) :ghc>> make[3]: *** [ghc_t-5.03] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/local/scratch-1/njn25/ws/build/ghc' make: *** [all] Error 1 Am I doing something wrong? Has something been broken in 5.02.2? In case it's useful, here's the exact steps I took: - CVS checkout happy, ghc, hslibs - make build tree with sym links to code tree - run autoconf in $(BUILD) and in ghc/$(BUILD) - run ./configure in $(BUILD), with apt. --prefix and --with-ghc values - create $(BUILD)/mk/build.mk: ProjectsToBuild = happy hslibs ghc GhcCompilerWays= GhcLibWays= (for ticky-ticky profiling, I added "t" to the last two lines) - run "make all" in $(BUILD) Thanks for the help. -- Nick Nethercote njn25(a)cam.ac.uk

1 0

ANNOUNCE: popenhs-1.00.0 released
by Jens Petersen 25 Jan '02

25 Jan '02

Version 1.00.0 of popenhs is out. You can get it from: http://www.01.246.ne.jp/~juhp/haskell/popenhs/ popenhs is a small library providing lazy string output from and input to a subprocess. The interface provided by "popen" now differs from the "popen3" offered in 0.00 by taking an input string argument instead of returning an input handle. Thanks to Uwe Schmidt for reporting the problem in the previous release of popen3 hanging on a closed input pipe, that led to this new implmentation, which I believe fixes the problem. Jens

1 0

[Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
by Wolfgang Jeltsch 25 Jan '02

25 Jan '02

Hello, I use GHC 5.00.2 on Solaris 2.6 at the university and am unable to use hierarchical module names --- with and without the -fglasgow-exts switch. GHCi notifies me of parse errors on the module name. What is interesting is that if my module with hierarchical name imports a module which cannot be found GHC tells me that it cannot find the latter module instead of first recognizing that the name of the former module is in its opinion illegal and complaining about this. Aren't hierarchical module names supported yet in GHC 5.00.2? At home with GHC 5.02 under Linux everything works fine. By the way, I couldn't find anything about hierarchical module names in the documentation. Wolfgang

2 1

ignore, please
by S.D.Mechveliani 25 Jan '02

25 Jan '02

this is mail test, ignore, please

1 0

Re: notes on ghc-5.02.2. Reply
by Ashley Yakeley 24 Jan '02

24 Jan '02

At 2002-01-24 06:52, Ketil Z. Malde wrote: >GHC is in Debian, you probably want to use a cutting-edge release >(i.e. sid or at least woody) to be reasonably current. ghc5 in woody and sid is 5.02. If anyone would has a deb for the latest release, that would be very useful... -- Ashley Yakeley, Seattle WA

1 0

notes on ghc-5.02.2. Reply
by S.D.Mechveliani 24 Jan '02

24 Jan '02

To my notes on ghc-5.02.2 Simon Marlow writes >> * up-arrow key does not work in ghci, >> and it worked in binary installation. >> Probably, some library was not found. How to fix this? > Do you have the readline-devel RPM installed? This is needed to compile > GHC with readline support. I run ghc here on two machines. And it appears now that both are under Debian Linux. Some people here say that this RPM does not go under Debian. Maybe, GHC can take care of Debian? Would it help now, after `make all', `make install', setting LD_LIBRARY_PATH or such, making symbolic links? >> * The interpreted code looks 2-3 times larger than compiled one. >> DoCon-library has size 11 Mb, >> .o files of compiled test take less than 2 Mb, >> test loading ghci -package docon T_ +RTS -Mxx -RTS >> >> needs xx = 12 for the compiled full test T_, >> 31 for interpreted T_. >> If DoCon-library is out of the heap reserved by -M (is it?), >> then, we have that interpreted code is 2.6 times larger. >> Is this due to large interaces kept in heap? > Compiled code isn't loaded into the heap, so it isn't included in the > size you give to -M. > > What are "interaces"? A typo. Module interfaces. In any case, I could confuse things, not understanding these implementation details, only observe that the interpreted code looks 2-3 times larger. Maybe, it is natural, maybe not, I do not know. Another question: am I in glasgow-haskell-users.. ? I am responding to Simon's respond to my letter to glasgow-haskell-users.. sent a couple of hours ago, and I had not recieved this my letter, so far. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: notes on ghc-5.02.2
by Simon Marlow 24 Jan '02

24 Jan '02

> Some questions > -------------- > > * up-arrow key does not work in ghci, > and it worked in binary installation. > Probably, some library was not found. How to fix this? Do you have the readline-devel RPM installed? This is needed to compile GHC with readline support. > I have stored config.log of `./configure ...' > and makeall.log of `make all'. > `make boot' (before `make all') did nothing and issued a > message recommending to run a thing something in some > subdirectory, and I skipped this command at all. Do I mistake? > > * the directory /share always neighboured to /bin /lib > in the installation directory. Why it is absent now? > Maybe, the up-arrow bug is related to this? /share is created when there is documentation to install. Probably you didn't install the documentation (it isn't installed by default). > * Where to find the ghc manual in the .ps form, > like set.ps provided by binary installation? There's a pre-formatted version on the GHC web site: http://www.haskell.org/ghc/docs/latest/set.ps > * The interpreted code looks 2-3 times larger than compiled one. > DoCon-library has size 11 Mb, > .o files of compiled test take less than 2 Mb, > test loading ghci -package docon T_ +RTS -Mxx -RTS > > needs xx = 12 for the compiled full test T_, > 31 for interpreted T_. > If DoCon-library is out of the heap reserved by -M (is it?), > then, we have that interpreted code is 2.6 times larger. Compiled code isn't loaded into the heap, so it isn't included in the size you give to -M. > Is this due to large interaces kept in heap? What are "interaces"? Cheers, Simon

1 0

notes on ghc-5.02.2
by S.D.Mechveliani 24 Jan '02

24 Jan '02

Dear GHC, Here are some comments on ghc-5.02.2. I have tested it in the following way. 1. Installed binary = ghc-5.02.2-i386-linux-unknown. 2. Compiled ghc-5.02.2-source with binary for linux-i386, under empty mk/build.mk, removed binary installation. 3. Compiled a large Haskell project DoCon under -O (making package, -fglasgow-exts, overlappings ...) 4. Run DoCon test. It looks all right. * It spends the memory in a better way when making a project and loading interpreted modules. * It looks fixed the bug with the value visibility in ghci in (let f = ...; let g = h f ...) Some questions -------------- * up-arrow key does not work in ghci, and it worked in binary installation. Probably, some library was not found. How to fix this? I have stored config.log of `./configure ...' and makeall.log of `make all'. `make boot' (before `make all') did nothing and issued a message recommending to run a thing something in some subdirectory, and I skipped this command at all. Do I mistake? * the directory /share always neighboured to /bin /lib in the installation directory. Why it is absent now? Maybe, the up-arrow bug is related to this? * Where to find the ghc manual in the .ps form, like set.ps provided by binary installation? * The interpreted code looks 2-3 times larger than compiled one. DoCon-library has size 11 Mb, .o files of compiled test take less than 2 Mb, test loading ghci -package docon T_ +RTS -Mxx -RTS needs xx = 12 for the compiled full test T_, 31 for interpreted T_. If DoCon-library is out of the heap reserved by -M (is it?), then, we have that interpreted code is 2.6 times larger. Is this due to large interaces kept in heap? Please, advise, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Why a context reduction stack overflow?
by Mike Gunter 23 Jan '02

23 Jan '02

Compilation, with ghc 5.02, of the following program: data Zero = Zero deriving Show data Succ a = Succ a deriving Show -- Compilations succeeds with the following line uncommented. -- t :: Succ Zero -- <============================= t = Zero `p` (Succ Zero) class P a b c | a b -> c where p :: a -> b -> c instance P Zero a a where p Zero a = a instance P a b c => P b a c where p b a = p a b main = putStrLn $ "Hello." succeeds with the indicated line uncommented. With it commented-out, the compilation fails with: Flip.hs:6: Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 ... `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `p at [Zero Succ Zero c]' arising from use of `p' at Flip.hs:6 When generalising the type(s) for t . Why? thanks, mike gunter

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 23 Jan '02

23 Jan '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > :m [+|-] [*]M1 ... [*]Mn (n >= 0) > > (nit: I would paraphrase to make n >= 1, since you start numbering at > 1. Wrap the whole M-list with optionality brackets if that's the > intended meaning (setting the scope to nothing? The default?)) The n >= 0 trick is used in the Haskell report so I thought it might be familiar to people here :-) > > Currently the non-* form isn't supported for compiled modules, and > > attempting to set an unsupported scope results in an error. > > Since, if I understand correctly, there is no explicit way of > differentiating between compiled and interpreted modules, so why not > simply fall back to interpreting the module in question? Because that requires a reload, which might be counter-intuitive (:m doesn't otherwise cause loading of modules), and furthermore it would erase any bindings made so far on the command line. But :m might emit a message like the following if you attempt to set the scope to the top-level of a compiled module: > :m Foo module 'Foo' is compiled; to include its top-level scope, try ':interpret Foo', ':reload', then ':m Foo'. Where ':interpret Foo' would force interpreting of module Foo starting from the next reload. Cheers, Simon

1 0