snarfer guard macro name decision: SCM_MAGIC_SNARFER

snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

this was used in 1.4.

libguile-1.6 .c source uses it as #ifndef, however both snarf.h and
guile-snarf have been in the meantime changed to not define this.

1.6 snarfing differs from 1.4 primarily in that there are now two kinds:
init and doc, as opposed to merely init.  in defining the names of the
specialization-trigger macros, we now remember usage of this old friend
(i.e., also as guard).

in the end, it is better to migrate self-guard naming internally, and
include that info in the data stream only (snarfing programs generate
program fragments opaque to all re-snarfing).

so, this is sort of a good-bye from public view for SCM_MAGIC_SNARFER
the cpp macro.  [band plays.]

anyone know what are the official namespaces allowed for programs that
munge the cpp macro space?  [macro looks up, wisened and ready for the
inevitable coup.  it is prepared to don a blade, but it has been heard
that the really crafty old dictators (the ones who stayed alive) mingled
and mewed and were the only ones allowed to slit their own throats.]

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Tue, 12 Mar 2002 23:51:38 -0800

   in the end, it is better to migrate self-guard naming internally, and
   include that info in the data stream only (snarfing programs generate
   program fragments opaque to all re-snarfing).

unfortunately, this is not completely realizable w/o reducing
functionality.  when invoked w/ known output file:

  guile-snarf -o foo.x foo.c		# ("-o OUTFILE" is new)

snarfing can recognize #include "foo.x" and such, filtering them from
the input, but this cannot be supported when writing to stdout (unknown
output file).

so SCM_MAGIC_SNARFER rules forever!  [the Author is now duly shot. x-p]

on the other hand...

when output is written to stdout, caller typically must check return
value and delete the already written but bogus file, if the return value
is false.  this is all handled by guile-snarf -o, so why ask for this
pain?  to be precise (old vs new):

  guile-snarf $(snarfcppopts) $< > $@ || { rm $@; false; }
  guile-snarf -o $@ $(snarfcppopts) $<

this point is already conceded by the comments in guile-snarf re temp
file usage, the question is: is it ok to not support writing to stdout?

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Thien-Thi Nguyen <ttn@giblet.glug.org>
>    Date: Tue, 12 Mar 2002 23:51:38 -0800
> 
>    in the end, it is better to migrate self-guard naming internally, and
>    include that info in the data stream only (snarfing programs generate
>    program fragments opaque to all re-snarfing).
> 
> unfortunately, this is not completely realizable w/o reducing
> functionality.

The basic problem is that during snarfing, the generated *.x file does
not get created soon enough so that it can be included while scanning
the original source, right?

Would it work to just make sure that the file exists (possibly empty
or with a comment in it) when cpp is run?

I.e, just move the last "echo" in guile-snarf before the CPP
invocation.

> when output is written to stdout, caller typically must check return
> value and delete the already written but bogus file, if the return value
> is false.  this is all handled by guile-snarf -o, so why ask for this
> pain?  to be precise (old vs new):
> 
>   guile-snarf $(snarfcppopts) $< > $@ || { rm $@; false; }
>   guile-snarf -o $@ $(snarfcppopts) $<
> 
> this point is already conceded by the comments in guile-snarf re temp
> file usage, the question is: is it ok to not support writing to stdout?

When it is easy to do (and I think it is), we should support writing
to stdout.  Offering the "-o" option is a very good thing, and we
should encourage people to use it, of course.

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 13 Mar 2002 20:15:48 +0100

   The basic problem is that during snarfing, the generated *.x file does
   not get created soon enough so that it can be included while scanning
   the original source, right?

yes.  (but this is only one issue.)

   Would it work to just make sure that the file exists (possibly empty
   or with a comment in it) when cpp is run?

yes, but only if you know the name of the output file.

   I.e, just move the last "echo" in guile-snarf before the CPP
   invocation.

this is not guaranteed to work; when invoked w/ "foo > out.x", the shell
does indeed create out.x first, satisfying most CPPs' requirements for
out.x existing to be #included.  however, it looks like the aix cpp
needs this file to be non-empty, which cannot be done when executing
echo and cpp (in any sequence) under the process "guile-snarf" since the
shell may buffer subprocess output.

you can require the makefile to "echo > foo.x" before invoking
guile-snarf, as another workaround, but all these workarounds (including
the "|| { rm $@; false; }" cruft) indicate to me that guile-snarf usage
should be at a higher abstraction...

   When it is easy to do (and I think it is), we should support writing
   to stdout.

