- Glasgow-haskell-users

Profiling question
by Kirsten Chevalier 06 Jan '03

06 Jan '03

Hi, I'd like to be able to determine the percentage of allocated objects of a particular type at specific points in a program's execution. I know that I can use heap profiling to create a graph of memory usage broken down by type, but is there any way to record this information at particular points in the program (i.e., between two statements in a do-expression)? Thanks, Kirsten -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

3 2

Linking with object files
by Adrian Hey 06 Jan '03

06 Jan '03

Hello, I seem to be having some trouble doing this and have a couple of questions.. The first question is how do you use --make option when doing this? Section 4.5 of the users guide seems to contradictory to me. It states.. "The command line must contain one source file or module name" and later.. "If the program needs to be linked with additional objects (say, some auxilliary C code), these can be specified on the command line as usual." > ghc Main.hs foo.o is OK, but whenever I try this... > ghc --make Main.hs foo.o I get the error.. can't find module 'foo.o' <while processing "foo.o"> The second question is what object formats does ghc understand and is the object file suffix significant? If I try elf format, this is accepted without complaint but I get a broken executable (though this could well be because my assembler has generated a broken elf file). Using coff format seems OK. The files have a ".o" suffix in both cases. FWIW, I'm using ghc 5.04.2 on Win32 with the nasm assembler. Thanks -- Adrian Hey

1 0

RE: --show-iface bug?
by Simon Marlow 06 Jan '03

06 Jan '03

> John Meacham wrote: > > [...] --show-iface seems to not be able to show .hi files > created when > > profiling is turned on. [...] > > Use the (undocumented :-) option "-buildtag p" *before* > --show-iface, e.g. > > ghc -buildtag p --show-iface Foo.p_hi > > It doesn't work after --show-iface, neither does any > combination with -prof. > SimonM: Should this be fixed or documented as a feature? Fixed, the test is now disabled when doing --show-iface. Cheers, Simon

1 0

RE: Profiling question
by Simon Marlow 06 Jan '03

06 Jan '03

> If you were using nhc98, then you could use the following: > > import NonStdProfile > > f ... = do ... > profile "point A" actionA > profile "point B" actionB > > The non-standard operation > profile :: String -> a -> a > places a labelled marker line on the profile graph at the time instant > when the value is demanded. > > I don't know whether ghc has anything similar? No, but that strikes me as rather a good idea. I'll have a go at implementing it. Cheers, Simon

1 0

RE: Suggested improvements to .hi-boot files
by Simon Marlow 06 Jan '03

06 Jan '03

