Any New Guile Release Planned ?

Any New Guile Release Planned ?

[Rafik NACCACHE]

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

Hi,

Is there any new release planned soon?

Rafik

[-- Attachment #2: Type: text/html, Size: 111 bytes --]

Re: Any New Guile Release Planned ?

[Thompson, David]

On Tue, Oct 27, 2015 at 12:37 PM, Rafik NACCACHE
<rafik.naccache@gmail.com> wrote:

> Is there any new release planned soon?

Yes.  A 2.1 pre-release for the upcoming 2.2 release will be coming
out shortly, and a 2.0.12 stable series release is in the works as
well.

- Dave

Re: Any New Guile Release Planned ?

[Ludovic Courtès]

Rafik NACCACHE <rafik.naccache@gmail.com> skribis:

> Is there any new release planned soon?

We’ve been meaning to release 2.0.12, which is mostly bug fixes.
However, we’re still debating on a new API that is introduced here.

Hopefully it’ll be ready soonish!

Besides, Andy Wingo is considering a first release of the 2.1.x unstable
series that will lead to 2.2.

Ludo’.

Re: Any New Guile Release Planned ?

[Barry Schwartz]

Ludovic Courtès <ludo@gnu.org> skribis:
> Rafik NACCACHE <rafik.naccache@gmail.com> skribis:
> 
> > Is there any new release planned soon?
> 
> We’ve been meaning to release 2.0.12, which is mostly bug fixes.
> However, we’re still debating on a new API that is introduced here.
> 
> Hopefully it’ll be ready soonish!
> 
> Besides, Andy Wingo is considering a first release of the 2.1.x unstable
> series that will lead to 2.2.
> 
> Ludo’.

It will be nice not to have to write #ifdefs for SMOBs support
anymore. :) I have been figuring the new foreign objects is what’s
holding up release.

Re: Any New Guile Release Planned ?

[David Michael]

On Tue, Oct 27, 2015 at 1:54 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Rafik NACCACHE <rafik.naccache@gmail.com> skribis:
>
>> Is there any new release planned soon?
>
> We’ve been meaning to release 2.0.12, which is mostly bug fixes.
> However, we’re still debating on a new API that is introduced here.

Could you consider including these Hurd signal definitions in the next release?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21116

The patch there adds all the signals detected on a Hurd system, but if
that's too much to add to a minor release, I'd specifically like to
use SIGLOST.  It's documented with the rest of the glibc signals:

https://www.gnu.org/software/libc/manual/html_mono/libc.html#Operation-Error-Signals

Thanks.

David

Re: Any New Guile Release Planned ?

[Vladimir Zhbanov]

On Tue, Oct 27, 2015 at 06:54:44PM +0100, Ludovic Courtès wrote:
> Rafik NACCACHE <rafik.naccache@gmail.com> skribis:
> 
> > Is there any new release planned soon?
> 
> We’ve been meaning to release 2.0.12, which is mostly bug fixes.

The stable-2.0 guile branch contains changes that some of our users
(that is, users of gEDA/gaf) have been waiting for years, especially
after guile 2.0 became necessary to build our package. I mean those
users who have been waiting for Windows support. (Some of them insist on
moving to using Python instead of Guile these days, since they have been
tired trying to cross-compile with guile-2.0 support.) A while ago I was
eventually able to build our toolkit using only one patch for guile [1]
(almost one-liner, in essence), and several work-around patches for some
of our programs, which can be found at [2] and are actually the same
code blocks (declaring an array and doing its initialisation). I don't
know why the latter patches work (geda-gaf with guile 1.8 worked without
them), however, I am sure the issue is in guile 2.0, though I cannot
even found the culprit by bisecting (because of too many changes in both
guile and geda-gaf repositories). Having said all that, I'd like to see
at least the patch [1] committed before the next guile release in order
to have guile cross-compilation for windows working. Are there any
chances for that?

Thanks,
  Vladimir

[1] https://github.com/vzh/minipack/blob/master/patches/guile/0001-MinGW-build-support.patch
[2] https://github.com/vzh/minipack/tree/master/patches/geda-gaf

Re: Any New Guile Release Planned ?

[Ludovic Courtès]

Vladimir Zhbanov <vzhbanov@gmail.com> skribis:

> On Tue, Oct 27, 2015 at 06:54:44PM +0100, Ludovic Courtès wrote:
>> Rafik NACCACHE <rafik.naccache@gmail.com> skribis:
>> 
>> > Is there any new release planned soon?
>> 
>> We’ve been meaning to release 2.0.12, which is mostly bug fixes.
>
> The stable-2.0 guile branch contains changes that some of our users
> (that is, users of gEDA/gaf) have been waiting for years, especially
> after guile 2.0 became necessary to build our package. I mean those
> users who have been waiting for Windows support. (Some of them insist on
> moving to using Python instead of Guile these days, since they have been
> tired trying to cross-compile with guile-2.0 support.) A while ago I was
> eventually able to build our toolkit using only one patch for guile [1]
> (almost one-liner, in essence), and several work-around patches for some
> of our programs, which can be found at [2] and are actually the same
> code blocks (declaring an array and doing its initialisation). I don't
> know why the latter patches work (geda-gaf with guile 1.8 worked without
> them), however, I am sure the issue is in guile 2.0, though I cannot
> even found the culprit by bisecting (because of too many changes in both
> guile and geda-gaf repositories). Having said all that, I'd like to see
> at least the patch [1] committed before the next guile release in order
> to have guile cross-compilation for windows working. Are there any
> chances for that?

Sure, we’ll do our best.

> [1] https://github.com/vzh/minipack/blob/master/patches/guile/0001-MinGW-build-support.patch

Could you explain the details?  An excerpt of the build log when
cross-compiling to MinGW without the patch would be great.

The reason I ask is that we rely on Gnulib for these portability
things.  The <sys/select.h> in libguile/iselect.h is supposed to do the
right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
fix the problem in Gnulib if it’s still there.

Thanks,
Ludo’.

Re: Any New Guile Release Planned ?

[Eli Zaretskii]

> Date: Wed, 28 Oct 2015 21:15:33 +0300
> From: Vladimir Zhbanov <vzhbanov@gmail.com>
> 
> The stable-2.0 guile branch contains changes that some of our users
> (that is, users of gEDA/gaf) have been waiting for years, especially
> after guile 2.0 became necessary to build our package. I mean those
> users who have been waiting for Windows support. (Some of them insist on
> moving to using Python instead of Guile these days, since they have been
> tired trying to cross-compile with guile-2.0 support.) A while ago I was
> eventually able to build our toolkit using only one patch for guile [1]
> (almost one-liner, in essence), and several work-around patches for some
> of our programs, which can be found at [2] and are actually the same
> code blocks (declaring an array and doing its initialisation). I don't
> know why the latter patches work (geda-gaf with guile 1.8 worked without
> them), however, I am sure the issue is in guile 2.0, though I cannot
> even found the culprit by bisecting (because of too many changes in both
> guile and geda-gaf repositories). Having said all that, I'd like to see
> at least the patch [1] committed before the next guile release in order
> to have guile cross-compilation for windows working. Are there any
> chances for that?

Just so you and your users know: there's a 32-bit MinGW build of Guile
2.0.x here:

  http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download

Re: Any New Guile Release Planned ?

[Ludovic Courtès]

David Michael <fedora.dm0@gmail.com> skribis:

> Could you consider including these Hurd signal definitions in the next release?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21116
>
> The patch there adds all the signals detected on a Hurd system, but if
> that's too much to add to a minor release,

I think it’s fine, so I pushed this patch and its friends.

Thanks for the heads-up, and sorry for the delay!

Ludo’.

Re: Any New Guile Release Planned ?

[Mike Gran]

On Tuesday, October 27, 2015 10:55 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>Rafik NACCACHE <rafik.naccache@gmail.com> skribis:
>
>> Is there any new release planned soon?
>
>We’ve been meaning to release 2.0.12, which is mostly bug fixes.
>However, we’re still debating on a new API that is introduced here.
>
>Hopefully it’ll be ready soonish!
>
>Besides, Andy Wingo is considering a first release of the 2.1.x unstable
>series that will lead to 2.2.
>
>Ludo’.
>

If someone wanted to regenerate the SRFI-14 charsets for
Unicode 8.0.0 before the next release, that'd be cool.
 
The script is libguile/unidata_to_charset.pl
 
The latest Unicode table is
ftp://unicode.org/Public/UNIDATA/UnicodeData.txt
 
The script regenerates libguile/srfi-14.i.c
 
-Mike

Re: Any New Guile Release Planned ?

[Vladimir Zhbanov]

Ludovic,
sorry for the private mail. I'll repeat it here.

On 10/29/15, Ludovic Courtès <ludo@gnu.org> wrote:
...
> Could you explain the details?  An excerpt of the build log when
> cross-compiling to MinGW without the patch would be great.
>
> The reason I ask is that we rely on Gnulib for these portability
> things.  The <sys/select.h> in libguile/iselect.h is supposed to do the
> right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
> fix the problem in Gnulib if it’s still there.

