[fricas-devel] FriCAS on Windows 10 - "MinGW64/MSYS2" vs "WSL + Debian based Linux w/o Xorg + Xrdp" (sleeping trouble :)

[Grégory Vanuxem]

Hello,

Having some troubles to sleep this night and instead of counting sheep I
have tried to rebuild and test FriCAS on my freshly reinitialized Windows
10. This message is just about testing FriCAS on Windows 10.

First I rebuild FriCAS on an updated MinGW64/MSYS2-X64 system [1] .
I found as always an issue relative to 'mkdir' (cfuns-c.c around line 113),
I will come back a little later, but no problem in 'make check', it's a not
always the case, that's a good news. No segfault etc. It seems some good
progress happen in the SBCL and MinGW communities.

The advantage of MinGW is that it's a build directly based on the Windows
API, not using the Cygwin dll for example which emulate a lot more of
UNIX-like POSIX norms. Moreover it seemed to me that CLisp on Cygwin no
longer supports dumping an image. Actually the binary version of FriCAS for
Windows available is version 1.2.5.

Better news now.

After I tried to build FriCAS on a Debian based Linux which uses WSL. And
it's a good news :
I tried Kali Linux available on the Microsoft store and after an 'apt-get
update && apt-get install sbcl gcc make' I was able to successfully build
FriCAS 1.3.4, install it and all the tests passed smoothly.

I did some simple comparison benchmarks of the build process between
MinGW64 and Linux with WSL

MinGW64 - WSL Linux
configure ~ 39 s ~ 9 s [2]
make ~ 5.46 min ~ 4.28 min [3]
make check ~ 2.2 min ~ .3 min [4]

FriCAS on Linux for Windows seems relatively competitive.

And for the fun I installed Xorg and Xrdp on Kali for Windows WSL (there is
also Debian,Ubuntu etc..). Using the Xrdp protocol I was able to run XFCE,
FriCAS and HyperDoc on Windows:

https://drive.google.com/open?id=1-LTs3ezIPUaj4q4JseRlNaFcPnX-m6oJ

and a quick benchs, first Kali against MinGW64 and later, the last 3
screenshots, on a real Linux, Parrot, make & make test & matrix
multiplication:

https://drive.google.com/open?id=1v4XDegvs-klcip8w1gP3CI3lI6ZWvSaO (61.5
min vs 67.6 min)

Parrot for a real Linux "comparison"

https://drive.google.com/open?id=1UCpMVScV6551OCDhh6LS_v5i04vVhbNx
(building : 2.4 min)
https://drive.google.com/open?id=1S8KvJ17Nhyiwgt4NeUht199a90fUp8Cq ('make
test' : 1.2 min)
https://drive.google.com/open?id=1raDAVVs1Dpb84tF7ZhOr7FkifAw9SLgO
(1000x1000 SF matrix multiplication 55.5 min)

And after I had to go work :)

That's all.

I hope you enjoy and I would like to test this with you with other distros
in the Microsoft store, document that and eventually make packages
availables.

--
Greg


[1] msys2-x86_64-20180531.exe - https://www.msys2.org/ - SBCL x64 binary
from http://www.sbcl.org/platform-table.html - 1.4.2
[2] https://drive.google.com/open?id=13lZNNtGHmZiLOom9kxIaQNCPc511nA41
[3] https://drive.google.com/open?id=1KjtdDhF1j0UfbadCP6WLZVtoBid_aNDI
[4] https://drive.google.com/open?id=16cq6a_d2jDdGTiIFr7S4nu_eJL-gr-5a

[oldk1331]

I think it's time to provide binaries (again) for Windows and macOS
since next FriCAS release, without X11 (hyperdoc) support.

First, X11 is badly supported on these platforms.
Second, without the need to support X11, it'll be much easier to
package for these platforms.

