- Glasgow-haskell-users

How to read heap Profile?
by Saswat Anand 06 Oct '01

06 Oct '01

Hi, Ghc doc does not say much about how to read the heap profile (.hp file). Could somebody explain. And how can one tell from the graph generated by hp2ps if the program has space leak. Thanks, Saswat

2 1

Re: UniCode
by Marcin 'Qrczak' Kowalczyk 05 Oct '01

05 Oct '01

05 Oct 2001 14:35:17 +0200, Ketil Malde <ketil(a)ii.uib.no> pisze: > Does Haskell's support of "Unicode" mean UTF-32, or full UCS-4? It's not decided officially. GHC uses UTF-32. It's expected that UCS-4 will vanish and ISO-10646 will be reduced to the same range U+0000..10FFFF as Unicode. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

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

05 Oct '01

To my >> [..] >> 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] Marcin 'Qrczak' Kowalczyk <qrczak(a)knm.org.pl> writes > 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. > [..] In this particular experiment Dm1 ... Dm9 were *interpreted* and the rest D project was compiled and loaded as object code from library via package. But the case of compiled Dm1 is sufficient too to present certain small question. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: UniCode
by Marcin 'Qrczak' Kowalczyk 05 Oct '01

05 Oct '01

Fri, 5 Oct 2001 02:29:51 -0700 (PDT), Krasimir Angelov <ka2_mail(a)yahoo.com> pisze: > Why Char is 32 bit. UniCode characters is 16 bit. No, Unicode characters have 21 bits (range U+0000..10FFFF). They used to fit in 16 bits a long time ago, and they are sometimes encoded as UTF-16 (each character occupies one or two 16-bit words). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

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