Interest in windows native port, interpreters for other languages and C++ binding API.

Interest in windows native port, interpreters for other languages and C++ binding API.

[Germán Diago]

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

Hello everyone,

WARNING: I cannot commit to any of the work below but I would try to do a
build system port if that makes sense.

I have been trying guile for a while lately (again). So far, so great!
Congratulations for this amazing piece of software. I am interested in
making real use of it in two main areas: as a general scripting engine and
for embedding in games.

Racket is also very mature and very good as a platform, but I would like to
put my effort in helping in guile maybe, especially because I use it as an
alternative to python and because guile supports native threads.

Here my questions:


1. As a general scripting engine, even if I love scheme, I know people do
not use it much, so this becomes kind of a social problem in team usage:
what is the status and roadmap to port: javascript, lua and python? I would
like to be able to use as an alternative inside guile. What is the effort
to complete javascript (I think it was started) in man-hours?

2. Windows works under POSIX. What would be the effort of doing a port to
native windows threads? Effort in man-hours?
3. Is there any interest in switching to meson build system? I think that
it works very well already and supports windows much better than autotools.
I have used it myself and it is improving day by day. I think it would be
reasonable to do 2. and 3. together if there is will. I could help
converting the project to meson as experimental myself.  Effort in
man-hours?

4. Interoperability: I was planning at some point, but I do not know if I
will find the time, to find a painless (as painless as Chaiscript for
example) way to bind scheme to C++ directly (not C), because it is the main
language I make use of. So maybe I could make use of the native bindings
and put a thin layer on top of it. Right now it makes a lot of sense for me
as a C API but I find it too verbose to use from C++: in C++ maybe I could
do better, something more similar to Chaiscript or
https://github.com/pybind/pybind11.


All this said, I am kind of a rookie still in scheme, but I am enjoying it
like no other dynamic language before :)

I would like to see guile succeed and I think that supporting more
languages is critical given that scheme's popularity is not as big as
python's or javascript's, but it is still possible to do so much more in
guile that I would not like to lose the chance to use it.

Thanks for your time.

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

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Eli Zaretskii]

> From: Germán Diago <germandiago@gmail.com>
> Date: Tue, 31 Jan 2017 11:28:50 +0700
> 
> 2. Windows works under POSIX. What would be the effort of doing a port to native windows threads? Effort in
> man-hours?

I've built native Windows port of Guile 2.0.x, you can find the
binaries here:

  http://sourceforge.net/projects/ezwinports/files/

However, building Guile with threads (using pthreads) on Windows
produces a broken binary which cannot even compile the *.scm files as
part of the build: it crashes a lot.  I don't know what causes this,
but I reported the details a few years ago, and you should be able to
find them in the archives.  The binaries whose URL is above are
compiled without threads.

> 3. Is there any interest in switching to meson build system? I think that it works very well already and supports
> windows much better than autotools.

Not my place to answer that, but let me just say that I didn't have
any problems using the present autotools-based build system on
Windows with MSYS.  The absolute majority of the problems I needed to
solve while working on the port had nothing to do with autotools, but
with various non-portable and Posix-centric stuff in the Guile sources
(most of them were fixed since then using the patches I proposed).

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Germán Diago]

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

2017-01-31 22:29 GMT+07:00 Eli Zaretskii <eliz@gnu.org>:

>
>
> Not my place to answer that, but let me just say that I didn't have
> any problems using the present autotools-based build system on
> Windows with MSYS.  The absolute majority of the problems I needed to
> solve while working on the port had nothing to do with autotools, but
> with various non-portable and Posix-centric stuff in the Guile sources
> (most of them were fixed since then using the patches I proposed).
>

Well, provided that you are tied to msys and you can never ever compile
guile with a microsoft compiler, that is ok. You are talking only about
your use case. The reality is quite different: if you want windows
adoption, you need to use the native toolchain to compile. I have extensive
experience with cmake and autotools and quite a bit with meson already. I
can say with confidence that keeping autotools and taking windows seriously
at the same time is just impossible. So my view here is that to have a
decent windows port we would need native windows threads and compile with
microsoft compiler (that is why I would be proposing meson). You just have
to see the gstreamer guys experience when switching to meson and the huge
improvement it was, especially in windows.

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

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Eli Zaretskii]

> From: Germán Diago <germandiago@gmail.com>
> Date: Wed, 1 Feb 2017 12:18:28 +0700
> Cc: guile-devel@gnu.org
> 
> Well, provided that you are tied to msys and you can never ever compile guile with a microsoft compiler, that
> is ok. You are talking only about your use case. The reality is quite different: if you want windows adoption, you
> need to use the native toolchain to compile.

MSYS is used only to run Bash, m4, perl, etc.  -- programs that are
invoked during the configure stage and by shell script fragments in
the Makefile.  The compiler is MinGW, not MSYS.  MinGW produces native
executables that are completely compatible with MSVC compiled
programs.  So I don't see a problem here, or any need to use non-free compilers.