OK, on my system (Debian jessie (stable)) guile builds well under
MinGW.  However, when I'm trying to compile geda-gaf it complains:

In file included from
/home/user/minipack/result/include/guile/2.0/libguile/threads.h:31:0,
                 from
/home/user/minipack/result/include/guile/2.0/libguile/async.h:29,
                 from
/home/user/minipack/result/include/guile/2.0/libguile.h:37,
                 from ./../include/libgeda_priv.h:4,
                 from scheme_init.c:26:
/home/user/minipack/result/include/guile/2.0/libguile/iselect.h:31:24:
fatal error: sys/select.h: No such file or directory
 #include <sys/select.h>
                        ^
compilation terminated.
make[4]: *** [scheme_init.x] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2

AFAICS, mingw package in Debian has the winsock2.h headers while I
don't see any select.h
  $ locate winsock|grep mingw
  /usr/i686-w64-mingw32/include/winsock2.h
  /usr/share/mingw-w64/include/winsock2.h
  /usr/x86_64-w64-mingw32/include/winsock2.h
  $ locate select.h|grep mingw

I don't know if the issue is in mingw itself or in guile, however
after applying the patch I've mentioned all builds well.

Thanks,
  Vladimir

Re: Any New Guile Release Planned ?

[Vladimir Zhbanov]

Hi Eli,

On 10/29/15, Eli Zaretskii <eliz@gnu.org> wrote:
...
> Just so you and your users know: there's a 32-bit MinGW build of Guile
> 2.0.x here:
>
>
> http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download
>

I know, thanks :)

Thank you for your great work on the guile port for Windows.
Unfortunately your prebuilt version didn't work for me last time I
tried it. Moreover, since our users and developers are mostly
Linux users, we prefer to cross-compile our programs in the Linux
environment rather than using Windows for that.

Thanks,
  Vladimir

(BTW, headers in your email are broken in my MUA, so I couldn't
read it there, while web interface shows it well.)

Re: Any New Guile Release Planned ?

[Ludovic Courtès]

Vladimir Zhbanov <vzhbanov@gmail.com> skribis:

> On 10/29/15, Ludovic Courtès <ludo@gnu.org> wrote:
> ...
>> Could you explain the details?  An excerpt of the build log when
>> cross-compiling to MinGW without the patch would be great.
>>
>> The reason I ask is that we rely on Gnulib for these portability
>> things.  The <sys/select.h> in libguile/iselect.h is supposed to do the
>> right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
>> fix the problem in Gnulib if it’s still there.
>
> OK, on my system (Debian jessie (stable)) guile builds well under
> MinGW.  However, when I'm trying to compile geda-gaf it complains:
>
> In file included from
> /home/user/minipack/result/include/guile/2.0/libguile/threads.h:31:0,
>                  from
> /home/user/minipack/result/include/guile/2.0/libguile/async.h:29,
>                  from
> /home/user/minipack/result/include/guile/2.0/libguile.h:37,
>                  from ./../include/libgeda_priv.h:4,
>                  from scheme_init.c:26:
> /home/user/minipack/result/include/guile/2.0/libguile/iselect.h:31:24:
> fatal error: sys/select.h: No such file or directory
>  #include <sys/select.h>

Could you run ‘make V=1’ and send a bit more of the log, so we can see
the compiler command line?

Thanks,
Ludo’.

Re: Any New Guile Release Planned ?

[Eli Zaretskii]

> Date: Mon, 2 Nov 2015 15:10:15 +0300
> From: Vladimir Zhbanov <vzhbanov@gmail.com>
> 
> > The reason I ask is that we rely on Gnulib for these portability
> > things.  The <sys/select.h> in libguile/iselect.h is supposed to do the
> > right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
> > fix the problem in Gnulib if it’s still there.
> 
> OK, on my system (Debian jessie (stable)) guile builds well under
> MinGW.  However, when I'm trying to compile geda-gaf it complains:
> 
> In file included from
> /home/user/minipack/result/include/guile/2.0/libguile/threads.h:31:0,
>                  from
> /home/user/minipack/result/include/guile/2.0/libguile/async.h:29,
>                  from
> /home/user/minipack/result/include/guile/2.0/libguile.h:37,
>                  from ./../include/libgeda_priv.h:4,
>                  from scheme_init.c:26:
> /home/user/minipack/result/include/guile/2.0/libguile/iselect.h:31:24:
> fatal error: sys/select.h: No such file or directory
>  #include <sys/select.h>
>                         ^
> compilation terminated.
> make[4]: *** [scheme_init.x] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all] Error 2
> 
> AFAICS, mingw package in Debian has the winsock2.h headers while I
> don't see any select.h

