Andy Wingo <wi...@pobox.com> writes: > On Fri 17 Apr 2015 07:17, Mark H Weaver <m...@netris.org> writes: > >> David Kastrup <d...@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 <d...@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