it is easy to do but not easy to use.  i've come to think guile-snarf
usage is in the same vein as gcc wrt output files -- if things go wrong,
you want the program to handle things rather than having to clean up
after it, manually.  you don't see makefiles with rules like:

   gcc -c $< > $@ || { rm $@; false; }

(although maybe secretly everyone wishes this were the case?!)  doc
snarfing, on the other hand, practically begs further processing, so
writing to stdout for that process is much more desirable.  we'll get to
that sooner or later...

see below for commentary (not yet checked in -- testing continues) for
guile-snarf.

thi


______________________________________
# Usage: guile-snarf [--compat=1.4] [-o OUTFILE] INFILE [CPP-OPTIONS ...]
#
# Process INFILE using the C pre-processor and some other programs.
# Write output to a file, named OUTFILE if specified, or STEM.x if
# INFILE looks like STEM.c, and no OUTFILE is specified.  Ignore
# lines from the input matching grep(1) regular expression:
#
#       ^#include ".*OUTFILE"
#
# If there are errors during processing, OUTFILE is not written
# and guile-snarf returns non-zero.
#
# Optional arg "--compat=1.4" means emulate guile-1.4 guile-snarf.
# This option is not fully tested -- see Guile reference manual.
#
# If env var CPP is set, use that value instead of the C pre-processor
# determined at guile configure-time: "@CPP@".

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> see below for commentary (not yet checked in -- testing continues)
> for guile-snarf.

Is there any easy way I can get back the 1.5 functionality of a few
months ago (i.e. is your stuff in a good enough state to check in for
even light use, or is there perhaps some temporary hack I can use for
right now?)

I ask because I'm suddenly in a situation where need to use 1.5 with
gnome-guile again, and I'd prefer to use the current source rather
than checking out an older 1.5 -- I'm not positive, but I think
gnome-guile worked with 1.5 as of a month or two ago...

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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Wed, 13 Mar 2002 16:00:33 -0600

   Is there any easy way I can get back the 1.5 functionality of a few
   months ago (i.e. is your stuff in a good enough state to check in for
   even light use, or is there perhaps some temporary hack I can use for
   right now?)

   I ask because I'm suddenly in a situation where need to use 1.5 with
   gnome-guile again, and I'd prefer to use the current source rather
   than checking out an older 1.5 -- I'm not positive, but I think
   gnome-guile worked with 1.5 as of a month or two ago...

see below for guile-snarf.in snapshot.  feedback welcome!

to play, modify Makefile.am to look like:

  snarfcppopts = $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)

  .c.x:
	./guile-snarf --compat=1.4 $< $(snarfcppopts)

(this is what i've done locally, except w/o the "--compat=1.4" for HEAD
and branch_release-1-6.  WARNING: the old_school_snarf is incomplete.)

thi

____________________________________
#!/bin/sh
# Extract the initialization actions for builtin things.
#
#  Copyright (C) 1996, 97, 98, 99, 2000, 2001, 2002 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
# Boston, MA 02111-1307 USA

# Commentary:

# Usage: guile-snarf [--compat=1.4] [-o OUTFILE] INFILE [CPP-OPTIONS ...]
#
# Process INFILE using the C pre-processor and some other programs.
# Write output to a file, named OUTFILE if specified, or STEM.x if
# INFILE looks like STEM.c and no OUTFILE is specified.  Ignore
# lines from the input matching grep(1) regular expression:
#
#       ^#include ".*OUTFILE"
#
# If there are errors during processing, delete OUTFILE and exit with
# non-zero status.
#
# Optional arg "--compat=1.4" means emulate guile-1.4 guile-snarf.
# This option is not fully tested -- see Guile reference manual.
#
# If env var CPP is set, use its value instead of the C pre-processor
# determined at Guile configure-time: "@CPP@".

# Code:

[ x$DEBUG = x1 ] && set -x

old_school_snarf ()
{
$cpp -DSCM_MAGIC_SNARFER "$@" > ${temp} && cpp_status=true
grep "^ *SCM__I" ${temp} | sed -e "s/^ *SCM__I//" -e 's/SCM__D.*$//g'
# TODO TODO TODO: here we need to handle changes like:
#                 scm_make_gsubr -> scm_c_define_gsubr
#                 (probably sed is ok)
}

