Re: Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

> From: Andy Moreton 
> Date: Sat, 16 Jul 2016 22:40:38 +0100
> 
> On Sat 16 Jul 2016, Eli Zaretskii wrote:
> 
> > The processors and OS versions of the emulated 'uname' need an update;
> > the patch below does that:
> 
> This uses GetVersionEx, which does not tell the truth on versions after
> Windows 8 unless the application contains a manifest (see online
> documentation for GetVersionEx at MSDN for details).

Right.

> Does the Mingw toolchain supply a suitable manifest automatically ?

No.  The manifest should be provided with Guile.

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Sat, 16 Jul 2016 17:34:02 -0300
> From: David Pirotte 
> Cc: guile-devel@gnu.org
> 
>   nice to see progress on MinGW, congrat!

Thanks.

> > > * configure.ac: Adding a copyright; bumping prereq -> 2.69  
> 
> > Why is that a good idea?
> 
> Why not? 
> 2.69 is the latest stable, available since April 2012
> 
> >  Are there any features Guile needs that older versions don't support?
> 
> It is not a just question of feature, but about running the same version [or 
> higher]
> then the one used to check, distcheck... Why would we want to even try to 
> support any
> previous version but the latest stable here?

Because people might have older versions installed, and it's a
nuisance to have to upgrade unrelated tools in your development
environment just because you need to build a newer version of Guile.
Besides, other packages might required older versions.

> Autotool chain related issue/bugs can be very tedious to track down and 
> solve, and
> requiring users to install the latest stable versions, guarantee they won't 
> have any
> surprise on that side, and saves us precious time, we have other things to do.

If there are known problems with older versions that get in the way, I
agree.  Are there?

If there are no known problems that interfere with maintaining Guile,
I think refraining from the above will be nicer to our users.

Re: Update 'uname' emulation on MS-Windows

[Andy Moreton]

On Sat 16 Jul 2016, Eli Zaretskii wrote:

> The processors and OS versions of the emulated 'uname' need an update;
> the patch below does that:

This uses GetVersionEx, which does not tell the truth on versions after
Windows 8 unless the application contains a manifest (see online
documentation for GetVersionEx at MSDN for details).

Does the Mingw toolchain supply a suitable manifest automatically ?

AndyM

Re: guile-lib - devel branch - patch 4 of 11

[David Pirotte]

Hi Eli,

nice to see progress on MinGW, congrat!

> > * configure.ac: Adding a copyright; bumping prereq -> 2.69  

> Why is that a good idea?

Why not? 
2.69 is the latest stable, available since April 2012

>  Are there any features Guile needs that older versions don't support?

It is not a just question of feature, but about running the same version [or 
higher]
then the one used to check, distcheck... Why would we want to even try to 
support any
previous version but the latest stable here?

I don't.

Autotool chain related issue/bugs can be very tedious to track down and solve, 
and
requiring users to install the latest stable versions, guarantee they won't 
have any
surprise on that side, and saves us precious time, we have other things to do.

IMO, it is the right thing to do.

Cheers,
David


pgpTaOlSn5hRL.pgp
Description: OpenPGP digital signature

Avoid warnings in sockets.c when HAVE_SIN6_SCOPE_ID is unavailable

[Eli Zaretskii]

CC   libguile_2.0_la-socket.lo
  socket.c: In function 'scm_fill_sockaddr':
  socket.c:747:16: warning: variable 'scope_id' set but not used 
[-Wunused-but-set-variable]
unsigned long scope_id = 0;
  ^

The patch to avoid this warning is below.  OK to commit?

