Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> (define coverage-trap (make #:behaviour cover-entry))
>
> You don't have to use goops to get a trap do you?
In terms of the low-level call outs from the evaluator, no. In terms
of the infrastructure that (i
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> (define coverage-trap (make #:behaviour cover-entry))
You don't have to use goops to get a trap do you?
> guile-statprof does a better job of trying to mitigate the
> latter factor, so is in fact a better current bet for profiling Guile
> code.
I ex
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> This might also be a good idea to apply to 1.8.
Yes, it's a bit obscure otherwise.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
glossed over details of how to get the current time, and time
arithmetic, so this probably won't work as is, but the intent should
be clear.
It will also be slow, and will incorrectly increase the time of
non-"leaf" code by the time t
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> Besides, it _really_ doesn't work here (see backtrace in my previous
>> post):
>
> the program I posted was tested with GUILE 1.8, perhaps you can start from
> there.
That's what I did (see my previous message). :-(
Thanks,
Ludovic.
PS: BTW
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Unfortunately, this is way too slow.
>>
>> **
>> [EMAIL PROTECTED] lilypond]$ time lilypond input/example-1
>> GNU LilyPond 2.11.10
>>
>> Hangup
>>
>> real0m2.534s
>> user0m2.456s
>> sys 0m0.063s
>>
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Unfortunately, this is way too slow.
>
> **
> [EMAIL PROTECTED] lilypond]$ time lilypond input/example-1
> GNU LilyPond 2.11.10
>
> Hangup
>
> real0m2.534s
> user0m2.456s
> sys 0m0.063s
>
>
> [EMAIL PROTECTED] lilypond]$ time lilypond
Neil Jerram escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Since noone responded, I decided to take a look myself.
>> My overall idea was to do the following:
>>
>> - at the top of deval(), find out current source file and line
>
> OK, but with the code where you have it at the mo
Neil Jerram escreveu:
>>> Do you think you need to do this in C? (You might do, for reasonable
>>> performance - I genuinely don't know yet.) The evaluator already has
>>> hooks (see "Evaluator trap options" in the manual) that allow you to
>>> call out to arbitrary Scheme code at the entry and e
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] info]$ guile
>> guile> (trap-enable 'enter-frame-handler)
>> throw from within critical section.
>> Abortado
>
> Same here with HEAD and 1.8.0. Here's what happens:
>
> #0 0x0fc13f6c in r
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] info]$ guile
> guile> (trap-enable 'enter-frame-handler)
> throw from within critical section.
> Abortado
Same here with HEAD and 1.8.0. Here's what happens:
#0 0x0fc13f6c in raise () from /lib/tls/libc.so.6
#1 0x0fc15a
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Neil Jerram escreveu:
>> Do you think you need to do this in C? (You might do, for reasonable
>> performance - I genuinely don't know yet.) The evaluator already has
>> hooks (see "Evaluator trap options" in the manual) that allow you to
>> call out
Neil Jerram escreveu:
> Do you think you need to do this in C? (You might do, for reasonable
> performance - I genuinely don't know yet.) The evaluator already has
> hooks (see "Evaluator trap options" in the manual) that allow you to
> call out to arbitrary Scheme code at the entry and exit of e
Neil Jerram escreveu:
>> - invoke some kind of callback that increments a counter for the
>> source location
>>
>> - produce pretty pretty coverage graphs with the contents of the hash
>>
>> The last two steps are trivial, but I'm getting lost with the first
>> step.
>>
>> I tried to follow what
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Since noone responded, I decided to take a look myself.
> My overall idea was to do the following:
>
> - at the top of deval(), find out current source file and line
OK, but with the code where you have it at the moment, you'll miss
tail-recursive c
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> - at the top of deval(), find out current source file and line
I suppose even cuter would be tracking each form being evaluated, not
just by line. Does the debugger interface have some single step that
could help? (I've never gotten into that.)
Hi,
On Tue, 2007-01-09 at 10:10 +0100, Ludovic Courtès wrote:
> For Scheme-level profiling, you may want to use the `statprof' module
> currently available in guile-lib. It's very easy to set up and provides
> results similar to `gprof' (it's a statistical profiler, too).
>
> For Scheme-level co
Ludovic Courtès escreveu:
> [...]
>
>> +int scm_do_profiling;
>
> Are you interested in just profiling or coverage? C-level or
> Scheme-level? (I assume the latter.)
they are related, but mainly coverage a la gcov for now.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~han
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Han-Wen Nienhuys escreveu:
>> I'd like to run a coverage check on the lilypond source.
>> How do I do this in GUILE?
>
> Since noone responded, I decided to take a look myself.
[...]
> +int scm_do_profiling;
Are you interested in just profili
Han-Wen Nienhuys escreveu:
> I'd like to run a coverage check on the lilypond source.
> How do I do this in GUILE?
Since noone responded, I decided to take a look myself.
My overall idea was to do the following:
- at the top of deval(), find out current source file and line
- invoke some ki
Hi,
I'd like to run a coverage check on the lilypond source.
How do I do this in GUILE?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listi
21 matches
Mail list logo
