guile 2.0.9 build on mingw

guile 2.0.9 build on mingw

[Panicz Maciej Godek]

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

Hi,
I'm trying to build guile on mingw, but i get the following error:

the instruction at 0x7059fe6b refrenced memory at 0x00000004 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 tries
to compile ice-9/eval.go.

I have tried to compile guile with different configurations -- with and
without threads, having disabled posix, networking and regexp (when
compiled without regexp, guile additionally wrote some complaints, which I
enclose in a screenshot, because terminal capabilities were too limited to
do the copy-paste on the text)

Does anyone have idea what could be going on, or what to begin with in
order to figure out?

The build process is happening on WinXP SP3 in virtual box with hardware
virtualization.

Greetz!

[-- Attachment #1.2: Type: text/html, Size: 1497 bytes --]

[-- Attachment #2: make.png --]
[-- Type: image/png, Size: 26512 bytes --]

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Mon, 20 May 2013 21:46:02 +0200
> From: Panicz Maciej Godek <godek.maciek@gmail.com>
> 
> I'm trying to build guile on mingw, but i get the following error:
> 
> the instruction at 0x7059fe6b refrenced memory at 0x00000004 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 tries
> to compile ice-9/eval.go.

I reported a similar problem here:

  http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html

So far no replies.  I hope to hear from them some day.

Btw, which version of GC did you use, and where did you get its MinGW
build?  (I used the latest 7.2d which I built myself.)

Re: guile 2.0.9 build on mingw

[Andy Wingo]

On Mon 20 May 2013 22:05, Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 20 May 2013 21:46:02 +0200
>> From: Panicz Maciej Godek <godek.maciek@gmail.com>
>> 
>> I'm trying to build guile on mingw, but i get the following error:
>> 
>> the instruction at 0x7059fe6b refrenced memory at 0x00000004 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 tries
>> to compile ice-9/eval.go.
>
> I reported a similar problem here:
>
>   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
>
> So far no replies.  I hope to hear from them some day.

Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
backtrace somehow?  Do you know what source line this error is coming
from?  I've only cross-built and not actually tried to run Guile on
native MinGW.

Andy
-- 
http://wingolog.org/

Re: guile 2.0.9 build on mingw

[objc]

Hi Eli,

I've seen problems like this too.
  GEN    guile-procedures.texi
Throw without catch before boot:

You have to build guile.exe properly before guile-procedures.texi etc...
 works because guile.exe  (guilec.exe) builds them.

To get the build right, I change ports.c print.c and strings .c
92: //jrg\f
#define iconv_open libiconv_open
#define iconv libiconv
#define iconv_close libiconv_close
//end jrg

print.c:
*******
59://jrg
#define iconv_open libiconv_open
#define iconv libiconv
#define iconv_close libiconv_close
//end jrg

strings.h
*********
1946:  const char *jrgbuf;//jrg
1993:  jrgbuf = NULL;
1996://  if (enc == NULL)
//    enc = "ISO-8859-1";
  if (enc == NULL) enc = "ANSI_X3.4-1968";    //jrg
  if (scm_i_is_narrow_string (str))
    {
	  jrgbuf = scm_i_string_chars (str);     //jrg
//      fprintf (stderr,"jrgbuf 
[%s]ilen[%d]encoding[%s]enc[%s]lenp[%d]\n",jrgbuf,ilen,encoding,enc,(int)(size_t 
 )lenp);//jrg
      ret = mem_iconveh (jrgbuf, ilen,
                         "ANSI_X3.4-1968", enc,//"ANSI_X3.4-1968" 
"ISO-8859-1" "UTF-8"
                         (enum iconv_ilseq_handler) handler, NULL,
                         &buf, &len);

      if (ret != 0)
      {//jrg
      //try another one !!
//      fprintf (stderr,"try ISO-8859-1 jrgbuf 
[%s]ilen[%d]encoding[%s]enc[%s]lenp[%d]\n",jrgbuf,ilen,encoding,enc,(int)(size_t 
 )lenp);//jrg
      ret = mem_iconveh (jrgbuf, ilen,
                         "ISO-8859-1", enc,//"ANSI_X3.4-1968"  "ISO-8859-1" 
"UTF-8"
                         (enum iconv_ilseq_handler) handler, NULL,
                         &buf, &len);
      }
      if (ret != 0)
      {//jrg
      //try another one !!
//      fprintf (stderr,"try UTF-8jrgbuf 
[%s]ilen[%d]encoding[%s]enc[%s]lenp[%d]\n",jrgbuf,ilen,encoding,enc,(int)(size_t 
 )lenp);//jrg
      ret = mem_iconveh (jrgbuf, ilen,
                         "UTF-8", enc,//"ANSI_X3.4-1968"  "ISO-8859-1" 
"UTF-8"
                         (enum iconv_ilseq_handler) handler, NULL,
                         &buf, &len);
      }
      if (ret != 0)
      {//jrg

        printf("(ret != 0) jrgbuf [%s] buf[%s]\n",jrgbuf,buf);//jrg
       fprintf (stderr,"failed return jrgbuf jrgbuf 
[%s]ilen[%d]encoding[%s]enc[%s]lenp[%d]\n",jrgbuf,ilen,encoding,enc,(int)(size_t 
 )lenp);//jrg
        return (char*)jrgbuf;//hmmm

        scm_encoding_error (__func__, errno,
			    "cannot convert narrow string to output locale",
			    SCM_BOOL_F,
			    /* FIXME: Faulty character unknown.  */
			    SCM_BOOL_F);
	  }//jrg
    }
  else
    {
	  jrgbuf = (char *)(scm_t_uint32 *) scm_i_string_wide_chars (str); 
//jrg
	  fprintf (stderr,"jrgbuf 
[%s]ilen[%d]encoding[%s]enc[%s]lenp[%d]\n",jrgbuf,ilen,encoding,enc,(int)(size_t 
 )lenp);//jrg
      buf = u32_conv_to_encoding (enc,
                                  (enum iconv_ilseq_handler) handler,
                                  (scm_t_uint32 *) scm_i_string_wide_chars 
(str),
                                  ilen,
                                  NULL,
                                  NULL, &len);
      if (buf == NULL)
      {//jrg
        printf("(buf == NULL) jrgbuf [%s] buf [%s]\n",jrgbuf,buf);//jrg
        scm_encoding_error (__func__, errno,
			    "cannot convert wide string to output locale",
			    SCM_BOOL_F,
			    /* FIXME: Faulty character unknown.  */
			    SCM_BOOL_F);
	  }
    }

This is just some hacking around, but may put someone on the right track.

I use cygwin (mingw) on XP SP3 (see 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" <wingo@pobox.com>
Sent: Monday, May 20, 2013 9:46 PM
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: <guile-user@gnu.org>
Subject: Re: guile 2.0.9 build on mingw

> On Mon 20 May 2013 22:05, Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Mon, 20 May 2013 21:46:02 +0200
>>> From: Panicz Maciej Godek <godek.maciek@gmail.com>
>>>
>>> I'm trying to build guile on mingw, but i get the following error:
>>>
>>> the instruction at 0x7059fe6b refrenced memory at 0x00000004 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 
>>> tries
>>> to compile ice-9/eval.go.
>>
>> I reported a similar problem here:
>>
>>   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
>>
>> So far no replies.  I hope to hear from them some day.
>
> Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
> backtrace somehow?  Do you know what source line this error is coming
> from?  I've only cross-built and not actually tried to run Guile on
> native MinGW.
>
> Andy
> -- 
> http://wingolog.org/
>
> 

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: "objc" <objcjohn@hotmail.com>
> Cc: <guile-user@gnu.org>
> 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 in these problems?

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,  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 problem here:
> >
> >   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
> >
> > So far no replies.  I hope to hear from them some day.
> 
> Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
> backtrace somehow?

I did my best, see below.  Running meta/gdb-uninstalled-guile cannot
help here, because the problem happens in a child Guile process, and
GDB on Windows doesn't support follow-fork/exec-mode.

Instead, I concatenated manually all the *.doc files, then ran this
command (the one that crashed, as revealed by "make V=1"):

  GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0  ../meta/uninstalled-env \
    guild snarf-check-and-output-texi < all-docs.doc > guile-procedures.texi

and then attached GDB to the child Guile process and looked around.

What I found is something I'll need a lot of help with.  The backtrace
displayed by Guile looks like this:

     Backtrace:
     In unknown file:
	?: 4 [apply-smob/1 #<catch-closure c1ddf0> quit #<unspecified>]
     In ice-9/eval.scm:
      484: 3 [eval # #]
      481: 2 [lp (#<fluid 13>) (#<procedure 41c1c78 at ice-9/eval.scm:264:7 %args>)]
     In unknown file:
	?: 1 [apply-smob/1 #<catch-closure 643d730>]
     In ice-9/eval.scm:
      481: 0 [lp (#<fluid 12>) ((#<catch-closure 643d710>))]

     ice-9/eval.scm:481:19:
                           ^

Yes, the last line is really unfinished, and the cursor sits where
shown.  But typing at this stage has no effect.

Setting a breakpoint on all 3 places that print "Backtrace:", I get
this C backtrace:

  Breakpoint 2, print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
      port=0x935c40) at continuations.c:490
  490           scm_display_backtrace_with_highlights (stack, port,
  (gdb) bt
  #0  print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
      port=0x935c40) at continuations.c:490
  #1  pre_unwind_handler (error_port=error_port@entry=0x935c40, tag=0x89c6f0,
      args=args@entry=0x37ff610) at continuations.c:534
  #2  0x00430eae in apply_catch_closure (clo=0x643d710, args=0x37ff608)
      at throw.c:151
  #3  0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
      argv=0xa01120, nargs=5121210) at vm-i-system.c:855
  #4  0x0045668b in scm_call_with_vm (vm=0x935c80, proc=0x896af0,
      args=<optimized out>) at vm.c:1045
  #5  0x00412f87 in scm_apply (proc=0x935c80, arg1=0x896af0,
      args=<optimized out>) at eval.c:748
  #6  0x004148fd in scm_apply_1 (proc=0x935c80, arg1=0x896af0,
      arg1@entry=0x89c6f0, args=0x37ff828, args@entry=0x37ff830) at eval.c:588
  #7  0x0043139b in scm_throw (key=0x89c6f0, args=0x37ff830) at throw.c:104
  #8  0x00431819 in scm_ithrow (key=key@entry=0x89c6f0, args=0x37ff830,
      noreturn=noreturn@entry=1) at throw.c:441
  #9  0x0041f507 in scm_error_scm (key=key@entry=0x89c6f0, subr=0x4,
      message=message@entry=0x643d630, args=args@entry=0x37ff850,
      data=data@entry=0x37ff870) at error.c:95
  #10 0x0041f577 in scm_error (key=0x89c6f0, subr=subr@entry=0x0,
      message=message@entry=0x4dd99c <scm_eval_string_in_module__name_string_stringbuf+72> "~A", args=0x37ff850, rest=rest@entry=0x37ff870) at error.c:62
  #11 0x0041f5fa in scm_syserror (subr=subr@entry=0x0) at error.c:167
  #12 0x00432fe3 in scm_spawn_thread (
      body=body@entry=0x436340 <signal_delivery_thread>,
      body_data=body_data@entry=0x0, handler=0x431794 <scm_handle_by_message>,
      handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1139
  #13 0x00436318 in start_signal_delivery_thread () at scmsigs.c:200
  #14 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
  #15 0x0043641c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
  #16 0x00432c00 in do_thread_exit (v=0x8d0f00) at threads.c:671
  #17 0x0045f8ac in c_body (d=0x28f6a0) at continuations.c:511
  #18 0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
      argv=0xa010a4, nargs=5121210) at vm-i-system.c:855
  #19 0x004145f8 in scm_call_4 (proc=0x896b28, arg1=arg1@entry=0x404,
      arg2=arg2@entry=0x643d730, arg3=arg3@entry=0x643d720,
      arg4=arg4@entry=0x643d710) at eval.c:507
  #20 0x004312a2 in scm_catch_with_pre_unwind_handler (key=0x404,
      thunk=0x643d730, handler=0x643d720, pre_unwind_handler=0x643d710)
      at throw.c:86
  #21 0x0043143e in scm_c_catch (tag=tag@entry=0x404, body=0x643d730,
      body@entry=0x45f89c <c_body>, body_data=0x643d720,
      body_data@entry=0x28f6a0, handler=0x643d710,
      handler@entry=0x45fb50 <c_handler>,
      handler_data=handler_data@entry=0x28f6a0,
      pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0x935c40) at throw.c:213
  #22 0x0045ff3b in scm_i_with_continuation_barrier (
      body=body@entry=0x45f89c <c_body>, body_data=body_data@entry=0x28f6a0,
      handler=handler@entry=0x45fb50 <c_handler>,
      handler_data=handler_data@entry=0x28f6a0,
      pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=0x935c40) at continuations.c:449
  #23 0x0045ffcc in scm_c_with_continuation_barrier (
      func=0x432bf0 <do_thread_exit>, data=0x8d0f00) at continuations.c:545
  #24 0x00431df4 in with_guile_trampoline (data=0x28f790) at threads.c:890
  #25 0x709cffa0 in ?? () from d:\usr\bin\libgc-1.dll
  #26 0x004326dc in with_gc_active (data=0x28f790,
      func=0x431ddc <with_guile_trampoline>) at threads.c:238
  #27 with_guile_and_parent (base=0x28f768, data=0x28f790) at threads.c:936
  #28 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
  #29 0x004328e0 in scm_i_with_guile_and_parent (parent=<optimized out>,
      data=0x8d0f00, func=0x432bf0 <do_thread_exit>) at threads.c:951
  #30 scm_with_guile (func=0x432bf0 <do_thread_exit>, data=0x8d0f00)
      at threads.c:957
  #31 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
  #32 0x00431e66 in on_thread_exit (v=0x8d0f00) at threads.c:754
  #33 0x62481f14 in ptw32_callUserDestroyRoutines ()
     from d:\usr\bin\pthreadGC2.dll
  #34 0x624855a1 in pthread_win32_thread_detach_np ()
     from d:\usr\bin\pthreadGC2.dll
  #35 0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll
  #36 0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthreadGC2.dll

What's more, after this backtrace is displayed, guile hangs here:

     void
     scm_i_close_signal_pipe()
     {
       /* SIGNAL_DELIVERY_THREAD_MUTEX is only locked while the signal delivery
	  thread is being launched.  The thread that calls this function is
	  already holding the thread admin mutex, so if the delivery thread hasn't
	  been launched at this point, it never will be before shutdown.  */
 >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);

     #if SCM_USE_PTHREAD_THREADS
       if (scm_i_signal_delivery_thread != NULL)
	 close (signal_pipe[1]);
     #endif

       scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
     }

The backtrace is displayed before that, probably from a different
thread, because I also tried to step through the code that eventually
comes to scm_i_close_signal_pipe, and that didn't go through the
function shown above that displays the Guile backtrace.

Now, I know almost nothing about pthreads.  Any ideas or suggestions
for further debugging are most welcome.

P.S.  Should we talk about this on bug-guile instead?

Re: guile 2.0.9 build on mingw

[Panicz Maciej Godek]

