Re: [PATCH] test-system-cmds: use sh -c instead of guile -c

[Eli Zaretskii]

> Date: Sat, 28 Jan 2023 11:17:07 +0100
> From: Omar Polo 
> 
> I'm not sure this patch is palatable as-is, but I'm adding it to the
> OpenBSD port to have less failures in the regress suite.
> 
> The main issue is that "guile" may not be available at test time for
> various reasons.  (the install prefix is not in $PATH, the executable
> may be renamed --program-suffix, etc...)

the intent of the test is to test the just-produced Guile binary, so
if that binary is not on PATH, the test suite should be fixed so that
it is on PATH.

> The comment about windows however makes me think that neither sh may
> be available.  Using meta/guile then is better, other tests are doing
> that, but I haven't found the right incantation to do so.

I'm responsible for that comment, so when I ran the test suite, it did
find the Guile binary in the build tree.  Maybe something happened in
the meantime that it doesn't now, but the right fix is IMO definitely
not to replace Guile with sh, as relying on sh being available is not
going to work on Windows.

Please instead try to figure out why guile is not on PATH.  Running
meta/guile might be better, but isn't that a shell script that
requires sh as well?

Re: Implementing Guile with a Windows port

[Eli Zaretskii]

> Date: Sat, 9 Oct 2021 22:02:06 -0300
> From: David Pirotte 
> Cc: Taylan Kammer , andrewgo...@yahoo.com.sg,
>  guile-devel@gnu.org
> 
> Le Sat, 09 Oct 2021 21:32:23 +0300,
> Eli Zaretskii  a écrit :
> 
> > A MinGW port of Guile 2.0.11 can be found on the ezwinports site.
> > AFAIK, the only feature it omits is threads, because Guile built with
> > threads is broken on MS-Windows.
> 
> Fwiw, when I need to, I use msys2:
> 
>   https://www.msys2.org/
> 
>   https://packages.msys2.org/search?t=binpkg=guile
>   =>
>   Package Version 
>   guile   2.2.7-1 
>   libguile2.2.7-1 
>   libguile-devel  2.2.7-1

That's not a native MS-Windows program, its behavior differs from
native programs in subtle ways.  If that doesn't bother the OP, then
it's fine to use it.  But you cannot, for example, use libguile from
that distribution to build a MinGW port of GDB or GNU Make with Guile
support, because that libguile can only be linked into MSYS2
executables.  So once you start using that library, you are locked
into MSYS2 applications and cannot escape into native MS-Windows
applications produced by MinGW.

Re: Implementing Guile with a Windows port

[Eli Zaretskii]

> From: Taylan Kammer 
> Date: Sat, 9 Oct 2021 20:10:15 +0200
> 
> I can't speak for the developers, but as far as I can tell, there isn't the
> right combination of willingness and resources to support a native port of
> GNU Guile for MS Windows.
> 
> As far as I know, there's a MinGW port, but if I'm not mistaken it's partly
> neglected and not as feature-rich as the "normal" GNU/Linux version.

A MinGW port of Guile 2.0.11 can be found on the ezwinports site.
AFAIK, the only feature it omits is threads, because Guile built with
threads is broken on MS-Windows.

Re: Replace ltdl with GLib's GModule

[Eli Zaretskii]

> From: Ludovic Courtès 
> Date: Fri, 27 Mar 2020 13:01:38 +0100
> 
> I’m very much tired of “file not found” :-), but I don’t think Guile
> should depend on GLib, which is quite big.

FWIW, I agree.

> I think we should either fix ltdl (probably less work than porting Guile
> to GModule, but also less exciting) or have a very basic wrapper around
> dlopen instead of using ltdl (I think Andy had made experiments in that
> direction.)

If you drop ltdl, the MinGW port of Guile will be broken, as dlopen
there is not guaranteed to exist (it exists in one flavor of MinGW,
but not in the other, which is the most popular one, AFAIK).

So my recommendation would be to fix ltdl.

Re: Stepping back up as a co-maintainer

[Eli Zaretskii]

> Date: Thu, 17 Oct 2019 12:33:33 +0200
> From: 
> Cc: zx spectrumgomas , guile-user 
> ,
>  guile-devel 
> 
> 
> On Thu, Oct 17, 2019 at 12:24:03PM +0200, Mikael Djurfeldt wrote:
> > I think we should trust what Mark says and not second guess him.
> 
> Definitely. I think this should count for *all*. Second-guessing anyone
> in this difficult situation can only add more difficulties on top.

Agreed.

Re: conflicts in the gnu project now affect guile

[Eli Zaretskii]

> From: Christopher Lemmer Webber 
> Date: Wed, 16 Oct 2019 11:33:11 -0400
> Cc: Andy Wingo 
> 
> I'm extremely saddened to see RMS pull this move.  It seriously
> undermines faith for maintainers of GNU projects that ther is any
> semblance of fair governance, and that the rug can't be pulled out from
> under their feet at any time.

To reach such conclusions, we'd need to hear a first-hand report of
what exactly did RMS and Mark say in their (presumed) off-list
exchange.  No such first-hand report was posted; Mark just said that
he decided to step back.

Re: Compiling guile-2.2.4 for mingw

[Eli Zaretskii]

> From: Christoph Buck 
> Date: Tue, 20 Nov 2018 15:31:25 +0100
> 
> > ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> > In procedure bytevector-u64-set!: Value out of range: -149659645
> > make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> > make[2]: Leaving directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> > make[1]: *** [Makefile:1857: all-recursive] Error 1
> > make[1]: Leaving directory '/home/Christoph.Buck/guile-2.2.4'
> > make: *** [Makefile:1743: all] Error 2
> 
> I have no idea what might be wrong here or how to fix this problem. Does
> anbody have an idea?

I have a guess: bytevector-u64-set! uses GMP functions to store a
64-bit value, but GMP doesn't yet support that on Windows, because it
thinks it can get away with the 'long' type for that, and 'long' is a
32-bit type on Windows, even in 64-bit builds.

I would suggest first to build a 32-bit Guile against a 32-bit GMP.
If that fails in the same way, then my guess is wrong ;-)

Re: c99 support

[Eli Zaretskii]

> From: Andy Wingo 
> Date: Sat, 23 Jun 2018 21:11:29 +0200
> Cc: guile-devel@gnu.org
> 
> Is there anyone who compiles Guile with a compiler that does not support
> C99?  If so, please give platform and compiler.

You mean C99 compiler or C99 C run-time library?  Or both?

MS-Windows (MinGW) doesn't have a C99 compliant C library, although
quite a few of what's needed is present.

Re: [PATCH PR guile/21104] Fix GDB build failure with Guile 2.2

[Eli Zaretskii]

> From: "Doug Evans via gdb-patches" 
> Date: Tue, 6 Feb 2018 10:58:07 -0800
> Cc: guile-devel@gnu.org
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index f69173a245..324f98b217 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -3,6 +3,8 @@
>  
>  *** Changes since GDB 8.1
>  
> +* Guile 2.2 support has been restored.

Do we need this entry?  Maybe I'm missing something, but I see nothing
in NEWS that says we stopped supporting Guile 2.2 at some point, so
"restored" here is surprising.  Maybe we shouldn't say anything about
this in NEWS, as (AFAIU) your work was a fix for a bug, and we don't
announce bugfixes in NEWS.

Thanks.

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter 
> Date: Thu, 25 Jan 2018 09:54:40 -0500
> Cc: guile-devel@gnu.org
> 
> Well, that was an obvious problem:  I had configured the build with 
> --without-posix, which I guess is no longer
> supported.

I don't know if it's supported, but it definitely is not needed for
the MS-Windows build.

> ERROR: In procedure primitive-load-path:
> In procedure primitive-load-path: Unable to find file
> "C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/meta/guild"
> in load path
> 
> Time to strap a bunch of instrumentation onto load.c and see where this is 
> coming from…

