Question re GDB interface functions and Guile

[Ian Hulin]

Hi all,
Eli Zaretskii recently asked this question as an aside in the thread on
guile 2.09 build on mingw.

"Btw, is there documentation anywhere about how to use the GDB
interface functions in Guile?  I sometimes need to display Scheme
values while debugging, and I see there are functions for that, but I
found no description of how they are supposed to be used.  What am I
missing?"

Some pointers would be really cool as we have had to brew our own things
in the Pond like this in a gdb file:


define ps
   print ly_display_scm($arg0)
end

document ps
  Interpret $arg0 as a scheme string by calling scm_display and
  scm_newline to output them to stdout
end

ly_display_scm is a C++ code-level routine, but all it basically does is

(define (ly_display_scm the-arg)
   (display the-arg)
   (newline))

So if you guys have any cool GDB things for dealing with Scheme
structures and things we'd find them really useful and would look to
include them in our documentation (CG = Contributors' Guide).

Thanks in advance, and yes, I've just invested in a hard copy of
"Debugging with GDB" as well as "The Guile 2.0 Reference Manual".

Cheers,
Ian Hulin (LilyPond Developer)

Re: Guile XCB

[Ludovic Courtès]

Hello,

m...@markwitmer.com skribis:

> I'm pleased to announce that Guile XCB is, at last, a real thing! I had
> to take a couple months off of working on it, but finally had time
> recently to go back and get it in pretty good shape.
>
> You can find it at https://github.com/mwitmer/guile-xcb.

Excellent!

It seems there’s no tag on the repo.  What about tagging this version,
and perhaps posting a tarball as produced by ‘make dist’?

> I also had an interesting time coming up with the necessary autotools
> magic

It seems that the Makefile.am lacks the magic trick to make sure that
the installed .go files are more recent than the installed .scm files
(to avoid triggering auto-compilation):

  http://lists.gnu.org/archive/html/guile-devel/2010-07/msg00125.html

>   Guile XCB requires the latest release of Guile (2.0.9).

Out of curiosity, what 2.0.9-specific thing does it rely on?

Happy hacking!

Ludo’.

Re: Guile XCB

[Stefan Israelsson Tampe]

Hi Mark!

Nice tool!

A bit off topic but maybe something that is perhaps useful in this project,
is there any scheme framework
centered around the scheme xsd specification to validate and translate
data.

If not, I could help. I'm wanting to learn that technology
and could in the mean time code something useful for
all to enjoy

If I would do that I would combine the guile module system and
xml namespaces an look at code that executes to a sxml-similar
representation.

Transfoming xml and parsing xml would mean that one uses syntax-parse,
syntax-rules
etc..

WDYT

/Stefan



On Tue, Jun 18, 2013 at 5:25 AM,  wrote:

>
> Hi everyone,
>
> I'm pleased to announce that Guile XCB is, at last, a real thing! I had
> to take a couple months off of working on it, but finally had time
> recently to go back and get it in pretty good shape.
>
> You can find it at https://github.com/mwitmer/guile-xcb.
>
> In the end I was able to write the whole thing without any C, so maybe
> this is a good candidate to include in the Guildhall. I've written a few
> simple programs in it but haven't really pushed it too hard. Sometime in
> the near-ish future I'd like to write some kind of window manager using
> it and I'm sure there will be many bugs found and squashed in the
> process!
>
> I also had an interesting time coming up with the necessary autotools
> magic to properly compile xml files to go files using the compiler I
> wrote and then install them. I'm still not sure if I'm doing it the
> right way -- adding new languages is really neat feature of Guile that's
> still a little tricky to automate.
>
> Here's the README:
>
> 1 Overview
> ==
>
>   Guile XCB is an X11 client library written entirely in Guile
>   Scheme. It makes use of the Guile compiler and virtual machine to turn
>   XML descriptions of the X protocol provided by the XCB project into
>   Guile object code files.
>
>   Support is included for the core X protocol and twenty-seven
>   extensions. Guile XCB also includes some simple code for running
>   asynchronous event loops.
>
>
> 2 Samples and Documentation
> ===
>
>   Samples using Guile XCB can be found in the xcb/xml/samples
>   directory. They include:
>
>   - tinywm.scm: A Guile XCB implementation of tinywm
>   - win.scm: A simple demonstration of creating a window and receiving
>  events
>   - randr.scm: A subset of the xrandr command line tool's functionality
>
>   More detailed documentation resides in the texinfo manual included in
>   this distribution.
>
>
> 3 Installation and Prerequisites
> 
>
>   You can use the typical ./configure, make, make install chain to build
>   Guile XCB.
>
>   Guile XCB requires the latest release of Guile (2.0.9).
>
>
> 4 Project Status and Caveats
> 
>
>   - The full XCB stack is implemented; however, many of the extensions
> haven't been extensively tested.
>
>   - Extensions that send large requests are probably going to be too
> slow for practical use. In a future release, void and byte lists
> should be represented as bytevectors, not regular vectors.
>
>   - Guile XCB includes a stripped-down Scheme implementation of Xauth
> that only supports UNIX sockets for now; it doesn't pick the "best"
> authentication method available, just the first.
>
>   - XPRINT is excluded because it's deprecated and its XML file has just
> enough special cases in it that it wasn't worth including. Some
> other deprecated extensions are included simply because there was no
> reason not to.
>
>
> --
> Mark Witmer
>
>

Re: Guile XCB

[mark . d . witmer]

The following message is a courtesy copy of an article
that has been posted to gmane.lisp.guile.user as well.

Stefan Israelsson Tampe  writes:

> Hi Mark!
>
> Nice tool!
>
> A bit off topic but maybe something that is perhaps useful in this
> project, is there any scheme framework 
> centered around the scheme xsd specification to validate and translate
> data.
>
> If not, I could help. I'm wanting to learn that technology 
> and could in the mean time code something useful for 
> all to enjoy
>
> If I would do that I would combine the guile module system and
> xml namespaces an look at code that executes to a sxml-similar
> representation.
>
> Transfoming xml and parsing xml would mean that one uses syntax-parse,
> syntax-rules
> etc.. 
>
> WDYT
>
> /Stefan
>

That's a cool idea. sxml-match provides a pattern-matching library for
xml with a way of binding variables to values extracted from the
sxml. Unlike xsd, however, it's missing a convenient way to constrain
the number of a particular child-element in some node (beyond specifying
0, 1, or many), and a way to check the type of data stored inside a
node. I had to write a few functions to do that stuff. I could see an
augmented version of sxml-match being useful as Scheme-friendly xsd
alternative.

-- 
Mark Witmer

Re: Guile XCB

[mark . d . witmer]

The following message is a courtesy copy of an article
that has been posted to gmane.lisp.guile.user as well.

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> m...@markwitmer.com skribis:
>
>> I'm pleased to announce that Guile XCB is, at last, a real thing! I had
>> to take a couple months off of working on it, but finally had time
>> recently to go back and get it in pretty good shape.
>>
>> You can find it at https://github.com/mwitmer/guile-xcb.
>
> Excellent!
>
> It seems there’s no tag on the repo.  What about tagging this version,
> and perhaps posting a tarball as produced by ‘make dist’?

Done. The url is http://www.markwitmer.com/dist/guile-xcb-0.1.tar.gz

>>   Guile XCB requires the latest release of Guile (2.0.9).
>
> Out of curiosity, what 2.0.9-specific thing does it rely on?
>

It uses the keyword argument #:trim-whitespace in xml->sxml, which was
added back in Februrary if I'm not mistaken.

>
>

-- 
Mark Witmer

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: l...@gnu.org,  guile-user@gnu.org
> Date: Mon, 17 Jun 2013 11:45:51 -0400
> 
> Eli Zaretskii  writes:
> > The bug report at http://bugs.gnu.org/14171 says that when Guile is
> > compiled with enable-posix, it "can't start the REPL".  Can someone
> > please show me a simple way of trying that?
> 
> Just run Guile in such a way that would lead to an interactive Guile
> prompt, e.g. by running without any command-line arguments.

Ah, so REPL means "read-eval-print loop".  It's a bit bizarre to see
this acronym used and explained in the Guile reference manual, but
not indexed, so please consider the trivial 2-line patch below.

> Two people
> reported that when built with --enable-posix, Guile would work when run
> in a non-interactive way (e.g. using -c or running a script), but would
> hang when run interactively.
> 
> As described in ,
> the problem seems to be in 'call-with-sigint' defined in
> ice-9/top-repl.scm.  Note that 'call-with-sigint' only installs a signal
> handler if POSIX support is enabled, and otherwise is a no-op.
> --disable-posix avoided the hang and allowed the REPL to be reached.

I looked into this.  First of all, the Guile I built without threads,
but with --enable-posix does not hang when I invoke it without
arguments.  It shows me the prompt and allows me to type commands.  It
also reacts correctly to Ctrl-C.  So the fact is that POSIX does not
by itself do any harm in the MinGW build.

My analysis of this, which included both reading the relevant sources
and the above-mentioned bug report, is that the conclusion in that bug
report is based on a mistaken interpretation of the reasons for the
hang.  It is not related to HAVE_POSIX, except accidentally.  It's
true that call-with-sigint installs a signal handler (by eventually
calling scm_sigaction_for_thread) only if HAVE_POSIX is defined.
However, nothing in the code of scm_sigaction_for_thread has anything
to do with HAVE_POSIX.  By contrast, it has _everything_ to do with
threads: it calls the same scm_i_ensure_signal_delivery_thread,
which unsurprisingly is the same place where I found Guile to hang
even in batch mode.  When SCM_USE_PTHREAD_THREADS is not defined,
scm_i_ensure_signal_delivery_thread is a no-op.

Moreover, the backtrace in the bug report clearly shows that Guile
hangs in pthread-related functions called from
scm_sigaction_for_thread, not in something that is only included if
HAVE_POSIX is defined.  So I concluded that disabling POSIX just works
around that problem, by not installing the signal handler, which
avoids calling scm_i_ensure_signal_delivery_thread, but the problem
itself, with threads usage, is still there.

IOW, it's not the POSIX functionality that is the culprit; it's
threads.

Which reminds me that it would be nice if someone could comment on the
findings and questions I published in
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00030.html.

Here's the patch for the manual:

  Improve indexing of "REPL".

* doc/ref/scheme-using.texi (Using Guile Interactively): Add index
entries for REPL.

diff --git a/doc/ref/scheme-using.texi b/doc/ref/scheme-using.texi
index 4422c18..350df9c 100644
--- a/doc/ref/scheme-using.texi
+++ b/doc/ref/scheme-using.texi
@@ -24,6 +24,8 @@ $3 = b
 @end lisp
 
 @noindent
+@cindex REPL
+@cindex read-eval-print loop
 This mode of use is called a @dfn{REPL}, which is short for
 ``Read-Eval-Print Loop'', because the Guile interpreter first reads the
 expression that you have typed, then evaluates it, and then prints the

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 20:17:25 +0300
> From: Eli Zaretskii 
> Cc: l...@gnu.org, guile-user@gnu.org
> 
> Ah, so REPL means "read-eval-print loop".  It's a bit bizarre to see
> this acronym used and explained in the Guile reference manual, but
> not indexed, so please consider the trivial 2-line patch below.

As long as we are on the topic of the Info docs: producing Info
manuals with UTF-8 encoded characters is not a good idea for the MinGW
build, because the Windows console does not support UTF-8, and so at
least the stand-alone Info reader will show a lot of garbage on
Windows.  I suggest to use --disable-encoding for the MinGW build.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii  skribis:

>> Date: Tue, 18 Jun 2013 20:17:25 +0300
>> From: Eli Zaretskii 
>> Cc: l...@gnu.org, guile-user@gnu.org
>> 
>> Ah, so REPL means "read-eval-print loop".  It's a bit bizarre to see
>> this acronym used and explained in the Guile reference manual, but
>> not indexed, so please consider the trivial 2-line patch below.
>
> As long as we are on the topic of the Info docs: producing Info
> manuals with UTF-8 encoded characters is not a good idea for the MinGW
> build, because the Windows console does not support UTF-8, and so at
> least the stand-alone Info reader will show a lot of garbage on
> Windows.  I suggest to use --disable-encoding for the MinGW build.

The problem is that the tarball comes with a .info file so that users
don’t need to have makeinfo installed (as per the GCS).

What about suggesting Windows users to use Emacs to view the
documentation?  My feeling is that people aware of Info on Windows may
already being doing this anyway.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: m...@netris.org,  guile-user@gnu.org
>> Date: Sun, 16 Jun 2013 16:59:19 +0200
>> 
>> >  Running ports.test
>> >  FAIL: ports.test: file: binary mode ignores port encoding
>> >  FAIL: ports.test: file: binary mode ignores file coding declaration
>> >
>> >Should I worry about this?
>> 
>> Possibly.  :-)
>> 
>> Can you try this patch, run ./check-guile ports.test, and report the
>> debugging statements that are printed?
>
> That pk thing is a useful trick, thanks.
>
> Btw, is there documentation anywhere about how to use the GDB
> interface functions in Guile?  I sometimes need to display Scheme
> values while debugging, and I see there are functions for that, but I
> found no description of how they are supposed to be used.  What am I
> missing?

