Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I am pushing a fix for this to master.
Will you care to post and discuss your patches before pushing them?
This is all the more important that the patches don't seem to have any
relation with the problem at hand:
f85ea2a85fcdd051f432964806f044c0301d0945 Merge branch 'master' of
git://git.sv.gnu.org/guile into nits
487b9dec2ea6b88ddbc6fbd17f445ddb197aebc5 Only sanity check numbers if
SCM_DEBUG_CELL_ACCESSES is unset.
80237dcc7783b4d94ecf1d987deb9306d61735a0 Set SRCPROP{PLIST,COPY} through a
macro, so SCM_DEBUG_CELL_ACCESSES compiles.
Can you please describe them and add ChangeLog entries (yes, we still
use that)?
In addition, they don't fix anything on x86-64:
$ ./pre-inst-guile
lt-guile: gc.c:610: scm_i_gc: Assertion `scm_i_gc_sweep_stats.collected +
scm_cells_allocated == scm_i_gc_sweep_stats.swept' failed.
Aborted (core dumped)
Do you think you can come up with a fix within the next few days?
Otherwise, I'm inclined to revert the offending commits in `master' and
wait for a signal from you (i.e., a patch or merge request posted to the
mailing list, *not* a commit on `master'). It would make it easier for
us to play with `master' in the meantime.
Besides, avoid pushing from an non-up-to-date repo: this yields to
automatic merges like the one above, which is annoying as it makes
history harder to follow. Better pull first, then merge your changes,
then push.
>> even the lazy smob case I wrote about here:
>>
>> http://thread.gmane.org/gmane.lisp.guile.user/6372
>
> I would classify the use of mark bits outside of the mark phase as outside
> of the defined API. If you want to have weak pointer semantics, use
> a weak hashtable, or implement reference counting on the C side.
That's a reasonable argument, but it's something we should not change
without discussing it first. For instance, it may be important to study
why Guile-GNOME had to resort to this, and how it could avoid it,
instead of just gratuitously breaking it.
Thanks,
Ludo'.
