- Glasgow-haskell-users

memory map in ghci
by S.D.Mechveliani 27 Apr '01

27 Apr '01

Dear GHC-5.00, I cannot find where it is explained the memory distribution used by ghci. For example, after ghci +RTS -M16m -RTS ... Prelude> :l XX ... (YY.o loaded ...) ... (XX interpreted ...) do YY.o, XX take any of these 16Mb ? Are there any commands in ghci to get the memory map? It is something like space taken by loaded compiled programs, interpreted programs, by data, free space for program, free space for data, space for stack. Is the interpreted program treated as data? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Building nhc98-1.02 with ghc-5.00
by wbuss＠telda.net 26 Apr '01

26 Apr '01

Hello, the building of nhc98-1.02 with ghc-5.00 aborts with the message: Main.hs:8: Failed to find interface decl for `PrelGHC.(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#)' from module `PrelGHC' Any hints for interpretation? Kind regards, Wolfhard.

2 1

RE: :! ghc -c vs :c
by Simon Marlow 26 Apr '01

26 Apr '01

> The ghc interactive ghci compiles the module by the command > > :! ghc -c > > Has it sense to provide a command :compile (:c), > > having a meaningful name and a format similar to other commands, > like say :load > ? Yes, this is another thing we'd like to do, but haven't got around to yet. (you can always define your own :compile command using :def of course, but the benefit of a built-in one would be that it could take advantage of the in-memroy interfaces rather than reading them from the disk). Cheers, Simon

2 1

RE: :l XX libFoo.a
by Simon Marlow 26 Apr '01

26 Apr '01

> The :load command of the ghc-5.00 interpreter > first searches the needed compiled modules (*.o) and loads them > when finds. > But how to make it to search them in the object code library > xxx/libFoo.a ? > For it is better to keep the fixed *.o files in a library. > And `:load' works in the above situation similarly as > ghc -o XX.o ... > I tried :l XX libFoo.a, > but it does not work. GHCi can't load ordinary .a libraries, only .o/.so objects. However, you can make a .o from a .a using something like $ ld --whole-archive -o Foo.o -lFoo Perhaps we'll have a way to make this slightly less painful in the future. Cheers, Simon

1 0

:l XX libFoo.a
by S.D.Mechveliani 26 Apr '01

26 Apr '01

The :load command of the ghc-5.00 interpreter first searches the needed compiled modules (*.o) and loads them when finds. But how to make it to search them in the object code library xxx/libFoo.a ? For it is better to keep the fixed *.o files in a library. And `:load' works in the above situation similarly as ghc -o XX.o ... I tried :l XX libFoo.a, but it does not work. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

:! ghc -c vs :c
by S.D.Mechveliani 26 Apr '01

26 Apr '01

The ghc interactive ghci compiles the module by the command :! ghc -c Has it sense to provide a command :compile (:c), having a meaningful name and a format similar to other commands, like say :load ? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

memory in --make
by S.D.Mechveliani 26 Apr '01

26 Apr '01

Hello, It occurs that ghc-5.00 --make spends the memory in a particular way. Making my project via Makefile (envoking ghc driver many times) succeeds within -M29m. While ghc --make ... -Mxxx Mk.hs needs more than 50Mb, probably, because it keeps much intermediate information between compiling the modules. Still I managed to `make' it with -M29m by issueing the latter command two times more, after the insufficient-heap break. ghc --make still looks faster and better to arrange. Each time it compiles only remainging modules. Maybe, something can be done to avoid these heap-exhausted breaks? For, seeing that some modules remain to compile and heap is exhausted, ghc can save the intermediate information to disk giving the room for the next module compilation. Also it can restart the driver itself - with appropriate message - ? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

haskell.runtime.* ??
by Kwanghoon Choi 25 Apr '01

25 Apr '01

Hello, I managed to restore an option for GHC 5.00 to produce java output but I realized that I also need some runtime system to run the java program produced by GHC. I examined the GHC source tree and the GHC website but in vain. Where do I get the runtime system? Thanks in advance. Kwanghoon

1 0

RE: -make
by Simon Marlow 25 Apr '01

25 Apr '01

> I have two questions on ghc-5.00 -make. > > The User's Guide says in Section 4.5 that it is simpler to use > -make than the Makefile technique. > > 1. I try ghc -make Main.hs > > with Main.hs containing main = putStr "hello\n" > > (in ghc-5.00, binary, i386-unknown, Linux), > and it reports > ghc-5.00: unrecognised flag: -make > - ? The flag is actually '--make' (note the double dash). Apparently the documentation system has some problems rendering the double dash in printed mode. > 2. How to simplify (eliminate?) Makefile. > ----------------------------------------- > > My project has many .hs files in the directories > ./source/ > ./source/auxil/ > ./source/pol/factor/ > ... > `make ...' compiles them putting .hi, .o files into ./export/, > then, applies `ar' to make .a library. > To do all this, Makefile includes the rules like > > .hs.o: > $(HC) -c $< $(HCFlags) > > and applies the compiler $(HC) with the flags > > ... -syslib data -recomp ... > -i$(E) -odir $(E) -ohi $(E)/$(notdir $*).hi $($*_flags) > ... > Now, this Makefile does not work under ghc-5.00, because second > compilation cannot find .hi file of the first compilation: > > ..ghc -c source/auxil/Prelude_.hs -fglasgow-exts ... > -recomp -iexport -odir export -ohi export/Prelude_.hi > +RTS -G3 -F1.5 -M29m -RTS -Onot > ... > ..ghc -c source/parse/Iparse_.hs -fglasgow-exts ... > -recomp -iexport -odir export -ohi export/Iparse_.hi > +RTS -G3 -F1.5 -M29m -RTS -Onot > > source/parse/Iparse_.hs:20: > failed to load interface for `Prelude_': > Bad interface file: export/Iparse_.hi > does not exist This is indeed a bug: -ohi doesn't work properly in 5.00. I'm fixing it right now. > Also what -make can do to replace some large part of Makefile. > For > (a) Makefile has rather odd language, it is not good to force the > functional programmer to look into it, > (b) one has to think of Makefile versions for different operation > systems. The simplest way to work is to put the objects and .hi files in the same directory as the source. Then you can use --make like this: $ ghc --make -i<dir1>:<dir2>:... Main to put the objects in a single directory, you can use -odir <dir>. Unfortunately the .hi files can't be saved elsewhere when using --make. Cheers, Simon

1 0

RE: Why does --make only allow one module?
by Simon Marlow 25 Apr '01

25 Apr '01

> ghc --make would be wonderful for UniForM, which at the > moment consists of > a large selection of libraries, were it not for the restriction that > ghc --make insists on only having one module as an argument. Er why? > At this rate I shall be driven to writing an otherwise useless module > which imports all the modules in each directory, since ghc --make does > indeed look a lot faster than compiling each module individually. > (In particular, we win big here, I think because the NFS system is > very inefficient and makes reading all the .hi files very expensive.) > > Actually I'd like to just give ghc --make a list of ALL the > source files > and let it figure out the dependencies. This could also include > object files (compiled from C) which were to be linked in, > for example. It's something we'd like to do, but haven't got around to yet. Perhaps for 5.01. Cheers, Simon

1 0