There’s a gdbinit file in Guile that you can load to get a few helper
functions.

>> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
>> index 9b1c6c0..6137181 100644
>> --- a/test-suite/tests/ports.test
>> +++ b/test-suite/tests/ports.test
>> @@ -251,7 +251,7 @@
>>  (line (read-line in-port)))
>> (close-port in-port)
>> (delete-file filename)
>> -   (string=? line binary-test-string)
>> +   (string=? (pk 'line line) binary-test-string)
>>  
>>  ;;; binary mode ignores file coding declaration
>>  (pass-if "file: binary mode ignores file coding declaration"
>> @@ -272,7 +272,7 @@
>>  (line2 (read-line in-port)))
>> (close-port in-port)
>> (delete-file filename)
>> -   (string=? line2 binary-test-string)
>> +   (string=? (pk 'line2 line2) binary-test-string)
>>  
>>  ;; open-file ignores file coding declaration by default
>>  (pass-if "file: open-file ignores coding declaration by default"
>
> It's due to the CRLF thing.  These files are open in the "w" mode, but
> then read using the "rb" mode.  So the CR character is left after the
> newline is stripped, and botches the comparison.  The debug lines you
> added show this (note the \r at the end):
>
>  ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>  FAIL: ports.test: file: binary mode ignores port encoding
>  
>  ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>  FAIL: ports.test: file: binary mode ignores file coding declaration

I think this patch solves the problem:

diff --git a/libguile/rdelim.c b/libguile/rdelim.c
index 9d14967..9f16c69 100644
--- a/libguile/rdelim.c
+++ b/libguile/rdelim.c
@@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
 	{
 	case EOF:
 	case '\n':
+	case '\r':
 	  delim = buf[index];
 	  break;
 
Probably the extra case should be #ifdef __MINGW32__, to make sure it
has no effect on non-Windows users.  Thoughts?

> I think the solution is to attach to the output port a transcoder that
> leaves the single newline character at end of line intact.  But I
> couldn't find any example or documentation that would show me how to
> construct a transcoder for an encoding.  make-transcoder wants a
> codec, but I see no documentation how to make one.  IOW, how do I take
> a string like "iso-8859-15" and make a codec out of it?  I trust that
> you will know, though ;-)

Ah ah, this is an R6RS API that’s not actually fully implemented.

So, there are predefined codecs, like ‘latin-1-codec’.  This part is
implemented, in terms of ‘set-port-encoding!’.

However the CR/LF transcoders are not implemented.

Ludo’.

Why launch the Guile signal delivery thread on exit? (was Re: guile 2.0.9 build on mingw)

[Mark H Weaver]

Hi Julian,

Could you help us understand some code you added to Guile in 2007?

Eli Zaretskii  writes:
> Why isn't the signal delivery thread launched at program start

The signal delivery thread is not launched until the first signal
handler is installed.  This would seem sensible if not for the fact that
it is always launched at exit, which I found surprising.

> and why is it launched at exit?

Good question.  This behavior was apparently introduced in this commit:

  
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2e77f7202b11ad0003831fcff94ec7db80cca015

It appears that Julian Graham may have been the author of these changes.
I've CC'd him, hoping that he can shed some light on this.

> +  /* Ensure the signal handling thread has been launched, because we might be
> + shutting it down.  */
> +  scm_i_ensure_signal_delivery_thread ();

Julian, can you remember why you did this?  I don't understand the
comment above.  What does "it" refer to?  I would that guess that "it"
is the signal handling thread, but how could we be shutting down that
thread if it hadn't yet been launched?

Regards,
  Mark

Re: guile 2.0.9 build on mingw

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Eli Zaretskii  skribis:
>
>> It's due to the CRLF thing.  These files are open in the "w" mode, but
>> then read using the "rb" mode.  So the CR character is left after the
>> newline is stripped, and botches the comparison.  The debug lines you
>> added show this (note the \r at the end):
>>
>>  ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>  FAIL: ports.test: file: binary mode ignores port encoding
>>  
>>  ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>  FAIL: ports.test: file: binary mode ignores file coding declaration
>
> I think this patch solves the problem:
>
> diff --git a/libguile/rdelim.c b/libguile/rdelim.c
> index 9d14967..9f16c69 100644
> --- a/libguile/rdelim.c
> +++ b/libguile/rdelim.c
> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>   {
>   case EOF:
>   case '\n':
> + case '\r':
> delim = buf[index];
> break;
>  
>
> Probably the extra case should be #ifdef __MINGW32__, to make sure it
> has no effect on non-Windows users.  Thoughts?

I think this is a bad idea for multiple reasons:

* Handling of alternate line endings does not belong here; it belongs in
  a transcoder of some sort.

* This solution partially hides a problem (the user reading text without
  a proper transcoder), but does not solve the problem adequately.  It
  will behave badly on files with CRLF line endings.  There's no way to
  fix that in 'read-line' because its API does not allow for a
  multi-character delimiter.

* It potentially breaks existing code.  Making the change only on mingw
  would seem to mitigate that problem, but that just muddies the waters
  by introducing a difference in behavior that is not necessarily
  warranted.

* It hard codes the assumption that the line ending style of the file
  being read is determined by the platform you're running on.

To my mind, this is a bug in those tests.  So how about the following
patch instead?

What do you think?

Mark


diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
index 9b1c6c0..758f8f6 100644
--- a/test-suite/tests/ports.test
+++ b/test-suite/tests/ports.test
@@ -238,7 +238,7 @@
 (pass-if "file: binary mode ignores port encoding"
   (with-fluids ((%default-port-encoding "UTF-8"))
(let* ((filename (test-file))
-  (port (open-file filename "w"))
+  (port (open-file filename "wb"))
   (test-string "一二三")
   (binary-test-string
(apply string
@@ -257,7 +257,7 @@
 (pass-if "file: binary mode ignores file coding declaration"
   (with-fluids ((%default-port-encoding "UTF-8"))
(let* ((filename (test-file))
-  (port (open-file filename "w"))
+  (port (open-file filename "wb"))
   (test-string "一二三")
   (binary-test-string
(apply string

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-user@gnu.org
> Date: Tue, 18 Jun 2013 22:19:13 +0200
> 
> > As long as we are on the topic of the Info docs: producing Info
> > manuals with UTF-8 encoded characters is not a good idea for the MinGW
> > build, because the Windows console does not support UTF-8, and so at
> > least the stand-alone Info reader will show a lot of garbage on
> > Windows.  I suggest to use --disable-encoding for the MinGW build.
> 
> The problem is that the tarball comes with a .info file so that users
> don’t need to have makeinfo installed (as per the GCS).

I know.  I didn't want to go as far as asking to not use UTF-8 in the
tarball as well (although given the lack of characters in the docs
that really need UTF-8, that would not be such a bad idea).  But at
least rebuilding docs could then DTRT.

> What about suggesting Windows users to use Emacs to view the
> documentation?  My feeling is that people aware of Info on Windows may
> already being doing this anyway.

I use both, FWIW.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: m...@netris.org,  guile-user@gnu.org
> Date: Tue, 18 Jun 2013 22:45:34 +0200
> 
> I think this patch solves the problem:
> 
> diff --git a/libguile/rdelim.c b/libguile/rdelim.c
> index 9d14967..9f16c69 100644
> --- a/libguile/rdelim.c
> +++ b/libguile/rdelim.c
> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>   {
>   case EOF:
>   case '\n':
> + case '\r':
> delim = buf[index];
> break;
> 
> Probably the extra case should be #ifdef __MINGW32__, to make sure it
> has no effect on non-Windows users.  Thoughts?

Not a good idea, IMO: it will remove lone CR characters as well.

> > I think the solution is to attach to the output port a transcoder that
> > leaves the single newline character at end of line intact.  But I
> > couldn't find any example or documentation that would show me how to
> > construct a transcoder for an encoding.  make-transcoder wants a
> > codec, but I see no documentation how to make one.  IOW, how do I take
> > a string like "iso-8859-15" and make a codec out of it?  I trust that
> > you will know, though ;-)
> 
> Ah ah, this is an R6RS API that’s not actually fully implemented.
> 
> So, there are predefined codecs, like ‘latin-1-codec’.  This part is
> implemented, in terms of ‘set-port-encoding!’.
> 
> However the CR/LF transcoders are not implemented.

Too bad.  The text/binary I/O issue on Windows is not really reliable
without that.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: Eli Zaretskii ,  guile-user@gnu.org
> Date: Tue, 18 Jun 2013 18:28:13 -0400
> 
> I think this is a bad idea for multiple reasons:
> 
> * Handling of alternate line endings does not belong here; it belongs in
>   a transcoder of some sort.
> 
> * This solution partially hides a problem (the user reading text without
>   a proper transcoder), but does not solve the problem adequately.  It
>   will behave badly on files with CRLF line endings.  There's no way to
>   fix that in 'read-line' because its API does not allow for a
>   multi-character delimiter.
> 
> * It potentially breaks existing code.  Making the change only on mingw
>   would seem to mitigate that problem, but that just muddies the waters
>   by introducing a difference in behavior that is not necessarily
>   warranted.
> 
> * It hard codes the assumption that the line ending style of the file
>   being read is determined by the platform you're running on.

I agree.

> To my mind, this is a bug in those tests.

Right.

> So how about the following patch instead?
> 
> What do you think?
> 
> Mark
> 
> 
> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
> index 9b1c6c0..758f8f6 100644
> --- a/test-suite/tests/ports.test
> +++ b/test-suite/tests/ports.test
> @@ -238,7 +238,7 @@
>  (pass-if "file: binary mode ignores port encoding"
>(with-fluids ((%default-port-encoding "UTF-8"))
> (let* ((filename (test-file))
> -  (port (open-file filename "w"))
> +  (port (open-file filename "wb"))
>(test-string "一二三")
>(binary-test-string
> (apply string
> @@ -257,7 +257,7 @@
>  (pass-if "file: binary mode ignores file coding declaration"
>(with-fluids ((%default-port-encoding "UTF-8"))
> (let* ((filename (test-file))
> -  (port (open-file filename "w"))
> +  (port (open-file filename "wb"))
>(test-string "一二三")
>(binary-test-string
> (apply string

I already tried that, and it doesn't work.  You cannot have a port
that is both UTF-8 encoded and open in binary mode, because Guile will
try to encode characters in 8859-1, and fail (because the characters
used here are not Latin-1 characters).

IOW, binary I/O cannot be encoded.