modern_snarf ()
{
$cpp -DSCM_MAGIC_SNARF_INITS "$@" > ${temp} && cpp_status=true
grep "^ *\^ *\^" ${temp} | sed -e "s/^ *\^ *\^//"
}

## main

# process command line
if [ x"$1" = x--help ] ; then
    @AWK@ '/^#.Commentary:/,/^#.Code:/' $0 | grep -v Code: \
        | sed -e 1,2d -e 's/^. *//g'
    exit 0
fi
if [ x"$1" = x--compat=1.4 ]
    then snarf=old_school_snarf ; shift
    else snarf=modern_snarf
fi
if [ x"$1" = x-o ]
    then outfile=$2 ; shift ; shift ; infile=$1 ; shift
    else infile=$1 ; shift ; outfile=`basename $infile .c`.x
fi

[ x"$infile" = x ] && { echo $0: No input file ; exit 1 ; }
[ ! -f "$infile" ] && { echo $0: No such file: $infile ; exit 1 ; }

# set vars and handler -- handle CPP override
cpp_status=false
temp="/tmp/snarf.$$"
if [ x"$CPP" = x ] ; then cpp="@CPP@" ; else cpp="$CPP" ; fi 
self_blind_regexp='^#include ".*'`basename $outfile`'"'
clean_infile=clean-`basename $infile`
trap "rm -f $temp $clean_infile" 0 1 2 15

# do the snarfing -- output something extra for needy cpp programs (AIX)
{ echo "/* source: $infile */" ;
  echo "/* cpp-options: $@ */" ;
  grep -v "$self_blind_regexp" $infile > $clean_infile ;
  $snarf "$@" $clean_infile ;
} > $outfile

# zonk outfile if errors occurred
if $cpp_status ; then
    exit 0
else
    rm -f $outfile
    exit 1
fi

# guile-snarf ends here



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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Wed, 13 Mar 2002 14:58:06 -0800

   WARNING: the old_school_snarf is incomplete.

ok, --compat=1.4 requirements is now clearer to me: when this is used,
the environment is all new (new snarf.h, new scm_c_define_gsubr, etc).
so really the compatibility is on the input (recognizing SCM_VCELL as
SCM_VARIABLE, for example), instead of on the output as implied by the
TODO comment in the guile-snarf.in post.

below is first usable stab for anyone who wants to try guile-snarf on
old code.  i'm taking a guess w/ SCM_CONST_LONG (feedback requested).
cut and paste as appropriate...

thi

______________________________________
## snarf funcs: $1 must be the input file and must be mutable (yuk!)

modern_snarf ()
{
${cpp} -DSCM_MAGIC_SNARF_INITS "$@" > ${temp} && cpp_status=true
grep "^ *\^ *\^" ${temp} | sed -e "s/^ *\^ *\^//"
}

old_school_snarf ()
{
sed -e 's/SCM_CONST_LONG/SCM_GLOBAL_VCELL_INIT/g' \
    -e 's/SCM_GLOBAL_VCELL_INIT/SCM_GLOBAL_VARIABLE_INIT/g' \
    -e 's/SCM_GLOBAL_VCELL/SCM_GLOBAL_VARIABLE/g' \
    -e 's/SCM_VCELL_INIT/SCM_VARIABLE_INIT/g' \
    -e 's/SCM_VCELL/SCM_VARIABLE/g' \
    $1 > ${temp}
cp ${temp} $1
modern_snarf "$@"
}

##### ---------8<-------------------
##### make sure snarf funcs' $1 is the input file:

-  $snarf "$@" $clean_infile ;
+  $snarf $clean_infile "$@" ;

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> below is first usable stab for anyone who wants to try guile-snarf on
> old code.  i'm taking a guess w/ SCM_CONST_LONG (feedback requested).
> cut and paste as appropriate...

Thanks.  I really appreciate your efforts here, though keep in mind
that (at least in my opinion), it's OK for us to require users to
modify their code to work with a newer, documented snarfer in the new
release of guile.  People are going to have to conditionalize things
either way, whether it's in the argument to guile-snarf, or in their
own code, and they're also going to have to accomodate all the other
API changes, so I'm not sure we need to spend too much time time
trying to emulate the old behavior.  Backward compatibility is good,
especially when there's a large community to consider, but I doubt
that's the case here, and maintaining two interfaces has it's own
attendant costs.

In any case, thanks again for trying to figure these bits out.

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Wed, 13 Mar 2002 14:58:06 -0800

   see below for guile-snarf.in snapshot.  feedback welcome!

