Re-addition of deprecated stuff to 1.7.

Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Hi,

I have started to re-add most of the things that were deprecated in
1.6 and removed in 1.7.  I hope everyone agrees that this is OK.

The idea is that we should backwards compatability for a longer time
when it is easy enough to do.  I am adding the things in as clean a
way as possible, so that they do not get in the way of the mainline
code.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

    Marius> Hi, I have started to re-add most of the things that were
    Marius> deprecated in 1.6 and removed in 1.7.  I hope everyone
    Marius> agrees that this is OK.

Yes, but can it be done in a way that the back compatible bits are
kept separate from the core?  A while ago you mentioned something like
_GNU_SOURCE, which seems exactly right to me.

For example, an application would just say

#define _GUILE_SOURCE 1.6
#include <libguile.h>

And a 1.7.x/1.8.x libguile.h would have something at the end like

#if _GUILE_SOURCE = 1.6
#include <guile/compat-1.6.h>
#endif

Similarly, any back compatibility object code would ideally be in
libguile-compat-1.6.so; although I'm not sure how to make the linking
in of the extra library as automatic as possible for the application
author.

    Marius> The idea is that we should backwards compatability for a
    Marius> longer time when it is easy enough to do.  I am adding the
    Marius> things in as clean a way as possible, so that they do not
    Marius> get in the way of the mainline code.

It's possible that I may have described what you are already doing,
then :-)

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
> 
>     Marius> Hi, I have started to re-add most of the things that were
>     Marius> deprecated in 1.6 and removed in 1.7.  I hope everyone
>     Marius> agrees that this is OK.
> 
> Yes, but can it be done in a way that the back compatible bits are
> kept separate from the core?

Yes, mostly.  When too much need to change just to support a re-added
deprecated thing, I'm not re-adding it.  For example, vcells are not
coming back.

> A while ago you mentioned something like _GNU_SOURCE, which seems
> exactly right to me.
>
> For example, an application would just say
> 
> #define _GUILE_SOURCE 1.6
> #include <libguile.h>
> 
> And a 1.7.x/1.8.x libguile.h would have something at the end like
> 
> #if _GUILE_SOURCE = 1.6
> #include <guile/compat-1.6.h>
> #endif

Hmm, I don't think I would want to include version numbers explicitely
in this mechanism.  I would say that when some code wants to be
compiled against the Guile 1.6 API, it should be compiled against
Guile 1.6.

But with a version specific switch, we can have conflicting APIs.  But
for that, I'd say, we should have one switch per conflicting feature.
And that switch could be deprecated over time...

To illustrate, consider the change from a two-arg version of scm_eval
to the three-arg one.  When making the decision to make that change
(instead of just adding a new function), we can offer a switch that
activates the three-arg version:


   /* old code, using two-arg eval */

   #include <libguile.h>

   -------------------
   /* new code, using three-arg eval */

   #define GUILE_ENABLE_THREE_ARG_EVAL
   #include <libguile.h>

Later, we can deprecate the 'enable' variant and prefer a 'disable'
one:

   /* old code, using two-arg eval */
   #define GUILE_DISABLE_THREE_ARG_EVAL
   #include <libguile.h>

   -------------------
   /* new code, using three-arg eval */

   #include <libguile.h>

And still later, we can just remove GUILE_DISABLE_THREE_ARG_EVAL and
let the old code fail.

>     Marius> The idea is that we should backwards compatability for a
>     Marius> longer time when it is easy enough to do.  I am adding the
>     Marius> things in as clean a way as possible, so that they do not
>     Marius> get in the way of the mainline code.
> 
> It's possible that I may have described what you are already doing,
> then :-)

Maybe... I try to only modify the files deprecated.c, deprecated.h and
deprecated.scm.  The rest of the code remains mostly untouched.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> To illustrate, consider the change from a two-arg version of scm_eval
> to the three-arg one.  When making the decision to make that change
> (instead of just adding a new function), we can offer a switch that
> activates the three-arg version:
>
>
>    /* old code, using two-arg eval */
>
>    #include <libguile.h>
>
>    -------------------
>    /* new code, using three-arg eval */
>
>    #define GUILE_ENABLE_THREE_ARG_EVAL
>    #include <libguile.h>
>
> Later, we can deprecate the 'enable' variant and prefer a 'disable'
> one:

So would this be a user-code compile-time setting, or a libguile
compile time setting?  (I'm wondering/concerned about binary API
compatibility and versioning issues.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
> 
> > To illustrate, consider the change from a two-arg version of scm_eval
> > to the three-arg one.  When making the decision to make that change
> > (instead of just adding a new function), we can offer a switch that
> > activates the three-arg version:
> >
> >
> >    /* old code, using two-arg eval */
> >
> >    #include <libguile.h>
> >
> >    -------------------
> >    /* new code, using three-arg eval */
> >
> >    #define GUILE_ENABLE_THREE_ARG_EVAL
> >    #include <libguile.h>
> >
> > Later, we can deprecate the 'enable' variant and prefer a 'disable'
> > one:
> 
> So would this be a user-code compile-time setting, or a libguile
> compile time setting?

That would be a user-code compile-time setting.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Bruce Korb]

Marius Vollmer wrote:

> > #define _GUILE_SOURCE 1.6
> > #include <libguile.h>
> >
> > And a 1.7.x/1.8.x libguile.h would have something at the end like
> >
> > #if _GUILE_SOURCE = 1.6
> > #include <guile/compat-1.6.h>
> > #endif

>    /* new code, using three-arg eval */
> 
>    #define GUILE_ENABLE_THREE_ARG_EVAL
>    #include <libguile.h>
> 
> Later, we can deprecate the 'enable' variant and prefer a 'disable'
> one:
> 
>    /* old code, using two-arg eval */
>    #define GUILE_DISABLE_THREE_ARG_EVAL
>    #include <libguile.h>
> 
>    -------------------
>    /* new code, using three-arg eval */
> 
>    #include <libguile.h>
> 
> And still later, we can just remove GUILE_DISABLE_THREE_ARG_EVAL and
> let the old code fail.

I'm going to guess here, so please correct me if I am wrong.
I think the client model you are operating with is that someone
develops some code and gets it running on their local system and
then they are happy campers.  That is not what I am doing.  I
am distributing my stuff to whomever and they will use whatever
Guile happens to be installed on their systems.  Some of them are
using libguiles that are quite a few years old.  May I please
encourage you to supply configury stuff that is capable of
adapting current interfaces to old Guiles?  For example, it would
be _really_nice_ if it were to define a scm2newstr_size_t.  That
way I would not be completely unbuildable on I32LP64 platforms
that still use "int" for the size argument.  Stuff like that would
be Really Nice.

You also need to consider what happens when someone tries to build
an old variation of my code with an as-yet-unreleased Guile.  It
is not a bad idea at all for me to define:

   #define _GUILE_SOURCE 1.6

as a way of saying, "When this program was distributed, it was
cognizant of the interface through to 1.6."  'course, in my case
it may actually be 1.4 because I don't have the time to track
changes. :)  My desire is to use a small stable subset that
won't vary very much.  Which is also why I selected the advertized-
as-stable gh interface for as much as possible.  *sigh*.

P.S. If _anyone_ can show me how to set the string port file
name and line number, I *sure* would be a happy camper.
I've tried all the variations of all the suggestions and have
still failed to get it working, though at least I'm now printing
the line and column numbers within each string fragment.
I'll even write it up or, better, I think, is to provide a:

   <<whateverprefixyouwant>>_eval_str_with_file_and_line

function.  That would sure make life easier for the next one along.

Cheers, Bruce

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> I'm going to guess here, so please correct me if I am wrong.  I
> think the client model you are operating with is that someone
> develops some code and gets it running on their local system and
> then they are happy campers.  That is not what I am doing.  I am
> distributing my stuff to whomever and they will use whatever Guile
> happens to be installed on their systems.  Some of them are using
> libguiles that are quite a few years old.

I'd say it is a trade-off between how much pain you are willing to
inflict upon your clients and how much pain you are willing to suffer
yourself.

I think (and hope) it is entirely tolerable to require you clients to
install Guile 1.6 when they want to compile your code.  They should
not need to remove (the run-time parts of) Guile 1.4 for this; thus,
software that uses Guile 1.4 will continue to run.  Installing Guile
1.6 is no big deal, I hope.