Post by Grégory Vanuxem
Hello,
Having some troubles to sleep this night and instead of counting sheep I
have tried to rebuild and test FriCAS on my freshly reinitialized
Windows 10. This message is just about testing FriCAS on Windows 10.
First I rebuild FriCAS on an updated MinGW64/MSYS2-X64 system [1] .
I found as always an issue relative to 'mkdir' (cfuns-c.c around line
113), I will come back a little later, but no problem in 'make check',
it's a not always the case, that's a good news. No segfault etc. It
seems some good progress happen in the SBCL and MinGW communities.
The advantage of MinGW is that it's a build directly based on the
Windows API, not using the Cygwin dll for example which emulate a lot
more of  UNIX-like POSIX norms. Moreover it seemed to me that CLisp on
Cygwin no longer supports dumping an image. Actually the binary version
of FriCAS for Windows available is version 1.2.5.
Better news now.
After I tried to build FriCAS on  a Debian based Linux which uses WSL.
I tried Kali Linux available on the Microsoft store and after an
'apt-get update && apt-get install sbcl gcc make' I was able to
successfully build FriCAS 1.3.4, install it and all the tests passed
smoothly.
I did some simple comparison benchmarks of the build process between
MinGW64 and Linux with WSL
                      MinGW64 - WSL Linux
configure        ~ 39 s           ~ 9 s                [2]
make             ~ 5.46 min     ~ 4.28 min        [3]
make check   ~ 2.2 min       ~ .3 min            [4]
FriCAS on Linux for Windows seems relatively competitive.
And for the fun I installed Xorg and Xrdp on Kali for Windows WSL (there
is also Debian,Ubuntu etc..). Using the Xrdp protocol I was able to run
https://drive.google.com/open?id=1-LTs3ezIPUaj4q4JseRlNaFcPnX-m6oJ
and a quick benchs, first Kali against MinGW64 and later, the last 3
screenshots, on a real Linux, Parrot, make & make test & matrix
https://drive.google.com/open?id=1v4XDegvs-klcip8w1gP3CI3lI6ZWvSaO (61.5
min vs 67.6 min)
Parrot for a real Linux "comparison"
https://drive.google.com/open?id=1UCpMVScV6551OCDhh6LS_v5i04vVhbNx
(building : 2.4 min)
https://drive.google.com/open?id=1S8KvJ17Nhyiwgt4NeUht199a90fUp8Cq
('make test' : 1.2 min)
https://drive.google.com/open?id=1raDAVVs1Dpb84tF7ZhOr7FkifAw9SLgO
(1000x1000 SF matrix multiplication 55.5 min)
And after I had to go work :)
That's all.
I hope you enjoy and I would like to test this with you with other
distros in the Microsoft store, document that and eventually make
packages availables.
--
Greg
[1] msys2-x86_64-20180531.exe - https://www.msys2.org/ - SBCL x64 binary
from http://www.sbcl.org/platform-table.html - 1.4.2
[2] https://drive.google.com/open?id=13lZNNtGHmZiLOom9kxIaQNCPc511nA41
[3] https://drive.google.com/open?id=1KjtdDhF1j0UfbadCP6WLZVtoBid_aNDI
[4] https://drive.google.com/open?id=16cq6a_d2jDdGTiIFr7S4nu_eJL-gr-5a
--
You received this message because you are subscribed to the Google
Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[Grégory Vanuxem]

Hi,

Yes I agree.

Am rebuilding it and I spoke earlier about an issue in c-funs.c near line
113 :

I don't know how you want to solve that but the offending code to build
FriCAS with MinGW is :

int
makedir(char *path)
{
#ifdef S_IRWXO
return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
#else
return ( mkdir (path) );
#endif
}

Here the preprocessor take the first call but it needs to take ' return (
mkdir (path) );'

Cheers,

Greg

Post by oldk1331
I think it's time to provide binaries (again) for Windows and macOS
since next FriCAS release, without X11 (hyperdoc) support.
First, X11 is badly supported on these platforms.
Second, without the need to support X11, it'll be much easier to
package for these platforms.

