[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFD: drop the GH interface.

From: Bruce Korb
Subject: Re: RFD: drop the GH interface.
Date: Sun, 21 Sep 2008 11:02:24 -0700

Hi Neil,

On Sun, Sep 21, 2008 at 2:40 AM, Neil Jerram <address@hidden> wrote:
> Hi Bruce, and thanks for your input on this...
> 2008/9/18 Bruce Korb <address@hidden>:
>> 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

> 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

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

        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 );
    port = scm_open_input_string( AG_SCM_STR02SCM( pzExpr ));

#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)
            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;

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

        SCM ans = SCM_UNSPECIFIED;

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

        return ans;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]