The alternative, making sure that your code works with both Guile 1.4
and Guile 1.6, is much more painful and moreover, it wont allow your
code to cleanly take advantage of the 'new, improved' features of
Guile 1.6.

> May I please encourage you to supply configury stuff that is capable
> of adapting current interfaces to old Guiles?

Too much work for too little gain, I'd say.  Instead, we should make
it as easy as possible to install Guile 1.6 so that there is no reason
not to have it on ones system.

> For example, it would be _really_nice_ if it were to define a
> scm2newstr_size_t.  That way I would not be completely unbuildable
> on I32LP64 platforms that still use "int" for the size argument.
> Stuff like that would be Really Nice.

Yep, that's a bug in Guile 1.6.  We haven't been careful enough to
keep the public API backwards compatible.

For this specific bug, if you really need to work with both API
versions, I think it is best to have a configure check in your package
that detects what kind of gh_scm2newstr you are compiling against.
These configure snippets might be collected in a central place, maybe,
when people are willing to maintain such a thing.

But given the above, I think it is OK to just fail and require Guile
1.6.

> My desire is to use a small stable subset that won't vary very much.
> Which is also why I selected the advertized- as-stable gh interface
> for as much as possible.  *sigh*.

There are two reasons (at least) to want stability in an interface:
one is that your code works unchanged with multiple
versions/implementations of the other side of the API, another is that
you don't want to do the work of tracking the changes in an API.

In my opinion, the first reason is not very valid for Guile; there
should be no reason to require some code to compile _unchanged_
against multiple versions of Guile.  When there are such reasons, we
should work to remove the reasons, not to make it easier to compile
_unchanged_.

Not the emphasis on _unchanged_.  Not wanting to do much work when
tracking API changes is a very good position to take.  When changing
the Guile API, we should make it in such a way that client code needs
to change as little as possible.  This often means that it doesn't
need to change at all.  However, it is not an unbreakable requirement
that client code must continue to compile with all new versions of
Guile.  

It is of course good practice to minimize the needed changes, and we
probably have botched it a bit in the Guile 1.4 to Guile 1.6
transition.  Client code might need to change more than in an ideal
transition, but as I said, there should be no strong reasons not to
make these changes.

> P.S. If _anyone_ can show me how to set the string port file
> name and line number, I *sure* would be a happy camper.

I'm getting to that in a few minutes... :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Bruce Korb]

[-- Attachment #1: Type: text/plain, Size: 3912 bytes --]

Marius Vollmer wrote:

> I'd say it is a trade-off between how much pain you are willing to
> inflict upon your clients and how much pain you are willing to suffer
> yourself.
> 
> I think (and hope) it is entirely tolerable to require you clients to
> install Guile 1.6 when they want to compile your code.

As the author of a piece of code that is relatively obscure,
it is tough enough to get it test-driven, let alone test-driven
after they have had to upgrade something else.  Current distributions
are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1
use it).  These releases are not even a year old yet.  It *will*
be a couple of years before it is reasonable to expect all potential
clients to have 1.6.

> > May I please encourage you to supply configury stuff that is capable
> > of adapting current interfaces to old Guiles?
> 
> Too much work for too little gain, I'd say.  Instead, we should make
> it as easy as possible to install Guile 1.6 so that there is no reason
> not to have it on ones system.

I sent some macros, tho I coded around the need to use it myself.

> These configure snippets might be collected in a central place, maybe,
> when people are willing to maintain such a thing.

That's what I was suggesting...

> But given the above, I think it is OK to just fail and require Guile
> 1.6.

Too early.

> There are two [main] reasons... to want stability in an interface:
> one is that your code works unchanged with multiple
> versions/implementations of the other side of the API, another is that
> you don't want to do the work of tracking the changes in an API.

> In my opinion, the first reason is not very valid for Guile; there
> should be no reason to require some code to compile _unchanged_
> against multiple versions of Guile.  When there are such reasons, we
> should work to remove the reasons, not to make it easier to compile
> _unchanged_.

I don't want to really say, "unchanged".  I do want to say
that the compatibility glue is important.  I am now developing against
1.6.  However, as much as you would like to see 1.4 retired,
the bulk of the distributions at this time have 1.4.  I need
to be able to jigger what I use so it can adapt to whatever
is locally installed.  By the time the bulk of installations
are running 1.6, you'll be shipping 1.8 and using the same arguments.

