Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

Hi Mike,

I was able to build a 64-bit libguile 3 based on the branch 
wip-mingw. It appears to be working fine so far, and I am grateful 
for your work.


The only glitch I have found is that (gettimeofday) does not 
return correct values. It should return a pair (seconds . 
microseconds). The seconds part is correct, but the microseconds 
are often greater than 100, and can even be negative.


I am not sure how to fix it, but I believe I have found the root 
cause of the problem. The mingw implementation of the timeval 
struct is:


struct timeval
{
long tv_sec;
long tv_usec;
};

But the file guile/lib/sys/time.h replaces it with that:

struct timeval
{
 time_t tv_sec;
 long int tv_usec;
};

long is 32-bit on Windows, and time_t is 64-bit. When 
scm_gettimeofday calls gettimeofday(), that function expects a 
timeval with two longs, and the seconds and microseconds end up in 
the low and high parts of tv_sec. When scm_from_long is called on 
tv_sec, the 64-bit value is truncated, and the seconds are 
correctly converted. When converting the tv_usec member, however, 
we only get what happend to be there on the stack.


I have found a test in guile/m4/sys_time_h.m4 that enables the 
timeval replacement mentioned above when sizeof(tv_sec) is smaller 
than sizeof(time_t), with this accompanying comment:


On native Windows with a 64-bit 'time_t', 'struct timeval' is 
defined
(in  and  for mingw64, in  
only

for MSVC) with a tv_sec field of type 'long' (32-bit!), which is
smaller than the 'time_t' type mandated by POSIX.
On OpenBSD 5.1 amd64, tv_sec is 64 bits and time_t 32 bits, but
that is good enough.

So I am left wondering how it is supposed to work if the timeval 
is replaced with members of a different size. Is scm_gettimeofday 
not calling the correct version of gettimeofday?



Another question. Are there more issues I can expect, while 
working with this wip-mingw branch? The name suggests it is not 
finished yet.


Regards,
Thomas Thiriez

Mike Gran  writes:


On Tue, Nov 22, 2022 at 01:44:47PM +0100, Jean Abou Samra wrote:


> Now, it is possible that the problem is that I am trying to 
> run a
> .go file compiled on macOS on a Windows machine, and that the 
> two
> platforms are different enough that the .go file can't be 
> reused.
> And because I get that "Value out of range" error when 
> compiling

> on Windows, I am probably stuck with .scm files instead of
> compiled .go files.


This bug is now hitting us too, we're investigating it here:

https://gitlab.com/lilypond/lilypond/-/issues/6474

Best,
Jean




For what it is worth, I do have functional 64-bit Guile 3.0.x 
for
Windows at the link below, but that tree is still full of 
missteps and
experiments and needs to made into a cleaner patchset.  And I'm 
still

actively hacking there because I'm trying to a Guile that, once
installed, lives in a single directory like most Windows 
applications

so I can make an MSIX installer. So it is a bit of a mess, but,
I'm fairly confident the integers are fixed.

https://github.com/spk121/guile/commits/wip-mingw-bleh

That tree was based on, and will eventually contribute
back to

https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw

Both of these trees require that you  --enable-mini-gmp 
--enable-jit=no and --disable-lto at configure time.


Regards,
Mike Gran

Re: [EXT] relocatable guile on windows

[Mike Gran]

On Wed, Dec 07, 2022 at 08:55:10AM -0500, Thompson, David wrote:
> Hi Mike,
> 
> On Sat, Dec 3, 2022 at 9:49 PM Mike Gran  wrote:
> >
> It would be really great if we could organize a bit around upstreaming
> patches for proper Windows support and come up with some documentation
> with official recommendations for how to build for Windows.  I never
> know what the best approach is: cygwin? mingw? native build (more work
> than the other two)?  A lot of other Scheme implementations run on
> Windows, so Guile should, too.

Cygwin is basically and emulated POSIX layer using a C library
(newlib) that is fairly similar to GNU libc.  Guile builds and works
fine with Cygwin already.  The disadvange to Cygwin is that graphical
programs in cygwin require an X server, so they are a bit slow to run
and quite difficult to package up without requiring a downstream user
to get all of Cygwin.

MinGW is basically GCC plus a C library that is definitely not POSIX:
UCRT or MSVCRT, the native Windows libraries.  The result is a native
Windows app.  It comes with just enough of a shell to run autotools.

Native windows using Microsoft's C compiler is always tough because
autotools doesn't support it without extreme gymnastics.  It works
better for CMake programs. I haven't attempted it. It has some quirks
like the lack of #include_next that gnulib depends on.

The long integer patch is the most important and most disruptive if we
want 64-bit windows support.  We have to start there, and everything
descends from that. I'm not sure how to gather support for that.

Regards,
Mike Gran

Re: relocatable guile on windows

[Mike Gran]

On Thu, Dec 08, 2022 at 06:56:44AM +0100, Janneke Nieuwenhuizen wrote:
> Mike Gran writes:
> 
> Hi!
> 
> > Almost all instances of the long integer are replaced with intptr_t,
> > since on 64-bit Windows, sizeof(long) < sizeof(void *), in violation
> > of Guile's expectations.  Largely janneke did this work, but, I added
> > a couple more.
> 
> Now that you found more, do you know if JIT works?  I couldn't get it to
> work on wip-mingw, so I've been using --disable-jit.

Sorry, I didn't even look into the lightening directory or try to
patch it.  I just assumed that JIT would be too compilicated
for me to understand.

A recompile with JIT enabled seems to fail almost immediately.

Regards,
Mike Gran

Re: relocatable guile on windows

[Janneke Nieuwenhuizen]

Mike Gran writes:

Hi!

> For reasons why you shouldn't use Microsoft Windows ever, see:
> https://www.gnu.org/philosophy/upgrade-windows.html

Right.  No-one in their right mind should ever use Windows.  Sadly,
people even pay for this stuff.

Having said that, great work!

> Almost all instances of the long integer are replaced with intptr_t,
> since on 64-bit Windows, sizeof(long) < sizeof(void *), in violation
> of Guile's expectations.  Largely janneke did this work, but, I added
> a couple more.

Now that you found more, do you know if JIT works?  I couldn't get it to
work on wip-mingw, so I've been using --disable-jit.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: [EXT] relocatable guile on windows

[Thompson, David]

Hi Mike,

On Sat, Dec 3, 2022 at 9:49 PM Mike Gran  wrote:
>
> Hello Guile,
>
> The Lisp Game Jam was a few weeks ago, and in prep, I took a stab an
> making Guile work better on Windows, using MinGW MSys64 UCRT64 for
> compilation. Little did I imagine that it would take a couple months
> to make something servicable, so I never got around to actually making
> a game.
>
> This Guile is a fork with a lot of hacks for Windows: lack of
> POSIX shell, DLL nonsense, Windows filesystem instead of FHS,
> yadda yadda yadda.  The biggest hack is that of making
> all the file paths relative to the guile executable, so that
> it can be distributed as a single zip file or MSIX install file.

I haven't had a chance to try this out yet but I wanted to say that
this is great work!  I'd really like to have a good story to tell for
shipping games built with Guile and Chickadee on Windows.  In the past
I've tried to cross-compile Guile for Windows from Linux and made it
as far as getting Guile 3 to boot, but the JIT didn't work and I think
threads, though enabled, were broken.  I haven't used Windows for
development in over 10 years so I'm somewhat helpless when things go
wrong.

It would be really great if we could organize a bit around upstreaming
patches for proper Windows support and come up with some documentation
with official recommendations for how to build for Windows.  I never
know what the best approach is: cygwin? mingw? native build (more work
than the other two)?  A lot of other Scheme implementations run on
Windows, so Guile should, too.

- Dave

Re: relocatable guile on windows

[Dr. Arne Babenhauserheide]

"Dr. Arne Babenhauserheide"  writes:

> Mike Gran  writes:
>> There is a README-win.txt file that explains how you might use it to
>> distribute a game jam game on Windows.
>>
>>   https://github.com/spk121/guile/blob/reloc-package/README-win.txt
>
> This may be just a hack, but it is absolutely awesome!

> It finally solves the problem of getting Guile-tools to Windows-using
> friends. (now I just have to learn how to follow that)

And this sounds like it could make games actually feel like standalone
games:

> The purpose of this is to allow someone to just double-click on the
> Guile executable to launch an app without requiring a shell script.

https://github.com/spk121/guile/blob/reloc-package/README-win.txt

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: relocatable guile on windows

[Vivien Kraus]

Hello,

Le samedi 03 décembre 2022 à 18:48 -0800, Mike Gran a écrit :
> To help deliver a game as a single zip or tar file, a new configure
> option --enable-relative-paths is added.  This installs all of guile
> into the $(prefix)/app directory, and modifies the loading logic to
> search for scheme, compiled scheme, and extension files relative to
> the location of the executable.  The applications and all shared
> object library files are in the root of that directory. 
> $(prefix)/app
> is just a staging directory, and that directory can be renamed and
> relocated.

This is a common problem for all programs, and gnulib has a working
solution for that:
https://www.gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html

Also, this chapter describes a few more things gnulib can do for
windows:
https://www.gnu.org/software/gnulib/manual/html_node/Native-Windows-Support.html

I hope this can help make your work more maintainable.

Best regards,

Vivien

Re: relocatable guile on windows

[Dr. Arne Babenhauserheide]

Mike Gran  writes:
> There is a README-win.txt file that explains how you might use it to
> distribute a game jam game on Windows.
>
>   https://github.com/spk121/guile/blob/reloc-package/README-win.txt

This may be just a hack, but it is absolutely awesome!

It finally solves the problem of getting Guile-tools to Windows-using
friends. (now I just have to learn how to follow that)

Thank you very much!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

relocatable guile on windows

[Mike Gran]

Hello Guile,

The Lisp Game Jam was a few weeks ago, and in prep, I took a stab an
making Guile work better on Windows, using MinGW MSys64 UCRT64 for
compilation. Little did I imagine that it would take a couple months
to make something servicable, so I never got around to actually making
a game.

This Guile is a fork with a lot of hacks for Windows: lack of
POSIX shell, DLL nonsense, Windows filesystem instead of FHS,
yadda yadda yadda.  The biggest hack is that of making
all the file paths relative to the guile executable, so that
it can be distributed as a single zip file or MSIX install file.

There is an MSIX installer and a Zip file of a compiled Guile at

  https://github.com/spk121/guile/releases/tag/3.0.8.1

For reasons why you shouldn't use Microsoft Windows ever, see:
https://www.gnu.org/philosophy/upgrade-windows.html

There is a README-win.txt file that explains how you might use it to
distribute a game jam game on Windows.

  https://github.com/spk121/guile/blob/reloc-package/README-win.txt

---

This is just a hack. I am not promising to maintain it, and I'm not
sure how much of this nonsense can or should be upstreamed.  But if
you do find a problem, I guess just email me directly so we don't clog
the mailing list with discussion of non-free software.

Also, my name shows up on the MSIX installer. I'm not taking credit,
it is just that the installer requires that the publisher match the
code signing certificate.

---

CHANGES FROM CORE GUILE

This fork from core Guile has features necessary to distribute a Guile
app on Windows.  These are some of the changes.

Almost all instances of the long integer are replaced with intptr_t,
since on 64-bit Windows, sizeof(long) < sizeof(void *), in violation
of Guile's expectations.  Largely janneke did this work, but, I added
a couple more.

To help deliver a game as a single zip or tar file, a new configure
option --enable-relative-paths is added.  This installs all of guile
into the $(prefix)/app directory, and modifies the loading logic to
search for scheme, compiled scheme, and extension files relative to
the location of the executable.  The applications and all shared
object library files are in the root of that directory.  $(prefix)/app
is just a staging directory, and that directory can be renamed and
relocated.

Since the presence of a POSIX shell is not guaranteed, the guild
script may not be usable. A binary executable version of guild, called
guile-tools, is added.  Previously, guile-tools was an alias to guild
but now it is a compiled program.

Since unpacking zip or MSIX files may not preserve timestamps,
unpacked scheme files may have more recent file timestamps than their
associated compiled scheme (*.go) files, causing a recompilation.  A
feature is added such that if a file named FINAL is present in
ccache-dir or site-ccache-dir, the files therein are not recompiled
when they have file timestamps older than their associated scheme
files.

On Windows, the fallback directory is set to a more canonical Windows
app directory

  \AppData\Local\guile

rather than

  \AppData\Local\.cache\guile

On Windows, before a binary extension is loaded, the $libdir and
$extensiondir paths are added to the DLL search directories.  Also the
paths in the LTDL_LIBRARY_PATH and SCM_EXTENSIONS_PATH environment
variables are added to the DLL search directories.  This helps improve
the problem with a DLL failing to load because it depends on a DLL in
a directory that has not yet been added to the DLL search directories.

On Windows, there is a new function add-dll-search-directories.

On Windows, UTF-8 locales are used and tested.  When using the UCRT
library instead of the deprecated MSVCRT libary, guile on Windows has
some UTF-8 support.

read-line now handles the alternate line endings CRLF, CR, LS and PS.
To handle CRLF, read-line may return a string line terminator.  I
guess theoretically NEL is also a line terminator, but, I ignored
that.

The HTTP read-header-line is simplfied to take advantage of CRLF
support in read-line.

By default, cmd and powershell scripts require security elevation on
Windows.  As a workaround to avoid having to make a batch file to
launch a game, if guile is called without any command line arguments,
it now searches for a file named "cmdargs.txt" in the current working
directory.  When present, it will be used as command line arguments
for executing guile.  The purpose of this is to allow someone to just
double-click on the Guile executable to launch an app without
requiring a shell script.

In "cmdargs.txt", a line that begins with '#' in the first column is
treated as a comment.  If you need a command-line argument that begins
with a '#', begin the line with a space or tab.  The first non-comment
line of "command-args.txt" is stripped of initial and terminal
whitespace and is used as the first command-line argument (argv[1]).
The 2nd non-comment line is the 2nd command-line argument 

Re: 64-bit Guile on Windows

[Jean Abou Samra]



> Le 22 nov. 2022 à 14:22, Mike Gran  a écrit :
> For what it is worth, I do have functional 64-bit Guile 3.0.x for
> Windows at the link below, but that tree is still full of missteps and
> experiments and needs to made into a cleaner patchset.


Thanks, that is good to know, but it doesn’t help LilyPond in the immediate 
future because we have long branched our next stable release, which is supposed 
to happen next month, and we require Guile 2.2 for this release.

So we need to live with the fact that fixnums are ~32 bits at most because GMP 
expects long, unlike what is done in the wip-mingw branch with mini-GMP.


Best,
Jean

Re: 64-bit Guile on Windows

[Mike Gran]

On Tue, Nov 22, 2022 at 01:44:47PM +0100, Jean Abou Samra wrote:
> 
>> > Now, it is possible that the problem is that I am trying to run a
> > .go file compiled on macOS on a Windows machine, and that the two
> > platforms are different enough that the .go file can't be reused.
> > And because I get that "Value out of range" error when compiling
> > on Windows, I am probably stuck with .scm files instead of
> > compiled .go files.
> 
> 
> This bug is now hitting us too, we're investigating it here:
> 
> https://gitlab.com/lilypond/lilypond/-/issues/6474
> 
> Best,
> Jean
> 


For what it is worth, I do have functional 64-bit Guile 3.0.x for
Windows at the link below, but that tree is still full of missteps and
experiments and needs to made into a cleaner patchset.  And I'm still
actively hacking there because I'm trying to a Guile that, once
installed, lives in a single directory like most Windows applications
so I can make an MSIX installer. So it is a bit of a mess, but,
I'm fairly confident the integers are fixed.

https://github.com/spk121/guile/commits/wip-mingw-bleh

That tree was based on, and will eventually contribute
back to

https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw

Both of these trees require that you  --enable-mini-gmp 
--enable-jit=no and --disable-lto at configure time.

Regards,
Mike Gran

Re: 64-bit Guile on Windows

[Jean Abou Samra]

Le 28/06/2022 à 16:41, Thomas Thiriez via General Guile related 
discussions a écrit :


Jean Abou Samra  writes:


Le 27/06/2022 à 15:56, Thomas Thiriez via General Guile related
discussions a écrit :

[...]

(* 999 999 999) -> -76738825

[...]


We had exactly the same problem at LilyPond, and this was the fix:

https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721 



Namely, you need to patch libguile/conv-integer.i.c and
conv-uinteger.i.c to replace "SIZEOF_TYPE < SIZEOF_SCM_T_BITS"
with "SIZEOF_TYPE < SIZEOF_LONG".

HTH,
Jean


Thanks for the info. I have tried this, but it doesn't appear to be 
helping.


I did a few tests with lilypond, and here is what I found. I have a 
test.scm file containing:


(display (* 999)) (newline)
(display (* 999 999)) (newline)
(display (* 999 999 999)) (newline)

lilypond.exe -e '(load \"test.scm\")' test.ly
GNU LilyPond 2.23.10 (running Guile 2.2)
999
998001
997002999

That is fine. Now, if I try compiling test.scm to test.go, I get:

lilypond.exe -e '(use-modules (system base compile))(compile-file 
\"test.scm\" #:output-file \"test.go\")' test.ly

GNU LilyPond 2.23.10 (running Guile 2.2)
ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
In procedure bytevector-u64-set!: Value out of range: -149659645

That doesn't work, so I compile test.scm to test.go with guile on my 
Mac. If I then try loading the generated test.go with lilypond, I get:


lilypond.exe -e '(load \"test.go\")' test.ly
GNU LilyPond 2.23.10 (running Guile 2.2)
999
998001
-76738825

Now, it is possible that the problem is that I am trying to run a .go 
file compiled on macOS on a Windows machine, and that the two 
platforms are different enough that the .go file can't be reused. And 
because I get that "Value out of range" error when compiling on 
Windows, I am probably stuck with .scm files instead of compiled .go 
files.



This bug is now hitting us too, we're investigating it here:

https://gitlab.com/lilypond/lilypond/-/issues/6474

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: 64-bit Guile on Windows

[Jean Abou Samra]

On 6/28/22 12:52, Maxime Devos wrote:

Jean Abou Samra schreef op di 28-06-2022 om 10:38 [+0200]:

We had exactly the same problem at LilyPond, and this was the fix:

https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721


For security, shouldn't this check the hash of the downloaded tarballls
and patches?



Sorry, I forgot to reply to this. Yes, it likely should. On the other
hand, LilyPond has a lot of much more pressing security issues to care 
about…


Jean

Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

"Dr. Arne Babenhauserheide"  writes:

[...]

Possibly fixnum-related, so maybe:

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

Maybe 32-bit <-> 64-bit related, so maybe:

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


Thanks a lot. I will check those out.


Also, guile@2.2 is not developed anymore AFAICT.


From what I see, Guile 2.2 does still get fixes, but no larger 
changes.
See 
https://git.savannah.gnu.org/cgit/guile.git/log/?h=stable-2.2


I was able to have something at least partially working with Guile 
2.2, but if I could have a working Guile 3 on Windows, that would 
be even better!


Regards,
Thomas Thiriez

Re: 64-bit Guile on Windows

[Dr. Arne Babenhauserheide]

Maxime Devos  writes:

> [[PGP Signed Part:No public key for 49E3EE22191725EE created at 
> 2022-06-28T18:14:22+0200 using EDDSA]]
> Thomas Thiriez via General Guile related discussions schreef op di 28-
> 06-2022 om 16:41 [+0200]:
>> Jean Abou Samra  writes:
>> 
>> > Le 27/06/2022 à 15:56, Thomas Thiriez via General Guile related
>> > discussions a écrit :
>> [...]
>> > > (* 999 999 999) -> -76738825
>> [...]
>> > 
>> > We had exactly the same problem at LilyPond, and this was the 
>> > fix:
>> > 
>> > https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721
>> > 
>> > Namely, you need to patch libguile/conv-integer.i.c and
>> > conv-uinteger.i.c to replace "SIZEOF_TYPE < SIZEOF_SCM_T_BITS"
>> > with "SIZEOF_TYPE < SIZEOF_LONG".
>> > 
>> > HTH,
>> > Jean
>> 
>> Thanks for the info. I have tried this, but it doesn't appear to 
>> be helping.
>> 
>> I did a few tests with lilypond, and here is what I found. I have 
>> a test.scm file containing:
>> 
>> (display (* 999)) (newline)
>> (display (* 999 999)) (newline)
>> (display (* 999 999 999)) (newline)
>> 
>> lilypond.exe -e '(load \"test.scm\")' test.ly
>> GNU LilyPond 2.23.10 (running Guile 2.2)
>> 999
>> 998001
>> 997002999
>> 
>> That is fine. Now, if I try compiling test.scm to test.go, I get:
>> 
>> lilypond.exe -e '(use-modules (system base compile))(compile-file 
>> \"test.scm\" #:output-file \"test.go\")' test.ly
>> GNU LilyPond 2.23.10 (running Guile 2.2)
>> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
>> In procedure bytevector-u64-set!: Value out of range: -149659645
>
> Possibly fixnum-related, so maybe:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42060
>
> Maybe 32-bit <-> 64-bit related, so maybe:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28920
>
> Also, guile@2.2 is not developed anymore AFAICT.

From what I see, Guile 2.2 does still get fixes, but no larger changes.
See https://git.savannah.gnu.org/cgit/guile.git/log/?h=stable-2.2

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: 64-bit Guile on Windows

[Maxime Devos]

Thomas Thiriez via General Guile related discussions schreef op di 28-
06-2022 om 16:41 [+0200]:
> Jean Abou Samra  writes:
> 
> > Le 27/06/2022 à 15:56, Thomas Thiriez via General Guile related
> > discussions a écrit :
> [...]
> > > (* 999 999 999) -> -76738825
> [...]
> > 
> > We had exactly the same problem at LilyPond, and this was the 
> > fix:
> > 
> > https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721
> > 
> > Namely, you need to patch libguile/conv-integer.i.c and
> > conv-uinteger.i.c to replace "SIZEOF_TYPE < SIZEOF_SCM_T_BITS"
> > with "SIZEOF_TYPE < SIZEOF_LONG".
> > 
> > HTH,
> > Jean
> 
> Thanks for the info. I have tried this, but it doesn't appear to 
> be helping.
> 
> I did a few tests with lilypond, and here is what I found. I have 
> a test.scm file containing:
> 
> (display (* 999)) (newline)
> (display (* 999 999)) (newline)
> (display (* 999 999 999)) (newline)
> 
> lilypond.exe -e '(load \"test.scm\")' test.ly
> GNU LilyPond 2.23.10 (running Guile 2.2)
> 999
> 998001
> 997002999
> 
> That is fine. Now, if I try compiling test.scm to test.go, I get:
> 
> lilypond.exe -e '(use-modules (system base compile))(compile-file 
> \"test.scm\" #:output-file \"test.go\")' test.ly
> GNU LilyPond 2.23.10 (running Guile 2.2)
> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> In procedure bytevector-u64-set!: Value out of range: -149659645

You can find some possibly related bugs on debbugs:

Possibly fixnum-related, so maybe:

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

Maybe 32-bit <-> 64-bit related, so maybe:

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

Also, guile@2.2 is not developed anymore AFAICT.

Greetings,
Maixme.


signature.asc
Description: This is a digitally signed message part

Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

Thomas Thiriez via General Guile related discussions 
 writes:


That doesn't work, so I compile test.scm to test.go with guile 
on my

Mac.


I have also tried compiling with this command on my Mac to 
generate bytecode for the right architecture, but the result is 
the same:


guild compile test.scm -T x86_64-w64-mingw32 -o test.go

Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

Jean Abou Samra  writes:


Le 27/06/2022 à 15:56, Thomas Thiriez via General Guile related
discussions a écrit :

[...]

(* 999 999 999) -> -76738825

[...]


We had exactly the same problem at LilyPond, and this was the 
fix:


https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721

Namely, you need to patch libguile/conv-integer.i.c and
conv-uinteger.i.c to replace "SIZEOF_TYPE < SIZEOF_SCM_T_BITS"
with "SIZEOF_TYPE < SIZEOF_LONG".

HTH,
Jean


Thanks for the info. I have tried this, but it doesn't appear to 
be helping.


I did a few tests with lilypond, and here is what I found. I have 
a test.scm file containing:


(display (* 999)) (newline)
(display (* 999 999)) (newline)
(display (* 999 999 999)) (newline)

lilypond.exe -e '(load \"test.scm\")' test.ly
GNU LilyPond 2.23.10 (running Guile 2.2)
999
998001
997002999

That is fine. Now, if I try compiling test.scm to test.go, I get:

lilypond.exe -e '(use-modules (system base compile))(compile-file 
\"test.scm\" #:output-file \"test.go\")' test.ly

GNU LilyPond 2.23.10 (running Guile 2.2)
ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
In procedure bytevector-u64-set!: Value out of range: -149659645

That doesn't work, so I compile test.scm to test.go with guile on 
my Mac. If I then try loading the generated test.go with lilypond, 
I get:


lilypond.exe -e '(load \"test.go\")' test.ly
GNU LilyPond 2.23.10 (running Guile 2.2)
999
998001
-76738825

Now, it is possible that the problem is that I am trying to run a 
.go file compiled on macOS on a Windows machine, and that the two 
platforms are different enough that the .go file can't be reused. 
And because I get that "Value out of range" error when compiling 
on Windows, I am probably stuck with .scm files instead of 
compiled .go files.


Regards,
Thomas Thiriez

Re: 64-bit Guile on Windows

[Maxime Devos]

Jean Abou Samra schreef op di 28-06-2022 om 10:38 [+0200]:
> We had exactly the same problem at LilyPond, and this was the fix:
> 
> https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721
> 

For security, shouldn't this check the hash of the downloaded tarballls
and patches?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: 64-bit Guile on Windows

[Jean Abou Samra]

Le 27/06/2022 à 15:56, Thomas Thiriez via General Guile related 
discussions a écrit :

Hi,

I am currently porting a macOS application to Windows, and need to 
have libguile working.


I can see GnuCash works with Guile. I could borrow their libguile.dll, 
but it is a 32-bit build, and I am making a 64-bit application. I 
tried building Guile 3, but had more success with Guile 2.2, so I will 
keep that version.


I have cross compiled it on my mac with mingw, and it kind of works. 
The only thing is that if I compile my .scm files to .go, then my 
fixnums are not automatically converted to big nums, and I get things 
like that:


(* 999 999 999) -> -76738825

My fix is to keep the .scm files, and avoid compiling to .go.

I believe this has something to do with the fact that, on that 
platform, we have:


sizeof(SCM)  == 8
sizeof(long) == 4

Is there something to do about that problem? Is there something I can 
do to have a working 64-bit Guile on Windows?


Thanks a lot for any help you could provide.



We had exactly the same problem at LilyPond, and this was the fix:

https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L721

Namely, you need to patch libguile/conv-integer.i.c and
conv-uinteger.i.c to replace "SIZEOF_TYPE < SIZEOF_SCM_T_BITS"
with "SIZEOF_TYPE < SIZEOF_LONG".

HTH,
Jean

Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

Jan Nieuwenhuizen  writes:


Thomas Thiriez via General Guile related discussions writes:

Hello,

I am currently porting a macOS application to Windows, and need 
to

have libguile working.

[..]
I tried building Guile 3, but had more success with Guile 2.2, 
so I will

keep that version.


There is a 64-bit port on the wip-mingw branch

https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw

but that is based on guile-3.0.8.


Ah, that's good news. I have installed it with Cygwin, and it is 
working fine.


If I understand correctly, in order to use that version of 
libguile, I would have to redistribute the Cygwin libs with it, 
and the license would not work well with my proprietary 
application, am I right?


Regards,
Thomas Thiriez

Re: 64-bit Guile on Windows

[Jan Nieuwenhuizen]

Thomas Thiriez via General Guile related discussions writes:

Hello,

> I am currently porting a macOS application to Windows, and need to
> have libguile working.
[..]
> I tried building Guile 3, but had more success with Guile 2.2, so I will
> keep that version.

There is a 64-bit port on the wip-mingw branch

https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw

but that is based on guile-3.0.8.

> I believe this has something to do with the fact that, on that
> platform, we have:
>
> sizeof(SCM)  == 8
> sizeof(long) == 4

Yes, indeed.

> Is there something to do about that problem? Is there something I can
> do to have a working 64-bit Guile on Windows?

It shouldn't be too much work to backport the fixes to guile-2.2.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen   | GNU LilyPond https://lilypond.org
Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com

64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions]

Hi,

I am currently porting a macOS application to Windows, and need to 
have libguile working.


I can see GnuCash works with Guile. I could borrow their 
libguile.dll, but it is a 32-bit build, and I am making a 64-bit 
application. I tried building Guile 3, but had more success with 
Guile 2.2, so I will keep that version.


I have cross compiled it on my mac with mingw, and it kind of 
works. The only thing is that if I compile my .scm files to .go, 
then my fixnums are not automatically converted to big nums, and I 
get things like that:


(* 999 999 999) -> -76738825

My fix is to keep the .scm files, and avoid compiling to .go.

I believe this has something to do with the fact that, on that 
platform, we have:


sizeof(SCM)  == 8
sizeof(long) == 4

Is there something to do about that problem? Is there something I 
can do to have a working 64-bit Guile on Windows?


Thanks a lot for any help you could provide.

Regards,
Thomas Thiriez

Re: No Guile on Windows?

[Ludovic Courtès]

Linus Björnstam  skribis:

> TIL that guile 1.6 had 2.5% pascal code!

I don’t think so.  :-)  Probably a mistake of the tool that tries to
identify languages.  For
,
sloccount says:

--8<---cut here---start->8---
Totals grouped by language (dominant language first):
ansic:61318 (75.07%)
lisp: 15803 (19.35%)
sh:2796 (3.42%)
asm:   1514 (1.85%)
awk:199 (0.24%)
csh: 50 (0.06%)
--8<---cut here---end--->8---

Ludo’.

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Linus Björnstam]

TIL that guile 1.6 had 2.5% pascal code!

-- 
  Linus Björnstam

On Thu, 13 Aug 2020, at 15:02, Pikachu Hy via General Guile related discussions 
wrote:
> hi,
> I build a msvc-version guile on Windows 10.
> 
> https://github.com/PikachuHy/guile-1.6.7/releases/tag/v20200813
> 
> Best wishes,
> PikachuHy
> 
>

No Guile on Windows? (was: My Guile Hacker Handbook)

[Pikachu Hy via General Guile related discussions]

hi,
I build a msvc-version guile on Windows 10.

https://github.com/PikachuHy/guile-1.6.7/releases/tag/v20200813

Best wishes,
PikachuHy

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Vladimir Zhbanov]

Mike,

On Mon, Jul 27, 2020 at 08:57:05PM -0700, Mike Gran wrote:
> On Tue, Jul 28, 2020 at 10:52:47AM +0800, Christopher Lam wrote:
> > My mistake: gnucash uses MinGW-w64.
> > 
> > The gnucash lead developer has a few patches to successfully compile guile
> > on MinGW-w64. It would be great if these patches were taken upstream and a
> > CI pipeline enabled for testing. Otherwise gnucash for windows will always
> > need to catch up, and is at severe risk of falling behind.
> > 
> > https://github.com/jralls/guile
> > 
> 
> Yeah, that's a patched version of 2.2.7.
> 
> Even though I'm on a hiatus from coding, I believe I have all the
> parts to make Guile 3.0.x work on MinGW 32-bit no-threads.  Maybe I'll
> just see if I can't put that together real quick.

You don't even imagine how many projects/devs are waiting for your
efforts! (Maybe even twice more than just 'gnucash' :-))

And I really would very much appreciate the effort, I know how
much non-trivial it is.  Five years ago I cross-compiled
guile-2.0.9 with all its GC bugs on windows and got a working
version of our tools only after 3-5 months.  Now, I'm trying to
repeat this effort with new versions, and see it again :-(

Thank you for your work!

-- 
  Vladimir

(λ)επτόν EDA — https://github.com/lepton-eda

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Christopher Lam]

My mistake: gnucash uses MinGW-w64.

The gnucash lead developer has a few patches to successfully compile guile
on MinGW-w64. It would be great if these patches were taken upstream and a
CI pipeline enabled for testing. Otherwise gnucash for windows will always
need to catch up, and is at severe risk of falling behind.

https://github.com/jralls/guile

On Sat, 25 Jul 2020, 10:28 pm Eli Zaretskii,  wrote:

> > From: Christopher Lam 
> > Date: Sat, 25 Jul 2020 13:56:28 +
> > Cc: guile-user , help-g...@gnu.org
> >
> > Gnucash 4.0 in windows is successfully using libguile-2.2-1.dll from
> MSYS2.
>
> Is Gnucash a MinGW build or an MSYS2 build?  If the latter, it's
> expected.
>

Re: No Guile on Windows?

[Dmitry Alexandrov]

David Pirotte  wrote:
> msys2
> has guile-2.2.7-1

> well maintained
> very friendly on irc

Appended with fact that MSYS2 is a fork of Cygwin, which has 3.0.4, these looks 
like an invitation to go to IRC and inquire about issues that made them stick 
with the legacy branch...


signature.asc
Description: PGP signature

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Mike Gran]

On Sat, Jul 25, 2020 at 09:31:41AM +0300, Eli Zaretskii wrote:
> > fwiw, i've used msys2 (not so much anymore, but i still would if i had
> > to ...), easy to install, update, well maintained, very friendly on irc
> > when i needed to ask for help ...:
> > 
> > https://www.msys2.org/
> > 
> > it has guile-2.2.7-1, threaded (which I've used. it works ...)
> 
> AFAIU, that's not a native Windows port, that's an MSYS2 port, which
> is almost the same as a Cygwin build (MSYS2 is a fork of Cygwin).
> 
> IOW, you cannot link the MSYS2 libguile with a native MinGW program,
> such as GDB or Gnu Make (or Lilypond, or any other application
> mentioned in this thread).  Right?

That is correct. When you try to build windows application in the
MinGW project, often times you need to run a configure script that may
require tools that don't have native windows versions. The way MinGW
helps these configure scripts run is by taking advantage of the the
MSYS2 environment -- which is similar to Cygwin -- so that has enough
tools to run a configure script.  It includes a version of Guile for
the purpose of running configure.

Like Cygwin, MSYS2 also has a big library that emulates POSIX that
everything links to.  The difference betwen MSYS2 and MinGW is that
MinGW apps try to link directly to windows libraries without linking
to an emulation library.

-Mike Gran

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Jérémy Korwin-Zmijowski]

Never heard about it.

I will try it and maybe update the Windows section ;-)

Thank you David

Jérémy

Le 25 juillet 2020 05:48:35 GMT+02:00, David Pirotte  a écrit :
>Hello,
>
>> > > ### On Windows
>> > > No solution yet.  
>
>fwiw, i've used msys2 (not so much anymore, but i still would if i had
>to ...), easy to install, update, well maintained, very friendly on irc
>when i needed to ask for help ...:
>
>   https://www.msys2.org/
>
>it has guile-2.2.7-1, threaded (which I've used. it works ...)
>
>   https://packages.msys2.org/base/guile
>
>for me, it was fantastic _not to have to deal_ with ouindoze on
>ouindoze, so msys2, its numerous packages ... and guile-2.2.7-1
>'saved my life' :)
>
>   dowload the lastest msys2
>   double-click -> linux terminal
>   use pacman (*) to update and install new packages
>
>David
>
>   ** Update
>
>   pacman -Syu
>   pacman -Su
>
>   ** Packages
>
>   pacman -S emacs
>   pacman -S guile
>   pacman -S libguile
>   pacman -S libguile-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Eli Zaretskii]

> From: Christopher Lam 
> Date: Sat, 25 Jul 2020 13:56:28 +
> Cc: guile-user , help-g...@gnu.org
> 
> Gnucash 4.0 in windows is successfully using libguile-2.2-1.dll from MSYS2.

Is Gnucash a MinGW build or an MSYS2 build?  If the latter, it's
expected.

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Christopher Lam]

Gnucash 4.0 in windows is successfully using libguile-2.2-1.dll from MSYS2.

On Sat, 25 Jul 2020 at 06:32, Eli Zaretskii  wrote:

> > Date: Sat, 25 Jul 2020 00:48:35 -0300
> > From: David Pirotte 
> > Cc: Dmitry Alexandrov , guile-user@gnu.org,
> help-g...@gnu.org
> >
> > fwiw, i've used msys2 (not so much anymore, but i still would if i had
> > to ...), easy to install, update, well maintained, very friendly on irc
> > when i needed to ask for help ...:
> >
> >   https://www.msys2.org/
> >
> > it has guile-2.2.7-1, threaded (which I've used. it works ...)
>
> AFAIU, that's not a native Windows port, that's an MSYS2 port, which
> is almost the same as a Cygwin build (MSYS2 is a fork of Cygwin).
>
> IOW, you cannot link the MSYS2 libguile with a native MinGW program,
> such as GDB or Gnu Make (or Lilypond, or any other application
> mentioned in this thread).  Right?
>
>

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Eli Zaretskii]

> Date: Sat, 25 Jul 2020 00:48:35 -0300
> From: David Pirotte 
> Cc: Dmitry Alexandrov , guile-user@gnu.org, help-g...@gnu.org
> 
> fwiw, i've used msys2 (not so much anymore, but i still would if i had
> to ...), easy to install, update, well maintained, very friendly on irc
> when i needed to ask for help ...:
> 
>   https://www.msys2.org/
> 
> it has guile-2.2.7-1, threaded (which I've used. it works ...)

AFAIU, that's not a native Windows port, that's an MSYS2 port, which
is almost the same as a Cygwin build (MSYS2 is a fork of Cygwin).

IOW, you cannot link the MSYS2 libguile with a native MinGW program,
such as GDB or Gnu Make (or Lilypond, or any other application
mentioned in this thread).  Right?

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[David Pirotte]

Hello,

> > > ### On Windows
> > > No solution yet.  

fwiw, i've used msys2 (not so much anymore, but i still would if i had
to ...), easy to install, update, well maintained, very friendly on irc
when i needed to ask for help ...:

https://www.msys2.org/

it has guile-2.2.7-1, threaded (which I've used. it works ...)

https://packages.msys2.org/base/guile

for me, it was fantastic _not to have to deal_ with ouindoze on
ouindoze, so msys2, its numerous packages ... and guile-2.2.7-1
'saved my life' :)

dowload the lastest msys2
double-click -> linux terminal
use pacman (*) to update and install new packages

David

** Update

pacman -Syu
pacman -Su

** Packages

pacman -S emacs
pacman -S guile
pacman -S libguile
pacman -S libguile-devel


pgpyeodAlFmKi.pgp
Description: OpenPGP digital signature

Re: Licensing of Cygwin comatibility layer (was: No Guile on Windows?)

[Mike Gran]

On Fri, Jul 24, 2020 at 07:25:07PM +0300, Dmitry Alexandrov wrote:
> Mike Gran  wrote:
> > Cygwin: use gcc or clang, link to a special C and POSIX library that 
> > handles the Windows API for you.
> > Its emulation library is GPL[ed]
> 
> Really?  I was under impression, that it is under a _weakened_ variant of 
> _Lesser_ GPL, i. e. its terms are even less restrictive that those of GNU 
> libc.
> 
> > so to distribute a Cygwin app, it must be GPL[-compatible]
> 
> After all, Cygwin itself (just like any other GNU distro) have always 
> distributed quite a few of GPL-incompatible software, so that statement does 
> not look plausible at all.

You are correct. I misread this page  https://cygwin.com/licensing.html

Apologies.

-Mike Gran

Re: No Guile on Windows?

[Jan Wielkiewicz]

Hello,

Dnia 2020-07-24, o godz. 16:00:56
Ludovic Courtès  napisał(a):

> However, my understanding is that Windows Subsystem for Linux (WSL)
> has the potential to make all of us happy.

This is fine as far as we're talking about proprietary Windows, but
this isn't good for software freedom generally - there's ReactOS
(https://reactos.org/) - a free Windows clone that is about to reach
beta stage. It is unlikely they're going to implement WSL there and
therefore Guile will be not usable on this platform. This could
potentially stop Guile users on Windows from switching to ReactOS.
If Guile were running natively on Windows, it would only benefit free
software - more Guile users, more people being interested in Guix and
more people switching to free alternatives.

If no current Guile maintainer is interested in porting it to Windows,
we could at least let people know we're looking for someone who does.
It could be a GSoC proposal, Outreachy something, etc.


Jan Wielkiewicz 

Re: No Guile on Windows?

[Dmitry Alexandrov]

Ludovic Courtès  wrote:
> Eli Zaretskii  skribis:
>>  Sadly, Guile seems to care only about one OS: GNU/Linux

> my understanding is that Windows Subsystem for Linux (WSL) has the potential 
> to make all of us happy.

Itʼs the most disappointing thing to hear from a Guile maintainer.

> For example, here’s info from someone who got Guix to run on Windows/WSL2:

Contrary to WSL1, which was rather a misnomer for an alternative ABI-compatible 
implementation of Linux® on top of Windowsʼ kernel, WSL2 fully justifies its 
name: itʼs subsystem _for_ running Linux in it.

In other words, what youʼve just said is: Guile does not need to support 
Windows, because you can always run GNU/Linux in a virtual machine.

Iʼm afraid, such an attitude, if Guile is staking claim for being something 
more than a DSL for defining distro packages, is a decade premature at best.

> Running Guile alone should be easier.  Notably, I would expect a bundle 
> created with ‘guix pack guile’ to Just Work on Windows.
>
> Does anyone have experience with that?

I do not, but do not see any reason why it should not.  If Guix pack would fail 
to run on Ubuntu, because it is running on emulated hardware, it would mean 
that Guix is really broken.  And we know, that itʼs not.


signature.asc
Description: PGP signature

Re: No Guile on Windows?

[Dr. Arne Babenhauserheide]

Stefan Israelsson Tampe  writes:

> I use guile all the time at my windows 10 machine at work (WSL) to handle
> xml files. Used apt to get it.

It’s great that that’s possible. If it requires people to first activate
WSL (so they cannot just start an application they get from me but have
to configure stuff first), I lose lots of users who would otherwise run
my application.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Licensing of Cygwin comatibility layer (was: No Guile on Windows?)

[Dmitry Alexandrov]

Mike Gran  wrote:
> Cygwin: use gcc or clang, link to a special C and POSIX library that handles 
> the Windows API for you.
> Its emulation library is GPL[ed]

Really?  I was under impression, that it is under a _weakened_ variant of 
_Lesser_ GPL, i. e. its terms are even less restrictive that those of GNU libc.

> so to distribute a Cygwin app, it must be GPL[-compatible]

After all, Cygwin itself (just like any other GNU distro) have always 
distributed quite a few of GPL-incompatible software, so that statement does 
not look plausible at all.


signature.asc
Description: PGP signature

Re: No Guile on Windows?

[Stefan Israelsson Tampe]

I use guile all the time at my windows 10 machine at work (WSL) to handle
xml files. Used apt to get it.

On Fri, Jul 24, 2020 at 4:01 PM Ludovic Courtès  wrote:

> Hi!
>
> Eli Zaretskii  skribis:
>
> > 
> > Sadly, Guile seems to care only about one OS: GNU/Linux, and more or
>
> Guile is software so it’s doesn’t care one way or the other ;-), but
> it’s true that the maintainers and probably most contributors are
> primarily concerned with GNU/Linux.
>
> However, my understanding is that Windows Subsystem for Linux (WSL) has
> the potential to make all of us happy.  For example, here’s info from
> someone who got Guix to run on Windows/WSL2:
>
>   https://gist.github.com/giuliano108/49ec5bd0a9339db98535bc793ceb5ab4
>
> Running Guile alone should be easier.  Notably, I would expect a bundle
> created with ‘guix pack guile’ to Just Work on Windows.
>
> Does anyone have experience with that?
>
> Thanks,
> Ludo’.
>
>
>

Re: No Guile on Windows?

[Ludovic Courtès]

Hi!

Eli Zaretskii  skribis:

> 
> Sadly, Guile seems to care only about one OS: GNU/Linux, and more or

Guile is software so it’s doesn’t care one way or the other ;-), but
it’s true that the maintainers and probably most contributors are
primarily concerned with GNU/Linux.

However, my understanding is that Windows Subsystem for Linux (WSL) has
the potential to make all of us happy.  For example, here’s info from
someone who got Guix to run on Windows/WSL2:

  https://gist.github.com/giuliano108/49ec5bd0a9339db98535bc793ceb5ab4

Running Guile alone should be easier.  Notably, I would expect a bundle
created with ‘guix pack guile’ to Just Work on Windows.

Does anyone have experience with that?

Thanks,
Ludo’.

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Mike Gran]

On Fri, Jul 24, 2020 at 09:22:54AM +0200, Dr. Arne Babenhauserheide wrote:
> 
> This is one of the biggest worries I have with the time I put into
> Guile: Many of my friends are still on Windows and in the current state
> of Guile I won???t be able to create tools that help them.
> 
> Creating installers for Windows was bad with Python, it is much worse
> with Guile. I wish I could just do something like
> guild package --target windows -o my-program.exe entry-point.scm 
> 
> This prevents people from using Guile for anything that might have to be
> cross-platform (though the Lilypond folks got it working
> https://lilypond.org/windows.de.html).

Yeah, I did put a 32-bit, no-thread Windows version of Guile-2.2 in
a game-jame game I did once, but, it was non-trivial.

For those that hanven't programmed on Windows much, it is a bit of a
struggle. The native tools are C++, not C, and the native API is just
different: different threading, different asyncs, similar but still
not identical sockets, different dynamic linking. No guarantee that
the sizeof(long) is sizeof(void *).

So different groups have created projects to help port or run legacy
UNIX-like software to Windows. The most familiar to free software people
are Cygwin and MinGW.

Cygwin: use gcc or clang, link to a special C and POSIX library that
handles the Windows API for you. This exists and works well for Guile.
Its emulation library is GPL, so to distribute a Cygwin app, it must
be GPL and must include a healthy chunk of the Cygwin infrastructure.

MinGW: use gcc or clang, link to native Windows API. Guile almost
supports this, because it uses Gnulib. Gnulib has a library of shims
that tweaks Windows C library API to be more POSIX-like, but, Gnulib
isn't a comprehensive solution.  When free software people talk of
a "port" to windows, they usualy mean that it is built with MinGW.

But, of course, MinGW had a spat years ago and now there are two
competing MinGW projects. Sigh.

Some projects go a step further and try to use the native windows
compilers and API, but, since autoconf basically won't work on Windows
because its shell language is not /bin/sh but is PowerShell or CMD,
this usually requires a different build system, like CMake or Meson.

Guile has both autoconf and gnulib, so MinGW is the semi-supported
path to a native Windows executable.

It actually would not be a lot of work to get a 32-bit, unthreaded
Guile 3.0 working again, assuming that lightening works for
Win32.  Just some run of the mill patching.  But historically
getting these patches in the main tree has been an awful experience
-- expecially in the Mark era -- because of arguments as to
whether they should be fixed in Guile or in Gnulib and having
to deal with both Guile and Gnulib having competing interests.

Thanks you for coming to my TED talk.  

Regards
Mike Gran

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Stefan Israelsson Tampe]

I just want to say that I use guile on windows regularly. And it was easy
peasy to enable it. The trick is to install the Linux subsystem for windows
10 and hack on. I know this is not always an option, just to remind you
where the future is.

On Fri, Jul 24, 2020 at 2:07 AM Dmitry Alexandrov  wrote:

> Jérémy Korwin-Zmijowski  wrote:
> > https://jeko.frama.io
>
> > ## Installation
>
> > ### On Windows
> >
> > No solution yet.
>
> Is that true?  Itʼs true (and a pity) that there no official packages, of
> course, but ‘no solution’?
>
> I vaguely recall, there was a Guile on MinGW a couple of years ago, does
> it no longer build?  And what happened with Cygwin package after all?
> cygwin.com says, that 3.0.4 is there [1].
>
> [1] https://cygwin.com/packages/summary/guile3.0.html
>

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Christopher Lam]

Ditto gnucash on windows does include guile 2.2 but it's a major pain point
to get it to build.

https://code.gnucash.org/logs/2020/07/16.html#T20:20:40

On Fri, 24 Jul 2020, 3:24 pm Dr. Arne Babenhauserheide, 
wrote:

>
> Eli Zaretskii  writes:
> > 
> > Sadly, Guile seems to care only about one OS: GNU/Linux, and more or
> > less disregard the rest.  Features are added that clearly cannot
> > easily work on other OSes, let alone non-Posix ones, and with each
> > such new feature producing a working MinGW port becomes harder and
> > harder, even for experienced hackers.
>
> This is one of the biggest worries I have with the time I put into
> Guile: Many of my friends are still on Windows and in the current state
> of Guile I won’t be able to create tools that help them.
>
> Creating installers for Windows was bad with Python, it is much worse
> with Guile. I wish I could just do something like
> guild package --target windows -o my-program.exe entry-point.scm
>
> This prevents people from using Guile for anything that might have to be
> cross-platform (though the Lilypond folks got it working
> https://lilypond.org/windows.de.html).
>
> > Please don't bother replying to this rant, it's just FYI, to convey my
> > personal recollections and experiences from doing the 2.0.x port, and
> > I don't intend to argue about it.
> > 
>
> I replied, because I did not intend to argue but rather support your
> point. While Guile is easiest to use on GNU Linux, a Windows port is a
> hard requirement if we want Guile to be useful as a platform for writing
> programs. There is GTK for Windows and it would be nice if we could
> actually script it from Guile:
> https://www.gtk.org/docs/installations/windows/
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Dr. Arne Babenhauserheide]

Eli Zaretskii  writes:
> 
> Sadly, Guile seems to care only about one OS: GNU/Linux, and more or
> less disregard the rest.  Features are added that clearly cannot
> easily work on other OSes, let alone non-Posix ones, and with each
> such new feature producing a working MinGW port becomes harder and
> harder, even for experienced hackers.

This is one of the biggest worries I have with the time I put into
Guile: Many of my friends are still on Windows and in the current state
of Guile I won’t be able to create tools that help them.

Creating installers for Windows was bad with Python, it is much worse
with Guile. I wish I could just do something like
guild package --target windows -o my-program.exe entry-point.scm 

This prevents people from using Guile for anything that might have to be
cross-platform (though the Lilypond folks got it working
https://lilypond.org/windows.de.html).

> Please don't bother replying to this rant, it's just FYI, to convey my
> personal recollections and experiences from doing the 2.0.x port, and
> I don't intend to argue about it.
> 

I replied, because I did not intend to argue but rather support your
point. While Guile is easiest to use on GNU Linux, a Windows port is a
hard requirement if we want Guile to be useful as a platform for writing
programs. There is GTK for Windows and it would be nice if we could
actually script it from Guile:
https://www.gtk.org/docs/installations/windows/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[divoplade]

Hello,

Le vendredi 24 juillet 2020 à 03:06 +0300, Dmitry Alexandrov a écrit :
> Jérémy Korwin-Zmijowski  wrote:
> > https://jeko.frama.io
> > ## Installation
> > ### On Windows
> > 
> > No solution yet.
> 
> Is that true?  Itʼs true (and a pity) that there no official
> packages, of course, but ‘no solution’?

>From what I gathered, there are a few stupid problems with existing
patches to make guile build for mingw (
https://github.com/mkeeter/guile-mingw/), but there is the hard problem
that the garbage collector won't work on mingw x86_64 because it
expects that pointers can fit in longs.

Anyways, I say that if we can't have mingw x86_64, let's have i686 and
everyone will be happy enough. By the time i686 is insufficient,
Windows will already be another OS built around linux anyway (n.b. this
is a personal opinion ^^). But there is a chance I fundamentally
misunderstood something...

Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Eli Zaretskii]

> From: Dmitry Alexandrov 
> Date: Fri, 24 Jul 2020 03:06:53 +0300
> Cc: Guile User , Guix Help 
> 
> > ## Installation
> 
> > ### On Windows
> >
> > No solution yet.
> 
> Is that true?  Itʼs true (and a pity) that there no official packages, of 
> course, but ‘no solution’?
> 
> I vaguely recall, there was a Guile on MinGW a couple of years ago, does it 
> no longer build?  And what happened with Cygwin package after all?  
> cygwin.com says, that 3.0.4 is there [1].

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

Mind you, this is a 32-bit build, and it is configured without threads
(because building with threads produces Guile that crashes for almost
any non-trivial operation, you can find the details in the Guile
mailing list archives).

I never tried to build a newer Guile, as doing a fully-functional
MinGW port is a non-trivial endeavor that consumes a lot of time, and
I don't have that time now.


Sadly, Guile seems to care only about one OS: GNU/Linux, and more or
less disregard the rest.  Features are added that clearly cannot
easily work on other OSes, let alone non-Posix ones, and with each
such new feature producing a working MinGW port becomes harder and
harder, even for experienced hackers.

Please don't bother replying to this rant, it's just FYI, to convey my
personal recollections and experiences from doing the 2.0.x port, and
I don't intend to argue about it.

No Guile on Windows? (was: My Guile Hacker Handbook)

[Dmitry Alexandrov]

Jérémy Korwin-Zmijowski  wrote:
> https://jeko.frama.io

> ## Installation

> ### On Windows
>
> No solution yet.

Is that true?  Itʼs true (and a pity) that there no official packages, of 
course, but ‘no solution’?

I vaguely recall, there was a Guile on MinGW a couple of years ago, does it no 
longer build?  And what happened with Cygwin package after all?  cygwin.com 
says, that 3.0.4 is there [1].

[1] https://cygwin.com/packages/summary/guile3.0.html


signature.asc
Description: PGP signature

Re: Guile on Windows? (Re: Upcoming 1.6.5 release)

[Neil Jerram]

[EMAIL PROTECTED] (Michael Herstine [EMAIL PROTECTED]) writes:

 Hi Neil,

 Sorry to trouble you.  I'm interested in using Guile on Win32, but I'm
 having trouble figuring out what the status there is.  [...]

 However, having downloaded 1.6.7, I see no mention of this..

 What's the story?

I think the story is basically that it (running Guile on Windows) can
be done, but it's not yet either straightforward or fully integrated
into the standard distro.

I'm broadly aware of three possible approaches.

1. Cygwin.  Guile 1.6.x is available via the standard cygwin setup, so
   you could just use that.

2. Native compilation using MSVC.  This is what I've done, but I
   haven't yet packaged/published the results.  Some things are not
   supported with this approach, like threads and some Posix stuff.

3. Cross-compilation targetting MinGW.  I believe Stefan Jahn has done
   this, and it pretty much just works, but I don't know the details
   myself.

What are you looking to do, more precisely?

Regards,
Neil



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user