GC rewrite, first version.

GC rewrite, first version.

[Han-Wen]

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

Re: GC rewrite, first version.

[Rob Browning]

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

Re: GC rewrite, first version.

[Michael Livshin]

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

Re: GC rewrite, first version.

[Dirk Herrmann]

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

Re: GC rewrite, first version.

[Rob Browning]

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

Re: GC rewrite, first version.

[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 :>

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

Re: GC rewrite, first version.

[Dirk Herrmann]

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

Re: GC rewrite, first version.

[Han-Wen Nienhuys]

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

Re: GC rewrite, first version.

[Neil Jerram]

>>>>> "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

Re: GC rewrite, first version.

[Rob Browning]

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

Re: GC rewrite, first version.

[Marius Vollmer]

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

Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[rm]

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

Re: GC rewrite, first version.

[Han-Wen Nienhuys]

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

Re: GC rewrite, first version.

[Han-Wen Nienhuys]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[rm]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Sergey Poznyakoff]

> 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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Sergey Poznyakoff]

> 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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[rm]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[rm]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Sergey Poznyakoff]

> > 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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Bruce Korb]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Rob Browning]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Sergey Poznyakoff]

> 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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Bruce Korb]

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

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

[Sergey Poznyakoff]

> 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