everything is checked in now.  please feel free to read the new docs,
try the new guile-snarf, and complain loudly so weirdnesses can be fixed
(when the going gets weird, the weird turn pro)...

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> everything is checked in now.  please feel free to read the new docs,
> try the new guile-snarf, and complain loudly so weirdnesses can be fixed
> (when the going gets weird, the weird turn pro)...

Great.  I'll suspect I'll be your first customer :> I'll try
gnome-guile in the morning.

I got 1.4 working for the code I was having trouble with after
removing (read-enable 'positions) in the offending case, but this just
exposes a later failure, one I've seen before during 1.4's make check

  scm_must_realloc called with arg bignum, was gh_symbol2newstr

If I can get gnome-guile to work with 1.5 now, I'll try it and see if
it tells me anything more.

Thanks again.

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
>
>> everything is checked in now.  please feel free to read the new docs,
>> try the new guile-snarf, and complain loudly so weirdnesses can be fixed
>> (when the going gets weird, the weird turn pro)...
>
> Great.  I'll suspect I'll be your first customer :> I'll try
> gnome-guile in the morning.

Actually, I can't build guile 1.5 ATM.  I'll investigate tomorrow.

Making all in guile-readline
make[2]: Entering directory `/home/rlb/dev/guile/core-1.5/guile-readline'
../libguile/guile-snarf -DHAVE_DLFCN_H=1 -DHAVE_LIBREADLINE=1 -DHAVE_SIGINTERRUPT=1 -DHAVE_RL_CLEAR_SIGNALS=1 -DHAVE_RL_CLEANUP_AFTER_SIGNAL=1 -DHAVE_RL_FILENAME_COMPLETION_FUNCTION=1 -DHAVE_RL_PRE_INPUT_HOOK=1 -DGUILE_SIGWINCH_SA_RESTART_CLEARED=1 -DHAVE_RL_GETC_FUNCTION=1 -DHAVE_STRDUP=1  -I.. -I./..  -g -O2 readline.c > readline.x \
|| { rm readline.x; false; }
make[2]: *** [readline.x] Error 1
make[2]: Leaving directory `/home/rlb/dev/guile/core-1.5/guile-readline'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rlb/dev/guile/core-1.5'
make: *** [stamp/guile-build] Error 2

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Thu, 14 Mar 2002 01:17:22 -0600

   Actually, I can't build guile 1.5 ATM.  I'll investigate tomorrow.
   [guile-readline not updated]

thanks for the bug report.  guile-readline/Makefile.am updated.

here's a command:

find -name Makefile.am \
  -exec grep -l '^.c.x' '{}' \; \
  -exec grep -l snarfcppopts '{}' \;

that prints out all known good Makefile.am files (twice).
for me this results in:

./guile-readline/Makefile.am
./guile-readline/Makefile.am
./libguile/Makefile.am
./libguile/Makefile.am
./srfi/Makefile.am
./srfi/Makefile.am

now is as a good time as any to seed the thought that we can save a lot
of keypresses by moving identical machinery into am/.  actually this
thought was there at am/ creation but i didn't apply it fully.  a missed
opportunity (the first of many).

obviously between slavish restraint and inopportune opportunism lies
some happy balance.  the state of the world is that people who benefit
from artificial restrictions to cultural development (including code)
would have you believe those myths that make up the machine:
  freedom is slavery
  war is peace
  ignorance is strength
the last is the first to be easily proven in the minds of many, when the
many love themselves because they are many.

grinding hate and grinding love both turn the soul to dust.

guile development
no matter the weed intake
a refuge from dust

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> old_school_snarf ()
> {
> sed -e 's/SCM_CONST_LONG/SCM_GLOBAL_VCELL_INIT/g' \
>     -e 's/SCM_GLOBAL_VCELL_INIT/SCM_GLOBAL_VARIABLE_INIT/g' \
>     -e 's/SCM_GLOBAL_VCELL/SCM_GLOBAL_VARIABLE/g' \
>     -e 's/SCM_VCELL_INIT/SCM_VARIABLE_INIT/g' \
>     -e 's/SCM_VCELL/SCM_VARIABLE/g' \
>     $1 > ${temp}
> cp ${temp} $1
> modern_snarf "$@"
> }

Don't do this.  First, SCM_VCELL and SCM_VARIABLE are not the same
thing.  You can't substitute one for the other.  (Likewise for the
substitutions.)  Second, we already keep proper backward compatibility
in the C code itself:

    #if (SCM_DEBUG_DEPRECATED == 0)

    #define SCM_CONST_LONG(c_name, scheme_name,value) \
    SCM_VCELL_INIT(c_name, scheme_name, scm_long2num(value))

