Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: Eli Zaretskii , guile-user@gnu.org > Date: Wed, 19 Jun 2013 21:26:34 +0200 > > > diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test > > index 9b1c6c0..758f8f6 100644 > > --- a/test-suite/tests/ports.test > > +++ b/test-suite/tests/p

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: guile-user@gnu.org > Date: Wed, 19 Jun 2013 21:28:19 +0200 > > > I know. I didn't want to go as far as asking to not use UTF-8 in the > > tarball as well (although given the lack of characters in the docs > > that really need UTF-8, that would not be s

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> From: l...@gnu.org (Ludovic Courtès) [...] >> There’s a gdbinit file in Guile that you can load to get a few helper >> functions. > > At first I wanted to say I was blind not seeing it, but then I > realized that this file is not in the tarball, only in the > repositor

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: guile-user@gnu.org >> Date: Tue, 18 Jun 2013 22:19:13 +0200 >> >> > As long as we are on the topic of the Info docs: producing Info >> > manuals with UTF-8 encoded characters is not a good idea for the MinGW >> > build, becaus

Re: guile 2.0.9 build on mingw

Hi Mark! Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Eli Zaretskii skribis: >> >>> It's due to the CRLF thing. These files are open in the "w" mode, but >>> then read using the "rb" mode. So the CR character is left after the >>> newline is stripped, and botches the c

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

Mark H Weaver skribis: > Eli Zaretskii writes: >> Why isn't the signal delivery thread launched at program start > > The signal delivery thread is not launched until the first signal > handler is installed. This would seem sensible if not for the fact that > it is always launched at exit, which

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

Hi Mark and Eli, On Tue, Jun 18, 2013 at 5:51 PM, Mark H Weaver wrote: > Could you help us understand some code you added to Guile in 2007? Wow, that was a long time ago! :) > Julian, can you remember why you did this? I don't understand the > comment above. What does "it" refer to? I woul

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Tue, 18 Jun 2013 22:45:34 +0200 > > > Btw, is there documentation anywhere about how to use the GDB > > interface functions in Guile? I sometimes need to display Scheme > > values while debugging, and I see

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

> From: Mark H Weaver > Cc: Eli Zaretskii , l...@gnu.org (Ludovic Courtès), > guile-user@gnu.org > Date: Tue, 18 Jun 2013 17:51:38 -0400 > > The signal delivery thread is not launched until the first signal > handler is installed. This would seem sensible if not for the fact that > it is always

Re: guile 2.0.9 build on mingw

> From: Mark H Weaver > Cc: Eli Zaretskii , guile-user@gnu.org > Date: Tue, 18 Jun 2013 18:28:13 -0400 > > I think this is a bad idea for multiple reasons: > > * Handling of alternate line endings does not belong here; it belongs in > a transcoder of some sort. > > * This solution partially

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Tue, 18 Jun 2013 22:45:34 +0200 > > I think this patch solves the problem: > > diff --git a/libguile/rdelim.c b/libguile/rdelim.c > index 9d14967..9f16c69 100644 > --- a/libguile/rdelim.c > +++ b/libguile/rd

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: guile-user@gnu.org > Date: Tue, 18 Jun 2013 22:19:13 +0200 > > > As long as we are on the topic of the Info docs: producing Info > > manuals with UTF-8 encoded characters is not a good idea for the MinGW > > build, because the Windows console does not s

Re: guile 2.0.9 build on mingw

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Eli Zaretskii skribis: > >> It's due to the CRLF thing. These files are open in the "w" mode, but >> then read using the "rb" mode. So the CR character is left after the >> newline is stripped, and botches the comparison. The debug lines yo

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

Hi Julian, Could you help us understand some code you added to Guile in 2007? Eli Zaretskii writes: > Why isn't the signal delivery thread launched at program start The signal delivery thread is not launched until the first signal handler is installed. This would seem sensible if not for the f

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: m...@netris.org, guile-user@gnu.org >> Date: Sun, 16 Jun 2013 16:59:19 +0200 >> >> > Running ports.test >> > FAIL: ports.test: file: binary mode ignores port encoding >> > FAIL: ports.test: file: binary mode ig

Re: guile 2.0.9 build on mingw

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

Re: guile 2.0.9 build on mingw

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

Re: guile 2.0.9 build on mingw

> From: Mark H Weaver > Cc: l...@gnu.org, guile-user@gnu.org > Date: Mon, 17 Jun 2013 11:45:51 -0400 > > Eli Zaretskii writes: > > The bug report at http://bugs.gnu.org/14171 says that when Guile is > > compiled with enable-posix, it "can't start the REPL". Can someone > > please show me a sim

Re: guile 2.0.9 build on mingw

