unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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;
    }
}




  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).