GOOPS memory corruption in `go_to_hell ()'

2008-08-19 Thread Ludovic Courtès
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Ludovic Courtès escreveu: > >> Not quite actually: the "hell = scm_malloc (...)" bit is still broken. > > ? I fixed it, added a ChangeLog and NEWS entry and a test case, and pushed it to 1.8. The simplest way to trigger a `go_to_hell ()' call i

Re: pass at srfi-89 implementation

2008-08-19 Thread Andy Wingo
Hi Julian, On Sat 16 Aug 2008 14:19, "Julian Graham" <[EMAIL PROTECTED]> writes: > (Has anyone else noticed that statprof hasn't been working for a while > now? I get a "Numerical overflow" from `statprof-display' no matter > what arguments I pass to `statprof-reset'.) I haven't noticed this, n

Re: request reversion regarding scm_i_* removal

2008-08-19 Thread Andy Wingo
Good day! Still on holiday, but the train provides a lovely hacktime. On Mon 11 Aug 2008 01:10, [EMAIL PROTECTED] (Ludovic Courtès) writes: > Andy Wingo <[EMAIL PROTECTED]> writes: > >> The removal of the scm_i_* functions is an ABI break in the stable 1.8 >> series. It should be reverted. (It's

Re: Goops & Valgrind

2008-08-19 Thread Andy Wingo
Hi Han-Wen, On Fri 15 Aug 2008 22:15, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Running the test suite through valgrind, I get some fishy errors. > > Can someone shed a light on this? The culprit seems to be > > #define SCM_NUMBER_OF_SLOTS(x) \ > ((SCM_STRUCT_DATA (x)[scm_struct_i_n_words

Re: load_extension tests broken

2008-08-19 Thread Andy Wingo
Hi, On Sat 16 Aug 2008 11:27, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > As it turns out, the test suite is loading extension modules (i18n.so > to be precise) from the path I supplied in LD_LIBRARY_PATH. Since this > was an old version, this failed in mysterious ways. > > Could someone modif

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Andy Wingo
On Sun 17 Aug 2008 14:51, [EMAIL PROTECTED] (Ludovic Courtès) writes: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> I have a request: can you put the gnulib into the repository of GUILE itself? > > Yeah, we could do that. I think this would be good; and call be ornery, but a simple import,

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: >> Ludovic Courtès escreveu: > >> Can you be more specific about this? > > Off the top of my head: incorrect indentation, missing spaces around > brackets, and more importantly comments (see (standards.info)Comments). The code I went through should not have that; pleas

Re: Goops & Valgrind

2008-08-19 Thread Han-Wen Nienhuys
Mikael Djurfeldt escreveu: > Unfortunately, I don't have time to fix this. I suggest that some > Guile developer removes %fast-slot-ref/set! and supplies some other > (more clean) way of supporting the code in active-slot.scm. Also, > make sure to check that these primitives are not used anywher

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Ludovic Courtès
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Ludovic Courtès escreveu: > Can you be more specific about this? Off the top of my head: incorrect indentation, missing spaces around brackets, and more importantly comments (see (standards.info)Comments). > See below - note that the old .scm

Re: Goops & Valgrind

2008-08-19 Thread Mikael Djurfeldt
2008/8/16 Han-Wen Nienhuys <[EMAIL PROTECTED]>: > Running the test suite through valgrind, I get some fishy errors. > > Can someone shed a light on this? The culprit seems to be > > #define SCM_NUMBER_OF_SLOTS(x) \ > ((SCM_STRUCT_DATA (x)[scm_struct_i_n_words]) - scm_struct_n_extra_words) > > whe

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: >> (I intend to squash into a single commit before pushing to master). > > First of all, thanks for your work (I know it's not so much fun to hack > the GC), but I feel unhappy with your commit to both `master' and > `branch_release-1-8'. On the contrary, I think the GC

Re: Goops & Valgrind

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> Running the test suite through valgrind, I get some fishy errors. > > So was that fixed by this commit? > > commit 51ef99f7fa9fb766fbb48619fc5863ab9914591d > Author: Han-Wen Nienhuys <[EMAIL PROTECTED]> > Date:

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: > Hi Han-Wen, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> Ludovic Courtès escreveu: > >>> is kind of hard to review in a glimpse. Does it just randomly "clean >>> things up" (whatever that means---it does not follow the GCS, for >> GCS? > > "GNU Coding Stand

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: >>>hell = scm_calloc (hell_size * sizeof (*hell)); >>> >>> `sizeof (*hell)' is actually `sizeof (scm_t_bits *)', which is equal >>> to `sizeof (scm_t_bits)', but using `sizeof (*hell)' is clearer and >>> less error-prone. >>> >>> Besides, is that c

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Han-Wen Nienhuys escreveu: > Ludovic Courtès escreveu: > >> Not quite actually: the "hell = scm_malloc (...)" bit is still broken. > > ? > >> BTW, can you please avoid pushing small topic branches like "nit" and >> "dev/with-gnulib" to Savannah, as we can't distinguish them from "big" >> branche

Re: GUILE_MAX_HEAP_SIZE

2008-08-19 Thread Han-Wen Nienhuys
Ludovic Courtès escreveu: > Not quite actually: the "hell = scm_malloc (...)" bit is still broken. ? > BTW, can you please avoid pushing small topic branches like "nit" and > "dev/with-gnulib" to Savannah, as we can't distinguish them from "big" > branches like "vm"? Sorry, - contrary to what m