Hi Eli, Eli Zaretskii writes: > The bug report at http://bugs.gnu.org/14171 says that when Guile is > compiled with enable-posix, it "can't start the REPL". Can someone > please show me a simple way of trying that? Just run Guile in such a way that would lead to an interactive Guile prompt, e.g

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 16:59:19 +0200 > > > Running ports.test > > FAIL: ports.test: file: binary mode ignores port encoding > > FAIL: ports.test: file: binary mode ignores file coding declaration >

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 21:50:40 +0200 > > > Please find the changes to do this below. I removed most of the > > HAVE_POSIX ifdef's, as they are no longer needed. > > Sorry I had overlooked this one. It looks nic

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> Date: Tue, 11 Jun 2013 19:53:21 +0300 >> From: Eli Zaretskii >> Cc: l...@gnu.org, guile-user@gnu.org >> >> Btw, --disable-posix disables too much, for no good reason. E.g., it >> removes such innocent and important functionalities as "chdir", >> "open", and "close".

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: m...@netris.org, guile-user@gnu.org >> Date: Sun, 16 Jun 2013 16:55:55 +0200 >> >> > The tests in foreign.test failed because they need to be able to call >> > C functions in Guile itself. According to libtool documentation,

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 17:04:15 +0200 > > Eli Zaretskii skribis: > > > The changes below work around the lack of h_error on Windows: > > > > --- libguile/net_db.c~0 2013-03-25 23:44:46.0 +0200 > > +++

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 16:55:55 +0200 > > > The tests in foreign.test failed because they need to be able to call > > C functions in Guile itself. According to libtool documentation, this > > requires to link with

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 16:44:55 +0200 > > In the future, could you send patches as produced by ‘git format-patch’, > with a ChangeLog-style commit log? That would allow us to preserve > authorship, and make it eas

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, guile-user@gnu.org > Date: Sun, 16 Jun 2013 16:36:50 +0200 > > > The patch below, which should be applied on top of the one I sent > > yesterday, is needed because open-pipe does this: > > > > (open-pipe* mode "/bin/sh" "-c" comma

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > The changes below work around the lack of h_error on Windows: > > --- libguile/net_db.c~0 2013-03-25 23:44:46.0 +0200 > +++ libguile/net_db.c 2013-06-13 13:30:20.448923200 +0300 > @@ -55,6 +55,47 @@ > #include "libguile/net_db.h" > #include "libguile/socke

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > A few strange warnings and failures I saw while running the test > suite, which I couldn't figure out or couldn't find a solution for: > > 1. Even after using -export-dynamic, the tests in foreign.test which >use 'qsort' fail: See my other message. > 2. Failures in

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > The tests in foreign.test failed because they need to be able to call > C functions in Guile itself. According to libtool documentation, this > requires to link with -export-dynamic, so this is needed: > > --- libguile/Makefile.am~ 2013-04-03 15:11:28.0 +0300

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> Date: Tue, 11 Jun 2013 19:53:21 +0300 >> From: Eli Zaretskii >> Cc: l...@gnu.org, guile-user@gnu.org >> >> What eventually did the trick was configuring --with-threads=no. Once >> I did that, the build ran successfully and almost 100% cleanly to >> completion. (I wil

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > First, running the test suite resulted in some failures. > test-system-cmds failed because it uses '..' quoting on the command > line, which the Windows shell doesn't support. Fixed thusly: > > --- test-suite/standalone/test-system-cmds~0 2010-12-08 11:07:11.0

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > Here are a few more changes that fix problems exposed by the test > suite. > > The patch below, which should be applied on top of the one I sent > yesterday, is needed because open-pipe does this: > > (open-pipe* mode "/bin/sh" "-c" command)) > > and obviously there'

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > Actually, that was wrong: the use of AF_UNIX is already conditioned on > its being available. The problem is elsewhere: socket.c failed to > condition its availability on HAVE_UNIX_DOMAIN_SOCKETS. Fixed thusly: > > --- libguile/socket.c~0 2013-03-18 23:30:13.0

Re: guile 2.0.9 build on mingw

A few strange warnings and failures I saw while running the test suite, which I couldn't figure out or couldn't find a solution for: 1. Even after using -export-dynamic, the tests in foreign.test which use 'qsort' fail: Backtrace: In ice-9/boot-9.scm: 157: 16 [catch #t # ...]

Re: guile 2.0.9 build on mingw

The changes below work around the lack of h_error on Windows: --- libguile/net_db.c~0 2013-03-25 23:44:46.0 +0200 +++ libguile/net_db.c 2013-06-13 13:30:20.448923200 +0300 @@ -55,6 +55,47 @@ #include "libguile/net_db.h" #include "libguile/socket.h" +#ifdef __MINGW32__ +# define h_err

Re: guile 2.0.9 build on mingw

Here are a few more changes that fix problems exposed by the test suite. The patch below, which should be applied on top of the one I sent yesterday, is needed because open-pipe does this: (open-pipe* mode "/bin/sh" "-c" command)) and obviously there's no /bin/sh on Windows. --- libguile/p

Re: guile 2.0.9 build on mingw

> Date: Wed, 12 Jun 2013 20:57:38 +0300 > From: Eli Zaretskii > Cc: guile-user@gnu.org > > Finally, the tests in check-guile fail because they unconditionally > use features that are not compiled into the MinGW build or not > supported by it, like 'lstat', AF_UNIX in sockets, etc. Actually, that

Re: guile 2.0.9 build on mingw

> Date: Tue, 11 Jun 2013 19:53:21 +0300 > From: Eli Zaretskii > Cc: l...@gnu.org, guile-user@gnu.org > > Btw, --disable-posix disables too much, for no good reason. E.g., it > removes such innocent and important functionalities as "chdir", > "open", and "close". This is unnecessary, especially

Re: guile 2.0.9 build on mingw

> Date: Tue, 11 Jun 2013 19:53:21 +0300 > From: Eli Zaretskii > Cc: l...@gnu.org, guile-user@gnu.org > > What eventually did the trick was configuring --with-threads=no. Once > I did that, the build ran successfully and almost 100% cleanly to > completion. (I will report the details about "almo

Re: guile 2.0.9 build on mingw

> Date: Tue, 11 Jun 2013 19:53:21 +0300 > From: Eli Zaretskii > Cc: l...@gnu.org, guile-user@gnu.org > > What eventually did the trick was configuring --with-threads=no. Once > I did that, the build ran successfully and almost 100% cleanly to > completion. (I will report the details about "almo

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: Mark H Weaver , guile-user@gnu.org > Date: Wed, 12 Jun 2013 00:11:46 +0200 > > > What eventually did the trick was configuring --with-threads=no. Once > > I did that, the build ran successfully and almost 100% cleanly to > > completion. (I will repor

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: >> From: Mark H Weaver >> Cc: l...@gnu.org, guile-user@gnu.org >> Date: Mon, 10 Jun 2013 16:54:44 -0400 >> >> There are some remaining problems revealed by the test suite, but the >> two people I spoke to reported that Guile 2.0.9 mostly works on mingw, >> if configured

Re: guile 2.0.9 build on mingw

> From: Mark H Weaver > Cc: l...@gnu.org, guile-user@gnu.org > Date: Mon, 10 Jun 2013 16:54:44 -0400 > > There are some remaining problems revealed by the test suite, but the > two people I spoke to reported that Guile 2.0.9 mostly works on mingw, > if configured with --disable-posix. > > >> Ar

Re: guile 2.0.9 build on mingw

Eli Zaretskii writes: >> From: Mark H Weaver >> Cc: l...@gnu.org (Ludovic Courtès), guile-user@gnu.org >> Date: Mon, 10 Jun 2013 15:09:09 -0400 >> >> I've spoken with a couple of other people have successfully built Guile >> 2.0.9 on mingw. See for example. > > May

Re: guile 2.0.9 build on mingw

> From: Mark H Weaver > Cc: l...@gnu.org (Ludovic Courtès), guile-user@gnu.org > Date: Mon, 10 Jun 2013 15:09:09 -0400 > > I've spoken with a couple of other people have successfully built Guile > 2.0.9 on mingw. See for example. Maybe I misread, but that bug sounds

Re: guile 2.0.9 build on mingw

Hi Eli, I've spoken with a couple of other people have successfully built Guile 2.0.9 on mingw. See for example. Are you configuring Guile with --disable-posix? Mark

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: guile-user@gnu.org > Date: Sun, 09 Jun 2013 22:33:50 +0200 > > Eli Zaretskii skribis: > > > There's only one thread at this point, its backtrace is below. > > Actually, I don't see more than this one thread during the entire run > > (GDB doesn't annou

Re: guile 2.0.9 build on mingw

> From: Andy Wingo > Cc: Eli Zaretskii , guile-user@gnu.org > Date: Sun, 09 Jun 2013 23:16:18 +0200 > > On Sun 09 Jun 2013 22:33, l...@gnu.org (Ludovic Courtès) writes: > > > However, that warning doesn’t take into account the signal thread, nor > > the GC thread (if any). So, although that se

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: Eli Zaretskii , guile-user@gnu.org > Date: Sun, 09 Jun 2013 23:35:54 +0200 > > Andy Wingo skribis: > > > On Sun 09 Jun 2013 22:33, l...@gnu.org (Ludovic Courtès) writes: > > > >> However, that warning doesn’t take into account the signal thread, nor

Re: guile 2.0.9 build on mingw

Andy Wingo skribis: > On Sun 09 Jun 2013 22:33, l...@gnu.org (Ludovic Courtès) writes: > >> However, that warning doesn’t take into account the signal thread, nor >> the GC thread (if any). So, although that seems unlikely, there could >> still be issues, for instance if the ‘scm_fork’ call happ

Re: guile 2.0.9 build on mingw

On Sun 09 Jun 2013 22:33, l...@gnu.org (Ludovic Courtès) writes: > However, that warning doesn’t take into account the signal thread, nor > the GC thread (if any). So, although that seems unlikely, there could > still be issues, for instance if the ‘scm_fork’ call happens while > ‘signal_delivery

Re: guile 2.0.9 build on mingw

Eli Zaretskii skribis: > There's only one thread at this point, its backtrace is below. > Actually, I don't see more than this one thread during the entire run > (GDB doesn't announce any thread birth or death, and Process Explorer > shows a single thread in the process at all times). Note that

Re: guile 2.0.9 build on mingw

> Date: Fri, 07 Jun 2013 17:59:57 +0300 > From: Eli Zaretskii > Cc: guile-user@gnu.org > > > > What's more, after this backtrace is displayed, guile hangs here: > > > > > > void > > > scm_i_close_signal_pipe() > > > { > > >/* SIGNAL_DELIVERY_THREAD_MUTEX is only locked whil

Re: guile 2.0.9 build on mingw

> From: l...@gnu.org (Ludovic Courtès) > Cc: guile-user@gnu.org > Date: Fri, 07 Jun 2013 14:44:42 +0200 > > That vaguely rings a bell, and there were commits in that area over the > last couple of years. > > What version of Guile and libgc is it? The latest ones I could find: guile-2.0.9 and gc-

Re: guile 2.0.9 build on mingw

Hi Eli, And sorry for the lng delay. Eli Zaretskii skribis: >> From: Andy Wingo >> Cc: Panicz Maciej Godek , guile-user@gnu.org >> Date: Mon, 20 May 2013 22:46:10 +0200 >> >> >> GEN guile-procedures.texi >> >> >> >> but when I ask make to keep going, the same error appears when g

Re: guile 2.0.9 build on mingw

Ping! Any ideas on the below? > Date: Wed, 22 May 2013 18:26:59 +0300 > From: Eli Zaretskii > Cc: guile-user@gnu.org > > > From: Andy Wingo > > Cc: Panicz Maciej Godek , guile-user@gnu.org > > Date: Mon, 20 May 2013 22:46:10 +0200 > > > > >> GEN guile-procedures.texi > > >> > > >> b

Re: guile 2.0.9 build on mingw

> From: Andy Wingo > Cc: Panicz Maciej Godek , guile-user@gnu.org > Date: Mon, 20 May 2013 22:46:10 +0200 > > >> GEN guile-procedures.texi > >> > >> but when I ask make to keep going, the same error appears when guilec tries > >> to compile ice-9/eval.go. > > > > I reported a similar pro

Re: guile 2.0.9 build on mingw

> From: "objc" > Cc: > Date: Mon, 20 May 2013 22:09:59 +0100 > > To get the build right, I change ports.c print.c and strings .c Thanks. Can you explain why these changes are needed? You seem to be disabling libiconv functionality, is that right? If so, why do you think libiconv is involved

Re: guile 2.0.9 build on mingw

http://branch-twigg.webs.com/ for my build). It's still buggy but does what I need it to do. Hope this helps. John Goodwin -- From: "Andy Wingo" Sent: Monday, May 20, 2013 9:46 PM To: "Eli Zaretskii" Cc: Subject: Re: gui

Re: guile 2.0.9 build on mingw

On Mon 20 May 2013 22:05, Eli Zaretskii writes: >> Date: Mon, 20 May 2013 21:46:02 +0200 >> From: Panicz Maciej Godek >> >> I'm trying to build guile on mingw, but i get the following error: >> >> the instruction at 0x7059fe6b refrenced memory at 0x0004 the memory >> could not be read >>

Re: guile 2.0.9 build on mingw

> Date: Mon, 20 May 2013 21:46:02 +0200 > From: Panicz Maciej Godek > > I'm trying to build guile on mingw, but i get the following error: > > the instruction at 0x7059fe6b refrenced memory at 0x0004 the memory > could not be read > > The error appears at the stage > > GEN guile-pro

guile 2.0.9 build on mingw

Hi, I'm trying to build guile on mingw, but i get the following error: the instruction at 0x7059fe6b refrenced memory at 0x0004 the memory could not be read The error appears at the stage GEN guile-procedures.texi but when I ask make to keep going, the same error appears when guilec