Post by Grégory Vanuxem
Hello,
Having some troubles to sleep this night and instead of counting sheep I
have tried to rebuild and test FriCAS on my freshly reinitialized
Windows 10. This message is just about testing FriCAS on Windows 10.
First I rebuild FriCAS on an updated MinGW64/MSYS2-X64 system [1] .
I found as always an issue relative to 'mkdir' (cfuns-c.c around line
113), I will come back a little later, but no problem in 'make check',
it's a not always the case, that's a good news. No segfault etc. It
seems some good progress happen in the SBCL and MinGW communities.
The advantage of MinGW is that it's a build directly based on the
Windows API, not using the Cygwin dll for example which emulate a lot
more of UNIX-like POSIX norms. Moreover it seemed to me that CLisp on
Cygwin no longer supports dumping an image. Actually the binary version
of FriCAS for Windows available is version 1.2.5.
Better news now.
After I tried to build FriCAS on a Debian based Linux which uses WSL.
I tried Kali Linux available on the Microsoft store and after an
'apt-get update && apt-get install sbcl gcc make' I was able to
successfully build FriCAS 1.3.4, install it and all the tests passed
smoothly.
I did some simple comparison benchmarks of the build process between
MinGW64 and Linux with WSL
MinGW64 - WSL Linux
configure ~ 39 s ~ 9 s [2]
make ~ 5.46 min ~ 4.28 min [3]
make check ~ 2.2 min ~ .3 min [4]
FriCAS on Linux for Windows seems relatively competitive.
And for the fun I installed Xorg and Xrdp on Kali for Windows WSL (there
is also Debian,Ubuntu etc..). Using the Xrdp protocol I was able to run
https://drive.google.com/open?id=1-LTs3ezIPUaj4q4JseRlNaFcPnX-m6oJ
and a quick benchs, first Kali against MinGW64 and later, the last 3
screenshots, on a real Linux, Parrot, make & make test & matrix
https://drive.google.com/open?id=1v4XDegvs-klcip8w1gP3CI3lI6ZWvSaO

(61.5

Post by Grégory Vanuxem
min vs 67.6 min)
Parrot for a real Linux "comparison"
https://drive.google.com/open?id=1UCpMVScV6551OCDhh6LS_v5i04vVhbNx
(building : 2.4 min)
https://drive.google.com/open?id=1S8KvJ17Nhyiwgt4NeUht199a90fUp8Cq
('make test' : 1.2 min)
https://drive.google.com/open?id=1raDAVVs1Dpb84tF7ZhOr7FkifAw9SLgO
(1000x1000 SF matrix multiplication 55.5 min)
And after I had to go work :)
That's all.
I hope you enjoy and I would like to test this with you with other
distros in the Microsoft store, document that and eventually make
packages availables.
--
Greg
[1] msys2-x86_64-20180531.exe - https://www.msys2.org/ - SBCL x64

binary

Post by Grégory Vanuxem
from http://www.sbcl.org/platform-table.html - 1.4.2
[2] https://drive.google.com/open?id=13lZNNtGHmZiLOom9kxIaQNCPc511nA41
[3] https://drive.google.com/open?id=1KjtdDhF1j0UfbadCP6WLZVtoBid_aNDI
[4] https://drive.google.com/open?id=16cq6a_d2jDdGTiIFr7S4nu_eJL-gr-5a
--
You received this message because you are subscribed to the Google
Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[Waldek Hebisch]

Post by Grégory Vanuxem
Am rebuilding it and I spoke earlier about an issue in c-funs.c near line
I don't know how you want to solve that but the offending code to build
int
makedir(char *path)
{
#ifdef S_IRWXO
return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
#else
return ( mkdir (path) );
#endif
}
Here the preprocessor take the first call but it needs to take ' return (
mkdir (path) );'

I have read what MinGW people wrote: they suggest puting WIN32
in condition. For now that would probably work, but I do
not like. One reasin is because Microsoft some day may decide
that Windows (they seem to call all their OS products Windows)
is no longer WIN32 and break it that way. For me its looks
better to test which variant compiles -- after all we do not
care if system is Windows or not but if 'mkdir' with two
arguments works or not. Given that test is try to compile
our code, I am tempted to add somwhat evil logic to Makefile:

- try to compile two argument version, if it works use the resulting
object file
- if first step failed, try one argument version, it it compiles
ose the resulting object file
- if both compiles above failed issue error message and fail
(which normally stops build)

[oldk1331]

I don't see why we should not use __WIN32__ macro:

1. It will be a long time till Microsoft deprecate WIN32, even
after that, I'm sure MS will maintain backwards compatibility for
a long time.

2. In order to have better cross platform support, WIN32 is unavoidable.

3. BTW, MS has deprecated "mkdir", use "_mkdir" instead.

Post by Waldek Hebisch
I have read what MinGW people wrote: they suggest puting WIN32
in condition. For now that would probably work, but I do
not like. One reasin is because Microsoft some day may decide
that Windows (they seem to call all their OS products Windows)
is no longer WIN32 and break it that way. For me its looks
better to test which variant compiles -- after all we do not
care if system is Windows or not but if 'mkdir' with two
arguments works or not. Given that test is try to compile
- try to compile two argument version, if it works use the resulting
object file
- if first step failed, try one argument version, it it compiles
ose the resulting object file
- if both compiles above failed issue error message and fail
(which normally stops build)