MinGW indeed doesn't have sys/select.h, but gnulib, included in Guile,
provides it.

So I think Ludovic is right, and showing the complete compiler command
line will give some hints.  I'm guessing something related to -I
switches or maybe even -isystem.

Re: Any New Guile Release Planned ?

[Eli Zaretskii]

> Date: Mon, 2 Nov 2015 15:21:00 +0300
> From: Vladimir Zhbanov <vzhbanov@gmail.com>
> Cc: guile-user@gnu.org
> 
> > http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download
> >
> 
> I know, thanks :)
> 
> Thank you for your great work on the guile port for Windows.
> Unfortunately your prebuilt version didn't work for me last time I
> tried it.

Strange.  It certainly works for me and others in GDB and in Make (and
of course as a stand-alone interpreter).  It also passes all the
tests.  So I suspect some snafu with the dependent DLLs or some such.

> (BTW, headers in your email are broken in my MUA, so I couldn't
> read it there, while web interface shows it well.)

That's the first time someone complains about that.  Broken how?

Re: Any New Guile Release Planned ?

[Vladimir Zhbanov]

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

On 11/2/15, Ludovic Courtès <ludo@gnu.org> wrote:
...
> Could you run ‘make V=1’ and send a bit more of the log, so we can see
> the compiler command line?

Sure. The full log is attached.

Thanks,
  Vladimir

[-- Attachment #2: log --]
[-- Type: application/octet-stream, Size: 6241 bytes --]

version.h is unchanged
make  all-recursive
make[1]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2'
Making all in intl
make[2]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/intl'
Making all in libgeda
make[2]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda'
Making all in po
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/po'
/bin/mkdir -p ../../.desktop-i18n
make 	  prefix=../../.desktop-i18n 	  localedir=../../.desktop-i18n/share/locale 	  DESTDIR= install && 	cp ./LINGUAS ../../.desktop-i18n/libgeda45.LINGUAS 	|| rm stamp-i18n
make[4]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/po'
/bin/mkdir -p ../../.desktop-i18n/share
installing ar.gmo as ../../.desktop-i18n/share/locale/ar/LC_MESSAGES/libgeda45.mo
installing ca.gmo as ../../.desktop-i18n/share/locale/ca/LC_MESSAGES/libgeda45.mo
installing da.gmo as ../../.desktop-i18n/share/locale/da/LC_MESSAGES/libgeda45.mo
installing de.gmo as ../../.desktop-i18n/share/locale/de/LC_MESSAGES/libgeda45.mo
installing el.gmo as ../../.desktop-i18n/share/locale/el/LC_MESSAGES/libgeda45.mo
installing en_GB.gmo as ../../.desktop-i18n/share/locale/en_GB/LC_MESSAGES/libgeda45.mo
installing es.gmo as ../../.desktop-i18n/share/locale/es/LC_MESSAGES/libgeda45.mo
installing fr.gmo as ../../.desktop-i18n/share/locale/fr/LC_MESSAGES/libgeda45.mo
installing hu.gmo as ../../.desktop-i18n/share/locale/hu/LC_MESSAGES/libgeda45.mo
installing it.gmo as ../../.desktop-i18n/share/locale/it/LC_MESSAGES/libgeda45.mo
installing nl.gmo as ../../.desktop-i18n/share/locale/nl/LC_MESSAGES/libgeda45.mo
installing pl.gmo as ../../.desktop-i18n/share/locale/pl/LC_MESSAGES/libgeda45.mo
installing pt.gmo as ../../.desktop-i18n/share/locale/pt/LC_MESSAGES/libgeda45.mo
installing pt_BR.gmo as ../../.desktop-i18n/share/locale/pt_BR/LC_MESSAGES/libgeda45.mo
installing ru.gmo as ../../.desktop-i18n/share/locale/ru/LC_MESSAGES/libgeda45.mo
installing sr.gmo as ../../.desktop-i18n/share/locale/sr/LC_MESSAGES/libgeda45.mo
installing sv.gmo as ../../.desktop-i18n/share/locale/sv/LC_MESSAGES/libgeda45.mo
installing tr.gmo as ../../.desktop-i18n/share/locale/tr/LC_MESSAGES/libgeda45.mo
installing uk.gmo as ../../.desktop-i18n/share/locale/uk/LC_MESSAGES/libgeda45.mo
installing zh_CN.gmo as ../../.desktop-i18n/share/locale/zh_CN/LC_MESSAGES/libgeda45.mo
installing zh_TW.gmo as ../../.desktop-i18n/share/locale/zh_TW/LC_MESSAGES/libgeda45.mo
if test "geda-gaf" = "gettext-tools"; then \
	  /bin/mkdir -p ../../.desktop-i18n/share/gettext/po; \
	  for file in Makefile.in.in remove-potcdate.sin quot.sed boldquot.sed en@quot.header en@boldquot.header insert-header.sin Rules-quot   Makevars.template; do \
	    /usr/bin/install -c -m 644 ./$file \
			    ../../.desktop-i18n/share/gettext/po/$file; \
	  done; \
	  for file in Makevars; do \
	    rm -f ../../.desktop-i18n/share/gettext/po/$file; \
	  done; \
	else \
	  : ; \
	fi
make[4]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/po'
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/po'
Making all in data
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/data'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/data'
Making all in docs
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs'
Making all in images
make[4]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs/images'
Type: make images  to create all the png/pdf images
make[4]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs/images'
make[4]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs'
Type: make doxygen  to create doxygen documentation for libgeda
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/docs'
Making all in include
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/include'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/include'
Making all in lib
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/lib'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/lib'
Making all in src
make[3]: Entering directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/src'
CPP="i686-w64-mingw32-gcc -E" guile-snarf -o scheme_init.x scheme_init.c -DHAVE_CONFIG_H -I. -I../..   -DLOCALEDIR=\"/home/user/minipack/result/share/locale\"   -I./../include -I./../include/libgeda -I../..  -Wall   -I/home/user/minipack/result/include/guile/2.0 -I/home/user/minipack/result/include   -mms-bitfields -I/home/user/minipack/result/include/glib-2.0 -I/home/user/minipack/result/lib/glib-2.0/include   -mms-bitfields -I/home/user/minipack/result/include/gdk-pixbuf-2.0 -I/home/user/minipack/result/include/libpng14 -I/home/user/minipack/result/include/glib-2.0 -I/home/user/minipack/result/lib/glib-2.0/include  
In file included from /home/user/minipack/result/include/guile/2.0/libguile/threads.h:31:0,
                 from /home/user/minipack/result/include/guile/2.0/libguile/async.h:29,
                 from /home/user/minipack/result/include/guile/2.0/libguile.h:37,
                 from ./../include/libgeda_priv.h:4,
                 from scheme_init.c:26:
/home/user/minipack/result/include/guile/2.0/libguile/iselect.h:31:24: fatal error: sys/select.h: No such file or directory
 #include <sys/select.h>
                        ^
compilation terminated.
make[3]: *** [scheme_init.x] Error 1
make[3]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2/libgeda'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/build/geda-gaf-1.9.2-1/geda-gaf-1.9.2'
make: *** [all] Error 2

Re: Any New Guile Release Planned ?

[Vladimir Zhbanov]

On Mon, Nov 02, 2015 at 05:42:46PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 2 Nov 2015 15:21:00 +0300
> > From: Vladimir Zhbanov <vzhbanov@gmail.com>
> > Cc: guile-user@gnu.org
> > 
> > > http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download
> > >
> > 
> > I know, thanks :)
> > 
> > Thank you for your great work on the guile port for Windows.
> > Unfortunately your prebuilt version didn't work for me last time I
> > tried it.
> 
> Strange.  It certainly works for me and others in GDB and in Make (and
> of course as a stand-alone interpreter).  It also passes all the
> tests.  So I suspect some snafu with the dependent DLLs or some such.

Perhaps, I used not correct enough words to formulate my thoughts.
I cannot remember all details since I've done too many various
attempts to build my package and used various library versions for
various dependencies to find a workable configuration. Your pre-built
version of guile worked well by itself, though I still could not make my
package work with libguile. AFAIR, amongst things I tried to make it work,
was just replacing the libguile DLL built by me with your version. It
didn't work, too, probably due to the same GC issues in the Windows
guile build appeared in version 2.0 (guile-1.8 worked well), workaround
for which I found much later.

Thanks,
  Vladimir

Re: Any New Guile Release Planned ?

[Ludovic Courtès]

Mike Gran <spk121@yahoo.com> skribis:

> If someone wanted to regenerate the SRFI-14 charsets for
> Unicode 8.0.0 before the next release, that'd be cool.

Done in c028c64.  Thanks!

Ludo’.