Re: SCM_LENGTH ???

Re: SCM_LENGTH ???

[Bruce Korb]

Hi Guile folks,

I got this problem report based on Guile 1.7.1.
I do not know what Guile 1.7.1 is supposed to be, but
my stuff still works against 1.6.7.  I do hope you are
not planning to eliminate SCM_LENGTH and SCM_SUBSTRP!!
Where did 1.7.1 come from anyway???

Thanks !  Regards, - Bruce

"SourceForge.net" wrote:
> 
> Support Requests item #1097543, was opened at 2005-01-06 15:54
> Message generated for change (Comment added) made by mckelvey
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=203593&aid=1097543&group_id=3593
> 
> Category: None
> Group: None
> Status: Open
> Priority: 5
> Submitted By: James W. McKelvey (mckelvey)
> Assigned to: Bruce Korb (bkorb)
> Summary: 5.6.5 Build Failure on Cygwin
> 
> Initial Comment:
> Link failure on symbols beginning with "SCM".
> 
> ./configure --disable-nls --disable-shared
> 
> $ uname -a
> CYGWIN_NT-5.1 jmckelvey-xp 1.5.12(0.116/4/2) 2004-11-10
> 08:34 i686 unknown unkno
> wn Cygwin
> 
> mckelvey@jmckelvey-xp ~/utilities/autogen-5.6.5
> $ cc -v
> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.1/specs
> Configured with: /gcc/3.4/gcc-3.4.1-1/configure
> --verbose --prefix=/usr --exec-p
> refix=/usr --sysconfdir=/etc --libdir=/usr/lib
> --libexecdir=/usr/lib --mandir=/u
> sr/share/man --infodir=/usr/share/info
> --enable-languages=c,ada,c++,f77,java,obj
> c --enable-nls --without-included-gettext
> --enable-libgcj --with-system-zlib --e
> nable-interpreter --enable-threads=posix
> --enable-java-gc=boehm --enable-sjlj-ex
> ceptions --disable-version-specific-runtime-libs
> --disable-win32-registry
> Thread model: posix
> gcc version 3.4.1 (cygming special)
> 
> <snip>
> cc -g -O2 -o autogen.exe autogen-ag.o
> -Wl,-R/usr/local/lib -Wl,--export-dynamic
> ../autoopts/.libs/libopts.a /usr/lib/libguile.dll.a
> /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a
> /usr/lib/libguile-ltdl.dll.a /usr/lib/libltdl.dll.a
> /usr/lib/libgmp.dll.a -lcrypt
> autogen-ag.o(.text+0x4a26): In function `ag_scm_dne':
> /cygdrive/c/jimdata/home/utilities/autogen-5.6.5/agen5/expFormat.c:161:
> undefined reference to `_SCM_LENGTH'
> autogen-ag.o(.text+0x4a49): In function `ag_scm_dne':
> /cygdrive/c/jimdata/home/utilities/autogen-5.6.5/agen5/autogen.h:481:
> undefined reference to `_SCM_SUBSTRP'
> autogen-ag.o(.text+0x4a59):/cygdrive/c/jimdata/home/utilities/autogen-5.6.5/agen5/autogen.h:482:
> undefined reference to `_SCM_CHARS'      etc ...
> 
> ----------------------------------------------------------------------
> 
> >Comment By: James W. McKelvey (mckelvey)
> Date: 2005-01-07 08:42
> 
> Message:
> Logged In: YES
> user_id=4633
> 
> $ guile --version
> Guile 1.7.1
> 
> mckelvey@jmckelvey-xp ~
> $ guile-config link
>  -lguile -lguile-ltdl -lgmp -lcrypt -lm
> 
> mckelvey@jmckelvey-xp ~
> $ guile-config compile
> -I /nonexistent/include
> 
> Oddly, this version is later than the version available from
> Gnu. The symbols.h file is completely different from the 1.6.7
> version.
> 
> I'm running a recently upgraded Cygwin with the latest (Exp)
> stuff.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Bruce Korb (bkorb)
> Date: 2005-01-06 16:22
> 
> Message:
> Logged In: YES
> user_id=19940
> 
> What version of Guile are you using.  e.g. line 161 of expFormat.c:
> 
>     if (SCM_LENGTH( prefix ) > 128 )
>         AG_ABEND( aprf( zPfxMsg, zPfxLen, 128 ));
> 
> should be defined in the libguile symbols.h header:
> 
> ./libguile/symbols.h:#define SCM_LENGTH(x) \
>   (((unsigned long) SCM_CELL_WORD_0 (x)) >> 8)
> 
> Type: "guile-config link" and "guile-config compile" and
> "guile --version" to get the interesting information.
> Thanks


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> I got this problem report based on Guile 1.7.1.
> I do not know what Guile 1.7.1 is supposed to be, but
> my stuff still works against 1.6.7.

1.7.1 is a 'technology preview' of the upcoming 1.8 release.  See the
announcement at http://www.gnu.org/software/guile/ (or below).

> I do hope you are not planning to eliminate SCM_LENGTH and
> SCM_SUBSTRP!!

We are!  In fact, SCM_LENGTH is already deprecated in 1.6, but not in
a very verbose way.

In 1.7, SCM_LENGTH has been removed.  You need to use
scm_c_string_length or scm_c_vector_length, as appropriate.  (Or stick
with 1.6.)

> Where did 1.7.1 come from anyway???

It came from alpha.gnu.org.  Here is the announcement again:

We are pleased to announce the release of Guile 1.7.1.  This is a
'technology preview' for the upcoming Guile 1.8.  It can be found
here:

    ftp://alpha.gnu.org/gnu/guile/guile-1.7.1.tar.gz

Its MD5 checksum is

    21c9f4061166900d2926955ade0ef5cc  guile-1.7.1.tar.gz

This version is guaranteed to contain serious bugs, and the publically
visible interfaces will almost certainly change before 1.8 is
released.  The 1.7 releases might be termed "selected snapshots".

We are releasing it anyway to start testing the new features, and to
get feedback about how difficult or tedious it is to switch from Guile
1.6 to this series.

Ideally, you should be able to just link your program with Guile 1.7.1
instead of with Guile 1.6.x.  You will get many warnings about
deprecated features, but your program should nevertheless run
correctly.  If you find that this is not the case (which is quite
likely) please do not change your program yet.  Instead, report the
problem to <bug-guile@gnu.org>.

The shared library major versions have been bumped compared to the 1.6
series, but they will not be bumped on binary incompatible changes
within the 1.7 series.


The NEWS file is quite long.  Here are the most spectacular entries in
a condensed form:

  Changes since the 1.6.x series:

  - Guile is now licensed with the GNU Lesser General Public License.

  - The manual is now licensed with the GNU Free Documentation License.

  - We now use GNU MP for bignums.

  - We now use native POSIX threads for real concurrent threads.

  - There is now support for copy-on-write substrings and
    mutation-sharing substrings.

  - We now have exact rationals, such as 1/3.

  - A new family of functions for converting between C values and
    Scheme values has been added that is future-proof and thread-safe.

  - The INUM macros like SCM_MAKINUM have been deprecated.

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

  - There is a new way to deal with non-local exits and re-entries in
    C code, which is nicer than scm_internal_dynamic_wind.

  - There are new malloc-like functions that work better than
    scm_must_malloc, etc.

and most importantly

  - call-with-current-continuation is now also available under the name
    call/cc.

See NEWS and the manual for more details.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Bruce Korb]

Marius Vollmer wrote:

> We are!  In fact, SCM_LENGTH is already deprecated in 1.6, but not in
> a very verbose way.

That is wrong.  A comment in an obscure document somewhere
is insufficient notice.  You must do something to get someone's
attention.  In my case, I got bumped by someone trying to install
my stuff using an *ALPHA* version of Guile.  Bad.  Very bad.

> In 1.7, SCM_LENGTH has been removed.  You need to use
> scm_c_string_length or scm_c_vector_length, as appropriate.  (Or stick
> with 1.6.)

I cannot control my clients.  They will use whatever is installed.
They could (and do) still use 1.4.  Are these scm_c_*_length functions
available in 1.6 (let alone 1.4)?   DO NOT DISCARD INTERFACES WITHOUT
A _VERY_ LONG TRANSITION and please supply a bridge:

# define SCM_LENGTH(e) \
    (gh_string_p(e) ? scm_c_string_length(e) : scm_c_vector_length(e))

and please do not say, "use configury and do it yourself".
You see, I already have software in the field that cannot
be magically retrofit with such a definition.

> > Where did 1.7.1 come from anyway???
> 
> It came from alpha.gnu.org.  Here is the announcement again:
> 
> We are pleased to announce the release of Guile 1.7.1.  This is a
> 'technology preview' for the upcoming Guile 1.8.  It can be found
> here:
...
> This version is guaranteed to contain serious bugs, and the publically
> visible interfaces will almost certainly change before 1.8 is
> released.  The 1.7 releases might be termed "selected snapshots".

A disappearing interface is certainly a bug.

> We are releasing it anyway to start testing the new features, and to
> get feedback about how difficult or tedious it is to switch from Guile
> 1.6 to this series.

It is not possible to migrate released software.
Please ensure that *ALL* legacy interfaces are maintained.
Thank you.

Regards, Bruce

P.S. please forgive my crankiness.  It's been a long week....Sorry.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> Marius Vollmer wrote:
>
>> We are!  In fact, SCM_LENGTH is already deprecated in 1.6, but not in
>> a very verbose way.
>
> That is wrong.  A comment in an obscure document somewhere
> is insufficient notice.  You must do something to get someone's
> attention.

Yes, true.  In 1.7 it was deprecated in a verbose way, but I removed
it completely when redoing the string implementation because, well,
sometimes I just don't want to have that stuff in there any longer and
can't constrain myself properly... I have brought back SCM_LENGTH,
SCM_CHARS, and SCM_UCHARS.

The recommended way to check for deprecated features is to compile a
version of Guile with --disable-deprecated and compile/link/test
against that.

> I cannot control my clients.  They will use whatever is installed.

Which is not always going to work, period.  Programs do have
reqirements that must be honored by the clients of these programs.
The less requirements there are, the better, but it is unrealistic to
aim for zero requirements.  Requiring Guile 1.6 is very reasonable in
my view, especially since it is still maintained.  Guile 1.4 is also
still around (if not 'officially' whatever that means).

> They could (and do) still use 1.4.  Are these scm_c_*_length functions
> available in 1.6 (let alone 1.4)?

No.

> DO NOT DISCARD INTERFACES WITHOUT A _VERY_ LONG TRANSITION and
> please supply a bridge:
>
> # define SCM_LENGTH(e) \
>     (gh_string_p(e) ? scm_c_string_length(e) : scm_c_vector_length(e))

We had this in 1.7 for a long time, and yes, I should not have removed
it.  It is back now.

>> This version is guaranteed to contain serious bugs, and the publically
>> visible interfaces will almost certainly change before 1.8 is
>> released.  The 1.7 releases might be termed "selected snapshots".
>
> A disappearing interface is certainly a bug.

No, if the interface itself is buggy, I'd say removing it is a
feature. :-)

>> We are releasing it anyway to start testing the new features, and to
>> get feedback about how difficult or tedious it is to switch from Guile
>> 1.6 to this series.
>
> It is not possible to migrate released software.

You are not supposed to.  Just use 1.6 for the old releases and
require 1.8 for the new ones, if you see a benefit.

> Please ensure that *ALL* legacy interfaces are maintained.

Unfortunately, the legacy interfaces of Guile are problematic.
Traditionally, Guile has exposed lots of its internal implementation
details (such as the fact that strings, symbols, and vectors stored
their length in the same way), and because of the lack of clean
alternatives and also lack of proper documentation, people have made
use of these internals in their programs.  We try to slowly fix this
situation.

So, SCM_LENGTH is definitely deprecated and you need to stop using it
eventually.  The alternatives are hopefully much better and will stay
around much longer.

> P.S. please forgive my crankiness.  It's been a long week....Sorry.

No problem, posts like yours do make a difference.  Please keep them
coming!


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Bruce Korb]

On Monday 10 January 2005 09:26 am, Marius Vollmer wrote:

> The recommended way to check for deprecated features is to compile a
> version of Guile with --disable-deprecated and compile/link/test
> against that.

That's a cute idea.  I like it!  I confess, I don't remember it from the last
time I went through the Guile docs.  When was that?  '99 or '98?
Have the docs changed much since then?  ;-)

> > I cannot control my clients.  They will use whatever is installed.
> 
> Which is not always going to work, period.  Programs do have
> reqirements that must be honored by the clients of these programs.
> The less requirements there are, the better, but it is unrealistic to
> aim for zero requirements.  Requiring Guile 1.6 is very reasonable in
> my view, especially since it is still maintained.

Well, 1.4 is old enough that requiring something newer isn't a problem
for me.

> > They could (and do) still use 1.4.  Are these scm_c_*_length functions
> > available in 1.6 (let alone 1.4)?
> 
> No.

However, it is a bit premature to use scm_c_*_length functions since
1.7.x is a test release series and 1.8 is not available.  :)  Thank you
for restoring the compatibility stuff!

> >> This version is guaranteed to contain serious bugs, and the publically
> >> visible interfaces will almost certainly change before 1.8 is
> >> released.  The 1.7 releases might be termed "selected snapshots".
> >
> > A disappearing interface is certainly a bug.
> 
> No, if the interface itself is buggy, I'd say removing it is a
> feature. :-)

OK.  A feature then.  Whether a feature or a bug, it breaks my released
software.  :-(

> > It is not possible to migrate released software.
> 
> You are not supposed to.  Just use 1.6 for the old releases and
> require 1.8 for the new ones, if you see a benefit.

1.4 is adequate for my needs (though I agree it is old enough to
not worry about anymore).  So, I want to build to an interface that
works for either 1.6 *or* 1.8 and I would really hope for binary
compatibility between them as well.  Once 1.6.x has been dormant
for a couple of years, *then* one can stop fretting over clients
still using the thing.

> > Please ensure that *ALL* legacy interfaces are maintained.
> 
> Unfortunately, the legacy interfaces of Guile are problematic.
> Traditionally, Guile has exposed lots of its internal implementation
> details (such as the fact that strings, symbols, and vectors stored
> their length in the same way), and because of the lack of clean
> alternatives and also lack of proper documentation, people have made
> use of these internals in their programs.  We try to slowly fix this
> situation.

To me, this still feels like grubbing around in internals and I do wish
you all were willing to supply something that approximates it.
I loathe having this in my code:

SCM
ag_scm_c_eval_string_from_file_line(
   const char* pzExpr, const char* pzFile, int line )
{
    SCM port;

    {
        static const char zEx[] = "eval-string-from-file-line";
        SCM  expr  = scm_makfrom0str( pzExpr );
        port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
    }

    {
        SCM file = scm_makfrom0str( pzFile );
        scm_t_port* pt = SCM_PTAB_ENTRY(port);
        pt->line_number = line - 1;
        pt->file_name   = file;
    }

    {
        SCM ans = SCM_UNSPECIFIED;

        /* Read expressions from that port; ignore the values.  */
        for (;;) {
            SCM form = scm_read( port );
            if (SCM_EOF_OBJECT_P( form ))
                break;
            ans = scm_primitive_eval_x( form );
        }

        return ans;
    }
}

> So, SCM_LENGTH is definitely deprecated and you need to stop using it
> eventually.  The alternatives are hopefully much better and will stay
> around much longer.

Excellent.  Thank you.

Regards, Bruce


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Ken Raeburn]

On Jan 10, 2005, at 12:26, Marius Vollmer wrote:
> The recommended way to check for deprecated features is to compile a
> version of Guile with --disable-deprecated and compile/link/test
> against that.

It might be a bit annoying to do in the source, but what about flagging 
deprecated symbols while still allowing their use, in the 
non-"--disable-deprecated" case?

E.g., declare a function SCM_LENGTH, which is declared in the header 
file with a macro which under recent enough versions of GCC expands to 
__attribute__((deprecated)) and on Windows to __declspec(deprecated), 
and in the source file defining the routine, on systems with the right 
compiler and assembler support, create a .gnu.warning.SCM_LENGTH (or 
.gnu.warning._SCM_LENGTH) section containing a message telling the user 
that the function will go away in a future release.  (As I understand 
it, on Windows you can even deprecate a macro by name.)

It won't work on all systems, but it should work on a lot of the 
configurations we'd care most about.  And if a macro is deprecated, the 
overhead of a function call shouldn't be a big deal, as long as the 
semantics are such that it can actually be implemented with a function 
call.

I started working out some configure tests and such to implement this 
at work, I could try to flesh them out a bit more if you like.  (I 
*think* I've got all my papers in order, but I don't know for sure if 
I've got papers in from my current employer, MIT, to cover Guile.  I 
haven't done the GNU maintainer bit in a while, could someone remind me 
where the list is?  Or check it for me?)

Ken



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Greg Troxel]

  1.4 is adequate for my needs (though I agree it is old enough to
  not worry about anymore).  So, I want to build to an interface that
  works for either 1.6 *or* 1.8 and I would really hope for binary
  compatibility between them as well.  Once 1.6.x has been dormant
  for a couple of years, *then* one can stop fretting over clients
  still using the thing.

Note that it is now - when a 1.7 release is happening that we can say
to those running 1.4 "you really should upgrade".  Until a few months
ago NetBSD pkgsrc compiled gnucash with 1.4.   Infrastructure is slow
to migrate.

The real issue is that we want people to use guile, and thus have to
be better about backwards compat than it might seem at first glance.

For me, it's source-level compat - I have no expectation of running
the same binary with with 1.6 or 1.8 shlibs.


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Bruce Korb]

On Monday 10 January 2005 12:34 pm, Ken Raeburn wrote:

> It won't work on all systems, but it should work on a lot of the 
> configurations we'd care most about.  And if a macro is deprecated, the 
> overhead of a function call shouldn't be a big deal, as long as the 
> semantics are such that it can actually be implemented with a function 
> call.

That would be great!  Please!  Thank you - Bruce


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> On Monday 10 January 2005 09:26 am, Marius Vollmer wrote:
>
>> The recommended way to check for deprecated features is to compile a
>> version of Guile with --disable-deprecated and compile/link/test
>> against that.
>
> That's a cute idea.  I like it!  I confess, I don't remember it from the last
> time I went through the Guile docs.  When was that?  '99 or '98?
> Have the docs changed much since then?  ;-)

Yes!

>> [...]
> However, it is a bit premature to use scm_c_*_length functions since
> 1.7.x is a test release series and 1.8 is not available.

Yes, you are right.  The recommended way in 1.6 is to use
SCM_STRING_LENGTH, for example.  It _is_ annoying to have to switch
away from SCM_STRING_LENGTH in 1.8 again, I have to agree to that.
(The reason for this is that 1.8 wants you to move away from making
assumptions about the internals of strings so that we can switch more
easily to Unicode later.)

> To me, this still feels like grubbing around in internals and I do wish
> you all were willing to supply something that approximates it.
> I loathe having this in my code:

Ugh, the ports API is still this ugly...


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Marius Vollmer]

Ken Raeburn <raeburn@raeburn.org> writes:

> E.g., declare a function SCM_LENGTH, which is declared in the header
> file with a macro which under recent enough versions of GCC expands to
> __attribute__((deprecated)) and on Windows to __declspec(deprecated),
> and in the source file defining the routine, on systems with the right
> compiler and assembler support, create a .gnu.warning.SCM_LENGTH (or
> .gnu.warning._SCM_LENGTH) section containing a message telling the
> user that the function will go away in a future release.  (As I
> understand it, on Windows you can even deprecate a macro by name.)

That would be a great addition to the existing deprecation system.
Right now spit out warnings when a feature such as SCM_LENGTH is used
for the first time, but warning at compile time is nice as well.

Would you like to work on this?  (I.e., on the needed infrastructure
and on the deprecated features themselves?)

> (I *think* I've got all my papers in order, but I don't know for
> sure if I've got papers in from my current employer, MIT, to cover
> Guile.  I haven't done the GNU maintainer bit in a while, could
> someone remind me where the list is?  Or check it for me?)

The list is on fencepost: /gd/gnuorg/copyright.list.  The FSF has your
papers for Guile, but no disclaimer from MIT, as far as I can see.
You can use /gd/gnuorg/Copyright/empdisclaim.future as a template or
ask <assign@gnu.org>.  I would be happy to help you with this, of
course.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Kevin Ryde]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> The recommended way in 1.6 is to use
> SCM_STRING_LENGTH, for example.  It _is_ annoying to have to switch
> away from SCM_STRING_LENGTH in 1.8 again,

Speaking of SCM_STRING_LENGTH, things like that which have been macros
in the past should remain as macros, not functions, even if all it
does is a function call.

Changing from macro to function for instance broke guile-gtk.  It was
#ifdef testing for SCM_STRING_LENGTH to know to use that (in 1.6), as
opposed to SCM_LENGTH (in whatever dim dark past).


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: SCM_LENGTH ???

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Speaking of SCM_STRING_LENGTH, things like that which have been macros
> in the past should remain as macros, not functions, even if all it
> does is a function call.
>
> Changing from macro to function for instance broke guile-gtk.  It was
> #ifdef testing for SCM_STRING_LENGTH to know to use that (in 1.6), as
> opposed to SCM_LENGTH (in whatever dim dark past).

Yes, you are right!  Thanks for reminding me, I will go thru all
deprecated things and make sure that macros stay macros.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

deprecated symbol warnings

[Ken Raeburn]

Some time back, I wrote:
> It might be a bit annoying to do in the source, but what about 
> flagging deprecated symbols while still allowing their use, in the 
> non-"--disable-deprecated" case?
>
> E.g., declare a function SCM_LENGTH, which is declared in the header 
> file with a macro which under recent enough versions of GCC expands to 
> __attribute__((deprecated)) and
[blah blah blah] and kind of volunteered myself to implement it.

Well, I've got a rough version up and limping, that does both 
compile-time and link-time warnings:

% make depr
gcc -I/var/raeburn/guile/guile-afs/Install/include -g   -c -o depr.o 
depr.c
depr.c: In function `main':
depr.c:6: warning: `SCM_ICDR' is deprecated (declared at 
/var/raeburn/guile/guile-afs/Install/include/libguile/deprecated.h:54)
gcc -o depr depr.o -L/var/raeburn/guile/guile-afs/Install/lib -lguile
depr.o(.text+0x15): In function `main':
/var/raeburn/guile/guile-afs/test/depr.c:6: SCM_ICDR is deprecated, 
please don't use it
%