[Grégory Vanuxem]

Hello,

I have quickly looked into this also and yes Microsoft deprecates use of
mkdir for _mkdir
See : https://msdn.microsoft.com/en-us/library/ms235326.aspx

But MinGW/GCC etc. are not Microsoft. I have found in the past the WIN32,
WIN and even WIN64 macros.

Personally I'm also in favor of the dark side of the force here to
paraphrase Waldek.
Whether we use mkdir or _mkdir with or without argument what we want is
something that compiles here.
It could be a headache to play with different filesystems and their
interface, and even if I don't think Microsoft or MinGW will remove
the WIN32 macro the simpliest is I think testing code here.

Just my two cents

--
Greg

Post by oldk1331
1. It will be a long time till Microsoft deprecate WIN32, even
after that, I'm sure MS will maintain backwards compatibility for
a long time.
2. In order to have better cross platform support, WIN32 is unavoidable.
3. BTW, MS has deprecated "mkdir", use "_mkdir" instead.

Post by Waldek Hebisch
I have read what MinGW people wrote: they suggest puting WIN32
in condition. For now that would probably work, but I do
not like. One reasin is because Microsoft some day may decide
that Windows (they seem to call all their OS products Windows)
is no longer WIN32 and break it that way. For me its looks
better to test which variant compiles -- after all we do not
care if system is Windows or not but if 'mkdir' with two
arguments works or not. Given that test is try to compile
- try to compile two argument version, if it works use the resulting
object file
- if first step failed, try one argument version, it it compiles
ose the resulting object file
- if both compiles above failed issue error message and fail
(which normally stops build)

--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[Grégory Vanuxem]

Hi,

I looked more deeply into this.

Microsoft with its compiler recommends to use _WIN32 and _WIN64 macros
whether we build a 32 bits or a 64 bits software. (see documentation of
Microsoft Developer Network - MSDN:
https://msdn.microsoft.com/en-us/library/b0084kay.aspx).

On the other hand with MinGW/GCC it's not as easy as it seems. As an
example see this discussion : https://reviews.llvm.org/D40285

But MinGW/GCC defines effectively these macros to follow Microsoft
conventions so I suggest to use something like :

=================================================
--- src/lib/cfuns-c.c.old 2018-10-29 08:39:29.390556000 +0100
+++ src/lib/cfuns-c.c 2018-10-29 09:37:37.408398400 +0100
@@ -110,7 +110,7 @@
int
makedir(char *path)
{
-#ifdef S_IRWXO
+#if !defined _WIN32 && !defined _WIN64 && defined S_IRWXO
return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
#else
return ( mkdir (path) );
=================================================

It remains the Cygwin case, I do not know how the Cygwin compiler behaves.
I know the __CYGWIN__ macro can be used.

Any comments appreciated.

__
Greg

Post by Grégory Vanuxem
Hello,
I have quickly looked into this also and yes Microsoft deprecates use of
mkdir for _mkdir
But MinGW/GCC etc. are not Microsoft. I have found in the past the WIN32,
WIN and even WIN64 macros.
Personally I'm also in favor of the dark side of the force here to
paraphrase Waldek.
Whether we use mkdir or _mkdir with or without argument what we want is
something that compiles here.
It could be a headache to play with different filesystems and their
interface, and even if I don't think Microsoft or MinGW will remove
the WIN32 macro the simpliest is I think testing code here.
Just my two cents
--
Greg

Post by oldk1331
1. It will be a long time till Microsoft deprecate WIN32, even
after that, I'm sure MS will maintain backwards compatibility for
a long time.
2. In order to have better cross platform support, WIN32 is unavoidable.
3. BTW, MS has deprecated "mkdir", use "_mkdir" instead.

Post by Waldek Hebisch
I have read what MinGW people wrote: they suggest puting WIN32
in condition. For now that would probably work, but I do
not like. One reasin is because Microsoft some day may decide
that Windows (they seem to call all their OS products Windows)
is no longer WIN32 and break it that way. For me its looks
better to test which variant compiles -- after all we do not
care if system is Windows or not but if 'mkdir' with two
arguments works or not. Given that test is try to compile
- try to compile two argument version, if it works use the resulting
object file
- if first step failed, try one argument version, it it compiles
ose the resulting object file
- if both compiles above failed issue error message and fail
(which normally stops build)

--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.