Yes, I think you will find that some code there doesn't know about the
Windows C:/foo/bar form of absolute file names.  Although
is_absolute_file_name and is_file_name_separator are in load.c,
and AFAICT do TRT for MinGW...  So maybe the problem is in some .scm
file instead.  Search for literals slash '/' characters to find some
potential offenders.

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter 
> Date: Tue, 23 Jan 2018 21:18:17 -0500
> Cc: guile-devel@gnu.org
> 
>   BOOTSTRAP GUILEC ice-9/eval.go
> ;;; note: source file 
> C:/msys64/home/mkeeter/guile/src/guile-2.2.3/module/ice-9/boot-9.scm
> ;;;   newer than compiled
> C:/msys64/home/mkeeter/guile/src/guile-2.2.3/prebuilt/32-bit-little-endian/ice-9/boot-9.go
> Backtrace:
>8 (apply-smob/1 #)
> In ice-9/eval.scm:
>657:36  7 (_ _)
> 619:8  6 (_ #(#(#)))
> 155:9  5 (_ _)
> 619:8  4 (_ #(#(#(#(#(#(#(#(#(#(#(#) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
> 159:9  3 (_ #(#(#(#(#(#(#(#(#(#(#(#) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
>223:20  2 (proc #(#(#(#(#(#(#(#(#(#(# ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
> In unknown file:
>1 (%resolve-variable (7 . SIGINT) #)
>0 (_ # #<▒> ▒)
> 
> ERROR: Unbound variable: SIGINT
> 
> If I boot up the interpreter, it too does not know about SIGINT:
> 
> mkeeter@MATTHEWKEETA8AA MINGW32 ~/guile/src/build-i686-w64-mingw32
> $ GUILE_AUTO_COMPILE=0 
> GUILE_LOAD_PATH=/home/mkeeter/guile/src/guile-2.2.3/module
> ./meta/build-env guile
> GNU Guile 2.2.3
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> SIGINT
> ice-9/eval.scm:619:8: In procedure module-lookup: Unbound variable: SIGINT
> 
> On my Mac, the variable is defined (and has a value of 2).

You should grep the libguile directory for "SIGINT" and make sure the
file(s) involved in defining that variable are compiled in your build.
(The MinGW port of Guile 2.0.11 I have here does know about SIGINT,
FWIW.)

> I believe the odd printing is a quirk of the MinGW terminal – it certainly 
> doesn’t help in
> debugging, but I think the fundamental issue here is Guile not knowing about 
> SIGINT.

Yes, but you should also look into the printing issue, as that
shouldn't happen.  It's a problem of some sort, perhaps Guile thinks
your terminal is UTF-8 capable or something.

Re: Thread 1 "guile" received signal SIGPWR, Power fail/restart.

[Eli Zaretskii]

> From: Mark H Weaver 
> Date: Sat, 20 Jan 2018 23:45:54 -0500
> Cc: Guile Devel 
> 
> SIGPWR is used internally by libgc.  If I recall correctly, it's done to
> suspend all threads within their signal handlers before performing a
> garbage collection.  I can't seem to reproduce this on my system at the
> moment, but as I recall, when this happened in GDB I would simply type
> "c" to continue.  Does that work for you?

An alternative would be to type the following command at the beginning
of a GDB session, or add it to a suitable .gdbinit file that is read
when a session is started:

  handle SIGPWR noprint pass

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter 
> Date: Thu, 18 Jan 2018 10:18:36 -0500
> 
> Yup, I’m building 2.2.3.  I see mktime.c in guile-2.2.3/lib, but do not see
> mktime.o when I objdump libgnu.a, indicating that it’s not being built.
> 
> In config.log, I see a few lines that could be relevant:
> 
> configure:34662: checking for working mktime
> ...
> gl_cv_func_working_mktime=yes
> ...
> GNULIB_MKTIME=‘1'
> ...
> REPLACE_MKTIME=‘0'
> ...
> gl_GNULIB_ENABLED_mktime_FALSE='#'
> gl_GNULIB_ENABLED_mktime_TRUE=‘'
> 
> (full config.log is here: 
> https://gist.github.com/mkeeter/81c273069a2804ad8d53e72533f6f8da)
> 
> Does this offer any insight?  I’m confused by the conflicting GNULIB_MKTIME vs
> gl_GNULIB_ENABLED_mktime_TRUE, but am not adept at parsing automake outputs…

Then this sounds like a bug in Gnulib: it determines that your
platform doesn't need mktime, but it "forgets" that timegm, which your
platform does need, depends on mktime.

So I suggest to report this to the Gnulib mailing list, and I hope
they will propose a solution.  Meanwhile, you can continue the build
by copy/pasting the source of mktime.c into some Gnulib source that is
being compiled (e.g. timegm.c, which needs it in the first place), and
re-running "make".

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter 
> Date: Wed, 17 Jan 2018 17:30:02 -0500
> Cc: guile-devel@gnu.org
> 
> Following your advice, I’m now trying to build a 32-bit version under MinGW,
> This fails a little earlier in the process:
> 
> make[2]: Entering directory 
> '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
> make  all-am
> make[3]: Entering directory 
> '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
>   CCLD libguile-2.2.la
> ../lib/.libs/libgnu.a(timegm.o):timegm.c:(.text+0x22): undefined reference to 
> `mktime_internal'
> collect2.exe: error: ld returned 1 exit status
> make[3]: *** [Makefile:2373: libguile-2.2.la] Error 1
> 
> This appears to be the same bug as #24681
> (http://lists.gnu.org/archive/html/bug-guile/2017-03/msg00095.html),
> but I don’t see anyone successfully resolving it
> (and I can’t find any references to it in the Git history).
> 
> Any ideas?

mktime_internal is in Gnulib's mktime.c.  What version of Guile 2.2.x
are you building?  The latest v2.2.3 includes mktime.c in
guile-2.2.3/lib/, do you have it?  If you do have it, do you see
mktime.o in libgnu.a?

If mktime.c is in the tree, but is not compiled, you need to
investigate why, by looking at config.log, where the configure script
determines whether your system needs mktime.c and/or mktime_internal.

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter 
> Date: Tue, 16 Jan 2018 17:50:58 -0500
> 
> So far, I’ve adapted or created a handful of patches, and have successfully
> built guile.exe.  The build is failing after this point, when it tries to 
> build the
> documentation (?):
> 
> make[3]: Entering directory 
> '/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile'
>   GEN  guile-procedures.texi
> Backtrace:
>0 (primitive-load-path "C:/msys64/home/mkeeter/guile/src/▒")

What is the system locale of your Windows machine?  That funny
character might mean you have problems with non-ASCII characters, due
to bugs in libunistring.  And even if you locale is English_USA, you
should still know that libunistring will give you trouble: the version
of it distributed by MSYS2 have a couple of grave bugs that make
character encoding conversions fail on MS-Windows, and since Guile
works in UTF-8 internally, you will have problems in with any
primitives that need to work with non-ASCII characters.  For that
reason, I recommend building the latest version of libunistring first,
as the bugs I discovered back when I was porting Guile 2.0 to MinGW
are now fixed in up-stream libunistring (but MSYS2 still offers the
old version, and the patches it uses don't include those needed to fix
those problems).

> ERROR: In procedure primitive-load-path:
> ERROR: In procedure primitive-load-path: Unable to find file
> "C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/meta/guild"
> in load path
> 
> Does anyone have tips for why primitive-load-path would be failing like this?

This looks like some code which doesn't consider C:/foo/bar an
absolute file name, so it prepends the current directory to it.  These
problems are supposed to be fixed by patches I submitted for v2.0, but
maybe there's some new code in 2.2 that needs similar treatment.

> Enter `,help' for help.
> scheme@(guile-user)> (+ 1 2)
> While compiling expression:
> ERROR: In procedure bytevector-u64-set!: Value out of range: -149659645

Sounds like overflow?  You should be aware that 64-bit Windows uses
the LLP64 model, whereas Unix and Linux use LP64.  In practice, this
means that every variable whose type is 'long' or 'unsigned long' is a
64-bit type on 64-bit Unix systems, but a 32-bit type on Windows, so
all such variables should be carefully audited to makesure they don't
have to be converted to the corresponding 64-bit types.  For that
reason, my suggestion would be to build a 32-bit port of Guile first
(AFAIK, Mingw64 and MSYS2 support that), and only switch to 64 bits
once you have the 32-bit port up and running, and it passes the test
suite.

Re: Cygwin port of Guile 2.2

[Eli Zaretskii]

> From: "Mike Gran" 
> Date: Tue, 04 Apr 2017 09:45:43 -0700
> 
> Lastly, Cygwin's fork just doesn't play well with Guile's
> new GC and threading model.  Despite a copy of days in the
> guts of it all, I don't understand the specifics of the
> issue.  So, in the branch, I disabled forking altogether,
> and by extension, popen and friends.

For popen, you could use the MinGW code, I think.

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Eli Zaretskii]

> From: Germán Diago 
> Date: Wed, 1 Feb 2017 12:18:28 +0700
> Cc: guile-devel@gnu.org
> 
> Well, provided that you are tied to msys and you can never ever compile guile 
> with a microsoft compiler, that
> is ok. You are talking only about your use case. The reality is quite 
> different: if you want windows adoption, you
> need to use the native toolchain to compile.

MSYS is used only to run Bash, m4, perl, etc.  -- programs that are
invoked during the configure stage and by shell script fragments in
the Makefile.  The compiler is MinGW, not MSYS.  MinGW produces native
executables that are completely compatible with MSVC compiled
programs.  So I don't see a problem here, or any need to use non-free compilers.

> I can say with confidence that keeping autotools and taking windows seriously 
> at the
> same time is just impossible.

That's definitely not my experience.

> So my view here is that to have a decent windows port we would need native
> windows threads and compile with microsoft compiler

MinGW supports native Windows threads, and in fact the ported pthreads
are just a very thin wrapper around native threads.

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Eli Zaretskii]

> From: Germán Diago 
> Date: Tue, 31 Jan 2017 11:28:50 +0700
> 
> 2. Windows works under POSIX. What would be the effort of doing a port to 
> native windows threads? Effort in
> man-hours?

I've built native Windows port of Guile 2.0.x, you can find the
binaries here:

  http://sourceforge.net/projects/ezwinports/files/

However, building Guile with threads (using pthreads) on Windows
produces a broken binary which cannot even compile the *.scm files as
part of the build: it crashes a lot.  I don't know what causes this,
but I reported the details a few years ago, and you should be able to
find them in the archives.  The binaries whose URL is above are
compiled without threads.

> 3. Is there any interest in switching to meson build system? I think that it 
> works very well already and supports
> windows much better than autotools.

Not my place to answer that, but let me just say that I didn't have
any problems using the present autotools-based build system on
Windows with MSYS.  The absolute majority of the problems I needed to
solve while working on the port had nothing to do with autotools, but
with various non-portable and Posix-centric stuff in the Guile sources
(most of them were fixed since then using the patches I proposed).

Re: srfi-1 take and drop seriously broken

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 22:52:12 +0100
> From: 
> 
> On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> > Jan Synáček writes:
> > 
> > > scheme@(guile-user)> ,use (srfi srfi-1)
> > > scheme@(guile-user)> (take (list 1 2 3) 4)
> > > ERROR: In procedure list-head:
> > > ERROR: In procedure list-head: Wrong type argument in position 1
> > > (expecting pair): ()
> > 
> > That's expected.
> > 
> > > scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> > > ERROR: In procedure list-tail:
> > > ERROR: In procedure list-tail: Wrong type argument in position 1
> > > (expecting pair): ()
> > 
> > That too.
> > 
> 
> Hm. Jan's example should work, nevertheless. And it does work for me:
> 
>   tomas@rasputin:~$ guile
>   GNU Guile 2.0.11.133-d680
>   Copyright (C) 1995-2014 Free Software Foundation, Inc.
>   
>   Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>   This program is free software, and you are welcome to redistribute it
>   under certain conditions; type `,show c' for details.
>   
>   Enter `,help' for help.
>   scheme@(guile-user)> (use-modules (srfi srfi-1))
>   scheme@(guile-user)> (take (list 1 2 3 4) 4)
>   $1 = (1 2 3 4)

Your example has 4 members in the list, while the original one had
only 3.

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> Cc: m...@netris.org,  guile-devel@gnu.org
> Date: Wed, 31 Aug 2016 10:52:10 +0200
> 
> On Sat 27 Aug 2016 10:23, Eli Zaretskii <e...@gnu.org> writes:
> 
> > Ping!  (2 weeks)
> 
> Tx for the ping, and good idea!  I ended up applying something
> similar -- I moved system* to posix.c, enabled it iff open-process was
> available, and implemented in terms of open-process in a portable way.
> Hopefully that should fix the problem.  Thanks again for the patch, it
> was a great idea!

Thanks, the commit looks good to me.

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

[Eli Zaretskii]

> From: Andy Wingo 
> Date: Wed, 31 Aug 2016 11:46:19 +0200
> Cc: guile-devel 
> 
> Hah!  Turns out we have been compiling in GCC's default mode the whole
> time, which is gnu11.

The default is version-dependent.  Only GCC 5.x switched to gnu11,
previous versions used gnu90, AFAIK.

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

Ping!  (2 weeks)

> Date: Sat, 13 Aug 2016 14:55:27 +0300
> From: Eli Zaretskii <e...@gnu.org>
> Cc: wi...@pobox.com, guile-devel@gnu.org
> 
> > Date: Sat, 13 Aug 2016 12:11:33 +0300
> > From: Eli Zaretskii <e...@gnu.org>
> > Cc: wi...@pobox.com, guile-devel@gnu.org
> > 
> > > From: Mark H Weaver <m...@netris.org>
> > > Cc: wi...@pobox.com,  guile-devel@gnu.org
> > > Date: Wed, 10 Aug 2016 13:03:09 -0400
> > > 
> > > Eli Zaretskii <e...@gnu.org> writes:
> > > 
> > > >> Date: Wed, 10 Aug 2016 17:26:15 +0300
> > > >> From: Eli Zaretskii <e...@gnu.org>
> > > >> Cc: wi...@pobox.com, guile-devel@gnu.org
> > > >> 
> > > >> If you suggest to do what I described above, then I obviously agree.
> > > >
> > > > IOW, do you want me to send a patch along the lines I suggested?
> > > 
> > > Yes, please!
> > 
> > Will do when I have enough time (correctly quoting command-line
> > arguments on Windows is a tricky business).
> 
> On further thought, I decided to reuse code we already have, rather
> than write something new.  Is the approach below acceptable?  If it
> is, I will post it in Git format wrt the current repo.
> 
> --- libguile/simpos.c~0   2016-01-02 16:24:55.0 +0200
> +++ libguile/simpos.c 2016-08-13 13:56:43.014875000 +0300
> @@ -45,12 +45,12 @@
>  # include 
>  #endif
>  
> +#include "posix.h"
> +
>  #ifdef __MINGW32__
> -# include /* for spawnvp and friends */
> +#include "posix-w32.h"
>  #endif
>  
> -#include "posix.h"
> -
>  
>  extern int system();
>  
> @@ -124,9 +124,9 @@ SCM_DEFINE (scm_system_star, "system*", 
>SCM oldquit;
>SCM sigquit;
>  #endif
> -#ifdef HAVE_FORK
>int pid;
> -#else
> +#ifndef HAVE_FORK
> +  int p1[2], p2[2];
>int status;
>  #endif
>char **execargv;
> @@ -177,7 +177,21 @@ SCM_DEFINE (scm_system_star, "system*", 
>return scm_from_int (status);
>  }
>  #else  /* !HAVE_FORK */
> +#ifdef __MINGW32__
> +  /* MS-Windows spawnvp needs execargv[] strings quoted if they
> +  include special characters, like whitespace.  The required
> +  quoting is non-trivial, and also depends on whether
> +  execargv[0] is cmd.exe.  So we invoke start_child instead,
> +  which already has all that figured out.  */
> +  pid = start_child (execargv[0], execargv, 0, p1, 0, p2,
> +  fileno (stdin), fileno (stdout), fileno (stderr));
> +  if (pid == -1)
> +SCM_SYSERROR;
> +
> +  waitpid (pid, , 0);
> +#else
>status = spawnvp (P_WAIT, execargv[0], (const char * const *)execargv);
> +#endif
>scm_sigaction (sigint, SCM_CAR (oldint), SCM_CDR (oldint));
>  #ifdef SIGQUIT
>scm_sigaction (sigquit, SCM_CAR (oldquit), SCM_CDR (oldquit));
> 
> 

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> Date: Sat, 13 Aug 2016 12:11:33 +0300
> From: Eli Zaretskii <e...@gnu.org>
> Cc: wi...@pobox.com, guile-devel@gnu.org
> 
> > From: Mark H Weaver <m...@netris.org>
> > Cc: wi...@pobox.com,  guile-devel@gnu.org
> > Date: Wed, 10 Aug 2016 13:03:09 -0400
> > 
> > Eli Zaretskii <e...@gnu.org> writes:
> > 
> > >> Date: Wed, 10 Aug 2016 17:26:15 +0300
> > >> From: Eli Zaretskii <e...@gnu.org>
> > >> Cc: wi...@pobox.com, guile-devel@gnu.org
> > >> 
> > >> If you suggest to do what I described above, then I obviously agree.
> > >
> > > IOW, do you want me to send a patch along the lines I suggested?
> > 
> > Yes, please!
> 
> Will do when I have enough time (correctly quoting command-line
> arguments on Windows is a tricky business).

On further thought, I decided to reuse code we already have, rather
than write something new.  Is the approach below acceptable?  If it
is, I will post it in Git format wrt the current repo.

--- libguile/simpos.c~0 2016-01-02 16:24:55.0 +0200
+++ libguile/simpos.c   2016-08-13 13:56:43.014875000 +0300
@@ -45,12 +45,12 @@
 # include 
 #endif
 
+#include "posix.h"
+
 #ifdef __MINGW32__
-# include   /* for spawnvp and friends */
+#include "posix-w32.h"
 #endif
 
-#include "posix.h"
-
 
 extern int system();
 
@@ -124,9 +124,9 @@ SCM_DEFINE (scm_system_star, "system*", 
   SCM oldquit;
   SCM sigquit;
 #endif
-#ifdef HAVE_FORK
   int pid;
-#else
+#ifndef HAVE_FORK
+  int p1[2], p2[2];
   int status;
 #endif
   char **execargv;
@@ -177,7 +177,21 @@ SCM_DEFINE (scm_system_star, "system*", 
   return scm_from_int (status);
 }
 #else  /* !HAVE_FORK */
+#ifdef __MINGW32__
+  /* MS-Windows spawnvp needs execargv[] strings quoted if they
+include special characters, like whitespace.  The required
+quoting is non-trivial, and also depends on whether
+execargv[0] is cmd.exe.  So we invoke start_child instead,
+which already has all that figured out.  */
+  pid = start_child (execargv[0], execargv, 0, p1, 0, p2,
+fileno (stdin), fileno (stdout), fileno (stderr));
+  if (pid == -1)
+SCM_SYSERROR;
+
+  waitpid (pid, , 0);
+#else
   status = spawnvp (P_WAIT, execargv[0], (const char * const *)execargv);
+#endif
   scm_sigaction (sigint, SCM_CAR (oldint), SCM_CDR (oldint));
 #ifdef SIGQUIT
   scm_sigaction (sigquit, SCM_CAR (oldquit), SCM_CDR (oldquit));

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> From: Mark H Weaver <m...@netris.org>
> Cc: wi...@pobox.com,  guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 13:03:09 -0400
> 
> Eli Zaretskii <e...@gnu.org> writes:
> 
> >> Date: Wed, 10 Aug 2016 17:26:15 +0300
> >> From: Eli Zaretskii <e...@gnu.org>
> >> Cc: wi...@pobox.com, guile-devel@gnu.org
> >> 
> >> If you suggest to do what I described above, then I obviously agree.
> >
> > IOW, do you want me to send a patch along the lines I suggested?
> 
> Yes, please!

Will do when I have enough time (correctly quoting command-line
arguments on Windows is a tricky business).

Re: Guile test-ffi uses an unportable assumption

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: Andy Wingo ,  guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 04:31:15 -0400
> 
> > However, in the case in point even compiling guile with -export-dynamic
> > won't help, because the function being used by the test, strerror,
> > comes from the C library, and is not statically linked into the guile
> > binary.  So I suggest to modify the test to use a function that is
> > part of the guile binary's own sources.
> 
> Sounds good to me.  Here's a proposed patch.  Can you test it on MinGW
> and report back?

It still fails, see the error messages below.  I think that's
expected, since scm_c_hook_add is in libguile, which is built as a
dynamic library, so should be accessed via dl_open'ing libguile.  What
I suggested above is to access a function whose code is inside the
executable itself, i.e. some function in test-ffi-lib.c, such as
test_make_c_hook.

Here's the error message I got:

  Backtrace:
  In ice-9/boot-9.scm:
   160: 11 [catch #t # ...]
  In unknown file:
 ?: 10 [apply-smob/1 #]
  In ice-9/boot-9.scm:
66: 9 [call-with-prompt prompt0 ...]
  In ice-9/eval.scm:
   432: 8 [eval # #]
  In ice-9/boot-9.scm:
  2404: 7 [save-module-excursion #]
  4056: 6 [#]
  1727: 5 [%start-stack load-stack #]
  1732: 4 [#]
  In unknown file:
 ?: 3 [primitive-load "d:/gnu/guile-2.0.12/test-suite/standalone/test-ffi"]
  In ice-9/eval.scm:
   453: 2 [eval # ()]
   387: 1 [eval # ()]
  In unknown file:
 ?: 0 [dynamic-func "scm_c_hook_add" #]

  ERROR: In procedure dynamic-func:
  ERROR: In procedure dynamic-pointer: Symbol not found: scm_c_hook_add
  FAIL: test-ffi

Re: Avoid warnings in sockets.c when HAVE_SIN6_SCOPE_ID is unavailable

[Eli Zaretskii]

> From: Mark H Weaver <m...@netris.org>
> Cc: guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 02:49:08 -0400
> 
> Hi Eli,
> 
> Eli Zaretskii <e...@gnu.org> writes:
> 
> > 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;
> >   ^
> 
> How about this?
> 
> --8<---cut here---start->8---
> diff --git a/libguile/socket.c b/libguile/socket.c
> index 3229ac8..beff305 100644
> --- a/libguile/socket.c
> +++ b/libguile/socket.c
> @@ -744,7 +744,7 @@ scm_fill_sockaddr (int fam, SCM address, SCM *args, int 
> which_arg,
>   int port;
>   struct sockaddr_in6 *soka;
>   unsigned long flowinfo = 0;
> - unsigned long scope_id = 0;
> + unsigned long scope_id SCM_UNUSED = 0;
>  
>   SCM_VALIDATE_CONS (which_arg + 1, *args);
>   port = scm_to_int (SCM_CAR (*args));
> --8<---cut here---end--->8---
> 
> See the definition of SCM_UNUSED in __scm.h.

Works for me (no warning after applying the patch), but couldn't this
be harmful for builds that do use the variable, by omitting real
warnings?  If it could, maybe make the use of SCM_UNUSED be
conditional on HAVE_SIN6_SCOPE_ID being defined?

Thanks.

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> Date: Wed, 10 Aug 2016 17:26:15 +0300
> From: Eli Zaretskii <e...@gnu.org>
> Cc: wi...@pobox.com, guile-devel@gnu.org
> 
> If you suggest to do what I described above, then I obviously agree.

IOW, do you want me to send a patch along the lines I suggested?

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: Andy Wingo ,  guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 02:24:56 -0400
> 
> >>   (zero? (system* "egrep" "-q" string filename))
> >
> > For this to work, the Windows implementation of system* will need to
> > be augmented to quote characters special for the shell, because
> > (unlike execvp on Posix hosts) the arguments of spawnvp are eventually
> > concatenated into a single string that gets passed to the system API
> > which invokes programs.  If this is the way you are willing to solve
> > this, I will submit a patch to that effect.
> 
> I think this is the approach we should take here.  In general, we prefer
> to use 'system*' over 'system' because it avoids having to worry about
> quoting issues on POSIX systems.  We should enable this to work properly
> on MinGW, and avoid a situation where users might be discouraged from
> using 'system*' for the sake of MinGW compatibility.
> 
> What do you think?

If you suggest to do what I described above, then I obviously agree.

Thanks.

Re: Avoid warning about alloca in read.c

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sun, 24 Jul 2016 15:35:08 +0200
> 
> >> > +#ifdef __MINGW32__
> >> > +#include 
> >> > +#endif
> >> > +
> >> 
> >> OK to commit but please remove the ifdef -- just include  in all
> >> cases.
> >
> > Is that header available on all supported platforms?
> 
> Yes, we use a Gnulib module to ensure that some workable version is
> present.

Thanks, pushed.

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

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 22:36:17 +0200
> 
> >> > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the
> >> > trick of appending "0" to the time-zone string, Windows runtime
> >> > doesn't support that.
> >> > +#ifndef __MINGW32__
> >> > +/* Don't do this for MinGW: it only supports fixed-format
> >> > +   TTTnnnDDD TZ specifications, and gets confused if a zero is
> >> > +   appended.  */
> >> 
> >> This patch disables the setzone() call entirely; seems to be the wrong
> >> thing, given that MinGW doesn't appear to have struct tm->tm_zone.  What
> >> if we just disable appending the 0 to the time zone?
> >
> > I'm not sure I understand what you have in mind, but if you show a
> > patch and a simple test, I can run it here.
> 
> The current code:
> 
> #if !defined (HAVE_STRUCT_TM_TM_ZONE)
> /* it seems the only way to tell non-GNU versions of strftime what
>zone to use (for the %Z format) is to set TZ in the
>environment.  interrupts and thread switching must be deferred
>until TZ is restored.  */
> char **oldenv = NULL;
> SCM zone_spec = SCM_SIMPLE_VECTOR_REF (stime, 10);
> int have_zone = 0;
> 
> if (scm_is_true (zone_spec) && scm_c_string_length (zone_spec) > 0)
>   {
> /* it's not required that the TZ setting be correct, just that
>it has the right name.  so try something like TZ=EST0.
>using only TZ=EST would be simpler but it doesn't work on
>some OSs, e.g., Solaris.  */
> SCM zone =
>   scm_string_append (scm_list_2 (zone_spec,
>  scm_from_locale_string ("0")));
> 
> have_zone = 1;
> SCM_CRITICAL_SECTION_START;
> oldenv = setzone (zone, SCM_ARG2, FUNC_NAME);
>   }
> #endif
> 
> You said that appending the 0 confuses MinGW, so you skip this section
> and the corresponding one after the nstrftime.  But you're skipping the
> setzone too, so I don't see how the strftime tests would work.

Appending 0 confuses MinGW because time-zone strings on Windows can be
something like "Jerusalem Standard Time", in which case appending 0
will not DTRT.  If the TZ string is a 3-letter name like EST, then
EST0 will indeed work on Windows.

But what setzone does causes much more trouble: it replaces the
environ array with one that has a single variable TZ, and that
confuses the heck out of the Windows C runtime.  Windows programs
cannot run with an empty environ.

Frankly, I don't understand why all this stuff with setzone is needed,
because on Windows all that's required to do what I think this code is
trying to do is this:

  putenv ("TZ=whatever");
  tzset ();
  tm->tm_isdst = 0;

The last bit is required for when the "whatever" zone doesn't have a
DST name (like "EDT"), in which case %Z will produce an empty string.
The code already does call tzset, so it should simply call putenv and
set the isdst member, instead of using this strange method implemented
in setzone.  Am I missing something?

> According to POSIX, our TZ value is valid:
> 
>   http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
> 
> What is the MinGW restriction?  You mention it in the comment but I
> don't understand the comment.

If you are asking about the forms of the TZ variable, they are
documented here:

  https://msdn.microsoft.com/en-us/library/90s5c885(v=vs.71).aspx

But that's not the important problem with setzone.

Of course, the same problems exist with localtime and mktime: they
should also call putenv instead of setzone.

Re: Avoid warnings in sockets.c when HAVE_SIN6_SCOPE_ID is unavailable

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 22:55:50 +0200
> 
> > 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?
> 
> I don't think so -- whether the underlying system has scope_id or no, we
> need this assert to happen:
> 
> > +#ifdef HAVE_SIN6_SCOPE_ID
> >   SCM_VALIDATE_ULONG_COPY (which_arg + 3, SCM_CAR (*args),
> >scope_id);
> > +#endif
> 
> Not sure what the right solution is.

How about something this instead:

#ifdef HAVE_SIN6_SCOPE_ID
 SCM_VALIDATE_ULONG_COPY (which_arg + 3, SCM_CAR (*args),
  scope_id);
#else
 (void)SCM_NUM2ULONG (which_arg + 3, SCM_CAR (*args));
#endif

Re: Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: andrewjmore...@gmail.com,  guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 23:03:46 +0200
> 
> >> > Does the Mingw toolchain supply a suitable manifest automatically ?
> >> 
> >> No.  The manifest should be provided with Guile.
> >
> > Of course, singe Guile is mainly a library, any application that is
> > linked against libguile also needs such a manifest.
> 
> Does the uname MinGW patch introduce a regression in any case that we
> care about?

No.  On the contrary: where before Guile would only report correct OS
version up to and including XP, it now reports correct values also for
Vista, Windows 7, and Windows 8.  Versions beyond that require the
manifest, and otherwise will be reported as 8.0.

Also, the modern CPU types are now supported, including 64-bit ones,
which were not reported at all before.

> Is it a user-visible change?  If so an update to NEWS might be
> needed.

>From my POV, this is a bugfix: APIs that were reporting inaccurate
values now report more accurate ones.

Re: c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 23:11:08 +0200
> 
> > It fails like this:
> >
> >  Running c-api.test
> >  'CUR' is not recognized as an internal or external command,
> >  operable program or batch file.
> >  egrep: Unmatched ( or \('CUR' is not recognized as an internal or 
> > external command, operable program or batch file.
> >
> > This is because it quotes shell commands /bin/sh '..' style:
> 
> Of course, because that's how `system' is specified.

On Posix hosts, yes.  But the ANSI C standard only says that the
argument will be passed to the host environment's command processor.

> > --- test-suite/tests/c-api.test~0 2016-01-02 13:32:40.0 +0200
> > +++ test-suite/tests/c-api.test   2016-07-23 14:12:57.257375000 +0300
> > @@ -22,7 +22,7 @@
> >  (define srcdir (cdr (assq 'srcdir %guile-build-info)))
> >  
> >  (define (egrep string filename)
> > -  (zero? (system (string-append "egrep '" string "' " filename
> > +  (zero? (system (string-append "egrep \"" string "\" " filename
> >  " >" %null-device
> >  
> >  (define (seek-offset-test dirname)
> >
> > OK to push such a change?
> 
> I think instead to get this to work on MinGW we should switch to use
> system* instead of praying that we get quoting right ;) Something like:
> 
>   (zero? (system* "egrep" "-q" string filename))

For this to work, the Windows implementation of system* will need to
be augmented to quote characters special for the shell, because
(unlike execvp on Posix hosts) the arguments of spawnvp are eventually
concatenated into a single string that gets passed to the system API
which invokes programs.  If this is the way you are willing to solve
this, I will submit a patch to that effect.

Re: Guile test-ffi uses an unportable assumption

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 23:17:58 +0200
> 
> > It assumes that libltdl can only produce a handle for a symbol in the
> > the program itself, as opposed to those loaded from shared libraries.
> > It tries 'strerror'.  This cannot work on MS-Windows, unless the
> > program was linked with -export-dynamic, which is not true for
> > the test program.
> 
> Interesting.  The test program is a Scheme script which looks up
> strerror in the dlopen(NULL).  Libguile is compiled with -export-dynamic
> but the guile binary is not.  Which part needs to be compiled with
> -export-dynamic, do you think?

The guile binary.  Here's what the libltdl documentation has to say
about this:

 -- Function: lt_dlhandle lt_dlopen (const char *FILENAME)
[...]
 If FILENAME is `NULL' and the program was linked with
 `-export-dynamic' or `-dlopen self', `lt_dlopen' will return a
 handle for the program itself, which can be used to access its
 symbols.
[...]
 If you use `lt_dlopen (NULL)' to get a HANDLE for the running
 binary, that handle will always be marked as resident, and
 consequently cannot be successfully `lt_dlclose'd.

However, in the case in point even compiling guile with -export-dynamic
won't help, because the function being used by the test, strerror,
comes from the C library, and is not statically linked into the guile
binary.  So I suggest to modify the test to use a function that is
part of the guile binary's own sources.

Re: Avoid warnings in threads.c when building without threads

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 22:49:03 +0200
> 
> On Sat 16 Jul 2016 19:12, Eli Zaretskii <e...@gnu.org> writes:
> 
> > 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
> 
> I think not, sorry :/  pthread_cancel returns an int, so
> scm_i_pthread_cancel should always return an int.

Then code which ignores the value should cast to void.

> > --- 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 ();
> >  
> 
> Likewise this is not needed -- the problem is in the cond_wait
> definition.

But the above is a valid code when the returned value is being
ignored, so why not use it?

> null-threads.h is a distressing header file.  I think the right thing to
> do is to use typedefs and static inline functions instead of CPP macros.
> That way we keep type-safety, and also the compiler will stop
> complaining.

I'm okay with any solution that will shut up the warnings, because
they distract and mask real problems.

TIA

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

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 14:15:06 +0200
> 
> > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the
> > trick of appending "0" to the time-zone string, Windows runtime
> > doesn't support that.
> > +#ifndef __MINGW32__
> > +/* Don't do this for MinGW: it only supports fixed-format
> > +   TTTnnnDDD TZ specifications, and gets confused if a zero is
> > +   appended.  */
> 
> This patch disables the setzone() call entirely; seems to be the wrong
> thing, given that MinGW doesn't appear to have struct tm->tm_zone.  What
> if we just disable appending the 0 to the time zone?

I'm not sure I understand what you have in mind, but if you show a
patch and a simple test, I can run it here.

Thanks.

Guile test-ffi uses an unportable assumption

[Eli Zaretskii]

It assumes that libltdl can only produce a handle for a symbol in the
the program itself, as opposed to those loaded from shared libraries.
It tries 'strerror'.  This cannot work on MS-Windows, unless the
program was linked with -export-dynamic, which is not true for
the test program.

So this test currently fails on MS-Windows.

Guile tests that cannot work on MS-Windows and should be disabled

[Eli Zaretskii]

These tests are:

 . ftw.test, which fails because ftw is not available:

 FAIL: ftw.test: file-system-fold: test-suite
 ERROR: ftw.test: file-system-fold: EACCES - arguments: ((unbound-variable 
#f "Unbound variable: ~S" (getuid) #f))
 ERROR: ftw.test: file-system-fold: dangling symlink and lstat - arguments: 
((system-error "mkdir" "~A" ("File exists") (17)))
 ERROR: ftw.test: file-system-fold: dangling symlink and stat - arguments: 
((system-error "mkdir" "~A" ("File exists") (17)))
 FAIL: ftw.test: file-system-tree: test-suite/*
 FAIL: ftw.test: file-system-tree: test-suite (recursive)
 FAIL: ftw.test: scandir: top-srcdir
 ERROR: ftw.test: scandir: symlink to directory - arguments: ((system-error 
"mkdir" "~A" ("File exists") (17)))

 . several net_db tests:

 Running net-db.test
 ERROR: net-db.test: getaddrinfo: 127.0.0.1, any service - arguments: 
((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))
 ERROR: net-db.test: getaddrinfo: 127.0.0.1:80 - arguments: 
((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))
 ERROR: net-db.test: getaddrinfo: port 80 - arguments: ((unbound-variable 
#f "Unbound variable: ~S" (AI_ADDRCONFIG) #f))
 ERROR: net-db.test: getaddrinfo: port 80 with family and socket type - 
arguments: ((unbound-variable #f "Unbound variable: ~S" (AI_ADDRCONFIG) #f))
 ERROR: net-db.test: getaddrinfo: no name - arguments: ((unbound-variable 
#f "Unbound variable: ~S" (EAI_NONAME) #f))
 ERROR: net-db.test: getaddrinfo: wrong service name - arguments: 
((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))

 . two "no duplicates" tests in popen.test: these require a Posix
   shell, and simply hang on MS-Windows.

 . ports.test, because it needs 'fcntl', which is not available:

 Running ports.test
 FAIL: ports.test: file: binary mode ignores port encoding
 FAIL: ports.test: file: binary mode ignores file coding declaration
 Backtrace:
 In unknown file:
?:  0 [memoize-variable-access! # #]
 In ice-9/eval.scm:
  393:  1 [eval # (# # . #)]
  386:  2 [eval # #]
  432:  3 [eval # #]
 In unknown file:
?:  4 [primitive-load "d:/gnu/guile-2.0.12/test-suite/tests/ports.test"]
 In ice-9/boot-9.scm:
 1732:  5 [#]
 1727:  6 [%start-stack load-stack ...]
 4056:  7 [#]
 2404:  8 [save-module-excursion #]
 In ice-9/eval.scm:
  481:  9 [lp (#) (("ports.test"))]
 In ice-9/boot-9.scm:
  778: 10 [for-each # #]
 In ice-9/eval.scm:
  432: 11 [eval # #]
  432: 12 [eval # #]
 In ice-9/boot-9.scm:
   66: 13 [call-with-prompt prompt0 ...]
 In unknown file:
?: 14 [apply-smob/1 #]
 In ice-9/boot-9.scm:
  160: 15 [catch #t # ...]

 ERROR: In procedure memoize-variable-access!:
 ERROR: Unbound variable: fcntl

 . ttyname posix.test ('ttyname' is not available):

 Running posix.test
 ERROR: posix.test: ttyname: non-tty argument - arguments: 
((unbound-variable #f "Unbound variable: ~S" (ttyname) #f))

 . statprof.test, because SIGPROF is not available:

 Running statprof.test
 ERROR: statprof.test: return values - arguments: ((unbound-variable 
"module-lookup" "Unbound variable: ~S" (SIGPROF) #f))
 ERROR: statprof.test: statistical sample counts within expected range - 
arguments: ((unbound-variable "module-lookup" "Unbound variable: ~S" (SIGPROF) 
#f))
 ERROR: statprof.test: accurate call counting - arguments: 
((unbound-variable "module-lookup" "Unbound variable: ~S" (SIGPROF) #f))

For the record, here's the statistics of the test suite:

  Totals for this test run:
  passes: 39066
  failures:   12
  unexpected passes:  0
  expected failures:  9
  unresolved test cases:  571
  untested test cases:1
  unsupported test cases: 18
  errors: 14

c-api.test fails on MS-Windows due to non-portable quoting

[Eli Zaretskii]

It fails like this:

 Running c-api.test
 'CUR' is not recognized as an internal or external command,
 operable program or batch file.
 egrep: Unmatched ( or \('CUR' is not recognized as an internal or external 
command, operable program or batch file.

This is because it quotes shell commands /bin/sh '..' style:

 (define (egrep string filename)
   (zero? (system (string-append "egrep '" string "' " filename
 " >" %null-device

The solution is to use the ".." style of quoting:

--- test-suite/tests/c-api.test~0   2016-01-02 13:32:40.0 +0200
+++ test-suite/tests/c-api.test 2016-07-23 14:12:57.257375000 +0300
@@ -22,7 +22,7 @@
 (define srcdir (cdr (assq 'srcdir %guile-build-info)))
 
 (define (egrep string filename)
-  (zero? (system (string-append "egrep '" string "' " filename
+  (zero? (system (string-append "egrep \"" string "\" " filename
 " >" %null-device
 
 (define (seek-offset-test dirname)

OK to push such a change?

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

[Eli Zaretskii]

Ping!  Two out of 3 patches sent here:

  https://lists.gnu.org/archive/html/guile-devel/2016-07/msg00085.html

are still waiting to be accepted.

Thanks.

Re: Avoid warnings in sockets.c when HAVE_SIN6_SCOPE_ID is unavailable

[Eli Zaretskii]

Ping!

> Date: Sat, 16 Jul 2016 20:16:35 +0300
> From: Eli Zaretskii <e...@gnu.org>
> 
> 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);
> }
> }
> 
> 

Re: Avoid warnings in threads.c when building without threads

[Eli Zaretskii]

Ping!

> Date: Sat, 16 Jul 2016 20:12:22 +0300
> From: Eli Zaretskii <e...@gnu.org>
> 
>  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.c2016-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: Avoid warning about alloca in read.c

[Eli Zaretskii]

Ping!

> Date: Sat, 16 Jul 2016 20:18:26 +0300
> From: Eli Zaretskii <e...@gnu.org>
> 
>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"
> 
> 

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

[Eli Zaretskii]

> Date: Tue, 19 Jul 2016 20:53:44 -0300
> From: David Pirotte 
> Cc: guile-devel@gnu.org
> 
> > > > > 2.69 is the latest stable, available since April 2012  
> 
> > > > If there are known problems with older versions that get in the way, I
> > > > agree.  Are there?  
> 
> > > Are there?  
> 
> > That's what I asked.  Do you know the answer?
> 
> Don't you understand? How could I possibly answer that quiz, since it's been 
> 4 years
> I use 2.69? You can't tell for sure just because there has been no complain: 
> you can
> only tell for sure if someone you 'trust' check with what ever version you'd 
> like to
> use.

Problems in past versions of development tools are described in the
documentation, and if that's not enough, the maintainers of the tools
can be asked about them.  There should be no need to learn about that
from personal experience alone.

> Besides, 'users' who locally manually install and compile GDB probably know a 
> lot
> more then I on the subject :)

I don't think the fact that I build my own GDB means my time is cheap
and should be disregarded.

> And I bet they all setup a specific environment for that..

Not necessarily.  E.g., I don't.

Once again, if we must use features that exist only in a newer
version, then it's a reason good enough to request users to upgrade.
But as long as no such features are required, doing this:

  AC_PREREQ(2.69)

even though an older version would do, is IMO not a good idea.

And if you still disagree, let's leave it at that.  I'm not speaking
for the Guile project, so my opinion can be easily overridden.

Thanks.

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

[Eli Zaretskii]

> Date: Sun, 17 Jul 2016 17:26:35 -0300
> From: David Pirotte 
> Cc: guile-devel@gnu.org
> 
> > > 2.69 is the latest stable, available since April 2012
> 
> > If there are known problems with older versions that get in the way, I
> > agree.  Are there?
> 
> Are there?

That's what I asked.  Do you know the answer?

> > 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.
> 
> I would not qualify autoconf/automake of 'unrelated' but 'essential' tools, 
> and
> would never call 'nuisance' the fact that you ask a user to be in the 
> 'conditions'
> that guarantee a proper build. I can not guarantee this proper build with 
> earlier
> versions, I don't have time neither any wish to maintain older version of 
> these
> essential tools.

We already guaranteed a proper build with older versions, since Guile
builds now with whatever minimal versions we were requiring.  So this
problem does not exist, and will not exist, unless we deliberately
start using a newer version.

> > Besides, other packages might required older versions.
> 
> Are you aware of any incompatibilities between 2.69 and earlier 2.x 
> version(s) of
> autoconf?

That's not the point.  If a package requires a certain version, my
best bet is to use that version.

And some packages (e.g., GDB) indeed require use of a specific version
in order to make sure changes in the derived files are consistent.

Re: Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

> Date: Sun, 17 Jul 2016 05:37:24 +0300
> From: Eli Zaretskii <e...@gnu.org>
> Cc: guile-devel@gnu.org
> 
> > Does the Mingw toolchain supply a suitable manifest automatically ?
> 
> No.  The manifest should be provided with Guile.

Of course, singe Guile is mainly a library, any application that is
linked against libguile also needs such a manifest.

Re: Update 'uname' emulation on MS-Windows

[Eli Zaretskii]

> From: Andy Moreton <andrewjmore...@gmail.com>
> 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.

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 <e...@gnu.org>
> 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 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 <wi...@pobox.com>
> 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 <e...@gnu.org> 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-related patches that were reported in 2014 but not applied

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> 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 <e...@gnu.org>
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 <e...@gnu.org>
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
 	retur

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> 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  <e...@gnu.org>

* 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.
<procs, proc_size>: 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.  

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 <wi...@pobox.com>
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:58:39 +0200
> 
> On Sat 16 Jul 2016 09:27, Eli Zaretskii <e...@gnu.org> writes:
> 
> > 2016-07-16  Eli Zaretskii  <e...@gnu.org>
> >
> > * 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.

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  <e...@gnu.org>

* 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.

Compilation warnings in net_db.c

[Eli Zaretskii]

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?

configure.ac needs a change for MinGW

[Eli Zaretskii]

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.

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

[Eli Zaretskii]

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?

TIA

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> 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.  This is
> not ideal, and I think we will need to be much more strict about this in
> the future, as Guile becomes more widely used.
> 
> 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.  You seem to say there
are in fact ABI incompatibilities in the 2.0.x series, and if that's
indeed true, then the only way to avoid trouble is to rebuild and
reinstall all the packages that are linked against Guile, once I
install the latest Guile.  That is unfortunate, to say the least,
since Guile is already used in important GNU packages such as GDB and
Make.

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

Thanks.

Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

"./configure --help" says:

 Fine tuning of the installation directories:
   [...]
   --datarootdir=DIR   read-only arch.-independent data root [PREFIX/share]
   --datadir=DIR   read-only architecture-independent data [DATAROOTDIR]

AFAIU, this means PREFIX/share/guile/2.0/ is where the *.scm files
will be installed.  That is, installing Guile 2.0.12 will overwrite
the Scheme files that were installed there by previous Guile 2.0.x
versions.

If the above is true, then the question that bothers me is whether
replacing these files might cause any trouble for programs that were
compiled against previous Guile 2.0.x versions (like GDB and Make, for
example).  If there are potential incompatibilities visible on the
Scheme level, then I think a versioned directory under
PREFIX/share/guile/2.0/ would be in order, so that several versions of
Guile could live on the same system.

The same issue arises with the cache directory, where the *.go files
are installed (I have those in LIBDIR/guile/2.0/ccache/).

Is there a potential problem here?

TIA

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> Cc: m...@netris.org,  l...@gnu.org,  guile-devel@gnu.org
> Date: Thu, 14 Jul 2016 20:11:28 +0200
> 
> On Thu 14 Jul 2016 17:34, Eli Zaretskii <e...@gnu.org> writes:
> 
> >> > The process ID is indeed an int, but my code hides a process handle
> >> > inside it.
> >> 
> >> If you don't mind my asking: why? :)
> >
> > Because that's the only way on Windows to make sure the process object
> > is kept around by the kernel.  Integer PIDs are reused very quickly on
> > Windows, so by the time you get to scm_waitpid or some other function
> > that wants to query the process, that PID might not exist, or even
> > name a different process.  Having a handle open on the process
> > prevents the process object from being recycled.  Also, _cwait, used
> > by the Windows emulation of waitpid, needs a handle.
> 
> Are you saying that Windows doesn't wait until you waitpid() on a PID to
> reap it?

If there's no handle open on a process, then when it exits, its object
is recycled and its PID can easily be reused (on a busy system), yes.

> >> The caller effectively just returns the PID to Scheme, at which
> >> point it has a not-quite-PID floating around.  Sounds like trouble
> >> to me.
> >
> > Not sure why you think it's trouble.  Can you explain?
> 
> Just that spawn_child isn't the only way to get a PID.  getpid would be
> the most obvious one, but reading a PID value over a socket or whatever
> is also possible.  But then your code is now introducing not-quite-PIDs
> as well.  What if an interface expects one but gets the other?

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.

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> Cc: m...@netris.org,  l...@gnu.org,  guile-devel@gnu.org
> Date: Thu, 14 Jul 2016 12:20:09 +0200
> 
> On Tue 12 Jul 2016 16:46, Eli Zaretskii <e...@gnu.org> writes:
> 
> >> But in reality the getuid is of this form:
> >> 
> >>   (define (load-user-init)
> >> (let* ((home (or (getenv "HOME")
> >>  (false-if-exception (passwd:dir (getpwuid (getuid
> >>  file-name-separator-string))  ;; fallback for cygwin 
> >> etc.
> >>(init-file (in-vicinity home ".guile")))
> >>   (if (file-exists? init-file)
> >>   (primitive-load init-file
> >> 
> >> So, no problem.
> >
> > Won't this fail to compile during boot, or at least produce a warning?
> 
> It will produce a warning at compile-time, yes, but no problem at
> run-time because of the false-if-exception block.

Sigh.

> > The process ID is indeed an int, but my code hides a process handle
> > inside it.
> 
> If you don't mind my asking: why? :)

Because that's the only way on Windows to make sure the process object
is kept around by the kernel.  Integer PIDs are reused very quickly on
Windows, so by the time you get to scm_waitpid or some other function
that wants to query the process, that PID might not exist, or even
name a different process.  Having a handle open on the process
prevents the process object from being recycled.  Also, _cwait, used
by the Windows emulation of waitpid, needs a handle.

> The caller effectively just returns the PID to Scheme, at which
> point it has a not-quite-PID floating around.  Sounds like trouble
> to me.

Not sure why you think it's trouble.  Can you explain?

Re: MinGW open-process, take N

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: guile-devel@gnu.org,  l...@gnu.org,  m...@netris.org
> Date: Tue, 12 Jul 2016 16:05:35 +0200
> 
> > It's hard for me to build Guile from Git, due to the additional
> > prerequisites that needs.
> 
> Understood, in that case please note that there is also an automatic
> build service that runs "make" and "make dist" to make tarballs:
> 
>   https://hydra.nixos.org/job/gnu/guile-2-0/tarball
> 
> Just click through and you can download a tarball.  For example:
> 
>   
> https://hydra.nixos.org/build/37557639/download/3/guile-2.0.11.238-e1cb7.tar.gz
> 
> There is .xz too.  This service exists for Guile master too:
> 
>   https://hydra.nixos.org/job/gnu/guile-master/tarball

Thanks, I will try that when I have time, if Guile is not released
before that.

>   getuid is used in boot-9.scm, so if it's unavailable, we cannot build
>   Guile without making changes in the Scheme code.  I don't know if that
>   convinces you, and I have no practical way of counting their uses in
>   Guile programs outside Guile itself.
> 
> But in reality the getuid is of this form:
> 
>   (define (load-user-init)
> (let* ((home (or (getenv "HOME")
>  (false-if-exception (passwd:dir (getpwuid (getuid
>  file-name-separator-string))  ;; fallback for cygwin etc.
>(init-file (in-vicinity home ".guile")))
>   (if (file-exists? init-file)
>   (primitive-load init-file
> 
> So, no problem.

Won't this fail to compile during boot, or at least produce a warning?

> > The only other issue I see is the type of the value returned by
> > start_child, and as result by scm_open_process.  On Windows, the value
> > returned has the type HANDLE, which is actually a pointer in disguise.
> > I used intptr_t for that, but you changed it to just int.  This will
> > not work in 64-bit MinGW builds, where a pointer is a 64-bit type.  I
> > think we should go back to intptr_t, and also change the conversion to
> > the value returned by scm_open_process, since scm_from_int will AFAIK
> > not support 64-bit integer types.  Note that the MinGW waitpid
> > implementation also expects to get a valu that is interpreted as a
> > handle.
> 
> Hu, I don't know, there are a number of other things in that file
> which treat PIDs as ints (scm_waitpid, scm_getppid, etc etc etc).  I
> think that would need to be another patch that adds scm_from_pid_t and
> scm_to_pid_t and so on.  And then what is this?
> 
>   http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/12235

The process ID is indeed an int, but my code hides a process handle
inside it.

> I will apply your patch though and I look forward to hearing if it works
> for you :)

The above is not a problem for me, since I use the 32-bit MinGW, where
a handle is a 32-bit type.  This is only a potential problem in 64-bit
builds.

Thanks.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: m...@netris.org,  wi...@pobox.com,  guile-devel@gnu.org
> Date: Mon, 11 Jul 2016 10:09:47 +0200
> 
> >> >>> Eli Zaretskii <e...@gnu.org> writes:
> >> >>> > +# define getuid()  (500) /* Local Administrator */
> >> >>> > +# define getgid()  (513) /* None */
> >> >>> > +# define setuid(u) (0)
> >> >>> > +# define setgid(g) (0)
> >> 
> >> What about leaving ‘setuid’ and ‘setgid’ undefined, as was the case
> >> until now?
> >
> > I fail to see how this would be better.  It would mean any program
> > that calls these will not work on MS-Windows.  Why should we expect
> > developers of those Guile programs to be aware of the issue and solve
> > it on the Guile Scheme level?  And what solution will they possibly be
> > able to come up with, except not to call these APIs on Windows?
> 
> Our strategy so far has been to (1) either solve the portability issue
> via Gnulib, or (2) do not provide the feature that is unavailable (the
> #ifdef HAVE_ in posix.c et al.)
> 
> It means that application writers have to be aware of the portability
> problems, even if it’s all Scheme.  That sounds reasonable to me.
> 
> WDYT?

I don't think it's wise, and I explained why.  Gnulib in this case is
unlikely to provide any implementation, except one that always fails,
because these operations have no equivalent on MS-Windows.

But if agreeing to remove these two lines will cause the rest of the
patch to be finally admitted, I'm fine with that compromise.

TIA

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii <e...@gnu.org>,  wi...@pobox.com,  guile-devel@gnu.org
> Date: Tue, 05 Jul 2016 10:04:23 +0200
> 
> Mark H Weaver <m...@netris.org> skribis:
> 
> > Eli Zaretskii <e...@gnu.org> writes:
> >
> >>> From: Mark H Weaver <m...@netris.org>
> >>> Cc: l...@gnu.org (Ludovic Courtès),  wi...@pobox.com,
> >>>   guile-devel@gnu.org
> >>> Date: Sat, 02 Jul 2016 19:02:08 -0400
> >>> 
> >>> Eli Zaretskii <e...@gnu.org> writes:
> >>> > +# define getuid()  (500) /* Local Administrator */
> >>> > +# define getgid()  (513) /* None */
> >>> > +# define setuid(u) (0)
> >>> > +# define setgid(g) (0)
> 
> What about leaving ‘setuid’ and ‘setgid’ undefined, as was the case
> until now?

I fail to see how this would be better.  It would mean any program
that calls these will not work on MS-Windows.  Why should we expect
developers of those Guile programs to be aware of the issue and solve
it on the Guile Scheme level?  And what solution will they possibly be
able to come up with, except not to call these APIs on Windows?

> ‘getuid’ and ‘getgid’ could either be undefined or return a “random”
> value; the latter only makes sense if in practice it helps run useful
> code without any observable difference, though I’m unsure whether such
> code exists.

Random values are better than nothing, but they are worse than
consistent values, because some program might record the value from
one call and then compare it further down the program flow with the
results of another call.  Consistent values will win in this case.

> Anyway, I think we shouldn’t lose our hair over this problem; I’m
> grateful Eli did all this work porting Guile to MinGW, and that is what
> matters most.

Thank you.  I certainly hope so.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: Mark H Weaver 
> Cc: wi...@pobox.com,  l...@gnu.org,  guile-devel@gnu.org
> Date: Tue, 05 Jul 2016 03:44:15 -0400
> 
> Most applications do not expose get*id/set*id to other programs as part
> of their public API.

Emacs exposes getuid, getgid, geteuid, and getegid, has been doing
that for a very long time.  See the functions user-id, user-real-id,
group-id, and group-real-id.

> When they are kept private, such hacks are far more defensible,
> because it is possible to examine every call site and thereby
> determine whether any harm might be caused by silently ignoring
> requests and returning bogus results.
> 
> In the case of Guile, you are asking us to expose these dishonest and
> potentially dangerous definitions in our public API, and therefore to an
> unbounded set of programs and use cases, not to mention public scrutiny.

I don't see a significant difference between these two classes of use
cases.  IME, when someone needs the results of getuid etc. in Lisp,
Scheme, or some other high-level language, they use them in the same
way as one would do that in C as part of some primitive.  After all,
what other reasons could you imagine for using these values, except to
write code in Scheme to do something similar to some primitive, but
with a quirk?  All the rest of the applications of these values I
could think of (e.g., scanning /etc/passwd etc.) are not relevant to
Windows anyway, since these facilities don't exist there in the form
and format they do on Posix platforms.

If you can think of some other kinds of application that might need
these values, please describe them.

> Before I would consider doing this, I would need to be convinced of
> three propositions:
> 
> (1) that get*id/set*id are used so frequently in Guile programs that it
> would be unreasonably onerous to examine and modify each call site
> to handle the MS-Windows case.

getuid is used in boot-9.scm, so if it's unavailable, we cannot build
Guile without making changes in the Scheme code.  I don't know if that
convinces you, and I have no practical way of counting their uses in
Guile programs outside Guile itself.

But even if the frequency is not high enough, what would be the
practical alternative?  Guile is an extension language, so we cannot
possibly go out and fix all those uses, as they are not confined to a
small number of known packages.

> (2) that security flaws would be extremely unlikely to arise from your
> definitions.

setuid and setgid are defined to no-ops, so their security flaws are
by definition nil.  What kind of security flaws could arise from
getuid and getgid, as I proposed to define them?  Windows will not
allow access to protected files regardless of the user/group ID we
use, so I think these, too, have no security related issues that I can
think of.

> (3) that for the overwhelming majority of call sites, your definitions
> lead to correct behavior on MS-Windows.

I can tell that they survived the Guile test suite.

More generally, the get*id values are just numbers that have no
implication on code correctness.  _Any_ scalar values returned by
these functions on Windows will not be correct, because the
corresponding Windows values are variable-length arrays (called
Security Identifiers, or "SIDs").  Moreover, even if we do return the
full SID to Guile, there's no way of using them in any Guile API
because those APIs are modeled on Posix, which expects a single scalar
value.

So I think doing something like I suggested is really the only
practical solution -- return some plausible number whose only real use
could be to display it.

> I'm skeptical of all three.

I know.  And that's what makes this experience so frustrating for me:
you remain skeptical whatever I say, even though this dispute has been
going on for a couple of years.

> > Raising exceptions in these cases will simply get in the
> > way of writing portable Guile programs, because the application
> > programmer will have to work around the exception in Guile code,
> 
> That's exactly what *should* be done, because only at the application
> level is it possible to reliably determine how to properly handle the
> absence of these operations.

IME, the considerations on the application level will invariably be
exactly the same as what I suggest: either don't call the API or
ignore the result.

Here's a relevant example: a Windows port of GNU 'cp'.  I'm trying to
recursively copy a directory:

  D:\usr\eli\data>cp -pvr foo bar
  `foo' -> `bar'
  `foo/#bug.m#' -> `bar/#bug.m#'
  `foo/bug.el' -> `bar/bug.el'
  `foo/bug.m' -> `bar/bug.m'
  cp: failed to preserve ownership for `bar': Permission denied
  ^

The error happens because the person who ported the program didn't
make 'chown' and its supporting code a no-op on Windows for
directories.  The result: infinite annoyance for users, and for no
good reason at all, because Windows copies the NTFS 

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> Date: Sun, 03 Jul 2016 06:47:37 +0300
> From: Eli Zaretskii <e...@gnu.org>
> Cc: wi...@pobox.com, l...@gnu.org, guile-devel@gnu.org
> 
> As I've said before, these operations either have no meaning on
> MS-Windows, or cannot be easily mapped to the equivalent Windows
> notions.  All other applications ported from Posix platforms that I
> know of do something like the above, and I have yet to hear a single
> complaint.  Raising exceptions in these cases will simply get in the
> way of writing portable Guile programs, because the application
> programmer will have to work around the exception in Guile code, or
> declare that the program does not support MS-Windows.

For those who want to see the detailed arguments I brought up in a
past discussion, please read

  https://lists.gnu.org/archive/html/guile-devel/2014-02/msg00072.html

It's a long message covering a lot of turf, but the stuff relevant to
these particular issues starts around the middle of the message, with
this citation:

> >> On the other hand, if a program _does_ try to do one of those things, it
> >> might be important that the job be done right.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: Mark H Weaver <m...@netris.org>
> Cc: l...@gnu.org (Ludovic Courtès),  wi...@pobox.com,
>   guile-devel@gnu.org
> Date: Sat, 02 Jul 2016 19:02:08 -0400
> 
> Eli Zaretskii <e...@gnu.org> writes:
> > +# define getuid()  (500) /* Local Administrator */
> > +# define getgid()  (513) /* None */
> > +# define setuid(u) (0)
> > +# define setgid(g) (0)
> 
> As I've said before, I'm not comfortable with these definitions.  These
> are not operations that can be safely ignored.  If we cannot do a job
> that's requested of us, we should raise an exception.  We should not
> make numbers up out of thin air and pass them off as fact, nor should we
> claim to have successfully done a job that we are unable to do.
> 
> More to the point, we should not assume that the caller's requests are
> unimportant.  Feigning success on ignored requests and fabricating
> misinformation might be okay in some cases, but in other cases it is
> likely to lead to security holes and other bugs.  For example, a common
> pattern is to use 'setuid' to drop privileges before running some
> untrusted code.  We must not silently ignore such requests.

As I've said before, these operations either have no meaning on
MS-Windows, or cannot be easily mapped to the equivalent Windows
notions.  All other applications ported from Posix platforms that I
know of do something like the above, and I have yet to hear a single
complaint.  Raising exceptions in these cases will simply get in the
way of writing portable Guile programs, because the application
programmer will have to work around the exception in Guile code, or
declare that the program does not support MS-Windows.

Please accept my opinions that are based on many years of experience
in porting Unix and GNU applications to MS-DOS and MS-Windows.

Thanks.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: l...@gnu.org (Ludovic Courtès),  guile-devel@gnu.org
> Date: Sat, 25 Jun 2016 16:43:34 +0200
> 
> > @@ -659,7 +663,7 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
> >  #else
> >/* Mingw has raise(), but not kill().  (Other raw DOS environments might
> >   be similar.)  Use raise() when the requested pid is our own process,
> > - otherwise bomb.  */
> > + otherwise TerminateProcess.  */
> >if (scm_to_int (pid) == getpid ())
> >  {
> >if (raise (scm_to_int (sig)) != 0)
> > @@ -673,6 +677,10 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
> >goto err;
> >  }
> >  }
> > +#ifdef __MINGW32__
> > +  if (w32_kill_proc (scm_to_int (pid), scm_to_int (sig)) != 0)
> > +SCM_SYSERROR;
> > +#endif /* __MINGW32__ */
> >  #endif
> >return SCM_UNSPECIFIED;
> >  }
> 
> Here we effectively have two mingw blocks.  Can the previous one be
> removed?

The previous block is not MinGW-specific.  It allows any system that
has 'raise' (which is Standard C, so should be available everywhere)
to at least kill the current process.  This code was there before my
changes, and I saw no reasons to remove it.

> If not, let's fold it into `w32_kill_proc', and in any case
> let's rename `w32_kill_proc' to `kill', and then define HAVE_KILL.

I didn't want to call the function 'kill', as some other linked-in
library might have it, and then you'd have a clash.  'kill' is too
simple a name to overload.

> > @@ -1141,7 +1143,7 @@ SCM_DEFINE (scm_execl, "execl", 1, 0, 1,
> >  
> >exec_argv = scm_i_allocate_string_pointers (args);
> >  
> > -  execv (exec_file, exec_argv);
> > +  execv (exec_file, (char const * const *)exec_argv);
> >SCM_SYSERROR;
> >  
> >/* not reached.  */
> 
> make[3]: Entering directory '/home/wingo/src/guile-2.0/libguile'
>   CC   libguile_2.0_la-posix.lo
> posix.c: In function 'scm_execl':
> posix.c:1146:21: warning: passing argument 2 of 'execv' from incompatible 
> pointer type [-Wincompatible-pointer-types]
>execv (exec_file, (char const * const *)exec_argv);
>  ^
> In file included from ../lib/unistd.h:40:0,
>  from posix.c:50:
> /home/wingo/.guix-profile/include/unistd.h:566:12: note: expected 'char * 
> const*' but argument is of type 'const char * const*'
>  extern int execv (const char *__path, char *const __argv[])
> ^
> 
> What should be done here?

Make the cast MinGW-only?

> > @@ -1408,16 +1433,16 @@ scm_open_process (SCM mode, SCM prog, SCM args)
> >if (err > 0)
> >  {
> >char *msg = strerror (errno);
> > -  fprintf (fdopen (err, "a"), "In execlp of %s: %s\n",
> > +  fprintf (fdopen (err, "a"), "In execvp of %s: %s\n",
> > exec_file, msg);
> >  }
> >  
> >_exit (EXIT_FAILURE);
> > +#endif /* HAVE_FORK */
> >/* Not reached.  */
> >return SCM_BOOL_F;
> >  }
> >  #undef FUNC_NAME
> > -#endif /* HAVE_FORK */
> 
> This change updates to provide `open-process' effectively on all systems
> instead of only if `fork' is available, but then it causes a runtime
> error if the system doesn't have `fork' and isn't `mingw32'.

Sorry, I don't follow: the change in fprintf fixes a simple type (the
function whose call failed is 'execvp', not 'execlp'.  Or are you
talking about something else?

> I guess that's OK in practice.  Would you mind updating the
> documentation in doc/ref/posix.texi to indicate this?  Thanks.

Once I understand the issue, sure.

Thanks.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

[Please disregard the previous patch and use this one instead.]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: Andy Wingo <wi...@pobox.com>,  guile-devel@gnu.org
> Date: Sat, 25 Jun 2016 15:02:42 +0200
> 
> >> Great!  I have two nits.  One, if it is possible for you, please attach
> >> the patch in the format that "git format-patch" makes.  That makes it
> >> easy to apply, otherwise I have to futz around with --author and I could
> >> accidentally fat-finger it and get it wrong.
> >> 
> >> Secondly, please make w32-proc override the definitions of
> >> HAVE_GETPRIORITY, HAVE_SETPRIORITY, HAVE_SCHED_GETAFFINITY, and
> >> HAVE_SCHED_SETAFFINITY.  That way you won't need this kind of change
> >> either:
> >> 
> >> > -#if HAVE_GETPRIORITY
> >> > +#if HAVE_GETPRIORITY || defined __MINGW32__
> >> 
> >> If you've already discussed this with Ludovic and decided to go this way
> >> explicitly, please disregard this second nit.
> >> 
> >> I will also wait a day or two for any comments from Ludovic before
> >> applying.
> >
> > Thanks, I will wait for Ludovic to tell he's okay with overriding the
> > HAVE_* macros,
> 
> Yes, I agree with Andy, I think it’ll be nicer.
> 
> > and will send a format-patch formatted changes after that.
> 
> Cool, thank you!

Updated patch below.

>From 21d718f0b1c9bba62204eab7342406c46e5cbdc2 Mon Sep 17 00:00:00 2001
From: Eli Zaretskii <e...@gnu.org>
Date: Sat, 25 Jun 2016 16:29:22 +0300
Subject: [PATCH] Provide support for open-process and related functions on
 MS-Windows

* libguile/w32-proc.c: New file, with MinGW support code for
scm_open_process, scm_kill, scm_getpriority, scm_setpriority,
scm_getaffinity, and scm_setaffinity.  Also, provides macros that
on Posix hosts are in sys/wait.h, like WIFEXITED and WTERMSIG, and
simple definitions for getuid, getgid, setuid, setgid, and
waitpid.

* libguile/posix.c [__MINGW32__]: Include w32-proc.c.
(scm_kill) [__MINGW32__]: Support killing subprocesses on MS-Windows.
(scm_status_exit_val, scm_getuid, scm_getegid): Don't exclude from
compilation with MinGW.
(scm_execl, scm_execle): Cast arguments of execv/execve to avoid
compiler warnings.
(scm_open_process): Condition parts specific to 'fork'-based
implementation with "#ifdef HAVE_FORK".
[__MINGW32__]: MinGW alternative to 'fork'-based implementation;
most of the supporting code is in w32-proc.c.
(scm_getpriority, scm_setpriority, scm_getaffinity)
(scm_setaffinity, scm_init_popen): Don't exclude from MinGW
compilation.
(scm_init_posix): Register scm_init_popen extension even if
HAVE_FORK is not defined.
---
 libguile/posix.c|  59 +++-
 libguile/w32-proc.c | 919 
 2 files changed, 960 insertions(+), 18 deletions(-)
 create mode 100644 libguile/w32-proc.c

diff --git a/libguile/posix.c b/libguile/posix.c
index 2654716..8541f7d 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -84,6 +84,10 @@
 #if HAVE_SYS_WAIT_H
 # include 
 #endif
+#ifdef __MINGW32__
+# include 
+#endif	/* __MINGW32__ */
+
 #ifndef WEXITSTATUS
 # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
 #endif
@@ -659,7 +663,7 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
 #else
   /* Mingw has raise(), but not kill().  (Other raw DOS environments might
  be similar.)  Use raise() when the requested pid is our own process,
- otherwise bomb.  */
+ otherwise TerminateProcess.  */
   if (scm_to_int (pid) == getpid ())
 {
   if (raise (scm_to_int (sig)) != 0)
@@ -673,6 +677,10 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
   goto err;
 }
 }
+#ifdef __MINGW32__
+  if (w32_kill_proc (scm_to_int (pid), scm_to_int (sig)) != 0)
+SCM_SYSERROR;
+#endif	/* __MINGW32__ */
 #endif
   return SCM_UNSPECIFIED;
 }
@@ -735,7 +743,6 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1, 0,
 #undef FUNC_NAME
 #endif /* HAVE_WAITPID */
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_status_exit_val, "status:exit-val", 1, 0, 0, 
 (SCM status),
 	"Return the exit status value, as would be set if a process\n"
@@ -786,7 +793,6 @@ SCM_DEFINE (scm_status_stop_sig, "status:stop-sig", 1, 0, 0,
 return SCM_BOOL_F;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 #ifdef HAVE_GETPPID
 SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
@@ -801,7 +807,6 @@ SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
 #endif /* HAVE_GETPPID */
 
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_getuid, "getuid", 0, 0, 0,
 (),
 	"Return an integer representing the current real user ID.")
@@ -905,10 +910,8 @@ SCM_DEFINE (scm_seteuid, "seteuid", 1, 0, 0,
   return SCM_UNSPECIFIED;
 }
 #undef FUNC_NAME
-#endif /*

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: Andy Wingo <wi...@pobox.com>,  guile-devel@gnu.org
> Date: Sat, 25 Jun 2016 15:02:42 +0200
> 
> >> Great!  I have two nits.  One, if it is possible for you, please attach
> >> the patch in the format that "git format-patch" makes.  That makes it
> >> easy to apply, otherwise I have to futz around with --author and I could
> >> accidentally fat-finger it and get it wrong.
> >> 
> >> Secondly, please make w32-proc override the definitions of
> >> HAVE_GETPRIORITY, HAVE_SETPRIORITY, HAVE_SCHED_GETAFFINITY, and
> >> HAVE_SCHED_SETAFFINITY.  That way you won't need this kind of change
> >> either:
> >> 
> >> > -#if HAVE_GETPRIORITY
> >> > +#if HAVE_GETPRIORITY || defined __MINGW32__
> >> 
> >> If you've already discussed this with Ludovic and decided to go this way
> >> explicitly, please disregard this second nit.
> >> 
> >> I will also wait a day or two for any comments from Ludovic before
> >> applying.
> >
> > Thanks, I will wait for Ludovic to tell he's okay with overriding the
> > HAVE_* macros,
> 
> Yes, I agree with Andy, I think it’ll be nicer.
> 
> > and will send a format-patch formatted changes after that.
> 
> Cool, thank you!

Thanks, updated patch attached below.

>From a02b0c9a95ce286669b2f7b76beba9709e8d9601 Mon Sep 17 00:00:00 2001
From: Eli Zaretskii <e...@gnu.org>
Date: Sat, 25 Jun 2016 16:14:21 +0300
Subject: [PATCH] Provide support for open-process and related functions on
 MS-Windows

* libguile/w32-proc.c: New file, with MinGW support code for
scm_open_process, scm_kill, scm_getpriority, scm_setpriority,
scm_getaffinity, and scm_setaffinity.  Also, provides macros that
on Posix hosts are in sys/wait.h, like WIFEXITED and WTERMSIG, and
simple definitions for getuid, getgid, setuid, setgid, and
waitpid.

* libguile/posix.c [__MINGW32__]: Include w32-proc.c.
(scm_kill) [__MINGW32__]: Support killing subprocesses on MS-Windows.
(scm_status_exit_val, scm_getuid, scm_getegid): Don't exclude from
compilation with MinGW.
(scm_execl, scm_execle): Cast arguments of execv/execve to avoid
compiler warnings.
(scm_open_process): Condition parts specific to 'fork'-based
implementation with "#ifdef HAVE_FORK".
[__MINGW32__]: MinGW alternative to 'fork'-based implementation;
most of the supporting code is in w32-proc.c.
(scm_getpriority, scm_setpriority, scm_getaffinity)
(scm_setaffinity, scm_init_popen): Don't exclude from MinGW
compilation.
(scm_init_posix): Register scm_init_popen extension even if
HAVE_FORK is not defined.
---
 libguile/posix.c|  75 +++--
 libguile/w32-proc.c | 919 
 2 files changed, 968 insertions(+), 26 deletions(-)
 create mode 100644 libguile/w32-proc.c

diff --git a/libguile/posix.c b/libguile/posix.c
index 2654716..741867c 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -84,6 +84,10 @@
 #if HAVE_SYS_WAIT_H
 # include 
 #endif
+#ifdef __MINGW32__
+# include 
+#endif	/* __MINGW32__ */
+
 #ifndef WEXITSTATUS
 # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
 #endif
@@ -659,7 +663,7 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
 #else
   /* Mingw has raise(), but not kill().  (Other raw DOS environments might
  be similar.)  Use raise() when the requested pid is our own process,
- otherwise bomb.  */
+ otherwise TerminateProcess.  */
   if (scm_to_int (pid) == getpid ())
 {
   if (raise (scm_to_int (sig)) != 0)
@@ -673,6 +677,10 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
   goto err;
 }
 }
+#ifdef __MINGW32__
+  if (w32_kill_proc (scm_to_int (pid), scm_to_int (sig)) != 0)
+SCM_SYSERROR;
+#endif	/* __MINGW32__ */
 #endif
   return SCM_UNSPECIFIED;
 }
@@ -735,7 +743,6 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1, 0,
 #undef FUNC_NAME
 #endif /* HAVE_WAITPID */
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_status_exit_val, "status:exit-val", 1, 0, 0, 
 (SCM status),
 	"Return the exit status value, as would be set if a process\n"
@@ -786,7 +793,6 @@ SCM_DEFINE (scm_status_stop_sig, "status:stop-sig", 1, 0, 0,
 return SCM_BOOL_F;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 #ifdef HAVE_GETPPID
 SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
@@ -801,7 +807,6 @@ SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
 #endif /* HAVE_GETPPID */
 
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_getuid, "getuid", 0, 0, 0,
 (),
 	"Return an integer representing the current real user ID.")
@@ -905,10 +910,8 @@ SCM_DEFINE (scm_seteuid, "seteuid", 1, 0, 0,
   return SCM_UNSPECIFIED;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 
-#ifde

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: Andy Wingo <wi...@pobox.com>
> Cc: l...@gnu.org,  guile-devel@gnu.org
> Date: Sat, 25 Jun 2016 11:51:53 +0200
> 
> On Sat 25 Jun 2016 11:11, Eli Zaretskii <e...@gnu.org> writes:
> 
> > Here's the modified patch with the couple of changes requested in
> > response to the previous version:
> 
> Great!  I have two nits.  One, if it is possible for you, please attach
> the patch in the format that "git format-patch" makes.  That makes it
> easy to apply, otherwise I have to futz around with --author and I could
> accidentally fat-finger it and get it wrong.
> 
> Secondly, please make w32-proc override the definitions of
> HAVE_GETPRIORITY, HAVE_SETPRIORITY, HAVE_SCHED_GETAFFINITY, and
> HAVE_SCHED_SETAFFINITY.  That way you won't need this kind of change
> either:
> 
> > -#if HAVE_GETPRIORITY
> > +#if HAVE_GETPRIORITY || defined __MINGW32__
> 
> If you've already discussed this with Ludovic and decided to go this way
> explicitly, please disregard this second nit.
> 
> I will also wait a day or two for any comments from Ludovic before
> applying.

Thanks, I will wait for Ludovic to tell he's okay with overriding the
HAVE_* macros, and will send a format-patch formatted changes after
that.

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

Here's the modified patch with the couple of changes requested in
response to the previous version:

Author: Eli Zaretskii <e...@gnu.org>
Date:   Fri Jun 25 12:10:34 2016 +0300

Provide support for open-process and related functions on MS-Windows

* libguile/w32-proc.c: New file, with MinGW support code for
scm_open_process, scm_kill, scm_getpriority, scm_setpriority,
scm_getaffinity, and scm_setaffinity.  Also, provides macros that
on Posix hosts are in sys/wait.h, like WIFEXITED and WTERMSIG, and
simple definitions for getuid, getgid, setuid, setgid, and
waitpid.

* libguile/posix.c [__MINGW32__]: Include w32-proc.c.
(scm_kill) [__MINGW32__]: Support killing subprocesses on MS-Windows.
(scm_status_exit_val, scm_getuid, scm_getegid): Don't exclude from
compilation with MinGW.
(scm_execl, scm_execle): Cast arguments of execv/execve to avoid
compiler warnings.
(scm_open_process): Condition parts specific to 'fork'-based
implementation with "#ifdef HAVE_FORK".
[__MINGW32__]: MinGW alternative to 'fork'-based implementation;
most of the supporting code is in w32-proc.c.
(scm_getpriority, scm_setpriority, scm_getaffinity)
(scm_setaffinity, scm_init_popen): Don't exclude from MinGW
compilation.
(scm_init_posix): Register scm_init_popen extension even if
HAVE_FORK is not defined.

diff --git a/libguile/posix.c b/libguile/posix.c
index 2654716..741867c 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -84,6 +84,10 @@
 #if HAVE_SYS_WAIT_H
 # include 
 #endif
+#ifdef __MINGW32__
+# include 
+#endif /* __MINGW32__ */
+
 #ifndef WEXITSTATUS
 # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
 #endif
@@ -659,7 +663,7 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
 #else
   /* Mingw has raise(), but not kill().  (Other raw DOS environments might
  be similar.)  Use raise() when the requested pid is our own process,
- otherwise bomb.  */
+ otherwise TerminateProcess.  */
   if (scm_to_int (pid) == getpid ())
 {
   if (raise (scm_to_int (sig)) != 0)
@@ -673,6 +677,10 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
   goto err;
 }
 }
+#ifdef __MINGW32__
+  if (w32_kill_proc (scm_to_int (pid), scm_to_int (sig)) != 0)
+SCM_SYSERROR;
+#endif /* __MINGW32__ */
 #endif
   return SCM_UNSPECIFIED;
 }
@@ -735,7 +743,6 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1, 0,
 #undef FUNC_NAME
 #endif /* HAVE_WAITPID */
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_status_exit_val, "status:exit-val", 1, 0, 0, 
 (SCM status),
"Return the exit status value, as would be set if a process\n"
@@ -786,7 +793,6 @@ SCM_DEFINE (scm_status_stop_sig, "status:stop-sig", 1, 0, 0,
 return SCM_BOOL_F;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 #ifdef HAVE_GETPPID
 SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
@@ -801,7 +807,6 @@ SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
 #endif /* HAVE_GETPPID */
 
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_getuid, "getuid", 0, 0, 0,
 (),
"Return an integer representing the current real user ID.")
@@ -905,10 +910,8 @@ SCM_DEFINE (scm_seteuid, "seteuid", 1, 0, 0,
   return SCM_UNSPECIFIED;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 
-#ifdef HAVE_SETEGID
 SCM_DEFINE (scm_setegid, "setegid", 1, 0, 0,
 (SCM id),
"Sets the effective group ID to the integer @var{id}, provided the 
process\n"
@@ -931,7 +934,6 @@ SCM_DEFINE (scm_setegid, "setegid", 1, 0, 0,
 
 }
 #undef FUNC_NAME
-#endif
 
 
 #ifdef HAVE_GETPGRP
@@ -1141,7 +1143,7 @@ SCM_DEFINE (scm_execl, "execl", 1, 0, 1,
 
   exec_argv = scm_i_allocate_string_pointers (args);
 
-  execv (exec_file, exec_argv);
+  execv (exec_file, (char const * const *)exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1170,7 +1172,7 @@ SCM_DEFINE (scm_execlp, "execlp", 1, 0, 1,
 
   exec_argv = scm_i_allocate_string_pointers (args);
 
-  execvp (exec_file, exec_argv);
+  execvp (exec_file, (char const * const *)exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1204,7 +1206,8 @@ SCM_DEFINE (scm_execle, "execle", 2, 0, 1,
   exec_argv = scm_i_allocate_string_pointers (args);
   exec_env = scm_i_allocate_string_pointers (env);
 
-  execve (exec_file, exec_argv, exec_env);
+  execve (exec_file, (char const * const *)exec_argv,
+ (char const * const *)exec_env);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1246,6 +1249,7 @@ SCM_DEFINE (scm_fork, "primitive-fork", 0, 0, 0,
   return scm_from_int (pid);
 }
 #undef FUNC_NAME
+#endif /* HAVE_FORK */
 
 /* Since Guile uses threads, we have to be very careful to avoid calling
functions that are not async-signal-safe in the child.  That's why
@@ -1262,7 +1266,9 @@ scm_open_process (SCM mode, SCM prog, 

Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: Andy Wingo ,  guile-devel@gnu.org
> Date: Fri, 24 Jun 2016 13:49:17 +0200
> 
> > diff --git a/libguile/posix.c b/libguile/posix.c
> > index 2654716..35b920f 100644
> > --- a/libguile/posix.c
> > +++ b/libguile/posix.c
> > @@ -84,6 +84,10 @@
> >  #if HAVE_SYS_WAIT_H
> >  # include 
> >  #endif
> > +#ifdef __MINGW32__
> > +# include "w32-proc.c"
> > +#endif /* __MINGW32__ */
> 
> I’d have a slight preference for using AC_LIBSOURCE or a Makefile.am
> snippet to compile w32-proc.c separately (which means w32-proc.h should
> be added to provide declarations).

I'm not much of an expert on autotools, so I preferred to do this the
way I can understand and convince myself the code is correct.  I don't
mind to doing that your way, of course, but I'd prefer that someone
else does the refactoring, if possible.

> However this shouldn’t be a blocker (if the current approach is kept,
> use  rather than "w32-proc.c").

Great!

> > +#ifdef __MINGW32__
> > +  else
> > +{
> > +  HANDLE ph = OpenProcess (PROCESS_TERMINATE, 0, scm_to_int (pid));
> > +  int s = scm_to_int (sig);
> > +
> > +  if (!ph)
> > +   {
> > + errno = EPERM;
> > + goto err;
> > +   }
> > +  if (!TerminateProcess (ph, w32_signal_to_status (s)))
> > +   {
> > + errno = EINVAL;
> > + goto err;
> > +   }
> > +  CloseHandle (ph);
> > +}
> > +#endif /* __MINGW32__ */
> >  #endif
> >return SCM_UNSPECIFIED;
> 
> For consistency maybe this should go in a ‘kill’ function in w32-proc.c?

I can do that.  It's just that I thought such a short code fragment
doesn't need that, but I don't mind.

> Thanks a lot for taking the time to update the patch, and for forgiving
> our failure to handle it earlier.

Thanks for giving me another chance to submit this.

Support open-process and friends on MS-Windows

[Eli Zaretskii]

This is a re-spin of the patches last posted here:

  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00015.html

At Andy's suggestion, I've removed most of the Windows-specific code
to the new Windows-specific file w32-proc.c, leaving just the minimum
changes in posix.c itself.  The patch below is against the stable-2.0
branch in the Guile Git repository.

I hope we will be able to get this into the repository this time.

TIA

commit 44f8eebf9850431790b23b031f5b6e90fb3de777
Author: Eli Zaretskii <e...@gnu.org>
Date:   Fri Jun 24 12:45:02 2016 +0300

Provide support for open-process and related functions on MS-Windows

* libguile/w32-proc.c: New file, with MinGW support code for
scm_open_process, scm_getpriority, scm_setpriority,
scm_getaffinity, and scm_setaffinity.  Also, provides macros that
on Posix hosts are in sys/wait.h, like WIFEXITED and WTERMSIG, and
simple definitions for getuid, getgid, setuid, setgid, and
waitpid.

* libguile/posix.c [__MINGW32__]: Include w32-proc.c.
(scm_kill) [__MINGW32__]: Support killing subprocesses on MS-Windows.
(scm_status_exit_val, scm_getuid, scm_getegid): Don't exclude from
compilation with MinGW.
(scm_execl, scm_execle): Cast arguments of execv/execve to avoid
compiler warnings.
(scm_open_process): Condition parts specific to 'fork'-based
implementation with "#ifdef HAVE_FORK".
[__MINGW32__]: MinGW alternative to 'fork'-based implementation;
most of the supporting code is in w32-proc.c.
(scm_getpriority, scm_setpriority, scm_getaffinity)
(scm_setaffinity, scm_init_popen): Don't exclude from MinGW
compilation.
(scm_init_posix): Register scm_init_popen extension even if
HAVE_FORK is not defined.

diff --git a/libguile/posix.c b/libguile/posix.c
index 2654716..35b920f 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -84,6 +84,10 @@
 #if HAVE_SYS_WAIT_H
 # include 
 #endif
+#ifdef __MINGW32__
+# include "w32-proc.c"
+#endif /* __MINGW32__ */
+
 #ifndef WEXITSTATUS
 # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
 #endif
@@ -659,7 +663,7 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
 #else
   /* Mingw has raise(), but not kill().  (Other raw DOS environments might
  be similar.)  Use raise() when the requested pid is our own process,
- otherwise bomb.  */
+ otherwise TerminateProcess.  */
   if (scm_to_int (pid) == getpid ())
 {
   if (raise (scm_to_int (sig)) != 0)
@@ -673,6 +677,25 @@ SCM_DEFINE (scm_kill, "kill", 2, 0, 0,
   goto err;
 }
 }
+#ifdef __MINGW32__
+  else
+{
+  HANDLE ph = OpenProcess (PROCESS_TERMINATE, 0, scm_to_int (pid));
+  int s = scm_to_int (sig);
+
+  if (!ph)
+   {
+ errno = EPERM;
+ goto err;
+   }
+  if (!TerminateProcess (ph, w32_signal_to_status (s)))
+   {
+ errno = EINVAL;
+ goto err;
+   }
+  CloseHandle (ph);
+}
+#endif /* __MINGW32__ */
 #endif
   return SCM_UNSPECIFIED;
 }
@@ -735,7 +758,6 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1, 0,
 #undef FUNC_NAME
 #endif /* HAVE_WAITPID */
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_status_exit_val, "status:exit-val", 1, 0, 0, 
 (SCM status),
"Return the exit status value, as would be set if a process\n"
@@ -786,7 +808,6 @@ SCM_DEFINE (scm_status_stop_sig, "status:stop-sig", 1, 0, 0,
 return SCM_BOOL_F;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 #ifdef HAVE_GETPPID
 SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
@@ -801,7 +822,6 @@ SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
 #endif /* HAVE_GETPPID */
 
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_getuid, "getuid", 0, 0, 0,
 (),
"Return an integer representing the current real user ID.")
@@ -905,10 +925,8 @@ SCM_DEFINE (scm_seteuid, "seteuid", 1, 0, 0,
   return SCM_UNSPECIFIED;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 
-#ifdef HAVE_SETEGID
 SCM_DEFINE (scm_setegid, "setegid", 1, 0, 0,
 (SCM id),
"Sets the effective group ID to the integer @var{id}, provided the 
process\n"
@@ -931,7 +949,6 @@ SCM_DEFINE (scm_setegid, "setegid", 1, 0, 0,
 
 }
 #undef FUNC_NAME
-#endif
 
 
 #ifdef HAVE_GETPGRP
@@ -1141,7 +1158,7 @@ SCM_DEFINE (scm_execl, "execl", 1, 0, 1,
 
   exec_argv = scm_i_allocate_string_pointers (args);
 
-  execv (exec_file, exec_argv);
+  execv (exec_file, (char const * const *)exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1170,7 +1187,7 @@ SCM_DEFINE (scm_execlp, "execlp", 1, 0, 1,
 
   exec_argv = scm_i_allocate_string_pointers (args);
 
-  execvp (exec_file, exec_argv);
+  execvp (exec_file, (char const * const *)exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1204,7 +1221,8 @@ SCM_DEFINE (scm_execle,

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel <guile-devel@gnu.org>
> Date: Fri, 30 Oct 2015 15:53:27 +0100
> 
> Eli Zaretskii <e...@gnu.org> skribis:
> 
> > Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> > own private version in libguile/.  This causes link failures on
> > systems, such as MinGW, that lack mkstemp in their system libraries:
> >
> >CCLD libguile-2.0.la
> >  ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
> >  d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
> >  
> > .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: 
> > first defined here
> >  collect2.exe: error: ld returned 1 exit status
> >  Makefile:2242: recipe for target `libguile-2.0.la' failed
> >  make[3]: *** [libguile-2.0.la] Error 1
> >  make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
> >  Makefile:2162: recipe for target `all' failed
> >
> > I think the solution is simply remove mkstemp.c from libguile/, and
> > all its traces from the configury that causes its dependency to be
> > added to libguile/Makefile.  Not sure how to do the latter, though.
> 
> I’m ashamed of the delay but hey, better late than never.
> 
> This bug was reported independently at <http://bugs.gnu.org/21425> and a
> fix was committed just yesterday, along the lines of what you suggested
> (see commit efd8a43.)  Let me know what you think.

Thanks, looks good.

Re: Failure in test-suite/standalone/test-ffi test

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel 
> Date: Fri, 30 Oct 2015 15:59:00 +0100
> 
> >  In unknown file:
> > ?: 3 [primitive-load 
> > "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
> >  In ice-9/eval.scm:
> >   453: 2 [eval # ()]
> >   387: 1 [eval # ()]
> >  In unknown file:
> > ?: 0 [dynamic-func "strerror" #]
> >ERROR: In procedure dynamic-func:
> >  ERROR: In procedure dynamic-pointer: Symbol not found: strerror
> >  FAIL: test-ffi
> >
> > Does this test make some unportable assumptions about the 'strerror'
> > symbol?
> 
> Yes.
> 
> Since the test just tries to use a global symbol exported from libc, we
> could use something else.

The equivalent of libc on Windows is a dynamic library, so these
functions are never statically linked into a program.

> Would ‘gethostname’ work on Windows?  That is, does:
> 
>   (dynamic-func "gethostname" (dynamic-link))
> 
> return a valid pointer?

No, that fails, but this works:

  (dynamic-func "strerror" (dynamic-link "msvcrt"))
=> #

(msvcrt.dll is the Windows equivalent of libc.)

So I think global references will always fail on Windows, so we should
simply skip this part of the test on Windows.

Thanks.

Re: [RFC] Block all async signals used by gdb when initializing Guile

[Eli Zaretskii]

> Date: Mon, 31 Aug 2015 22:05:59 -0700
> From: Doug Evans <xdj...@gmail.com>
> Cc: Mark Kettenis <mark.kette...@xs4all.nl>, 
>   "gdb-patc...@sourceware.org" <gdb-patc...@sourceware.org>, guile-devel 
> <guile-devel@gnu.org>
> 
> On Sat, Aug 29, 2015 at 7:37 PM, Eli Zaretskii <e...@gnu.org> wrote:
> >> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
> >> From: Mark Kettenis <mark.kette...@xs4all.nl>
> >> CC: e...@gnu.org, gdb-patc...@sourceware.org, guile-devel@gnu.org
> >>
> >> I suppose blocking these in the threads that guile starts is necessary
> >> because that is the only way to guarantee that those signals will be
> >> delivered to the main gdb thread on POSIX systems.
> >>
> >> On Windows you probably need to do something completely different.
> >
> > I might be missing something, because I don't see why.
> 
> The goal here is to block these signals from being sent to the threads
> that Guile (or more specifically libgc) creates.

Why only libgc?  Don't we want to block these signals in any Guile
code invoked later by GDB?

> Not sure how to do that on windows.

That problem doesn't exist on Windows, but what about Guile
application threads launched later?

Re: [RFC] Block all async signals used by gdb when initializing Guile

[Eli Zaretskii]

> Date: Tue, 1 Sep 2015 08:22:44 -0700
> From: Doug Evans <xdj...@gmail.com>
> Cc: Mark Kettenis <mark.kette...@xs4all.nl>, 
>   "gdb-patc...@sourceware.org" <gdb-patc...@sourceware.org>, guile-devel 
> <guile-devel@gnu.org>
> 
> On Tue, Sep 1, 2015 at 7:35 AM, Eli Zaretskii <e...@gnu.org> wrote:
> >> The goal here is to block these signals from being sent to the threads
> >> that Guile (or more specifically libgc) creates.
> >
> > Why only libgc?  Don't we want to block these signals in any Guile
> > code invoked later by GDB?
> 
> Any threads created later are required to DTRT themselves.
> [Same as on python.]

Then I guess this problem can be ignored for Windows.

Re: [RFC] Block all async signals used by gdb when initializing Guile

[Eli Zaretskii]

 From: Doug Evans xdj...@gmail.com
 cc: guile-devel@gnu.org
 Date: Sat, 29 Aug 2015 10:22:11 -0700
 
 --- a/gdb/guile/guile.c
 +++ b/gdb/guile/guile.c
 @@ -847,7 +847,7 @@ _initialize_guile (void)
  #if HAVE_GUILE
{
  #ifdef HAVE_SIGPROCMASK
 -sigset_t sigchld_mask, prev_mask;
 +sigset_t guile_init_mask, prev_mask;
  #endif
  
  /* The Python support puts the C side in module _gdb, leaving the 
 Python
 @@ -867,9 +867,23 @@ _initialize_guile (void)
 have SIGCHLD blocked.  PR 17247.
 Really libgc and Guile should do this, but we need to work with
 libgc 7.4.x.  */
 -sigemptyset (sigchld_mask);
 -sigaddset (sigchld_mask, SIGCHLD);
 -sigprocmask (SIG_BLOCK, sigchld_mask, prev_mask);
 +sigemptyset (guile_init_mask);
 +sigaddset (guile_init_mask, SIGCHLD);
 +/* Also block other asynchronous signals used by GDB.  See event-top.c.
 +   Really we want to block every signal here except for those 
 specifically
 +   used by Guile (e.g., GC threads), but this is safer for now.  */
 +sigaddset (guile_init_mask, SIGINT);
 +sigaddset (guile_init_mask, SIGTERM);
 +#ifdef SIGQUIT
 +sigaddset (guile_init_mask, SIGQUIT);
 +#endif
 +#ifdef SIGHUP
 +sigaddset (guile_init_mask, SIGHUP);
 +#endif
 +#ifdef SIGWINCH
 +sigaddset (guile_init_mask, SIGWINCH);
 +#endif
 +sigprocmask (SIG_BLOCK, guile_init_mask, prev_mask);
  #endif

What about platforms that don't have sigprocmask, but do have SIGINT?
Don't we want to block SIGINT on those platforms?

Re: [RFC] Block all async signals used by gdb when initializing Guile

[Eli Zaretskii]

 Date: Sat, 29 Aug 2015 13:39:55 -0700
 From: Doug Evans xdj...@gmail.com
 Cc: gdb-patc...@sourceware.org gdb-patc...@sourceware.org, guile-devel 
 guile-devel@gnu.org
 
 On Sat, Aug 29, 2015 at 1:16 PM, Eli Zaretskii e...@gnu.org wrote:
  Date: Sat, 29 Aug 2015 12:20:24 -0700
  From: Doug Evans xdj...@gmail.com
  Cc: gdb-patc...@sourceware.org gdb-patc...@sourceware.org, guile-devel 
  guile-devel@gnu.org
 
   What about platforms that don't have sigprocmask, but do have SIGINT?
   Don't we want to block SIGINT on those platforms?
 
  Do they have threads
 
  They might.  (The only way I've succeeded to have a working Guile on
  Windows was to disable threads, but I hope that bug will be fixed one
  day.)
 
  and how does one block SIGINT on those platforms?
 
  With a call to 'signal', I guess.
 
 I'm guessing that won't work here, we'll need something else.

I don't understand why.  Can you explain?  Maybe I'm missing
something.

 The issue is we need the threads that guile starts
 to have these signals blocked. Then after guile init
 returns we unblock the signals.

Inhibit SIGINT ech time before calling Guile and restore it after
Guile returns.  Wouldn't that do what you want?

Re: [RFC] Block all async signals used by gdb when initializing Guile

[Eli Zaretskii]

 Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
 From: Mark Kettenis mark.kette...@xs4all.nl
 CC: e...@gnu.org, gdb-patc...@sourceware.org, guile-devel@gnu.org
 
 I suppose blocking these in the threads that guile starts is necessary
 because that is the only way to guarantee that those signals will be
 delivered to the main gdb thread on POSIX systems.
 
 On Windows you probably need to do something completely different.

I might be missing something, because I don't see why.

Re: Exception-safety for C++ code integrated with Guile.

[Eli Zaretskii]

 From: Taahir Ahmed ahmed.taa...@gmail.com
 Cc: guile-devel@gnu.org
 Date: Tue, 24 Feb 2015 13:21:48 -0600
 
 From looking at the libunwind source, the only os-dependent code is a single 
 function for looking through an elf image.

So it's only good for platforms that use ELF?  If so, none of Windows
GNU-based environments will do, they all use PE-COFF.

 What are the platforms that Guile supports? (I can't find a comprehensive 
 list 
 anywhere).

That's a good question, I hope that people here will know the answer
(I don't, sorry).

Re: Exception-safety for C++ code integrated with Guile.

[Eli Zaretskii]

 From: Taahir Ahmed ahmed.taa...@gmail.com
 Date: Mon, 23 Feb 2015 15:59:43 -0600
 
   2) Replace all uses of set/longjmp with replacements (call them
  eh_setjmp and eh_longjmp) that are based on libunwind [1].
  eh_longjmp uses libunwind to walk up the stack, calling each
  frame's personality routine [2].  This approach will requires a
  platform that uses DWARF exception handling (i.e., everybody
  except non-Cygwin Windows).

mingw.org's MinGW uses DWARF exception handling.  Perhaps you are
thinking of MinGW64, which (AFAIK) indeed uses eh by default, but can
be configured to use DWARF.

As for libunwind, are you sure it supports enough platforms to be a
useful alternative?  AFAIK, the last official release supports only
IA-64, and even the current development version in git repo basically
supports GNU/Linux and almost nothing else (2 FreeBSD targets and 1 on
HP-UX).

Re: inotify ffi

[Eli Zaretskii]

 Date: Wed, 12 Nov 2014 01:59:13 +0800
 From: Chaos Eternal chaoseter...@shlug.org
 
 and it is not very portable.
 
 
 On Wed, Nov 12, 2014 at 1:55 AM, Chaos Eternal chaoseter...@shlug.org wrote:
  i wrote a FFI to inotify system call.
 
  https://github.com/ChaosEternal/guile-inotify2
 
  procedures:
  * inotify-init
  * inotify-init1
  * inotify-add-watch
  * inotify-rm-watch
  * inotify-read-port
 
  the errno handle is unreliable, use with caution.
 
  License: LGPL v3

Why not use the glib file monitoring instead?  It is much more
portable, and has an inotify back-end AFAIK.

Re: inotify ffi

[Eli Zaretskii]

 From: David Thompson dthomps...@worcester.edu
 Cc: guile-devel@gnu.org
 Date: Tue, 11 Nov 2014 15:05:05 -0500
 
 Eli Zaretskii e...@gnu.org writes:
 
  Why not use the glib file monitoring instead?  It is much more
  portable, and has an inotify back-end AFAIK.
 
 If you're only after inotify, glib seems like a heavy dependency.

But inotify is practically a single-OS solution.  How does it make
sense for Guile to support file notifications only on one platform?
That effectively limits packages that use Guile as an extension
language to that single platform.

Anyway, Guile already depends on quite a few external libraries, so
adding a few more doesn't sound a big deal to me, FWIW.

Re: Fix link failure in test-suite/standalone

[Eli Zaretskii]

 From: Mark H Weaver m...@netris.org
 Cc: guile-devel@gnu.org
 Date: Sun, 21 Sep 2014 23:30:59 -0400
 
 Eli Zaretskii e...@gnu.org writes:
 
  Linking test-scm-take-locale-symbol fails on systems that need
  rpl_strdup from gnulib.  Here's the fix:
 
  --- test-suite/standalone/Makefile.am~0 2014-03-20 10:06:33.0 
  +0200
  +++ test-suite/standalone/Makefile.am   2014-08-16 14:56:02.828125000 
  +0300
  @@ -179,7 +179,7 @@
   # test-scm-take-locale-symbol
   test_scm_take_locale_symbol_SOURCES = test-scm-take-locale-symbol.c
   test_scm_take_locale_symbol_CFLAGS = ${test_cflags}
  -test_scm_take_locale_symbol_LDADD = $(LIBGUILE_LDADD)
  +test_scm_take_locale_symbol_LDADD = $(LIBGUILE_LDADD) 
  $(top_builddir)/lib/libgnu.la
   check_PROGRAMS += test-scm-take-locale-symbol
   TESTS += test-scm-take-locale-symbol
 
 This is now done in commit b38c19a5a5935dc5b874625767ed4951452f46c2 on
 the stable-2.0 branch.

Thanks!

Re: Dijkstra's Methodology for Secure Systems Development

[Eli Zaretskii]

 From: Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com
 Date: Sat, 20 Sep 2014 14:46:01 +0200
 Cc: Ian Grant ian.a.n.gr...@googlemail.com, guile-devel 
 guile-devel@gnu.org
  If there are some people accessing my files, why should I feel
  unfomfortable with that?  Why can't I trust that someome with such
  great power isn't going to be mean and evil?
 
 I always like to say, there are no James Bond villains on Earth.  The
 Hollywood trope of a sociopathic villain who's consciously evil for the
 sake of it is a big distraction from the fact that groups like the Nazi
 party or people like Joseph Stalin have in fact existed and came into
 positions of power in our very real world.  And they didn't feel they
 were evil; they genuinely believed they were doing the right thing.  How
 long has it been since such a scandal of humanity last happened?  Is
 it really thoroughly implausible that it would happen again?  Has it
 even really stopped happening entirely, or is one of the most powerful
 countries on the world supporting (even if indirectly) the bombardment
 of civilians and the torture of captives in the Middle East right now?

Evil is not about right and wrong.  Evil is about moral and immoral,
lawful and unlawful.  If you don't understand the fundamental
difference between those categories, perhaps you should refrain from
talking about Hitler, Stalin, and bombardment of civilians.  Certainly
here, where you yourself admitted this is OT.

Re: Dijkstra's Methodology for Secure Systems Development

[Eli Zaretskii]

 From: Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com
 Cc: godek.mac...@gmail.com,  ian.a.n.gr...@googlemail.com,  
 guile-devel@gnu.org
 Date: Sat, 20 Sep 2014 18:45:49 +0200
 
 Eli Zaretskii e...@gnu.org writes:
 
  Evil is not about right and wrong.  Evil is about moral and immoral,
  lawful and unlawful.  If you don't understand the fundamental
  difference between those categories, perhaps you should refrain from
  talking about Hitler, Stalin, and bombardment of civilians.
 
 If any of those words have well-defined semantics in a widely accepted
 school of thought, then I didn't know that.

And right and wrong, do they have well-defined semantics?  No,
they don't, and yet you used them freely to make your point.  How's
that for consistency?

Your point was that villains act thinking they are doing the right
thing.  But that's exactly the weakness of right and wrong: they
are intrinsically POV-relative.  When you and me have a conflict of
interests, what is right for you is wrong for me, and vice versa.

Use the words I suggested, and this problem disappears, even if others
remain.

 (Except for laws, though I'm confused on how they're relevant at
 all.)

Perhaps you don't understand why we have laws, then.

 I was simply going on the assumption that we all agree on
 ethics based on human well-being

Oh, come on, grow up!  This kind of naiveté will get you nowhere.
Tell me: when someone shoots a burglar who broke into their house and
threatened them with a weapon, what exactly happens to the human
well-being of the burglar?

 It would follow that we need to be careful not to give power to
 those disagreeing with that.  If the assumption was wrong, then
 never mind.

We can all agree on this assumption, but the question is what do you
do in practice with that?

Re: Dijkstra's Methodology for Secure Systems Development

[Eli Zaretskii]

 From: Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com
 Cc: godek.mac...@gmail.com,  ian.a.n.gr...@googlemail.com,  
 guile-devel@gnu.org
 Date: Sat, 20 Sep 2014 21:11:33 +0200
 
  Use the words I suggested, and this problem disappears, even if others
  remain.
 
 Well, that's false.  Many people think it's amoral to be homosexual.
 And many countries' laws forbid it, too.

Yes, and the Swiss think it's amoral to litter.  So what?  How is this
related to the issues at hand?

Are there countries that have laws that allow to freely kill, or break
into other's houses, or summarily hold people in captivity and torture
them?  No, there aren't.  So, for the purpose of this discussion, we
all agree what is mormal and what is not.

  (Except for laws, though I'm confused on how they're relevant at
  all.)
 
  Perhaps you don't understand why we have laws, then.
 
 I said that because laws are just the written down form of what a group
 of people think is right.

Yes, but why do we bother to have laws at all?  Think about this, and
perhaps you will arrive at a much more useful explanation for why we
have laws.

  Tell me: when someone shoots a burglar who broke into their house and
  threatened them with a weapon, what exactly happens to the human
  well-being of the burglar?
 
 It's traded off for the well-being of the home owner, and probably for
 the well-being of future possible victims.  Ethics calculus. ;-)

Right, and Stalin traded off well-being of his victims for that of
himself and his satraps.  And Hitler traded off the well-being of
Jews for that of the Aryans.  Your well-being methodology is a dead
end: using it, you will never be able to decide whom to support and
whom to condemn in a given conflict.

 Anyway, I now suspect that the discussion might go on for dozens of
 mails if we don't just abruptly stop; I had previously hoped that we
 would instead quickly either agree or agree to disagree on clear points.
 Or maybe we can just agree to disagree on the meaning and importance of
 laws?  The other points seem cleared up, I think.  I'm desperately
 looking for a way to end the discussion without requiring either side to
 accept giving the other the last word, so help me a little...

OK, I will now stop.

Re: [ANN] guile-colorized-0.0.2 released

[Eli Zaretskii]

 From: Nala Ginrut nalagin...@gmail.com
 Cc: guile-u...@gnu.org, guile-devel@gnu.org
 Date: Wed, 17 Sep 2014 18:33:50 +0800
 
  Too bad it requires an ANSI-capable terminal, and therefore will not
  work on MS-Windows.
 
 Oh, I'm not familiar with Windows, what's the solution on it?

You cannot do that from Scheme, I think, you need to call special
functions to set foreground and background colors from the C level.

This would require Scheme procedures to set console colors of the
text, and then your package would need to call them, instead of
constructing SGR sequences on the flight.

 Or patches welcome. ;-)

I'll see what I can do.

Thanks.

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

Ping!  (1 month)

 Date: Fri, 29 Aug 2014 11:29:29 +0300
 From: Eli Zaretskii e...@gnu.org
 
 Ping!
 
  Date: Sat, 16 Aug 2014 14:42:54 +0300
  From: Eli Zaretskii e...@gnu.org
  
  Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
  own private version in libguile/.  This causes link failures on
  systems, such as MinGW, that lack mkstemp in their system libraries:
  
 CCLD libguile-2.0.la
   ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
   d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
   
  .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: 
  first defined here
   collect2.exe: error: ld returned 1 exit status
   Makefile:2242: recipe for target `libguile-2.0.la' failed
   make[3]: *** [libguile-2.0.la] Error 1
   make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
   Makefile:2162: recipe for target `all' failed
  
  I think the solution is simply remove mkstemp.c from libguile/, and
  all its traces from the configury that causes its dependency to be
  added to libguile/Makefile.  Not sure how to do the latter, though.