RFD: drop the GH interface.

RFD: drop the GH interface.

[Han-Wen Nienhuys]

The GH interface was marked as deprecated in 

commit a0143ebc24c24198e0dfce9b80f3648feb706226
Author: Neil Jerram <neil@ossau.uklinux.net>
Date:   Wed Jun 20 22:08:19 2001 +0000

    * Explain GH deprecation & plan for scm documentation.


Let's really drop it now.
 
-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: RFD: drop the GH interface.

[Ludovic Courtès]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> The GH interface was marked as deprecated in 
>
> commit a0143ebc24c24198e0dfce9b80f3648feb706226
> Author: Neil Jerram <neil@ossau.uklinux.net>
> Date:   Wed Jun 20 22:08:19 2001 +0000
>
>     * Explain GH deprecation & plan for scm documentation.
>
>
> Let's really drop it now.

Why?  It doesn't cost much to keep it, does it?

Thanks,
Ludo'.

Re: RFD: drop the GH interface.

[Neil Jerram]

2008/9/13 Ludovic Courtès <ludo@gnu.org>:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> The GH interface was marked as deprecated in
>>
>> commit a0143ebc24c24198e0dfce9b80f3648feb706226
>> Author: Neil Jerram <neil@ossau.uklinux.net>
>> Date:   Wed Jun 20 22:08:19 2001 +0000
>>
>>     * Explain GH deprecation & plan for scm documentation.
>>
>>
>> Let's really drop it now.
>
> Why?  It doesn't cost much to keep it, does it?

My view: it doesn't cost much, but it does cost something.  For
example, every time one greps the code to find all uses of a libguile
function/variable/macro, the GH code means that there is a bit more to
look at.  In general, I think less code is better, so we would need a
good reason for keeping the GH code, and we don't need an especially
compelling reason to throw it away.

Therefore, I vote for dropping it.

     Neil

Re: RFD: drop the GH interface.

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> The GH interface was marked as deprecated in 
>>
>> commit a0143ebc24c24198e0dfce9b80f3648feb706226
>> Author: Neil Jerram <neil@ossau.uklinux.net>
>> Date:   Wed Jun 20 22:08:19 2001 +0000
>>
>>     * Explain GH deprecation & plan for scm documentation.
>>
>>
>> Let's really drop it now.
> 
> Why?  It doesn't cost much to keep it, does it?

It is a small cost, but it is recurring. Eliminating
it once will save us work over a longer period.  Also,
if we don't remove interfaces that we deprecate, we 
shouldn't bother with deprecating them in the first 
place.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: RFD: drop the GH interface.

[Han-Wen Nienhuys]

Do we have a consensus?

Ludovic Courtès escreveu:

>> The GH interface was marked as deprecated in 

>>     * Explain GH deprecation & plan for scm documentation.
>>
>>
>> Let's really drop it now.
> 
> Why?  It doesn't cost much to keep it, does it?
> 

	
-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: RFD: drop the GH interface.

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Do we have a consensus?

Yes, fine by me, but no rush.  ;-)

Ludo'.

Re: RFD: drop the GH interface.

[Neil Jerram]

2008/9/18 Ludovic Courtès <ludo@gnu.org>:
> Hi,
>
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> Do we have a consensus?
>
> Yes, fine by me, but no rush.  ;-)

Do you mean anything specific by "no rush" here?  I think we should do
it before we forget that we have a consensus. :-)  Han-Wen, would you
like to do the work?  (I assume it should be just in the master branch
for now.)

Regards,
     Neil

Re: RFD: drop the GH interface.

[Ludovic Courtès]

"Neil Jerram" <neiljerram@googlemail.com> writes:

> 2008/9/18 Ludovic Courtès <ludo@gnu.org>:

>> Yes, fine by me, but no rush.  ;-)
>
> Do you mean anything specific by "no rush" here?

I just meant I'm not gonna do it Right Now but that's fine by me if
somebody else does.

Thanks,
Ludo'.

Re: RFD: drop the GH interface.

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
>>> Yes, fine by me, but no rush.  ;-)
>> Do you mean anything specific by "no rush" here?
> 
> I just meant I'm not gonna do it Right Now but that's fine by me if
> somebody else does.

Please see dev/hanwen on savannah.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: RFD: drop the GH interface.

[Han-Wen Nienhuys]

Ping?


Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>>>> Yes, fine by me, but no rush.  ;-)
>>> Do you mean anything specific by "no rush" here?
>> I just meant I'm not gonna do it Right Now but that's fine by me if
>> somebody else does.
> 
> Please see dev/hanwen on savannah.
> 


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: RFD: drop the GH interface.

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Ludovic Courtès escreveu:
>>>> Yes, fine by me, but no rush.  ;-)
>>> Do you mean anything specific by "no rush" here?
>> 
>> I just meant I'm not gonna do it Right Now but that's fine by me if
>> somebody else does.
>
> Please see dev/hanwen on savannah.

I'm assuming this patch:

  commit 784f04c8702393b0d25c07515a449ff7b7adaca1
  Author: Han-Wen Nienhuys <hanwen@lilypond.org>
  Date:   Sat Sep 13 00:19:23 2008 -0300

      Remove GH and its traces.

