> Date: Thu, 27 Feb 2025 16:55:54 + (UTC)
> From: Mike Gran
> Cc: "hah...@hahnjo.de"
>
> - need to make sure that dlopen searches PATH on Win32
This is guaranteed by the algorithm used by Windows APIs that load
DLLs (which dlopen calls) -- assuming that dlopen you use is the one
that comes
> From: Jean Abou Samra
> Cc: r...@defaultvalue.org, guile-devel@gnu.org
> Date: Sun, 07 Jul 2024 17:16:31 +0200
>
> There are non-trivial backwards compatibility implications. To give
> a concrete case: LilyPond definitely has code that would break if
> passed a string whose "conversion to UTF-8
> Cc: "j...@abou-samra.fr" ,
> "r...@defaultvalue.org" ,
> "guile-devel@gnu.org"
> From: Maxime Devos
> Date: Sun, 7 Jul 2024 16:59:10 +0200
>
> >> >> Guile is a Scheme implementation, bound by Scheme standards and
> >> >> compatibility
> >> >> with other Scheme implementations (a
> Cc: "r...@defaultvalue.org" ,
> "guile-devel@gnu.org"
> From: Maxime Devos
> Date: Sun, 7 Jul 2024 13:35:27 +0200
>
> >> Guile is a Scheme implementation, bound by Scheme standards and
> >> compatibility
> >> with other Scheme implementations (and backwards compatibility too).
> >
> >Y
> From: Jean Abou Samra
> Cc: guile-devel@gnu.org
> Date: Sun, 07 Jul 2024 12:03:06 +0200
>
> Le dimanche 07 juillet 2024 à 08:33 +0300, Eli Zaretskii a écrit :
> >
> > - The internal representation is a superset of UTF-8, in that it
> > is capable of
> From: Rob Browning
> Date: Sat, 06 Jul 2024 15:32:17 -0500
>
> * Problem
>
> System data like environment variables, user names, group names, file
> paths and extended attributes (xattr), etc. are on some systems (like
> Linux) binary data, and may not be encodable as a string in the current
>
> 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
> 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 ezwinp
> 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
> 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
> 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 *al
> 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: 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/Christo
> From: Andy Wingo
> Cc: guile-us...@gnu.org, guile-devel@gnu.org
> Date: Sat, 23 Jun 2018 22:07:24 +0200
>
> > MS-Windows (MinGW) doesn't have a C99 compliant C library, although
> > quite a few of what's needed is present.
>
> Hard to say :) I think my questions are limited to, in decreasing
> 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
> 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
> 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-
> 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.
> 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 a
> 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:346
> 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-mingw
> 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/m
> 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 altogeth
> 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 w
> 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/pr
> 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 p
> From: Andy Wingo
> 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 writes:
>
> > Ping! (2 weeks)
>
> Tx for the ping, and good idea! I ended up applying something
> similar -- I
> 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.
Ping! (2 weeks)
> Date: Sat, 13 Aug 2016 14:55:27 +0300
> From: Eli Zaretskii
> Cc: wi...@pobox.com, guile-devel@gnu.org
>
> > Date: Sat, 13 Aug 2016 12:11:33 +0300
> > From: Eli Zaretskii
> > Cc: wi...@pobox.com, guile-devel@gnu.org
> >
> > > F
> Date: Sat, 13 Aug 2016 12:11:33 +0300
> From: Eli Zaretskii
> Cc: wi...@pobox.com, guile-devel@gnu.org
>
> > From: Mark H Weaver
> > Cc: wi...@pobox.com, guile-devel@gnu.org
> > Date: Wed, 10 Aug 2016 13:03:09 -0400
> >
> > Eli Zaretskii writes:
&
> From: Mark H Weaver
> Cc: wi...@pobox.com, guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 13:03:09 -0400
>
> Eli Zaretskii writes:
>
> >> Date: Wed, 10 Aug 2016 17:26:15 +0300
> >> From: Eli Zaretskii
> >> Cc: wi...@pobox.com, guile-devel@g
> 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 stati
> From: Mark H Weaver
> Cc: guile-devel@gnu.org
> Date: Wed, 10 Aug 2016 02:49:08 -0400
>
> Hi Eli,
>
> Eli Zaretskii writes:
>
> > CC libguile_2.0_la-socket.lo
> > socket.c: In function 'scm_fill_sockaddr':
> > socket.c:7
> Date: Wed, 10 Aug 2016 17:26:15 +0300
> From: Eli Zaretskii
> 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?
> 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, be
> 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 pla
> 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__
> >> > +
> 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
> 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 libra
> 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 no
> 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, unle
> From: Andy Wingo
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 22:57:02 +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?
> From: Andy Wingo
> Cc: guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 22:49:03 +0200
>
> On Sat 16 Jul 2016 19:12, Eli Zaretskii writes:
>
> > The patch to shut up these warnings is below. OK to commit?
> >
> > --- libguile/null-threads.h~0
> 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 thi
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
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 symlin
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 she
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.
Ping!
> Date: Sat, 16 Jul 2016 20:16:35 +0300
> From: 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-v
Ping!
> Date: Sat, 16 Jul 2016 20:12:22 +0300
> From: 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,
>
Ping!
> Date: Sat, 16 Jul 2016 20:18:26 +0300
> From: 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-f
> 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?
>
> > T
> 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
> Date: Sun, 17 Jul 2016 05:37:24 +0300
> From: Eli Zaretskii
> 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 ap
> From: Andy Moreton
> Date: Sat, 16 Jul 2016 22:40:38 +0100
>
> On Sat 16 Jul 2016, Eli Zaretskii wrote:
>
> > The processors and OS versions of the emulated 'uname' need an update;
> > the patch below does that:
>
> This uses GetVersionEx, whic
> 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, availa
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?
--- libgui
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 de
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/nul
> Date: Sat, 16 Jul 2016 16:24:46 +0300
> From: Eli Zaretskii
> Cc: m...@netris.org, l...@gnu.org, guile-devel@gnu.org
>
> Is it okay to push what I have now, and remove all the tabs from
> posix-w32.c (not just those I added) in a follow-up commit?
Never mind, I just did that.
Thanks.
> 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 wi
> 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 fr
> From: Andy Wingo
> Cc: m...@netris.org, l...@gnu.org, guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 13:32:04 +0200
>
> On Sat 16 Jul 2016 12:54, Eli Zaretskii writes:
>
> > Here's the first cut. (I will rework it into git-format-patch form,
> > or commi
current stable-2.0 are attached.
>From 8a1e4631fc2dddf5ca63039b4a77ae0d33d3cb90 Mon Sep 17 00:00:00 2001
From: Eli Zaretskii
Date: Sat, 16 Jul 2016 14:17:25 +0300
Subject: [PATCH] Open temporary files in binary mode on MS-Windows
* libguile/filesys.c (scm_mkstemp) [__MINGW32__]: Make sure the
te
e, 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
alrea
> 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 an
> From: Andy Wingo
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:58:39 +0200
>
> On Sat 16 Jul 2016 09:27, Eli Zaretskii writes:
>
> > 2016-07-16 Eli Zaretskii
> >
> > * libguile/posix-w32.c (uname): Update to modern processors (ia64
> >
> 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
> 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 evid
The processors and OS versions of the emulated 'uname' need an update;
the patch below does that:
2016-07-16 Eli Zaretskii
* libguile/posix-w32.c (uname): Update to modern processors (ia64
and x86_64) and OS versions (Vista to Windows 10). Delete
trailing
> 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.
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: not
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]
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 messa
> 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 cou
"./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
> From: Andy Wingo
> 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 writes:
>
> >> > The process ID is indeed an int, but my code hides a process handle
> >> &g
> From: Andy Wingo
> 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 writes:
>
> >> But in reality the getuid is of this form:
> >>
> >> (define (load
> 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
> bui
> From: Andy Wingo
> Cc: guile-devel@gnu.org, l...@gnu.org, m...@netris.org
> Date: Mon, 11 Jul 2016 23:51:17 +0200
>
> I have reworked Guile a bit in anticipation of your patch and in the end
> reworked your patch a bit too. Please fetch git and see how things are
> working for you, first -- it
> 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 writes:
> >> >>> > +# define getuid() (500) /* Local Administrator
> From: l...@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii , wi...@pobox.com, guile-devel@gnu.org
> Date: Tue, 05 Jul 2016 10:04:23 +0200
>
> Mark H Weaver skribis:
>
> > Eli Zaretskii writes:
> >
> >>> From: Mark H Weaver
> >>>
> 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
> Date: Sun, 03 Jul 2016 06:47:37 +0300
> From: Eli Zaretskii
> 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
> From: Mark H Weaver
> 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 writes:
> > +# define getuid() (500) /* Local Administrator */
> > +# define getgi
> 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.)
> 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
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 a02b0c9a95ce286669b2f7
> From: Andy Wingo
> 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 writes:
>
> > Here's the modified patch with the couple of changes requested in
> > response to the previous ve
Here's the modified patch with the couple of changes requested in
response to the previous version:
Author: Eli Zaretskii
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
> 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
> From: Andy Wingo
> Cc: l...@gnu.org, guile-devel@gnu.org
> Date: Fri, 24 Jun 2016 12:45:36 +0200
>
> Thanks!
>
> I think it looks pretty good. I wouldn't mind committing as-is. I
> would like to hear what Ludovic or Mark thinks before doing do; WDYT?
It's obviously your call how to proceed
self. 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
Date: Fri Jun 24 12:45:02 2016 +0300
Provide support for open-p
> 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 # ()
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel
> Date: Fri, 30 Oct 2015 15:53:27 +0100
>
> Eli Zaretskii 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
> Date: Tue, 1 Sep 2015 08:22:44 -0700
> From: Doug Evans
> Cc: Mark Kettenis ,
> "gdb-patc...@sourceware.org" , guile-devel
>
>
> On Tue, Sep 1, 2015 at 7:35 AM, Eli Zaretskii wrote:
> >> The goal here is to block these signals from being sent
> Date: Mon, 31 Aug 2015 22:05:59 -0700
> From: Doug Evans
> Cc: Mark Kettenis ,
> "gdb-patc...@sourceware.org" , guile-devel
>
>
> On Sat, Aug 29, 2015 at 7:37 PM, Eli Zaretskii wrote:
> >> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
> &g
> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
> From: Mark Kettenis
> 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
> Date: Sat, 29 Aug 2015 13:39:55 -0700
> From: Doug Evans
> Cc: "gdb-patc...@sourceware.org" , guile-devel
>
>
> On Sat, Aug 29, 2015 at 1:16 PM, Eli Zaretskii wrote:
> >> Date: Sat, 29 Aug 2015 12:20:24 -0700
> >> From: Doug Evans
>
> Date: Sat, 29 Aug 2015 12:20:24 -0700
> From: Doug Evans
> Cc: "gdb-patc...@sourceware.org" , guile-devel
>
>
> > 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
1 - 100 of 222 matches
Mail list logo
