RE: Profiling question
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:[EMAIL PROTECTED]] | Sent: 03 January 2003 19:30 | To: [EMAIL PROTECTED] | 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 * [EMAIL PROTECTED] * Often in error, never in doubt | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Template Haskell reification
| 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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Suggested improvements to .hi-boot files
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.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling question
Kirsten Chevalier [EMAIL PROTECTED] writes: 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)? 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? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Proposal for GHC documentation
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Run-time options in ghc on Linux
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: reaping fd's and flushing buffers
Sure enough, after I say that all my fd reaping issues are solved at the Haskell level, I've been bitten by issues that look like the RTS doing things behind my back wrt. reaping fd's etc. etc. Basically, while I used socketToHandle the fd's got closed prematurely, and once I eliminated all uses of it, the socket fd's appeared to leak despite attempts to explicitly close them. Also, there were some very strange goings-on with respect to attempts to flush buffers after the fd's they were being flushed to were closed. So, what are the semantics here? I wouldn't rule out a bug here. Sockets are actually implemented as two independent handles internally, one each for the read side and write side so that each side gets a separate buffer and duplex reading/writing from different threads is supported. The programmer still just sees a single Handle. The tricky bit is knowing when the socket can be closed: both sides have to be unreferenced by the program. We handle this by having the read side point to the write side, and then place the finalizer on the write side. The finalizer should then only run when both sides are unreferenced (of course, it's always better to do the closing explicitly if you can). ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reaping fd's and flushing buffers
On Mon, Jan 06, 2003 at 02:02:13PM -, Simon Marlow wrote: ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) Thanks, I've started brewing up a tree and I'll take that for a spin when it's done cooking. Thanks, Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Suggested improvements to .hi-boot files
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
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: --show-iface bug?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linking with object files
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling question
Ah, I'd definatly like to request it for GHC. as well as a version in the IO monad, I have wanted both on various occasions. John On Mon, Jan 06, 2003 at 12:55:35PM +, Malcolm Wallace wrote: Kirsten Chevalier [EMAIL PROTECTED] writes: 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)? 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? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