--- libguile/socket.c~0 2016-01-02 16:24:55.0 +0200
+++ libguile/socket.c   2016-07-15 19:17:40.02325 +0300
@@ -744,7 +744,9 @@ scm_fill_sockaddr (int fam, SCM address,
int port;
struct sockaddr_in6 *soka;
unsigned long flowinfo = 0;
+#ifdef HAVE_SIN6_SCOPE_ID
unsigned long scope_id = 0;
+#endif
 
SCM_VALIDATE_CONS (which_arg + 1, *args);
port = scm_to_int (SCM_CAR (*args));
@@ -755,8 +757,10 @@ scm_fill_sockaddr (int fam, SCM address,
*args = SCM_CDR (*args);
if (scm_is_pair (*args))
  {
+#ifdef HAVE_SIN6_SCOPE_ID
SCM_VALIDATE_ULONG_COPY (which_arg + 3, SCM_CAR (*args),
 scope_id);
+#endif
*args = SCM_CDR (*args);
  }
  }

Avoid warning about alloca in read.c

[Eli Zaretskii]

   CC   libguile_2.0_la-read.lo
 read.c: In function 'try_read_ci_chars':
 read.c:983:3: warning: implicit declaration of function 'alloca' 
[-Wimplicit-function-declaration]
 read.c:983:22: warning: incompatible implicit declaration of built-in 
function 'alloca' [enabled by default]

The patch to avoid this warning is below.  OK to commit?

--- libguile/read.c~0   2016-01-02 16:24:55.0 +0200
+++ libguile/read.c 2016-07-15 12:38:42.195125000 +0300
@@ -33,6 +33,10 @@
 #include 
 #include 
 
+#ifdef __MINGW32__
+#include 
+#endif
+
 #include "libguile/_scm.h"
 #include "libguile/bytevectors.h"
 #include "libguile/chars.h"

Avoid warnings in threads.c when building without threads

[Eli Zaretskii]

 CC   libguile_2.0_la-threads.lo
   In file included from ../libguile/threads.h:40:0,
from ../libguile/gc.h:30,
from ../libguile/_scm.h:76,
from threads.c:28:
   threads.c: In function 'scm_call_with_new_thread':
   ../libguile/null-threads.h:74:53: warning: right-hand operand of comma 
expression has no effect [-Wunused-value]
#define scm_i_pthread_cond_wait(c,m)(abort(), 0)
^
   ../libguile/null-threads.h:102:45: note: in expansion of macro 
'scm_i_pthread_cond_wait'
#define scm_i_scm_pthread_cond_wait scm_i_pthread_cond_wait
^
   threads.c:1061:5: note: in expansion of macro 'scm_i_scm_pthread_cond_wait'
scm_i_scm_pthread_cond_wait (, );
^

The patch to shut up these warnings is below.  OK to commit?

--- libguile/null-threads.h~0   2016-01-02 13:32:40.0 +0200
+++ libguile/null-threads.h 2016-07-15 17:47:37.101375000 +0300
@@ -43,7 +43,7 @@
 #define scm_i_pthread_create(t,a,f,d)   (*(t)=0, (void)(f), ENOSYS)
 #define scm_i_pthread_detach(t) do { } while (0)
 #define scm_i_pthread_exit(v)   exit (EXIT_SUCCESS)
-#define scm_i_pthread_cancel(t) 0
+#define scm_i_pthread_cancel(t) (void)0
 #define scm_i_pthread_cleanup_push(t,v) 0
 #define scm_i_pthread_cleanup_pop(e)0
 #define scm_i_sched_yield() 0


--- libguile/threads.c~ 2016-06-20 23:35:06.0 +0300
+++ libguile/threads.c  2016-07-15 17:48:20.757625000 +0300
@@ -1058,7 +1058,7 @@ SCM_DEFINE (scm_call_with_new_thread, "c
 }
 
   while (scm_is_false (data.thread))
-scm_i_scm_pthread_cond_wait (, );
+(void)scm_i_scm_pthread_cond_wait (, );
 
   scm_i_pthread_mutex_unlock ();
 
@@ -1138,7 +1138,7 @@ scm_spawn_thread (scm_t_catch_body body,
 }
 
   while (scm_is_false (data.thread))
-scm_i_scm_pthread_cond_wait (, );
+(void)scm_i_scm_pthread_cond_wait (, );
 
   scm_i_pthread_mutex_unlock ();
 

Re: MinGW open-process, take N

[Eli Zaretskii]

> Date: Sat, 16 Jul 2016 16:24:46 +0300
> From: Eli Zaretskii 
> Cc: m...@netris.org, l...@gnu.org, guile-devel@gnu.org
> 
> Is it okay to push what I have now, and remove all the tabs from
> posix-w32.c (not just those I added) in a follow-up commit?

Never mind, I just did that.

Thanks.

Re: MinGW-related patches that were reported in 2014 but not applied

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 15:39:23 +0200
> 
> I think the right thing here is to use the mkostemp gnulib module
> instead and pass O_BINARY in the flags.  I have made this change in
> git; please let me know if it causes problems for you.

I'm sure it will DTRT, but it's hard for me to test such changes out
of Git.

Thanks.

Re: MinGW-related patches that were reported in 2014 but not applied

[Andy Wingo]

On Sat 16 Jul 2016 13:24, Eli Zaretskii  writes:

> diff --git a/libguile/filesys.c b/libguile/filesys.c
> index 48232e8..c47c2f4 100644
> --- a/libguile/filesys.c
> +++ b/libguile/filesys.c
> @@ -1472,6 +1472,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0,
>SCM_SYSCALL (rv = mkstemp (c_tmpl));
>if (rv == -1)
>  SCM_SYSERROR;
> +#ifdef __MINGW32__
> +  /* Files created by this function are used for *.go files, so make
> + sure they use binary I/O, or else the produced *.go files will be
> + corrupted by end-of-line conversion and ^Z "software EOF"
> + misfeature.  Gnulib's 'mkstemp' uses the default text mode to
> + open the file .  */
> +  _setmode (rv, _O_BINARY);
> +#endif

This function is used for other purposes as well.  I think the right
thing here is to use the mkostemp gnulib module instead and pass
O_BINARY in the flags.  I have made this change in git; please let me
know if it causes problems for you.

Andy

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: m...@netris.org,  l...@gnu.org,  guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 13:32:04 +0200
> 
> Patch looks good to me, feel free to push after fixing tab problems and
> adding the mutex.

I added the mutex.

Is it okay to push what I have now, and remove all the tabs from
posix-w32.c (not just those I added) in a follow-up commit?

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: m...@netris.org,  l...@gnu.org,  guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 13:32:04 +0200
> 
> On Sat 16 Jul 2016 12:54, Eli Zaretskii  writes:
> 
> > Here's the first cut.  (I will rework it into git-format-patch form,
> > or commit and push myself, whatever is more convenient for you, as
> > soon as it is okayed for upstream.)
> 
> Looks good to me.

Thanks.

> Please configure your editor to not introduce tabs though

Sorry, not going to happen.  That's the default GNU indentation style.

> and remove tabs introduced in this patch.

The file had an enormous amount of tabs before my changes and my
changes added maybe 2 or 3.  Does it make sense to remove only those
few?

