* Re: Any New Guile Release Planned ?
2015-10-27 17:54 ` Ludovic Courtès
@ 2015-10-28 16:58 ` Barry Schwartz
2015-10-28 17:17 ` David Michael
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Barry Schwartz @ 2015-10-28 16:58 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guile-user
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-27 17:54 ` Ludovic Courtès
2015-10-28 16:58 ` Barry Schwartz
@ 2015-10-28 17:17 ` David Michael
2015-10-29 22:48 ` Ludovic Courtès
2015-10-28 18:15 ` Vladimir Zhbanov
2015-10-29 22:53 ` Mike Gran
3 siblings, 1 reply; 18+ messages in thread
From: David Michael @ 2015-10-28 17:17 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guile-user@gnu.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-27 17:54 ` Ludovic Courtès
2015-10-28 16:58 ` Barry Schwartz
2015-10-28 17:17 ` David Michael
@ 2015-10-28 18:15 ` Vladimir Zhbanov
2015-10-29 15:19 ` Ludovic Courtès
2015-10-29 16:39 ` Eli Zaretskii
2015-10-29 22:53 ` Mike Gran
3 siblings, 2 replies; 18+ messages in thread
From: Vladimir Zhbanov @ 2015-10-28 18:15 UTC (permalink / raw)
To: guile-user
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-28 18:15 ` Vladimir Zhbanov
@ 2015-10-29 15:19 ` Ludovic Courtès
2015-11-02 12:10 ` Vladimir Zhbanov
2015-10-29 16:39 ` Eli Zaretskii
1 sibling, 1 reply; 18+ messages in thread
From: Ludovic Courtès @ 2015-10-29 15:19 UTC (permalink / raw)
To: guile-user
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’.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-29 15:19 ` Ludovic Courtès
@ 2015-11-02 12:10 ` Vladimir Zhbanov
2015-11-02 13:42 ` Ludovic Courtès
2015-11-02 15:40 ` Eli Zaretskii
0 siblings, 2 replies; 18+ messages in thread
From: Vladimir Zhbanov @ 2015-11-02 12:10 UTC (permalink / raw)
To: guile-user
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-11-02 12:10 ` Vladimir Zhbanov
@ 2015-11-02 13:42 ` Ludovic Courtès
2015-11-03 9:27 ` Vladimir Zhbanov
2015-11-02 15:40 ` Eli Zaretskii
1 sibling, 1 reply; 18+ messages in thread
From: Ludovic Courtès @ 2015-11-02 13:42 UTC (permalink / raw)
To: Vladimir Zhbanov; +Cc: guile-user
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’.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-11-02 13:42 ` Ludovic Courtès
@ 2015-11-03 9:27 ` Vladimir Zhbanov
0 siblings, 0 replies; 18+ messages in thread
From: Vladimir Zhbanov @ 2015-11-03 9:27 UTC (permalink / raw)
To: guile-user
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-11-02 12:10 ` Vladimir Zhbanov
2015-11-02 13:42 ` Ludovic Courtès
@ 2015-11-02 15:40 ` Eli Zaretskii
1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2015-11-02 15:40 UTC (permalink / raw)
To: Vladimir Zhbanov; +Cc: guile-user
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-28 18:15 ` Vladimir Zhbanov
2015-10-29 15:19 ` Ludovic Courtès
@ 2015-10-29 16:39 ` Eli Zaretskii
2015-11-02 12:21 ` Vladimir Zhbanov
1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2015-10-29 16:39 UTC (permalink / raw)
To: Vladimir Zhbanov; +Cc: guile-user
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-29 16:39 ` Eli Zaretskii
@ 2015-11-02 12:21 ` Vladimir Zhbanov
2015-11-02 15:42 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Vladimir Zhbanov @ 2015-11-02 12:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: guile-user
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.)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-11-02 12:21 ` Vladimir Zhbanov
@ 2015-11-02 15:42 ` Eli Zaretskii
2015-11-03 14:29 ` Vladimir Zhbanov
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2015-11-02 15:42 UTC (permalink / raw)
To: Vladimir Zhbanov; +Cc: guile-user
> 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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-11-02 15:42 ` Eli Zaretskii
@ 2015-11-03 14:29 ` Vladimir Zhbanov
0 siblings, 0 replies; 18+ messages in thread
From: Vladimir Zhbanov @ 2015-11-03 14:29 UTC (permalink / raw)
To: guile-user
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Any New Guile Release Planned ?
2015-10-27 17:54 ` Ludovic Courtès
` (2 preceding siblings ...)
2015-10-28 18:15 ` Vladimir Zhbanov
@ 2015-10-29 22:53 ` Mike Gran
2015-11-05 20:08 ` Ludovic Courtès
3 siblings, 1 reply; 18+ messages in thread
From: Mike Gran @ 2015-10-29 22:53 UTC (permalink / raw)
To: Ludovic Courtès, guile-user@gnu.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread