Re: Guile automated builds available
Hi Neil, "Neil Jerram" <[EMAIL PROTECTED]> writes: > 2008/8/12 Ludovic Courtès <[EMAIL PROTECTED]>: >> I use a simple script (attached) that invokes Autobuild's m4 macro [2]. >> I'm wondering whether it would be a good idea to include it in releases, >> and tell people they can run >> "./configure && make check | mail [EMAIL PROTECTED]" so that >> we get more build results. >> >> Thoughts? > > I think that's an excellent idea. Just to check that I'm > understanding correctly: I believe you mean just adding AB_INIT to > configure.in, and the source for AB_INIT to acinclude.m4; is that > right? Yes. Will do it shortly. Thanks, Ludo'.
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 > allocation sizes will just be a bit off as a result. While the thing is under development, it probably makes sense to have an `assert ()'. Hitting these assertions wouldn't be a problem if there was a separate GC development branch. In the meantime, `printf ()' seems better suited than `scm_c_issue_deprecation_warning ()'. > Let's just remove the variable, since scm_i_last_marked_cell_count is a > more exact name. OK. Thanks, Ludo'.
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 invariants. > > OTOH, if we are to change the way `scm_cells_allocated' is used and > don't want older code to interfere with that, it's safe the break the > ABI here (we're on `master' after all). 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. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: boot-9 compiling in guile-vm
On Thu 11 Sep 2008 00:59, "Neil Jerram" <[EMAIL PROTECTED]> writes: > I just pulled and built: got this error... > > vm-engine.c: In function 'vm_run': > vm-engine.c:199: error: unable to find a register to spill in class 'SIREG' Yeah, it seems the gcc with debian does this, at least on x86-32. (Dale ran into this on IRC recently.) To work around this, you can remove the #ifdef __i386__ block in vm-engine.h, or comment out the entire #ifdef __GNUC__ section. There are more comments there. > (expr_list:REG_UNUSED (reg:SI 1 dx [1189]) > (expr_list:REG_UNUSED (reg/f:SI 5 di [...] > > ... which seems fantastic Yes it does look delightful, doesn't it :) Cheers, Andy ps. Dale also ran into some bootstrap problems; a make -k and then make "fixed" it for him. -- http://wingolog.org/
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 agree. I'll support you if you take this route. :-) Thanks, Ludo'.
Re: Goops & Valgrind
2008/8/18 Andy Wingo <[EMAIL PROTECTED]>: > 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]) - scm_struct_n_extra_words) >> >> where scm_struct_i_n_words is -2 Reading somewhat belatedly through this trail... Up until your email, I was thinking that the problem here is the "- scm_struct_n_extra_words" - i.e. Mikael's error #2. It seems clear from the code in scm_alloc_struct() that SCM_STRUCT_DATA (x)[scm_struct_i_n_words] does not include the extra words, and hence that scm_struct_n_extra_words should not be subtracted. But then you wrote > Classes that are not metaclasses allocate their instances using "light > structs". So the object layout goes like this: > > the vtable word the data word >+---+-+ > SCM of object = |SCM of class | scm_tc3_struct | SCM* array of slots | >+---|-+ > > For classes, the SCM* points to the middle of a SCM array, which has > some number of words before 0; 4 words normally, or 6 if the object is > an "entity", like a generic function. But for objects there are no words > before 0, hence the valid valgrind error. Are you sure? Surely that would require a call somewhere to scm_alloc_struct() with n_extra = 0, and I can't see any of those. Also, is Mikael right with his error #1? I'm thinking not, because I believe that instances are structs too, so surely it's OK to call SCM_STRUCT_DATA (x)[...] on them? Regards, Neil
Re: Updated HACKING
2008/9/4 Ludovic Courtès <[EMAIL PROTECTED]>: > Hi, > > Andy Wingo <[EMAIL PROTECTED]> writes: > >> On Wed 03 Sep 2008 19:35, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >> >>> How about the following: >>> >>> >>> - Provide a description in the commit message, like so: >>> >>> 1-line description of change >>> >>> More extensive discussion of your change. Document why you are >>> changing things. >>> >>> * filename (function name): file specific change comments. >> >> This looks really good to me. If we move from ChangeLogs, then it makes >> sense to adjust the format as necessary, preserving the same semantics. >> We should probably propose this as the standard GNU format, actually. (I >> believe bzr people use something like this as well.) > > Actually, what you're proposing is what I had in mind. :-) > > It's essentially the GNU ChangeLog format, with the addition of the > summary line and optional extended summary. Adding a one-line summary > has been common practice in some projects, there are examples in Gnulib > and Guile. For the record, I'm happy with this too. Thanks Han-Wen for describing this in HACKING (and for the other updates). So, have we yet announced that we're definitively switching from ChangeLog change logs to Git commit message change logs? In case anyone's in doubt: we are. In practice, I believe the last commit with a ChangeLog change was 31st August, so for the record (if needed) we can say that the switch happened from 1st September onwards. Regards, Neil
Re: boot-9 compiling in guile-vm
2008/9/11 Andy Wingo <[EMAIL PROTECTED]>: > Yeah, it seems the gcc with debian does this, at least on x86-32. (Dale > ran into this on IRC recently.) To work around this, you can remove the > #ifdef __i386__ block in vm-engine.h, or comment out the entire #ifdef > __GNUC__ section. There are more comments there. Thanks, all built now. Neil