> I would just use scm_i_misc_mutex in this case though.
> 
>   scm_i_scm_pthread_mutex_lock (_i_misc_mutex);
> 
>   /* do your thing */
> 
>   scm_i_pthread_mutex_unlock (_i_misc_mutex);

OK, will do.

> >  . Once a subprocess is launched, its record sits in the procs[] array
> >until deleted by waitpid, if it finds that the process has exited,
> >or by kill.  If neither waitpid nor kill are called, the process's
> >record will not be deleted, even though the process might be long
> >dead.  This means that we leak handles, and the system gets process
> >objects accumulated that it cannot recycle.  (This problem was
> >already present in the previous version of the code, it is not new
> >with the modified version.)  Can we be sure that a well-behaving
> >Guile program will always call one of these 2 functions?  If not,
> >how to prevent that in a well-behaving Guile program?  I guess at
> >least close-port should try killing the process (if it doesn't
> >already)?  Any other ideas?
> 
> This mirrors how POSIX works AFAIU.  Until you waitpid() on a child
> process, the PID isn't recycled, and the process exists in a "zombie"
> state.  So portable Guile programs will always waitpid() on processes
> they spawn.

Ah, good to know.

> Patch looks good to me, feel free to push after fixing tab problems and
> adding the mutex.

Will do, after we figure out the tricky tabs issue ;-)

Re: MinGW open-process, take N

[Andy Wingo]

On Sat 16 Jul 2016 12:54, Eli Zaretskii  writes:

> Here's the first cut.  (I will rework it into git-format-patch form,
> or commit and push myself, whatever is more convenient for you, as
> soon as it is okayed for upstream.)

Looks good to me.  Please configure your editor to not introduce tabs
though, and remove tabs introduced in this patch.

>  . Access to the procs[] array should be synchronized between
>threads.  (Currently, MinGW builds of Guile don't work at all
>unless built with --disable-threads, but AFAIR Mark wanted to have
>the code thread-safe anyway.)  I guess this entails taking some
>mutex before accessing the array, but I never wrote any such code
>in Guile, so I'd appreciate to be pointed to some example, or to
>have some boilerplate for that.

You can either use the scm_i_misc_mutex, or define your own.  If you
define your own you do:

  static scm_i_pthread_mutex_t process_table_lock = 
SCM_I_PTHREAD_MUTEX_INITIALIZER;

I would just use scm_i_misc_mutex in this case though.

  scm_i_scm_pthread_mutex_lock (_i_misc_mutex);

  /* do your thing */

  scm_i_pthread_mutex_unlock (_i_misc_mutex);

>  . Once a subprocess is launched, its record sits in the procs[] array
>until deleted by waitpid, if it finds that the process has exited,
>or by kill.  If neither waitpid nor kill are called, the process's
>record will not be deleted, even though the process might be long
>dead.  This means that we leak handles, and the system gets process
>objects accumulated that it cannot recycle.  (This problem was
>already present in the previous version of the code, it is not new
>with the modified version.)  Can we be sure that a well-behaving
>Guile program will always call one of these 2 functions?  If not,
>how to prevent that in a well-behaving Guile program?  I guess at
>least close-port should try killing the process (if it doesn't
>already)?  Any other ideas?

This mirrors how POSIX works AFAIU.  Until you waitpid() on a child
process, the PID isn't recycled, and the process exists in a "zombie"
state.  So portable Guile programs will always waitpid() on processes
they spawn.

Patch looks good to me, feel free to push after fixing tab problems and
adding the mutex.

Andy

Re: MinGW-related patches that were reported in 2014 but not applied

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:33:56 +0200
> 
> > Can these please be applied?
> 
> Sure let's work on it.  Would you mind submitting these again, making
> sure they apply cleanly to stable-2.0?

3 patches against the current stable-2.0 are attached.

>From 8a1e4631fc2dddf5ca63039b4a77ae0d33d3cb90 Mon Sep 17 00:00:00 2001
From: Eli Zaretskii 
Date: Sat, 16 Jul 2016 14:17:25 +0300
Subject: [PATCH] Open temporary files in binary mode on MS-Windows

* libguile/filesys.c (scm_mkstemp) [__MINGW32__]: Make sure the
temporary file is open in binary mode.
---
 libguile/filesys.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libguile/filesys.c b/libguile/filesys.c
index 48232e8..c47c2f4 100644
--- a/libguile/filesys.c
+++ b/libguile/filesys.c
@@ -1472,6 +1472,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0,
   SCM_SYSCALL (rv = mkstemp (c_tmpl));
   if (rv == -1)
 SCM_SYSERROR;
+#ifdef __MINGW32__
+  /* Files created by this function are used for *.go files, so make
+ sure they use binary I/O, or else the produced *.go files will be
+ corrupted by end-of-line conversion and ^Z "software EOF"
+ misfeature.  Gnulib's 'mkstemp' uses the default text mode to
+ open the file .  */
+  _setmode (rv, _O_BINARY);
+#endif
 
   scm_substring_move_x (scm_from_locale_string (c_tmpl),
 			SCM_INUM0, scm_string_length (tmpl),
-- 
2.9.0.windows.1

>From f598db99c0da4aefce0b393f52a4da8f0c4c055e Mon Sep 17 00:00:00 2001
From: Eli Zaretskii 
Date: Sat, 16 Jul 2016 14:20:23 +0300
Subject: [PATCH] Fix 'dirname' and 'basename' on MS-Windows

* libguile/filesys.c (is_drive_letter): New helper function.
(scm_dirname, scm_basename): Use it.  Don't assume the leading
slash is always at the beginning of the file name.  Support UNC
file names on MS-Windows.
---
 libguile/filesys.c | 87 +++---
 1 file changed, 76 insertions(+), 11 deletions(-)

diff --git a/libguile/filesys.c b/libguile/filesys.c
index c47c2f4..55df768 100644
--- a/libguile/filesys.c
+++ b/libguile/filesys.c
@@ -449,6 +449,18 @@ is_file_name_separator (SCM c)
   return 0;
 }
 
