April 2001 - Glasgow-haskell-users

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

RE: -optCrts-M28m
by Simon Marlow 25 Apr '01

25 Apr '01

> Could ghc-5.00 explain, please, some changes in the compiler and > RTS options? > > 1. -hi-diffs worked in ghc-4.08 and now does not. It's now called -ddump-hi-diffs. Cheers, Simon

1 0

RE: make maintainer-clean (was: Re: The (Interactive) Glasgow Haskell Compiler -- version 5.00)
by Simon Marlow 25 Apr '01

25 Apr '01

> erm, not that I say, sticking to the standards is mandatory, but... ;) > > $ info standards 'Managing Releases' 'Makefile Conventions' > 'Standard Targets' > [...] > The reason we say "almost everything" is that running the command > `make maintainer-clean' should not delete `configure' even if > `configure' can be remade using a rule in the Makefile. More > generally, `make maintainer-clean' should not delete > anything that > needs to exist in order to run `configure' and then > begin to build > the program. This is the only exception; > `maintainer-clean' should > delete everything else that can be rebuilt. > [...] > > > There should be an additional target, e.g. "make cvs-clean", or > similar. Oh blimey. Ok, I'll make it not delete configure. Cheers, Simon

1 0