Thanks for the suggestions, George. May I suggest that a good place for these things is the "Feature Requests" tracker on the GHC SourceForge page - otherwise good suggestions tend to get lost if we don't implement them immediately. > I am using .hi-boot files quite a lot at the moment. I'm > very grateful for the recent > change to a more Haskelly syntax, but I have a couple of > suggestions for the GHC team > to implement in their no doubt ample free time. 8-) > > (1) Importing a module {-# SOURCE #-} into itself currently > produces a warning, but no other action > so far as I can see. I suggest instead that this provoke a > check that the .hi-boot module accurately > reflects reality. (Otherwise there is no way of checking is > there?) Or perhaps you could add a > pragma {-# RECURSIVE #-} at the top of the module that > indicates the presence of a .hi-boot file which > should be checked. We'd like to do something like this, but there's no simple hack that gets us there quickly. One for the feature requests page. > (2) Instance declarations (with empty bodies) should be permitted. Tricky, because an instance declaration in an interface has to name the dictionary function, and currently dictionary functions are given weird internal names (that might not be the only stumbling block). But we would like to do this. > (3) There should be an option to pass .hi-boot files through > cpp. This would not be particularly useful > to me, as I have already implemented a pre-compilation phase > which does just that, but it might > be useful for others. I'd say just use Makefiles for this. > (4) The manual should recommend using say the GHCi :info > command to find out that, > say, IO must be called GHC.IOBase.IO. (If I'd known this > it'd have saved me having > to trawl through the GHC sources.) Good point. I'll add a note to the docs. > Obviously one would > ideally be able to type IO rather > than GHC.IOBase.IO, but my guess would be that this would be > (a) harder to implement than > the other suggestions, (b) less useful. We looked into this, but couldn't find an easy way to do it. > Happy New Year by the way. If any Simon is still reading, > about long have we got before the > current old library hierarchy is done away with in an > official release? Sometime before then > I will need to carry out a massive global-exchange. I'd planned to remove hslibs in the next major release, but that might prove to be too soon - especially since hslibs still contains some stuff that hasn't moved over to the hierarchy yet. So it will probably be the next-but-one major release; as usual, feedback from you folks out there is welcome. Cheers, Simon

1 0

RE: Run-time options in ghc on Linux
by Simon Marlow 06 Jan '03

06 Jan '03

> Ok, > $ cat >null.hs > module Main(main) where > main = return () > $ ghc null.hs -o null > $ ./null +RTS -? > $ Is your GHCRTS environment variable set to anything? Cheers, Simon

1 0

RE: Proposal for GHC documentation
by Simon Marlow 06 Jan '03

06 Jan '03

> > The rewritten documentation can be translated > > to HTML using just a standard xsltproc tool (available > > for both Cygwin & Linux) and XSLT DocBook stylesheet. > > The main advantage of XML version is that there is > > already developed XSLT stylesheet which generates > > input for Microsoft HTML Help Compiler. > ... > > I think that this will made GHC documentation much more easy > > for reading and browsing. > > I would strongly support such a change. Me too, I'm happy for us to move to DocBook/XML if that would give us more functionality and compatibility with existing tools, and it seems that this is the case. I imagine the updated docs will continue to work with an existing DocBook system as long as the DocBook 4 DTD is installed? If that's the case, would you like to commit your changes Krasimir? Cheers, Simon

1 0

Suggested improvements to .hi-boot files
by George Russell 06 Jan '03

06 Jan '03

I am using .hi-boot files quite a lot at the moment. I'm very grateful for the recent change to a more Haskelly syntax, but I have a couple of suggestions for the GHC team to implement in their no doubt ample free time. 8-) (1) Importing a module {-# SOURCE #-} into itself currently produces a warning, but no other action so far as I can see. I suggest instead that this provoke a check that the .hi-boot module accurately reflects reality. (Otherwise there is no way of checking is there?) Or perhaps you could add a pragma {-# RECURSIVE #-} at the top of the module that indicates the presence of a .hi-boot file which should be checked. (2) Instance declarations (with empty bodies) should be permitted. (3) There should be an option to pass .hi-boot files through cpp. This would not be particularly useful to me, as I have already implemented a pre-compilation phase which does just that, but it might be useful for others. (4) The manual should recommend using say the GHCi :info command to find out that, say, IO must be called GHC.IOBase.IO. (If I'd known this it'd have saved me having to trawl through the GHC sources.) Obviously one would ideally be able to type IO rather than GHC.IOBase.IO, but my guess would be that this would be (a) harder to implement than the other suggestions, (b) less useful. Happy New Year by the way. If any Simon is still reading, about long have we got before the current old library hierarchy is done away with in an official release? Sometime before then I will need to carry out a massive global-exchange.

1 0

RE: Template Haskell reification
by Simon Peyton-Jones 06 Jan '03

06 Jan '03

| Why is it that one can't reify top level function declarations? At the | moment it only seems that we can reify type declarations. No immediate | reason for this seems to spring to mind, but there may be one. [I'm interested to know something about your application, incidentally.] Several reasons conspire. a) Inconvenience (it's a little tiresome to implement) b) It would be particularly difficult to get the definition of a function defined in another module (because we'd have to read that entire module too). This is not true of data type declarations, which travel in interface files, so there is no ugly cross-module issue to worry about. c) I'm not quite clear what you'd expect to get. If we have f = ...f... it's easy enough. If you have mutual recursion f = ...g... g = ...f... do you get just f's definition, or g's too? If it's a pattern binding (f,g) = ... you can't avoid getting both. And even if it's a simple, non-recursive defn f = ....g.... (where g is defined earlier), I wonder whether there should be some way to get at g's definition too.

1 0

RE: Profiling question
by Simon Peyton-Jones 06 Jan '03

06 Jan '03

Not currently. It's not clear what a "point" in execution *is*! The top-level IO monad thread might provide such a point, but even then it might not be clear how much of a lazy data structure had been evaluated by that "point". I could see sense in having an I/O operation markProfile :: String -> IO () which would put a labelled vertical line on the profile to say when that "point" was. Simon | -----Original Message----- | From: Kirsten Chevalier [mailto:krc@uclink.berkeley.edu] | Sent: 03 January 2003 19:30 | To: glasgow-haskell-users(a)haskell.org | Subject: Profiling question | | Hi, | I'd like to be able to determine the percentage of allocated objects of a | particular type at specific points in a program's execution. I know that I | can use heap profiling to create a graph of memory usage broken down by type, | but is there any way to record this information at particular points in the | program (i.e., between two statements in a do-expression)? | | Thanks, | Kirsten | | -- | Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0