October 2001 - Glasgow-haskell-users

Re: scope in ghci
by Marcin 'Qrczak' Kowalczyk 05 Oct '01

05 Oct '01

Fri, 05 Oct 2001 15:14:15 +0400, S.D.Mechveliani <mechvel(a)math.botik.ru> pisze: > Dm1> sort $ dm1 [1%2,1%3] -- contrived example > is impossible. > Instead, it needs > Dm1> List.sort Prelude.$ dm1 [1 Ratio.% 2, 1 Ratio.% 3] This happens when the module Dm1 is compiled. It's because a compiled module doesn't provide the information which names were in scope in its source. Perhaps ghc should use the .o/.hi files for execution and parse its .hs for getting this information if it's set as the current module. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

what is :a
by S.D.Mechveliani 05 Oct '01

05 Oct '01

Who would tell, please, what is the real difference between :load and :add in ghci-5.02 ? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

scope in ghci
by S.D.Mechveliani 05 Oct '01

05 Oct '01

Dear GHC, Consider the following question concerning scopes in ghc -interpreted. A large application called D consists of 70 modules, it reexports all its public items via module DExport. It has also demonstration examples Dm1.hs ... Dm9.hs. Each example imports 4-5 modules from D and lists precisely the imported items, like this: import List (sort) import Foo1 (f, g, Dt(..)) There also exists the total Dm.hs which reexports Dm1 ... Dm9 and adds the total `test' function. All this compiles successfully (Dm* may skip compilation). Then, ghci -package D Dm1 ... Dm1> sort $ dm1 [1%2,1%3] -- contrived example is impossible. Instead, it needs Dm1> List.sort Prelude.$ dm1 [1 Ratio.% 2, 1 Ratio.% 3] Also the user is expected to command :m DExport and work with other modules than Dm*. I try to improve this as follows. Add (...module Prelude, module List, module Ratio, module Random...) import Prelude; import List; import Ratio; import Random; to DExport.hs and replace the import part in Dm1.hs ... Dm9.hs with import DExport Formally, everything works. But I doubt. DExport imports and exports so many things that it looks natural to add all the standard Haskell library to it. But the imports of Dm1.hs ... Dm9.hs are different. I wonder, what is the difference between M.hs: ...import Foo (f,g) and N.hs: ...import DExport First, suppose M.hs contains name clashes with DExport and wants to avoid qualified names. Second, when compiling M.hs the name search is smaller (would it compile any essentially faster?). Third, how GHC will react at :load Dm ? By occasion, would not it load 9 copies of DExport ? Shortly: is this all right to set import DExport to all the above Dm* ? Thanks to everyone for possible advice. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: enormous executable
by Simon Marlow 04 Oct '01

04 Oct '01

> I don't think the native ld on alpha-dec-osf3 supports such a feature, > so we would (I assume) have to leave -split-objs in ghc even if we do > implement -ffunction-sections/-fdata-sections. (Would it just be a > matter of enabling it when invoking gcc? Would I be able to try it on > my i386-linux box with -optc-ffunction-sections? Or I suppose the > mangler would need to be educated...) AFAIK it only works on ELF, and only with GNU ld. You could take advantage of it when doing unregisterised compilation, but otherwise we have to teach the mangler about it. And there's bound to be some complication due to the assumptions we make in the RTS about the relative ordering of code/data. Cheers, Simon

2 1

RE: enormous executable
by Simon Marlow 03 Oct '01

03 Oct '01

> | Surely the executable itself is only linked with the > | functions that are actually used by the program? > > AFAIUI the GNU linker is not clever enough to remove junk > on a per-function basis, only on a per-object basis. This is > why we do object-splitting -- by breaking libraries up into > thousands of .o files before rolling them into a .a, the > effectiveness of what GNU ld can do is enhanced. > > Perhaps more recent GNU ld's do better on some platforms? > I have a vague recollection of some -gc-sections flag. Yup, but it needs compiler support. The idea is to get the compiler to put each function in its own section, then the linker removes unused sections from the linked image. Cheers, Simon

3 2

RE: ghc-pkg
by Simon Marlow 02 Oct '01

02 Oct '01

> I notice that the method for detecting the configuration of ghc (for > building 'hmake') no longer works with 5.02. This must be the most > unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, > and now 5.02 as well! > > > ghc-pkg-5.00 --show-package std --field import_dirs > /usr/malcolm/local/lib/ghc-5.00/imports/std > > ghc-pkg-5.02 --show-package std --field import_dirs > $libdir/imports/std > > There does not appear to be any way to persuade the new ghc-pkg to > reveal what $libdir is set to. Can someone give me a clue how to > discover this information? Oh woe is me. Sorry about that - we went to some effort to make the package configuration independent of the installation location, in order to make various things less fragile. The installation location can be discovered on a Unix system by looking up the -B<dir> argument in the ghc script. On a Windows installation, you have to derive $libdir from the location of GHC itself. Perhaps it would be easier to have hmake just invoke 'ghc --make' under the hood? Cheers, Simon

2 1

Re: enormous executable
by Marcin 'Qrczak' Kowalczyk 02 Oct '01

02 Oct '01

Mon, 1 Oct 2001 09:55:11 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > We don't have support for shared libraries under Unix at the moment. It > has been investigated at various times in the past, and I believe the > story is that we couldn't do it without at least losing some performance > (more performance loss than you get from compiling C into a shared > library). There is also a big problem of binary incompatibility between different versions of ghc, and dependence on the exact version of modules our package depends on. Dynamic libraries work for C because C has a very stable ABI. Also it's easy to maintain binary compatibility in libraries. I'm afraid that cross-module optimizations of ghc make dynamic libraries nearly impractical. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

ghc-pkg
by Malcolm Wallace 02 Oct '01

02 Oct '01

I notice that the method for detecting the configuration of ghc (for building 'hmake') no longer works with 5.02. This must be the most unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, and now 5.02 as well! > ghc-pkg-5.00 --show-package std --field import_dirs /usr/malcolm/local/lib/ghc-5.00/imports/std > ghc-pkg-5.02 --show-package std --field import_dirs $libdir/imports/std There does not appear to be any way to persuade the new ghc-pkg to reveal what $libdir is set to. Can someone give me a clue how to discover this information? Regards, Malcolm

1 0

enormous binaries
by Willem Robert van Hage 02 Oct '01

02 Oct '01

Hello, I'm trying out GHC along with gtk+hs and iHaskell and I was surprised that a simple example with a list of selectable distribution names generated a binary of 2Mb. So I tried a simple hello world example exactly like the one I saw somewhere on the GHC pages that compiled to a binary of 6kb and I was surprised to see that even after stripping the binary it still takes up 140kb. Is there a good explanation for this? Am I doing something wrong or is it something else? ~/haskell/ghc-test % cat hello.hs module Main where main = putStrLn "hello, world!" ~/haskell/ghc-test % ghc -o hello hello.hs ~/haskell/ghc-test % ls -l total 212 -rwxr-xr-x 1 willem users 201453 Sep 29 09:55 hello -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o ~/haskell/ghc-test % strip hello ~/haskell/ghc-test % ls -l total 152 -rwxr-xr-x 1 willem users 141024 Sep 29 09:59 hello -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o ~/haskell/ghc-test % strings hello > strs I attached the file strs, maybe someone can deduce something from its contents... Willem van Hage -- wrvh(a)xs4all.nl | http://www.xs4all.nl/~wrvh wrvhage(a)science.uva.nl | http://quest.sourceforge.net

2 1

RE: More 5.02 downloads
by Simon Marlow 01 Oct '01

01 Oct '01

> Is there any chance of a MacOSX binary release? We're not planning to make one ourselves, but hopefully one of our friends with MacOS X expertise will help out: Atze, Sebastien - any plans? Cheers, Simon

2 1