--- Begin Message ---
|
Subject: |
Incompatible API change in 2.0 series for string port encoding |
|
Date: |
Sun, 15 Mar 2015 14:15:56 +0100 |
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. Since we are ping-ponging between GUILE and a
native LilyPond interpreter and need to work with file offsets for
keeping them in synch, it isn't an option to have scm_open_input_string
convert to a different encoding.
It also does not make sense from an efficiency point of view since
strings are either encoded as latin-1 or UTF-32, so encoding string
ports as UTF-8 without alternative means that it is _impossible_ to
employ string ports efficiently and without conversion.
--
David Kastrup
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20109: Incompatible API change in 2.0 series for string port encoding |
|
Date: |
Thu, 23 Jun 2016 19:58:12 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
On Thu 23 Jun 2016 18:46, David Kastrup <address@hidden> writes:
> With regard to Guile 2.0, I cannot provide anything that would warrant
> keeping this report open.
Okeydoke, will close. Thanks :)
Andy
--- End Message ---