etc...

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    I.e, just move the last "echo" in guile-snarf before the CPP
>    invocation.
> 
> this is not guaranteed to work; when invoked w/ "foo > out.x", the shell
> does indeed create out.x first, satisfying most CPPs' requirements for
> out.x existing to be #included.

Sorry, I was confused.  I still am, for that matter.  How can it
happen that during

    guile-snarf foo.c >foo.x

the file foo.x does not exist?  It should get created by the shell
before guile-snarf is executed.

I remember seeing problems with non-existent *.x files way back then,
but I can't remember the details.  Looking at the code in guile-gtk,
it mighta just as well been an issue with the dependency computation
used by an old version of automake.

> however, it looks like the aix cpp needs this file to be non-empty,
> which cannot be done when executing echo and cpp (in any sequence)
> under the process "guile-snarf" since the shell may buffer
> subprocess output.

This is a specific problem on AIX, and the workaround need only work
on AIX, so we only need to worry about this when AIX does in fact
buffer echoes.  I would be surprised if it does...

>    When it is easy to do (and I think it is), we should support writing
>    to stdout.
> 
> it is easy to do but not easy to use.

Yes, but it is still easier not to change existing code that makes use
of the old behavior of guile-snarf.

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 14 Mar 2002 19:48:55 +0100

   Don't do this.  First, SCM_VCELL and SCM_VARIABLE are not the same
   thing.  You can't substitute one for the other.  (Likewise for the
   substitutions.)

oops my bad, i didn't understand the macros well enough.  what can you
use then, if you're interested in the long term?

   Second, we already keep proper backward compatibility in the C code
   itself:

       #if (SCM_DEBUG_DEPRECATED == 0)

       #define SCM_CONST_LONG(c_name, scheme_name,value) \
       SCM_VCELL_INIT(c_name, scheme_name, scm_long2num(value))

these are not available in HEAD branch, which is where i did the
original digging (thinking that perhaps snarfing macros are no longer in
flux, but now i see that's not the case).

they are indeed in branch_release-1-6.

so now i'm confused.  is each guile release going to change these names
to something else and yank some previous name?  why isn't SCM_VCELL in
HEAD branch snarf.h?  how do you propose to handle the situation where a
user has SCM_VCELL but would like to use guile-1.8?

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 14 Mar 2002 20:09:36 +0100

   > this is not guaranteed to work; when invoked w/ "foo > out.x", the shell
   > does indeed create out.x first, satisfying most CPPs' requirements for
   > out.x existing to be #included.

   Sorry, I was confused.  I still am, for that matter.  How can it
   happen that during

       guile-snarf foo.c >foo.x

   the file foo.x does not exist?  It should get created by the shell
   before guile-snarf is executed.

wrt when foo.x is created, we're saying the same thing.  (the "this is
not guaranteed to work" applies to the whole design -- where we need to
regard mere file availability as insufficient.)

   This is a specific problem on AIX, and the workaround need only work
   on AIX, so we only need to worry about this when AIX does in fact
   buffer echoes.  I would be surprised if it does...

the AIX problem is not that its shell buffers echo, but that its cpp
(reportedly) doesn't like to #include an empty .x file.  shells (of any
platform) buffering subprocess output could be regarded as a problem,
but is generally accepted (and desirable for obvious reasons), so we
need to re-examine our usage.

here's a simple program that tests the relevant behavior:

 #!/bin/sh
 echo hi
 cat zz

save to file z, chmod +x z, and invoke it like "z > zz".
what do you see?  on my system i see:

 cat: zz: input file is output file

and the program exits w/ non-zero status value.  substitute cat w/ some
other program that eventually needs to read zz, and it is no surprise if
that program fails.  thus, i conclude that in general this kind of usage
is the wrong way to go about things, not because cat failed, but because
this style forces us to know the intracacies of each program (e.g.,
"test -f" works, "test -s" works sometimes, etc), which is a PITA to
determine and maintain.  big lose.

we can special-case for AIX but that way lies madness.  the approach
i've taken is to look at the AIX problem as an additional constraint
that when satisfied should not burden other platforms.

   Yes, but it is still easier not to change existing code that makes use
   of the old behavior of guile-snarf.

