* GC rewrite, first version. @ 2002-07-27 22:54 Han-Wen 2002-07-28 16:40 ` Rob Browning 2002-07-28 16:51 ` Michael Livshin 0 siblings, 2 replies; 31+ messages in thread From: Han-Wen @ 2002-07-27 22:54 UTC (permalink / raw) I've just finished a first version of the rewrite of the garbage collector. You can download it from http://www.cs.uu.nl/~hanwen/public/guile/gc-rewrite-0.0.tar.gz Some general notes: * I've split gc.c in a lot of files, and a private header file. The formerly static functions are now exported, but with the scm_ prefix I think the prefix scm_i_ is utterly unreadable. I decided against using it. The header file is not `exported' so that should make it clear that the structures are internal. * Clusters have been removed. We already had cards as a unit of memory; for MT applications, we can hand out a few free cards for each thread. * The code has been cleaned up *a lot*. I think that the code is almost readable now (except for the actual sweep & mark functions, I didn't touch those.). * I've removed a lot of cruft. (gc.c still contained verbatim fragments of SCM portability glue -- Ick!) * I've also removed part of the header file. I think that GUILE client programs should not have anything to do with how GC works, but if someone desparately needs a symbol back, it could be done. * I've tried to retain the basic interface of the GC (wrt statistics and mtriggers), but I'm not sure that I succeeded, there is a lot of undocumented stuff going on there. * The debugging options are still broken; it is not clear to me for whom these options are, and I only want to put them back when it's clear what the final form of the GC will be, and when there is a need. * Some preliminary benchmarks show that the code is about 2 to 10 % slower than the old GC. I suspect this is because the cards are relatively small, causing more overhead during the sweep. * Next target: try to beat the old GC using lazy sweeping. (When this target is met, I think the code should replace the old GC in CVS guile). [And yes, I don't care much for the compatibility. Especially not in this hacking stage, and especially not for the internals of the GC.] -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-27 22:54 GC rewrite, first version Han-Wen @ 2002-07-28 16:40 ` Rob Browning 2002-07-29 20:11 ` Dirk Herrmann 2002-07-28 16:51 ` Michael Livshin 1 sibling, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-07-28 16:40 UTC (permalink / raw) Cc: guile-devel Han-Wen <hanwen@cs.uu.nl> writes: > * I've split gc.c in a lot of files, and a private header file. The > formerly static functions are now exported, but with the scm_ prefix > > I think the prefix scm_i_ is utterly unreadable. I decided against > using it. The header file is not `exported' so that should make it > clear that the structures are internal. I believe there was a discussion about this a while back, and although I'm fine with the idea of private headers (in fact, I tend to think that from the end-user's perspective they may be a bit cleaner), that wasn't the consensus. People preferred the scm_i_ approach. So while in general I'm not conceptually opposed to private headers instead of the scm_i_ prefix, I think whatever we do we should do it consistently. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-28 16:40 ` Rob Browning @ 2002-07-29 20:11 ` Dirk Herrmann 2002-07-29 21:04 ` Rob Browning 0 siblings, 1 reply; 31+ messages in thread From: Dirk Herrmann @ 2002-07-29 20:11 UTC (permalink / raw) Cc: hanwen, guile-devel On Sun, 28 Jul 2002, Rob Browning wrote: > Han-Wen <hanwen@cs.uu.nl> writes: > > > * I've split gc.c in a lot of files, and a private header file. The > > formerly static functions are now exported, but with the scm_ prefix > > > > I think the prefix scm_i_ is utterly unreadable. I decided against > > using it. The header file is not `exported' so that should make it > > clear that the structures are internal. > > I believe there was a discussion about this a while back, and although > I'm fine with the idea of private headers (in fact, I tend to think > that from the end-user's perspective they may be a bit cleaner), that > wasn't the consensus. People preferred the scm_i_ approach. > > So while in general I'm not conceptually opposed to private headers > instead of the scm_i_ prefix, I think whatever we do we should do it > consistently. The problem with private headers is, that sometimes you like to introduce some macros / function references which themselves are not part of the API, but which you need to implement some macros (or - in the not too far future - inline functions) that are part of the API. This, however, means that these have to be part of the public headers. This is one of the reasons we decided for the scm_i_ and SCM_I_ prefixes. Best regards, Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-29 20:11 ` Dirk Herrmann @ 2002-07-29 21:04 ` Rob Browning 2002-07-29 22:05 ` Han-Wen 0 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-07-29 21:04 UTC (permalink / raw) Cc: hanwen, guile-devel Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes: > The problem with private headers is, that sometimes you like to > introduce some macros / function references which themselves are not > part of the API, but which you need to implement some macros (or - > in the not too far future - inline functions) that are part of the > API. This, however, means that these have to be part of the public > headers. This is one of the reasons we decided for the scm_i_ and > SCM_I_ prefixes. Oh right -- thanks -- I remember that now. That was a pretty good reason :> -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-29 21:04 ` Rob Browning @ 2002-07-29 22:05 ` Han-Wen 2002-07-31 17:03 ` Dirk Herrmann 2002-07-31 18:46 ` Neil Jerram 0 siblings, 2 replies; 31+ messages in thread From: Han-Wen @ 2002-07-29 22:05 UTC (permalink / raw) Cc: Dirk Herrmann, guile-devel rlb@defaultvalue.org writes: > Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes: > > > The problem with private headers is, that sometimes you like to > > introduce some macros / function references which themselves are not > > part of the API, but which you need to implement some macros (or - > > in the not too far future - inline functions) that are part of the > > API. This, however, means that these have to be part of the public > > headers. This is one of the reasons we decided for the scm_i_ and > > SCM_I_ prefixes. > > Oh right -- thanks -- I remember that now. That was a pretty good > reason :> Well, if any of the private GC move to public headers, we can always insert the I. -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-29 22:05 ` Han-Wen @ 2002-07-31 17:03 ` Dirk Herrmann 2002-07-31 18:02 ` Han-Wen Nienhuys 2002-07-31 18:46 ` Neil Jerram 1 sibling, 1 reply; 31+ messages in thread From: Dirk Herrmann @ 2002-07-31 17:03 UTC (permalink / raw) Cc: guile-devel On Tue, 30 Jul 2002, Han-Wen wrote: > rlb@defaultvalue.org writes: > > Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes: > > > > > The problem with private headers is, that sometimes you like to > > > introduce some macros / function references which themselves are not > > > part of the API, but which you need to implement some macros (or - > > > in the not too far future - inline functions) that are part of the > > > API. This, however, means that these have to be part of the public > > > headers. This is one of the reasons we decided for the scm_i_ and > > > SCM_I_ prefixes. > > > > Oh right -- thanks -- I remember that now. That was a pretty good > > reason :> > > Well, if any of the private GC move to public headers, we can always > insert the I. Well, it has been said that as long as you are in the hacking phase, you shouldn't care about policy and naming, and I agree. And, I think that your changes will be a great step forward for guile. However, when you are going to add your stuff to CVS I think it is important that it does not deliberately violate conventions that have been agreed upon. Feel free to start a discussion about improving the convention, but until the decision is made to change things the way you like it, please follow the current convention when changing code in CVS. Best regards, Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-31 17:03 ` Dirk Herrmann @ 2002-07-31 18:02 ` Han-Wen Nienhuys 2002-07-31 21:15 ` Rob Browning 2002-08-01 8:46 ` Marius Vollmer 0 siblings, 2 replies; 31+ messages in thread From: Han-Wen Nienhuys @ 2002-07-31 18:02 UTC (permalink / raw) Cc: guile-devel dirk@sallust.ida.ing.tu-bs.de writes: > However, when you are going to add your stuff to CVS I think it is > important that it does not deliberately violate conventions that have been > agreed upon. Feel free to start a discussion about improving the > convention, but until the decision is made to change things the way you > like it, please follow the current convention when changing code in CVS. I'm a bit reluctant to start a discussion, because that typically draws comments from people that don't code, but do think they know better anyway. With this warning in advance, comments from people that write actual Scheme code is welcome. Personally, I view source code as a form of prose. It should be easily readable. Hence I prefer variable names that can just be read as an english expression, with the prefix scm_ for delimiting our namespace, perhaps with an abbreviation here or there to keep the lines within my editor window. Typically, the most generic word (always a noun), eg number, size, string, comes last i.e. scm_heap_segment_table_size scm_formals_str(ing) in stead of scm_n_heap_segs scm_s_formals Inside C structs this convention is kept reasonably well, i.e. throw_value jmpbuf backing_store_size line_number rstate_size However, all exported symbols that don't have a Scheme-derived name are named with unpronounceable and unreadable names. I would prefer the following: internal ENTITY_X: internal_ENTITY_X (not i_ENTITY_X) string FOO: FOO_string (not s_foo) BAR-type: Bar_type (not t_BAR) (or even: simply BAR. Constructors are named new_BAR, so no clashes should arise) number of FOOS: FOO_count Perhaps the other way (generic word first) would also be readable, but then most of the C code is wrong. To what extent are these naming standards decided (names.txt is dated march, and I believe little has been done on the code since)? If it is we have to wait for two releases (four years) before the old names are scrapped, then I'm not going to waste energy on it. And for the rest, I think that GUILE 1.6 should be released. As an aside, if no-one objects to it, I would like to merge the new GC code coming weekend. -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-31 18:02 ` Han-Wen Nienhuys @ 2002-07-31 21:15 ` Rob Browning 2002-08-01 9:20 ` Release Guile, now ;-) [was:] " rm 2002-08-01 9:59 ` Han-Wen Nienhuys 2002-08-01 8:46 ` Marius Vollmer 1 sibling, 2 replies; 31+ messages in thread From: Rob Browning @ 2002-07-31 21:15 UTC (permalink / raw) Cc: Dirk Herrmann, guile-devel Han-Wen Nienhuys <hanwen@cs.uu.nl> writes: > Personally, I view source code as a form of prose. It should be > easily readable. Hence I prefer variable names that can just be read > as an english expression, with the prefix scm_ for delimiting our > namespace, perhaps with an abbreviation here or there to keep the > lines within my editor window. Typically, the most generic word > (always a noun), eg number, size, string, comes last Overall I agree, though I will say that all other things being equal, I tend to feel that consistency within the codebase, up to a certain point, improves readability (and managability wrt finding things via the normal tools like grep, etc.) more than having some files with the "perfect style" and others without would. > scm_heap_segment_table_size > scm_formals_str(ing) > > in stead of > > scm_n_heap_segs > scm_s_formals I consider the latter uglier, and wouldn't choose it myself, but I could manage with either if the convention were consistently used. > And for the rest, I think that GUILE 1.6 should be released. Agreed. I've fixed the remaining issues, and 1.5.7 has been ready for upload since last week, but I've been waiting for alpha.gnu.org to become available again. > As an aside, if no-one objects to it, I would like to merge the new GC > code coming weekend. No opinion -- I'd rather have the people who know the GC better comment on that, but I definitely appreciate your efforts in trying to clean things up. Seems like the gc and eval are two of the (understandably) harder segments of code to get a handle on when you start messing with guile, so the more we can make these transparent without appreciably harming our performance or functionality, the better. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-07-31 21:15 ` Rob Browning @ 2002-08-01 9:20 ` rm 2002-08-01 16:27 ` Rob Browning 2002-08-01 9:59 ` Han-Wen Nienhuys 1 sibling, 1 reply; 31+ messages in thread From: rm @ 2002-08-01 9:20 UTC (permalink / raw) Cc: Han-Wen Nienhuys, Dirk Herrmann, guile-devel On Wed, Jul 31, 2002 at 04:15:11PM -0500, Rob Browning wrote: > > And for the rest, I think that GUILE 1.6 should be released. Oh, yes, please! > Agreed. I've fixed the remaining issues, and 1.5.7 has been ready for > upload since last week, but I've been waiting for alpha.gnu.org to > become available again. > Hmm, i reported a problem/bug with the file libguile/scmconfig.h that exports '#define's that it shouldn't. I'd actually consider this a release-critical bug: it's actually impossible to build GNU-autoconfish software that includes this file while instructing the compiler to treat warnings as errors (the most offensive defines are lines 557-570 in file scmconfig.h.in). Should i use the bug reporting tool on savannah.gnu.org is something like my mail to the developer group sufficent? Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 9:20 ` Release Guile, now ;-) [was:] " rm @ 2002-08-01 16:27 ` Rob Browning 2002-08-01 16:44 ` rm ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Rob Browning @ 2002-08-01 16:27 UTC (permalink / raw) Cc: Han-Wen Nienhuys, Dirk Herrmann, guile-devel rm@fabula.de writes: > Hmm, i reported a problem/bug with the file libguile/scmconfig.h > that exports '#define's that it shouldn't. I'd actually consider > this a release-critical bug: it's actually impossible to build > GNU-autoconfish software that includes this file while instructing > the compiler to treat warnings as errors (the most offensive defines > are lines 557-570 in file scmconfig.h.in). I agree it's a bug, but it also appears to be one we've had for a while. I believe guile 1.4 had the same problem. For that reason I hadn't been strongly inclined to consider it release critical since 1.5.7 was ready to go. However since I'm waiting to upload anyway I'll go see how extensive the changes to fix it might be. BTW: I don't think we can compile with with warnings treated as errors anyhow in 1.5.* -- I believe num2*.c still prevents it. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 16:27 ` Rob Browning @ 2002-08-01 16:44 ` rm 2002-08-01 18:37 ` Sergey Poznyakoff 2002-08-01 22:40 ` Rob Browning 2 siblings, 0 replies; 31+ messages in thread From: rm @ 2002-08-01 16:44 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel On Thu, Aug 01, 2002 at 11:27:03AM -0500, Rob Browning wrote: > > I agree it's a bug, but it also appears to be one we've had for a > while. I believe guile 1.4 had the same problem. For that reason I > hadn't been strongly inclined to consider it release critical since > 1.5.7 was ready to go. However since I'm waiting to upload anyway > I'll go see how extensive the changes to fix it might be. Ok, i see. I just stumbled across it while converting mod_guile to autonf -- so far i never used autoheader in my projects. > BTW: I don't think we can compile with with warnings treated as errors > anyhow in 1.5.* -- I believe num2*.c still prevents it. Oh, i don't mind not compiling guile itself with warnings treated as errors (and for interpreters i'd expect compilation warnings anyway). The problematic headers just prevent third party code to be compiled like that -- our header problem 'leaks', so to speak. Ralf Mattes > -- > Rob Browning > rlb @defaultvalue.org, @linuxdevel.com, and @debian.org > Previously @cs.utexas.edu > GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 16:27 ` Rob Browning 2002-08-01 16:44 ` rm @ 2002-08-01 18:37 ` Sergey Poznyakoff 2002-08-01 22:21 ` Rob Browning 2002-08-01 22:40 ` Rob Browning 2 siblings, 1 reply; 31+ messages in thread From: Sergey Poznyakoff @ 2002-08-01 18:37 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel > I agree it's a bug, but it also appears to be one we've had for a > while. I believe guile 1.4 had the same problem. No, guile 1.4 did not have it. It started with 1.4.1. Sorry for my two cents:) -Sergey _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 18:37 ` Sergey Poznyakoff @ 2002-08-01 22:21 ` Rob Browning 2002-08-02 6:09 ` Sergey Poznyakoff 0 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-08-01 22:21 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Sergey Poznyakoff <gray@Mirddin.farlep.net> writes: > No, guile 1.4 did not have it. It started with 1.4.1. > > Sorry for my two cents:) Are you sure? My 1.4 __scm.h has #include "libguile/scmconfig.h" in it (which according to automake is actually wrong -- it should be <libguile/scmconfig.h> everywhere) and my scmconfig.h has all the config.h style HAVE_* bits, etc., or were the bits that are causing the current problem only recently added? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 22:21 ` Rob Browning @ 2002-08-02 6:09 ` Sergey Poznyakoff 2002-08-02 14:36 ` Rob Browning 0 siblings, 1 reply; 31+ messages in thread From: Sergey Poznyakoff @ 2002-08-02 6:09 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel > Are you sure? My 1.4 __scm.h has #include "libguile/scmconfig.h" in > it (which according to automake is actually wrong -- it should be > <libguile/scmconfig.h> everywhere) and my scmconfig.h has all the > config.h style HAVE_* bits, etc., or were the bits that are causing > the current problem only recently added? Yes, they were. It's not the libguile/scmconfig.h itself that causes the problem, it's primarily the PACKAGE_.* defines that cause it. They appeared recently. I guess if you remove them or just move them to some private header, the problem will be solved. Another solution would be to protect each PACKAGE_ define by an #ifdef, e.g.: #ifndef PACKAGE_STRING /* Define to the full name and version of this package. */ # define PACKAGE_STRING "" #endif then any application could easily override them in its config.h And, as Han-Wen says, coeterum censeo Guilem releasem esse :) Regards, Sergey _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 6:09 ` Sergey Poznyakoff @ 2002-08-02 14:36 ` Rob Browning 2002-08-02 17:29 ` Sergey Poznyakoff 0 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-08-02 14:36 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Sergey Poznyakoff <gray@Mirddin.farlep.net> writes: > Yes, they were. It's not the libguile/scmconfig.h itself that causes > the problem, it's primarily the PACKAGE_.* defines that cause it. They > appeared recently. I guess if you remove them or just move them to > some private header, the problem will be solved. Another solution > would be to protect each PACKAGE_ define by an #ifdef, e.g.: > > #ifndef PACKAGE_STRING > /* Define to the full name and version of this package. */ > # define PACKAGE_STRING "" > #endif > > then any application could easily override them in its config.h Yeah, but these shouldn't even be there. For now, can you tell which defines are the real trouble makers? Are there others than PACKAGE_STRING? I'm wondering if we can just fix the major offenders for now and then fix it *right* for 1.6.2. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 14:36 ` Rob Browning @ 2002-08-02 17:29 ` Sergey Poznyakoff 2002-08-02 18:10 ` Bruce Korb 0 siblings, 1 reply; 31+ messages in thread From: Sergey Poznyakoff @ 2002-08-02 17:29 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel > > then any application could easily override them in its config.h > > Yeah, but these shouldn't even be there. Agreed, I've proposed the #ifdef approach only as a temporary solution. > For now, can you tell which defines are the real trouble makers? Are > there others than PACKAGE_STRING? I'm wondering if we can just fix > the major offenders for now and then fix it *right* for 1.6.2. The major ones are: PACKAGE_NAME, PACKAGE_TARNAME, PACKAGE_VERSION, PACKAGE_BUGREPORT. The HAVE_.* defines just generate lots of redefinition warning, but apart from that they don't do any harm. Regards, Sergey _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 17:29 ` Sergey Poznyakoff @ 2002-08-02 18:10 ` Bruce Korb 2002-08-02 19:50 ` Rob Browning 2002-08-03 7:13 ` Sergey Poznyakoff 0 siblings, 2 replies; 31+ messages in thread From: Bruce Korb @ 2002-08-02 18:10 UTC (permalink / raw) Cc: Rob Browning, rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Sergey Poznyakoff wrote: > Agreed, I've proposed the #ifdef approach only as a temporary > solution. > > > For now, can you tell which defines are the real trouble makers? Are > > there others than PACKAGE_STRING? I'm wondering if we can just fix > > the major offenders for now and then fix it *right* for 1.6.2. > > The major ones are: PACKAGE_NAME, PACKAGE_TARNAME, PACKAGE_VERSION, > PACKAGE_BUGREPORT. The HAVE_.* defines just generate lots of > redefinition warning, but apart from that they don't do any harm. I'm sure you know, the problem stems from standardized autoconf tests pluging in standardized names. Just add the following macro at the end of the configure.ac file: http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html Commentary from the macro: dnl takes the usual config.h generated header file; looks for each of dnl the generated "#define SOMEDEF" lines, and prefixes the defined name dnl (ie. makes it "#define PREFIX_SOMEDEF". The result is written to dnl the output config.header file. The PREFIX is converted to uppercase dnl for the conversions. dnl dnl default OUTPUT-HEADER = $PACKAGE-config.h dnl default PREFIX = $PACKAGE dnl default ORIG-HEADER, derived from OUTPUT-HEADER dnl if OUTPUT-HEADER has a "/", use the basename dnl if OUTPUT-HEADER has a "-", use the section after it. dnl otherwise, just config.h dnl dnl In most cases, the configure.in will contain a line saying dnl AC_CONFIG_HEADER(config.h) dnl somewhere *before* AC_OUTPUT and a simple line saying dnl AC_PREFIX_CONFIG_HEADER dnl somewhere *after* AC_OUTPUT. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 18:10 ` Bruce Korb @ 2002-08-02 19:50 ` Rob Browning 2002-08-03 7:13 ` Sergey Poznyakoff 1 sibling, 0 replies; 31+ messages in thread From: Rob Browning @ 2002-08-02 19:50 UTC (permalink / raw) Cc: Sergey Poznyakoff, rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Bruce Korb <bkorb@pacbell.net> writes: > I'm sure you know, the problem stems from standardized autoconf tests > pluging in standardized names. Just add the following macro at the > end of the configure.ac file: > > http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html Oh, right, I've seen that, and it may be the right way to go in the end, but I still currently favor the idea that our public autogenerated config file should be a lot more selective about what it publishes than our private config.h. i.e. the shorter the better. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 18:10 ` Bruce Korb 2002-08-02 19:50 ` Rob Browning @ 2002-08-03 7:13 ` Sergey Poznyakoff 2002-08-04 20:43 ` Bruce Korb 1 sibling, 1 reply; 31+ messages in thread From: Sergey Poznyakoff @ 2002-08-03 7:13 UTC (permalink / raw) Cc: Rob Browning, rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel > Just add the following macro at the > end of the configure.ac file: > > http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html Sure, I know about this macro. Still, I don't believe it solves the problem, rather, it presents a work-around. The idea behind auto.* tools was to generate a configuration file *for a given package*, i.e. a private header. However, here the private header is made global and as such makes linking Guile to other packages unreasonably difficult. Imagine a developer who wishes to use Guile as an extension language for his package, he then would need to change almost all his configuration suite. Regards, Sergey _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-03 7:13 ` Sergey Poznyakoff @ 2002-08-04 20:43 ` Bruce Korb 2002-08-04 20:57 ` Sergey Poznyakoff 0 siblings, 1 reply; 31+ messages in thread From: Bruce Korb @ 2002-08-04 20:43 UTC (permalink / raw) Cc: Rob Browning, rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Sergey Poznyakoff wrote: > > > Just add the following macro at the > > end of the configure.ac file: > > > > http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html > > Sure, I know about this macro. Still, I don't believe it solves the > problem, rather, it presents a work-around. The idea behind auto.* > tools was to generate a configuration file *for a given package*, i.e. > a private header. However, here the private header is made global Which is exactly the problem. Guile should *not* be exporting its config.h header. Further, since Guile should not be doing it, anyone depending upon the Guile-configured values has mis- coded their program. On that theory, the config header Guile exports should be free to prefix all its values. Guile should do this. > and as such makes linking Guile to other packages unreasonably > difficult. Imagine a developer who wishes to use Guile as an extension > language for his package, he then would need to change almost all his > configuration suite. To the contrary. Guile needs to do this. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-04 20:43 ` Bruce Korb @ 2002-08-04 20:57 ` Sergey Poznyakoff 0 siblings, 0 replies; 31+ messages in thread From: Sergey Poznyakoff @ 2002-08-04 20:57 UTC (permalink / raw) Cc: Rob Browning, rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel > Which is exactly the problem. Guile should *not* be exporting > its config.h header. Further, since Guile should not be doing > it, anyone depending upon the Guile-configured values has mis- > coded their program. On that theory, the config header Guile > exports should be free to prefix all its values. Guile should > do this. [...] > > Imagine a developer who wishes to use Guile as an extension > > language for his package, he then would need to change almost all his > > configuration suite. > > To the contrary. Guile needs to do this. Agreed to both points. Another (yet related) question: Should guile-doc-snarf stuff be installed to bin as guile-snarf is? I believe it should. If a developer needs to use guile-snarf then he will surely need to use guile-doc-snarf, yet the latter is a noinst_SCRIPTS target. I guess this is inconsistent. For example, the GNU radius project provides a set of scheme primitives via SCM_DEFINE. To process the sources I need to include in the package a copy of guile-doc-snarf (for version 1.4 as well as for 1.6). It would be a lot easier if Guile had installed all the snarfers. Regards, Sergey _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 16:27 ` Rob Browning 2002-08-01 16:44 ` rm 2002-08-01 18:37 ` Sergey Poznyakoff @ 2002-08-01 22:40 ` Rob Browning 2002-08-02 9:35 ` rm 2 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-08-01 22:40 UTC (permalink / raw) Cc: Han-Wen Nienhuys, Dirk Herrmann, guile-devel Rob Browning <rlb@defaultvalue.org> writes: > 1.5.7 was ready to go. However since I'm waiting to upload anyway > I'll go see how extensive the changes to fix it might be. OK, after looking in to it, it seems like we probably need a number of changes to get things "right". One of the main questions is how do you generate a header that can be included in the install tree containing info based on configure's results, but doesn't refer to any of those results (at least not to the generic names). After poking around a bit I propose the following solution: * change our configure generated header to be config.h via config.h.in as per the normal autoconf expectations and put it in the normal place ./config.h.in. This will now be a completely private header, not installed, and not included by anything but .c files. * change all *.c occurrences of #include ?libguile/scmconfig.h?" to "#include <config.h>" except for the include in __scm.h. That one will be left alone. * add a rule to libguile/Makefile.am like this: scmconfig.h: ${builddir}/scmconfig-generate ${builddir}/scmconfig-generate > scmconfig.h.tmp mv scmconfig.h.tmp scmconfig.h * write libguile/scmconfig-generate.c to use the values in <config.h> to generate a config.h independent header like this: #include <config.h> #include <stdio.h> int main (int argc, char *argv[]) { printf( "/* libguile/scmconfig.h -*-c-*- This file contains bits that were determined automatically, but should be included in the guile public header install This file is generated automatically from libguile/scmconfig-generate. Please make changes there. */\n\n"); #ifdef HAVE_LONG_LONGS printf("#define SCM_HAVE_LONG_LONGS"); #endif /* etc. */ return 0; } This allows us to autogenerate the file from the contents of config.h without having to do anything too fancy with sed/config.status, etc. * go through and add items to scmconfig-generate.c as needed, but leave as much as possible in <config.h> -- where it'll be private. For example, I'm guessing that most of the HAVE_FOO macros won't be public, and the ones that must be public (i.e. in scmconfig.h) should be renamed to SCM_HAVE_FOO, or similar. But this looks like a non-trivial amount of work. I've already done all the steps but the last in a test tree, but that's the big one. So the question is, does this have to be done before 1.6.1? Also while poking around I noticed that there are at least several #defines in __scm.h that appear to serve no purpose -- they're not referred to anywhere else. I'm wondering if these can be dropped. For example, TICKS isn't used anywhere, and it looks like ENGNOT could be moved to numbers.c without problems. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-01 22:40 ` Rob Browning @ 2002-08-02 9:35 ` rm 2002-08-02 11:59 ` rm 2002-08-02 14:50 ` Rob Browning 0 siblings, 2 replies; 31+ messages in thread From: rm @ 2002-08-02 9:35 UTC (permalink / raw) Cc: rm, Han-Wen Nienhuys, Dirk Herrmann, guile-devel Hi Rob, I feel sorry seeing that my complaints cause such a lot of trouble. On Thu, Aug 01, 2002 at 05:40:31PM -0500, Rob Browning wrote: > Rob Browning <rlb@defaultvalue.org> writes: > > > 1.5.7 was ready to go. However since I'm waiting to upload anyway > > I'll go see how extensive the changes to fix it might be. > > OK, after looking in to it, it seems like we probably need a number of > changes to get things "right". One of the main questions is how do > you generate a header that can be included in the install tree > containing info based on configure's results, but doesn't refer to any > of those results (at least not to the generic names). Hmm, i don't understand this. The offending header file is not generated by 'autoheader', it's processed by 'configure'. Instead of writing a custom c program that emits all needed #defines wouldn't it be sufficient to create scmconfig.h.in by hand? > After poking > around a bit I propose the following solution: > > * change our configure generated header to be config.h via > config.h.in as per the normal autoconf expectations and put it in > the normal place ./config.h.in. This will now be a completely > private header, not installed, and not included by anything but .c > files. Good idea, IMHO. > [...] > * add a rule to libguile/Makefile.am like this: > > scmconfig.h: ${builddir}/scmconfig-generate > ${builddir}/scmconfig-generate > scmconfig.h.tmp > mv scmconfig.h.tmp scmconfig.h > > * write libguile/scmconfig-generate.c to use the values in > <config.h> to generate a config.h independent header like this: > > #include <config.h> > #include <stdio.h> > > int > main (int argc, char *argv[]) > { > printf( > [...] > This allows us to autogenerate the file from the contents of > config.h without having to do anything too fancy with > sed/config.status, etc. > > * go through and add items to scmconfig-generate.c as needed, but > leave as much as possible in <config.h> -- where it'll be private. > For example, I'm guessing that most of the HAVE_FOO macros won't > be public, and the ones that must be public (i.e. in scmconfig.h) > should be renamed to SCM_HAVE_FOO, or similar. But if you want to select the values you want/need to export anyway, why not use the autoconf machinery for that. Instead of putting these values as string constants into a C program might as well have: *---------------------------------------------------------------------- | | dnl file: public_defines.ac | dnl This files describes the #defines detected | dnl during libguile's build process that need to | dnl be visible to users of the library. | | AC_PREREQ(2.53) | AC_INIT | | AM_CONFIG_HEADER(libguile/scmconfig.h) | | AC_DEFINE(GUILE_DEBUG_FREELIST, 1, | [Define this if you want to debug the free list (helps w/ GC bugs).]) | AC_DEFINE(GUILE ...... | and then have it processed by autoheader with an invocation like this: autoheader public_defines.ac that's all that's needed, as far as i understand. > > But this looks like a non-trivial amount of work. I've already done > all the steps but the last in a test tree, but that's the big one. > So the question is, does this have to be done before 1.6.1? May i offer my help? Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 9:35 ` rm @ 2002-08-02 11:59 ` rm 2002-08-02 15:00 ` Rob Browning 2002-08-02 14:50 ` Rob Browning 1 sibling, 1 reply; 31+ messages in thread From: rm @ 2002-08-02 11:59 UTC (permalink / raw) Cc: Rob Browning, Han-Wen Nienhuys, Dirk Herrmann, guile-devel On Fri, Aug 02, 2002 at 11:35:47AM +0200, rm@fabula.de wrote: > [...] > and then have it processed by autoheader with an invocation like this: > > autoheader public_defines.ac > > that's all that's needed, as far as i understand. Hit me on the forehead with the elsip manual for not testing this -- it doesn't work. Autoheader insists on emitting the offending #defines even if given a custom input file (the offending macro is AC_INIT). But browsing through the autoconf mailing list i found http://mail.gnu.org/pipermail/autoconf/2002-June/013361.html which seems to describe our problem. There's a reference to http://ac-archive.sourceforge.net/Miscellaneous/ac_create_prefix_config_h.html an autoconf macro that might just do what we want. > > > > But this looks like a non-trivial amount of work. I've already done > > all the steps but the last in a test tree, but that's the big one. > > So the question is, does this have to be done before 1.6.1? > > May i offer my help? Since the aforementioned doen't exactly do what we need (it creates a file prefixed with 'libguile-' rather than a file 'scmconfig.h.in') i can offer to modify it so we have another guile macro (would GUILE_CREATE_PUBLIC_HEADER be apropriate?). Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 11:59 ` rm @ 2002-08-02 15:00 ` Rob Browning 0 siblings, 0 replies; 31+ messages in thread From: Rob Browning @ 2002-08-02 15:00 UTC (permalink / raw) Cc: Han-Wen Nienhuys, Dirk Herrmann, guile-devel rm@fabula.de writes: > Since the aforementioned doen't exactly do what we need (it creates > a file prefixed with 'libguile-' rather than a file 'scmconfig.h.in') > i can offer to modify it so we have another guile macro (would > GUILE_CREATE_PUBLIC_HEADER be apropriate?). Maybe, but I'm still unconvinced that this is easier to understand than a simple C program with #ifdefs and printfs in it. Imagine coming to the project from the outside. If you needed to fix something I suspect that wading through a little bit of Makefile.am and C code is going to be easier than trying to figure out extra autoconfery and an add-on autoconf macro, and I suspect the future maintenance burden of the C program would be lighter than that of autoconf macros across auto* upgrades, etc. I also kinda like the fact that with the C program approach we'll have to be completely explicit about what actually goes in the generated public header rather than just getting everything that's in config.h, especially since most of the values in config.h shouldn't be needed (or used by) or public headers. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version. 2002-08-02 9:35 ` rm 2002-08-02 11:59 ` rm @ 2002-08-02 14:50 ` Rob Browning 1 sibling, 0 replies; 31+ messages in thread From: Rob Browning @ 2002-08-02 14:50 UTC (permalink / raw) Cc: Han-Wen Nienhuys, Dirk Herrmann, guile-devel rm@fabula.de writes: > I feel sorry seeing that my complaints cause such a lot of trouble. No it's good. If we're now #defining really generic things that break compilation with other packages, then we really have to fix that. > Hmm, i don't understand this. The offending header file is not > generated by 'autoheader', it's processed by 'configure'. Instead of > writing a custom c program that emits all needed #defines wouldn't > it be sufficient to create scmconfig.h.in by hand? Actually I believe scmconfig.h is generated by autoheader. See configure.in: AM_CONFIG_HEADER(libguile/scmconfig.h) And while I'd certainly be open to other options, the trivial C program means we can use *exactly* the values that the auto* machinery normally generates via config.h, and it'll automatically get the dependencies right too. When config.h changes, so will scmconfig.h. Other solutions would be OK too, but this one seems nice and simple. I thought about using configure to generate scmconfig.h from scmconfig.h.in via embedded @FOO@ bits, but if you do that, then you have to go through and add a whole lot more code to configure.in to AC_DEFINE all the things you need, and you can't do #if* reasoning based on the config.h HAVE_* defines to decide what to put in scmconfig.h. With the C program approach, you get this for "free". > | AC_PREREQ(2.53) > | AC_INIT > | > | AM_CONFIG_HEADER(libguile/scmconfig.h) > | > | AC_DEFINE(GUILE_DEBUG_FREELIST, 1, > | [Define this if you want to debug the free list (helps w/ GC bugs).]) > | AC_DEFINE(GUILE ...... > | Sure we could do that, but what if we wanted to do things like: #ifdef HAVE_FOO && HAVE_BAR printf("#define ..."); printf("typedef ..."); printf("#define super fancy ..."); #else printf("..."); #endif Of course, you can do this with the configure machinery, but I suspect it's going to be more code, and not as straigtforward. With the tiny C program approach, you only have 2 files, the normal config.h you've got to have anyhow and the C program, and the processing is just a trivial Makefile.am rule, or to put it another way, when the info you need's already going to be in a C header, it seemed most straightforward to handle it via C. > May i offer my help? Sure, though we've got to figure out how much has to be done immediately. I'm suspecting we may be able to just back out PACKAGE_NAME and a few of the other offenders and solve things more correctly after 1.6.1. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-31 21:15 ` Rob Browning 2002-08-01 9:20 ` Release Guile, now ;-) [was:] " rm @ 2002-08-01 9:59 ` Han-Wen Nienhuys 1 sibling, 0 replies; 31+ messages in thread From: Han-Wen Nienhuys @ 2002-08-01 9:59 UTC (permalink / raw) Cc: Dirk Herrmann, guile-devel rlb@defaultvalue.org writes: > I consider the latter uglier, and wouldn't choose it myself, but I > could manage with either if the convention were consistently used. > > > And for the rest, I think that GUILE 1.6 should be released. > > Agreed. I've fixed the remaining issues, and 1.5.7 has been ready for > upload since last week, but I've been waiting for alpha.gnu.org to > become available again. You could simply make it available through another channel? -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-31 18:02 ` Han-Wen Nienhuys 2002-07-31 21:15 ` Rob Browning @ 2002-08-01 8:46 ` Marius Vollmer 1 sibling, 0 replies; 31+ messages in thread From: Marius Vollmer @ 2002-08-01 8:46 UTC (permalink / raw) Cc: Dirk Herrmann, guile-devel Han-Wen Nienhuys <hanwen@cs.uu.nl> writes: > To what extent are these naming standards decided (names.txt is dated > march, and I believe little has been done on the code since)? The definite list of naming conventions is the section "Naming Conventions" in the file HACKING. We probably need to distinguish between "must" conventions and "should" conventions there, tho. I.e. the scm_i_ convention must be followed, but scm_n_ only should. > If it is we have to wait for two releases (four years) before the > old names are scrapped, then I'm not going to waste energy on it. On what? Scrapping the old names or following the new convention? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-29 22:05 ` Han-Wen 2002-07-31 17:03 ` Dirk Herrmann @ 2002-07-31 18:46 ` Neil Jerram 2002-08-01 9:58 ` Han-Wen Nienhuys 1 sibling, 1 reply; 31+ messages in thread From: Neil Jerram @ 2002-07-31 18:46 UTC (permalink / raw) Cc: Rob Browning, Dirk Herrmann, guile-devel >>>>> "Han-Wen" == Han-Wen <hanwen@cs.uu.nl> writes: Han-Wen> rlb@defaultvalue.org writes: >> Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes: >> >> > The problem with private headers is, that sometimes you like to >> > introduce some macros / function references which themselves are not >> > part of the API, but which you need to implement some macros (or - >> > in the not too far future - inline functions) that are part of the >> > API. This, however, means that these have to be part of the public >> > headers. This is one of the reasons we decided for the scm_i_ and >> > SCM_I_ prefixes. >> >> Oh right -- thanks -- I remember that now. That was a pretty good >> reason :> Han-Wen> Well, if any of the private GC move to public headers, we can always Han-Wen> insert the I. It's not only about what you can see in which header files. It's about clearly identifying which of the exports from the libguile library are intended for application developers' use, and which are internal. This then helps (or will help) us to check that we've documented everything that should be documented, and that we've described everything that has changed between releases. Since we spent some time discussing this and agreeing it on the list, could you not just go along with it? (I believe this is the point where an American would say "Sheesh.") Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-31 18:46 ` Neil Jerram @ 2002-08-01 9:58 ` Han-Wen Nienhuys 0 siblings, 0 replies; 31+ messages in thread From: Han-Wen Nienhuys @ 2002-08-01 9:58 UTC (permalink / raw) Cc: Rob Browning, Dirk Herrmann, guile-devel neil@ossau.uklinux.net writes: > Since we spent some time discussing this and agreeing it on the list, > could you not just go along with it? > > (I believe this is the point where an American would say "Sheesh.") Sorry, I was getting carried away a little: I spent some time on the GC code, and IMO, it now has almost perfect style. It makes me a little sad to scrap some of that perfection. (Of course the coming merge will use the mandatory conventions ) -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: GC rewrite, first version. 2002-07-27 22:54 GC rewrite, first version Han-Wen 2002-07-28 16:40 ` Rob Browning @ 2002-07-28 16:51 ` Michael Livshin 1 sibling, 0 replies; 31+ messages in thread From: Michael Livshin @ 2002-07-28 16:51 UTC (permalink / raw) Han-Wen <hanwen@cs.uu.nl> writes: > I've just finished a first version of the rewrite of the garbage > collector. You can download it from > > http://www.cs.uu.nl/~hanwen/public/guile/gc-rewrite-0.0.tar.gz > > [ yummy stuff snipped ] > > [And yes, I don't care much for the compatibility. Especially not in > this hacking stage, and especially not for the internals of the GC.] and right you are. I don't know what the policy is these days, nor how stupid do I sound with this advice from the sidelines, but to avoid drowning in discussions it is IMHO advisable to do the following: * don't publish patches, many people are too lazy to install them. instead work in a branch of the main CVS repository. * don't worry about style and policy until you are ready to merge. -- Due to the holiday next Monday, there will be no garbage collection. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-08-04 20:57 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-07-27 22:54 GC rewrite, first version Han-Wen 2002-07-28 16:40 ` Rob Browning 2002-07-29 20:11 ` Dirk Herrmann 2002-07-29 21:04 ` Rob Browning 2002-07-29 22:05 ` Han-Wen 2002-07-31 17:03 ` Dirk Herrmann 2002-07-31 18:02 ` Han-Wen Nienhuys 2002-07-31 21:15 ` Rob Browning 2002-08-01 9:20 ` Release Guile, now ;-) [was:] " rm 2002-08-01 16:27 ` Rob Browning 2002-08-01 16:44 ` rm 2002-08-01 18:37 ` Sergey Poznyakoff 2002-08-01 22:21 ` Rob Browning 2002-08-02 6:09 ` Sergey Poznyakoff 2002-08-02 14:36 ` Rob Browning 2002-08-02 17:29 ` Sergey Poznyakoff 2002-08-02 18:10 ` Bruce Korb 2002-08-02 19:50 ` Rob Browning 2002-08-03 7:13 ` Sergey Poznyakoff 2002-08-04 20:43 ` Bruce Korb 2002-08-04 20:57 ` Sergey Poznyakoff 2002-08-01 22:40 ` Rob Browning 2002-08-02 9:35 ` rm 2002-08-02 11:59 ` rm 2002-08-02 15:00 ` Rob Browning 2002-08-02 14:50 ` Rob Browning 2002-08-01 9:59 ` Han-Wen Nienhuys 2002-08-01 8:46 ` Marius Vollmer 2002-07-31 18:46 ` Neil Jerram 2002-08-01 9:58 ` Han-Wen Nienhuys 2002-07-28 16:51 ` Michael Livshin
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).