Re: [Bug-autogen] test failure with guile-2.0.2

[Andy Wingo]

Hi Bruce,

On Wed 13 Jul 2011 17:11, Bruce Korb <address@hidden> writes:

> On 07/13/11 06:41, Andy Wingo wrote:
>> the new interface name is libguile-2.0.so.
>
> Well, yes, but for source distributions, it gets compiled and linked
> against whatever the current platform's default Guile happens to be.

I would like to avoid this circumstance in the future, while still
preserving Guile's ability to change.  Hopefully whenever you decide
that you can stop supporting Guile 1.6, as we have, then you can switch
to use pkg-config.  This will allow you to specify the versions of Guile
that you support, at build-time, *and choose them* from among a number
of installed Guile versions.

This way, you only deal with changes in Guile 2.2 *when you choose* to
upgrade to Guile 2.2.  Presumably at that point you read the NEWS as
well :-)

But, with the current guile-config situation, that's not the case.  You
end up dealing with changes in Guile when you're trying to do something
else, as now.  But it's bugs versus bugs, right?  What did you expect us
to do, deprecate scm_from_locale_string because in 1.8 it could be
treated as a byte array, after introducing it in 1.8?

> New name, please.

We'll try harder in the future.  But we cannot change the fact that
scm_from_locale_string does decode its argument.

One thing we might be able to do is Mark Weaver's "permissive" string
trick using the reserved unicode codepoints.  That code doesn't exist
yet though.

> #if   GUILE_VERSION < 107000
> # define AG_SCM_BOOL_P(_b)            SCM_BOOLP(_b)
> # define AG_SCM_CHAR(_c)              gh_scm2char(_c)

IMO, this is not the way to do deprecation.  The way to go is to use the
new names, and #define implementations for older Guile.  That way your
source is cleaner, and you get deprecation messages when current
functions are deprecated.

So here you should use scm_is_bool and SCM_CHAR.

> # define AG_SCM_CHARS(_s)             SCM_CHARS(_s)
[...]
> #elif GUILE_VERSION < 201000
> # define AG_SCM_CHARS(_s)             scm_i_string_chars(_s)

This is totally incorrect, and a bit dangerous.  It won't work if you
have a wide string.  The "_i_" in the name is for "internal".  From the
NEWS from 1.8.0, from February 2006, notes:

    ** The macros SCM_STRINGP, SCM_STRING_CHARS, SCM_STRING_LENGTH,
       SCM_SYMBOL_CHARS, and SCM_SYMBOL_LENGTH have been deprecated.

    They export too many assumptions about the implementation of strings
    and symbols that are no longer true in the presence of
    mutation-sharing substrings and when Guile switches to some form of
    Unicode.

    When working with strings, it is often best to use the normal string
    functions provided by Guile, such as scm_c_string_ref,
    scm_c_string_set_x, scm_string_append, etc.  Be sure to look in the
    manual since many more such functions are now provided than
    previously.

    When you want to convert a SCM string to a C string, use the
    scm_to_locale_string function or similar instead.  For symbols, use
    scm_symbol_to_string and then work with that string.  Because of the
    new string representation, scm_symbol_to_string does not need to copy
    and is thus quite efficient.

You'll be much less surprised at things if you read the NEWS when new
major versions are released :-)

Finally, as I think we have discussed already all of the relevant
aspects of this situation, we need to move on.  The easiest thing to do
is for you to put in a couple of #defines for
scm_{from,to}_latin1_string.  Then we can go back to building GNU!

Regards,

Andy
-- 
http://wingolog.org/