(No warning is printed at run time.)

The warnings can be disabled while building guile (only while building 
deprecated.c, I hope) so that -Werror doesn't kill the build.

In the header files, here's how it's taking shape, roughly:

#if defined(SCM_DISABLE_DEPRECATION_WARNINGS)
# define SCM_DECL_DEPRECATED /* empty */
#elif __GNUC__ >= 3
# define SCM_DECL_DEPRECATED __attribute__((deprecated))
#elif defined _WIN32
/* TBD: How many old versions of the compiler support this?
    Will older ones complain, or ignore it?  */
# define SCM_DECL_DEPRECATED __declspec(deprecated) /* UNTESTED */
#else
# define SCM_DECL_DEPRECATED /* empty, no compile-time warnings */
#endif


/* N.B.: Application code will sometimes test whether one of these
    macros is defined, to figure out if the version of Guile in use
    predates the creation of the macro.  So at deprecation time, we
    still want the macro to be visible.  ANSI C says "#define foo foo"
    is okay, but if we get complaints about it, try switching the
    non-macro name to "foo_" or "foo_deprecated" or something; make it
    a simple concatenation so that we can make the other macros
    continue to be simple.  */

/* From eval.h: Macros for handling ilocs.  These were deprecated in 
guile
  * 1.7.0 on 2004-04-22.  */