+static int
+is_drive_letter (SCM c)
+{
+#ifdef __MINGW32__
+  if (SCM_CHAR (c) >= 'a' && SCM_CHAR (c) <= 'z')
+return 1;
+  else if (SCM_CHAR (c) >= 'A' && SCM_CHAR (c) <= 'Z')
+return 1;
+#endif
+  return 0;
+}
+
 SCM_DEFINE (scm_stat, "stat", 1, 1, 0, 
 (SCM object, SCM exception_on_error),
 	"Return an object containing various information about the file\n"
@@ -1522,24 +1534,60 @@ SCM_DEFINE (scm_dirname, "dirname", 1, 0, 0,
 {
   long int i;
   unsigned long int len;
+  /* Length of prefix before the top-level slash.  Always zero on
+ Posix hosts, but may be non-zero on Windows.  */
+  long prefix_len = 0;
+  int is_unc = 0;
+  unsigned long unc_end = 0;
 
   SCM_VALIDATE_STRING (1, filename);
 
   len = scm_i_string_length (filename);
+  if (len >= 2
+  && is_drive_letter (scm_c_string_ref (filename, 0))
+  && scm_is_eq (scm_c_string_ref (filename, 1), SCM_MAKE_CHAR (':')))
+{
+  prefix_len = 1;
+  if (len > 2 && is_file_name_separator (scm_c_string_ref (filename, 2)))
+	prefix_len++;
+}
+#ifdef __MINGW32__
+  if (len > 1
+  && is_file_name_separator (scm_c_string_ref (filename, 0))
+  && is_file_name_separator (scm_c_string_ref (filename, 1)))
+{
+  is_unc = 1;
+  prefix_len = 1;
+}
+#endif
 
   i = len - 1;
 
-  while (i >= 0 && is_file_name_separator (scm_c_string_ref (filename, i)))
+  while (i >= prefix_len
+	 && is_file_name_separator (scm_c_string_ref (filename, i)))
 --i;
-  while (i >= 0 && !is_file_name_separator (scm_c_string_ref (filename, i)))
+  if (is_unc)
+unc_end = i + 1;
+  while (i >= prefix_len
+	 && !is_file_name_separator (scm_c_string_ref (filename, i)))
 --i;
-  while (i >= 0 && is_file_name_separator (scm_c_string_ref (filename, i)))
+  while (i >= prefix_len
+	 && is_file_name_separator (scm_c_string_ref (filename, i)))
 --i;
 
-  if (i < 0)
+  if (i < prefix_len)
 {
-  if (len > 0 && is_file_name_separator (scm_c_string_ref (filename, 0)))
-	return scm_c_substring (filename, 0, 1);
+  if (is_unc)
+	return scm_c_substring (filename, 0, unc_end);
+  else if (len > prefix_len
+	  && is_file_name_separator (scm_c_string_ref (filename, prefix_len)))
+	return scm_c_substring (filename, 0, prefix_len + 1);
+#ifdef __MINGW32__
+  else if (len > prefix_len
+	   && scm_is_eq (scm_c_string_ref (filename, 1),
+			 SCM_MAKE_CHAR (':')))
+	return scm_c_substring (filename, 0, prefix_len + 1);
+#endif
   else
 	return scm_dot_string;
 }
@@ -1557,6 +1605,9 @@ SCM_DEFINE (scm_basename, "basename", 1, 1, 0,
 #define FUNC_NAME s_scm_basename
 {
   int i, j, len, end;
+  /* Length of prefix before the top-level slash.  Always zero on
+ Posix hosts, but may be non-zero on Windows.  */
+  long 

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: m...@netris.org,  l...@gnu.org,  guile-devel@gnu.org
> Date: Thu, 14 Jul 2016 23:31:31 +0200
> 
> > I see your point, and I think I can fix this, together with the pid_t
> > width issue in 64-bit build, if I introduce an array private to
> > posix-w32.c that will hold the PIDs of all processes known to Guile
> > for which waitpid did not yet return an exit code, and their
> > corresponding process handles.  Then we can return an int to Scheme,
> > and the w32 functions will get hold of the handle by looking up the
> > PID in that array.
> >
> > How's that sound?  If you agree, I can work on this tomorrow.
> 
> That actually sounds really nice!  That way the PID-using functions will
> all see proper PIDS and we also get the waitpid() behavior.
> 
> I would be happy to apply such a patch.  Thank you :-)

Here's the first cut.  (I will rework it into git-format-patch form,
or commit and push myself, whatever is more convenient for you, as
soon as it is okayed for upstream.)

There are two more issues which I need help/guidance to resolve:

 . Access to the procs[] array should be synchronized between
   threads.  (Currently, MinGW builds of Guile don't work at all
   unless built with --disable-threads, but AFAIR Mark wanted to have
   the code thread-safe anyway.)  I guess this entails taking some
   mutex before accessing the array, but I never wrote any such code
   in Guile, so I'd appreciate to be pointed to some example, or to
   have some boilerplate for that.

 . Once a subprocess is launched, its record sits in the procs[] array
   until deleted by waitpid, if it finds that the process has exited,
   or by kill.  If neither waitpid nor kill are called, the process's
   record will not be deleted, even though the process might be long
   dead.  This means that we leak handles, and the system gets process
   objects accumulated that it cannot recycle.  (This problem was
   already present in the previous version of the code, it is not new
   with the modified version.)  Can we be sure that a well-behaving
   Guile program will always call one of these 2 functions?  If not,
   how to prevent that in a well-behaving Guile program?  I guess at
   least close-port should try killing the process (if it doesn't
   already)?  Any other ideas?

Thanks.

Here's the patch:

2016-07-16  Eli Zaretskii  

* libguile/posix-w32.c (uname): Update to modern processors (ia64
and x86_64) and OS versions (Vista to Windows 10).  Delete
trailing whitespace.
(proc_record): New structure tag.
: New static variables.
(find_proc, proc_handle, record_proc, delete_proc): New utility
functions.
(start_child): Return value is now pid_t, as it is on Posix
platforms.  Record the new process and returns its PID, instead of
returning a handle.
(waitpid, kill, getpriority, setpriority, sched_getaffinity)
(sched_setaffinity): Look up the PID in the recorded subprocesses
before trying to open a process that is not our subprocess.  Make
sure any open handle is closed before returning, unless it's our
subprocess.

--- libguile/posix-w32.c~2  2016-07-16 10:22:08.27325 +0300
+++ libguile/posix-w32.c2016-07-16 13:18:51.163875000 +0300
@@ -173,6 +173,80 @@ uname (struct utsname *uts)
   return 0;
 }
 
+/* Utility functions for maintaining the list of subprocesses launched
+   by Guile.  */
+
+struct proc_record {
+  DWORD pid;
+  HANDLE handle;
+};
+
+static struct proc_record *procs;
+static ptrdiff_t proc_size;
+
+/* Find the process slot that corresponds to PID.  Return the index of
+   the slot, or -1 if not found.  */
+static ptrdiff_t
+find_proc (pid_t pid)
+{
+  ptrdiff_t found = -1, i;
+
+  for (i = 0; i < proc_size; i++)
+{
+  if (procs[i].pid == pid && procs[i].handle != INVALID_HANDLE_VALUE)
+   found = i;
+}
+
+  return found;
+}
+
+/* Return the process handle corresponding to its PID.  If not found,
+   return invalid handle value.  */
+static HANDLE
+proc_handle (pid_t pid)
+{
+  ptrdiff_t idx = find_proc (pid);
+
+  if (idx < 0)
+return INVALID_HANDLE_VALUE;
+  return procs[idx].handle;
+}
+
+/* Store a process record in the procs[] array.  */
+static void
+record_proc (pid_t proc_pid, HANDLE proc_handle)
+{
+  ptrdiff_t i;
+
+  /* Find a vacant slot.  */
+  for (i = 0; i < proc_size; i++)
+{
+  if (procs[i].handle == INVALID_HANDLE_VALUE)
+   break;
+}
+
+  /* If no vacant slot, enlarge the array.  */
+  if (i == proc_size)
+{
+  proc_size++;
+  procs = scm_realloc (procs, proc_size * sizeof(procs[0]));
+}
+
+  /* Store the process data.  */
+  procs[i].pid = proc_pid;
+  procs[i].handle = proc_handle;
+}
+
+/* Delete a process record for process PID.  */
+static void
+delete_proc (pid_t pid)
+{
+  ptrdiff_t idx = find_proc (pid);
+
+  if (0 <= idx && idx < proc_size)

Re: [PATCH] Re: Patchset related to array functions

[Chris Vine]

On Sat, 16 Jul 2016 11:07:40 +0200
Andy Wingo  wrote:
[snip]
> I would like stdint.h though :)

I agree.  stdint.h is required by C++11, Appendix D5, to be available
in C++11 and later, with the same meaning as in C99, but in practice it
was available before then.  It is provided by gcc-4.4 with the
-std=c++0x or -std=c99 flags for example (gcc-4.4 is the oldest compiler
I have installed, which I keep for test purposes).

I think it is reasonable to assume these days that any reasonable
compiler implementation will have the C99 extended integer types
available to it, including the optional ones so far as the architecture
supports them.

Chris

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: Mark H Weaver ,  guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 11:06:06 +0200
> 
> Any incompatible change between 2.0.12 and a previous release in the
> 2.0.x series is a bug.  It is impossible to make a list of all bugs in a
> project of course :)
> 
> I do not know of any incompatibility introduced in 2.0.12.

Thanks, that's good to hear.

Re: Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:58:39 +0200
> 
> On Sat 16 Jul 2016 09:27, Eli Zaretskii  writes:
> 
> > 2016-07-16  Eli Zaretskii  
> >
> > * libguile/posix-w32.c (uname): Update to modern processors (ia64
> > and x86_64) and OS versions (Vista to Windows 10).  Delete
> > trailing whitespace.
> 
> Applied, thanks.

Thanks.

> I will do what I can to apply patches that aren't in
> git-format-patch format, but I note that using git-format-patch
> makes it more likely that they go upstream.

Noted.  (The reason I didn't use git-format-patch is that the diffs
were generated relative to 2.0.12 in its source tree, so I didn't have
a commit to use in the first place.)

AFAIK, I have write access to the Guile repository, so if it's more
convenient, once I have the approval, I can apply the patch and push
it myself.

Re: Compilation warnings in net_db.c

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:53:37 +0200
> 
> >net_db.c:454:20: warning: 'sym_ai_passive' defined but not used 
> > [-Wunused-variable]
> > SCM_VARIABLE_INIT (sym_ai_passive, "AI_PASSIVE",
> >^
> >../libguile/snarf.h:82:29: note: in definition of macro 'SCM_SNARF_HERE'
> > #  define SCM_SNARF_HERE(X) X
> > ^
> >net_db.c:454:1: note: in expansion of macro 'SCM_VARIABLE_INIT'
> > SCM_VARIABLE_INIT (sym_ai_passive, "AI_PASSIVE",
> > ^
> >
> > AFAICT, these SCM_VARIABLE_INIT calls wind up declaring static
> > variables that are not used in net_db.c.  Is that what's supposed to
> > happen, or do I need to look more into this?  Do people get these
> > warnings on Posix platforms?
> 
> Oddly I don't get these warnings, but perhaps I should.

Which version of GCC do you use?  I have 5.3.0 here, and its quite
picky, given the warning options we use.

> I reworked this file to not create these variables.  Thanks for the
> report :)

Thanks.

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 04:39:24 -0400
> 
> > It make sense if it indeed works in practice.
> 
> As I wrote in my previous message, it does indeed seem to work in
> practice, based on the lack of bug reports indicating otherwise.  If you
> have evidence to the contrary, please bring it to our attention.
> 
> > Is it possible to publish the list of ABI incompatibilities between
> > 2.0.11 and 2.0.12 specifically?
> 
> I'm not aware of any.

Great, this means the problem doesn't exist.  Thanks.

Re: [PATCH] Re: Patchset related to array functions

[Andy Wingo]

On Fri 15 Jul 2016 12:52, Chris Vine  writes:

> On Thu, 14 Jul 2016 17:41:45 +0200
> Daniel Llorens  wrote:
> [snip]
>> I think we'd want C89/C90 users to still be able to #include
>> . Dunno.
>
> libguile.h can also at present be included in C++89/03/11/14 code by
> design - all the necessary "extern C" stuff is there.  I would hope
> that would continue, but some C99 things, such as variable length
> arrays, designated initializers, the _Complex type, the restrict
> qualifier and compound literals (except in C++11/14) are not available.
>
> There is no problem with using these in libguile implementation
> (*.c) code, but including them in headers will generally stop the
> headers being usable in C++ code.  Having said that, g++ happens to
> accept some of these in C++ code as an extension.

Good points, all.  Thanks for this list Chris.  I don't think we need
anything in your list at present.  I would like stdint.h though :)

Andy

Re: Guile's DATAROOTDIR and DATADIR

[Andy Wingo]

On Fri 15 Jul 2016 19:46, Eli Zaretskii  writes:

> Is it possible to publish the list of ABI incompatibilities between
> 2.0.11 and 2.0.12 specifically?

Any incompatible change between 2.0.12 and a previous release in the
2.0.x series is a bug.  It is impossible to make a list of all bugs in a
project of course :)

