From: "Bruce Korb" <bkorb@gnu.org>
To: "Neil Jerram" <neiljerram@googlemail.com>
Cc: guile-devel@gnu.org
Subject: Re: RFD: drop the GH interface.
Date: Sun, 21 Sep 2008 11:02:24 -0700 [thread overview]
Message-ID: <668c430c0809211102i701b3d40o37643bf6713fe28@mail.gmail.com> (raw)
In-Reply-To: <49dd78620809210240r6a426487xdb893b55519f8ccd@mail.gmail.com>
Hi Neil,
On Sun, Sep 21, 2008 at 2:40 AM, Neil Jerram <neiljerram@googlemail.com> wrote:
> Hi Bruce, and thanks for your input on this...
>
> 2008/9/18 Bruce Korb <bkorb@gnu.org>:
>> 1. the most retrograde platform must have all the GH capabilities in
>> the SCM interfaces for their releases. It seems to take quite a few
>> years for BSD to get around to building newer versions.
>
> Greg has countered this, I believe. Do you still think there's any
> real concern here?
To be honest, I don't know. Some years back I started using some newfangled
Guile interfaces that were, at the time, a couple years old. I think
it was a 1.6-ism.
However, some variation of BSD (I'd guess not "Net") was still on 1.4.x.
So, I became responsible for having some if-def code decide which way to do
something based on the Guile version. Not a particularly difficult problem, but
nevertheless a bug report + new release cycle problem.
>> 3. I finally get around to removing GH stuff from my code
>
> Just to be clear: are you saying that you still need to do this?
Once bitten, twice shy. I want to be as sure as I can that my "clients" are all
up to 1.6 before dumping the last of 1.4 support. I am as retrograde as I
can get away with. :)
>> 4. a couple more years pass
>
> Why is this interval needed?
We have two parallel development processes: Guile and AutoGen.
They get picked up by clients at semi-random, un-coordinated points in time.
My switch from GH must be after potential clients have pretty much all
gotten recent
enough Guile versions. Similarly, releasing a Guile without GH must happen
long enough after your clients have switched that few such clients would get
whacked.
> I will make an announcement to the guile-users list; that should be
> enough. (Anyone who is going to use or package a new Guile version
> needs to be (at least vaguely) following guile-devel or guile-users.)
That's probably my level of "following": vaguely. :)
On a slightly unrelated question, are there any pending changes that would make
the following code obsolete? I've hated using it ever since I wrote
it, but I still
do not know of any reasonable alternative.
Thank you. Regards, Bruce
SCM
ag_scm_c_eval_string_from_file_line( char const * pzExpr, char const *
pzFile, int line )
{
SCM port;
if (OPT_VALUE_TRACE >= TRACE_EVERYTHING) {
fprintf( pfTrace, "eval from file %s line %d:\n%s\n", pzFile, line,
pzExpr );
}
#if GUILE_VERSION < 106000
{
static char const zEx[] = "eval-string-from-file-line";
SCM expr = scm_makfrom0str( pzExpr );
port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
}
#else
port = scm_open_input_string( AG_SCM_STR02SCM( pzExpr ));
#endif
#if GUILE_VERSION < 107000
{
static SCM file = SCM_UNDEFINED;
static char* pzFl = NULL;
scm_t_port* pt;
if ( (pzFl == NULL)
|| (strcmp( AG_SCM_CHARS( file ), pzFile ) != 0) ) {
if (pzFl != NULL)
AGFREE(pzFl);
AGDUPSTR(pzFl, pzFile, "eval file name");
file = AG_SCM_STR02SCM( pzFile );
}
pt = SCM_PTAB_ENTRY(port);
pt->line_number = line - 1;
pt->file_name = file;
}
#else
{
static SCM file = SCM_UNDEFINED;
static char* pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp( pzOldFile, pzFile ) != 0)) {
if (pzOldFile != NULL)
AGFREE( pzOldFile );
AGDUPSTR( pzOldFile, pzFile, "scheme file source" );
file = scm_from_locale_string( pzFile );
}
scm_set_port_filename_x( port, file );
}
{
SCM ln = scm_from_int( line );
scm_set_port_line_x( port, ln );
}
#endif
{
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;
}
}
next prev parent reply other threads:[~2008-09-21 18:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-13 3:08 RFD: drop the GH interface Han-Wen Nienhuys
2008-09-13 10:05 ` Ludovic Courtès
2008-09-14 16:19 ` Neil Jerram
2008-09-14 18:29 ` Han-Wen Nienhuys
2008-09-18 5:37 ` Han-Wen Nienhuys
2008-09-18 8:07 ` Ludovic Courtès
2008-09-18 9:07 ` Neil Jerram
2008-09-18 13:37 ` Ludovic Courtès
2008-09-20 23:11 ` Han-Wen Nienhuys
2008-09-28 20:47 ` Han-Wen Nienhuys
2008-09-28 20:58 ` Ludovic Courtès
2008-09-18 15:04 ` Bruce Korb
2008-09-19 21:57 ` Greg Troxel
2008-09-21 9:40 ` Neil Jerram
2008-09-21 18:02 ` Bruce Korb [this message]
2008-09-22 15:16 ` Ludovic Courtès
2008-09-22 20:12 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=668c430c0809211102i701b3d40o37643bf6713fe28@mail.gmail.com \
--to=bkorb@gnu.org \
--cc=guile-devel@gnu.org \
--cc=neiljerram@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).