unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Andy Wingo <wingo@pobox.com>
Cc: 20109@debbugs.gnu.org
Subject: bug#20109: Incompatible API change in 2.0 series for string port encoding
Date: Thu, 23 Jun 2016 18:46:25 +0200	[thread overview]
Message-ID: <87wplfetum.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87vb0znac6.fsf@pobox.com> (Andy Wingo's message of "Thu, 23 Jun 2016 18:23:05 +0200")

Andy Wingo <wingo@pobox.com> writes:

> On Fri 17 Apr 2015 07:17, Mark H Weaver <mhw@netris.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> In 2.0.9, the following patch/code for getting what amounts to a binary
>>> string port worked.
>>>
>>> commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
>>> Author: David Kastrup <dak@gnu.org>
>>> 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





  reply	other threads:[~2016-06-23 16:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-15 13:15 bug#20109: Incompatible API change in 2.0 series for string port encoding David Kastrup
2015-03-16 20:42 ` Mark H Weaver
2015-03-16 20:46   ` Mark H Weaver
2015-03-17  8:39   ` David Kastrup
2015-03-17 22:44     ` Mark H Weaver
2015-03-18 12:32       ` David Kastrup
2015-04-17  5:17 ` Mark H Weaver
2016-06-23 16:23   ` Andy Wingo
2016-06-23 16:46     ` David Kastrup [this message]
2016-06-23 17:58       ` Andy Wingo

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=87wplfetum.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=20109@debbugs.gnu.org \
    --cc=wingo@pobox.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).