extern SCM_DECL_DEPRECATED scm_t_bits SCM_IFRINC;
extern SCM_DECL_DEPRECATED scm_t_bits SCM_ICDR;
#define SCM_IFRINC		SCM_IFRINC
#define SCM_ICDR		SCM_ICDR

extern SCM_DECL_DEPRECATED long SCM_IFRAME(SCM n);
#define SCM_IFRAME		SCM_IFRAME


and in the source files:

#undef SCM_IFRINC
SCM_DEPRECATED (SCM_IFRINC);
scm_t_bits SCM_IFRINC = (0x00000100L);
#undef SCM_ICDR
SCM_DEPRECATED (SCM_ICDR);
scm_t_bits SCM_ICDR = (0x00080000L);

#undef SCM_IFRAME
SCM_DEPRECATED (SCM_IFRAME);
long SCM_IFRAME(SCM n)
{
   return ((long)((SCM_ICDR-SCM_IFRINC)>>8)
	  & (SCM_UNPACK (n) >> 8));
}


The link-time warnings are a bit messier.  So far, I'm working with a 
macro SCM_DEPRECATED(SYMBOLNAME) that gets used at the top level 
(outside of any functions), and on systems that support it -- that 
configure test isn't written yet, so basically it's x86-linux 
configurations -- it spits out a string into section 
.gnu.warning.SYMBOLNAME that the GNU linker will use if SYMBOLNAME is 
referenced.  It's a const char array with a synthesized name based on 
the symbol name, so if the symbol in question is a function, it'll be 
easy for the function to use that symbol in a call to 
scm_c_issue_deprecation_warning (though I don't know if I need to worry 
about i18n interactions there).  I'm actually working on a couple 
different forms, one which always causes the message to be available to 
the code, and one which only outputs the message if separate sections 
are supported; the latter would be for the case where the code doesn't 
explicitly use the message, and we'd be wasting space on a platform 
that doesn't support warning sections.

