Kevin Ryde escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> SCM
>> scm_make_srcprops (long line, int col, SCM filename, SCM copy, SCM plist)
>> {
>> + if (!SCM_UNBNDP (filename))
>> +plist = scm_acons (scm_sym_filename, filename, plist);
>
> Can those two cells be shared among a
Kevin Ryde escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> See attached patch.
>
> Sounds worryingly specific to what you're doing. Perhaps something
> which was just a hook to each function call made (by the debug
> evaluator), with the memoized and unmemoized form if that's necessar
Kevin Ryde escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> SCM
>> scm_make_srcprops (long line, int col, SCM filename, SCM copy, SCM plist)
>> {
>> + if (!SCM_UNBNDP (filename))
>> +plist = scm_acons (scm_sym_filename, filename, plist);
>
> Can those two cells be shared among a
Han-Wen Nienhuys escreveu:
> Lately, I have begun using GIT for managing version control
> in all my projects.
>
> Since I prefer to interface with GUILE using GIT as well, I have
> setup a CVS -> GIT import for guile-core, which is mirrored at
>
> http://repo.or.cz/w/guile.git
This is act
Han-Wen Nienhuys escreveu:
> Hi,
>
> See attached patch. This still has rough edges. For some reason, I
> don't catch the memoization of display to #.
This is fixed in attached patch.
This code
(define (x a b)
(let*
((z (+ a b)))
(if (>= z 3)
(begin
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> See attached patch. This still has rough edges. For some reason, I
> don't catch the memoization of display to #.
Overall, as Kevin suggested, I'd be more in favor of using the existing
trap mechanism (possibly extending it if it doesn't provide
Ludovic Courtès escreveu:
>> See attached patch. This still has rough edges. For some reason, I
>> don't catch the memoization of display to #.
>
> Overall, as Kevin suggested, I'd be more in favor of using the existing
> trap mechanism (possibly extending it if it doesn't provide enough
> informa
Hello,
what is the status of the eval options structure wrt binary compatibility?
Right now, it says
scm_t_option scm_evaluator_trap_table[] = {
{ SCM_OPTION_BOOLEAN, "traps", 0, "Enable evaluator traps." },
{ SCM_OPTION_BOOLEAN, "enter-frame", 0, "Trap when eval enters new frame." },
{
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I have doubts whether this can ever be good enough. For effective
> coverage analysis, you have a to run an entire test-suite with
> coverage enabled. Eg. for lilypond, the entire test-suite takes 5
> minutes on a 1.6ghz Core duo (single thread)
Hi,
Vector-move-left! modifies its 3rd argument rather than its 1st. As
such, it does not conform to the GUILE naming standards.
Should this be fixed, or is this an inconsistency in the standard?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Ludovic Courtès escreveu:
>> Of course, the patch that I posted is ad-hoc, because it hardcodes the
>> coverage analysis in eval.c. If it were to be included, I propose
>> something like
>>
>> (trap-set! 'memoize-symbol
>> record-coverage)
>> (trap-enable 'memoize-symbol)
>>
>> which
11 matches
Mail list logo