[-- Attachment #1.1: Type: text/plain, Size: 3486 bytes --]

2013/5/20 Andy Wingo <wingo@pobox.com>

> On Mon 20 May 2013 22:05, Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Date: Mon, 20 May 2013 21:46:02 +0200
> >> From: Panicz Maciej Godek <godek.maciek@gmail.com>
> >>
> >> I'm trying to build guile on mingw, but i get the following error:
> >>
> >> the instruction at 0x7059fe6b refrenced memory at 0x00000004 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
> tries
> >> to compile ice-9/eval.go.
> >
> > I reported a similar problem here:
> >
> >   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
> >
> > So far no replies.  I hope to hear from them some day.
>
> Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
> backtrace somehow?  Do you know what source line this error is coming
> from?  I've only cross-built and not actually tried to run Guile on
> native MinGW.
>

I don't know how to handle more advanced debugging methods, but perhaps it
might be helpful to note that in case of GUILEC, the error pop-ups almost
simultaneously with a notice from make, which states that it wrote the .go
file.
I include the standard output and error logs from make -k.

After some cheap cheats with makefiles (i.e. replacing the
guile-procedues.texi rule with "touch $@" in libguile/Makefile, and
touching libguile/guile-procedures.txt) I finally managed to make -k
install (the "-k" option was needed, because there was no file named
guild.exe, and I don't think that there's supposed to be one).

When I run it for the first time, I got the following message:

--BEGIN--
Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find
file ~S in load path" ("ice-9/boot-9") #f)Aborting.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Cannot exit gracefully when init is in progress; aborting.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
--END--

I therefore decided to show guile explicitly where it should look for
modules:
$ GUILE_LOAD_PATH=/usr/share/guile/2.0

It opened and started to compile the modules, although initially it was
complaining that there was no language scheme nor tree-il, and the
auto-compilation process stalled when compiling ice-9/threads.scm

The aforementioned complaints didin't appear when I ran guile for the
second time, but then I obtained a lot of messages like:
;;; compiling C:/msys/share/guile/2.0\language\assembly.scm
;;; it seems C:/msys/share/guile/2.0\language\assembly.scm
;;; is part of the compiler; skipping auto-compilation

it sort of stalled after having skipped the srfi\srfi-11.scm module, so I
decided to run it for the third time, this time passing
GUILE_AUTO_COMPILE=0 as well, but then the interpreter started without any
prompt, as if it was dead (although it did terminate with Ctrl+C). I also
decided to see whether it could be readline's fault (or something), so I
ran it passing the --version arg, but it didn't change anything.

I attach the make logs, unfortunately in two distinct files for stdout and
stderr, loosing the chronology of messages. During compilation to .go
files, the error messages came after the "wrote `*.go'".

Best regards!

[-- Attachment #1.2: Type: text/html, Size: 4987 bytes --]

[-- Attachment #2: make.err --]
[-- Type: application/octet-stream, Size: 21845 bytes --]

make[3]: *** [guile-procedures.texi] Error 1
make[3]: Target `all-am' not remade because of errors.
make[2]: *** [all] Error 2
make[2]: *** [ice-9/vlist.go] Error 5
make[2]: *** [srfi/srfi-1.go] Error 5
make[2]: *** [language/tree-il/peval.go] Error 5
make[2]: *** [language/tree-il/cse.go] Error 5
make[2]: *** [language/tree-il.go] Error 5
make[2]: *** [language/glil.go] Error 5
make[2]: *** [language/assembly.go] Error 5
make[2]: *** [language/tree-il/primitives.go] Error 5
make[2]: *** [language/tree-il/effects.go] Error 5
make[2]: *** [language/tree-il/fix-letrec.go] Error 5
make[2]: *** [language/tree-il/optimize.go] Error 5
make[2]: *** [language/tree-il/canonicalize.go] Error 5
make[2]: *** [language/tree-il/analyze.go] Error 5
make[2]: *** [language/tree-il/inline.go] Error 5
make[2]: *** [language/tree-il/compile-glil.go] Error 5
make[2]: *** [language/tree-il/debug.go] Error 5
make[2]: *** [language/tree-il/spec.go] Error 5
make[2]: *** [language/glil/spec.go] Error 5
make[2]: *** [language/glil/compile-assembly.go] Error 5
make[2]: *** [language/assembly/spec.go] Error 5
make[2]: *** [language/assembly/compile-bytecode.go] Error 5
make[2]: *** [language/assembly/decompile-bytecode.go] Error 5
make[2]: *** [language/assembly/disassemble.go] Error 5
make[2]: *** [language/bytecode/spec.go] Error 5
make[2]: *** [language/objcode/spec.go] Error 5
make[2]: *** [language/value/spec.go] Error 5
make[2]: *** [language/scheme/spec.go] Error 5
make[2]: *** [language/scheme/compile-tree-il.go] Error 5
make[2]: *** [language/scheme/decompile-tree-il.go] Error 5
make[2]: *** [system/base/pmatch.go] Error 5
make[2]: *** [system/base/syntax.go] Error 5
make[2]: *** [system/base/compile.go] Error 5
make[2]: *** [system/base/language.go] Error 5
make[2]: *** [system/base/lalr.go] Error 5
make[2]: *** [system/base/message.go] Error 5
make[2]: *** [system/base/target.go] Error 5
make[2]: *** [system/base/ck.go] Error 5
make[2]: *** [ice-9/r4rs.go] Error 5
make[2]: *** [ice-9/r5rs.go] Error 5
make[2]: *** [ice-9/deprecated.go] Error 5
make[2]: *** [ice-9/and-let-star.go] Error 5
make[2]: *** [ice-9/binary-ports.go] Error 5
make[2]: *** [ice-9/calling.go] Error 5
make[2]: *** [ice-9/command-line.go] Error 5
make[2]: *** [ice-9/common-list.go] Error 5
make[2]: *** [ice-9/control.go] Error 5
make[2]: *** [ice-9/curried-definitions.go] Error 5
make[2]: *** [ice-9/debug.go] Error 5
make[2]: *** [ice-9/documentation.go] Error 5
make[2]: *** [ice-9/eval-string.go] Error 5
make[2]: *** [ice-9/expect.go] Error 5
make[2]: *** [ice-9/format.go] Error 5
make[2]: *** [ice-9/futures.go] Error 253
make[2]: *** [ice-9/getopt-long.go] Error 5
make[2]: *** [ice-9/hcons.go] Error 5
make[2]: *** [ice-9/i18n.go] Error 5
make[2]: *** [ice-9/iconv.go] Error 5
make[2]: *** [ice-9/lineio.go] Error 5
make[2]: *** [ice-9/ls.go] Error 253
make[2]: *** [ice-9/mapping.go] Error 253
make[2]: *** [ice-9/match.go] Error 5
ice-9/networking.scm:23:29: warning: possibly unbound variable `gethost'
ice-9/networking.scm:24:29: warning: possibly unbound variable `gethost'
ice-9/networking.scm:26:28: warning: possibly unbound variable `getnet'
ice-9/networking.scm:27:28: warning: possibly unbound variable `getnet'
ice-9/networking.scm:29:30: warning: possibly unbound variable `getproto'
ice-9/networking.scm:30:32: warning: possibly unbound variable `getproto'
ice-9/networking.scm:32:35: warning: possibly unbound variable `getserv'
ice-9/networking.scm:33:35: warning: possibly unbound variable `getserv'
ice-9/networking.scm:37:6: warning: possibly unbound variable `sethost'
ice-9/networking.scm:38:6: warning: possibly unbound variable `sethost'
ice-9/networking.scm:41:6: warning: possibly unbound variable `setnet'
ice-9/networking.scm:42:6: warning: possibly unbound variable `setnet'
ice-9/networking.scm:45:6: warning: possibly unbound variable `setproto'
ice-9/networking.scm:46:6: warning: possibly unbound variable `setproto'
ice-9/nemake[2]: *** [ice-9/networking.go] Error 5
make[2]: *** [ice-9/null.go] Error 5
make[2]: *** [ice-9/occam-channel.go] Error 5
make[2]: *** [ice-9/optargs.go] Error 253
make[2]: *** [ice-9/poe.go] Error 5
make[2]: *** [ice-9/poll.go] Error 5
make[2]: *** [ice-9/posix.go] Error 5
make[2]: *** [ice-9/q.go] Error 5
make[2]: *** [ice-9/rdelim.go] Error 5
make[2]: *** [ice-9/receive.go] Error 5
make[2]: *** [ice-9/regex.go] Error 5
make[2]: *** [ice-9/runq.go] Error 5
make[2]: *** [ice-9/rw.go] Error 253
make[2]: *** [ice-9/safe-r5rs.go] Error 253
make[2]: *** [ice-9/safe.go] Error 253
make[2]: *** [ice-9/save-stack.go] Error 253
make[2]: *** [ice-9/scm-style-repl.go] Error 5
ice-9/session.scm:241:11: warning: non-literal format string
make[2]: *** [ice-9/session.go] Error 5
make[2]: *** [ice-9/slib.go] Error 253
make[2]: *** [ice-9/stack-catch.go] Error 253
make[2]: *** [ice-9/streams.go] Error 5
make[2]: *** [ice-9/string-fun.go] Error 5
make[2]: *** [ice-9/syncase.go] Error 5
make[2]: *** [ice-9/threads.go] Error 5
make[2]: *** [ice-9/top-repl.go] Error 5
make[2]: *** [ice-9/buffered-input.go] Error 5
make[2]: *** [ice-9/time.go] Error 5
make[2]: *** [ice-9/history.go] Error 5
make[2]: *** [ice-9/channel.go] Error 253
make[2]: *** [ice-9/pretty-print.go] Error 5
ice-9/ftw.scm:256:13: warning: possibly unbound variable `getuid'
ice-9/ftw.scm:257:13: warning: possibly unbound variable `getgid'
ice-9/ftw.scm:284:35: warning: possibly unbound variable `lstat'
ice-9/ftw.scm:307:46: warning: possibly unbound variable `getuid'
ice-9/ftw.scm:307:55: warning: possibly unbound variable `getgid'
ice-9/ftw.scm:327:44: warning: possibly unbound variable `lstat'
ice-9/ftw.scm:353:52: warning: possibly unbound variable `getuid'
ice-9/ftw.scm:353:61: warning: possibly unbound variable `getgid'
ice-9/ftw.scm:399:0: warning: possibly unbound variable `lstat'
ice-9/ftw.scm:493:0: warning: possibly unbound variable `lstat'
ice-9/ftw.scm:565:9: warning: possibly unbound variable `lstat'
make[2]: *** [ice-9/ftw.go] Error 5
make[2]: *** [ice-9/gap-buffer.go] Error 5
make[2]: *** [ice-9/weak-vector.go] Error 5
make[2]: *** [ice-9/list.go] Error 5
make[2]: *** [ice-9/serialize.go] Error 253
make[2]: *** [ice-9/local-eval.go] Error 5
make[2]: *** [srfi/srfi-2.go] Error 5
make[2]: *** [srfi/srfi-4.go] Error 5
make[2]: *** [srfi/srfi-4/gnu.go] Error 5
make[2]: *** [srfi/srfi-6.go] Error 5
make[2]: *** [srfi/srfi-8.go] Error 5
make[2]: *** [srfi/srfi-9.go] Error 5
make[2]: *** [srfi/srfi-9/gnu.go] Error 5
make[2]: *** [srfi/srfi-10.go] Error 5
make[2]: *** [srfi/srfi-11.go] Error 5
make[2]: *** [srfi/srfi-13.go] Error 5
make[2]: *** [srfi/srfi-14.go] Error 5
make[2]: *** [srfi/srfi-16.go] Error 5
make[2]: *** [srfi/srfi-17.go] Error 253
make[2]: *** [srfi/srfi-18.go] Error 5
make[2]: *** [srfi/srfi-19.go] Error 5
make[2]: *** [srfi/srfi-26.go] Error 5
make[2]: *** [srfi/srfi-27.go] Error 5
make[2]: *** [srfi/srfi-31.go] Error 5
make[2]: *** [srfi/srfi-34.go] Error 5
make[2]: *** [srfi/srfi-35.go] Error 253
make[2]: *** [srfi/srfi-37.go] Error 5
make[2]: *** [srfi/srfi-38.go] Error 253
make[2]: *** [srfi/srfi-41.go] Error 5
make[2]: *** [srfi/srfi-42.go] Error 5
make[2]: *** [srfi/srfi-39.go] Error 5
make[2]: *** [srfi/srfi-45.go] Error 5
make[2]: *** [srfi/srfi-60.go] Error 5
make[2]: *** [srfi/srfi-67.go] Error 5
make[2]: *** [srfi/srfi-69.go] Error 253
make[2]: *** [srfi/srfi-88.go] Error 5
make[2]: *** [srfi/srfi-98.go] Error 253
make[2]: *** [rnrs/base.go] Error 5
make[2]: *** [rnrs/conditions.go] Error 5
make[2]: *** [rnrs/control.go] Error 5
make[2]: *** [rnrs/enums.go] Error 5
make[2]: *** [rnrs/eval.go] Error 5
make[2]: *** [rnrs/exceptions.go] Error 5
make[2]: *** [rnrs/files.go] Error 5
make[2]: *** [rnrs/hashtables.go] Error 5
make[2]: *** [rnrs/lists.go] Error 5
make[2]: *** [rnrs/mutable-pairs.go] Error 253
make[2]: *** [rnrs/mutable-strings.go] Error 253
make[2]: *** [rnrs/programs.go] Error 5
make[2]: *** [rnrs/r5rs.go] Error 5
make[2]: *** [rnrs/sorting.go] Error 5
make[2]: *** [rnrs/syntax-case.go] Error 5
make[2]: *** [rnrs/unicode.go] Error 5
make[2]: *** [rnrs/arithmetic/bitwise.go] Error 5
make[2]: *** [rnrs/arithmetic/fixnums.go] Error 5
make[2]: *** [rnrs/arithmetic/flonums.go] Error 5
make[2]: *** [rnrs/bytevectors.go] Error 5
make[2]: *** [rnrs/io/simple.go] Error 5
make[2]: *** [rnrs/io/ports.go] Error 5
make[2]: *** [rnrs/records/inspection.go] Error 5
make[2]: *** [rnrs/records/procedural.go] Error 5
make[2]: *** [rnrs/records/syntactic.go] Error 5
make[2]: *** [rnrs.go] Error 5
make[2]: *** [oop/goops.go] Error 5
make[2]: *** [oop/goops/active-slot.go] Error 5
make[2]: *** [oop/goops/compile.go] Error 5
make[2]: *** [oop/goops/composite-slot.go] Error 5
make[2]: *** [oop/goops/describe.go] Error 5
make[2]: *** [oop/goops/dispatch.go] Error 5
make[2]: *** [oop/goops/internal.go] Error 5
make[2]: *** [oop/goops/save.go] Error 5
make[2]: *** [oop/goops/stklos.go] Error 5
make[2]: *** [oop/goops/util.go] Error 5
make[2]: *** [oop/goops/accessors.go] Error 5
make[2]: *** [oop/goops/simple.go] Error 5
make[2]: *** [system/vm/inspect.go] Error 5
make[2]: *** [system/vm/coverage.go] Error 5
make[2]: *** [system/vm/frame.go] Error 5
make[2]: *** [system/vm/instruction.go] Error 253
make[2]: *** [system/vm/objcode.go] Error 253
make[2]: *** [system/vm/program.go] Error 253
make[2]: *** [system/vm/trace.go] Error 253
make[2]: *** [system/vm/traps.go] Error 253
make[2]: *** [system/vm/trap-state.go] Error 253
make[2]: *** [system/vm/vm.go] Error 253
make[2]: *** [system/foreign.go] Error 5
make[2]: *** [system/xref.go] Error 5
make[2]: *** [system/repl/debug.go] Error 5
make[2]: *** [system/repl/error-handling.go] Error 5
make[2]: *** [system/repl/common.go] Error 5
make[2]: *** [system/repl/command.go] Error 5
make[2]: *** [system/repl/repl.go] Error 5
system/repl/server.scm:106:2: warning: possibly unbound variable `SIGPIPE'
make[2]: *** [system/repl/server.go] Error 5
make[2]: *** [scripts/compile.go] Error 5
make[2]: *** [scripts/disassemble.go] Error 5
make[2]: *** [scripts/display-commentary.go] Error 5
make[2]: *** [scripts/doc-snarf.go] Error 5
make[2]: *** [scripts/frisk.go] Error 5
make[2]: *** [scripts/generate-autoload.go] Error 5
make[2]: *** [scripts/help.go] Error 5
make[2]: *** [scripts/lint.go] Error 5
make[2]: *** [scripts/list.go] Error 5
make[2]: *** [scripts/punify.go] Error 5
make[2]: *** [scripts/read-scheme-source.go] Error 5
make[2]: *** [scripts/read-text-outline.go] Error 5
make[2]: *** [scripts/use2dot.go] Error 5
make[2]: *** [scripts/snarf-check-and-output-texi.go] Error 5
make[2]: *** [scripts/summarize-guile-TODO.go] Error 5
make[2]: *** [scripts/api-diff.go] Error 5
make[2]: *** [scripts/read-rfc822.go] Error 5
make[2]: *** [scripts/snarf-guile-m4-docs.go] Error 5
make[2]: *** [language/ecmascript/tokenize.go] Error 5
make[2]: *** [language/ecmascript/parse.go] Error 5
make[2]: *** [language/ecmascript/impl.go] Error 5
language/ecmascript/base.scm:227:22: warning: possibly unbound variable `Boolean'
language/ecmascript/base.scm:228:21: warning: possibly unbound variable `String'
language/ecmascript/base.scm:229:21: warning: possibly unbound variable `Number'
make[2]: *** [language/ecmascript/base.go] Error 5
language/ecmascript/function.scm:40:9: warning: possibly unbound variable `<js-array-object>'
language/ecmascript/function.scm:44:43: warning: possibly unbound variable `js-array-vector'
make[2]: *** [language/ecmascript/function.go] Error 5
make[2]: *** [language/ecmascript/array.go] Error 5
make[2]: *** [language/ecmascript/compile-tree-il.go] Error 5
make[2]: *** [language/ecmascript/spec.go] Error 5
make[2]: *** [language/elisp/lexer.go] Error 5
make[2]: *** [language/elisp/parser.go] Error 5
make[2]: *** [language/elisp/bindings.go] Error 5
make[2]: *** [language/elisp/compile-tree-il.go] Error 5
make[2]: *** [language/elisp/runtime.go] Error 5
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `if'
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `let'
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `let*'
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `while'
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `defmacro'
WARNING: (language elisp runtime function-slot): imported module (language elisp compile-tree-il) overrides core binding `quote'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `lambda'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `when'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `unless'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `cond'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `and'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `or'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime macros) overrides core binding `catch'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `='
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `<'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `<='
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `>'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `>='
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `max'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `min'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `abs'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `#{1+}#'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `#{1-}#'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `+'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `-'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `*'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `car'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `cdr'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `length'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `cons'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `list'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `make-list'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `append'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `reverse'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `copy-tree'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `apply'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `throw'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `not'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `eval'
WARNING: (language elisp runtime function-slot): imported module (language elisp runtime subrs) overrides core binding `load'
make[2]: *** [language/elisp/runtime/function-slot.go] Error 5
make[2]: *** [language/elisp/runtime/value-slot.go] Error 5
make[2]: *** [language/elisp/runtime/macros.go] Error 5
make[2]: *** [language/elisp/runtime/subrs.go] Error 5
make[2]: *** [language/elisp/spec.go] Error 5
make[2]: *** [language/brainfuck/parse.go] Error 5
make[2]: *** [language/brainfuck/compile-scheme.go] Error 5
make[2]: *** [language/brainfuck/compile-tree-il.go] Error 5
make[2]: *** [language/brainfuck/spec.go] Error 5
statprof.scm:303:8: warning: possibly unbound variable `setitimer'
statprof.scm:303:8: warning: possibly unbound variable `ITIMER_PROF'
statprof.scm:355:12: warning: possibly unbound variable `setitimer'
statprof.scm:355:12: warning: possibly unbound variable `ITIMER_PROF'
statprof.scm:356:12: warning: possibly unbound variable `setitimer'
statprof.scm:356:12: warning: possibly unbound variable `ITIMER_PROF'
statprof.scm:380:34: warning: possibly unbound variable `setitimer'
statprof.scm:380:34: warning: possibly unbound variable `ITIMER_PROF'
statprof.scm:404:2: warning: possibly unbound variable `SIGPROF'
make[2]: *** [statprof.go] Error 5
make[2]: *** [sxml/apply-templates.go] Error 5
make[2]: *** [sxml/fold.go] Error 5
make[2]: *** [sxml/match.go] Error 5
make[2]: *** [sxml/simple.go] Error 5
make[2]: *** [sxml/ssax/input-parse.go] Error 5
make[2]: *** [sxml/ssax.go] Error 5
make[2]: *** [sxml/transform.go] Error 5
make[2]: *** [sxml/xpath.go] Error 5
make[2]: *** [texinfo.go] Error 5
make[2]: *** [texinfo/docbook.go] Error 5
make[2]: *** [texinfo/html.go] Error 5
make[2]: *** [texinfo/indexing.go] Error 5
make[2]: *** [texinfo/string-utils.go] Error 5
make[2]: *** [texinfo/plain-text.go] Error 5
make[2]: *** [texinfo/reflection.go] Error 5
make[2]: *** [texinfo/serialize.go] Error 5
make[2]: *** [web/client.go] Error 5
make[2]: *** [web/http.go] Error 5
make[2]: *** [web/request.go] Error 5
make[2]: *** [web/response.go] Error 5
make[2]: *** [web/server.go] Error 5
web/server/http.scm:67:2: warning: possibly unbound variable `SIGPIPE'
make[2]: *** [web/server/http.go] Error 5
make[2]: *** [web/uri.go] Error 5
make[2]: Target `all' not remade because of errors.
libtool: link: warning: `c:/msys/lib/libgc.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libffi.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libintl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libunistring.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/libintl.la' seems to be moved
libtool: link: warning: `/usr/lib/libiconv.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgmp.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libltdl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgc.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libffi.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libintl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libunistring.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/libintl.la' seems to be moved
libtool: link: warning: `/usr/lib/libiconv.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgmp.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libltdl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgc.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libffi.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libintl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libunistring.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/libintl.la' seems to be moved
libtool: link: warning: `/usr/lib/libiconv.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgmp.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libltdl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgc.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libffi.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libintl.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libunistring.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/libintl.la' seems to be moved
libtool: link: warning: `/usr/lib/libiconv.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libgmp.la' seems to be moved
libtool: link: warning: `c:/msys/lib/libltdl.la' seems to be moved
make[2]: *** No rule to make target `libguile/guile-procedures.texi', needed by `libguile/guile-procedures.txt'.
make[2]: Target `all-am' not remade because of errors.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

[-- Attachment #3: make.log --]
[-- Type: application/octet-stream, Size: 52381 bytes --]

make  all-recursive
make[1]: Entering directory `/home/XPMUser/guile-2.0.9'
Making all in lib
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/lib'
make  all-recursive
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/lib'
make[4]: Entering directory `/home/XPMUser/guile-2.0.9/lib'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/XPMUser/guile-2.0.9/lib'
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/lib'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/lib'
Making all in meta
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/meta'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/meta'
Making all in libguile
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/libguile'
make  all-am
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/libguile'
  GEN      guile-procedures.texi
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/libguile'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/libguile'
Making all in module
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/module'
  GUILEC ice-9/vlist.go
  GUILEC srfi/srfi-1.go
  GUILEC language/tree-il/peval.go
  GUILEC language/tree-il/cse.go
  GUILEC language/tree-il.go
  GUILEC language/glil.go
  GUILEC language/assembly.go
  GUILEC language/tree-il/primitives.go
  GUILEC language/tree-il/effects.go
  GUILEC language/tree-il/fix-letrec.go
  GUILEC language/tree-il/optimize.go
  GUILEC language/tree-il/canonicalize.go
  GUILEC language/tree-il/analyze.go
  GUILEC language/tree-il/inline.go
  GUILEC language/tree-il/compile-glil.go
  GUILEC language/tree-il/debug.go
wrote `language/tree-il/debug.go'
  GUILEC language/tree-il/spec.go
  GUILEC language/glil/spec.go
  GUILEC language/glil/compile-assembly.go
  GUILEC language/assembly/spec.go
  GUILEC language/assembly/compile-bytecode.go
wrote `language/assembly/compile-bytecode.go'
  GUILEC language/assembly/decompile-bytecode.go
wrote `language/assembly/decompile-bytecode.go'
  GUILEC language/assembly/disassemble.go
wrote `language/assembly/disassemble.go'
  GUILEC language/bytecode/spec.go
  GUILEC language/objcode/spec.go
wrote `language/objcode/spec.go'
  GUILEC language/value/spec.go
  GUILEC language/scheme/spec.go
  GUILEC language/scheme/compile-tree-il.go
  GUILEC language/scheme/decompile-tree-il.go
wrote `language/scheme/decompile-tree-il.go'
  GUILEC system/base/pmatch.go
  GUILEC system/base/syntax.go
wrote `system/base/syntax.go'
  GUILEC system/base/compile.go
wrote `system/base/compile.go'
  GUILEC system/base/language.go
  GUILEC system/base/lalr.go
  GUILEC system/base/message.go
  GUILEC system/base/target.go
wrote `system/base/target.go'
  GUILEC system/base/ck.go
  GUILEC ice-9/r4rs.go
  GUILEC ice-9/r5rs.go
  GUILEC ice-9/deprecated.go
  GUILEC ice-9/and-let-star.go
  GUILEC ice-9/binary-ports.go
  GUILEC ice-9/calling.go
  GUILEC ice-9/command-line.go
wrote `ice-9/command-line.go'
  GUILEC ice-9/common-list.go
wrote `ice-9/common-list.go'
  GUILEC ice-9/control.go
  GUILEC ice-9/curried-definitions.go
  GUILEC ice-9/debug.go
  GUILEC ice-9/documentation.go
wrote `ice-9/documentation.go'
  GUILEC ice-9/eval-string.go
  GUILEC ice-9/expect.go
wrote `ice-9/expect.go'
  GUILEC ice-9/format.go
wrote `ice-9/format.go'
  GUILEC ice-9/futures.go
  GUILEC ice-9/getopt-long.go
  GUILEC ice-9/hcons.go
wrote `ice-9/hcons.go'
  GUILEC ice-9/i18n.go
  GUILEC ice-9/iconv.go
wrote `ice-9/iconv.go'
  GUILEC ice-9/lineio.go
wrote `ice-9/lineio.go'
  GUILEC ice-9/ls.go
  GUILEC ice-9/mapping.go
  GUILEC ice-9/match.go
  GUILEC ice-9/networking.go
  GUILEC ice-9/null.go
  GUILEC ice-9/occam-channel.go
  GUILEC ice-9/optargs.go
  GUILEC ice-9/poe.go
wrote `ice-9/poe.go'
  GUILEC ice-9/poll.go
wrote `ice-9/poll.go'
  GUILEC ice-9/posix.go
  GUILEC ice-9/q.go
  GUILEC ice-9/rdelim.go
wrote `ice-9/rdelim.go'
  GUILEC ice-9/receive.go
  GUILEC ice-9/regex.go
wrote `ice-9/regex.go'
  GUILEC ice-9/runq.go
wrote `ice-9/runq.go'
  GUILEC ice-9/rw.go
  GUILEC ice-9/safe-r5rs.go
  GUILEC ice-9/safe.go
  GUILEC ice-9/save-stack.go
  GUILEC ice-9/scm-style-repl.go
wrote `ice-9/scm-style-repl.go'
  GUILEC ice-9/session.go
wrote `ice-9/session.go'
  GUILEC ice-9/slib.go
  GUILEC ice-9/stack-catch.go
  GUILEC ice-9/streams.go
wrote `ice-9/streams.go'
  GUILEC ice-9/string-fun.go
wrote `ice-9/string-fun.go'
  GUILEC ice-9/syncase.go
  GUILEC ice-9/threads.go
wrote `ice-9/threads.go'
  GUILEC ice-9/top-repl.go
  GUILEC ice-9/buffered-input.go
  GUILEC ice-9/time.go
  GUILEC ice-9/history.go
  GUILEC ice-9/channel.go
  GUILEC ice-9/pretty-print.go
  GUILEC ice-9/ftw.go
wrote `ice-9/ftw.go'
  GUILEC ice-9/gap-buffer.go
wrote `ice-9/gap-buffer.go'
  GUILEC ice-9/weak-vector.go
  GUILEC ice-9/list.go
wrote `ice-9/list.go'
  GUILEC ice-9/serialize.go
  GUILEC ice-9/local-eval.go
wrote `ice-9/local-eval.go'
  GUILEC srfi/srfi-2.go
  GUILEC srfi/srfi-4.go
  GUILEC srfi/srfi-4/gnu.go
  GUILEC srfi/srfi-6.go
wrote `srfi/srfi-6.go'
  GUILEC srfi/srfi-8.go
wrote `srfi/srfi-8.go'
  GUILEC srfi/srfi-9.go
wrote `srfi/srfi-9.go'
  GUILEC srfi/srfi-9/gnu.go
  GUILEC srfi/srfi-10.go
  GUILEC srfi/srfi-11.go
  GUILEC srfi/srfi-13.go
  GUILEC srfi/srfi-14.go
  GUILEC srfi/srfi-16.go
  GUILEC srfi/srfi-17.go
  GUILEC srfi/srfi-18.go
wrote `srfi/srfi-18.go'
  GUILEC srfi/srfi-19.go
wrote `srfi/srfi-19.go'
  GUILEC srfi/srfi-26.go
  GUILEC srfi/srfi-27.go
wrote `srfi/srfi-27.go'
  GUILEC srfi/srfi-31.go
  GUILEC srfi/srfi-34.go
  GUILEC srfi/srfi-35.go
  GUILEC srfi/srfi-37.go
  GUILEC srfi/srfi-38.go
  GUILEC srfi/srfi-41.go
wrote `srfi/srfi-41.go'
  GUILEC srfi/srfi-42.go
wrote `srfi/srfi-42.go'
  GUILEC srfi/srfi-39.go
  GUILEC srfi/srfi-45.go
  GUILEC srfi/srfi-60.go
  GUILEC srfi/srfi-67.go
wrote `srfi/srfi-67.go'
  GUILEC srfi/srfi-69.go
  GUILEC srfi/srfi-88.go
  GUILEC srfi/srfi-98.go
  GUILEC rnrs/base.go
  GUILEC rnrs/conditions.go
  GUILEC rnrs/control.go
  GUILEC rnrs/enums.go
  GUILEC rnrs/eval.go
  GUILEC rnrs/exceptions.go
  GUILEC rnrs/files.go
  GUILEC rnrs/hashtables.go
  GUILEC rnrs/lists.go
  GUILEC rnrs/mutable-pairs.go
  GUILEC rnrs/mutable-strings.go
  GUILEC rnrs/programs.go
  GUILEC rnrs/r5rs.go
  GUILEC rnrs/sorting.go
  GUILEC rnrs/syntax-case.go
  GUILEC rnrs/unicode.go
  GUILEC rnrs/arithmetic/bitwise.go
  GUILEC rnrs/arithmetic/fixnums.go
  GUILEC rnrs/arithmetic/flonums.go
  GUILEC rnrs/bytevectors.go
  GUILEC rnrs/io/simple.go
  GUILEC rnrs/io/ports.go
  GUILEC rnrs/records/inspection.go
  GUILEC rnrs/records/procedural.go
  GUILEC rnrs/records/syntactic.go
  GUILEC rnrs.go
  GUILEC oop/goops.go
wrote `oop/goops.go'
  GUILEC oop/goops/active-slot.go
wrote `oop/goops/active-slot.go'
  GUILEC oop/goops/compile.go
  GUILEC oop/goops/composite-slot.go
  GUILEC oop/goops/describe.go
wrote `oop/goops/describe.go'
  GUILEC oop/goops/dispatch.go
wrote `oop/goops/dispatch.go'
  GUILEC oop/goops/internal.go
wrote `oop/goops/internal.go'
  GUILEC oop/goops/save.go
wrote `oop/goops/save.go'
  GUILEC oop/goops/stklos.go
  GUILEC oop/goops/util.go
  GUILEC oop/goops/accessors.go
  GUILEC oop/goops/simple.go
wrote `oop/goops/simple.go'
  GUILEC system/vm/inspect.go
  GUILEC system/vm/coverage.go
  GUILEC system/vm/frame.go
  GUILEC system/vm/instruction.go
  GUILEC system/vm/objcode.go
  GUILEC system/vm/program.go
  GUILEC system/vm/trace.go
  GUILEC system/vm/traps.go
  GUILEC system/vm/trap-state.go
  GUILEC system/vm/vm.go
  GUILEC system/foreign.go
  GUILEC system/xref.go
wrote `system/xref.go'
  GUILEC system/repl/debug.go
wrote `system/repl/debug.go'
  GUILEC system/repl/error-handling.go
  GUILEC system/repl/common.go
wrote `system/repl/common.go'
  GUILEC system/repl/command.go
wrote `system/repl/command.go'
  GUILEC system/repl/repl.go
  GUILEC system/repl/server.go
wrote `system/repl/server.go'
  GUILEC scripts/compile.go
wrote `scripts/compile.go'
  GUILEC scripts/disassemble.go
wrote `scripts/disassemble.go'
  GUILEC scripts/display-commentary.go
wrote `scripts/display-commentary.go'
  GUILEC scripts/doc-snarf.go
wrote `scripts/doc-snarf.go'
  GUILEC scripts/frisk.go
wrote `scripts/frisk.go'
  GUILEC scripts/generate-autoload.go
wrote `scripts/generate-autoload.go'
  GUILEC scripts/help.go
wrote `scripts/help.go'
  GUILEC scripts/lint.go
wrote `scripts/lint.go'
  GUILEC scripts/list.go
wrote `scripts/list.go'
  GUILEC scripts/punify.go
wrote `scripts/punify.go'
  GUILEC scripts/read-scheme-source.go
wrote `scripts/read-scheme-source.go'
  GUILEC scripts/read-text-outline.go
wrote `scripts/read-text-outline.go'
  GUILEC scripts/use2dot.go
wrote `scripts/use2dot.go'
  GUILEC scripts/snarf-check-and-output-texi.go
wrote `scripts/snarf-check-and-output-texi.go'
  GUILEC scripts/summarize-guile-TODO.go
wrote `scripts/summarize-guile-TODO.go'
  GUILEC scripts/api-diff.go
wrote `scripts/api-diff.go'
  GUILEC scripts/read-rfc822.go
wrote `scripts/read-rfc822.go'
  GUILEC scripts/snarf-guile-m4-docs.go
wrote `scripts/snarf-guile-m4-docs.go'
  GUILEC language/ecmascript/tokenize.go
wrote `language/ecmascript/tokenize.go'
  GUILEC language/ecmascript/parse.go
%% Shift/Reduce conflict (shift 36, reduce 82) on 'lbrace' in state 437
%% Shift/Reduce conflict (shift 35, reduce 82) on 'lparen' in state 437
%% Shift/Reduce conflict (shift 34, reduce 82) on 'lbracket' in state 437
%% Shift/Reduce conflict (shift 33, reduce 82) on 'dot' in state 437
%% Shift/Reduce conflict (shift 32, reduce 82) on 'semicolon' in state 437
%% Shift/Reduce conflict (shift 31, reduce 82) on '+' in state 437
%% Shift/Reduce conflict (shift 30, reduce 82) on '-' in state 437
%% Shift/Reduce conflict (shift 29, reduce 82) on '++' in state 437
%% Shift/Reduce conflict (shift 28, reduce 82) on '--' in state 437
%% Shift/Reduce conflict (shift 27, reduce 82) on '!' in state 437
%% Shift/Reduce conflict (shift 26, reduce 82) on '~' in state 437
%% Shift/Reduce conflict (shift 25, reduce 82) on 'break' in state 437
%% Shift/Reduce conflict (shift 24, reduce 82) on 'new' in state 437
%% Shift/Reduce conflict (shift 23, reduce 82) on 'var' in state 437
%% Shift/Reduce conflict (shift 22, reduce 82) on 'return' in state 437
%% Shift/Reduce conflict (shift 21, reduce 82) on 'void' in state 437
%% Shift/Reduce conflict (shift 20, reduce 82) on 'for' in state 437
%% Shift/Reduce conflict (shift 19, reduce 82) on 'switch' in state 437
%% Shift/Reduce conflict (shift 18, reduce 82) on 'while' in state 437
%% Shift/Reduce conflict (shift 17, reduce 82) on 'continue' in state 437
%% Shift/Reduce conflict (shift 82, reduce 82) on 'function' in state 437
%% Shift/Reduce conflict (shift 15, reduce 82) on 'this' in state 437
%% Shift/Reduce conflict (shift 14, reduce 82) on 'with' in state 437
%% Shift/Reduce conflict (shift 13, reduce 82) on 'if' in state 437
%% Shift/Reduce conflict (shift 12, reduce 82) on 'throw' in state 437
%% Shift/Reduce conflict (shift 11, reduce 82) on 'delete' in state 437
%% Shift/Reduce conflict (shift 10, reduce 82) on 'try' in state 437
%% Shift/Reduce conflict (shift 9, reduce 82) on 'do' in state 437
%% Shift/Reduce conflict (shift 8, reduce 82) on 'typeof' in state 437
%% Shift/Reduce conflict (shift 7, reduce 82) on 'null' in state 437
%% Shift/Reduce conflict (shift 6, reduce 82) on 'true' in state 437
%% Shift/Reduce conflict (shift 5, reduce 82) on 'false' in state 437
%% Shift/Reduce conflict (shift 4, reduce 82) on 'Identifier' in state 437
%% Shift/Reduce conflict (shift 3, reduce 82) on 'StringLiteral' in state 437
%% Shift/Reduce conflict (shift 2, reduce 82) on 'NumericLiteral' in state 437
%% Shift/Reduce conflict (shift 1, reduce 82) on 'RegexpLiteral' in state 437
%% Shift/Reduce conflict (shift 36, reduce 81) on 'lbrace' in state 424
%% Shift/Reduce conflict (shift 35, reduce 81) on 'lparen' in state 424
%% Shift/Reduce conflict (shift 34, reduce 81) on 'lbracket' in state 424
%% Shift/Reduce conflict (shift 33, reduce 81) on 'dot' in state 424
%% Shift/Reduce conflict (shift 32, reduce 81) on 'semicolon' in state 424
%% Shift/Reduce conflict (shift 31, reduce 81) on '+' in state 424
%% Shift/Reduce conflict (shift 30, reduce 81) on '-' in state 424
%% Shift/Reduce conflict (shift 29, reduce 81) on '++' in state 424
%% Shift/Reduce conflict (shift 28, reduce 81) on '--' in state 424
%% Shift/Reduce conflict (shift 27, reduce 81) on '!' in state 424
%% Shift/Reduce conflict (shift 26, reduce 81) on '~' in state 424
%% Shift/Reduce conflict (shift 25, reduce 81) on 'break' in state 424
%% Shift/Reduce conflict (shift 24, reduce 81) on 'new' in state 424
%% Shift/Reduce conflict (shift 23, reduce 81) on 'var' in state 424
%% Shift/Reduce conflict (shift 22, reduce 81) on 'return' in state 424
%% Shift/Reduce conflict (shift 21, reduce 81) on 'void' in state 424
%% Shift/Reduce conflict (shift 20, reduce 81) on 'for' in state 424
%% Shift/Reduce conflict (shift 19, reduce 81) on 'switch' in state 424
%% Shift/Reduce conflict (shift 18, reduce 81) on 'while' in state 424
%% Shift/Reduce conflict (shift 17, reduce 81) on 'continue' in state 424
%% Shift/Reduce conflict (shift 82, reduce 81) on 'function' in state 424
%% Shift/Reduce conflict (shift 15, reduce 81) on 'this' in state 424
%% Shift/Reduce conflict (shift 14, reduce 81) on 'with' in state 424
%% Shift/Reduce conflict (shift 13, reduce 81) on 'if' in state 424
%% Shift/Reduce conflict (shift 12, reduce 81) on 'throw' in state 424
%% Shift/Reduce conflict (shift 11, reduce 81) on 'delete' in state 424
%% Shift/Reduce conflict (shift 10, reduce 81) on 'try' in state 424
%% Shift/Reduce conflict (shift 9, reduce 81) on 'do' in state 424
%% Shift/Reduce conflict (shift 8, reduce 81) on 'typeof' in state 424
%% Shift/Reduce conflict (shift 7, reduce 81) on 'null' in state 424
%% Shift/Reduce conflict (shift 6, reduce 81) on 'true' in state 424
%% Shift/Reduce conflict (shift 5, reduce 81) on 'false' in state 424
%% Shift/Reduce conflict (shift 4, reduce 81) on 'Identifier' in state 424
%% Shift/Reduce conflict (shift 3, reduce 81) on 'StringLiteral' in state 424
%% Shift/Reduce conflict (shift 2, reduce 81) on 'NumericLiteral' in state 424
%% Shift/Reduce conflict (shift 1, reduce 81) on 'RegexpLiteral' in state 424
%% Shift/Reduce conflict (shift 36, reduce 84) on 'lbrace' in state 423
%% Shift/Reduce conflict (shift 35, reduce 84) on 'lparen' in state 423
%% Shift/Reduce conflict (shift 34, reduce 84) on 'lbracket' in state 423
%% Shift/Reduce conflict (shift 33, reduce 84) on 'dot' in state 423
%% Shift/Reduce conflict (shift 32, reduce 84) on 'semicolon' in state 423
%% Shift/Reduce conflict (shift 31, reduce 84) on '+' in state 423
%% Shift/Reduce conflict (shift 30, reduce 84) on '-' in state 423
%% Shift/Reduce conflict (shift 29, reduce 84) on '++' in state 423
%% Shift/Reduce conflict (shift 28, reduce 84) on '--' in state 423
%% Shift/Reduce conflict (shift 27, reduce 84) on '!' in state 423
%% Shift/Reduce conflict (shift 26, reduce 84) on '~' in state 423
%% Shift/Reduce conflict (shift 25, reduce 84) on 'break' in state 423
%% Shift/Reduce conflict (shift 24, reduce 84) on 'new' in state 423
%% Shift/Reduce conflict (shift 23, reduce 84) on 'var' in state 423
%% Shift/Reduce conflict (shift 22, reduce 84) on 'return' in state 423
%% Shift/Reduce conflict (shift 21, reduce 84) on 'void' in state 423
%% Shift/Reduce conflict (shift 20, reduce 84) on 'for' in state 423
%% Shift/Reduce conflict (shift 19, reduce 84) on 'switch' in state 423
%% Shift/Reduce conflict (shift 18, reduce 84) on 'while' in state 423
%% Shift/Reduce conflict (shift 17, reduce 84) on 'continue' in state 423
%% Shift/Reduce conflict (shift 82, reduce 84) on 'function' in state 423
%% Shift/Reduce conflict (shift 15, reduce 84) on 'this' in state 423
%% Shift/Reduce conflict (shift 14, reduce 84) on 'with' in state 423
%% Shift/Reduce conflict (shift 13, reduce 84) on 'if' in state 423
%% Shift/Reduce conflict (shift 12, reduce 84) on 'throw' in state 423
%% Shift/Reduce conflict (shift 11, reduce 84) on 'delete' in state 423
%% Shift/Reduce conflict (shift 10, reduce 84) on 'try' in state 423
%% Shift/Reduce conflict (shift 9, reduce 84) on 'do' in state 423
%% Shift/Reduce conflict (shift 8, reduce 84) on 'typeof' in state 423
%% Shift/Reduce conflict (shift 7, reduce 84) on 'null' in state 423
%% Shift/Reduce conflict (shift 6, reduce 84) on 'true' in state 423
%% Shift/Reduce conflict (shift 5, reduce 84) on 'false' in state 423
%% Shift/Reduce conflict (shift 4, reduce 84) on 'Identifier' in state 423
%% Shift/Reduce conflict (shift 3, reduce 84) on 'StringLiteral' in state 423
%% Shift/Reduce conflict (shift 2, reduce 84) on 'NumericLiteral' in state 423
%% Shift/Reduce conflict (shift 1, reduce 84) on 'RegexpLiteral' in state 423
%% Reduce/Reduce conflict (reduce 11, reduce 7) on '--' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on '++' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on '-' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on '+' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on 'semicolon' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on 'dot' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on 'lbracket' in state 422
%% Reduce/Reduce conflict (reduce 11, reduce 7) on 'lparen' in state 422
%% Shift/Reduce conflict (shift 36, reduce 83) on 'lbrace' in state 400
%% Shift/Reduce conflict (shift 35, reduce 83) on 'lparen' in state 400
%% Shift/Reduce conflict (shift 34, reduce 83) on 'lbracket' in state 400
%% Shift/Reduce conflict (shift 33, reduce 83) on 'dot' in state 400
%% Shift/Reduce conflict (shift 32, reduce 83) on 'semicolon' in state 400
%% Shift/Reduce conflict (shift 31, reduce 83) on '+' in state 400
%% Shift/Reduce conflict (shift 30, reduce 83) on '-' in state 400
%% Shift/Reduce conflict (shift 29, reduce 83) on '++' in state 400
%% Shift/Reduce conflict (shift 28, reduce 83) on '--' in state 400
%% Shift/Reduce conflict (shift 27, reduce 83) on '!' in state 400
%% Shift/Reduce conflict (shift 26, reduce 83) on '~' in state 400
%% Shift/Reduce conflict (shift 25, reduce 83) on 'break' in state 400
%% Shift/Reduce conflict (shift 24, reduce 83) on 'new' in state 400
%% Shift/Reduce conflict (shift 23, reduce 83) on 'var' in state 400
%% Shift/Reduce conflict (shift 22, reduce 83) on 'return' in state 400
%% Shift/Reduce conflict (shift 21, reduce 83) on 'void' in state 400
%% Shift/Reduce conflict (shift 20, reduce 83) on 'for' in state 400
%% Shift/Reduce conflict (shift 19, reduce 83) on 'switch' in state 400
%% Shift/Reduce conflict (shift 18, reduce 83) on 'while' in state 400
%% Shift/Reduce conflict (shift 17, reduce 83) on 'continue' in state 400
%% Shift/Reduce conflict (shift 82, reduce 83) on 'function' in state 400
%% Shift/Reduce conflict (shift 15, reduce 83) on 'this' in state 400
%% Shift/Reduce conflict (shift 14, reduce 83) on 'with' in state 400
%% Shift/Reduce conflict (shift 13, reduce 83) on 'if' in state 400
%% Shift/Reduce conflict (shift 12, reduce 83) on 'throw' in state 400
%% Shift/Reduce conflict (shift 11, reduce 83) on 'delete' in state 400
%% Shift/Reduce conflict (shift 10, reduce 83) on 'try' in state 400
%% Shift/Reduce conflict (shift 9, reduce 83) on 'do' in state 400
%% Shift/Reduce conflict (shift 8, reduce 83) on 'typeof' in state 400
%% Shift/Reduce conflict (shift 7, reduce 83) on 'null' in state 400
%% Shift/Reduce conflict (shift 6, reduce 83) on 'true' in state 400
%% Shift/Reduce conflict (shift 5, reduce 83) on 'false' in state 400
%% Shift/Reduce conflict (shift 4, reduce 83) on 'Identifier' in state 400
%% Shift/Reduce conflict (shift 3, reduce 83) on 'StringLiteral' in state 400
%% Shift/Reduce conflict (shift 2, reduce 83) on 'NumericLiteral' in state 400
%% Shift/Reduce conflict (shift 1, reduce 83) on 'RegexpLiteral' in state 400
%% Reduce/Reduce conflict (reduce 9, reduce 6) on '--' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on '++' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on '-' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on '+' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on 'semicolon' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on 'dot' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on 'lbracket' in state 397
%% Reduce/Reduce conflict (reduce 9, reduce 6) on 'lparen' in state 397
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 393
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 393
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 393
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 393
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 393
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 393
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 393
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 393
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 393
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 393
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 393
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 393
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 393
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 393
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 393
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 393
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 393
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 393
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 393
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 393
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 393
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 393
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 393
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 393
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 393
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 393
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 393
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 393
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 393
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 393
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 393
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 393
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 393
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 393
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 393
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 393
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 369
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 369
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 369
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 369
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 369
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 369
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 369
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 369
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 369
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 369
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 369
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 369
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 369
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 369
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 369
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 369
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 369
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 369
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 369
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 369
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 369
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 369
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 369
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 369
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 369
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 369
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 369
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 369
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 369
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 369
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 369
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 369
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 369
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 369
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 369
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 369
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 363
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 363
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 363
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 363
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 363
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 363
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 363
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 363
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 363
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 363
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 363
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 363
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 363
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 363
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 363
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 363
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 363
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 363
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 363
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 363
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 363
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 363
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 363
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 363
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 363
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 363
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 363
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 363
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 363
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 363
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 363
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 363
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 363
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 363
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 363
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 363
%% Shift/Reduce conflict (shift 170, reduce 139) on '++' in state 338
%% Shift/Reduce conflict (shift 169, reduce 139) on '--' in state 338
%% Shift/Reduce conflict (shift 168, reduce 139) on '=' in state 338
%% Shift/Reduce conflict (shift 167, reduce 139) on '+=' in state 338
%% Shift/Reduce conflict (shift 166, reduce 139) on '-=' in state 338
%% Shift/Reduce conflict (shift 165, reduce 139) on '*=' in state 338
%% Shift/Reduce conflict (shift 164, reduce 139) on '%=' in state 338
%% Shift/Reduce conflict (shift 163, reduce 139) on '<<=' in state 338
%% Shift/Reduce conflict (shift 162, reduce 139) on '>>=' in state 338
%% Shift/Reduce conflict (shift 161, reduce 139) on '>>>=' in state 338
%% Shift/Reduce conflict (shift 160, reduce 139) on '&=' in state 338
%% Shift/Reduce conflict (shift 159, reduce 139) on 'bor=' in state 338
%% Shift/Reduce conflict (shift 158, reduce 139) on '^=' in state 338
%% Shift/Reduce conflict (shift 157, reduce 139) on '/=' in state 338
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 326
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 326
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 326
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 326
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 326
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 326
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 326
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 326
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 326
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 326
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 326
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 326
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 326
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 326
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 326
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 326
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 326
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 326
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 326
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 326
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 326
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 326
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 326
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 326
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 326
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 326
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 326
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 326
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 326
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 326
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 326
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 326
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 326
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 326
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 326
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 326
%% Shift/Reduce conflict (shift 36, reduce 16) on 'lbrace' in state 324
%% Shift/Reduce conflict (shift 35, reduce 16) on 'lparen' in state 324
%% Shift/Reduce conflict (shift 34, reduce 16) on 'lbracket' in state 324
%% Shift/Reduce conflict (shift 33, reduce 16) on 'dot' in state 324
%% Shift/Reduce conflict (shift 32, reduce 16) on 'semicolon' in state 324
%% Shift/Reduce conflict (shift 31, reduce 16) on '+' in state 324
%% Shift/Reduce conflict (shift 30, reduce 16) on '-' in state 324
%% Shift/Reduce conflict (shift 29, reduce 16) on '++' in state 324
%% Shift/Reduce conflict (shift 28, reduce 16) on '--' in state 324
%% Shift/Reduce conflict (shift 27, reduce 16) on '!' in state 324
%% Shift/Reduce conflict (shift 26, reduce 16) on '~' in state 324
%% Shift/Reduce conflict (shift 25, reduce 16) on 'break' in state 324
%% Shift/Reduce conflict (shift 24, reduce 16) on 'new' in state 324
%% Shift/Reduce conflict (shift 23, reduce 16) on 'var' in state 324
%% Shift/Reduce conflict (shift 22, reduce 16) on 'return' in state 324
%% Shift/Reduce conflict (shift 21, reduce 16) on 'void' in state 324
%% Shift/Reduce conflict (shift 20, reduce 16) on 'for' in state 324
%% Shift/Reduce conflict (shift 19, reduce 16) on 'switch' in state 324
%% Shift/Reduce conflict (shift 18, reduce 16) on 'while' in state 324
%% Shift/Reduce conflict (shift 17, reduce 16) on 'continue' in state 324
%% Shift/Reduce conflict (shift 16, reduce 16) on 'function' in state 324
%% Shift/Reduce conflict (shift 15, reduce 16) on 'this' in state 324
%% Shift/Reduce conflict (shift 14, reduce 16) on 'with' in state 324
%% Shift/Reduce conflict (shift 13, reduce 16) on 'if' in state 324
%% Shift/Reduce conflict (shift 12, reduce 16) on 'throw' in state 324
%% Shift/Reduce conflict (shift 11, reduce 16) on 'delete' in state 324
%% Shift/Reduce conflict (shift 10, reduce 16) on 'try' in state 324
%% Shift/Reduce conflict (shift 9, reduce 16) on 'do' in state 324
%% Shift/Reduce conflict (shift 8, reduce 16) on 'typeof' in state 324
%% Shift/Reduce conflict (shift 7, reduce 16) on 'null' in state 324
%% Shift/Reduce conflict (shift 6, reduce 16) on 'true' in state 324
%% Shift/Reduce conflict (shift 5, reduce 16) on 'false' in state 324
%% Shift/Reduce conflict (shift 4, reduce 16) on 'Identifier' in state 324
%% Shift/Reduce conflict (shift 3, reduce 16) on 'StringLiteral' in state 324
%% Shift/Reduce conflict (shift 2, reduce 16) on 'NumericLiteral' in state 324
%% Shift/Reduce conflict (shift 1, reduce 16) on 'RegexpLiteral' in state 324
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 321
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 321
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 321
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 321
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 321
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 321
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 321
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 321
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 321
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 321
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 321
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 321
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 321
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 321
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 321
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 321
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 321
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 321
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 321
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 321
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 321
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 321
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 321
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 321
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 321
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 321
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 321
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 321
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 321
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 321
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 321
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 321
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 321
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 321
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 321
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 321
%% Shift/Reduce conflict (shift 367, reduce 49) on 'else' in state 319
%% Shift/Reduce conflict (shift 216, reduce 42) on '=' in state 279
%% Shift/Reduce conflict (shift 36, reduce 17) on 'lbrace' in state 274
%% Shift/Reduce conflict (shift 35, reduce 17) on 'lparen' in state 274
%% Shift/Reduce conflict (shift 34, reduce 17) on 'lbracket' in state 274
%% Shift/Reduce conflict (shift 33, reduce 17) on 'dot' in state 274
%% Shift/Reduce conflict (shift 32, reduce 17) on 'semicolon' in state 274
%% Shift/Reduce conflict (shift 31, reduce 17) on '+' in state 274
%% Shift/Reduce conflict (shift 30, reduce 17) on '-' in state 274
%% Shift/Reduce conflict (shift 29, reduce 17) on '++' in state 274
%% Shift/Reduce conflict (shift 28, reduce 17) on '--' in state 274
%% Shift/Reduce conflict (shift 27, reduce 17) on '!' in state 274
%% Shift/Reduce conflict (shift 26, reduce 17) on '~' in state 274
%% Shift/Reduce conflict (shift 25, reduce 17) on 'break' in state 274
%% Shift/Reduce conflict (shift 24, reduce 17) on 'new' in state 274
%% Shift/Reduce conflict (shift 23, reduce 17) on 'var' in state 274
%% Shift/Reduce conflict (shift 22, reduce 17) on 'return' in state 274
%% Shift/Reduce conflict (shift 21, reduce 17) on 'void' in state 274
%% Shift/Reduce conflict (shift 20, reduce 17) on 'for' in state 274
%% Shift/Reduce conflict (shift 19, reduce 17) on 'switch' in state 274
%% Shift/Reduce conflict (shift 18, reduce 17) on 'while' in state 274
%% Shift/Reduce conflict (shift 17, reduce 17) on 'continue' in state 274
%% Shift/Reduce conflict (shift 16, reduce 17) on 'function' in state 274
%% Shift/Reduce conflict (shift 15, reduce 17) on 'this' in state 274
%% Shift/Reduce conflict (shift 14, reduce 17) on 'with' in state 274
%% Shift/Reduce conflict (shift 13, reduce 17) on 'if' in state 274
%% Shift/Reduce conflict (shift 12, reduce 17) on 'throw' in state 274
%% Shift/Reduce conflict (shift 11, reduce 17) on 'delete' in state 274
%% Shift/Reduce conflict (shift 10, reduce 17) on 'try' in state 274
%% Shift/Reduce conflict (shift 9, reduce 17) on 'do' in state 274
%% Shift/Reduce conflict (shift 8, reduce 17) on 'typeof' in state 274
%% Shift/Reduce conflict (shift 7, reduce 17) on 'null' in state 274
%% Shift/Reduce conflict (shift 6, reduce 17) on 'true' in state 274
%% Shift/Reduce conflict (shift 5, reduce 17) on 'false' in state 274
%% Shift/Reduce conflict (shift 4, reduce 17) on 'Identifier' in state 274
%% Shift/Reduce conflict (shift 3, reduce 17) on 'StringLiteral' in state 274
%% Shift/Reduce conflict (shift 2, reduce 17) on 'NumericLiteral' in state 274
%% Shift/Reduce conflict (shift 1, reduce 17) on 'RegexpLiteral' in state 274
%% Shift/Reduce conflict (shift 144, reduce 177) on 'in' in state 242
%% Shift/Reduce conflict (shift 144, reduce 178) on 'in' in state 241
%% Shift/Reduce conflict (shift 144, reduce 179) on 'in' in state 240
%% Shift/Reduce conflict (shift 144, reduce 180) on 'in' in state 239
%% Shift/Reduce conflict (shift 170, reduce 139) on '++' in state 214
%% Shift/Reduce conflict (shift 169, reduce 139) on '--' in state 214
%% Shift/Reduce conflict (shift 168, reduce 139) on '=' in state 214
%% Shift/Reduce conflict (shift 167, reduce 139) on '+=' in state 214
%% Shift/Reduce conflict (shift 166, reduce 139) on '-=' in state 214
%% Shift/Reduce conflict (shift 165, reduce 139) on '*=' in state 214
%% Shift/Reduce conflict (shift 164, reduce 139) on '%=' in state 214
%% Shift/Reduce conflict (shift 163, reduce 139) on '<<=' in state 214
%% Shift/Reduce conflict (shift 162, reduce 139) on '>>=' in state 214
%% Shift/Reduce conflict (shift 161, reduce 139) on '>>>=' in state 214
%% Shift/Reduce conflict (shift 160, reduce 139) on '&=' in state 214
%% Shift/Reduce conflict (shift 159, reduce 139) on 'bor=' in state 214
%% Shift/Reduce conflict (shift 158, reduce 139) on '^=' in state 214
%% Shift/Reduce conflict (shift 157, reduce 139) on '/=' in state 214
%% Shift/Reduce conflict (shift 301, reduce 139) on 'in' in state 214
%% Shift/Reduce conflict (shift 188, reduce 87) on 'finally' in state 190
%% Shift/Reduce conflict (shift 80, reduce 119) on 'colon' in state 125
%% Shift/Reduce conflict (shift 174, reduce 127) on 'lparen' in state 107
%% Shift/Reduce conflict (shift 177, reduce 127) on 'lbracket' in state 107
%% Shift/Reduce conflict (shift 176, reduce 127) on 'dot' in state 107
%% Shift/Reduce conflict (shift 216, reduce 40) on '=' in state 103
%% Shift/Reduce conflict (shift 170, reduce 139) on '++' in state 85
%% Shift/Reduce conflict (shift 169, reduce 139) on '--' in state 85
%% Shift/Reduce conflict (shift 36, reduce 2) on 'lbrace' in state 75
%% Shift/Reduce conflict (shift 35, reduce 2) on 'lparen' in state 75
%% Shift/Reduce conflict (shift 34, reduce 2) on 'lbracket' in state 75
%% Shift/Reduce conflict (shift 33, reduce 2) on 'dot' in state 75
%% Shift/Reduce conflict (shift 32, reduce 2) on 'semicolon' in state 75
%% Shift/Reduce conflict (shift 31, reduce 2) on '+' in state 75
%% Shift/Reduce conflict (shift 30, reduce 2) on '-' in state 75
%% Shift/Reduce conflict (shift 29, reduce 2) on '++' in state 75
%% Shift/Reduce conflict (shift 28, reduce 2) on '--' in state 75
%% Shift/Reduce conflict (shift 27, reduce 2) on '!' in state 75
%% Shift/Reduce conflict (shift 26, reduce 2) on '~' in state 75
%% Shift/Reduce conflict (shift 25, reduce 2) on 'break' in state 75
%% Shift/Reduce conflict (shift 24, reduce 2) on 'new' in state 75
%% Shift/Reduce conflict (shift 23, reduce 2) on 'var' in state 75
%% Shift/Reduce conflict (shift 22, reduce 2) on 'return' in state 75
%% Shift/Reduce conflict (shift 21, reduce 2) on 'void' in state 75
%% Shift/Reduce conflict (shift 20, reduce 2) on 'for' in state 75
%% Shift/Reduce conflict (shift 19, reduce 2) on 'switch' in state 75
%% Shift/Reduce conflict (shift 18, reduce 2) on 'while' in state 75
%% Shift/Reduce conflict (shift 17, reduce 2) on 'continue' in state 75
%% Shift/Reduce conflict (shift 16, reduce 2) on 'function' in state 75
%% Shift/Reduce conflict (shift 15, reduce 2) on 'this' in state 75
%% Shift/Reduce conflict (shift 14, reduce 2) on 'with' in state 75
%% Shift/Reduce conflict (shift 13, reduce 2) on 'if' in state 75
%% Shift/Reduce conflict (shift 12, reduce 2) on 'throw' in state 75
%% Shift/Reduce conflict (shift 11, reduce 2) on 'delete' in state 75
%% Shift/Reduce conflict (shift 10, reduce 2) on 'try' in state 75
%% Shift/Reduce conflict (shift 9, reduce 2) on 'do' in state 75
%% Shift/Reduce conflict (shift 8, reduce 2) on 'typeof' in state 75
%% Shift/Reduce conflict (shift 7, reduce 2) on 'null' in state 75
%% Shift/Reduce conflict (shift 6, reduce 2) on 'true' in state 75
%% Shift/Reduce conflict (shift 5, reduce 2) on 'false' in state 75
%% Shift/Reduce conflict (shift 4, reduce 2) on 'Identifier' in state 75
%% Shift/Reduce conflict (shift 3, reduce 2) on 'StringLiteral' in state 75
%% Shift/Reduce conflict (shift 2, reduce 2) on 'NumericLiteral' in state 75
%% Shift/Reduce conflict (shift 1, reduce 2) on 'RegexpLiteral' in state 75
%% Shift/Reduce conflict (shift 174, reduce 127) on 'lparen' in state 56
%% Shift/Reduce conflict (shift 177, reduce 127) on 'lbracket' in state 56
%% Shift/Reduce conflict (shift 176, reduce 127) on 'dot' in state 56
%% Shift/Reduce conflict (shift 174, reduce 138) on 'lparen' in state 54
%% Shift/Reduce conflict (shift 173, reduce 138) on 'lbracket' in state 54
%% Shift/Reduce conflict (shift 172, reduce 138) on 'dot' in state 54
%% Shift/Reduce conflict (shift 170, reduce 139) on '++' in state 53
%% Shift/Reduce conflict (shift 169, reduce 139) on '--' in state 53
%% Shift/Reduce conflict (shift 168, reduce 139) on '=' in state 53
%% Shift/Reduce conflict (shift 167, reduce 139) on '+=' in state 53
%% Shift/Reduce conflict (shift 166, reduce 139) on '-=' in state 53
%% Shift/Reduce conflict (shift 165, reduce 139) on '*=' in state 53
%% Shift/Reduce conflict (shift 164, reduce 139) on '%=' in state 53
%% Shift/Reduce conflict (shift 163, reduce 139) on '<<=' in state 53
%% Shift/Reduce conflict (shift 162, reduce 139) on '>>=' in state 53
%% Shift/Reduce conflict (shift 161, reduce 139) on '>>>=' in state 53
%% Shift/Reduce conflict (shift 160, reduce 139) on '&=' in state 53
%% Shift/Reduce conflict (shift 159, reduce 139) on 'bor=' in state 53
%% Shift/Reduce conflict (shift 158, reduce 139) on '^=' in state 53
%% Shift/Reduce conflict (shift 157, reduce 139) on '/=' in state 53
%% Shift/Reduce conflict (shift 153, reduce 159) on '+' in state 49
%% Shift/Reduce conflict (shift 152, reduce 159) on '-' in state 49
%% Shift/Reduce conflict (shift 144, reduce 176) on 'in' in state 47
wrote `language/ecmascript/parse.go'
  GUILEC language/ecmascript/impl.go
  GUILEC language/ecmascript/base.go
wrote `language/ecmascript/base.go'
  GUILEC language/ecmascript/function.go
wrote `language/ecmascript/function.go'
  GUILEC language/ecmascript/array.go
wrote `language/ecmascript/array.go'
  GUILEC language/ecmascript/compile-tree-il.go
wrote `language/ecmascript/compile-tree-il.go'
  GUILEC language/ecmascript/spec.go
wrote `language/ecmascript/spec.go'
  GUILEC language/elisp/lexer.go
wrote `language/elisp/lexer.go'
  GUILEC language/elisp/parser.go
wrote `language/elisp/parser.go'
  GUILEC language/elisp/bindings.go
wrote `language/elisp/bindings.go'
  GUILEC language/elisp/compile-tree-il.go
  GUILEC language/elisp/runtime.go
wrote `language/elisp/runtime.go'
  GUILEC language/elisp/runtime/function-slot.go
wrote `language/elisp/runtime/function-slot.go'
  GUILEC language/elisp/runtime/value-slot.go
wrote `language/elisp/runtime/value-slot.go'
  GUILEC language/elisp/runtime/macros.go
wrote `language/elisp/runtime/macros.go'
  GUILEC language/elisp/runtime/subrs.go
wrote `language/elisp/runtime/subrs.go'
  GUILEC language/elisp/spec.go
wrote `language/elisp/spec.go'
  GUILEC language/brainfuck/parse.go
wrote `language/brainfuck/parse.go'
  GUILEC language/brainfuck/compile-scheme.go
wrote `language/brainfuck/compile-scheme.go'
  GUILEC language/brainfuck/compile-tree-il.go
wrote `language/brainfuck/compile-tree-il.go'
  GUILEC language/brainfuck/spec.go
wrote `language/brainfuck/spec.go'
  GUILEC statprof.go
wrote `statprof.go'
  GUILEC sxml/apply-templates.go
wrote `sxml/apply-templates.go'
  GUILEC sxml/fold.go
wrote `sxml/fold.go'
  GUILEC sxml/match.go
wrote `sxml/match.go'
  GUILEC sxml/simple.go
  GUILEC sxml/ssax/input-parse.go
wrote `sxml/ssax/input-parse.go'
  GUILEC sxml/ssax.go
wrote `sxml/ssax.go'
  GUILEC sxml/transform.go
wrote `sxml/transform.go'
  GUILEC sxml/xpath.go
wrote `sxml/xpath.go'
  GUILEC texinfo.go
wrote `texinfo.go'
  GUILEC texinfo/docbook.go
wrote `texinfo/docbook.go'
  GUILEC texinfo/html.go
wrote `texinfo/html.go'
  GUILEC texinfo/indexing.go
wrote `texinfo/indexing.go'
  GUILEC texinfo/string-utils.go
wrote `texinfo/string-utils.go'
  GUILEC texinfo/plain-text.go
wrote `texinfo/plain-text.go'
  GUILEC texinfo/reflection.go
wrote `texinfo/reflection.go'
  GUILEC texinfo/serialize.go
wrote `texinfo/serialize.go'
  GUILEC web/client.go
wrote `web/client.go'
  GUILEC web/http.go
wrote `web/http.go'
  GUILEC web/request.go
wrote `web/request.go'
  GUILEC web/response.go
wrote `web/response.go'
  GUILEC web/server.go
wrote `web/server.go'
  GUILEC web/server/http.go
wrote `web/server/http.go'
  GUILEC web/uri.go
wrote `web/uri.go'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/module'
Making all in guile-readline
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/guile-readline'
make  all-am
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/guile-readline'
  CC       readline.lo
  CCLD     libguilereadline-v-18.la

*** Warning: linker path does not have real file for library -lncurses.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libncurses and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libncurses.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/guile-readline'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/guile-readline'
Making all in examples
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/examples'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/examples'
Making all in emacs
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/emacs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/emacs'
Making all in test-suite
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/test-suite'
Making all in standalone
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/test-suite/standalone'
make  all-am
make[4]: Entering directory `/home/XPMUser/guile-2.0.9/test-suite/standalone'
  CC       libtest_asmobs_la-test-asmobs-lib.lo
  CCLD     libtest-asmobs.la
  CC       libtest_ffi_la-test-ffi-lib.lo
  CCLD     libtest-ffi.la
  CC       libtest_extensions_la-test-extensions-lib.lo
  CCLD     libtest-extensions.la
make[4]: Leaving directory `/home/XPMUser/guile-2.0.9/test-suite/standalone'
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/test-suite/standalone'
Making all in vm
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/test-suite/vm'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/test-suite/vm'
make[3]: Entering directory `/home/XPMUser/guile-2.0.9/test-suite'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/XPMUser/guile-2.0.9/test-suite'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/test-suite'
Making all in benchmark-suite
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/benchmark-suite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/benchmark-suite'
Making all in gc-benchmarks
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/gc-benchmarks'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/gc-benchmarks'
Making all in am
make[2]: Entering directory `/home/XPMUser/guile-2.0.9/am'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9/am'
make[2]: Entering directory `/home/XPMUser/guile-2.0.9'
make[2]: Leaving directory `/home/XPMUser/guile-2.0.9'
make[1]: Leaving directory `/home/XPMUser/guile-2.0.9'

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

Ping!  Any ideas on the below?

> Date: Wed, 22 May 2013 18:26:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: guile-user@gnu.org
> 
> > From: Andy Wingo <wingo@pobox.com>
> > Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,  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 problem here:
> > >
> > >   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
> > >
> > > So far no replies.  I hope to hear from them some day.
> > 
> > Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
> > backtrace somehow?
> 
> I did my best, see below.  Running meta/gdb-uninstalled-guile cannot
> help here, because the problem happens in a child Guile process, and
> GDB on Windows doesn't support follow-fork/exec-mode.
> 
> Instead, I concatenated manually all the *.doc files, then ran this
> command (the one that crashed, as revealed by "make V=1"):
> 
>   GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0  ../meta/uninstalled-env \
>     guild snarf-check-and-output-texi < all-docs.doc > guile-procedures.texi
> 
> and then attached GDB to the child Guile process and looked around.
> 
> What I found is something I'll need a lot of help with.  The backtrace
> displayed by Guile looks like this:
> 
>      Backtrace:
>      In unknown file:
> 	?: 4 [apply-smob/1 #<catch-closure c1ddf0> quit #<unspecified>]
>      In ice-9/eval.scm:
>       484: 3 [eval # #]
>       481: 2 [lp (#<fluid 13>) (#<procedure 41c1c78 at ice-9/eval.scm:264:7 %args>)]
>      In unknown file:
> 	?: 1 [apply-smob/1 #<catch-closure 643d730>]
>      In ice-9/eval.scm:
>       481: 0 [lp (#<fluid 12>) ((#<catch-closure 643d710>))]
> 
>      ice-9/eval.scm:481:19:
>                            ^
> 
> Yes, the last line is really unfinished, and the cursor sits where
> shown.  But typing at this stage has no effect.
> 
> Setting a breakpoint on all 3 places that print "Backtrace:", I get
> this C backtrace:
> 
>   Breakpoint 2, print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490
>   490           scm_display_backtrace_with_highlights (stack, port,
>   (gdb) bt
>   #0  print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490
>   #1  pre_unwind_handler (error_port=error_port@entry=0x935c40, tag=0x89c6f0,
>       args=args@entry=0x37ff610) at continuations.c:534
>   #2  0x00430eae in apply_catch_closure (clo=0x643d710, args=0x37ff608)
>       at throw.c:151
>   #3  0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
>       argv=0xa01120, nargs=5121210) at vm-i-system.c:855
>   #4  0x0045668b in scm_call_with_vm (vm=0x935c80, proc=0x896af0,
>       args=<optimized out>) at vm.c:1045
>   #5  0x00412f87 in scm_apply (proc=0x935c80, arg1=0x896af0,
>       args=<optimized out>) at eval.c:748
>   #6  0x004148fd in scm_apply_1 (proc=0x935c80, arg1=0x896af0,
>       arg1@entry=0x89c6f0, args=0x37ff828, args@entry=0x37ff830) at eval.c:588
>   #7  0x0043139b in scm_throw (key=0x89c6f0, args=0x37ff830) at throw.c:104
>   #8  0x00431819 in scm_ithrow (key=key@entry=0x89c6f0, args=0x37ff830,
>       noreturn=noreturn@entry=1) at throw.c:441
>   #9  0x0041f507 in scm_error_scm (key=key@entry=0x89c6f0, subr=0x4,
>       message=message@entry=0x643d630, args=args@entry=0x37ff850,
>       data=data@entry=0x37ff870) at error.c:95
>   #10 0x0041f577 in scm_error (key=0x89c6f0, subr=subr@entry=0x0,
>       message=message@entry=0x4dd99c <scm_eval_string_in_module__name_string_stringbuf+72> "~A", args=0x37ff850, rest=rest@entry=0x37ff870) at error.c:62
>   #11 0x0041f5fa in scm_syserror (subr=subr@entry=0x0) at error.c:167
>   #12 0x00432fe3 in scm_spawn_thread (
>       body=body@entry=0x436340 <signal_delivery_thread>,
>       body_data=body_data@entry=0x0, handler=0x431794 <scm_handle_by_message>,
>       handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1139
>   #13 0x00436318 in start_signal_delivery_thread () at scmsigs.c:200
>   #14 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
>   #15 0x0043641c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
>   #16 0x00432c00 in do_thread_exit (v=0x8d0f00) at threads.c:671
>   #17 0x0045f8ac in c_body (d=0x28f6a0) at continuations.c:511
>   #18 0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
>       argv=0xa010a4, nargs=5121210) at vm-i-system.c:855
>   #19 0x004145f8 in scm_call_4 (proc=0x896b28, arg1=arg1@entry=0x404,
>       arg2=arg2@entry=0x643d730, arg3=arg3@entry=0x643d720,
>       arg4=arg4@entry=0x643d710) at eval.c:507
>   #20 0x004312a2 in scm_catch_with_pre_unwind_handler (key=0x404,
>       thunk=0x643d730, handler=0x643d720, pre_unwind_handler=0x643d710)
>       at throw.c:86
>   #21 0x0043143e in scm_c_catch (tag=tag@entry=0x404, body=0x643d730,
>       body@entry=0x45f89c <c_body>, body_data=0x643d720,
>       body_data@entry=0x28f6a0, handler=0x643d710,
>       handler@entry=0x45fb50 <c_handler>,
>       handler_data=handler_data@entry=0x28f6a0,
>       pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0x935c40) at throw.c:213
>   #22 0x0045ff3b in scm_i_with_continuation_barrier (
>       body=body@entry=0x45f89c <c_body>, body_data=body_data@entry=0x28f6a0,
>       handler=handler@entry=0x45fb50 <c_handler>,
>       handler_data=handler_data@entry=0x28f6a0,
>       pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=0x935c40) at continuations.c:449
>   #23 0x0045ffcc in scm_c_with_continuation_barrier (
>       func=0x432bf0 <do_thread_exit>, data=0x8d0f00) at continuations.c:545
>   #24 0x00431df4 in with_guile_trampoline (data=0x28f790) at threads.c:890
>   #25 0x709cffa0 in ?? () from d:\usr\bin\libgc-1.dll
>   #26 0x004326dc in with_gc_active (data=0x28f790,
>       func=0x431ddc <with_guile_trampoline>) at threads.c:238
>   #27 with_guile_and_parent (base=0x28f768, data=0x28f790) at threads.c:936
>   #28 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
>   #29 0x004328e0 in scm_i_with_guile_and_parent (parent=<optimized out>,
>       data=0x8d0f00, func=0x432bf0 <do_thread_exit>) at threads.c:951
>   #30 scm_with_guile (func=0x432bf0 <do_thread_exit>, data=0x8d0f00)
>       at threads.c:957
>   #31 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
>   #32 0x00431e66 in on_thread_exit (v=0x8d0f00) at threads.c:754
>   #33 0x62481f14 in ptw32_callUserDestroyRoutines ()
>      from d:\usr\bin\pthreadGC2.dll
>   #34 0x624855a1 in pthread_win32_thread_detach_np ()
>      from d:\usr\bin\pthreadGC2.dll
>   #35 0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll
>   #36 0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthreadGC2.dll
> 
> What's more, after this backtrace is displayed, guile hangs here:
> 
>      void
>      scm_i_close_signal_pipe()
>      {
>        /* SIGNAL_DELIVERY_THREAD_MUTEX is only locked while the signal delivery
> 	  thread is being launched.  The thread that calls this function is
> 	  already holding the thread admin mutex, so if the delivery thread hasn't
> 	  been launched at this point, it never will be before shutdown.  */
>  >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
> 
>      #if SCM_USE_PTHREAD_THREADS
>        if (scm_i_signal_delivery_thread != NULL)
> 	 close (signal_pipe[1]);
>      #endif
> 
>        scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
>      }
> 
> The backtrace is displayed before that, probably from a different
> thread, because I also tried to step through the code that eventually
> comes to scm_i_close_signal_pipe, and that didn't go through the
> function shown above that displays the Guile backtrace.
> 
> Now, I know almost nothing about pthreads.  Any ideas or suggestions
> for further debugging are most welcome.
> 
> P.S.  Should we talk about this on bug-guile instead?
> 
> 

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Hi Eli,

And sorry for the loooong delay.

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: Andy Wingo <wingo@pobox.com>
>> Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,  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 problem here:
>> >
>> >   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
>> >
>> > So far no replies.  I hope to hear from them some day.
>> 
>> Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
>> backtrace somehow?
>
> I did my best, see below.  Running meta/gdb-uninstalled-guile cannot
> help here, because the problem happens in a child Guile process, and
> GDB on Windows doesn't support follow-fork/exec-mode.
>
> Instead, I concatenated manually all the *.doc files, then ran this
> command (the one that crashed, as revealed by "make V=1"):
>
>   GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0  ../meta/uninstalled-env \
>     guild snarf-check-and-output-texi < all-docs.doc > guile-procedures.texi
>
> and then attached GDB to the child Guile process and looked around.
>
> What I found is something I'll need a lot of help with.  The backtrace
> displayed by Guile looks like this:
>
>      Backtrace:
>      In unknown file:
> 	?: 4 [apply-smob/1 #<catch-closure c1ddf0> quit #<unspecified>]
>      In ice-9/eval.scm:
>       484: 3 [eval # #]
>       481: 2 [lp (#<fluid 13>) (#<procedure 41c1c78 at ice-9/eval.scm:264:7 %args>)]
>      In unknown file:
> 	?: 1 [apply-smob/1 #<catch-closure 643d730>]
>      In ice-9/eval.scm:
>       481: 0 [lp (#<fluid 12>) ((#<catch-closure 643d710>))]
>
>      ice-9/eval.scm:481:19:
>                            ^
>
> Yes, the last line is really unfinished, and the cursor sits where
> shown.  But typing at this stage has no effect.
>
> Setting a breakpoint on all 3 places that print "Backtrace:", I get
> this C backtrace:
>
>   Breakpoint 2, print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490
>   490           scm_display_backtrace_with_highlights (stack, port,
>   (gdb) bt
>   #0  print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490

[...]

>   #11 0x0041f5fa in scm_syserror (subr=subr@entry=0x0) at error.c:167
>   #12 0x00432fe3 in scm_spawn_thread (
>       body=body@entry=0x436340 <signal_delivery_thread>,
>       body_data=body_data@entry=0x0, handler=0x431794 <scm_handle_by_message>,
>       handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1139
>   #13 0x00436318 in start_signal_delivery_thread () at scmsigs.c:200
>   #14 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
>   #15 0x0043641c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
>   #16 0x00432c00 in do_thread_exit (v=0x8d0f00) at threads.c:671

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?

Did you build them with pthread support (this is the default for Guile)?

> What's more, after this backtrace is displayed, guile hangs here:
>
>      void
>      scm_i_close_signal_pipe()
>      {
>        /* SIGNAL_DELIVERY_THREAD_MUTEX is only locked while the signal delivery
> 	  thread is being launched.  The thread that calls this function is
> 	  already holding the thread admin mutex, so if the delivery thread hasn't
> 	  been launched at this point, it never will be before shutdown.  */
>  >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
>
>      #if SCM_USE_PTHREAD_THREADS
>        if (scm_i_signal_delivery_thread != NULL)
> 	 close (signal_pipe[1]);
>      #endif
>
>        scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
>      }

Can you run ‘thread apply all bt’ in gdb once it’s hang, and send the
tip of the C backtraces for all the threads?

Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@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-7.2d.

> Did you build them with pthread support (this is the default for Guile)?

Yes.

> > What's more, after this backtrace is displayed, guile hangs here:
> >
> >      void
> >      scm_i_close_signal_pipe()
> >      {
> >        /* SIGNAL_DELIVERY_THREAD_MUTEX is only locked while the signal delivery
> > 	  thread is being launched.  The thread that calls this function is
> > 	  already holding the thread admin mutex, so if the delivery thread hasn't
> > 	  been launched at this point, it never will be before shutdown.  */
> >  >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
> >
> >      #if SCM_USE_PTHREAD_THREADS
> >        if (scm_i_signal_delivery_thread != NULL)
> > 	 close (signal_pipe[1]);
> >      #endif
> >
> >        scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
> >      }
> 
> Can you run ‘thread apply all bt’ in gdb once it’s hang, and send the
> tip of the C backtraces for all the threads?

I'll try.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Fri, 07 Jun 2013 17:59:57 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 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 while the signal delivery
> > > 	  thread is being launched.  The thread that calls this function is
> > > 	  already holding the thread admin mutex, so if the delivery thread hasn't
> > > 	  been launched at this point, it never will be before shutdown.  */
> > >  >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
> > >
> > >      #if SCM_USE_PTHREAD_THREADS
> > >        if (scm_i_signal_delivery_thread != NULL)
> > > 	 close (signal_pipe[1]);
> > >      #endif
> > >
> > >        scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
> > >      }
> > 
> > Can you run ‘thread apply all bt’ in gdb once it’s hang, and send the
> > tip of the C backtraces for all the threads?
> 
> I'll try.

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 we are
talking about a child guile process -- it's that one that prints the
weird traceback and hangs.  The parent just waits for the child to
finish.

Here's the backtrace with some context info:

     GNU gdb (GDB) 7.6
     Copyright (C) 2013 Free Software Foundation, Inc.
     License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
     This is free software: you are free to change and redistribute it.
     There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
     and "show warranty" for details.
     This GDB was configured as "i686-pc-mingw32".
     For bug reporting instructions, please see:
     <http://www.gnu.org/software/gdb/bugs/>.
     Attaching to process 5864
     [New Thread 5864.0x15cc]
     [New Thread 5864.0x1dc4]
     Reading symbols from d:\usr\eli\utils\guile-2.0.9\libguile\.libs\guile.exe...done.
     (gdb) info threads
       Id   Target Id         Frame
     * 2    Thread 5864.0x1dc4 0x77c4000d in ntdll!DbgBreakPoint ()
	from C:\Windows\SysWOW64\ntdll.dll
       1    Thread 5864.0x15cc vm_regular_engine (vm=0xf65c80, program=0xfa0f98,
	 argv=0x0, nargs=0) at vm-i-system.c:779
     (gdb) bre
     break        break-range
     (gdb) break scmsi
     scmsigs.c  scmsigs.x
     (gdb) break scmsigs.c:662
     Breakpoint 1 at 0x43671b: file scmsigs.c, line 662.
     (gdb) c
     Continuing.
     [Thread 5864.0x1dc4 exited with code 0]
     [Switching to Thread 5864.0x15cc]

     Breakpoint 1, scm_i_close_signal_pipe () at scmsigs.c:662
     662       scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
     (gdb) bt
     #0  scm_i_close_signal_pipe () at scmsigs.c:662
     #1  0x00431ee9 in on_thread_exit (v=0xef0f00) at threads.c:777
     #2  0x62481f14 in ptw32_callUserDestroyRoutines ()
	from d:\usr\bin\pthreadGC2.dll
     #3  0x624855a1 in pthread_win32_thread_detach_np ()
	from d:\usr\bin\pthreadGC2.dll
     #4  0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll
     #5  0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthreadGC2.dll
     #6  0x77c69950 in ntdll!RtlQueryEnvironmentVariable ()
	from C:\Windows\SysWOW64\ntdll.dll
     #7  0x62480000 in ?? ()
     #8  0x77c7d6b2 in ntdll!LdrShutdownProcess ()
	from C:\Windows\SysWOW64\ntdll.dll
     #9  0x624810c0 in __dll_exit () from d:\usr\bin\pthreadGC2.dll
     #10 0x77c7d554 in ntdll!RtlExitUserProcess ()
	from C:\Windows\SysWOW64\ntdll.dll
     #11 0x75e97a0d in KERNEL32!ExitProcess ()
	from C:\Windows\syswow64\kernel32.dll
     #12 0x00000000 in ?? ()
     (gdb) info threads
       Id   Target Id         Frame
     * 1    Thread 5864.0x15cc scm_i_close_signal_pipe () at scmsigs.c:662

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> 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 we are
> talking about a child guile process -- it's that one that prints the
> weird traceback and hangs.  The parent just waits for the child to
> finish.

Where’s the child process created exactly?  It’s not clear to me.

Anyway, it could be that the parent Guile process has more than one
thread, and the child Guile process (which has only one thread) ends up
with some mutexes locked, and possibly inconsistent state.

Normally a Guile with multiple threads warns upon ‘fork’, precisely
because of this problem (see ‘scm_fork’ in posix.c.)

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_thread_mutex’ is locked.

We would need to check if we are in such a scenario.  Could you try a
small test case, something simple to start with:

  (use-modules (ice-9 match))
  (match (primitive-fork)
    (0 (gc) (primitive-exit 0))
    (child
      (waitpid child)
      (exit 0)))

TIA,
Ludo’.

Re: guile 2.0.9 build on mingw

[Andy Wingo]

On Sun 09 Jun 2013 22:33, ludo@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_thread_mutex’ is locked.

In theory the signal thread is counted among the threads -- iirc anyway.
The signal-handling thread is kicked off at the first call to sigaction,
which shouldn't happen there, right?  Also there should be no GC threads
active at that point.

Andy
-- 
http://wingolog.org/

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> On Sun 09 Jun 2013 22:33, ludo@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_thread_mutex’ is locked.
>
> In theory the signal thread is counted among the threads -- iirc anyway.

Apparently no, because ‘scm_fork’ uses ‘scm_all_threads’, which
explicitly “hides” the signal thread.

> The signal-handling thread is kicked off at the first call to sigaction,
> which shouldn't happen there, right?

Hmm, right, though it can also be spawned from ‘on_thread_exit’.

A better test would be:

  (use-modules (ice-9 match))
  (sigaction SIGINT)
  (match (primitive-fork)
    (0 (gc) (primitive-exit 0))
    (child
      (waitpid child)
      (exit 0)))

> Also there should be no GC threads active at that point.

Even with the 7.3ish marker thread thing?  At any rate, that’s something
that’s not really under Guile’s control.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii <eliz@gnu.org>,  guile-user@gnu.org
> Date: Sun, 09 Jun 2013 23:35:54 +0200
> 
> Andy Wingo <wingo@pobox.com> skribis:
> 
> > On Sun 09 Jun 2013 22:33, ludo@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_thread_mutex’ is locked.
> >
> > In theory the signal thread is counted among the threads -- iirc anyway.
> 
> Apparently no, because ‘scm_fork’ uses ‘scm_all_threads’, which
> explicitly “hides” the signal thread.
> 
> > The signal-handling thread is kicked off at the first call to sigaction,
> > which shouldn't happen there, right?
> 
> Hmm, right, though it can also be spawned from ‘on_thread_exit’.
> 
> A better test would be:
> 
>   (use-modules (ice-9 match))
>   (sigaction SIGINT)
>   (match (primitive-fork)
>     (0 (gc) (primitive-exit 0))
>     (child
>       (waitpid child)
>       (exit 0)))

Are you sure the above is relevant to Windows?  You are aware that
there's no 'fork' system call on Windows, and no real signals (except
SIGINT and SIGSEGV)?  Or does Guile emulate 'fork' somehow?

Anyway, I tried what you asked.  I've put the above into a test.scm
script and invoked Guile thusly, from the libguile directory of the
source tree:

  $ GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guild test1

Is this the right way of running the above script?

Anyway, Guile gets stuck.  Attaching GDB shows the info below, I hope
it will help you see what is going on.  (Thread #3 is the thread
started by Windows for attaching the debugger, so disregard it.)

If nothing rings the bell, I guess I will try building Guile without
threads, maybe I will have better luck that way.

     (gdb) info threads
       Id   Target Id         Frame
     * 3    Thread 15068.0x32f4 0x77c4000d in ntdll!DbgBreakPoint ()
	from C:\Windows\SysWOW64\ntdll.dll
       2    Thread 15068.0x32e0 0x77c4f8b1 in ntdll!ZwWaitForSingleObject ()
	from C:\Windows\SysWOW64\ntdll.dll
       1    Thread 15068.0x3e90 0x77c5013d in ntdll!ZwWaitForMultipleObjects ()
	from C:\Windows\SysWOW64\ntdll.dll
     (gdb) thread apply all bt

     Thread 3 (Thread 15068.0x32f4):
     #0  0x77c4000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
     #1  0x77ccf896 in ntdll!DbgUiRemoteBreakin ()
	from C:\Windows\SysWOW64\ntdll.dll
     #2  0x3a26c959 in ?? ()
     #3  0x00000000 in ?? ()

     Thread 2 (Thread 15068.0x32e0):
     #0  0x77c4f8b1 in ntdll!ZwWaitForSingleObject ()
	from C:\Windows\SysWOW64\ntdll.dll
     #1  0x77c4f8b1 in ntdll!ZwWaitForSingleObject ()
	from C:\Windows\SysWOW64\ntdll.dll
     #2  0x7744149d in WaitForSingleObjectEx ()
	from C:\Windows\syswow64\KernelBase.dll
     #3  0x0000016c in ?? ()
     #4  0x00000000 in ?? ()

     Thread 1 (Thread 15068.0x3e90):
     #0  0x77c5013d in ntdll!ZwWaitForMultipleObjects ()
	from C:\Windows\SysWOW64\ntdll.dll
     #1  0x77c5013d in ntdll!ZwWaitForMultipleObjects ()
	from C:\Windows\SysWOW64\ntdll.dll
     #2  0x774415e9 in WaitForMultipleObjectsEx ()
	from C:\Windows\syswow64\KernelBase.dll
     #3  0x00000002 in ?? ()
     #4  0x0028ef38 in ?? ()
     #5  0x75e91a2c in WaitForMultipleObjectsEx ()
	from C:\Windows\syswow64\kernel32.dll
     #6  0x75e94220 in WaitForMultipleObjects ()
	from C:\Windows\syswow64\kernel32.dll
     #7  0x6248b9ec in pthreadCancelableTimedWait () from d:\usr\bin\pthreadGC2.dll
     #8  0x6248c6b6 in sem_timedwait () from d:\usr\bin\pthreadGC2.dll
     #9  0x6248cf8b in pthread_cond_wait () from d:\usr\bin\pthreadGC2.dll
     #10 0x00432ecb in scm_pthread_cond_wait (cond=cond@entry=0x28f1ac,
	 mutex=mutex@entry=0x28f1a8) at threads.c:1990
     #11 0x00432f7c in scm_spawn_thread (
	 body=body@entry=0x436340 <signal_delivery_thread>,
	 body_data=body_data@entry=0x0, handler=0x431794 <scm_handle_by_message>,
	 handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1143
     #12 0x00436318 in start_signal_delivery_thread () at scmsigs.c:200
     #13 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
     #14 0x0043641c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
     #15 0x0043648f in scm_sigaction_for_thread (signum=0xa, handler=0x904,
	 flags=0x904, thread=0x23396d8) at scmsigs.c:330
     #16 0x00454b5a in vm_regular_engine (vm=0x2395c80, program=0x0,
	 argv=0x2400308, nargs=5121981) at vm-i-system.c:861
     #17 0x00414adc in scm_primitive_eval (exp=0x2d28188) at eval.c:685
     #18 0x00437b6f in scm_primitive_load (filename=filename@entry=0x2bad3d0)
	 at load.c:132
     #19 0x004386f8 in scm_primitive_load_path (args=0x2d07b10) at load.c:1050
     #20 0x00454b99 in vm_regular_engine (vm=0x2395c80, program=0x0,
	 argv=0x24002d8, nargs=5120951) at vm-i-system.c:852
     #21 0x00414adc in scm_primitive_eval (exp=exp@entry=0x2e056c0) at eval.c:685
     #22 0x00414b2f in scm_eval (exp=0x2e056c0,
	 module_or_state=module_or_state@entry=0x2d866c0) at eval.c:719
     #23 0x004129fd in scm_shell (argc=argc@entry=6, argv=argv@entry=0xa30f78)
	 at script.c:441
     #24 0x0040146f in inner_main (closure=0x0, argc=6, argv=0xa30f78)
	 at guile.c:62
     #25 0x00412aec in invoke_main_func (body_data=0x28fee0) at init.c:337
     #26 0x0045f8ac in c_body (d=0x28fe14) at continuations.c:511
     #27 0x00454b8b in vm_regular_engine (vm=0x2395c80, program=0x0,
	 argv=0x240007c, nargs=5121210) at vm-i-system.c:855
     #28 0x004145f8 in scm_call_4 (proc=0x22f6b28, arg1=arg1@entry=0x404,
	 arg2=arg2@entry=0x2c11d50, arg3=arg3@entry=0x2c11d20,
	 arg4=arg4@entry=0x2c11ce0) at eval.c:507
     #29 0x004312a2 in scm_catch_with_pre_unwind_handler (key=0x404,
	 thunk=0x2c11d50, handler=0x2c11d20, pre_unwind_handler=0x2c11ce0)
	 at throw.c:86
     #30 0x0043143e in scm_c_catch (tag=tag@entry=0x404, body=0x2c11d50,
	 body@entry=0x45f89c <c_body>, body_data=0x2c11d20,
	 body_data@entry=0x28fe14, handler=0x2c11ce0,
	 handler@entry=0x45fb50 <c_handler>,
	 handler_data=handler_data@entry=0x28fe14,
	 pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0x2395c40)
	 at throw.c:213
     #31 0x0045ff3b in scm_i_with_continuation_barrier (
	 body=body@entry=0x45f89c <c_body>, body_data=body_data@entry=0x28fe14,
	 handler=handler@entry=0x45fb50 <c_handler>,
	 handler_data=handler_data@entry=0x28fe14,
	 pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=0x2395c40) at continuations.c:449
     #32 0x0045ffcc in scm_c_with_continuation_barrier (
	 func=0x412abc <invoke_main_func>, data=0x28fee0) at continuations.c:545
     #33 0x004326a5 in with_guile_and_parent (base=0x28fe8c, data=0x28feb4)
	 at threads.c:908
     #34 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
     #35 0x004328e0 in scm_i_with_guile_and_parent (parent=<optimized out>,
	 data=0x28fee0, data@entry=0x28feb0,
	 func=func@entry=0x412abc <invoke_main_func>) at threads.c:951
     #36 scm_with_guile (func=func@entry=0x412abc <invoke_main_func>,
	 data=data@entry=0x28fee0) at threads.c:957
     #37 0x00412bf7 in scm_boot_guile (argc=argc@entry=6,
	 argv=argv@entry=0xa30f78,
	 main_func=main_func@entry=0x4013d4 <inner_main>,
	 closure=closure@entry=0x0) at init.c:320
     #38 0x004c631f in main (argc=6, argv=0xa30f78) at guile.c:108
     (gdb)

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  guile-user@gnu.org
> Date: Sun, 09 Jun 2013 23:16:18 +0200
> 
> On Sun 09 Jun 2013 22:33, ludo@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_thread_mutex’ is locked.
> 
> In theory the signal thread is counted among the threads -- iirc anyway.
> The signal-handling thread is kicked off at the first call to sigaction,
> which shouldn't happen there, right?

Windows doesn't have sigaction.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: guile-user@gnu.org
> Date: Sun, 09 Jun 2013 22:33:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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 we are
> > talking about a child guile process -- it's that one that prints the
> > weird traceback and hangs.  The parent just waits for the child to
> > finish.
> 
> Where’s the child process created exactly?  It’s not clear to me.

Sorry, this was a red herring.  The parent process is the guile.exe
from libguile, which is just a wrapper around the real guile.exe,
which is hidden in its .libs subdirectory.  So the parent is not
important; only the child is.

> Anyway, it could be that the parent Guile process has more than one
> thread, and the child Guile process (which has only one thread) ends up
> with some mutexes locked, and possibly inconsistent state.

See above: the parent is not really Guile, it's just called guile.exe
to dupe all kinds of scripts (and me ;-).

> Normally a Guile with multiple threads warns upon ‘fork’, precisely
> because of this problem (see ‘scm_fork’ in posix.c.)

As I wrote earlier, there's no 'fork' in MinGW, so I'm not sure this
is at all relevant.  Or maybe it is -- perhaps the threads
infrastructure in Guile really assumes Posix functionality that just
isn't there in the MinGW build?

> 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_thread_mutex’ is locked.

What signal would that be?  Are you sure it exists, or is emulated, on
Windows?

Thanks.

Re: guile 2.0.9 build on mingw

[Mark H Weaver]

Hi Eli,

I've spoken with a couple of other people have successfully built Guile
2.0.9 on mingw.  See <http://bugs.gnu.org/14171> for example.

Are you configuring Guile with --disable-posix?

      Mark

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: ludo@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 <http://bugs.gnu.org/14171> for example.

Maybe I misread, but that bug sounds like the build was UN-successful.

> Are you configuring Guile with --disable-posix?

No.  Should I?

Re: guile 2.0.9 build on mingw

[Mark H Weaver]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark H Weaver <mhw@netris.org>
>> Cc: ludo@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 <http://bugs.gnu.org/14171> for example.
>
> Maybe I misread, but that bug sounds like the build was UN-successful.

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.

>> Are you configuring Guile with --disable-posix?
>
> No.  Should I?

Yes.  Ideally our configure script would --disable-posix by default on
mingw, but for now it has to be specified manually.

    Thanks!
      Mark

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: ludo@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.
> 
> >> Are you configuring Guile with --disable-posix?
> >
> > No.  Should I?
> 
> Yes.  Ideally our configure script would --disable-posix by default on
> mingw, but for now it has to be specified manually.

Thanks.  I tried that, but it didn't help.  I see the same problems as
without --disable-posix.

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 "almost" later.)

I will try to compare the two builds and find what breaks the one with
threads.  Since my knowledge about pthreads in general and on Windows
in particular is strictly zero, I'm not sure I'll know where to look.
So perhaps the following observation will help someone here to come up
with ideas or hints about where to look: Guile gets stuck when it is
about to exit.  That is, it processes its input completely (e.g.,
compiles the .scm file), writes out the corresponding output (e.g.,
the .go file), announces that the output was written, and then gets
stuck.  So this suggests something related to some bookkeeping done at
exit; any ideas what that could be?

If no ideas are brought up, I guess the conclusion is that Guile on
Windows cannot be built with pthreads, at least not with their binary
package distributed by mingw.org, which is what I used.

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 since most of
the functions disabled by --disable-posix already have HAVE_foo guards
around them, so systems that don't have them will not have the
corresponding Guile feature.  I will try to lift as much of the
disabled functionality as MinGW can bear.

Another set of disabled features is the network related functions --
for some reason, the build process insists on h_errno being available,
although h_errno is an obsolete facility that AFAIK no one is treating
seriously anymore.  Why not use errno instead?

Thanks.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: Mark H Weaver <mhw@netris.org>
>> Cc: ludo@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.
>> 
>> >> Are you configuring Guile with --disable-posix?
>> >
>> > No.  Should I?
>> 
>> Yes.  Ideally our configure script would --disable-posix by default on
>> mingw, but for now it has to be specified manually.
>
> Thanks.  I tried that, but it didn't help.  I see the same problems as
> without --disable-posix.
>
> 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 "almost" later.)
>
> I will try to compare the two builds and find what breaks the one with
> threads.  Since my knowledge about pthreads in general and on Windows
> in particular is strictly zero, I'm not sure I'll know where to look.
> So perhaps the following observation will help someone here to come up
> with ideas or hints about where to look: Guile gets stuck when it is
> about to exit.  That is, it processes its input completely (e.g.,
> compiles the .scm file), writes out the corresponding output (e.g.,
> the .go file), announces that the output was written, and then gets
> stuck.  So this suggests something related to some bookkeeping done at
> exit; any ideas what that could be?

The backtrace you reported before suggests that it’s stuck waiting for a
signal delivery thread mutex, right?  I have no idea how this would
happen, though.

> If no ideas are brought up, I guess the conclusion is that Guile on
> Windows cannot be built with pthreads, at least not with their binary
> package distributed by mingw.org, which is what I used.

[...]

FWIW, Guile cross-builds fine to MinGW with pthread-w32 and pthread
support, but that runs none of the C code since it uses the native Guile
to compile the .scm files.

> Another set of disabled features is the network related functions --
> for some reason, the build process insists on h_errno being available,
> although h_errno is an obsolete facility that AFAIK no one is treating
> seriously anymore.  Why not use errno instead?

I don’t know.  It’s used only in net_db.c, and only if ‘h_errno’ is
available.

Is there any harm in using it when it’s available?

Could it be that older-but-not-too-old MinGW versions required use of
‘h_errno’?

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: Mark H Weaver <mhw@netris.org>,  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 report the details about "almost" later.)
> >
> > I will try to compare the two builds and find what breaks the one with
> > threads.  Since my knowledge about pthreads in general and on Windows
> > in particular is strictly zero, I'm not sure I'll know where to look.
> > So perhaps the following observation will help someone here to come up
> > with ideas or hints about where to look: Guile gets stuck when it is
> > about to exit.  That is, it processes its input completely (e.g.,
> > compiles the .scm file), writes out the corresponding output (e.g.,
> > the .go file), announces that the output was written, and then gets
> > stuck.  So this suggests something related to some bookkeeping done at
> > exit; any ideas what that could be?
> 
> The backtrace you reported before suggests that it’s stuck waiting for a
> signal delivery thread mutex, right?  I have no idea how this would
> happen, though.

I looked deeper into this.  What I saw surprised me, but maybe that's
because I know nothing about pthreads, nor how Guile uses them.  I
will describe my findings in the hope that someone here will know
more.  In a nutshell, I think the hang waiting for a mutex is a
symptom, not the problem; see below.

What I did was stop Guile at the entry to 'main', and then attach GDB
and set a breakpoint at scm_i_ensure_signal_delivery_thread, before
letting Guile proceed.  I expected that function to be called some
time during the startup, and I expected to see GDB announce a new
thread.  Surprisingly, none of that happened.  Instead, the function
is called when Guile is done (it was compiling a .scm file), and is
exiting!  See the backtrace below; you can clearly see that the
top-level call-stack frame is in ExitProcess, and the whole sequence
of calls leading to the attempt to create a signal delivery thread
starts in on_thread_exit.

What happens next is that the attempt to launch that thread fails
here:

     SCM
     scm_spawn_thread (scm_t_catch_body body, void *body_data,
		       scm_t_catch_handler handler, void *handler_data)
     {
       spawn_data data;
       scm_i_pthread_t id;
       int err;

       data.parent = scm_current_dynamic_state ();
       data.body = body;
       data.body_data = body_data;
       data.handler = handler;
       data.handler_data = handler_data;
       data.thread = SCM_BOOL_F;
       scm_i_pthread_mutex_init (&data.mutex, NULL);
       scm_i_pthread_cond_init (&data.cond, NULL);

       scm_i_scm_pthread_mutex_lock (&data.mutex);
       err = scm_i_pthread_create (&id, NULL, spawn_thread, &data); <<<<<<<
       if (err)
	 {
	   scm_i_pthread_mutex_unlock (&data.mutex);
	   errno = err;
	   scm_syserror (NULL);
	 }

scm_i_pthread_create returns err = 11 (EAGAIN), and then Guile calls
scm_syserror.  I believe that call outputs the Scheme backtrace, and
then Guile hangs as I described.

The call to start the signal delivery thread comes from here:

     /* Perform thread tear-down, in guile mode.
      */
     static void *
     do_thread_exit (void *v)
     {
       scm_i_thread *t = (scm_i_thread *) v;

       /* Ensure the signal handling thread has been launched, because we might be
	  shutting it down.  This needs to be done in Guile mode.  */
       scm_i_ensure_signal_delivery_thread ();  <<<<<<<<<<<<<<<<<<<<<

Why isn't the signal delivery thread launched at program start, and
why is it launched at exit?

Also, is it possible for you or someone else to describe how the
signal delivery stuff is supposed to work, especially since there are
some MinGW related comments in scmsigs.c that mention signals between
processes (how's that related? Guile is a single process, right?)?
I'd like to understand a bit more what is going on here.

> > Another set of disabled features is the network related functions --
> > for some reason, the build process insists on h_errno being available,
> > although h_errno is an obsolete facility that AFAIK no one is treating
> > seriously anymore.  Why not use errno instead?
> 
> I don’t know.  It’s used only in net_db.c, and only if ‘h_errno’ is
> available.
> 
> Is there any harm in using it when it’s available?

No, of course not.  The harm is to disable all network features when
h_errno is _not_ available.

> Could it be that older-but-not-too-old MinGW versions required use of
> ‘h_errno’?

I sincerely doubt that.  Windows doesn't have h_errno, and AFAIK never
had.

Here's the backtrace when scm_spawn_thread is called during exit:

     Breakpoint 1, scm_spawn_thread (
	 body=body@entry=0x436350 <signal_delivery_thread>,
	 body_data=body_data@entry=0x0, handler=0x4317a4 <scm_handle_by_message>,
	 handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1119
     1119    {
     (gdb) bt
     #0  scm_spawn_thread (body=body@entry=0x436350 <signal_delivery_thread>,
	 body_data=body_data@entry=0x0, handler=0x4317a4 <scm_handle_by_message>,
	 handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1119
     #1  0x00436328 in start_signal_delivery_thread () at scmsigs.c:200
     #2  0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
     #3  0x0043642c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
     #4  0x00432c10 in do_thread_exit (v=0x9b0f00) at threads.c:671
     #5  0x0045f8bc in c_body (d=0x28f6a0) at continuations.c:511
     #6  0x00454b9b in vm_regular_engine (vm=0xb95c80, program=0x0,
	 argv=0x23f00a4, nargs=5121210) at vm-i-system.c:855
     #7  0x00414608 in scm_call_4 (proc=0x926b28, arg1=arg1@entry=0x404,
	 arg2=arg2@entry=0x5408d80, arg3=arg3@entry=0x5408d70,
	 arg4=arg4@entry=0x5408d60) at eval.c:507
     #8  0x004312b2 in scm_catch_with_pre_unwind_handler (key=0x404,
	 thunk=0x5408d80, handler=0x5408d70, pre_unwind_handler=0x5408d60)
	 at throw.c:86
     #9  0x0043144e in scm_c_catch (tag=tag@entry=0x404, body=0x5408d80,
	 body@entry=0x45f8ac <c_body>, body_data=0x5408d70,
	 body_data@entry=0x28f6a0, handler=0x5408d60,
	 handler@entry=0x45fb60 <c_handler>,
	 handler_data=handler_data@entry=0x28f6a0,
	 pre_unwind_handler=pre_unwind_handler@entry=0x45f9cc <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0xb95c40) at throw.c:213
     #10 0x0045ff4b in scm_i_with_continuation_barrier (
	 body=body@entry=0x45f8ac <c_body>, body_data=body_data@entry=0x28f6a0,
	 handler=handler@entry=0x45fb60 <c_handler>,
	 handler_data=handler_data@entry=0x28f6a0,
	 pre_unwind_handler=pre_unwind_handler@entry=0x45f9cc <pre_unwind_handler>, pre_unwind_handler_data=0xb95c40) at continuations.c:449
     #11 0x0045ffdc in scm_c_with_continuation_barrier (
	 func=0x432c00 <do_thread_exit>, data=0x9b0f00) at continuations.c:545
     #12 0x00431e04 in with_guile_trampoline (data=0x28f790) at threads.c:890
     #13 0x709cffa0 in ?? () from d:\usr\bin\libgc-1.dll
     #14 0x004326ec in with_gc_active (data=0x28f790,
	 func=0x431dec <with_guile_trampoline>) at threads.c:238
     #15 with_guile_and_parent (base=0x28f768, data=0x28f790) at threads.c:936
     #16 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
     #17 0x004328f0 in scm_i_with_guile_and_parent (parent=<optimized out>,
	 data=0x9b0f00, func=0x432c00 <do_thread_exit>) at threads.c:951
     #18 scm_with_guile (func=0x432c00 <do_thread_exit>, data=0x9b0f00)
	 at threads.c:957
     #19 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
     #20 0x00431e76 in on_thread_exit (v=0x9b0f00) at threads.c:754
     #21 0x62481f14 in ptw32_callUserDestroyRoutines ()
	from d:\usr\bin\pthreadGC2.dll
     #22 0x624855a1 in pthread_win32_thread_detach_np ()
	from d:\usr\bin\pthreadGC2.dll
     #23 0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll
     #24 0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthreadGC2.dll
     #25 0x77c69950 in ntdll!RtlQueryEnvironmentVariable ()
	from C:\Windows\SysWOW64\ntdll.dll
     #26 0x62480000 in ?? ()
     #27 0x77c7d6b2 in ntdll!LdrShutdownProcess ()
	from C:\Windows\SysWOW64\ntdll.dll
     #28 0x624810c0 in __dll_exit () from d:\usr\bin\pthreadGC2.dll
     #29 0x77c7d554 in ntdll!RtlExitUserProcess ()
	from C:\Windows\SysWOW64\ntdll.dll
     #30 0x75e97a0d in KERNEL32!ExitProcess ()
	from C:\Windows\syswow64\kernel32.dll

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Tue, 11 Jun 2013 19:53:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ludo@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 "almost" later.)

Here's part 1 of those details.

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.000000000 +0200
+++ test-suite/standalone/test-system-cmds	2013-06-12 13:52:14.333269200 +0300
@@ -10,7 +10,7 @@
          "test-system-cmds: (system) did not return a boolean\n")
         (exit 1)))
   
-  (let ((rs (status:exit-val (system "guile -c '(exit 42)'"))))
+  (let ((rs (status:exit-val (system "guile -c \"(exit 42)\""))))
     (if (not (= 42 rs))
         (begin
           (simple-format
@@ -39,4 +39,4 @@
 
 ;; Local Variables:
 ;; mode: scheme
-;; End:
\ No newline at end of file
+;; End:

Next, test-unwind failed because it assumed that either $TMPDIR or
'/tmp' will exist, none of which can be counted upon on Windows.
Here's the fix for that (the declaration of mkstemp avoids compiler
warning):

--- test-suite/standalone/test-unwind.c~0	2012-01-31 00:32:38.000000000 +0200
+++ test-suite/standalone/test-unwind.c	2013-06-12 14:11:47.967231800 +0300
@@ -200,9 +200,19 @@ check_ports ()
 #define FILENAME_TEMPLATE "/check-ports.XXXXXX"
   char *filename;
   const char *tmpdir = getenv ("TMPDIR");
+#ifdef __MINGW32__
+  extern int mkstemp (char *);
 
   if (tmpdir == NULL)
+    tmpdir = getenv ("TEMP");
+  if (tmpdir == NULL)
+    tmpdir = getenv ("TMP");
+  if (tmpdir == NULL)
+    tmpdir = "/";
+#else
+  if (tmpdir == NULL)
     tmpdir = "/tmp";
+#endif
 
   filename = alloca (strlen (tmpdir) + sizeof (FILENAME_TEMPLATE) + 1);
   strcpy (filename, tmpdir);


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.  Moreover,
whenever a test fails, the run stops without running the rest of the
test.  Is there a way to skip tests that are known to fail?  I see
that renaming the corresponding test files to not have the .test
extension would probably do the trick, but is there a better way?  For
that matter, is there a way of forcing the test run to continue even
if some test failed?  (I would actually suggest to skip tests
automatically based on unsupported features.)

Thanks.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Tue, 11 Jun 2013 19:53:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ludo@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 "almost" later.)

The second part of the details is about "make install": it failed
because it looked for guild.exe and guile_tools.exe, which don't
exist, because guild and guile_tools are shell scripts, not .exe
programs.  Fixed thusly:

--- meta/Makefile.am~0	2013-03-25 23:24:24.000000000 +0200
+++ meta/Makefile.am	2013-06-12 14:26:47.032031800 +0300
@@ -30,9 +30,9 @@
 # What we now call `guild' used to be known as `guile-tools'.
 install-exec-hook:
 	guild="`echo $(ECHO_N) guild				\
-	   | $(SED) -e '$(program_transform_name)'`$(EXEEXT)" ;	\
+	   | $(SED) -e '$(program_transform_name)'`" ;	\
 	guile_tools="`echo $(ECHO_N) guile-tools		\
-	   | $(SED) -e '$(program_transform_name)'`$(EXEEXT)" ;	\
+	   | $(SED) -e '$(program_transform_name)'`" ;	\
 	cd $(DESTDIR)$(bindir) && rm -f "$$guile_tools" &&	\
 	$(LN_S) "$$guild" "$$guile_tools"
 

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Tue, 11 Jun 2013 19:53:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ludo@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 since most of
> the functions disabled by --disable-posix already have HAVE_foo guards
> around them, so systems that don't have them will not have the
> corresponding Guile feature.  I will try to lift as much of the
> disabled functionality as MinGW can bear.

Please find the changes to do this below.  I removed most of the
HAVE_POSIX ifdef's, as they are no longer needed.

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?  I'd like to see if my
build, which didn't use --disable-posix, has any problems in that
area, and if so try to debug them.


--- libguile/filesys.c~0	2013-04-09 09:52:31.000000000 +0300
+++ libguile/filesys.c	2013-06-12 13:41:31.244477700 +0300
@@ -112,7 +112,12 @@
 
 /* Some more definitions for the native Windows port. */
 #ifdef __MINGW32__
-# define fsync(fd) _commit (fd)
+# define fsync(fd)    _commit (fd)
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+/* FIXME: Should use 'link' module from gnulib.  */
+# define link(f1,f2)  CreateHardLink(f2, f1, NULL)
+# define HAVE_LINK 1
 #endif /* __MINGW32__ */
 
 
@@ -143,8 +148,6 @@
 
 \f
 
-#ifdef HAVE_POSIX
-
 /* {Permissions}
  */
 
@@ -320,8 +323,6 @@ SCM_DEFINE (scm_close_fdes, "close-fdes"
 }
 #undef FUNC_NAME
 
-#endif /* HAVE_POSIX */
-
 \f
 /* {Files}
  */
@@ -587,7 +588,6 @@ SCM_DEFINE (scm_lstat, "lstat", 1, 0, 0,
 #endif /* HAVE_LSTAT */
 
 \f
-#ifdef HAVE_POSIX
 
 /* {Modifying Directories}
  */
@@ -1219,8 +1219,6 @@ SCM_DEFINE (scm_sendfile, "sendfile", 3,
 }
 #undef FUNC_NAME
 
-#endif /* HAVE_POSIX */
-
 \f
 /* Essential procedures used in (system base compile).  */
 
@@ -1845,7 +1843,6 @@ SCM_DEFINE (scm_closedir, "closedir", 1,
 #undef FUNC_NAME
 
 
-#ifdef HAVE_POSIX
 static int
 scm_dir_print (SCM exp, SCM port, scm_print_state *pstate SCM_UNUSED)
 {
@@ -1866,14 +1863,12 @@ scm_dir_free (SCM p)
     closedir ((DIR *) SCM_SMOB_DATA_1 (p));
   return 0;
 }
-#endif
 
 \f
 
 void
 scm_init_filesys ()
 {
-#ifdef HAVE_POSIX
   scm_tc16_dir = scm_make_smob_type ("directory", 0);
   scm_set_smob_free (scm_tc16_dir, scm_dir_free);
   scm_set_smob_print (scm_tc16_dir, scm_dir_print);
@@ -1942,7 +1937,6 @@ scm_init_filesys ()
 #ifdef FD_CLOEXEC  
   scm_c_define ("FD_CLOEXEC", scm_from_int (FD_CLOEXEC));
 #endif
-#endif /* HAVE_POSIX */
 
   /* `access' symbols.  */
   scm_c_define ("R_OK", scm_from_int (R_OK));
--- libguile/posix.c~0	2013-03-29 21:20:01.000000000 +0300
+++ libguile/posix.c	2013-06-12 13:03:12.379677700 +0300
@@ -85,6 +85,27 @@
 #if HAVE_SYS_WAIT_H
 # include <sys/wait.h>
 #endif
+#ifdef __MINGW32__
+# define WEXITSTATUS(stat_val) ((stat_val) & 255)
+/* Windows reports exit status from fatal exceptions as 0xC0000nnn
+   codes, see winbase.h.  We usurp codes above 0xC0000200 for SIGxxx
+   signals.  */
+# define WIFEXITED(stat_val)   (((stat_val) & 0xC0000000) == 0)
+# define WIFSIGNALED(stat_val) (((stat_val) & 0xC0000000) != 0)
+# define WTERMSIG(stat_val)    ((stat_val > 0xC0000200) ? stat_val - 0xC0000200 : stat_val)
+# define WIFSTOPPED(stat_val)  (0)
+# define WSTOPSIG(stat_var)    (0)
+# include <process.h>
+# define waitpid(p,s,o)        _cwait(s, p, WAIT_CHILD)
+# define HAVE_WAITPID 1
+# define getuid()              (500) /* Local Administrator */
+# define getgid()              (513) /* None */
+# define setuid(u)             (0)
+# define setgid(g)             (0)
+# define pipe(f)               _pipe(f, 0, O_NOINHERIT)
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+#endif
 #ifndef WEXITSTATUS
 # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
 #endif
@@ -674,6 +695,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, 0xC0000200 + s))
+	{
+	  errno = EINVAL;
+	  goto err;
+	}
+      CloseHandle (ph);
+    }
+#endif	/* __MINGW32__ */
 #endif
   return SCM_UNSPECIFIED;
 }
@@ -720,6 +760,7 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1
 {
   int i;
   int status;
+#ifndef __MINGW32__
   int ioptions;
   if (SCM_UNBNDP (options))
     ioptions = 0;
@@ -728,6 +769,7 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1
       /* Flags are interned in scm_init_posix.  */
       ioptions = scm_to_int (options);
     }
+#endif
   SCM_SYSCALL (i = waitpid (scm_to_int (pid), &status, ioptions));
   if (i == -1)
     SCM_SYSERROR;
@@ -736,7 +778,6 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1
 #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"
@@ -787,7 +828,6 @@ SCM_DEFINE (scm_status_stop_sig, "status
     return SCM_BOOL_F;
 }
 #undef FUNC_NAME
-#endif /* __MINGW32__ */
 
 #ifdef HAVE_GETPPID
 SCM_DEFINE (scm_getppid, "getppid", 0, 0, 0,
@@ -802,7 +842,6 @@ SCM_DEFINE (scm_getppid, "getppid", 0, 0
 #endif /* HAVE_GETPPID */
 
 
-#ifndef __MINGW32__
 SCM_DEFINE (scm_getuid, "getuid", 0, 0, 0,
             (),
 	    "Return an integer representing the current real user ID.")
@@ -906,10 +945,8 @@ SCM_DEFINE (scm_seteuid, "seteuid", 1, 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"
@@ -921,7 +958,7 @@ SCM_DEFINE (scm_setegid, "setegid", 1, 0
 {
   int rv;
 
-#ifdef HAVE_SETEUID
+#ifdef HAVE_SETEGID
   rv = setegid (scm_to_int (id));
 #else
   rv = setgid (scm_to_int (id));
@@ -932,7 +969,6 @@ SCM_DEFINE (scm_setegid, "setegid", 1, 0
     
 }
 #undef FUNC_NAME
-#endif
 
 
 #ifdef HAVE_GETPGRP
@@ -1247,6 +1283,7 @@ SCM_DEFINE (scm_fork, "primitive-fork", 
   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
@@ -1320,7 +1357,130 @@ scm_open_process (SCM mode, SCM prog, SC
   }
 #endif
 
+#ifdef HAVE_FORK
   pid = fork ();
+#elif defined(__MINGW32__)
+  {
+    int save_stdin = -1, save_stdout = -1;
+    int errno_save;
+
+    if (reading)
+      {
+	save_stdout = dup (1);
+	errno_save = errno;
+	if (save_stdout == -1)
+	  {
+	    close (c2p[0]);
+	    close (c2p[1]);
+	    free (exec_file);
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+      }
+
+    if (writing)
+      {
+	save_stdin = dup (0);
+	errno_save = errno;
+	if (save_stdin == -1)
+	  {
+	    if (reading)
+	      close (save_stdout);
+	    close (p2c[0]);
+	    close (p2c[1]);
+	    free (exec_file);
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+      }
+
+    if (reading)
+      {
+	close (1);
+	if (dup (c2p[1]) != 1)
+	  {
+	    errno_save = errno;
+	    close (save_stdout);
+	    close (c2p[0]);
+	    close (c2p[1]);
+	    if (writing)
+	      {
+		close (save_stdin);
+		close (p2c[0]);
+		close (p2c[1]);
+	      }
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+	close (c2p[1]);
+      }
+    if (writing)
+      {
+	close (0);
+	if (dup (p2c[0]) != 0)
+	  {
+	    errno_save = errno;
+	    close (save_stdin);
+	    close (p2c[0]);
+	    close (p2c[1]);
+	    if (reading)
+	      {
+		close (save_stdout);
+		close (c2p[0]);
+		close (c2p[1]);
+	      }
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+	close (p2c[0]);
+      }
+
+    pid = spawnvp (P_NOWAIT, exec_file, exec_argv);
+    errno_save = errno;
+
+    if (reading)
+      {
+	close (1);
+	if (dup (save_stdout) != 1)
+	  {
+	    if (writing)
+	      close (save_stdin);
+	    close (save_stdout);
+	    close (p2c[1]);
+	    close (c2p[0]);
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+	close (save_stdout);
+      }
+    if (writing)
+      {
+	close (0);
+	if (dup (save_stdin) != 0)
+	  {
+	    if (reading)
+	      close (save_stdout);
+	    close (save_stdin);
+	    close (p2c[1]);
+	    close (c2p[0]);
+	    errno = errno_save;
+	    SCM_SYSERROR;
+	  }
+	close (save_stdin);
+      }
+
+    if (pid < 0)
+      errno = errno_save;
+  }
+#else
+  close (c2p[0]);
+  close (c2p[1]);
+  close (p2c[0]);
+  close (p2c[1]);
+  free (exec_file);
+  errno = ENOSYS;
+  SCM_SYSERROR;
+#endif	/* HAVE_FORK */
 
   if (pid == -1)
     {
@@ -1329,14 +1489,28 @@ scm_open_process (SCM mode, SCM prog, SC
       if (reading)
         {
           close (c2p[0]);
+#ifdef HAVE_FORK
           close (c2p[1]);
+#endif
         }
       if (writing)
         {
+#ifdef HAVE_FORK
           close (p2c[0]);
+#endif
           close (p2c[1]);
         }
       errno = errno_save;
+
+#ifndef HAVE_FORK
+      /* The exec failed!  There is nothing sensible to do.  */
+      if (err > 0)
+	{
+	  char *msg = strerror (errno);
+	  fprintf (fdopen (err, "a"), "In spawnvp of %s: %s\n",
+		   exec_file, msg);
+	}
+#endif
       SCM_SYSERROR;
     }
 
@@ -1362,7 +1536,8 @@ scm_open_process (SCM mode, SCM prog, SC
       return scm_values
         (scm_list_3 (read_port, write_port, scm_from_int (pid)));
     }
-  
+
+#ifdef HAVE_FORK
   /* The child.  */
   if (reading)
     close (c2p[0]);
@@ -1411,16 +1586,16 @@ scm_open_process (SCM mode, SCM prog, SC
   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);
   /* Not reached.  */
   return SCM_BOOL_F;
+#endif	/* HAVE_FORK */
 }
 #undef FUNC_NAME
-#endif /* HAVE_FORK */
 
 #ifdef __MINGW32__
 # include "win32-uname.h"
@@ -2238,13 +2413,11 @@ SCM_DEFINE (scm_gethostname, "gethostnam
 #endif /* HAVE_GETHOSTNAME */
 
 \f
-#ifdef HAVE_FORK
 static void
 scm_init_popen (void)
 {
   scm_c_define_gsubr ("open-process", 2, 0, 1, scm_open_process);
 }
-#endif
 
 void
 scm_init_posix ()
@@ -2337,11 +2510,11 @@ scm_init_posix ()
 
 #ifdef HAVE_FORK
   scm_add_feature ("fork");
+#endif	/* HAVE_FORK */
   scm_c_register_extension ("libguile-" SCM_EFFECTIVE_VERSION,
                             "scm_init_popen",
 			    (scm_t_extension_init_func) scm_init_popen,
 			    NULL);
-#endif	/* HAVE_FORK */
 }
 
 /*

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Wed, 12 Jun 2013 20:57:38 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 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 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.000000000 +0200
+++ libguile/socket.c	2013-06-13 06:58:36.917359500 +0300
@@ -1737,8 +1737,10 @@ scm_init_socket ()
   scm_c_define ("AF_UNSPEC", scm_from_int (AF_UNSPEC));
 #endif
 #ifdef AF_UNIX
+#ifdef HAVE_UNIX_DOMAIN_SOCKETS
   scm_c_define ("AF_UNIX", scm_from_int (AF_UNIX));
 #endif
+#endif
 #ifdef AF_INET
   scm_c_define ("AF_INET", scm_from_int (AF_INET));
 #endif

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

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/posix.c~1	2013-06-13 08:54:44.926293300 +0300
+++ libguile/posix.c	2013-06-13 08:57:44.262743700 +0300
@@ -1300,7 +1300,9 @@ scm_open_process (SCM mode, SCM prog, SC
   int pid;
   char *exec_file;
   char **exec_argv;
+#ifdef HAVE_FORK
   int max_fd = 1024;
+#endif
 
   exec_file = scm_to_locale_string (prog);
   exec_argv = scm_i_allocate_string_pointers (scm_cons (prog, args));
@@ -1435,6 +1437,14 @@ scm_open_process (SCM mode, SCM prog, SC
 	close (p2c[0]);
       }
 
+    if (c_strcasecmp (exec_file, "/bin/sh") == 0)
+      {
+	strcpy (exec_file, "cmd.exe");
+	strcpy (exec_argv[0], "cmd.exe");
+	if (strcmp (exec_argv[1], "-c") == 0)
+	  strcpy (exec_argv[1], "/c");
+      }
+
     pid = spawnvp (P_NOWAIT, exec_file, exec_argv);
     errno_save = errno;
 
@@ -1486,7 +1496,6 @@ scm_open_process (SCM mode, SCM prog, SC
     {
       int errno_save = errno;
 
-      free (exec_file);
       if (reading)
         {
           close (c2p[0]);
@@ -1512,6 +1521,7 @@ scm_open_process (SCM mode, SCM prog, SC
 		   exec_file, msg);
 	}
 #endif
+      free (exec_file);
       SCM_SYSERROR;
     }
 
@@ -1592,9 +1602,9 @@ scm_open_process (SCM mode, SCM prog, SC
     }
 
   _exit (EXIT_FAILURE);
+#endif	/* HAVE_FORK */
   /* Not reached.  */
   return SCM_BOOL_F;
-#endif	/* HAVE_FORK */
 }
 #undef FUNC_NAME

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.000000000 +0300
+++ libguile/Makefile.am	2013-06-13 13:34:27.545323200 +0300
@@ -113,7 +113,7 @@
 guile_SOURCES = guile.c
 guile_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
 guile_LDADD = libguile-@GUILE_EFFECTIVE_VERSION@.la
-guile_LDFLAGS = $(GUILE_CFLAGS)
+guile_LDFLAGS = $(GUILE_CFLAGS) -export-dynamic
 
 libguile_@GUILE_EFFECTIVE_VERSION@_la_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)

The following patch prevents test failure on systems that don't
support symlinks, and thus test-symlink file is not created and does
not exist there.
 
--- test-suite/tests/filesys.test~0	2013-04-09 09:52:31.000000000 +0300
+++ test-suite/tests/filesys.test	2013-06-13 07:49:51.567974100 +0300
@@ -222,4 +222,5 @@
           (throw 'unresolved)))))
 
 (delete-file (test-file))
-(delete-file (test-symlink))
+(if (file-exists? (test-symlink))
+    (delete-file (test-symlink)))


Thanks.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

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 #<catch-closure 43e6990> ...]
     In unknown file:
	?: 15 [apply-smob/1 #<catch-closure 43e6990>]
     In ice-9/boot-9.scm:
       63: 14 [call-with-prompt prompt0 ...]
     In ice-9/eval.scm:
      432: 13 [eval # #]
      432: 12 [eval # #]
     In ice-9/boot-9.scm:
      697: 11 [for-each #<procedure 4d06780 at ice-9/eval.scm:416:20 (a)> #]
     In ice-9/eval.scm:
      481: 10 [lp (#<fluid 23>) (("foreign.test"))]
     In ice-9/boot-9.scm:
     2320: 9 [save-module-excursion #<procedure 61d04a0 at ice-9/boot-9.scm:3961:3 ()>]
     3966: 8 [#<procedure 61d04a0 at ice-9/boot-9.scm:3961:3 ()>]
     1645: 7 [%start-stack load-stack ...]
     1650: 6 [#<procedure 5c73a20 ()>]
     In unknown file:
	?: 5 [primitive-load "d:/usr/eli/utils/guile-2.0.9/test-suite/tests\\foreign.test"]
     In ice-9/eval.scm:
      481: 4 [lp (#<fluid 23>) (("foreign.test" "procedure->pointer"))]
      432: 3 [eval # #]
      436: 2 [eval # #]
      387: 1 [eval # #]
     In unknown file:
	?: 0 [dynamic-func "qsort" #<dynamic-object #f>]

     ERROR: In procedure dynamic-func:
     ERROR: In procedure dynamic-pointer: Symbol not found: qsort

   This is because on Windows, 'qsort' is not in the program itself,
   it is dynamically loaded from a system shared library.  Maybe this
   test should be skipped on Windows.  (Btw, how does one condition
   OS-specific code in Guile?)

2. Failures in ports.test:

     Running ports.test
     FAIL: ports.test: file: binary mode ignores port encoding
     FAIL: ports.test: file: binary mode ignores file coding declaration

   Should I worry about this?

3. Emacs-lisp test display warnings about overriding Scheme procedures
   -- is that something to worry about?

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

The changes below work around the lack of h_error on Windows:

--- libguile/net_db.c~0	2013-03-25 23:44:46.000000000 +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_errno        WSAGetLastError()
+# define HAVE_H_ERRNO   1
+# define HAVE_HSTRERROR 1
+# ifdef HAVE_DECL_HSTRERROR
+#  undef HAVE_DECL_HSTRERROR
+# endif
+# define HAVE_DECL_HSTRERROR 1
+# define HOST_NOT_FOUND WSAHOST_NOT_FOUND
+# define TRY_AGAIN      WSATRY_AGAIN
+# define NO_RECOVERY    WSANO_RECOVERY
+# define NO_DATA        WSANO_DATA
+
+char *hstrerror (int);
+
+char *
+hstrerror (int error_no)
+{
+  static char buf[500];
+  DWORD ret;
+
+  if (error_no == 0)
+    error_no = WSAGetLastError ();
+
+  ret = FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM |
+                       FORMAT_MESSAGE_IGNORE_INSERTS,
+                       NULL,
+                       error_no,
+                       0, /* choose most suitable language */
+                       buf, sizeof (buf), NULL);
+
+  while (ret > 0 && (buf[ret - 1] == '\n' ||
+                     buf[ret - 1] == '\r' ))
+      --ret;
+  buf[ret] = '\0';
+  if (!ret)
+    sprintf (buf, "Winsock error %u", error_no);
+
+  return buf;
+}
+#endif	/* __MINGW32__ */
 
 #if defined (HAVE_H_ERRNO)
 /* Only wrap gethostbyname / gethostbyaddr if h_errno is available.  */

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> 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.000000000 +0200
> +++ libguile/socket.c	2013-06-13 06:58:36.917359500 +0300
> @@ -1737,8 +1737,10 @@ scm_init_socket ()
>    scm_c_define ("AF_UNSPEC", scm_from_int (AF_UNSPEC));
>  #endif
>  #ifdef AF_UNIX
> +#ifdef HAVE_UNIX_DOMAIN_SOCKETS
>    scm_c_define ("AF_UNIX", scm_from_int (AF_UNIX));
>  #endif
> +#endif
>  #ifdef AF_INET
>    scm_c_define ("AF_INET", scm_from_int (AF_INET));
>  #endif

Applied, thanks!

Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

Eli Zaretskii <eliz@gnu.org> 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's no /bin/sh on Windows.
>
> --- libguile/posix.c~1	2013-06-13 08:54:44.926293300 +0300
> +++ libguile/posix.c	2013-06-13 08:57:44.262743700 +0300
> @@ -1300,7 +1300,9 @@ scm_open_process (SCM mode, SCM prog, SC
>    int pid;
>    char *exec_file;
>    char **exec_argv;
> +#ifdef HAVE_FORK
>    int max_fd = 1024;
> +#endif

The #ifdef appears unnecessary given that this is already in #ifdef HAVE_FORK.

>    exec_file = scm_to_locale_string (prog);
>    exec_argv = scm_i_allocate_string_pointers (scm_cons (prog, args));
> @@ -1435,6 +1437,14 @@ scm_open_process (SCM mode, SCM prog, SC
>  	close (p2c[0]);
>        }
>  
> +    if (c_strcasecmp (exec_file, "/bin/sh") == 0)
> +      {
> +	strcpy (exec_file, "cmd.exe");
> +	strcpy (exec_argv[0], "cmd.exe");
> +	if (strcmp (exec_argv[1], "-c") == 0)
> +	  strcpy (exec_argv[1], "/c");
> +      }
> +
>      pid = spawnvp (P_NOWAIT, exec_file, exec_argv);
>      errno_save = errno;
>  
> @@ -1486,7 +1496,6 @@ scm_open_process (SCM mode, SCM prog, SC
>      {
>        int errno_save = errno;
>  
> -      free (exec_file);
>        if (reading)
>          {
>            close (c2p[0]);
> @@ -1512,6 +1521,7 @@ scm_open_process (SCM mode, SCM prog, SC
>  		   exec_file, msg);
>  	}
>  #endif
> +      free (exec_file);
>        SCM_SYSERROR;
>      }
>  
> @@ -1592,9 +1602,9 @@ scm_open_process (SCM mode, SCM prog, SC
>      }
>  
>    _exit (EXIT_FAILURE);
> +#endif	/* HAVE_FORK */
>    /* Not reached.  */
>    return SCM_BOOL_F;
> -#endif	/* HAVE_FORK */
>  }
>  #undef FUNC_NAME

This last hunk doesn’t apply since the whole thing is already in
#ifdef HAVE_FORK AFAICS.

What about this (hopefully simpler) patch instead?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1098 bytes --]

diff --git a/module/ice-9/popen.scm b/module/ice-9/popen.scm
index 7d0549e..e431949 100644
--- a/module/ice-9/popen.scm
+++ b/module/ice-9/popen.scm
@@ -61,13 +61,23 @@ port to the process is created: it should be the value of
         (hashq-set! port/pid-table port pid)
         port))))
 
+(define %shell-command
+  (cond ((file-exists? "/bin/sh")
+         "/bin/sh")
+        ((getenv "SHELL")
+         ;; Hope that $SHELL points at a Bourne-compatible shell.
+         => identity)
+        (else
+         ;; Assume we're on Windows.
+         "cmd.exe")))
+
 (define (open-pipe command mode)
   "Executes the shell command @var{command} (a string) in a subprocess.
 A port to the process (based on pipes) is created and returned.
 @var{mode} specifies whether an input, an output or an input-output
 port to the process is created: it should be the value of
 @code{OPEN_READ}, @code{OPEN_WRITE} or @code{OPEN_BOTH}."
-  (open-pipe* mode "/bin/sh" "-c" command))
+  (open-pipe* mode %shell-command "-c" command))
 
 (define (fetch-pid port)
   (let ((pid (hashq-ref port/pid-table port)))

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> 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.000000000 +0200
> +++ test-suite/standalone/test-system-cmds	2013-06-12 13:52:14.333269200 +0300
> @@ -10,7 +10,7 @@
>           "test-system-cmds: (system) did not return a boolean\n")
>          (exit 1)))
>    
> -  (let ((rs (status:exit-val (system "guile -c '(exit 42)'"))))
> +  (let ((rs (status:exit-val (system "guile -c \"(exit 42)\""))))
>      (if (not (= 42 rs))
>          (begin
>            (simple-format
> @@ -39,4 +39,4 @@
>  
>  ;; Local Variables:
>  ;; mode: scheme
> -;; End:
> \ No newline at end of file
> +;; End:

Applied.

> '/tmp' will exist, none of which can be counted upon on Windows.
> Here's the fix for that (the declaration of mkstemp avoids compiler
> warning):
>
> --- test-suite/standalone/test-unwind.c~0	2012-01-31 00:32:38.000000000 +0200
> +++ test-suite/standalone/test-unwind.c	2013-06-12 14:11:47.967231800 +0300
> @@ -200,9 +200,19 @@ check_ports ()
>  #define FILENAME_TEMPLATE "/check-ports.XXXXXX"
>    char *filename;
>    const char *tmpdir = getenv ("TMPDIR");
> +#ifdef __MINGW32__
> +  extern int mkstemp (char *);
>  
>    if (tmpdir == NULL)
> +    tmpdir = getenv ("TEMP");
> +  if (tmpdir == NULL)
> +    tmpdir = getenv ("TMP");
> +  if (tmpdir == NULL)
> +    tmpdir = "/";
> +#else
> +  if (tmpdir == NULL)
>      tmpdir = "/tmp";
> +#endif
>  
>    filename = alloca (strlen (tmpdir) + sizeof (FILENAME_TEMPLATE) + 1);
>    strcpy (filename, tmpdir);

Applied, thanks.

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 easier to apply patches.

Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> Date: Tue, 11 Jun 2013 19:53:21 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: ludo@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 "almost" later.)
>
> The second part of the details is about "make install": it failed
> because it looked for guild.exe and guile_tools.exe, which don't
> exist, because guild and guile_tools are shell scripts, not .exe
> programs.  Fixed thusly:
>
> --- meta/Makefile.am~0	2013-03-25 23:24:24.000000000 +0200
> +++ meta/Makefile.am	2013-06-12 14:26:47.032031800 +0300
> @@ -30,9 +30,9 @@
>  # What we now call `guild' used to be known as `guile-tools'.
>  install-exec-hook:
>  	guild="`echo $(ECHO_N) guild				\
> -	   | $(SED) -e '$(program_transform_name)'`$(EXEEXT)" ;	\
> +	   | $(SED) -e '$(program_transform_name)'`" ;	\
>  	guile_tools="`echo $(ECHO_N) guile-tools		\
> -	   | $(SED) -e '$(program_transform_name)'`$(EXEEXT)" ;	\
> +	   | $(SED) -e '$(program_transform_name)'`" ;	\
>  	cd $(DESTDIR)$(bindir) && rm -f "$$guile_tools" &&	\
>  	$(LN_S) "$$guild" "$$guile_tools"

This was already fixed in dac5e6491b215f8d70bc8328639b4c72cb7cd565
(Apr. 2013).

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Eli Zaretskii <eliz@gnu.org> 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.000000000 +0300
> +++ libguile/Makefile.am	2013-06-13 13:34:27.545323200 +0300
> @@ -113,7 +113,7 @@
>  guile_SOURCES = guile.c
>  guile_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
>  guile_LDADD = libguile-@GUILE_EFFECTIVE_VERSION@.la
> -guile_LDFLAGS = $(GUILE_CFLAGS)
> +guile_LDFLAGS = $(GUILE_CFLAGS) -export-dynamic
>  
>  libguile_@GUILE_EFFECTIVE_VERSION@_la_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)

Rather than exporting more symbols just for the sake of those test
cases, I changed the test suite to skip those test cases when ‘qsort’ is
not visible:


[-- Attachment #2: Type: text/x-patch, Size: 2437 bytes --]

commit 09fb52b6c908606a0f4a5d5d118128c02de606c4
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Sun Jun 16 16:52:38 2013 +0200

    tests: Skip FFI tests that use `qsort' when it's not accessible.
    
    * test-suite/tests/foreign.test ("procedure->pointer")[qsort]: Wrap in
      `false-if-exception'.
      ["qsort", "qsort, wrong return type", "qsort, wrong arity"]: Throw
      'unresolved when QSORT if #f.
      Reported by Eli Zaretskii <eliz@gnu.org>.

	Modified   test-suite/tests/foreign.test
diff --git a/test-suite/tests/foreign.test b/test-suite/tests/foreign.test
index 66fd3d5..4b129db 100644
--- a/test-suite/tests/foreign.test
+++ b/test-suite/tests/foreign.test
@@ -224,9 +224,13 @@
 
   (define qsort
     ;; Bindings for libc's `qsort' function.
-    (pointer->procedure void
-                        (dynamic-func "qsort" (dynamic-link))
-                        (list '* size_t size_t '*)))
+    ;; On some platforms, such as MinGW, `qsort' is visible only if
+    ;; linking with `-export-dynamic'.  Just skip these tests when it's
+    ;; not visible.
+    (false-if-exception
+     (pointer->procedure void
+                         (dynamic-func "qsort" (dynamic-link))
+                         (list '* size_t size_t '*))))
 
   (define (dereference-pointer-to-byte ptr)
     (let ((b (pointer->bytevector ptr 1)))
@@ -236,7 +240,7 @@
     '(7 1 127 3 5 4 77 2 9 0))
 
   (pass-if "qsort"
-    (if (defined? 'procedure->pointer)
+    (if (and qsort (defined? 'procedure->pointer))
         (let* ((called? #f)
                (cmp     (lambda (x y)
                           (set! called? #t)
@@ -254,7 +258,7 @@
   (pass-if-exception "qsort, wrong return type"
     exception:wrong-type-arg
 
-    (if (defined? 'procedure->pointer)
+    (if (and qsort (defined? 'procedure->pointer))
         (let* ((cmp     (lambda (x y) #f)) ; wrong return type
                (ptr     (procedure->pointer int cmp (list '* '*)))
                (bv      (u8-list->bytevector input)))
@@ -266,7 +270,7 @@
   (pass-if-exception "qsort, wrong arity"
     exception:wrong-num-args
 
-    (if (defined? 'procedure->pointer)
+    (if (and qsort (defined? 'procedure->pointer))
         (let* ((cmp     (lambda (x y z) #f)) ; wrong arity
                (ptr     (procedure->pointer int cmp (list '* '*)))
                (bv      (u8-list->bytevector input)))


[-- Attachment #3: Type: text/plain, Size: 551 bytes --]


> The following patch prevents test failure on systems that don't
> support symlinks, and thus test-symlink file is not created and does
> not exist there.
>  
> --- test-suite/tests/filesys.test~0	2013-04-09 09:52:31.000000000 +0300
> +++ test-suite/tests/filesys.test	2013-06-13 07:49:51.567974100 +0300
> @@ -222,4 +222,5 @@
>            (throw 'unresolved)))))
>  
>  (delete-file (test-file))
> -(delete-file (test-symlink))
> +(if (file-exists? (test-symlink))
> +    (delete-file (test-symlink)))

Applied, thanks!

Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Eli Zaretskii <eliz@gnu.org> 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 ports.test:
>
>      Running ports.test
>      FAIL: ports.test: file: binary mode ignores port encoding
>      FAIL: ports.test: file: binary mode ignores file coding declaration
>
>    Should I worry about this?

Possibly.  :-)

Can you try this patch, run ./check-guile ports.test, and report the
debugging statements that are printed?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 983 bytes --]

diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
index 9b1c6c0..6137181 100644
--- a/test-suite/tests/ports.test
+++ b/test-suite/tests/ports.test
@@ -251,7 +251,7 @@
                         (line (read-line in-port)))
                    (close-port in-port)
                    (delete-file filename)
-                   (string=? line binary-test-string)))))
+                   (string=? (pk 'line line) binary-test-string)))))
 
 ;;; binary mode ignores file coding declaration
 (pass-if "file: binary mode ignores file coding declaration"
@@ -272,7 +272,7 @@
                         (line2 (read-line in-port)))
                    (close-port in-port)
                    (delete-file filename)
-                   (string=? line2 binary-test-string)))))
+                   (string=? (pk 'line2 line2) binary-test-string)))))
 
 ;; open-file ignores file coding declaration by default
 (pass-if "file: open-file ignores coding declaration by default"

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]


> 3. Emacs-lisp test display warnings about overriding Scheme procedures
>    -- is that something to worry about?

No.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

> The changes below work around the lack of h_error on Windows:
>
> --- libguile/net_db.c~0	2013-03-25 23:44:46.000000000 +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_errno        WSAGetLastError()
> +# define HAVE_H_ERRNO   1
> +# define HAVE_HSTRERROR 1
> +# ifdef HAVE_DECL_HSTRERROR
> +#  undef HAVE_DECL_HSTRERROR
> +# endif
> +# define HAVE_DECL_HSTRERROR 1
> +# define HOST_NOT_FOUND WSAHOST_NOT_FOUND
> +# define TRY_AGAIN      WSATRY_AGAIN
> +# define NO_RECOVERY    WSANO_RECOVERY
> +# define NO_DATA        WSANO_DATA
> +
> +char *hstrerror (int);
> +
> +char *
> +hstrerror (int error_no)
> +{
> +  static char buf[500];

Rather allocate it dynamically, with ‘scm_gc_malloc_pointerless’.

> +  DWORD ret;
> +
> +  if (error_no == 0)
> +    error_no = WSAGetLastError ();
> +
> +  ret = FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM |
> +                       FORMAT_MESSAGE_IGNORE_INSERTS,
> +                       NULL,
> +                       error_no,
> +                       0, /* choose most suitable language */
> +                       buf, sizeof (buf), NULL);
> +
> +  while (ret > 0 && (buf[ret - 1] == '\n' ||
> +                     buf[ret - 1] == '\r' ))
> +      --ret;
> +  buf[ret] = '\0';
> +  if (!ret)
> +    sprintf (buf, "Winsock error %u", error_no);
> +
> +  return buf;
> +}
> +#endif	/* __MINGW32__ */

This looks good, but I feel that this ought to be in a Gnulib module,
no?  Would you like to propose such a module on bug-gnulib@?

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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" command))
> >
> > and obviously there's no /bin/sh on Windows.
> >
> > --- libguile/posix.c~1	2013-06-13 08:54:44.926293300 +0300
> > +++ libguile/posix.c	2013-06-13 08:57:44.262743700 +0300
> > @@ -1300,7 +1300,9 @@ scm_open_process (SCM mode, SCM prog, SC
> >    int pid;
> >    char *exec_file;
> >    char **exec_argv;
> > +#ifdef HAVE_FORK
> >    int max_fd = 1024;
> > +#endif
> 
> The #ifdef appears unnecessary given that this is already in #ifdef HAVE_FORK.

As I wrote above, this was supposed to be applied on top of what I
sent here:

  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00033.html

which, among other things, inserted "#endif" before scm_open_process,
thus making it available when fork isn't.

> This last hunk doesn’t apply since the whole thing is already in
> #ifdef HAVE_FORK AFAICS.

See above.  The intent was to make open-process available on Windows,
so ifdef'ing all of it conditioned on fork would be
counter-productive...

> What about this (hopefully simpler) patch instead?
> 
> diff --git a/module/ice-9/popen.scm b/module/ice-9/popen.scm
> index 7d0549e..e431949 100644
> --- a/module/ice-9/popen.scm
> +++ b/module/ice-9/popen.scm
> @@ -61,13 +61,23 @@ port to the process is created: it should be the value of
>          (hashq-set! port/pid-table port pid)
>          port))))
>  
> +(define %shell-command
> +  (cond ((file-exists? "/bin/sh")
> +         "/bin/sh")
> +        ((getenv "SHELL")
> +         ;; Hope that $SHELL points at a Bourne-compatible shell.
> +         => identity)
> +        (else
> +         ;; Assume we're on Windows.
> +         "cmd.exe")))
> +
>  (define (open-pipe command mode)
>    "Executes the shell command @var{command} (a string) in a subprocess.
>  A port to the process (based on pipes) is created and returned.
>  @var{mode} specifies whether an input, an output or an input-output
>  port to the process is created: it should be the value of
>  @code{OPEN_READ}, @code{OPEN_WRITE} or @code{OPEN_BOTH}."
> -  (open-pipe* mode "/bin/sh" "-c" command))
> +  (open-pipe* mode %shell-command "-c" command))
>  
>  (define (fetch-pid port)
>    (let ((pid (hashq-ref port/pid-table port)))

The "-c" part needs to be replaced with "/c".  And that would only
take care of open-pipe; there are more instances of using /bin/sh
etc. elsewhere in Guile.  If we want to handle this on the Scheme
level, it will be necessary to consistently discourage people from
using explicit shell file names and instead use %shell-file-name and
%shell-command-switch, like Emacs does.

And the parts of scm_open_process that replace the Unix fork/exec
stuff will still be needed, just without rewriting exec_file and
exec_arg[].

Thanks.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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 easier to apply patches.

OK.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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 -export-dynamic, so this is needed:
> >
> > --- libguile/Makefile.am~	2013-04-03 15:11:28.000000000 +0300
> > +++ libguile/Makefile.am	2013-06-13 13:34:27.545323200 +0300
> > @@ -113,7 +113,7 @@
> >  guile_SOURCES = guile.c
> >  guile_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
> >  guile_LDADD = libguile-@GUILE_EFFECTIVE_VERSION@.la
> > -guile_LDFLAGS = $(GUILE_CFLAGS)
> > +guile_LDFLAGS = $(GUILE_CFLAGS) -export-dynamic
> >  
> >  libguile_@GUILE_EFFECTIVE_VERSION@_la_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
> 
> Rather than exporting more symbols just for the sake of those test
> cases, I changed the test suite to skip those test cases when ‘qsort’ is
> not visible:

This isn't only about 'qsort', it's also about another test (whose
name I cannot remember at the moment).  Anyway, doesn't Guile expect
to be able to call its own functions via dynamic-link?  If it does,
then the only way of making that work is to use -export-dynamic, if my
reading of the libtool docs is correct.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@netris.org,  guile-user@gnu.org
> Date: Sun, 16 Jun 2013 17:04:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> skribis:
> 
> > The changes below work around the lack of h_error on Windows:
> >
> > --- libguile/net_db.c~0	2013-03-25 23:44:46.000000000 +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_errno        WSAGetLastError()
> > +# define HAVE_H_ERRNO   1
> > +# define HAVE_HSTRERROR 1
> > +# ifdef HAVE_DECL_HSTRERROR
> > +#  undef HAVE_DECL_HSTRERROR
> > +# endif
> > +# define HAVE_DECL_HSTRERROR 1
> > +# define HOST_NOT_FOUND WSAHOST_NOT_FOUND
> > +# define TRY_AGAIN      WSATRY_AGAIN
> > +# define NO_RECOVERY    WSANO_RECOVERY
> > +# define NO_DATA        WSANO_DATA
> > +
> > +char *hstrerror (int);
> > +
> > +char *
> > +hstrerror (int error_no)
> > +{
> > +  static char buf[500];
> 
> Rather allocate it dynamically, with ‘scm_gc_malloc_pointerless’.
> 
> > +  DWORD ret;
> > +
> > +  if (error_no == 0)
> > +    error_no = WSAGetLastError ();
> > +
> > +  ret = FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM |
> > +                       FORMAT_MESSAGE_IGNORE_INSERTS,
> > +                       NULL,
> > +                       error_no,
> > +                       0, /* choose most suitable language */
> > +                       buf, sizeof (buf), NULL);
> > +
> > +  while (ret > 0 && (buf[ret - 1] == '\n' ||
> > +                     buf[ret - 1] == '\r' ))
> > +      --ret;
> > +  buf[ret] = '\0';
> > +  if (!ret)
> > +    sprintf (buf, "Winsock error %u", error_no);
> > +
> > +  return buf;
> > +}
> > +#endif	/* __MINGW32__ */
> 
> This looks good, but I feel that this ought to be in a Gnulib module,
> no?  Would you like to propose such a module on bug-gnulib@?

I will try.

Thanks.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: mhw@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 -export-dynamic, so this is needed:
>> >
>> > --- libguile/Makefile.am~	2013-04-03 15:11:28.000000000 +0300
>> > +++ libguile/Makefile.am	2013-06-13 13:34:27.545323200 +0300
>> > @@ -113,7 +113,7 @@
>> >  guile_SOURCES = guile.c
>> >  guile_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
>> >  guile_LDADD = libguile-@GUILE_EFFECTIVE_VERSION@.la
>> > -guile_LDFLAGS = $(GUILE_CFLAGS)
>> > +guile_LDFLAGS = $(GUILE_CFLAGS) -export-dynamic
>> >  
>> >  libguile_@GUILE_EFFECTIVE_VERSION@_la_CFLAGS = $(GUILE_CFLAGS) $(AM_CFLAGS)
>> 
>> Rather than exporting more symbols just for the sake of those test
>> cases, I changed the test suite to skip those test cases when ‘qsort’ is
>> not visible:
>
> This isn't only about 'qsort', it's also about another test (whose
> name I cannot remember at the moment).

Oh, in coverage.test.  Fixed.

> Anyway, doesn't Guile expect to be able to call its own functions via
> dynamic-link?

No.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

Eli Zaretskii <eliz@gnu.org> skribis:

>> Date: Tue, 11 Jun 2013 19:53:21 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: ludo@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 since most of
>> the functions disabled by --disable-posix already have HAVE_foo guards
>> around them, so systems that don't have them will not have the
>> corresponding Guile feature.  I will try to lift as much of the
>> disabled functionality as MinGW can bear.
>
> 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 nice!

We would need the copyright to be assigned to the FSF before it can be
committed.  How does that sound?  If you’re willing to do so, I can send
you the paperwork off-line.

> 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?  I'd like to see if my
> build, which didn't use --disable-posix, has any problems in that
> area, and if so try to debug them.

No idea.

A few comments:

> --- libguile/filesys.c~0	2013-04-09 09:52:31.000000000 +0300
> +++ libguile/filesys.c	2013-06-12 13:41:31.244477700 +0300
> @@ -112,7 +112,12 @@
>  
>  /* Some more definitions for the native Windows port. */
>  #ifdef __MINGW32__
> -# define fsync(fd) _commit (fd)
> +# define fsync(fd)    _commit (fd)
> +# define WIN32_LEAN_AND_MEAN

What does that mean?  :-)

> +# include <windows.h>
> +/* FIXME: Should use 'link' module from gnulib.  */
> +# define link(f1,f2)  CreateHardLink(f2, f1, NULL)
> +# define HAVE_LINK 1

Let’s do it then, and remove that part of the patch.

> -#ifdef HAVE_POSIX
> -

Note that HAVE_POSIX really means --enable-posix.  Since this patch
keeps that option, it should probably keep the #ifdefs.  That would be a
topic for a separate patch.

> @@ -921,7 +958,7 @@ SCM_DEFINE (scm_setegid, "setegid", 1, 0
>  {
>    int rv;
>  
> -#ifdef HAVE_SETEUID
> +#ifdef HAVE_SETEGID

Oops, applied.

> @@ -1320,7 +1357,130 @@ scm_open_process (SCM mode, SCM prog, SC
>    }
>  #endif
>  
> +#ifdef HAVE_FORK
>    pid = fork ();
> +#elif defined(__MINGW32__)
> +  {
> +    int save_stdin = -1, save_stdout = -1;
> +    int errno_save;
> +
> +    if (reading)

[...]

Could this MinGW-specific code be moved to a separate function?

I think the patch also needs something like this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 309 bytes --]

--- a/configure.ac
+++ b/configure.ac
@@ -760,7 +760,7 @@ AC_CHECK_FUNCS([DINFINITY DQNAN cexp chsize clog clog10 ctermid		\
   sched_setaffinity sendfile])
 
 AM_CONDITIONAL([BUILD_ICE_9_POPEN],
-  [test "x$enable_posix" = "xyes" && test "x$ac_cv_func_fork" = "xyes"])
+  [test "x$enable_posix" = "xyes"])
 

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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 nice!

Thanks.

> We would need the copyright to be assigned to the FSF before it can be
> committed.  How does that sound?  If you’re willing to do so, I can send
> you the paperwork off-line.

Please do.

> > --- libguile/filesys.c~0	2013-04-09 09:52:31.000000000 +0300
> > +++ libguile/filesys.c	2013-06-12 13:41:31.244477700 +0300
> > @@ -112,7 +112,12 @@
> >  
> >  /* Some more definitions for the native Windows port. */
> >  #ifdef __MINGW32__
> > -# define fsync(fd) _commit (fd)
> > +# define fsync(fd)    _commit (fd)
> > +# define WIN32_LEAN_AND_MEAN
> 
> What does that mean?  :-)

It prevents the compiler from fetching too much from the windows.h
header, thus minimizing the possibility of conflicts with other
headers and macros.

> > +# include <windows.h>
> > +/* FIXME: Should use 'link' module from gnulib.  */
> > +# define link(f1,f2)  CreateHardLink(f2, f1, NULL)
> > +# define HAVE_LINK 1
> 
> Let’s do it then, and remove that part of the patch.

Right.

> > -#ifdef HAVE_POSIX
> > -
> 
> Note that HAVE_POSIX really means --enable-posix.  Since this patch
> keeps that option, it should probably keep the #ifdefs.  That would be a
> topic for a separate patch.

What is the purpose of --enable-posix?  I thought it could be removed,
once you accepted the changes to the sources.

> > +#ifdef HAVE_FORK
> >    pid = fork ();
> > +#elif defined(__MINGW32__)
> > +  {
> > +    int save_stdin = -1, save_stdout = -1;
> > +    int errno_save;
> > +
> > +    if (reading)
> 
> [...]
> 
> Could this MinGW-specific code be moved to a separate function?

Yes.  But there are still non-FORK parts of the patch elsewhere in
this function that are needed.

> I think the patch also needs something like this:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -760,7 +760,7 @@ AC_CHECK_FUNCS([DINFINITY DQNAN cexp chsize clog clog10 ctermid		\
>    sched_setaffinity sendfile])
>  
>  AM_CONDITIONAL([BUILD_ICE_9_POPEN],
> -  [test "x$enable_posix" = "xyes" && test "x$ac_cv_func_fork" = "xyes"])
> +  [test "x$enable_posix" = "xyes"])

Right you are.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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
> >
> >    Should I worry about this?
> 
> Possibly.  :-)
> 
> Can you try this patch, run ./check-guile ports.test, and report the
> debugging statements that are printed?

That pk thing is a useful trick, thanks.

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 there are functions for that, but I
found no description of how they are supposed to be used.  What am I
missing?

> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
> index 9b1c6c0..6137181 100644
> --- a/test-suite/tests/ports.test
> +++ b/test-suite/tests/ports.test
> @@ -251,7 +251,7 @@
>                          (line (read-line in-port)))
>                     (close-port in-port)
>                     (delete-file filename)
> -                   (string=? line binary-test-string)))))
> +                   (string=? (pk 'line line) binary-test-string)))))
>  
>  ;;; binary mode ignores file coding declaration
>  (pass-if "file: binary mode ignores file coding declaration"
> @@ -272,7 +272,7 @@
>                          (line2 (read-line in-port)))
>                     (close-port in-port)
>                     (delete-file filename)
> -                   (string=? line2 binary-test-string)))))
> +                   (string=? (pk 'line2 line2) binary-test-string)))))
>  
>  ;; open-file ignores file coding declaration by default
>  (pass-if "file: open-file ignores coding declaration by default"

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 you
added show this (note the \r at the end):

     ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
     FAIL: ports.test: file: binary mode ignores port encoding
     
     ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
     FAIL: ports.test: file: binary mode ignores file coding declaration

I think the solution is to attach to the output port a transcoder that
leaves the single newline character at end of line intact.  But I
couldn't find any example or documentation that would show me how to
construct a transcoder for an encoding.  make-transcoder wants a
codec, but I see no documentation how to make one.  IOW, how do I take
a string like "iso-8859-15" and make a codec out of it?  I trust that
you will know, though ;-)

Thanks.

Re: guile 2.0.9 build on mingw

[Mark H Weaver]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> 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. by running without any command-line arguments.  Two people
reported that when built with --enable-posix, Guile would work when run
in a non-interactive way (e.g. using -c or running a script), but would
hang when run interactively.

As described in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14171#14>,
the problem seems to be in 'call-with-sigint' defined in
ice-9/top-repl.scm.  Note that 'call-with-sigint' only installs a signal
handler if POSIX support is enabled, and otherwise is a no-op.
--disable-posix avoided the hang and allowed the REPL to be reached.

> I'd like to see if my
> build, which didn't use --disable-posix, has any problems in that
> area, and if so try to debug them.

Thanks for your work on this!

     Mark

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: ludo@gnu.org,  guile-user@gnu.org
> Date: Mon, 17 Jun 2013 11:45:51 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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. by running without any command-line arguments.

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 patch below.

> Two people
> reported that when built with --enable-posix, Guile would work when run
> in a non-interactive way (e.g. using -c or running a script), but would
> hang when run interactively.
> 
> As described in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14171#14>,
> the problem seems to be in 'call-with-sigint' defined in
> ice-9/top-repl.scm.  Note that 'call-with-sigint' only installs a signal
> handler if POSIX support is enabled, and otherwise is a no-op.
> --disable-posix avoided the hang and allowed the REPL to be reached.

I looked into this.  First of all, the Guile I built without threads,
but with --enable-posix does not hang when I invoke it without
arguments.  It shows me the prompt and allows me to type commands.  It
also reacts correctly to Ctrl-C.  So the fact is that POSIX does not
by itself do any harm in the MinGW build.

My analysis of this, which included both reading the relevant sources
and the above-mentioned bug report, is that the conclusion in that bug
report is based on a mistaken interpretation of the reasons for the
hang.  It is not related to HAVE_POSIX, except accidentally.  It's
true that call-with-sigint installs a signal handler (by eventually
calling scm_sigaction_for_thread) only if HAVE_POSIX is defined.
However, nothing in the code of scm_sigaction_for_thread has anything
to do with HAVE_POSIX.  By contrast, it has _everything_ to do with
threads: it calls the same scm_i_ensure_signal_delivery_thread,
which unsurprisingly is the same place where I found Guile to hang
even in batch mode.  When SCM_USE_PTHREAD_THREADS is not defined,
scm_i_ensure_signal_delivery_thread is a no-op.

Moreover, the backtrace in the bug report clearly shows that Guile
hangs in pthread-related functions called from
scm_sigaction_for_thread, not in something that is only included if
HAVE_POSIX is defined.  So I concluded that disabling POSIX just works
around that problem, by not installing the signal handler, which
avoids calling scm_i_ensure_signal_delivery_thread, but the problem
itself, with threads usage, is still there.

IOW, it's not the POSIX functionality that is the culprit; it's
threads.

Which reminds me that it would be nice if someone could comment on the
findings and questions I published in
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00030.html.

Here's the patch for the manual:

  Improve indexing of "REPL".

	* doc/ref/scheme-using.texi (Using Guile Interactively): Add index
	entries for REPL.

diff --git a/doc/ref/scheme-using.texi b/doc/ref/scheme-using.texi
index 4422c18..350df9c 100644
--- a/doc/ref/scheme-using.texi
+++ b/doc/ref/scheme-using.texi
@@ -24,6 +24,8 @@ $3 = b
 @end lisp
 
 @noindent
+@cindex REPL
+@cindex read-eval-print loop
 This mode of use is called a @dfn{REPL}, which is short for
 ``Read-Eval-Print Loop'', because the Guile interpreter first reads the
 expression that you have typed, then evaluates it, and then prints the

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 20:17:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ludo@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 patch below.

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 support UTF-8, and so at
least the stand-alone Info reader will show a lot of garbage on
Windows.  I suggest to use --disable-encoding for the MinGW build.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> Date: Tue, 18 Jun 2013 20:17:25 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: ludo@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 patch below.
>
> 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 support UTF-8, and so at
> least the stand-alone Info reader will show a lot of garbage on
> Windows.  I suggest to use --disable-encoding for the MinGW build.

The problem is that the tarball comes with a .info file so that users
don’t need to have makeinfo installed (as per the GCS).

What about suggesting Windows users to use Emacs to view the
documentation?  My feeling is that people aware of Info on Windows may
already being doing this anyway.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: mhw@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
>> >
>> >    Should I worry about this?
>> 
>> Possibly.  :-)
>> 
>> Can you try this patch, run ./check-guile ports.test, and report the
>> debugging statements that are printed?
>
> That pk thing is a useful trick, thanks.
>
> 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 there are functions for that, but I
> found no description of how they are supposed to be used.  What am I
> missing?

There’s a gdbinit file in Guile that you can load to get a few helper
functions.

>> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
>> index 9b1c6c0..6137181 100644
>> --- a/test-suite/tests/ports.test
>> +++ b/test-suite/tests/ports.test
>> @@ -251,7 +251,7 @@
>>                          (line (read-line in-port)))
>>                     (close-port in-port)
>>                     (delete-file filename)
>> -                   (string=? line binary-test-string)))))
>> +                   (string=? (pk 'line line) binary-test-string)))))
>>  
>>  ;;; binary mode ignores file coding declaration
>>  (pass-if "file: binary mode ignores file coding declaration"
>> @@ -272,7 +272,7 @@
>>                          (line2 (read-line in-port)))
>>                     (close-port in-port)
>>                     (delete-file filename)
>> -                   (string=? line2 binary-test-string)))))
>> +                   (string=? (pk 'line2 line2) binary-test-string)))))
>>  
>>  ;; open-file ignores file coding declaration by default
>>  (pass-if "file: open-file ignores coding declaration by default"
>
> 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 you
> added show this (note the \r at the end):
>
>      ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>      FAIL: ports.test: file: binary mode ignores port encoding
>      
>      ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>      FAIL: ports.test: file: binary mode ignores file coding declaration

I think this patch solves the problem:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 301 bytes --]

diff --git a/libguile/rdelim.c b/libguile/rdelim.c
index 9d14967..9f16c69 100644
--- a/libguile/rdelim.c
+++ b/libguile/rdelim.c
@@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
 	    {
 	    case EOF:
 	    case '\n':
+	    case '\r':
 	      delim = buf[index];
 	      break;
 

[-- Attachment #3: Type: text/plain, Size: 847 bytes --]


Probably the extra case should be #ifdef __MINGW32__, to make sure it
has no effect on non-Windows users.  Thoughts?

> I think the solution is to attach to the output port a transcoder that
> leaves the single newline character at end of line intact.  But I
> couldn't find any example or documentation that would show me how to
> construct a transcoder for an encoding.  make-transcoder wants a
> codec, but I see no documentation how to make one.  IOW, how do I take
> a string like "iso-8859-15" and make a codec out of it?  I trust that
> you will know, though ;-)

Ah ah, this is an R6RS API that’s not actually fully implemented.

So, there are predefined codecs, like ‘latin-1-codec’.  This part is
implemented, in terms of ‘set-port-encoding!’.

However the CR/LF transcoders are not implemented.

Ludo’.

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

[Mark H Weaver]

Hi Julian,

Could you help us understand some code you added to Guile in 2007?

Eli Zaretskii <eliz@gnu.org> 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 I found surprising.

> and why is it launched at exit?

Good question.  This behavior was apparently introduced in this commit:

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2e77f7202b11ad0003831fcff94ec7db80cca015

It appears that Julian Graham may have been the author of these changes.
I've CC'd him, hoping that he can shed some light on this.

> +  /* Ensure the signal handling thread has been launched, because we might be
> +     shutting it down.  */
> +  scm_i_ensure_signal_delivery_thread ();

Julian, can you remember why you did this?  I don't understand the
comment above.  What does "it" refer to?  I would that guess that "it"
is the signal handling thread, but how could we be shutting down that
thread if it hadn't yet been launched?

    Regards,
      Mark

Re: guile 2.0.9 build on mingw

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Eli Zaretskii <eliz@gnu.org> 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 you
>> added show this (note the \r at the end):
>>
>>      ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>      FAIL: ports.test: file: binary mode ignores port encoding
>>      
>>      ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>      FAIL: ports.test: file: binary mode ignores file coding declaration
>
> 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/rdelim.c
> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>  	    {
>  	    case EOF:
>  	    case '\n':
> +	    case '\r':
>  	      delim = buf[index];
>  	      break;
>  
>
> Probably the extra case should be #ifdef __MINGW32__, to make sure it
> has no effect on non-Windows users.  Thoughts?

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 hides a problem (the user reading text without
  a proper transcoder), but does not solve the problem adequately.  It
  will behave badly on files with CRLF line endings.  There's no way to
  fix that in 'read-line' because its API does not allow for a
  multi-character delimiter.

* It potentially breaks existing code.  Making the change only on mingw
  would seem to mitigate that problem, but that just muddies the waters
  by introducing a difference in behavior that is not necessarily
  warranted.

* It hard codes the assumption that the line ending style of the file
  being read is determined by the platform you're running on.

To my mind, this is a bug in those tests.  So how about the following
patch instead?

What do you think?

    Mark


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/ports.test
@@ -238,7 +238,7 @@
 (pass-if "file: binary mode ignores port encoding"
   (with-fluids ((%default-port-encoding "UTF-8"))
                (let* ((filename (test-file))
-                      (port (open-file filename "w"))
+                      (port (open-file filename "wb"))
                       (test-string "一二三")
                       (binary-test-string
                        (apply string
@@ -257,7 +257,7 @@
 (pass-if "file: binary mode ignores file coding declaration"
   (with-fluids ((%default-port-encoding "UTF-8"))
                (let* ((filename (test-file))
-                      (port (open-file filename "w"))
+                      (port (open-file filename "wb"))
                       (test-string "一二三")
                       (binary-test-string
                        (apply string

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@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 support UTF-8, and so at
> > least the stand-alone Info reader will show a lot of garbage on
> > Windows.  I suggest to use --disable-encoding for the MinGW build.
> 
> The problem is that the tarball comes with a .info file so that users
> don’t need to have makeinfo installed (as per the GCS).

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 such a bad idea).  But at
least rebuilding docs could then DTRT.

> What about suggesting Windows users to use Emacs to view the
> documentation?  My feeling is that people aware of Info on Windows may
> already being doing this anyway.

I use both, FWIW.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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/rdelim.c
> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>  	    {
>  	    case EOF:
>  	    case '\n':
> +	    case '\r':
>  	      delim = buf[index];
>  	      break;
> 
> Probably the extra case should be #ifdef __MINGW32__, to make sure it
> has no effect on non-Windows users.  Thoughts?

Not a good idea, IMO: it will remove lone CR characters as well.

> > I think the solution is to attach to the output port a transcoder that
> > leaves the single newline character at end of line intact.  But I
> > couldn't find any example or documentation that would show me how to
> > construct a transcoder for an encoding.  make-transcoder wants a
> > codec, but I see no documentation how to make one.  IOW, how do I take
> > a string like "iso-8859-15" and make a codec out of it?  I trust that
> > you will know, though ;-)
> 
> Ah ah, this is an R6RS API that’s not actually fully implemented.
> 
> So, there are predefined codecs, like ‘latin-1-codec’.  This part is
> implemented, in terms of ‘set-port-encoding!’.
> 
> However the CR/LF transcoders are not implemented.

Too bad.  The text/binary I/O issue on Windows is not really reliable
without that.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  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 hides a problem (the user reading text without
>   a proper transcoder), but does not solve the problem adequately.  It
>   will behave badly on files with CRLF line endings.  There's no way to
>   fix that in 'read-line' because its API does not allow for a
>   multi-character delimiter.
> 
> * It potentially breaks existing code.  Making the change only on mingw
>   would seem to mitigate that problem, but that just muddies the waters
>   by introducing a difference in behavior that is not necessarily
>   warranted.
> 
> * It hard codes the assumption that the line ending style of the file
>   being read is determined by the platform you're running on.

I agree.

> To my mind, this is a bug in those tests.

Right.

> So how about the following patch instead?
> 
> What do you think?
> 
>     Mark
> 
> 
> 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/ports.test
> @@ -238,7 +238,7 @@
>  (pass-if "file: binary mode ignores port encoding"
>    (with-fluids ((%default-port-encoding "UTF-8"))
>                 (let* ((filename (test-file))
> -                      (port (open-file filename "w"))
> +                      (port (open-file filename "wb"))
>                        (test-string "一二三")
>                        (binary-test-string
>                         (apply string
> @@ -257,7 +257,7 @@
>  (pass-if "file: binary mode ignores file coding declaration"
>    (with-fluids ((%default-port-encoding "UTF-8"))
>                 (let* ((filename (test-file))
> -                      (port (open-file filename "w"))
> +                      (port (open-file filename "wb"))
>                        (test-string "一二三")
>                        (binary-test-string
>                         (apply string

I already tried that, and it doesn't work.  You cannot have a port
that is both UTF-8 encoded and open in binary mode, because Guile will
try to encode characters in 8859-1, and fail (because the characters
used here are not Latin-1 characters).

IOW, binary I/O cannot be encoded.

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

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, ludo@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 launched at exit, which I found surprising.

Since launching a signal delivery thread hangs even if it happens
early in the program run, like as result of

  (sigaction SIGINT)

I looked closer at what happens when that thread starts.  What I found
is this:

    - scm_spawn_thread calls scm_i_pthread_create

    - a new thread is created running the spawn_thread function, and
      GDB announces the new thread

    - spawn_thread calls scm_i_pthread_detach, which calls
      pthread_detach, which in turn calls pthread_mutex_lock, which
      hangs inside WaitForSingleObjectEx

    - scm_spawn_thread waits inside scm_i_scm_pthread_cond_wait for
      the thread to release the conditional variable, which never
      happens.  So guile waits forever, a.k.a. "hangs".

According to this part of pthread_detach:

     if (result == 0)
       {
	 /* Thread is joinable */

	 if (destroyIt)
	   {
	     /* The thread has exited or is exiting but has not been joined or
	      * detached. Need to wait in case it's still exiting.
	      */
	     (void) WaitForSingleObject(tp->threadH, INFINITE);
	     ptw32_threadDestroy (thread);
	   }
       }

it seems like pthreads thinks that the thread has exited or is
exiting.  But if the thread really exited, for whatever reasons, why
doesn't WaitForSingleObject return?

Does this ring a bell for someone?

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@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 there are functions for that, but I
> > found no description of how they are supposed to be used.  What am I
> > missing?
> 
> 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
repository.  So I never found it before.

May I suggest to make it part of the release tarball?

Also, as none of the commands defined on gdbinit are documented in any
shape or form, could you perhaps say a few words about the purpose and
the intended usage of each one of them?  E.g., when to use 'pp' and
when to use 'gdisplay' or 'gwrite' or 'sputs'?  And what are 'pslot'
and 'gslot' good for?

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

[Julian Graham]

Hi Mark and Eli,


On Tue, Jun 18, 2013 at 5:51 PM, Mark H Weaver <mhw@netris.org> 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 would that guess that "it"
> is the signal handling thread, but how could we be shutting down that
> thread if it hadn't yet been launched?

My memories a bit foggy (and I won't be able to take a deep dive into
the code until I get home from work), but my recollection is that
there was something slightly dangerous about calling
`scm_i_close_signal_pipe' if the signal handling thread hadn't been
launched, since if it launched during shutdown it would hang. (See my
comments in `scm_i_close_signal_pipe' to that effect.) So I think I
opted to start it explicitly to avoid this possibility. Admittedly
it's not terribly elegant.

Does that help?


Regards,
Julian

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

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Eli Zaretskii <eliz@gnu.org> 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 I found surprising.
>
>> and why is it launched at exit?
>
> Good question.  This behavior was apparently introduced in this commit:
>
>   http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2e77f7202b11ad0003831fcff94ec7db80cca015

See also:

  http://lists.gnu.org/archive/html/guile-devel/2011-06/msg00034.html

HTH,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Eli Zaretskii <eliz@gnu.org> 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 you
>>> added show this (note the \r at the end):
>>>
>>>      ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>>      FAIL: ports.test: file: binary mode ignores port encoding
>>>      
>>>      ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>>      FAIL: ports.test: file: binary mode ignores file coding declaration
>>
>> 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/rdelim.c
>> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>>  	    {
>>  	    case EOF:
>>  	    case '\n':
>> +	    case '\r':
>>  	      delim = buf[index];
>>  	      break;
>>  
>>
>> Probably the extra case should be #ifdef __MINGW32__, to make sure it
>> has no effect on non-Windows users.  Thoughts?
>
> I think this is a bad idea for multiple reasons:

Well yes, agreed on all points.

I think now we just need to augments ports with CR/LF handling in 2.1.

[...]

> To my mind, this is a bug in those tests.  So how about the following
> patch instead?

[...]

> 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/ports.test
> @@ -238,7 +238,7 @@
>  (pass-if "file: binary mode ignores port encoding"
>    (with-fluids ((%default-port-encoding "UTF-8"))
>                 (let* ((filename (test-file))
> -                      (port (open-file filename "w"))
> +                      (port (open-file filename "wb"))
>                        (test-string "一二三")
>                        (binary-test-string
>                         (apply string
> @@ -257,7 +257,7 @@
>  (pass-if "file: binary mode ignores file coding declaration"
>    (with-fluids ((%default-port-encoding "UTF-8"))
>                 (let* ((filename (test-file))
> -                      (port (open-file filename "w"))
> +                      (port (open-file filename "wb"))
>                        (test-string "一二三")
>                        (binary-test-string
>                         (apply string

Yes, looks good.

The tests would actually make more sense if %default-port-encoding was
set to something different from UTF-8, because here we can’t tell if
it’s ignored.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@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 support UTF-8, and so at
>> > least the stand-alone Info reader will show a lot of garbage on
>> > Windows.  I suggest to use --disable-encoding for the MinGW build.
>> 
>> The problem is that the tarball comes with a .info file so that users
>> don’t need to have makeinfo installed (as per the GCS).
>
> 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 such a bad idea).  But at
> least rebuilding docs could then DTRT.

Well that’s something Windows users can always do manually anyway.  How
could Guile’s build system be of any help?

Ludo’.

Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@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
> repository.  So I never found it before.
>
> May I suggest to make it part of the release tarball?

Will do.

> Also, as none of the commands defined on gdbinit are documented in any
> shape or form, could you perhaps say a few words about the purpose and
> the intended usage of each one of them?

Keep in mind

> E.g., when to use 'pp' and when to use 'gdisplay' or 'gwrite' or
> 'sputs'?

It’s like the Scheme procedures pretty-print, display, write, and
scm_puts.

> And what are 'pslot' and 'gslot' good for?

Ah ah, good question.  I guess they print/access a struct slot.

Thanks,
Ludo’.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@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 such a bad idea).  But at
> > least rebuilding docs could then DTRT.
> 
> Well that’s something Windows users can always do manually anyway.  How
> could Guile’s build system be of any help?

Add the --disable-encoding switch to makeinfo when the host is MinGW.

Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii <eliz@gnu.org>,  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/ports.test
> > @@ -238,7 +238,7 @@
> >  (pass-if "file: binary mode ignores port encoding"
> >    (with-fluids ((%default-port-encoding "UTF-8"))
> >                 (let* ((filename (test-file))
> > -                      (port (open-file filename "w"))
> > +                      (port (open-file filename "wb"))
> >                        (test-string "一二三")
> >                        (binary-test-string
> >                         (apply string
> > @@ -257,7 +257,7 @@
> >  (pass-if "file: binary mode ignores file coding declaration"
> >    (with-fluids ((%default-port-encoding "UTF-8"))
> >                 (let* ((filename (test-file))
> > -                      (port (open-file filename "w"))
> > +                      (port (open-file filename "wb"))
> >                        (test-string "一二三")
> >                        (binary-test-string
> >                         (apply string
> 
> Yes, looks good.

But this doesn't work.  You get "???" in the file, because binary
ports cannot have encoding.  As I wrote, I tried that, and when it
didn't work, debugged it and saw that this is simply not supported
(the docs say as much).  What am I missing?