here, the code that needs changing is primarily in makefiles, which are
not as big a pain to update as C source, there being fewer makefiles
than source files typically.

(if someone installs a new guile (and new guile-snarf), they need to
modify the makefile to enable some compatibility anyway.  in the process
if they don't take advantage of the less-crufty new usage and demand
"support" for making them do more work, rather than question their
dubious judgement (and unslackful ethics) i suppose my response would be
to say that guile-snarf was never documented in the first place, and be
done w/ it.)

on the other hand, i am eager to resolve the SCM_VCELL removal issue in
favor of allowing minimal changes to C source.

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> on the other hand, i am eager to resolve the SCM_VCELL removal issue in
> favor of allowing minimal changes to C source.

For at least the next release of guile, it's unlikely that we're going
to have completely smooth transitions -- guile has a lot of
accumulated cruft, some from it's origins, and some because until
recently we were on a very different (and ambiguous) path with respect
to the gh_ interface, an interface which now should be going away in
it's *entirety* in the not too distant future.  Heck until we finish
the _I_ _i_ renamings, there wasn't even any way for anyone to *know*
when they were using soemthing they shouldn't have been, but that
doesn't mean we're planning to support the entire exposed interface
going forward.

IMO the process of dropping all this cruft and cleaning things up may
be a bit painful, but I think it's far better than maintaining all of
it into the indefinite future, and this shouldn't be a continual
problem.  Once we finish one or two more releases with heavy cleanup,
guile should be much less jarring from release to release.

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 14 Mar 2002 19:48:55 +0100
> 
>    Don't do this.  First, SCM_VCELL and SCM_VARIABLE are not the same
>    thing.  You can't substitute one for the other.  (Likewise for the
>    substitutions.)
> 
> oops my bad, i didn't understand the macros well enough.  what can you
> use then, if you're interested in the long term?

The long term macro is SCM_VARIABLE.