There's also another form of the macro which allows the message to be 
specified separately, so the programmer can be told which other 
functions should be used instead.

(I'm in the process of reworking some of these macros, so I don't have 
a good code sample right now.)

On Windows, actually, I'm told there are pragmas which can produce 
deprecation warnings for uses of macros, without having to mess around 
with turning them into variables.  But this scheme I'm using above 
ought to work on both GNU and Windows compilers, and is less messy than 
trying to handle each separately.  (Note that I haven't tested the 
Windows version yet.)

Comments, before I take this too much further?

Ken


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Neil Jerram]

Ken Raeburn wrote:
> 
> Well, I've got a rough version up and limping, that does both 
> compile-time and link-time warnings:

This looks very useful.  I'm not an expert in this kind of thing, but 
here are some comments.

> % make depr
> gcc -I/var/raeburn/guile/guile-afs/Install/include -g   -c -o depr.o 
> depr.c
> depr.c: In function `main':
> depr.c:6: warning: `SCM_ICDR' is deprecated (declared at 
> /var/raeburn/guile/guile-afs/Install/include/libguile/deprecated.h:54)
> gcc -o depr depr.o -L/var/raeburn/guile/guile-afs/Install/lib -lguile
> depr.o(.text+0x15): In function `main':
> /var/raeburn/guile/guile-afs/test/depr.c:6: SCM_ICDR is deprecated, 
> please don't use it

Nice output.

> (No warning is printed at run time.)

Yes, that makes sense.

> The warnings can be disabled while building guile (only while building 
> deprecated.c, I hope) so that -Werror doesn't kill the build.
> 
> In the header files, here's how it's taking shape, roughly:
> 
> #if defined(SCM_DISABLE_DEPRECATION_WARNINGS)
> # define SCM_DECL_DEPRECATED /* empty */
> #elif __GNUC__ >= 3
> # define SCM_DECL_DEPRECATED __attribute__((deprecated))
> #elif defined _WIN32

Does the __declspec syntax work for all Windows compilers?  If it's 
actually specific to MSVC (which is the only compiler I'm familiar 
with), you should use _MSC_VER.  If it's for all Windows compilers, I'm 
surprised by the underscore - i.e. I'd normally use WIN32; are WIN32 and 
_WIN32 equivalent?

> /* TBD: How many old versions of the compiler support this?
>     Will older ones complain, or ignore it?  */
> # define SCM_DECL_DEPRECATED __declspec(deprecated) /* UNTESTED */
> #else
> # define SCM_DECL_DEPRECATED /* empty, no compile-time warnings */
> #endif
> 
> 
> /* N.B.: Application code will sometimes test whether one of these
>     macros is defined, to figure out if the version of Guile in use
>     predates the creation of the macro.  So at deprecation time, we
>     still want the macro to be visible.  ANSI C says "#define foo foo"
>     is okay, but if we get complaints about it, try switching the
>     non-macro name to "foo_" or "foo_deprecated" or something; make it
>     a simple concatenation so that we can make the other macros
>     continue to be simple.  */

I think we should assume in advance that we'll hit trouble with this on 
some platforms.  Otherwise it's just another hiccup to push people away 
from trying Guile out.

> 
> /* From eval.h: Macros for handling ilocs.  These were deprecated in 
> guile
>   * 1.7.0 on 2004-04-22.  */
> extern SCM_DECL_DEPRECATED scm_t_bits SCM_IFRINC;
> extern SCM_DECL_DEPRECATED scm_t_bits SCM_ICDR;
> #define SCM_IFRINC		SCM_IFRINC
> #define SCM_ICDR		SCM_ICDR
> 
> extern SCM_DECL_DEPRECATED long SCM_IFRAME(SCM n);
> #define SCM_IFRAME		SCM_IFRAME

Nice.  Slight extra overhead, but well worth it IMO for the extra function.

> The link-time warnings are a bit messier.

What is the extra benefit of link-time warnings over compile-time?  Are 
there any cases where the user will see a link-time warning without a 
corresponding compile-time one?  Would link-time warnings show up when 
linking against a 3rd party library that chose to use deprecated symbols?

> scm_c_issue_deprecation_warning (though I don't know if I need to worry 
> about i18n interactions there).

I don't believe it's yet been suggested that we would translate the 
Scheme names of primitives, so I doubt there would be a problem here. 
(Out of interest, do any other scripting languages do this?)

Regards,
	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Ken Raeburn]

On May 14, 2005, at 08:40, Neil Jerram wrote:
> This looks very useful.  I'm not an expert in this kind of thing, but 
> here are some comments.

Thanks...

>> #elif defined _WIN32
>
> Does the __declspec syntax work for all Windows compilers?  If it's 
> actually specific to MSVC (which is the only compiler I'm familiar 
> with), you should use _MSC_VER.  If it's for all Windows compilers, 
> I'm surprised by the underscore - i.e. I'd normally use WIN32; are 
> WIN32 and _WIN32 equivalent?

I have no idea.  I do a small amount of work with MSVC, and the other 
compiler I'd be concerned about would be GCC, which is checked for 
first (though, actually, only for gcc 3 and later, should fix that); I 
have no idea what other Windows compilers would do, though I would 
expect for maximum interoperability they would implement or at least 
ignore the __declspec annotations.  In the code I deal with at work, we 
generally check _WIN32.

I'm hoping some Windows developer can help out here... we've got some 
at work, maybe I can ping them about it.

>> /* N.B.: Application code will sometimes test whether one of these
>>     macros is defined, to figure out if the version of Guile in use
>>     predates the creation of the macro.  So at deprecation time, we
>>     still want the macro to be visible.  ANSI C says "#define foo foo"
>>     is okay, but if we get complaints about it, try switching the
>>     non-macro name to "foo_" or "foo_deprecated" or something; make it
>>     a simple concatenation so that we can make the other macros
>>     continue to be simple.  */
>
> I think we should assume in advance that we'll hit trouble with this 
> on some platforms.  Otherwise it's just another hiccup to push people 
> away from trying Guile out.

*sigh*  I was afraid of that.  So when do we start requiring "real" 
ANSI C support? :-(

Doing this means the compile-time messages will give the wrong symbol 
names.  They'll be close to the names used by the application, but not 
the same.  Still, getting messages that are close is probably better 
than explaining to people why this strange use of the preprocessor is 
actually valid and it's their compiler that's broken.  I wonder if it's 
really a problem these days, though, a decade and a half after the spec 
was published....

> Nice.  Slight extra overhead, but well worth it IMO for the extra 
> function.

Yeah, consuming a bit more space in the library is slightly annoying, 
but the run-time performance for deprecated functions probably isn't 
anything to worry about.

>> The link-time warnings are a bit messier.
>
> What is the extra benefit of link-time warnings over compile-time?  
> Are there any cases where the user will see a link-time warning 
> without a corresponding compile-time one?

If the application refers to Guile functions without including 
libguile.h, yes.

Or if an older version of gcc is used that can generate ELF sections 
but doesn't support the "deprecated" attribute.  (I *think* "section" 
came first.)

Or if we add support for another compiler that lets us use 'asm' to 
emit warning sections or symbols or whatever the tool chain supports, 
but doesn't have a compile-time equivalent to the "deprecated" 
attribute, but we could treat that case separately.

Or...

>   Would link-time warnings show up when linking against a 3rd party 
> library that chose to use deprecated symbols?

Yes.  Hmm, at least for a static library.  I'm not sure about a shared 
library, if it would happen when the library was built, or used, or 
both.  I would assume they would be printed when the library is built, 
at least.  I'm guessing that this would probably be the most 
interesting of the cases.

Or, in the real world, if all the non-fatal compile-time warnings have 
all scrolled off the screen and the trailing bits of the "make" output 
still visible, and the only bits likely to get looked at unless 
something breaks, include only the final link step.


If it's not that interesting after all, I could drop it (as I 
indicated, it's the more complicated approach, though not terribly so) 
and just go with the compile-time warnings based on the predefined 
macros.  Turning macros into variables and/or functions is needed even 
without link-time warnings, as GCC can't attach attributes to the 
macros, only to the variable and function symbols, so it doesn't 
simplify things all that much.

>> scm_c_issue_deprecation_warning (though I don't know if I need to 
>> worry about i18n interactions there).
>
> I don't believe it's yet been suggested that we would translate the 
> Scheme names of primitives, so I doubt there would be a problem here. 
> (Out of interest, do any other scripting languages do this?)

I was thinking of the "is deprecated, please use" part.  The symbol 
names we should display as they are, but possibly the recommendation to 
change the application code should be given in Swahili or Klingon or 
whatever.  That we could do at run time, and gcc could do it at compile 
time, but I don't think we can do anything about it at link time.

Ken


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[John W. Eaton]

On 14-May-2005, Ken Raeburn wrote:

| >> /* N.B.: Application code will sometimes test whether one of these
| >>     macros is defined, to figure out if the version of Guile in use
| >>     predates the creation of the macro.  So at deprecation time, we
| >>     still want the macro to be visible.  ANSI C says "#define foo foo"
| >>     is okay, but if we get complaints about it, try switching the
| >>     non-macro name to "foo_" or "foo_deprecated" or something; make it
| >>     a simple concatenation so that we can make the other macros
| >>     continue to be simple.  */
| >
| > I think we should assume in advance that we'll hit trouble with this 
| > on some platforms.  Otherwise it's just another hiccup to push people 
| > away from trying Guile out.
| 
| *sigh*  I was afraid of that.  So when do we start requiring "real" 
| ANSI C support? :-(

Can you point to a widely used compiler that will actually have
trouble with this?  If not, then maybe it is not worth worrying about?

| Doing this means the compile-time messages will give the wrong symbol 
| names.  They'll be close to the names used by the application, but not 
| the same.  Still, getting messages that are close is probably better 
| than explaining to people why this strange use of the preprocessor is 
| actually valid and it's their compiler that's broken.  I wonder if it's 
| really a problem these days, though, a decade and a half after the spec 
| was published....

Having the messages use the wrong names might cause a lot more
confusion than having to explain to people that their compiler is
broken.

jwe

-- 
jwe at octave dot org | Peace would shock and awe me.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Neil Jerram]

John W. Eaton wrote:
> On 14-May-2005, Ken Raeburn wrote:
> 
> | > I think we should assume in advance that we'll hit trouble with this 
> | > on some platforms.  Otherwise it's just another hiccup to push people 
> | > away from trying Guile out.
> | 
> | *sigh*  I was afraid of that.  So when do we start requiring "real" 
> | ANSI C support? :-(
> 
> Can you point to a widely used compiler that will actually have
> trouble with this?  If not, then maybe it is not worth worrying about?

No I can't.  But I know that we intermittently get unexpected build 
errors reported on the mailing list for even fairly mainstream OSs such 
as Solaris and HP-UX, and recently OS X, so I was just advising caution 
in order to avoid introducing a possible roadhump for people off the 
GNU/Linux/gcc mainline.  Also, in my own experience (which is 
reasonable) I've never seen "#define foo foo" used before, so I have no 
personal feel for how well supported it is.  (And you have to agree that 
it is an edge case, surely?)

However ... when advising as above, I hadn't realized that the reported 
names would be wrong.  Now that I realize that, I think it is worth 
using "#define foo foo" and handling any problems if they arise.  (We 
have future options, if we need them, for using configure tests to test 
support, and adding a suffix where necessary.)

> 
> | Doing this means the compile-time messages will give the wrong symbol 
> | names.  They'll be close to the names used by the application, but not 
> | the same.  Still, getting messages that are close is probably better 
> | than explaining to people why this strange use of the preprocessor is 
> | actually valid and it's their compiler that's broken.  I wonder if it's 
> | really a problem these days, though, a decade and a half after the spec 
> | was published....
> 
> Having the messages use the wrong names might cause a lot more
> confusion than having to explain to people that their compiler is
> broken.

Yes, agreed now.

	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Ken Raeburn]

On May 14, 2005, at 23:17, John W. Eaton wrote:
[..."#define foo foo"...]
> Can you point to a widely used compiler that will actually have
> trouble with this?  If not, then maybe it is not worth worrying about?

Hmm... does anyone feel like setting up an array of test machines to 
automatically do frequent builds and tests of snapshots and report 
errors as they come up?

I've done something like this a couple of times (for binutils, while I 
was maintaining it at Cygnus, and more recently for Kerberos at MIT), 
but it's always involved machines I had privileges on; something more 
distributed that lots of us could contribute cycles to without having 
to grant each other login access or anything like that would be better 
for Guile, but a bit harder to design and implement, at least if you're 
security-conscious.  (And in fact some trouble we've had recently with 
Kerberos has been to do with platforms *not* represented in our local 
test setup.)

With something like this in place, we could simply implement schemes 
like this, and get feedback relatively quickly on how it's handled on 
lots of platforms that any contributors care about, rather than waiting 
and hoping somebody has tested platforms X, Y, and Z before the release 
goes out.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[tomas]

[-- Attachment #1.1: Type: text/plain, Size: 735 bytes --]

On Mon, May 16, 2005 at 01:52:01AM -0400, Ken Raeburn wrote:
> On May 14, 2005, at 23:17, John W. Eaton wrote:
> [..."#define foo foo"...]
> >Can you point to a widely used compiler that will actually have
> >trouble with this? [...]
> 
> Hmm... does anyone feel like setting up an array of test machines to 
> automatically do frequent builds and tests of snapshots and report 
> errors as they come up?

FWIW, SourceForge makes such a testing farm available. See, for example

  <http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1>

Not that I have any experience with it, but it strikes me as a good idea
to have such a thing as common infrastructure for free software projects.

Regards
-- tomás

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Ludovic Courtès]

Hello,

Ken Raeburn <raeburn@raeburn.org> writes:

> Hmm... does anyone feel like setting up an array of test machines to
> automatically do frequent builds and tests of snapshots and report
> errors as they come up?

This sounds like a good idea.  However, this would need to be somewhat
automated, like Debian's build system, still without compromising on the
user's privacy and control.  I think that's a project of its own, isn't
it?  :-)

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

automated testing (was Re: deprecated symbol warnings)

[Ken Raeburn]

On May 18, 2005, at 08:20, Ludovic Courtès wrote:
> This sounds like a good idea.  However, this would need to be somewhat
> automated, like Debian's build system, still without compromising on 
> the
> user's privacy and control.  I think that's a project of its own, isn't
> it?  :-)

Definitely.

FWIW, I use a separate, dedicated account for this sort of thing at 
work.  (Not enough cycles to add Guile builds on many of these 
machines.  But maybe a couple.)  That still essentially means you've 
giving random developers access to your machine, if somewhat 
indirectly, so unless you trust them all, you probably still want to be 
somewhat careful.  There are various OS-specific approaches to 
confining a collection of processes in different ways, but of course 
part of the goal is to do testing across a variety of platforms as well 
as different configurations of certain popular platforms.  Using chroot 
only gets you so far, but UML or VMware won't tell you if you've got 
problems on Alphas running Tru64.  So I suspect a variety of approaches 
would be needed -- depending in part on how concerned the system owner 
is about access to random data on their system.

In fact, at the end of the day, I think maybe the test-running and 
result-collecting and -reporting might be one interesting project, and 
the build isolation probably several other interesting projects or 
products (UML, Bochs, Plex, SIMH, PearPC, VMware, Mac On Linux, FreeBSD 
jails, Solaris 10's ... um ... whatever they called it).  There are 
plenty of people working on the latter set.  Anyone want to put 
together the former?

And if a potential tester doesn't have much stuff that a Guile build 
absolutely has to be kept away from, or they've just got a reasonable 
amount of trust in the other Guile developers, they could use the 
dedicated-account approach and a cron job, and not worry about it....

Ken

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings and Windows

[Ken Raeburn]

On May 14, 2005, at 08:40, Neil Jerram wrote:
>> The warnings can be disabled while building guile (only while 
>> building deprecated.c, I hope) so that -Werror doesn't kill the 
>> build.
>> In the header files, here's how it's taking shape, roughly:
>> #if defined(SCM_DISABLE_DEPRECATION_WARNINGS)
>> # define SCM_DECL_DEPRECATED /* empty */
>> #elif __GNUC__ >= 3
>> # define SCM_DECL_DEPRECATED __attribute__((deprecated))
>> #elif defined _WIN32
>
> Does the __declspec syntax work for all Windows compilers?  If it's 
> actually specific to MSVC (which is the only compiler I'm familiar 
> with), you should use _MSC_VER.  If it's for all Windows compilers, 
> I'm surprised by the underscore - i.e. I'd normally use WIN32; are 
> WIN32 and _WIN32 equivalent?

I've done a bit more investigating, and it appears that 
__declspec(deprecated) is new with Visual Studio 2003, or maybe 2002.  
So there would be no warning with older compilers, probably.  (And the 
older compiler we've been using at work defines _WIN32 but not WIN32.)  
For now, in my code, I'm testing _MSC_VER >= 1310.

In looking at the current headers, I think when I'm changing macros 
into functions, I need to stick "SCM_API" in front where I'd use 
"extern" normally, to get the Windows DLL import/export specs right?  
So this conversion will actually be adding to the exported-symbol list 
of the DLL.  (Has anyone thought about limiting exported symbols on 
UNIX?)  I've just gotten access to the newer compilers, so I should be 
able to run some tests any make sure I've gotten the syntax right for 
multiple declspecs etc.

Oh, and based on the discussions, I'm sticking with the "#define foo 
foo" form for now, rather than renaming symbols.

Ken


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Neil Jerram]

Ken Raeburn wrote:
> On May 14, 2005, at 08:40, Neil Jerram wrote:
> 
>>What is the extra benefit of link-time warnings over compile-time?  
>>Are there any cases where the user will see a link-time warning 
>>without a corresponding compile-time one?
> 
> 
> If the application refers to Guile functions without including 
> libguile.h, yes.
> 
> Or if an older version of gcc is used that can generate ELF sections 
> but doesn't support the "deprecated" attribute.  (I *think* "section" 
> came first.)
> 
> Or if we add support for another compiler that lets us use 'asm' to 
> emit warning sections or symbols or whatever the tool chain supports, 
> but doesn't have a compile-time equivalent to the "deprecated" 
> attribute, but we could treat that case separately.
> 
> Or...

All of which strike me as pretty marginal.

> 
> 
>>  Would link-time warnings show up when linking against a 3rd party 
>>library that chose to use deprecated symbols?
> 
> 
> Yes.  Hmm, at least for a static library.  I'm not sure about a shared 
> library, if it would happen when the library was built, or used, or 
> both.  I would assume they would be printed when the library is built, 
> at least.  I'm guessing that this would probably be the most 
> interesting of the cases.

Interesting in a sense, yes - but I was thinking that this is a good 
argument for NOT implementing link-time warnings.  The point being that 
in this case the developer can't do anything about the warnings, so 
they're just an annoyance.

> 
> Or, in the real world, if all the non-fatal compile-time warnings have 
> all scrolled off the screen and the trailing bits of the "make" output 
> still visible, and the only bits likely to get looked at unless 
> something breaks, include only the final link step.

Seriously?  (In my real world, if people are concerned about warnings 
they put processes in place so as not to miss them.)

> 
> 
> If it's not that interesting after all, I could drop it (as I 
> indicated, it's the more complicated approach, though not terribly so) 
> and just go with the compile-time warnings based on the predefined 
> macros.

That would be my inclination.

>>>scm_c_issue_deprecation_warning (though I don't know if I need to 
>>>worry about i18n interactions there).
>>
>>I don't believe it's yet been suggested that we would translate the 
>>Scheme names of primitives, so I doubt there would be a problem here. 
>>(Out of interest, do any other scripting languages do this?)
> 
> 
> I was thinking of the "is deprecated, please use" part.  The symbol 
> names we should display as they are, but possibly the recommendation to 
> change the application code should be given in Swahili or Klingon or 
> whatever.  That we could do at run time, and gcc could do it at compile 
> time, but I don't think we can do anything about it at link time.

I see - thanks for explaining.

Regards,
	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: deprecated symbol warnings

[Ken Raeburn]

On May 26, 2005, at 14:58, Neil Jerram wrote:
>>> What is the extra benefit of link-time warnings over compile-time?  
>>> Are there any cases where the user will see a link-time warning 
>>> without a corresponding compile-time one?
[...]

> All of which strike me as pretty marginal.

Okay...

>>>  Would link-time warnings show up when linking against a 3rd party 
>>> library that chose to use deprecated symbols?
>> Yes.  Hmm, at least for a static library.  I'm not sure about a 
>> shared library, if it would happen when the library was built, or 
>> used, or both.  I would assume they would be printed when the library 
>> is built, at least.  I'm guessing that this would probably be the 
>> most interesting of the cases.
>
> Interesting in a sense, yes - but I was thinking that this is a good 
> argument for NOT implementing link-time warnings.  The point being 
> that in this case the developer can't do anything about the warnings, 
> so they're just an annoyance.

Good point.

If these were security-related warnings, I'd suggest that they should 
be displayed anyways, to make the end user/developer aware that they're 
using software that could potentially compromise their systems.  But 
for deprecated symbols, all one could do would be to complain at the 
third party supplying the library.

>> Or, in the real world, if all the non-fatal compile-time warnings 
>> have all scrolled off the screen and the trailing bits of the "make" 
>> output still visible, and the only bits likely to get looked at 
>> unless something breaks, include only the final link step.
>
> Seriously?  (In my real world, if people are concerned about warnings 
> they put processes in place so as not to miss them.)

Well, I haven't looked over people's shoulders much while they build 
software, but enough software has warnings while building that I expect 
that's not the normal process for a lot of people.  But if an 
"interesting" warning (i.e., not the 
pointer-assignment-changes-signedness or cast-changes-alignment or 
other relatively benign warnings they may be in the habit of ignoring) 
is still on-screen when the build finishes, maybe they'll take note.

Also, in some packages, link time is when arbitrary developer-provided 
warnings get displayed now, if only because compile-time support hasn't 
been there.

Hmm... come to think of it, though, we're increasingly working in a 
world where building software package X requires that you have software 
package Y installed, and software package Y may be built via some 
provided package system that routinely ignores warnings as it builds 
and installs some large collection of packages based on some dependency 
tree.  That might be a case where someone hacking on package X might 
like to know that package Y does have some issues, and they might be 
able to do something about it, but they wouldn't normally go looking 
for problems there.

>> If it's not that interesting after all, I could drop it (as I 
>> indicated, it's the more complicated approach, though not terribly 
>> so) and just go with the compile-time warnings based on the 
>> predefined macros.
>
> That would be my inclination.

Okay.  Unless someone else wants the link-time warnings, I'll start 
backing that part out of my source tree soon.  They're pretty 
independent, so it wouldn't be hard to put them back in later as a 
separate bit of work.

Ken

P.S.  Apparently I've got updated assignment forms I need to file -- 
the FSF has already sent them to me -- and I probably need to get the 
current disclaimer form to my current employer.  So it'll take a little 
while yet before the patches can go in.  But I'll try and send 
something for review soon anyways.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user