Rob Browning wrote:
Rob Browning <[EMAIL PROTECTED]> writes:
Hmm. Did I misunderstand. I thought your previous message said that
this was too big a change for the 1.6 series. Or did you mean that
you want to gear up for a 1.8 release now?
Nevermind. I see I hadn't read far enough in the
Rob Browning <[EMAIL PROTECTED]> writes:
> Hmm. Did I misunderstand. I thought your previous message said that
> this was too big a change for the 1.6 series. Or did you mean that
> you want to gear up for a 1.8 release now?
Nevermind. I see I hadn't read far enough in the thread yet. I'm no
Rob Browning <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>> Yes, I've already done that. Any idea of when we will see this in a
>>> release?
>>
>> As soon as Rob gets around to do it! :-)
>
> Hmm. Did I misunderst
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Yes, I've already done that. Any idea of when we will see this in a
>> release?
>
> As soon as Rob gets around to do it! :-)
Hmm. Did I misunderstand. I thought your previous message said that
this w
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Yes, I've already done that. Any idea of when we will see this in a
> release?
As soon as Rob gets around to do it! :-)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-d
Han-Wen Nienhuys wrote:
I'm not convinced that you have fixed the original problem. I've CVS
upped GUILE, and now LilyPond is again soaring to 750mb memory
footprints while processing many trivial files. The problem is a little
more acute, since I've upped the GC yield for performance reasons.
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
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Well, almost. The scm_stand_in_scm_procs need to be weak too.
It is; this change will remain in 1.6. Sorry that I wasn't clear
about that. With "too large" I was only referring to the changed
semantics of weak hash tables and guardians.
--
GPG: D
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 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
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:
isn't it possible to store the 'module property in a doubly weak hash
table?
That would work, but the 'module property would then be a special
case. If we can, we should solve the general problem, I'd say.
There is already a special case anyway: the 'arity property
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> isn't it possible to store the 'module property in a doubly weak hash
> table?
That would work, but the 'module property would then be a special
case. If we can, we should solve the general problem, I'd say.
The general problem being that cycles
Marius Vollmer wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
what happens if the weak (c[ad]r ITEM) is marked through a postponed
weak vector that you haven't processed yet? Then P is removed
erroneously, or am I missing something?
Hmm, you are right. I first have thought about this
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> what happens if the weak (c[ad]r ITEM) is marked through a postponed
> weak vector that you haven't processed yet? Then P is removed
> erroneously, or am I missing something?
Hmm, you are right. I first have thought about this behavior as a
feature
Marius Vollmer wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
I think the right fix is to change the weak hashtable marking
algorithm to properly cope with circular references like this. I will
try this and then come back to you.
Interesting. How would you go about doing that?
The
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> I think the right fix is to change the weak hashtable marking
>> algorithm to properly cope with circular references like this. I will
>> try this and then come back to you.
>
> Interesting. How would you go about doing that?
The marking would wo
On 7/10/05, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> Mikael Djurfeldt wrote:
> > Eval closures can be any arbitrary procedure which fulfills the
> > obligations of an eval closure. This has been used in the guile-tcltk
> > interface to make Tcl variables and functions look like ordinary
> > Sc
On 7/10/05, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> guile-tcltk, is that still alive?
Yes.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Mikael Djurfeldt wrote:
Eval closures can be any arbitrary procedure which fulfills the
obligations of an eval closure. This has been used in the guile-tcltk
interface to make Tcl variables and functions look like ordinary
Scheme variables. The SMOB eval closures is an optimization for the
stan
Mikael Djurfeldt wrote:
Eval closures can be any arbitrary procedure which fulfills the
obligations of an eval closure. This has been used in the guile-tcltk
interface to make Tcl variables and functions look like ordinary
Scheme variables. The SMOB eval closures is an optimization for the
standa
On 7/9/05, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> > That would be good, because the current fix (which is already
> > committed to CVS HEAD, and which removes the setting of the
> > procedure-property) still leaves code in modules.c which expects the
> > procedure-property to be set. If Han
Mikael Djurfeldt wrote:
On 7/7/05, Marius Vollmer <[EMAIL PROTECTED]> wrote:
I've fixed this by introducing a new function (eval-closure-module)
which returns the module of a closure via the eval-closure smob.
I think the right fix is to change the weak hashtable marking
algorithm to properly
Marius Vollmer wrote:
So the closure is a key in a weak hash-table, pointing to the module
as a value (using scm_stand_in_procs), the module is always marked
during GC. However, since the module points back to the closure via
the 'eval-closure slot, the key is always marked. Consequently,
neithe
On 7/7/05, Marius Vollmer <[EMAIL PROTECTED]> wrote:
> > I've fixed this by introducing a new function (eval-closure-module)
> > which returns the module of a closure via the eval-closure smob.
>
> I think the right fix is to change the weak hashtable marking
> algorithm to properly cope with circ
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've found a memory leak in GUILE.
>
> The contents of modules are not garbage collected.
>
> This seems to be related with two errors:
>
> - scm_stand_in_procs is a hashtable. I believe it should be weak_key
> hashtable, just like the scm_o
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Since noone has complained, I've taken the liberty of adding this to
> CVS guile 1.6 as well.
Humph. I can see that my slowness is to blame here, but usually
things like this should not happen... Let's hope your fix is
brilliant :-)
> Marius could
Neil Jerram wrote:
PS. I feel like a broken record, but when will GUILE 1.8 be out?
Out of interest, when would you like it, and for what feature(s) in
particular?
Oh, strings longer than 16mb would be nice. LilyPond can't deal with
certain unicode fonts because GUILE 1.6 can't create string
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I don't really know what I am doing, so please comment. FWIW, the
> test suite compiled without complaints.
[...]
> Since noone has complained, I've taken the liberty of adding this to
> CVS guile 1.6 as well. Marius could you prepare a
> release(c
Neil Jerram wrote:
I've found a memory leak in GUILE.
The contents of modules are not garbage collected. [...]
Your analysis sounds reasonable, but ...
If noone objects, I will merge this
patch tomorrow night.
Since noone has complained, I've taken the liberty of adding this to CVS
gu
Neil Jerram wrote:
If noone objects, I will merge this
patch tomorrow night.
... this does not leave me enough time to be sure that I'm happy with
it. Therefore unless you can wait a bit longer, I can't properly comment.
(This may not be a problem, of course, if others can be quicker than me.
Han-Wen Nienhuys wrote:
> Hi,
>
> I've found a memory leak in GUILE.
>
> The contents of modules are not garbage collected. [...]
Your analysis sounds reasonable, but ...
> If noone objects, I will merge this
> patch tomorrow night.
... this does not leave me enough time to be sure that I'm h
32 matches
Mail list logo