I do not know of any incompatibility introduced in 2.0.12.

Andy

Re: [PATCH] doc: Do not gender the programmer.

[Andy Wingo]

On Fri 15 Jul 2016 09:41, Ricardo Wurmus  writes:

> * doc/ref/api-foreign.texi: Replace "his" with "their".
> * doc/ref/sxml.texi: Likewise.

Applied, thanks.

Andy

Re: Update 'uname' emulation on MS-Windows

[Andy Wingo]

On Sat 16 Jul 2016 09:27, Eli Zaretskii  writes:

> 2016-07-16  Eli Zaretskii  
>
>   * libguile/posix-w32.c (uname): Update to modern processors (ia64
>   and x86_64) and OS versions (Vista to Windows 10).  Delete
>   trailing whitespace.

Applied, thanks.  I will do what I can to apply patches that aren't in
git-format-patch format, but I note that using git-format-patch makes it
more likely that they go upstream.  Cheers :)

Andy

Re: Do-loop enigma with two variables

[Taylan Ulrich Bayırlı/Kammer]

Pierre Lairez  writes:

> Dear guile users,
>
> When running the following loop:
> (do ((i 1 (+ 1 i))
>  (j 0 i))
> ((> i 4) (newline))
>   (display (list i j)))
>
> I expect without hesitation to read
> (1 0)(2 1)(3 2)(4 3)
>
> To my surprise, I obtain
> (1 0)(2 2)(3 3)(4 4)
>
> After macro-expansion, the loop above is rewritten in the following:
> (letrec ((loop
>   (λ (i j)
> (if (> i 4)
> (newline)
> (begin
>   (display (list i j))
>   (loop (+ 1 i) i))
>   (loop 1 0))
>
> The equality j = i + 1 is clearly a loop invariant, the function “loop“
> is *never* called with two equal arguments. So I cannot understand why
> (2 2) may possibly appear in the output. What do I not see?
>
> Best regards,
>
> Pierre

I suspect this is a bug in the optimizer; guile-devel CC'd.

Using 2.0.11 (gotta upgrade!):

scheme@(guile-user)> ,expand (do ((i 1 (+ 1 i))
  (j 0 i))
 ((> i 4) (newline))
   (display (list i j)))
$5 = (let loop ((i 1) (j 0))
  (if (> i 4)
(begin (if #f #f) (newline))
(begin (display (list i j)) (loop (+ 1 i) i

;; Looks good to me.  Let's use the interpreter on it:

scheme@(guile-user)> (eval '(let loop ((i 1) (j 0))
  (if (> i 4)
  (begin (if #f #f) (newline))
  (begin (display (list i j)) (loop (+ 1 i) 
i
   ((@ (rnrs eval) environment) '(guile)))
(1 0)(2 1)(3 2)(4 3)

;; Looks good to me as well.  Now the compiler's optimizer:

scheme@(guile-user)> ,optimize (let loop ((i 1) (j 0))
 (if (> i 4)
 (begin (if #f #f) (newline))
 (begin (display (list i j)) (loop (+ 1 i) 
i
$6 = (begin
  (display (list 1 0))
  (begin
(display (list 2 2))
(begin
  (display (list 3 3))
  (begin (display (list 4 4)) (newline)

;; Beep!

(Note that the Guile REPL compiles the given expressions by default.)

Taylan

Re: Compilation warnings in net_db.c

[Andy Wingo]

Hi,

On Fri 15 Jul 2016 21:23, Eli Zaretskii  writes:

> While compiling net_db.c from Guile 2.0.12 with MinGW, I get a bunch
> of warnings such as this one:
>
>net_db.c:454:20: warning: 'sym_ai_passive' defined but not used 
> [-Wunused-variable]
> SCM_VARIABLE_INIT (sym_ai_passive, "AI_PASSIVE",
>  ^
>../libguile/snarf.h:82:29: note: in definition of macro 'SCM_SNARF_HERE'
> #  define SCM_SNARF_HERE(X) X
>   ^
>net_db.c:454:1: note: in expansion of macro 'SCM_VARIABLE_INIT'
> SCM_VARIABLE_INIT (sym_ai_passive, "AI_PASSIVE",
> ^
>
> AFAICT, these SCM_VARIABLE_INIT calls wind up declaring static
> variables that are not used in net_db.c.  Is that what's supposed to
> happen, or do I need to look more into this?  Do people get these
> warnings on Posix platforms?

Oddly I don't get these warnings, but perhaps I should.  I reworked this
file to not create these variables.  Thanks for the report :)

Andy

Re: Guile's DATAROOTDIR and DATADIR

[Mark H Weaver]

Eli Zaretskii  writes:

>> From: Mark H Weaver 
>> Cc: guile-devel@gnu.org
>> Date: Fri, 15 Jul 2016 13:25:46 -0400
>> 
>> Having said this, I will admit that we've not maintained perfect ABI
>> compatibility within 2.0.x, e.g. we've removed some obscure interfaces
>> that were intended to be kept private, or were broken and could not be
>> easily fixed, and that we believed to be unused in practice.

Sorry, my statement above was in error.  It was based on a false claim
made by David Kastrup here:

  http://article.gmane.org/gmane.emacs.devel/174438

He wrote that our NEWS file "lists plenty of things that have been
_removed_ during the stable-2.0 branch, breaking existing uses", but the
examples he cited were *deprecations*, not removals.  Existing uses
continue to work throughout the 2.0.x series.

I spent some time searching our NEWS file for examples of *actual* ABI
breakage in 2.0.x, and I didn't find anything.

>> In any case, to the extent that there's a problem here, the solution is
>> to redouble our efforts to avoid ABI breakage.  The solution is most
>> definitely *not* to have separate directories for every maintenance
>> release.  The reason is that we want existing Guile programs compiled
>> against 2.0.11 to benefit from the bug fixes in 2.0.12.
>> 
>> Does that make sense?
>
> It make sense if it indeed works in practice.

As I wrote in my previous message, it does indeed seem to work in
practice, based on the lack of bug reports indicating otherwise.  If you
have evidence to the contrary, please bring it to our attention.

> Is it possible to publish the list of ABI incompatibilities between
> 2.0.11 and 2.0.12 specifically?

I'm not aware of any.

 Mark

Re: configure.ac needs a change for MinGW

[Andy Wingo]

On Fri 15 Jul 2016 21:10, Eli Zaretskii  writes:

> win32-uname.[ch] were renamed in Guile 2.0.12, but configure.ac still
> references them:
>
>   case $host in
> *-*-mingw*)
>   AC_CHECK_HEADER(winsock2.h, [AC_DEFINE([HAVE_WINSOCK2_H], 1,
>   [Define if you have the  header file.])])
>   AC_CHECK_LIB(ws2_32, main)
>   AC_LIBOBJ([win32-uname])  <
>
> This causes a fatal error during the build with MinGW.

Fixed, thanks.

If you don't mind, it's sufficient to just mail guile-devel; please
leave me out of the "To" field for new threads.  Cheers :)

Andy

Re: MinGW-related patches that were reported in 2014 but not applied

[Andy Wingo]

Hi,

On Fri 15 Jul 2016 21:04, Eli Zaretskii  writes:

> I built Guile 2.0.12 today with MinGW, and to my chagrin found that
> some of the patches I sent long ago are still not in the repository.
>
> Below please find the list of those patches.
>
> The stime.c patch in this message was not applied, although it causes
> failures in time.test (explained in the message):
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-06/msg00012.html
>
> The issues with dirname and basename, for which I posted a patch here:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-07/msg00012.html
>
> were subsequently discussed, but the code was not changed, AFAICT.
>
> This patch is needed, because without it Guile will write corrupted
> *.go files:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00052.html
>
> Can these please be applied?

Sure let's work on it.  Would you mind submitting these again, making
sure they apply cleanly to stable-2.0?

Thanks,

Andy

Re: Patchset related to array functions

[Andy Wingo]

On Fri 15 Jul 2016 19:41, Mark H Weaver  writes:

> Andy Wingo  writes:
>
>>   (2) Can we use C99 in our public interface, or just internally?  If we
>>   use it publically, what should we change?  No more scm_t_uint8 I
>>   hope, besides for back-compat?  This patch set does not have to
>>   include these changes, but we should have a plan.
>
> Good question!  Since Emacs 25 requires C99, I think it's reasonable for
> us to also require C99 *internally*, but whether we can reasonably
> assume C99 in our public headers is far less clear.  Existing programs
> that include  might have conflicting requirements for the C
> dialect options passed to the compiler.  Even if there's no conflict,
> developers may resent being asked to change their C dialect options.
>
> Thoughts?

Yeah I dunno :)  I suppose requiring stdint.h would be possible though
without requiring support for new language features.  So that's an
intermediate point.

Since building against Guile 2.2 is an opt-in thing (with parallel
installation and all), I think at some point it's reasonable to say "you
can stay with Guile 2.0, but if you upgrade you need to support a C
standard released within the last 20 years" :)  That point may be now;
not sure.

Andy

Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

The processors and OS versions of the emulated 'uname' need an update;
the patch below does that:

2016-07-16  Eli Zaretskii  

* libguile/posix-w32.c (uname): Update to modern processors (ia64
and x86_64) and OS versions (Vista to Windows 10).  Delete
trailing whitespace.

--- libguile/posix-w32.c~1  2016-07-15 19:18:26.83575 +0300
+++ libguile/posix-w32.c2016-07-16 10:22:08.27325 +0300
@@ -64,13 +64,26 @@ uname (struct utsname *uts)
 strcpy (uts->sysname, "Windows NT3x"); /* NT3x */
   else if (osver.dwMajorVersion == 5 && osver.dwMinorVersion < 1)
 strcpy (uts->sysname, "Windows 2000"); /* 2k */
-  else if (osver.dwMajorVersion >= 5)
+  else if (osver.dwMajorVersion < 6)
 strcpy (uts->sysname, "Windows XP");   /* XP */
+  else if (osver.dwMajorVersion == 6)
+   {
+ if (osver.dwMinorVersion < 1)
+   strcpy (uts->sysname, "Windows Vista");   /* Vista */
+ else if (osver.dwMinorVersion < 2)
+   strcpy (uts->sysname, "Windows 7"); /* Windows 7 */
+ else if (osver.dwMinorVersion < 3)
+   strcpy (uts->sysname, "Windows 8"); /* Windows 8 */
+ else if (osver.dwMinorVersion < 4)
+   strcpy (uts->sysname, "Windows 8.1"); /* Windows 8.1 */
+   }
+  else if (osver.dwMajorVersion >= 10)
+strcpy (uts->sysname, "Windows 10 or later"); /* Windows 10 and later 
*/
   os = WinNT;
   break;
 
 case VER_PLATFORM_WIN32_WINDOWS: /* Win95, Win98 or WinME */
-  if ((osver.dwMajorVersion > 4) || 
+  if ((osver.dwMajorVersion > 4) ||
   ((osver.dwMajorVersion == 4) && (osver.dwMinorVersion > 0)))
 {
  if (osver.dwMinorVersion >= 90)
@@ -91,11 +104,11 @@ uname (struct utsname *uts)
   break;
 }
 
-  sprintf (uts->version, "%ld.%02ld", 
+  sprintf (uts->version, "%ld.%02ld",
osver.dwMajorVersion, osver.dwMinorVersion);
 
   if (osver.szCSDVersion[0] != '\0' &&
-  (strlen (osver.szCSDVersion) + strlen (uts->version) + 1) < 
+  (strlen (osver.szCSDVersion) + strlen (uts->version) + 1) <
   sizeof (uts->version))
 {
   strcat (uts->version, " ");
@@ -115,10 +128,13 @@ uname (struct utsname *uts)
 case PROCESSOR_ARCHITECTURE_MIPS:
   strcpy (uts->machine, "mips");
   break;
+case PROCESSOR_ARCHITECTURE_IA64:
+  strcpy (uts->machine, "ia64");
+  break;
 case PROCESSOR_ARCHITECTURE_INTEL:
-  /* 
+  /*
* dwProcessorType is only valid in Win95 and Win98 and WinME
-   * wProcessorLevel is only valid in WinNT 
+   * wProcessorLevel is only valid in WinNT
*/
   switch (os)
 {
@@ -142,13 +158,16 @@ uname (struct utsname *uts)
 default:
   strcpy (uts->machine, "unknown");
   break;
-  }
+}
+  break;
+case PROCESSOR_ARCHITECTURE_AMD64:
+  strcpy (uts->machine, "x86_64");
   break;
 default:
   strcpy (uts->machine, "unknown");
   break;
   }
-  
+
   sLength = sizeof (uts->nodename) - 1;
   GetComputerName (uts->nodename, );
   return 0;

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Fri, 15 Jul 2016 22:43:05 -0300
> From: David Pirotte 
> 
> * configure.ac: Adding a copyright; bumping prereq -> 2.69

Why is that a good idea?  Are there any features Guile needs that
older versions don't support?

Thanks.