>    Second, we already keep proper backward compatibility in the C code
>    itself:
> 
>        #if (SCM_DEBUG_DEPRECATED == 0)
> 
>        #define SCM_CONST_LONG(c_name, scheme_name,value) \
>        SCM_VCELL_INIT(c_name, scheme_name, scm_long2num(value))
> 
> these are not available in HEAD branch, which is where i did the
> original digging (thinking that perhaps snarfing macros are no longer in
> flux, but now i see that's not the case).
> 
> they are indeed in branch_release-1-6.
> 
> so now i'm confused.  is each guile release going to change these names
> to something else and yank some previous name?

Not necessarily.

> why isn't SCM_VCELL in HEAD branch snarf.h?

It is deprecated in the 1.6 branch and all things that are deprecated
in 1.6 are already removed from HEAD.  It is deprecated in the 1.6
branch because the whole concept of vcells has been deprecated.  This
has been done to clean up a confusing between glocs and structs and to
make the memoized code be a proper Scheme data structure.  Also, some
bindings where done with variables, and some not.  Now all bindings
are done with variables which makes for a better integration of the
module system into the rest of Guile.

> how do you propose to handle the situation where a user has
> SCM_VCELL but would like to use guile-1.8?

He should remove all uses of vcells and switch to variables.

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> everything is checked in now.  please feel free to read the new docs,
> try the new guile-snarf, and complain loudly so weirdnesses can be fixed
> (when the going gets weird, the weird turn pro)...

Please read the "Stable branch will freeze" article in guile-devel.
Here is the relevant excerpt:

    The guile-snarf changes need to be brought back to a state where
    guile-snarf is completely compatible with the last guile-snarf
    that has been installed.  It can add features, but must not remove
    any.  Also it should define SCM_MAGIC_SNARFER in addition to
    SCM_MAGIC_SNARF_INIT when pre-processing the C file.  The fact
    that SCM_MAGIC_SNARFER is defined should be documented, while
    SCM_MAGIC_SNARF_INIT should not be documented.  Thien-Thi, I can
    make these changes if you want me to.  Please feel free to hack on
    guile-snarf in the HEAD branch.  I really think your work on the
    snarfer is important, please don't get me wrong.


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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 15 Mar 2002 00:35:23 +0100

   > why isn't SCM_VCELL in HEAD branch snarf.h?

   It is deprecated in the 1.6 branch and all things that are deprecated
   in 1.6 are already removed from HEAD.  It is deprecated in the 1.6
   branch because the whole concept of vcells has been deprecated.  This
   has been done to clean up a confusing between glocs and structs and to
   make the memoized code be a proper Scheme data structure.  Also, some
   bindings where done with variables, and some not.  Now all bindings
   are done with variables which makes for a better integration of the
   module system into the rest of Guile.

   > how do you propose to handle the situation where a user has
   > SCM_VCELL but would like to use guile-1.8?

   He should remove all uses of vcells and switch to variables.

thanks for the explanation (which is also touched upon in NEWS -- i
should have looked there first).  looks like "1.4 compatibility" in
snarfing has no value in the long run, so "guile-snarf --compat=1.4"
support is misguided and can be removed.  i'll replace it with detection
of the deprecated macros, which for 1.6 would result in a warning, and
1.8 would result in an error.

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Thu, 14 Mar 2002 20:26:23 -0800

   i'll replace it with detection of the deprecated macros, which for
   1.6 would result in a warning, and 1.8 would result in an error.

here's guile-snarf commentary now (the bits that have changed):

# Usage: guile-snarf [-d | -D] [-o OUTFILE] INFILE [CPP-OPTIONS ...]
# [...]
# Optional arg "-d" means grep INFILE for deprecated macros and
# issue a warning if any are found.  Alternatively, "-D" means
# do the same thing but signal error and exit w/ non-zero status.

deprecrated macros listed in guile-snarf, tools.texi and NEWS:
 SCM_CONST_LONG
 SCM_VCELL
 SCM_VCELL_INIT
 SCM_GLOBAL_VCELL
 SCM_GLOBAL_VCELL_INIT

thi

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 14 Mar 2002 20:09:36 +0100
> 
>    > this is not guaranteed to work; when invoked w/ "foo > out.x", the shell
>    > does indeed create out.x first, satisfying most CPPs' requirements for
>    > out.x existing to be #included.
> 
>    Sorry, I was confused.  I still am, for that matter.  How can it
>    happen that during
> 
>        guile-snarf foo.c >foo.x
> 
>    the file foo.x does not exist?  It should get created by the shell
>    before guile-snarf is executed.

Ouch.  Boy, I was really really dense here.  Of course the actual
command that is run is not "guile-snarf foo.c >foo.x" but

    guile-snarf foo.c >foo.tmp.x && mv foo.tmp.x foo.x

No fancy buffer issues or race conditions needed to explain the
lossage...  People have been using the #ifdef SCM_MAGIC_SNARFER trick
to work around this, and we need to make that fix work again.

I now also understand why writing to stdout is so bad and why the "-o"
option is so much better.  (it's taken a while, sorry Thien-Thi.)

>    Yes, but it is still easier not to change existing code that makes use
>    of the old behavior of guile-snarf.
> 
> here, the code that needs changing is primarily in makefiles, which are
> not as big a pain to update as C source, there being fewer makefiles
> than source files typically.

But it's still easier not to change the snarfing rules.  Arguing for
an evil by citing a larger, unrelated evil is not really
convincing. ;-)

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Thien-Thi Nguyen <ttn@giblet.glug.org>
>    Date: Thu, 14 Mar 2002 20:26:23 -0800
> 
>    i'll replace it with detection of the deprecated macros, which for
>    1.6 would result in a warning, and 1.8 would result in an error.

That's a very good thing to do, in my opinion.

I think it would be even better when the list of deprecated snarfer
macros are taken from snarf.h itself.  Like, we could change the
SCM_VCELL definition to

    #define SCM_VCELL(c_name, scheme_name) \
    SCM_SNARF_HERE(static SCM c_name) \
    SCM_SNARF_INIT_DEPRECATED(c_name = \
      scm_permanent_object (scm_sysintern (scheme_name, SCM_BOOL_F));)

with

    # define SCM_SNARF_INIT_DEPRECATED(X) ^^deprecated X

guile-snarf could then detect the ^^deprecated marker and do its
thing.

Or, simpler, we could explicitely include calls to
scm_c_issue_deprecation_warning into the INIT code for deprecated snaf
macros.  Like

    #define SCM_VCELL(c_name, scheme_name) \
    SCM_SNARF_HERE(static SCM c_name) \
    SCM_SNARF_INIT(scm_c_issue_deprecation_warning \
     ("SCM_VCELL is deprecated.  Use SCM_VARIABLE instead."); \
     c_name = scm_permanent_object (scm_sysintern (scheme_name, SCM_BOOL_F));)


I even wonder if it would be good to enable the "-d" behavior by
default?

What do you think?

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

OK, so where does this leave us?  Is there still more work to be done
on snarfing, and if so, any ideas about when it might be ready?

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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> OK, so where does this leave us?  Is there still more work to be done
> on snarfing, and if so, any ideas about when it might be ready?

I will change the snarfer in the 1.6 branch to be compatible with the
1.4 one.  By compatible, I mean the guile-snarf program will have a
compatible usage, not that all the snarfer macros of 1.4 (like
SCM_VCELL) will be available.

That should be done by tomorrow.

When there crop up problems with the new snarfer (like non-portable
shell constructs), I will revert it to the simpler 1.4 snarfer and
attempt to fix the bugs in 1.7 in parallel.

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I will change the snarfer in the 1.6 branch to be compatible with the
> 1.4 one.  By compatible, I mean the guile-snarf program will have a
> compatible usage, not that all the snarfer macros of 1.4 (like
> SCM_VCELL) will be available.
>
> That should be done by tomorrow.

OK, then I'll plan to try to release the next 1.5 version (including
the gensym threads fix) mon or tues.

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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > I will change the snarfer in the 1.6 branch to be compatible with the
> > 1.4 one.  By compatible, I mean the guile-snarf program will have a
> > compatible usage, not that all the snarfer macros of 1.4 (like
> > SCM_VCELL) will be available.
> >
> > That should be done by tomorrow.
> 
> OK, then I'll plan to try to release the next 1.5 version (including
> the gensym threads fix) mon or tues.