It looks good to me.  Feel free to apply it to `master' as long as it
doesn't break "distcheck".

One thing about the NEWS entry:

+** The GH interface (deprecated in 2001) was removed

I'd say "deprecated in the 1.6 series, in 2001".

Thanks,
Ludo'.

Re: RFD: drop the GH interface.

[Bruce Korb]

Ludovic Courte`s wrote:
> Hi,
> 
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> Do we have a consensus?
> 
> Yes, fine by me, but no rush.  ;-)

 From a Guile-user and not developer perspective, the sequence needs to be:
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.

2. Once that happens, a couple of years must pass

3. I finally get around to removing GH stuff from my code (is there a guide?)

4. a couple more years pass

5. now it's okay by me for released code to not have GH.

I think we're to step 3 now, but I need to check the Guile version distributed
with net/open/free BSD.  Last I looked (~4 or 5 years ago...), it was either
1.4.x or, perhaps, 1.6.x.  It was many years behind.  In any case, I would
suggest checking with your "customers" and "redistributors" instead of this list.
IMHO, anyway.

Regards, Bruce

Re: RFD: drop the GH interface.

[Greg Troxel]

Bruce Korb <bkorb@gnu.org> writes:

> From a Guile-user and not developer perspective, the sequence needs to be:
> 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.

I'm not sure quite what you mean.  The BSD systems are different from
linux in that there is a 'base system' and then a 'package system', and
releases of the base system are decoupled from packaging system changes.
NetBSD and Dragonfly uses pkgsrc, and pkgsrc has stable pkgsrc releases
every quarter.  Currently pkgsrc has guile 1.8.5, which I think is up to
date.

I am not clear on the status of guile in FreeBSD ports and OpenBSD
ports.  I don't think there are other BSDs.

> I think we're to step 3 now, but I need to check the Guile version
> distributed with net/open/free BSD.  Last I looked (~4 or 5 years
> ago...), it was either 1.4.x or, perhaps, 1.6.x.  It was many years
> behind.  In any case, I would suggest checking with your "customers"
> and "redistributors" instead of this list.  IMHO, anyway.

I maintain the guile package in pkgsrc; I would hope the other system's
maintainers are also on this list, or at least on some announce list.

But for pkgsrc, it's been at 1.8 since

date: 2007/06/12 03:02:33;  author: dmcmahill;  state: Exp;  lines: +24 -3

Re: RFD: drop the GH interface.

[Neil Jerram]

Hi Bruce, and thanks for your input on this...

2008/9/18 Bruce Korb <bkorb@gnu.org>:
>
> From a Guile-user and not developer perspective, the sequence needs to be:
> 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?

> 2. Once that happens, a couple of years must pass

I'm not sure exactly what starting point you mean, but

- Guile 1.8.1 was released in October 2006

- the decision to deprecate and eventually remove GH happened in June 2001.

> 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?

> (is there a guide?)

Yes, node `Transitioning away from GH' in the manual.

(And there's also the GH code, of course, libguile/gh*.)

> 4. a couple more years pass

Why is this interval needed?

> In any case, I would
> suggest checking with your "customers" and "redistributors" instead of this
> list.

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

Regards,
        Neil

Re: RFD: drop the GH interface.

[Bruce Korb]

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

Re: RFD: drop the GH interface.

[Ludovic Courtès]

Hi,

"Bruce Korb" <bkorb@gnu.org> writes:

>         SCM  expr  = scm_makfrom0str( pzExpr );

That's deprecated as of 1.8, use `scm_from_locale_string ()'.

>         scm_t_port* pt;

I wouldn't recommend using this structure as it's in a semi-internal,
undocumented state.  :-)

Anyway, why not just use `scm_c_eval_string ()'?  It'd be really safer
than "rolling your own".

Thanks,
Ludovic.

Re: RFD: drop the GH interface.

[Neil Jerram]

2008/9/21 Bruce Korb <bkorb@gnu.org>:
>
> 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 )
[...]

<friendly sarcasm>

There aren't any pending changes that would make this code obsolete.
But there is a little something that Guile has supported for a while,
called Scheme.

</friendly sarcasm>

Seriously, though.  The whole point of Guile is to allow people to
write more Scheme and less C, and your C code could be written much
more easily in Scheme:

(define (ag-eval-string-from-file-line expr file line)
  (with-input-from-string expr
    (lambda ()
      (set-port-filename! (current-input-port) file)
      (set-port-line! (current-input-port) line)
      (set-port-column! (current-input-port) 0)
      (let loop ((ans *unspecified*)
		 (x (read)))
	(if (eof-object? x)
	    ans
	    (loop (primitive-eval x)
		  (read)))))))

As far as I know, everything there has been in place and stable since
the start of 1.6.

So, the reason the libguile API doesn't include functions that are
complex compositions of more primitive APIs, such as your
ag_scm_c_eval_string_from_file_line(), is that such compositions are
supposed to be done in Scheme instead.

I think the Scheme above is way clearer than the C.  Also, once you're
in Scheme, it's way easier to add further bells and whistles, such as
more intelligent error handling.  For a real example of that, see the
block of code beginning `((eval)' in ice-9/gds-client.scm (currently
line 353).

What do you think?  Could autogen do this in Scheme instead of in C?

Regards,
       Neil