bug#20109: Incompatible API change in 2.0 series for string port encoding

[David Kastrup]

Andy Wingo <address@hidden> writes:

> On Fri 17 Apr 2015 07:17, Mark H Weaver <address@hidden> writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> In 2.0.9, the following patch/code for getting what amounts to a binary
>>> string port worked.
>>>
>>> commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
>>> Author: David Kastrup <address@hidden>
>>> Date:   Sun Sep 21 18:40:06 2014 +0200
>>>
>>>     Source_file::init_port: Keep GUILEv2 from redecoding string input
>>>
>>> diff --git a/lily/source-file.cc b/lily/source-file.cc
>>> index 1118b9d..75ed0d9 100644
>>> --- a/lily/source-file.cc
>>> +++ b/lily/source-file.cc
>>> @@ -152,7 +152,11 @@ Source_file::init_port ()
>>>    // we do our own utf8 encoding and verification in the parser, so we
>>>    // use the no-conversion equivalent of latin1
>>>    SCM str = scm_from_latin1_string (c_str ());
>>> -  str_port_ = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG, 
>>> __FUNCTION__);
>>> +  scm_dynwind_begin ((scm_t_dynwind_flags)0);
>>> +  // Why doesn't scm_set_port_encoding_x work here?
>>> +  scm_dynwind_fluid (ly_lily_module_constant ("%default-port-encoding"), 
>>> SCM_BOOL_F);
>>> +  str_port_ = scm_open_input_string (str);
>>> +  scm_dynwind_end ();
>>>    scm_set_port_filename_x (str_port_, ly_string2scm (name_));
>>>  }
>>>  
>>>
>>> In 2.0.11, it doesn't.  This is an incompatible API change within the
>>> "stable" 2.0 series.
>>
>> Are you sure that you weren't using Guile from our 'master' branch?  I'm
>> not aware of any change made on our stable-2.0 branch that would break
>> the above approach.
>>
>> We _did_ make an incompatible change that would break this approach on
>> our master branch, which will become Guile 2.2.  On that branch, string
>> ports always use UTF-8 to encode the initial string, and UTF-8 is always
>> used as the initial port encoding.  However, stable-2.0 still uses
>> %default-port-encoding.
>
> I believe Mark is right -- the change to string ports is only on
> `master'.  Given that, I think the bug can be closed.  David does this
> match your perception?

My recollection is that I had a branch working in this area and it
stopped doing so.  I haven't kept written notes, I have not pinpointed a
commit in the respective Guile version range that looks like it could be
responsible.  As this occured in the context of an Ubuntu update,
changes in other libraries (like the locale parts) and/or settings might
have been at play.  I think I downgraded the guile-1.8-dev package (and
dependencies) for a test and was not able to get the stuff working again
either.  I noticed this problem months after the change likely has
happened.

All in all, I cannot provide anything useful for tracking down the
purported regression, nor dependable evidence of it, nor even
circumstancial evidence.  It's purely anecdotal and I have not been able
to recover the purportedly better working state with downgrading.

Whatever may or may not have been involved here, with the fixes to R6RS
binary streams to be released in 2.0.12 we'll have another chance to
steer clear entirely of this area in LilyPond (which has the added
advantage that the changes in 2.1 should no longer affect us).

With regard to Guile 2.0, I cannot provide anything that would warrant
keeping this report open.

-- 
David Kastrup