Oops, sorry, I didn't find time this weekend.  I'll be busy Monday and
Tuesday as well...

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Oops, sorry, I didn't find time this weekend.  I'll be busy Monday and
> Tuesday as well...

No problem.  Thanks for letting me know, though -- just holler when
you get a chance to finish.

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > Oops, sorry, I didn't find time this weekend.  I'll be busy Monday and
> > Tuesday as well...
> 
> No problem.  Thanks for letting me know, though -- just holler when
> you get a chance to finish.

Ok, I've committed something.  Please check.

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

>> No problem.  Thanks for letting me know, though -- just holler when
>> you get a chance to finish.
>
> Ok, I've committed something.  Please check.

I'm trying to check against some of the other projects that use
guile-snarf, and I wanted to make sure I knew how things are expected
to work now (it's OK if the other projects need to change their
source, I just want to make sure I knew what those changes are and
that they're in NEWS and/or info).

Here's what gnome-guile 0.21pre4's failing on with current 1.5 cvs --
if I run the make immediately again, it seems to proceed normally, so
I'm presuming there's still some "file existence race" or similar:

  make[2]: Entering directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4/guile-gtk'
  guile-snarf -DHAVE_CONFIG_H -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include  -I/home/rlb/dev/guile/check/src/gnome-guile/guile-gtk -I/home/rlb/dev/guile/check/tmp/include -I/home/rlb/dev/guile/check/tmp/include -I/home/rlb/dev/guile/check/tmp/include  -g -O2 gtk-support.c >gtk-support.x
  make[2]: *** [gtk-support.x] Error 1
  make[2]: Leaving directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4/guile-gtk'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4'
  make: *** [all] Error 2

-- 
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: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Sorry for the delay.  Is this still an issue?

Rob Browning <rlb@defaultvalue.org> writes:

> Here's what gnome-guile 0.21pre4's failing on with current 1.5 cvs
> -- if I run the make immediately again, it seems to proceed
> normally, so I'm presuming there's still some "file existence race"
> or similar:
> 
>   make[2]: Entering directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4/guile-gtk'
>   guile-snarf -DHAVE_CONFIG_H -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include  -I/home/rlb/dev/guile/check/src/gnome-guile/guile-gtk -I/home/rlb/dev/guile/check/tmp/include -I/home/rlb/dev/guile/check/tmp/include -I/home/rlb/dev/guile/check/tmp/include  -g -O2 gtk-support.c >gtk-support.x
>   make[2]: *** [gtk-support.x] Error 1
>   make[2]: Leaving directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4/guile-gtk'
>   make[1]: *** [all-recursive] Error 1
>   make[1]: Leaving directory `/home/rlb/dev/guile/check/src/gnome-guile-0.21pre4'
>   make: *** [all] Error 2

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

Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Sorry for the delay.  Is this still an issue?

Nope, my current combination of guile stable and my gnome-guile tree
work fine together, but I may need to send a gnome-guile patch
upstream -- haven't checked yet where things ended up on that front.

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