Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I've found a memory leak in GUILE.
>
> The contents of modules are not garbage collected.
I believe this is fixed in CVS HEAD now in the 'proper' way:
guile> (define g (make-guardian))
guile> (g (make-module))
guile> (gc)
guile> (g)
Marius Vollmer wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
I've found a memory leak in GUILE.
The contents of modules are not garbage collected.
I believe this is fixed in CVS HEAD now in the 'proper' way:
guile> (define g (make-guardian))
guile> (g (make-module))
guil
Marius Vollmer wrote:
I think this change is a too large to go into 1.6, tho. Is there a
workaround that you could put into your code, such as
(set-procedure-property! (module-eval-closure M) 'module #f)
in an appropriate place?
Well, almost. The scm_stand_in_scm_procs need to be weak to
Marius Vollmer <[EMAIL PROTECTED]> writes:
>
> There is no guarantee about the order in which objects are returned
> from a guardian. If you want to impose an order on finalization
> actions, for example, you can do that by keeping objects alive in
> some global data structure
I made the change below, it leaves the code alone, just grows the
buffer more each time, by a factor 1.5x so copying time is no longer
quadratic in the output size.
I think I'll do this in the 1.6 branch too. Backtraces there have
been slow to the point of unusable for me in some parsing stuff I'
Stephen Compall <[EMAIL PROTECTED]> writes:
>
> I also have a pure syntax-rules
That stuff was very slow last time I tried it. define-macro would be
better if you go the macro route.
> +SRFI 61 is implemented in the Guile core; there's no need to
> +use this module at the moment. However, it ma
On Tue, 2005-08-02 at 10:00 +1000, Kevin Ryde wrote:
> I think you should decide now if applications need to use that module
> or not. If not then may as well describe the full syntax with the
> main `cond' docs.
I went with the "not" route. As I previously wrote, code that breaks on
this would
