Re: [PATCH] Revise GC asserts.

Hello, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > If this is our stance, this looks like a good opportunity to take all > these variable private, and have people use gc-stats to get the data. > > Providing direct access to variables is problematic from an API stability > point of view. I agr

Re: [PATCH] Revise GC asserts.

Ludovic Courtès escreveu: >> * libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count, >> as a private mechanism for maintaining cell counts. Previous >> versions incremented scm_cells_allocated in an inlined function, so >> loading dynamic objects of older GUILEs would break in

Re: [PATCH] Revise GC asserts.

Hello, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Ludovic Courtès escreveu: >>> * libguile/gc.c (scm_i_gc): Change assert into deprecation warning. >> >> Why? It's not a deprecation but really an invariant, right? > > Yes, but it probably does not warrant crashing the program; memory > all

Re: [PATCH] Revise GC asserts.

Ludovic Courtès escreveu: >> * libguile/gc.c (scm_i_gc): Change assert into deprecation warning. > > Why? It's not a deprecation but really an invariant, right? Yes, but it probably does not warrant crashing the program; memory allocation sizes will just be a bit off as a result. > Thus I woul

Re: [PATCH] Revise GC asserts.

Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > * libguile/gc.c (scm_i_gc): Change assert into deprecation warning. Why? It's not a deprecation but really an invariant, right? > * libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count, > as a private mechanism for maintaining

[PATCH] Revise GC asserts.

* libguile/gc.c (scm_i_gc): Change assert into deprecation warning. * libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count, as a private mechanism for maintaining cell counts. Previous versions incremented scm_cells_allocated in an inlined function, so loading dynamic object