bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`

2020-03-22 Thread Andreas Rottmann


Ludovic Courtès writes:

> Hi Andreas,
>
> And welcome back!  :-)
>
Thanks -- and thanks in return for looking into this!

> Andreas Rottmann  skribis:
>
>> Andreas Rottmann  writes:
>>
>>> [...] I isolated the cause; the following snippet hangs on Guile 2.2
>>> and 3.0, while it worked as expected on 2.0:
>>>
>>> ;; --
>>> (import (rnrs))
>>>
>>> (let* ((p (pipe))
>>>(in (car p))
>>>(out (transcoded-port (cdr p) (make-transcoder (utf-8-codec)
>>>   (put-datum out "foo")
>>>   (flush-output-port out)
>>>   (display "Should have written to pipe by now, attempting reading a 
>>> byte\n")
>>>   (display "Got")
>>>   (display (get-u8 in))
>>>   (newline))
>>> ;; ---
>>>
>>> It seems the underlying port is no longer flushed to the OS, so the
>>> `get-u8` now hangs waiting for input, starting with Guile 2.2.
>>>
>> I'd like to add that this is indeed not passing data to the OS, as
>> verified by strace. Also, I have now figured out the commit introducing
>> the regression, namely 8399e7af5 ("Generic port facility provides
>> buffering uniformly"); the commit before (e8b1d) still runs the
>> above code to completion.
>
> Actually I think the code above behaves as expected.  ‘pipe’ returns
> buffered ports by default.  When flushing the transcoded port,
> ‘transcoded_port_write’ is called, but then bytes written to the pipe
> are buffered.
>
> The fix is to add:
>
>   (setvbuf (cdr p) 'none)
>
> Does that make sense?
>
It makes sense, and I can confirm that it makes the boiled-down example
I posted work.

However, I'm not sure it is the expected behavior. Regardless of
buffering modes used, I would expect a `flush-output-port` in a "port
stack" (as produced by `transcoded-output-port`) to propagate all the
way to the OS. It seems that was the case in Guile 2.0, as I'm pretty
sure I observed the "breaking" behavior change with 8399e7af5 applied,
and not with the commit preceding it.

If the current behavior is indeed the intended one, we should make sure
the docs somehow reflect this caveat, as I imagine it may surprise
future Guile users which happen to use its R6RS support and pipes in
combination.

Regards, Rotty





bug#39361: continuation and gc performance

2020-03-22 Thread Ludovic Courtès
Hi,

Stefan Israelsson Tampe  skribis:

> That function marks the working stack no, what about stack segments in
> continuations will they be marked correctly as well?

Oh you’re right, from a quick look at continuations.c, a continuation’s
stack appears to be conservatively scanned (allocated with
‘scm_gc_malloc’).

My intuition is that it’s “good enough” in most cases, but could affect
GC performance a tiny bit in continuation-heavy code, such as Fibers.

Ludo’.





bug#29001: git patch

2020-03-22 Thread Ludovic Courtès
Hi Matt,

Matt Wette  skribis:

>>From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001
> From: Matt Wette 
> Date: Sun, 22 Mar 2020 09:12:37 -0700
> Subject: [PATCH] 2020-03-22 Matt Wette 
>
> * configure.ac:
> Provide new option: --disable-tmpnam
> This is made available for installations that don't want to allow
> the insecure POSIX tmpname function.  Use mkstemp! instead.
>
> * libguile/posix.c
> tmpnam is deprecated; and enabled by ENABLE_TMPNAM

I tweaked the commit log and pushed.  Thank you!

Ludo’.





bug#29001: git patch

2020-03-22 Thread Matt Wette

Attached is the git patch against the following guile commit:

bef5e0b3938cc88e3a1a1ac590b009875cc38162



>From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001
From: Matt Wette 
Date: Sun, 22 Mar 2020 09:12:37 -0700
Subject: [PATCH] 2020-03-22 Matt Wette 

* configure.ac:
Provide new option: --disable-tmpnam
This is made available for installations that don't want to allow
the insecure POSIX tmpname function.  Use mkstemp! instead.

* libguile/posix.c
tmpnam is deprecated; and enabled by ENABLE_TMPNAM
---
 configure.ac |  8 
 libguile/posix.c | 11 +++
 2 files changed, 19 insertions(+)

diff --git a/configure.ac b/configure.ac
index 6198c7e..3e96094 100644
--- a/configure.ac
+++ b/configure.ac
@@ -166,6 +166,10 @@ AC_ARG_ENABLE(regex,
   [  --disable-regex omit regular expression interfaces],,
   enable_regex=yes)
 
+AC_ARG_ENABLE(tmpnam,
+  AS_HELP_STRING([--disable-tmpnam],[omit POSIX tmpnam]),,
+  enable_tmpnam=yes)
+
 AC_ARG_ENABLE([deprecated],
   AS_HELP_STRING([--disable-deprecated],[omit deprecated features]))
 
@@ -909,6 +913,10 @@ if test "$enable_regex" = yes; then
AC_DEFINE([ENABLE_REGEX], 1, [Define when regex support is enabled.])
 fi
 
+if test "$enable_tmpnam" = yes; then
+   AC_DEFINE([ENABLE_TMPNAM], 1, [Define when tmpnam support is enabled.])
+fi
+
 AC_REPLACE_FUNCS([strerror memmove])
 
 # Reasons for testing:
diff --git a/libguile/posix.c b/libguile/posix.c
index a1520ab..9b9b476 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -87,6 +87,10 @@
 #include "vectors.h"
 #include "version.h"
 
+#if (SCM_ENABLE_DEPRECATED == 1)
+#include "deprecation.h"
+#endif
+
 #include "posix.h"
 
 #if HAVE_SYS_WAIT_H
@@ -1588,6 +1592,8 @@ SCM_DEFINE (scm_environ, "environ", 0, 1, 0,
 }
 #undef FUNC_NAME
 
+#if (SCM_ENABLE_DEPRECATED == 1)
+#ifdef ENABLE_TMPNAM
 #ifdef L_tmpnam
 
 SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0,
@@ -1602,6 +1608,9 @@ SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0,
   char name[L_tmpnam];
   char *rv;
 
+  scm_c_issue_deprecation_warning
+  ("Use of tmpnam is deprecated.  Use mkstemp! instead.");
+
   SCM_SYSCALL (rv = tmpnam (name));
   if (rv == NULL)
 /* not SCM_SYSERROR since errno probably not set.  */
@@ -1610,6 +1619,8 @@ SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0,
 }
 #undef FUNC_NAME
 
+#endif
+#endif
 #endif
 
 SCM_DEFINE (scm_tmpfile, "tmpfile", 0, 0, 0,
-- 
2.17.1