> I can say with confidence that keeping autotools and taking windows seriously at the
> same time is just impossible.

That's definitely not my experience.

> So my view here is that to have a decent windows port we would need native
> windows threads and compile with microsoft compiler

MinGW supports native Windows threads, and in fact the ported pthreads
are just a very thin wrapper around native threads.

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[David Kastrup]

Germán Diago <germandiago@gmail.com> writes:

> 2017-01-31 22:29 GMT+07:00 Eli Zaretskii <eliz@gnu.org>:
>
>>
>>
>> Not my place to answer that, but let me just say that I didn't have
>> any problems using the present autotools-based build system on
>> Windows with MSYS.  The absolute majority of the problems I needed to
>> solve while working on the port had nothing to do with autotools, but
>> with various non-portable and Posix-centric stuff in the Guile sources
>> (most of them were fixed since then using the patches I proposed).
>>
>
> Well, provided that you are tied to msys and you can never ever compile
> guile with a microsoft compiler, that is ok. You are talking only about
> your use case. The reality is quite different: if you want windows
> adoption, you need to use the native toolchain to compile. I have extensive
> experience with cmake and autotools and quite a bit with meson already. I
> can say with confidence that keeping autotools and taking windows seriously
> at the same time is just impossible.

The GNU project does not actually take "Windows seriously" to the degree
that it demands using a non-free compiler chain.

I can only agree about half with your assessment: I can say with
confidence that taking Windows seriously at the same time as GNU/Linux
and other unixy platforms is only possible with a permanent serious
drain of resources.

GNU LilyPond does not take Windows seriously.  It does not even try to
make it compile with proprietary compilers.  Instead it uses a huge
crosscompiling setup to release binary packages simultaneously for
Windows, MacOSX (also on PowerPC), several GNU/Linux and FreeBSD
variants, about every 2 weeks.

Development can only be done sensibly on GNU/Linux, we provide a virtual
Ubuntu environment with the necessary packages installed.

A large percentage of Lilypond's user base and about 80% of its
"supporting staff" (servers, regression tests, bug handling etc) use
Windows.

Developer mindshare invested into Windows is zero, unless the porting
machine breaks.  Which happens every few years on average, requiring
updates for the crosscompiled libraries or crosscompiling compilers.

Both what Eli calls serious Windows support of Emacs (and if you take a
look at his commits in that area, it does not really deserve any other
name) as well as what, say, projects like Git invest as a permanent
drain of developer energy and fun into supporting Windows are way more
effort than LilyPond spends here.

> So my view here is that to have a decent windows port we would need
> native windows threads and compile with microsoft compiler (that is
> why I would be proposing meson). You just have to see the gstreamer
> guys experience when switching to meson and the huge improvement it
> was, especially in windows.

If you don't want a permanent fixture of developers to non-free
platforms, that is not my experience.  For an inherently GUI-bound
program like Emacs, of course crosscompilation would not answer _all_
questions.  You still need all the relevant surface-dependent code, of
course.  And debugging _that_ when the only sensible user-accessible way
is to wait for the fortnightly monster crosscompilation run is not an
option.

But you really cannot maintain one large project sensibly under two
fundamentally different toolchains.  Particularly not a GNU-relevant one
that will want to be able to access a number of UNIX-typical facilities
and programs in order not to degress into what programming was before
the seventies.

-- 
David Kastrup

Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[Germán Diago]

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

El El mié, 1 feb 2017 a las 19:56, Eli Zaretskii <eliz@gnu.org> escribió:

> > From: Germán Diago <germandiago@gmail.com>
> > Date: Wed, 1 Feb 2017 12:18:28 +0700
> > Cc: guile-devel@gnu.org
> >
> > Well, provided that you are tied to msys and you can never ever compile
> guile with a microsoft compiler, that
> > is ok. You are talking only about your use case. The reality is quite
> different: if you want windows adoption, you
> > need to use the native toolchain to compile.
>
> MSYS is used only to run Bash, m4, perl, etc.  -- programs that are
> invoked during the configure stage and by shell script fragments in
> the Makefile.  The compiler is MinGW, not MSYS.  MinGW produces native
> executables that are completely compatible with MSVC compiled
> programs.  So I don't see a problem here, or any need to use non-free
> compilers.


Good to hear it is compatible at least. I do not see the  point in blocking
users to use the compiler of their choice as long as you can still use your
free compiler. Autotools is slow in windows as well I say this by own
experience. Anyway I do not wanna get into ideological fights. If you are
not willing to take positively suggestions and possible collaborations for
potentially improving adoption, I do not wanna stay in your way. I think
this attitude will harm more than benefit the project.


> MinGW supports native Windows threads, and in fact the ported pthreads
> are just a very thin wrapper around native threads.


This is not how most users use a setup in windows no matter how much we
whine. This will prevent adoption. So if you want my help, I am still
available. As I said, my proposal does not prevent you from using MinGW.

Thanks for your time.

>

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