> Note the emphasis on _unchanged_.  Not wanting to do much work when
> tracking API changes is a very good position to take.

I'm taking both positions (I get to, I'm not developing Guile ;-).
But I'm also willing to share what I've done.  (Attached are two
configury macros.  One to find libguile, even on systems where
guile-config was omitted [Red Hat], the other to detect 1.4 systems
and provide #define glue for scm_eval_x and scm_port.)

> When changing
> the Guile API, we should make it in such a way that client code needs
> to change as little as possible.  This often means that it doesn't
> need to change at all.  However, it is not an unbreakable requirement
> that client code must continue to compile with all new versions of
> Guile.

That's a little extreme.  OTOH, when you retire ``scm_port'' you
could also add:

  #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6)
  #  define  scm_port scm_t_port
  #endif

and delete that code only after 1.6 has been in the major distros
for a couple of years.  The Guile version I understand is a
mix of 1.4 and 1.6 'cuz I'm transitioning.  The attached configury
checks for 1.4 and does the reverse #define:

  /* Define this if no scm_t_port */
  #define scm_t_port scm_port

> It is of course good practice to minimize the needed changes,

I'm sure you do your best.  One's best cannot ever be perfect.

> > P.S. If _anyone_ can show me how to set the string port file
> > name and line number, I *sure* would be a happy camper.
> 
> I'm getting to that in a few minutes... :-)

Cool.  :-D

[-- Attachment #2: libguile.m4 --]
[-- Type: text/plain, Size: 5035 bytes --]


AC_DEFUN([AG_WITHLIB_GUILE],[
  AC_ARG_WITH([libguile],
    AC_HELP_STRING([--with-libguile], [libguile installation prefix]),
    [ag_cv_with_libguile_root=${with_libguile}],
    AC_CACHE_CHECK([whether with-libguile was specified], ag_cv_with_libguile_root,
      ag_cv_with_libguile_root=no)
  ) # end of AC_ARG_WITH libguile

  if test "${with_libguile+set}" = set && \
     test "${withval}" = no
  then ## disabled by request
    ag_cv_with_libguile_root=no
    ag_cv_with_libguile_cflags=no
    ag_cv_with_libguile_libs=no
  else

  AC_ARG_WITH([libguile-cflags],
    AC_HELP_STRING([--with-libguile-cflags], [libguile compile flags]),
    [ag_cv_with_libguile_cflags=${with_guile_cflags}],
    AC_CACHE_CHECK([whether with-libguile-cflags was specified], ag_cv_with_libguile_cflags,
      ag_cv_with_libguile_cflags=no)
  ) # end of AC_ARG_WITH libguile-cflags

  AC_ARG_WITH([libguile-libs],
    AC_HELP_STRING([--with-libguile-libs], [libguile link command arguments]),
    [ag_cv_with_libguile_libs=${with_guile_libs}],
    AC_CACHE_CHECK([whether with-libguile-libs was specified], ag_cv_with_libguile_libs,
      ag_cv_with_libguile_libs=no)
  ) # end of AC_ARG_WITH libguile-libs

  case "X${ag_cv_with_libguile_cflags}" in
  Xyes|Xno|X )
    case "X${ag_cv_with_libguile_root}" in
    Xyes|Xno|X ) ag_cv_with_libguile_cflags=no ;;
    * )        ag_cv_with_libguile_cflags=-I${ag_cv_with_libguile_root}/include ;;
    esac
  esac
  case "X${ag_cv_with_libguile_libs}" in
  Xyes|Xno|X )
    case "X${ag_cv_with_libguile_root}" in
    Xyes|Xno|X ) ag_cv_with_libguile_libs=no ;;
    * )        ag_cv_with_libguile_libs="-L${ag_cv_with_libguile_root}/lib -lguile";;
    esac
  esac
  ag_save_CPPFLAGS="${CPPFLAGS}"
  ag_save_LIBS="${LIBS}"
  case "X${ag_cv_with_libguile_cflags}" in
  Xyes|Xno|X )
    f=`guile-config compile 2>/dev/null` || f=''
    test -n "${f}" && ag_cv_with_libguile_cflags="${f}" && \
      AC_MSG_NOTICE([guile-config used for CFLAGS: $f]) ;;
  esac
  case "X${ag_cv_with_libguile_libs}" in
  Xyes|Xno|X )
    f=`guile-config link 2>/dev/null` || f=''
    test -n "${f}" && ag_cv_with_libguile_libs="${f}" && \
      AC_MSG_NOTICE([guile-config used for LIBS: $f]) ;;
  esac
  fi ## disabled by request

  case "X${ag_cv_with_libguile_cflags}" in
  Xyes|Xno|X )
    ag_cv_with_libguile_cflags="" ;;
  * ) CPPFLAGS="${CPPFLAGS} ${ag_cv_with_libguile_cflags}" ;;
  esac
  case "X${ag_cv_with_libguile_libs}" in
  Xyes|Xno|X )
    LIBS="${LIBS} -lguile"
    ag_cv_with_libguile_libs="-lguile" ;;
  * )
    LIBS="${LIBS} ${ag_cv_with_libguile_libs}" ;;
  esac
  LIBGUILE_CFLAGS=""
  LIBGUILE_LIBS=""
  AC_MSG_CHECKING([whether libguile can be linked with])
  AC_CACHE_VAL([ag_cv_with_libguile],[
  AC_LINK_IFELSE([[@%:@include <guile/gh.h>
@%:@include <libguile.h>
int main () {
  SCM fumble, bumble, stumble;
  stumble = scm_cons( fumble, bumble );
  stumble = scm_display( fumble, bumble );
  stumble = scm_ilength( fumble );
  stumble = scm_makstr( 1, 2 );
  stumble = gh_eval_str( "stumble" );
  scm_misc_error( "oops", "bad", bumble );
  stumble = scm_num_eq_p( fumble, bumble );
  scm_wrong_type_arg( "oops", 1, bumble );
  return 0; }]],
    [ag_cv_with_libguile=yes],
    [ag_cv_with_libguile=no]) # end of AC_LINK_IFELSE 
  ]) # end of AC_CACHE_VAL for ag_cv_with_libguile
  AC_MSG_RESULT([${ag_cv_with_libguile}])
    AC_SUBST([LIBGUILE_CFLAGS])
    AC_SUBST([LIBGUILE_LIBS])
    AC_SUBST([LIBGUILE_PATH])

  if test "X${ag_cv_with_libguile}" != Xno
  then[
      LIBGUILE_CFLAGS="${ag_cv_with_libguile_cflags}"
      LIBGUILE_LIBS="${ag_cv_with_libguile_libs}"
      case "${LIBGUILE_LIBS}" in *-L* )
        LIBGUILE_PATH=`echo ${LIBGUILE_LIBS} | sed 's/.*-L[ 	]*//;s/[ 	].*//'`
      ;; * ) LIBGUILE_PATH='' ;; esac]
      CPPFLAGS="@S|@{ag_save_CPPFLAGS}"
  LIBS="@S|@{ag_save_LIBS}"
  else
    CPPFLAGS="${ag_save_CPPFLAGS}"
    LIBS="${ag_save_LIBS}"
      LIBGUILE_CFLAGS=''
      LIBGUILE_LIBS=''
      LIBGUILE_PATH=''
      AC_MSG_ERROR([Cannot find working libguile])
  fi
  AC_SUBST([AG_GUILE])
  
]) # end of AC_DEFUN of AG_WITHLIB_GUILE


