* module GC bug
@ 2005-06-09 23:32 Han-Wen Nienhuys
2005-06-10 6:32 ` Neil Jerram
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-06-09 23:32 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
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_object_whash table. For, if a closure is
GC'd, so should it properties.
- in boot-9.scm, set-module-eval-closure! does
(set-procedure-property! closure 'module module))
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,
neither closure nor module are ever GC'd.
I've fixed this by introducing a new function (eval-closure-module)
which returns the module of a closure via the eval-closure smob. Find
the patch (including test) attached.
I don't really know what I am doing, so please comment. FWIW, the test
suite compiled without complaints. If noone objects, I will merge this
patch tomorrow night. Furthermore, I believe the same bug is in GUILE
1.6, so a 1.6.8 release is warranted IMO.
Greetings,
Han-Wen
PS. I feel like a broken record, but when will GUILE 1.8 be out?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
[-- Attachment #2: evalclos --]
[-- Type: text/plain, Size: 7736 bytes --]
? b
? core.11847
? core.8858
? evalclos
? gettext.m4
? libltdl
? t.scm
Index: INSTALL
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/INSTALL,v
retrieving revision 1.40
diff -u -r1.40 INSTALL
--- INSTALL 28 Sep 2004 19:33:40 -0000 1.40
+++ INSTALL 9 Jun 2005 23:27:25 -0000
@@ -1,7 +1,7 @@
Installation Instructions
*************************
-Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004 Free
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free
Software Foundation, Inc.
This file is free documentation; the Free Software Foundation gives
@@ -189,8 +189,13 @@
./configure CC=/usr/local2/bin/gcc
-will cause the specified gcc to be used as the C compiler (unless it is
-overridden in the site shell script).
+causes the specified `gcc' to be used as the C compiler (unless it is
+overridden in the site shell script). Here is a another example:
+
+ /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
+Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
+configuration-related scripts to be executed by `/bin/bash'.
`configure' Invocation
======================
Index: ice-9/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ice-9/ChangeLog,v
retrieving revision 1.650
diff -u -r1.650 ChangeLog
--- ice-9/ChangeLog 5 Jun 2005 17:26:07 -0000 1.650
+++ ice-9/ChangeLog 9 Jun 2005 23:27:27 -0000
@@ -1,3 +1,9 @@
+2005-06-10 Han-Wen Nienhuys <hanwen@xs4all.nl>
+
+ * boot-9.scm (set-module-eval-closure!): remove
+ set-procedure-property! closure 'module. Setting this property
+ causes un-gc-able modules.
+
2005-06-05 Marius Vollmer <mvo@zagadka.de>
* boot-9.scm (substring-fill!): New, for compatability.
Index: ice-9/boot-9.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ice-9/boot-9.scm,v
retrieving revision 1.349
diff -u -r1.349 boot-9.scm
--- ice-9/boot-9.scm 5 Jun 2005 17:24:52 -0000 1.349
+++ ice-9/boot-9.scm 9 Jun 2005 23:27:28 -0000
@@ -339,7 +339,7 @@
(define (environment-module env)
(let ((closure (and (pair? env) (car (last-pair env)))))
- (and closure (procedure-property closure 'module))))
+ (and closure (eval-closure-module closure))))
\f
@@ -1266,10 +1266,12 @@
(let ((setter (record-modifier module-type 'eval-closure)))
(lambda (module closure)
(setter module closure)
- ;; Make it possible to lookup the module from the environment.
- ;; This implementation is correct since an eval closure can belong
- ;; to maximally one module.
- (set-procedure-property! closure 'module module))))
+
+
+ ;; do not set procedure properties on closures.
+ ;; since procedure properties are weak-hashes, they cannot
+ ;; have cyclical data, otherwise the data cannot be GC-ed.
+ )))
\f
Index: libguile/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ChangeLog,v
retrieving revision 1.2281
diff -u -r1.2281 ChangeLog
--- libguile/ChangeLog 9 Jun 2005 19:33:38 -0000 1.2281
+++ libguile/ChangeLog 9 Jun 2005 23:27:35 -0000
@@ -1,3 +1,12 @@
+2005-06-10 Han-Wen Nienhuys <hanwen@xs4all.nl>
+
+ * modules.c (s_scm_eval_closure_module): new function. Return the
+ module inside an eval-closure.
+
+ * gc.c (scm_init_storage): make scm_stand_in_procs a weak_key hash
+ table. This means that procedure properties are GC'd if the
+ procedure dies.
+
2005-06-09 Han-Wen Nienhuys <hanwen@xs4all.nl>
* gc.c (tag_table_to_type_alist): convert tag number to "tag %d"
Index: libguile/gc.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/gc.c,v
retrieving revision 1.268
diff -u -r1.268 gc.c
--- libguile/gc.c 9 Jun 2005 19:33:38 -0000 1.268
+++ libguile/gc.c 9 Jun 2005 23:27:35 -0000
@@ -935,7 +935,7 @@
#endif
- scm_stand_in_procs = scm_c_make_hash_table (257);
+ scm_stand_in_procs = scm_make_weak_key_hash_table (scm_from_int (257));
scm_permobjs = SCM_EOL;
scm_protects = scm_c_make_hash_table (31);
scm_gc_registered_roots = scm_c_make_hash_table (31);
Index: libguile/modules.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/modules.c,v
retrieving revision 1.59
diff -u -r1.59 modules.c
--- libguile/modules.c 23 May 2005 19:57:20 -0000 1.59
+++ libguile/modules.c 9 Jun 2005 23:27:36 -0000
@@ -346,6 +346,19 @@
}
#undef FUNC_NAME
+
+SCM_DEFINE (scm_eval_closure_module, "eval-closure-module", 1, 0, 0,
+ (SCM closure),
+ "Return the module for @var{closure}.")
+#define FUNC_NAME s_scm_eval_closure_module
+{
+ SCM_ASSERT_TYPE(SCM_EVAL_CLOSURE_P (closure), closure, SCM_ARG1, FUNC_NAME, "eval-closure");
+ return SCM_PACK (SCM_CELL_WORD_1(closure));
+}
+#undef FUNC_NAME
+
+
+
SCM_DEFINE (scm_standard_interface_eval_closure,
"standard-interface-eval-closure", 1, 0, 0,
(SCM module),
Index: libguile/modules.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/modules.h,v
retrieving revision 1.26
diff -u -r1.26 modules.h
--- libguile/modules.h 23 May 2005 19:57:20 -0000 1.26
+++ libguile/modules.h 9 Jun 2005 23:27:36 -0000
@@ -98,6 +98,7 @@
SCM_API SCM scm_current_module_transformer (void);
SCM_API SCM scm_eval_closure_lookup (SCM eclo, SCM sym, SCM definep);
SCM_API SCM scm_standard_eval_closure (SCM module);
+SCM_API SCM scm_eval_closure_module (SCM closure);
SCM_API SCM scm_standard_interface_eval_closure (SCM module);
SCM_API SCM scm_get_pre_modules_obarray (void);
SCM_API SCM scm_lookup_closure_module (SCM proc);
Index: test-suite/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/ChangeLog,v
retrieving revision 1.350
diff -u -r1.350 ChangeLog
--- test-suite/ChangeLog 5 Jun 2005 21:38:22 -0000 1.350
+++ test-suite/ChangeLog 9 Jun 2005 23:27:37 -0000
@@ -1,3 +1,8 @@
+2005-06-10 Han-Wen Nienhuys <hanwen@xs4all.nl>
+
+ * tests/gc.test ("gc"): add a test to verify that modules are
+ garbage collected.
+
2005-06-06 Kevin Ryde <user42@zip.com.au>
* tests/strings.test (string-split): Try splitting on an 8-bit char.
Index: test-suite/tests/gc.test
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/tests/gc.test,v
retrieving revision 1.6
diff -u -r1.6 gc.test
--- test-suite/tests/gc.test 23 May 2005 19:57:22 -0000 1.6
+++ test-suite/tests/gc.test 9 Jun 2005 23:27:37 -0000
@@ -55,3 +55,17 @@
(gc)
(remove-hook! after-gc-hook thunk)
foo)))
+
+
+(with-test-prefix "gc"
+ (pass-if "Unused modules are removed"
+ (let*
+ ((dummy (gc))
+ (last-count (cdr (assoc
+ "eval-closure" (gc-live-object-stats)))))
+
+ (for-each (lambda (x) (make-module)) (iota 1000))
+ (gc)
+ (gc) ;; twice: have to kill the weak vectors.
+ (= last-count (cdr (assoc "eval-closure" (gc-live-object-stats)))))
+ ))
Index: test-suite/tests/hash.test
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/tests/hash.test,v
retrieving revision 1.3
diff -u -r1.3 hash.test
--- test-suite/tests/hash.test 23 May 2005 19:57:22 -0000 1.3
+++ test-suite/tests/hash.test 9 Jun 2005 23:27:37 -0000
@@ -65,7 +65,6 @@
;;;
;;; hashx-remove!
;;;
-
(with-test-prefix "hashx-remove!"
(pass-if (->bool (object-documentation hashx-remove!)))
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-09 23:32 module GC bug Han-Wen Nienhuys
@ 2005-06-10 6:32 ` Neil Jerram
2005-06-10 11:48 ` Han-Wen Nienhuys
` (2 more replies)
2005-07-07 18:42 ` Marius Vollmer
2005-08-01 0:20 ` Marius Vollmer
2 siblings, 3 replies; 31+ messages in thread
From: Neil Jerram @ 2005-06-10 6:32 UTC (permalink / raw)
Cc: guile-devel
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 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.)
> 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?
Regards,
Neil
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-10 6:32 ` Neil Jerram
@ 2005-06-10 11:48 ` Han-Wen Nienhuys
2005-06-19 13:32 ` Han-Wen Nienhuys
2005-06-24 17:50 ` Han-Wen Nienhuys
2 siblings, 0 replies; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-06-10 11:48 UTC (permalink / raw)
Cc: guile-devel
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.)
Well, we can always back out the patch if something goes horribly wrong.
>>PS. I feel like a broken record, but when will GUILE 1.8 be out?
>
> Out of interest, when would you like it,
Yesterday would have been nice.
> and for what feature(s) in
> particular?
Native fractions would be nice. And all of the code/fixes that I
contributed. All of the effort that I have put into GUILE CVS to date
has had zero return on value, since the result has not been shipped to
any of my end-users.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-10 6:32 ` Neil Jerram
2005-06-10 11:48 ` Han-Wen Nienhuys
@ 2005-06-19 13:32 ` Han-Wen Nienhuys
2005-06-19 17:33 ` Rob Browning
2005-07-07 18:48 ` Marius Vollmer
2005-06-24 17:50 ` Han-Wen Nienhuys
2 siblings, 2 replies; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-06-19 13:32 UTC (permalink / raw)
Cc: mvo, guile-devel
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
guile 1.6 as well. Marius could you prepare a release(candidate) of
1.6.8, or is Rob still the person responsible for doing 1.6 ?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-19 13:32 ` Han-Wen Nienhuys
@ 2005-06-19 17:33 ` Rob Browning
2005-07-07 18:48 ` Marius Vollmer
1 sibling, 0 replies; 31+ messages in thread
From: Rob Browning @ 2005-06-19 17:33 UTC (permalink / raw)
Cc: guile-devel, mvo, Neil Jerram
Han-Wen Nienhuys <hanwen@xs4all.nl> 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(candidate) of 1.6.8, or is Rob still the person responsible
> for doing 1.6 ?
Yes, I'm still responsible for 1.6, and while I appreciate your help,
I'm not comfortable with this change for a stable release until/unless
someone more knowledgable about the issue has a chance to review the
changes and comment (i.e. probably Marius).
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-19 13:32 ` Han-Wen Nienhuys
2005-06-19 17:33 ` Rob Browning
@ 2005-07-07 18:48 ` Marius Vollmer
1 sibling, 0 replies; 31+ messages in thread
From: Marius Vollmer @ 2005-07-07 18:48 UTC (permalink / raw)
Cc: guile-devel, Neil Jerram
Han-Wen Nienhuys <hanwen@xs4all.nl> 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 you prepare a release(candidate)
> of 1.6.8, or is Rob still the person responsible for doing 1.6 ?
Rob is still responsible. The release candidate would be the 'stable'
nightly snapshot from
ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots/
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-10 6:32 ` Neil Jerram
2005-06-10 11:48 ` Han-Wen Nienhuys
2005-06-19 13:32 ` Han-Wen Nienhuys
@ 2005-06-24 17:50 ` Han-Wen Nienhuys
2 siblings, 0 replies; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-06-24 17:50 UTC (permalink / raw)
Cc: guile-devel
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 strings long enough.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-09 23:32 module GC bug Han-Wen Nienhuys
2005-06-10 6:32 ` Neil Jerram
@ 2005-07-07 18:42 ` Marius Vollmer
2005-07-08 9:24 ` Mikael Djurfeldt
2005-07-08 21:43 ` Han-Wen Nienhuys
2005-08-01 0:20 ` Marius Vollmer
2 siblings, 2 replies; 31+ messages in thread
From: Marius Vollmer @ 2005-07-07 18:42 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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_object_whash table. For, if a closure is
> GC'd, so should it properties.
Yes.
> - in boot-9.scm, set-module-eval-closure! does
>
> (set-procedure-property! closure 'module module))
>
> 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,
> neither closure nor module are ever GC'd.
>
> 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 circular references like this. I will
try this and then come back to you. (I don't know how long this might
take since the required changes look to be slightly non-trivial (but
entirely possible).)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-07 18:42 ` Marius Vollmer
@ 2005-07-08 9:24 ` Mikael Djurfeldt
2005-07-09 8:28 ` Han-Wen Nienhuys
2005-07-08 21:43 ` Han-Wen Nienhuys
1 sibling, 1 reply; 31+ messages in thread
From: Mikael Djurfeldt @ 2005-07-08 9:24 UTC (permalink / raw)
Cc: Mikael Djurfeldt, guile-devel
On 7/7/05, Marius Vollmer <mvo@zagadka.de> 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 circular references like this. I will
> try this and then come back to you. (I don't know how long this might
> take since the required changes look to be slightly non-trivial (but
> entirely possible).)
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-Wen's fix is to be kept, then
you should, at least, remove that code. The consequence is that it
will no longer be possible to lookup the module of the eval closure
for any kind of closures except the standard ones (which are
implemented as a smob).
M
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-08 9:24 ` Mikael Djurfeldt
@ 2005-07-09 8:28 ` Han-Wen Nienhuys
2005-07-09 19:28 ` Mikael Djurfeldt
0 siblings, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-09 8:28 UTC (permalink / raw)
Cc: guile-devel, Marius Vollmer
Mikael Djurfeldt wrote:
> On 7/7/05, Marius Vollmer <mvo@zagadka.de> 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 circular references like this. I will
>>try this and then come back to you. (I don't know how long this might
>>take since the required changes look to be slightly non-trivial (but
>>entirely possible).)
>
>
> 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-Wen's fix is to be kept, then
> you should, at least, remove that code. The consequence is that it
> will no longer be possible to lookup the module of the eval closure
> for any kind of closures except the standard ones (which are
> implemented as a smob).
Hi,
I guess I'm missing something. Where is the 'module procedure property
set for other eval closures?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-09 8:28 ` Han-Wen Nienhuys
@ 2005-07-09 19:28 ` Mikael Djurfeldt
2005-07-09 23:25 ` Han-Wen Nienhuys
2005-07-09 23:32 ` Han-Wen Nienhuys
0 siblings, 2 replies; 31+ messages in thread
From: Mikael Djurfeldt @ 2005-07-09 19:28 UTC (permalink / raw)
Cc: Marius Vollmer, guile-devel
On 7/9/05, Han-Wen Nienhuys <hanwen@xs4all.nl> 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-Wen's fix is to be kept, then
> > you should, at least, remove that code. The consequence is that it
> > will no longer be possible to lookup the module of the eval closure
> > for any kind of closures except the standard ones (which are
> > implemented as a smob).
> [...]
> I guess I'm missing something. Where is the 'module procedure property
> set for other eval closures?
It was set in set-module-eval-closure! before this change:
2005-06-10 Han-Wen Nienhuys <hanwen@xs4all.nl>
* boot-9.scm (set-module-eval-closure!): remove
set-procedure-property! closure 'module. Setting this property
causes un-gc-able modules.
It is read by code in modules.c which (still) looks like this:
SCM
scm_lookup_closure_module (SCM proc)
{
if (scm_is_false (proc))
return the_root_module ();
else if (SCM_EVAL_CLOSURE_P (proc))
return SCM_PACK (SCM_SMOB_DATA (proc));
else
{
SCM mod = scm_procedure_property (proc, sym_module); <--- HERE
if (scm_is_false (mod))
mod = the_root_module ();
return mod;
}
}
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
standard case.
M
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-09 19:28 ` Mikael Djurfeldt
@ 2005-07-09 23:25 ` Han-Wen Nienhuys
2005-07-10 8:16 ` Mikael Djurfeldt
2005-07-09 23:32 ` Han-Wen Nienhuys
1 sibling, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-09 23:25 UTC (permalink / raw)
Cc: Marius Vollmer, 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
> standard case.
Hmmm. and we can't use procedure properties, since arbitrary procedures
store those with a weak hashtable.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-09 23:25 ` Han-Wen Nienhuys
@ 2005-07-10 8:16 ` Mikael Djurfeldt
0 siblings, 0 replies; 31+ messages in thread
From: Mikael Djurfeldt @ 2005-07-10 8:16 UTC (permalink / raw)
Cc: guile-devel, Marius Vollmer
On 7/10/05, Han-Wen Nienhuys <hanwen@xs4all.nl> 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
> > Scheme variables. The SMOB eval closures is an optimization for the
> > standard case.
>
> Hmmm. and we can't use procedure properties, since arbitrary procedures
> store those with a weak hashtable.
Obviously, this is a general problem with procedure properties. If
that problem is solved, the problem with the module property also goes
away.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-09 19:28 ` Mikael Djurfeldt
2005-07-09 23:25 ` Han-Wen Nienhuys
@ 2005-07-09 23:32 ` Han-Wen Nienhuys
2005-07-10 8:17 ` Mikael Djurfeldt
1 sibling, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-09 23:32 UTC (permalink / raw)
Cc: Marius Vollmer, 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
> standard case.
>
guile-tcltk, is that still alive?
> M
>
>
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-07 18:42 ` Marius Vollmer
2005-07-08 9:24 ` Mikael Djurfeldt
@ 2005-07-08 21:43 ` Han-Wen Nienhuys
2005-07-13 21:02 ` Marius Vollmer
1 sibling, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-08 21:43 UTC (permalink / raw)
Cc: guile-devel
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,
>>neither closure nor module are ever GC'd.
>>
>>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 circular references like this. I will
> try this and then come back to you.
Interesting. How would you go about doing that?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-08 21:43 ` Han-Wen Nienhuys
@ 2005-07-13 21:02 ` Marius Vollmer
2005-07-13 22:19 ` Han-Wen Nienhuys
0 siblings, 1 reply; 31+ messages in thread
From: Marius Vollmer @ 2005-07-13 21:02 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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 would rougly look like this (some special cases are
not considered, like improper alists):
mark OBJ:
if mark of OBJ is set:
return
set mark of OBJ
if OBJ is a weak vector
put it on POSTPONED_OBJECTS
else
mark references of OBJ
gc:
POSTPONED_OBJECTS = '()
mark all root references
while POSTPONED_OBJECTS not empty
OBJS = POSTPONED_OBJECTS
POSTPONED_OBJECTS = '()
mark_weak_vector all OBJS
sweep
mark_weak_vector OBJ:
for all elements ELT of OBJ:
for all pairs P on list ELT:
if P is marked, break
ITEM = car of P
if ITEM is a pair:
if (OBJ has weak keys and car of ITEM is unmarked)
or (OBJ has weak values and cdr of ITEM is unmarked)
remove P from ELT
else:
mark ITEM (recursively)
set mark of P
The non-trivial stuff is to integrate this properly with the abstract
hashtables (but I have basically done this already as well).
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-13 21:02 ` Marius Vollmer
@ 2005-07-13 22:19 ` Han-Wen Nienhuys
2005-07-16 18:57 ` Marius Vollmer
0 siblings, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-13 22:19 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> 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 would rougly look like this (some special cases are
> not considered, like improper alists):
>
> mark OBJ:
> if mark of OBJ is set:
> return
> set mark of OBJ
> if OBJ is a weak vector
> put it on POSTPONED_OBJECTS
> else
> mark references of OBJ
>
> gc:
> POSTPONED_OBJECTS = '()
> mark all root references
> while POSTPONED_OBJECTS not empty
> OBJS = POSTPONED_OBJECTS
> POSTPONED_OBJECTS = '()
> mark_weak_vector all OBJS
> sweep
>
> mark_weak_vector OBJ:
> for all elements ELT of OBJ:
> for all pairs P on list ELT:
> if P is marked, break
> ITEM = car of P
> if ITEM is a pair:
> if (OBJ has weak keys and car of ITEM is unmarked)
> or (OBJ has weak values and cdr of ITEM is unmarked)
> remove P from ELT
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?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-13 22:19 ` Han-Wen Nienhuys
@ 2005-07-16 18:57 ` Marius Vollmer
2005-07-17 18:50 ` Han-Wen Nienhuys
0 siblings, 1 reply; 31+ messages in thread
From: Marius Vollmer @ 2005-07-16 18:57 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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, but I now see that it is in fact not wanted. The order the
weak vectors are processed in affects the result, which is not good,
obviously.
Right now, I hope to get around this by repeatedly scanning all weak
vectors until no new markings have taken place, and only then remove
the unmarked items.
Thanks for pointing this out!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-16 18:57 ` Marius Vollmer
@ 2005-07-17 18:50 ` Han-Wen Nienhuys
2005-07-17 20:44 ` Marius Vollmer
0 siblings, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-07-17 18:50 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> 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, but I now see that it is in fact not wanted. The order the
> weak vectors are processed in affects the result, which is not good,
> obviously.
>
> Right now, I hope to get around this by repeatedly scanning all weak
> vectors until no new markings have taken place, and only then remove
> the unmarked items.
Hi;
isn't it possible to store the 'module property in a doubly weak hash
table? What you propose sounds very costly , and my gut instinct says
that I can punch a hole in it as well.
>
> Thanks for pointing this out!
>
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-07-17 18:50 ` Han-Wen Nienhuys
@ 2005-07-17 20:44 ` Marius Vollmer
2005-07-18 13:43 ` Han-Wen Nienhuys
0 siblings, 1 reply; 31+ messages in thread
From: Marius Vollmer @ 2005-07-17 20:44 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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 of references where at least one
of the references is weak are not broken up. For example:
(define w (make-weak-key-alist-vector 1))
(vector-set! w o (let ((k "foo"))
(acons k k '())))
will never remove the entry from w.
> What you propose sounds very costly,
I don't think so. With my changes, we normally do three passes over a
weak alist vector, while now we make two.
And since it (hopefully) fixes the bug above, I think it is worth
this.
> and my gut instinct says that I can punch a hole in it as well.
Maybe, but hopefully we can stuff those holes. I will commit the
change soonish; please try to break it then.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-06-09 23:32 module GC bug Han-Wen Nienhuys
2005-06-10 6:32 ` Neil Jerram
2005-07-07 18:42 ` Marius Vollmer
@ 2005-08-01 0:20 ` Marius Vollmer
2005-08-01 11:04 ` Han-Wen Nienhuys
` (2 more replies)
2 siblings, 3 replies; 31+ messages in thread
From: Marius Vollmer @ 2005-08-01 0:20 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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)
#<module b7b859b0>
The fix consists of storing procedure properties in a weak key
hashtable (as you did), and fixing weak hashtables so that cycles from
the value back to the key get properly collected.
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?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-08-01 0:20 ` Marius Vollmer
@ 2005-08-01 11:04 ` Han-Wen Nienhuys
2005-08-10 22:29 ` Marius Vollmer
[not found] ` <42EE63F9.4080102@xs4all.nl>
[not found] ` <42F1DF3E.70204@xs4all.nl>
2 siblings, 1 reply; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-08-01 11:04 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer wrote:
> Han-Wen Nienhuys <hanwen@xs4all.nl> 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)
> #<module b7b859b0>
>
> The fix consists of storing procedure properties in a weak key
> hashtable (as you did), and fixing weak hashtables so that cycles from
> the value back to the key get properly collected.
>
Thanks!
> 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?
Yes, I've already done that. Any idea of when we will see this in a
release?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-08-01 11:04 ` Han-Wen Nienhuys
@ 2005-08-10 22:29 ` Marius Vollmer
2005-08-15 23:57 ` Rob Browning
0 siblings, 1 reply; 31+ messages in thread
From: Marius Vollmer @ 2005-08-10 22:29 UTC (permalink / raw)
Cc: guile-devel
Han-Wen Nienhuys <hanwen@xs4all.nl> 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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-08-10 22:29 ` Marius Vollmer
@ 2005-08-15 23:57 ` Rob Browning
2005-08-16 0:10 ` Marius Vollmer
2005-08-16 0:16 ` Rob Browning
0 siblings, 2 replies; 31+ messages in thread
From: Rob Browning @ 2005-08-15 23:57 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> 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 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?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-08-15 23:57 ` Rob Browning
@ 2005-08-16 0:10 ` Marius Vollmer
2005-08-16 0:16 ` Rob Browning
1 sibling, 0 replies; 31+ messages in thread
From: Marius Vollmer @ 2005-08-16 0:10 UTC (permalink / raw)
Cc: guile-devel
Rob Browning <rlb@defaultvalue.org> writes:
> Marius Vollmer <mvo@zagadka.de> writes:
>
>> Han-Wen Nienhuys <hanwen@xs4all.nl> 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 was too big a change for the 1.6 series.
Only part of it. The following change in 1.6 makes Han-Wen's life
much somewhat easier, I think:
2005-06-10 Han-Wen Nienhuys <hanwen@xs4all.nl>
* gc.c (scm_init_storage): make scm_stand_in_procs a weak_key hash
table. This means that procedure properties are GC'd if the
procedure dies.
> Or did you mean that you want to gear up for a 1.8 release now?
Not really, tho there is 'only' the thread-robustness review to be
done and we might think about doing it after 1.8 since it will
probably need no changes to the API...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: module GC bug
2005-08-15 23:57 ` Rob Browning
2005-08-16 0:10 ` Marius Vollmer
@ 2005-08-16 0:16 ` Rob Browning
2005-08-28 23:31 ` Han-Wen Nienhuys
1 sibling, 1 reply; 31+ messages in thread
From: Rob Browning @ 2005-08-16 0:16 UTC (permalink / raw)
Cc: guile-devel
Rob Browning <rlb@defaultvalue.org> 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 not
certain, but I expect that we should be able to release 1.6.8 in the
next week or two.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <42EE63F9.4080102@xs4all.nl>]
[parent not found: <42F1DF3E.70204@xs4all.nl>]
* Re: module GC bug
[not found] ` <42F1DF3E.70204@xs4all.nl>
@ 2005-08-05 14:48 ` Han-Wen Nienhuys
0 siblings, 0 replies; 31+ messages in thread
From: Han-Wen Nienhuys @ 2005-08-05 14:48 UTC (permalink / raw)
Cc: guile-devel, Marius Vollmer
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.
>
> And... this version of Lily even has the kludge I built for 1.6: ie.
> clearing the 'module property, and replacing scm_stand_in_procs with a
> weak key hash table.
Paint my face in fluorescent blushing red. This leak was actually caused
by me forgetting to #define MODULE_GC_KLUDGE. Case closed, I hope!
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2005-08-28 23:31 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-09 23:32 module GC bug Han-Wen Nienhuys
2005-06-10 6:32 ` Neil Jerram
2005-06-10 11:48 ` Han-Wen Nienhuys
2005-06-19 13:32 ` Han-Wen Nienhuys
2005-06-19 17:33 ` Rob Browning
2005-07-07 18:48 ` Marius Vollmer
2005-06-24 17:50 ` Han-Wen Nienhuys
2005-07-07 18:42 ` Marius Vollmer
2005-07-08 9:24 ` Mikael Djurfeldt
2005-07-09 8:28 ` Han-Wen Nienhuys
2005-07-09 19:28 ` Mikael Djurfeldt
2005-07-09 23:25 ` Han-Wen Nienhuys
2005-07-10 8:16 ` Mikael Djurfeldt
2005-07-09 23:32 ` Han-Wen Nienhuys
2005-07-10 8:17 ` Mikael Djurfeldt
2005-07-08 21:43 ` Han-Wen Nienhuys
2005-07-13 21:02 ` Marius Vollmer
2005-07-13 22:19 ` Han-Wen Nienhuys
2005-07-16 18:57 ` Marius Vollmer
2005-07-17 18:50 ` Han-Wen Nienhuys
2005-07-17 20:44 ` Marius Vollmer
2005-07-18 13:43 ` Han-Wen Nienhuys
2005-08-01 0:20 ` Marius Vollmer
2005-08-01 11:04 ` Han-Wen Nienhuys
2005-08-10 22:29 ` Marius Vollmer
2005-08-15 23:57 ` Rob Browning
2005-08-16 0:10 ` Marius Vollmer
2005-08-16 0:16 ` Rob Browning
2005-08-28 23:31 ` Han-Wen Nienhuys
[not found] ` <42EE63F9.4080102@xs4all.nl>
2005-08-02 19:14 ` Marius Vollmer
[not found] ` <42F1DF3E.70204@xs4all.nl>
2005-08-05 14:48 ` Han-Wen Nienhuys
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).