AC_DEFUN([AG_LINK_EVAL_STRING],[
  AC_MSG_CHECKING([whether scm_primitive_eval_x links])
  AC_CACHE_VAL([ag_cv_link_eval_string],[
    ag_save_CPPFLAGS="${CPPFLAGS}"
    CPPFLAGS="${ag_cv_with_libguile_cflags} ${CPPFLAGS}"
    ag_save_LIBS="${LIBS}"
    LIBS="${ag_cv_with_libguile_libs} ${LIBS}"
  AC_TRY_LINK([@%:@include <guile/gh.h>
@%:@include <libguile.h>],
    [SCM res = scm_primitive_eval_x( SCM_UNDEFINED );],
    [ag_cv_link_eval_string=yes],[ag_cv_link_eval_string=no]
  ) # end of TRY_LINK
    CPPFLAGS="${ag_save_CPPFLAGS}"
    LIBS="${ag_save_LIBS}"
  ]) # end of AC_CACHE_VAL for ag_cv_link_eval_string
  AC_MSG_RESULT([${ag_cv_link_eval_string}])

  if test "X${ag_cv_link_eval_string}" = Xno
  then
    AC_DEFINE([scm_primitive_eval_x], [scm_eval_x],
        [Define this if no scm_primitive_eval_x])
AC_DEFINE([scm_t_port], [scm_port], [Define this if no scm_t_port])
  fi
  
]) # end of AC_DEFUN of AG_LINK_EVAL_STRING

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> Marius Vollmer wrote:
> 
> > I'd say it is a trade-off between how much pain you are willing to
> > inflict upon your clients and how much pain you are willing to suffer
> > yourself.
> > 
> > I think (and hope) it is entirely tolerable to require you clients to
> > install Guile 1.6 when they want to compile your code.
> 
> As the author of a piece of code that is relatively obscure,
> it is tough enough to get it test-driven, let alone test-driven
> after they have had to upgrade something else.  Current distributions
> are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1
> use it).  These releases are not even a year old yet.  It *will*
> be a couple of years before it is reasonable to expect all potential
> clients to have 1.6.

Yes, maybe.  What about talking the distros into providing Guile 1.6
sooner?  That would make more sense, in my view.  We could provide
RPMs for Red Hat, Suse, and DEBs for Debian stable.  That will make it
easier to retrofit ones system with Guile 1.6.

> I sent some macros, tho I coded around the need to use it myself.
> 
> > These configure snippets might be collected in a central place, maybe,
> > when people are willing to maintain such a thing.
> 
> That's what I was suggesting...

Ok.  So how shall we proceed?  I'm don't want to make it a
release-critical goal of Guile 1.8 to come with such a set of snippets
unless there is more demand from 'the community'.  However, the
snippets can be collected in the Guile CVS repo, when people want to
do that.  We will have to apply all the usual FSF legal rules to them,
tho: copyright must be assigned, etc.

> [...]  I do want to say that the compatibility glue is important.  I
> am now developing against 1.6.  However, as much as you would like
> to see 1.4 retired, the bulk of the distributions at this time have
> 1.4.  I need to be able to jigger what I use so it can adapt to
> whatever is locally installed.

So you are effectively targeting 1.4 and 1.6, not just 1.6 alone.  I'm
not sure what kind of compatability glue you are talking about: do you
want to have a layer that makes 1.4 identical to 1.6?  Or do you want
a layer that fixes bugs (such as the gh_scm2newstring size_t bug) so
that code that worked with 1.4 continues to work with 1.6?

Neither of these two types of compatability glue makes much sense to
me: for the first, it is easier to use the genuine Guile 1.6 as the
'layer'.  Just package it with your code when you don't want your
clients to download and install it themselves.  For the second type,
it is easier to just stick with Guile 1.4, which should be available
already on your clients system, as you say.

>  By the time the bulk of installations are running 1.6, you'll be
> shipping 1.8 and using the same arguments.

Yes.  And I sill think they are sensible arguments.

> [...]  OTOH, when you retire ``scm_port'' you could also add:
> 
>   #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6)
>   #  define  scm_port scm_t_port
>   #endif
> 
> and delete that code only after 1.6 has been in the major distros
> for a couple of years.

Yes, we are doing this now (kind of) and are being more careful than
we have been with 1.6.  See the "Handling of Deprecated Features"
section in the README.

Incidentally, "scm_port" is available with Guile 1.6, but I see that
you want to have "scm_t_port" with 1.4.  That's a strange thing to do,
in my view: you can't get the 'goodness' of 1.6 from 1.4.  You might
create the illusion in simple cases like scm_port, but this wont work
in general.  The result is code that is written is then a, in your own
words:

> The Guile version I understand is a mix of 1.4 and 1.6 'cuz I'm
> transitioning.

Coding for such a mixed API is not on the path of least pain, I'd say.

> > It is of course good practice to minimize the needed changes,
> 
> I'm sure you do your best.  One's best cannot ever be perfect.

But we are getting better!  :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel