fricas on ECL on windows
22 views
Skip to first unread message
Qian Yun
Jul 21, 2026, 9:41:51 AM (yesterday) Jul 21
to fricas-devel
I've made fricas build with ECL on windows in CI a while ago,
but today it's my first time to try to run the binary myself.
I just made a commit to make it work. On windows, the "cmp"
module does not exist by default, (in CI it comes from build
directory), if we don't load it, I've confirmed the bytecode
compiler works.
After that, the immediate problem: anti virus program.
Since ECL compiles each domain into a separate executable,
loading each of them will trigger a virus scan, cost a few seconds,
or over ten seconds if "cloud based threat detection" is enabled.
That means computing a simple integral can take minutes for the
first try.
I suggest we add an extra build mode that builds a single executable,
instead of 1400+.
It should also reduce the build size, because of all these duplicated
PE headers. (On windows, ecl build is over 100MB while sbcl build
is 34MB.)
BTW, for cygwin build, I'm still trying to figure out why the build
takes 3 hours and "make check" takes 2 hours. The mingw64 build
takes 1 hours and "make check" takes 3 minutes, for comparison.
- Qian
but today it's my first time to try to run the binary myself.
I just made a commit to make it work. On windows, the "cmp"
module does not exist by default, (in CI it comes from build
directory), if we don't load it, I've confirmed the bytecode
compiler works.
After that, the immediate problem: anti virus program.
Since ECL compiles each domain into a separate executable,
loading each of them will trigger a virus scan, cost a few seconds,
or over ten seconds if "cloud based threat detection" is enabled.
That means computing a simple integral can take minutes for the
first try.
I suggest we add an extra build mode that builds a single executable,
instead of 1400+.
It should also reduce the build size, because of all these duplicated
PE headers. (On windows, ecl build is over 100MB while sbcl build
is 34MB.)
BTW, for cygwin build, I'm still trying to figure out why the build
takes 3 hours and "make check" takes 2 hours. The mingw64 build
takes 1 hours and "make check" takes 3 minutes, for comparison.
- Qian
Waldek Hebisch
Jul 21, 2026, 12:52:09 PM (yesterday) Jul 21
to fricas...@googlegroups.com
On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
> I've made fricas build with ECL on windows in CI a while ago,
> but today it's my first time to try to run the binary myself.
>
> I just made a commit to make it work. On windows, the "cmp"
> module does not exist by default, (in CI it comes from build
> directory), if we don't load it, I've confirmed the bytecode
> compiler works.
Last time that I looked at ECL related problem I was told
> I've made fricas build with ECL on windows in CI a while ago,
> but today it's my first time to try to run the binary myself.
>
> I just made a commit to make it work. On windows, the "cmp"
> module does not exist by default, (in CI it comes from build
> directory), if we don't load it, I've confirmed the bytecode
> compiler works.
that ECL FFI constructs only work in compiled code. Did
this change?
> After that, the immediate problem: anti virus program.
>
> Since ECL compiles each domain into a separate executable,
> loading each of them will trigger a virus scan, cost a few seconds,
> or over ten seconds if "cloud based threat detection" is enabled.
>
> That means computing a simple integral can take minutes for the
> first try.
seem to be used to it.
> I suggest we add an extra build mode that builds a single executable,
> instead of 1400+.
probably would increase space use.
> It should also reduce the build size, because of all these duplicated
> PE headers. (On windows, ecl build is over 100MB while sbcl build
> is 34MB.)
files. During compilation we load categories and core domains.
Database build loads everything.
> BTW, for cygwin build, I'm still trying to figure out why the build
> takes 3 hours and "make check" takes 2 hours. The mingw64 build
> takes 1 hours and "make check" takes 3 minutes, for comparison.
--
Waldek Hebisch
Dima Pasechnik
Jul 21, 2026, 1:24:37 PM (yesterday) Jul 21
to fricas...@googlegroups.com
On July 21, 2026 11:52:05 AM CDT, Waldek Hebisch <de...@fricas.org> wrote:
>On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
>> I've made fricas build with ECL on windows in CI a while ago,
>> but today it's my first time to try to run the binary myself.
>>
>> I just made a commit to make it work. On windows, the "cmp"
>> module does not exist by default, (in CI it comes from build
>> directory), if we don't load it, I've confirmed the bytecode
>> compiler works.
>
>Last time that I looked at ECL related problem I was told
>that ECL FFI constructs only work in compiled code. Did
>this change?
>
>> After that, the immediate problem: anti virus program.
>>
>> Since ECL compiles each domain into a separate executable,
>> loading each of them will trigger a virus scan, cost a few seconds,
>> or over ten seconds if "cloud based threat detection" is enabled.
>>
>> That means computing a simple integral can take minutes for the
>> first try.
>
>That is problem not only for FriCAS. People running antivirus
>seem to be used to it.
>
>> I suggest we add an extra build mode that builds a single executable,
>> instead of 1400+.
>
>That would add considerable complexity to the build system and
>probably would increase space use.
by "(require :maxima)", it wasn't something complex.
Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
>
>> It should also reduce the build size, because of all these duplicated
>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>> is 34MB.)
>
>Current build process depends on ability to load freshly compiled
>files. During compilation we load categories and core domains.
>Database build loads everything.
>
>> BTW, for cygwin build, I'm still trying to figure out why the build
>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
>> takes 1 hours and "make check" takes 3 minutes, for comparison.
>
>Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.
Dima
Qian Yun
Jul 21, 2026, 6:33:30 PM (20 hours ago) Jul 21
to fricas...@googlegroups.com
On 7/22/26 12:52 AM, Waldek Hebisch wrote:
> On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
>> I've made fricas build with ECL on windows in CI a while ago,
>> but today it's my first time to try to run the binary myself.
>>
>> I just made a commit to make it work. On windows, the "cmp"
>> module does not exist by default, (in CI it comes from build
>> directory), if we don't load it, I've confirmed the bytecode
>> compiler works.
>
> Last time that I looked at ECL related problem I was told
> that ECL FFI constructs only work in compiled code. Did
> this change?
I guess no. To be clear: during building fricas, "cmp" and
> On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
>> I've made fricas build with ECL on windows in CI a while ago,
>> but today it's my first time to try to run the binary myself.
>>
>> I just made a commit to make it work. On windows, the "cmp"
>> module does not exist by default, (in CI it comes from build
>> directory), if we don't load it, I've confirmed the bytecode
>> compiler works.
>
> Last time that I looked at ECL related problem I was told
> that ECL FFI constructs only work in compiled code. Did
> this change?
c compiler is still used. But when delivering the final
binary to end user's computer, "cmp" and c compiler is disabled,
and user can use bytecode compiler to do ")compiler xxx.spad".
>> After that, the immediate problem: anti virus program.
>>
>> Since ECL compiles each domain into a separate executable,
>> loading each of them will trigger a virus scan, cost a few seconds,
>> or over ten seconds if "cloud based threat detection" is enabled.
>>
>> That means computing a simple integral can take minutes for the
>> first try.
>
> That is problem not only for FriCAS. People running antivirus
> seem to be used to it.
to one application containing 1400+ binaries waiting to be scanning.
>> I suggest we add an extra build mode that builds a single executable,
>> instead of 1400+.
>
> That would add considerable complexity to the build system and
> probably would increase space use.
>
>> It should also reduce the build size, because of all these duplicated
>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>> is 34MB.)
>
> Current build process depends on ability to load freshly compiled
> files. During compilation we load categories and core domains.
> Database build loads everything.
>
I tried before that concat 1400+ lsp file into one and compile
to one single fas file.
Also, this approach can help fricas on ecl on wasm, because loading
domains one by one via network is too slow. Loading all domains
at once is faster.
- Qian
Qian Yun
Jul 21, 2026, 8:00:18 PM (18 hours ago) Jul 21
to fricas...@googlegroups.com
On 7/22/26 1:24 AM, Dima Pasechnik wrote:
>
>
>
>
> I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> by "(require :maxima)", it wasn't something complex.
>
> Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
>
>
Maxima can be built as pure lisp via ASDF. FriCAS does not support
>
>
>
>
> I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> by "(require :maxima)", it wasn't something complex.
>
> Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
>
>
that yet. This option can be explored.
>
>
>>
>>> It should also reduce the build size, because of all these duplicated
>>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>>> is 34MB.)
>>
>> Current build process depends on ability to load freshly compiled
>> files. During compilation we load categories and core domains.
>> Database build loads everything.
>>
>>> BTW, for cygwin build, I'm still trying to figure out why the build
>>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
>>> takes 1 hours and "make check" takes 3 minutes, for comparison.
>>
>> Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
>
> Yes, we used to build Sage (including ecl and Maxima) on Cygwin, and it was taking like 5 time more time than such a build on Linux.
> Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.
>
> Dima
>
The above "make check" difference is 40x. It can't be explained
by slow "fork". I didn't profile or debug deeper.
Just note it here that people should avoid fricas on ecl on cygwin
when possible.
- Qian
Dima Pasechnik
Jul 21, 2026, 8:15:19 PM (18 hours ago) Jul 21
to fricas...@googlegroups.com
On Tue, Jul 21, 2026 at 7:00 PM Qian Yun <oldk...@gmail.com> wrote:
>
> On 7/22/26 1:24 AM, Dima Pasechnik wrote:
> >
> >
> >
> >
> > I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> > by "(require :maxima)", it wasn't something complex.
> >
> > Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
> >
> >
>
> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> that yet. This option can be explored.
>
I don't know what "pure lisp" means here.
>
> On 7/22/26 1:24 AM, Dima Pasechnik wrote:
> >
> >
> >
> >
> > I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> > by "(require :maxima)", it wasn't something complex.
> >
> > Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
> >
> >
>
> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> that yet. This option can be explored.
>
What's the difference between https://github.com/oldk1331/fricas0
and "standard" Fricas?
I understand Fricas language (spad?) runs on top of a Lisp, just as
Maxima's language runs on top of a Lisp.
But perhaps it's not quite so.
> >
> >
> >>
> >>> It should also reduce the build size, because of all these duplicated
> >>> PE headers. (On windows, ecl build is over 100MB while sbcl build
> >>> is 34MB.)
> >>
> >> Current build process depends on ability to load freshly compiled
> >> files. During compilation we load categories and core domains.
> >> Database build loads everything.
> >>
> >>> BTW, for cygwin build, I'm still trying to figure out why the build
> >>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
> >>> takes 1 hours and "make check" takes 3 minutes, for comparison.
> >>
> >> Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
> >
> > Yes, we used to build Sage (including ecl and Maxima) on Cygwin, and it was taking like 5 time more time than such a build on Linux.
> > Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.
> >
> > Dima
> >
>
> Just tried my self, the computation is indeed very slow, over 10x.
> The above "make check" difference is 40x. It can't be explained
> by slow "fork". I didn't profile or debug deeper.
> Just note it here that people should avoid fricas on ecl on cygwin
> when possible.
>
> - Qian
>
> 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 email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/19c57c26-0532-4b84-89c8-46e62e546f0d%40gmail.com.
Qian Yun
Jul 21, 2026, 8:45:21 PM (18 hours ago) Jul 21
to fricas...@googlegroups.com
On 7/22/26 8:15 AM, Dima Pasechnik wrote:
>>
>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>> that yet. This option can be explored.
>>
> I don't know what "pure lisp" means here.
> What's the difference between https://github.com/oldk1331/fricas0
> and "standard" Fricas?
> I understand Fricas language (spad?) runs on top of a Lisp, just as
> Maxima's language runs on top of a Lisp.
> But perhaps it's not quite so.
>
"Pure lisp" build means lacking a few FFI C functions, especially
>>
>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>> that yet. This option can be explored.
>>
> I don't know what "pure lisp" means here.
> What's the difference between https://github.com/oldk1331/fricas0
> and "standard" Fricas?
> I understand Fricas language (spad?) runs on top of a Lisp, just as
> Maxima's language runs on top of a Lisp.
> But perhaps it's not quite so.
>
socket functions, so no communication with C components: hyperdoc,
graphics.
fricas0 is pure lisp, but not via ASDF, unlike maxima:
https://github.com/calyau/maxima/blob/master/src/maxima.asd
So compiling fricas into one single file is not as straight forward
as maxima.
- Qian
Dima Pasechnik
Jul 21, 2026, 10:06:52 PM (16 hours ago) Jul 21
to fricas...@googlegroups.com
On Tue, Jul 21, 2026 at 7:45 PM Qian Yun <oldk...@gmail.com> wrote:
>
> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
> >>
> >> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> >> that yet. This option can be explored.
> >>
> > I don't know what "pure lisp" means here.
> > What's the difference between https://github.com/oldk1331/fricas0
> > and "standard" Fricas?
> > I understand Fricas language (spad?) runs on top of a Lisp, just as
> > Maxima's language runs on top of a Lisp.
> > But perhaps it's not quite so.
> >
>
> "Pure lisp" build means lacking a few FFI C functions, especially
> socket functions, so no communication with C components: hyperdoc,
> graphics.
>
> fricas0 is pure lisp, but not via ASDF, unlike maxima:
> https://github.com/calyau/maxima/blob/master/src/maxima.asd
isn't it more or less trivial to create fricas.asd ?
>
> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
> >>
> >> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> >> that yet. This option can be explored.
> >>
> > I don't know what "pure lisp" means here.
> > What's the difference between https://github.com/oldk1331/fricas0
> > and "standard" Fricas?
> > I understand Fricas language (spad?) runs on top of a Lisp, just as
> > Maxima's language runs on top of a Lisp.
> > But perhaps it's not quite so.
> >
>
> "Pure lisp" build means lacking a few FFI C functions, especially
> socket functions, so no communication with C components: hyperdoc,
> graphics.
>
> fricas0 is pure lisp, but not via ASDF, unlike maxima:
> https://github.com/calyau/maxima/blob/master/src/maxima.asd
Basically, listing files into appropriate slots, no?
>
> So compiling fricas into one single file is not as straight forward
> as maxima.
>
> - Qian
>
> --
> 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 email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/99f1e6c8-927f-4d04-9355-f237262c5cbf%40gmail.com.
> 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 email to fricas-devel...@googlegroups.com.
Qian Yun
1:28 AM (13 hours ago) 1:28 AM
to fricas...@googlegroups.com
On 7/22/26 10:06 AM, Dima Pasechnik wrote:
> On Tue, Jul 21, 2026 at 7:45 PM Qian Yun <oldk...@gmail.com> wrote:
>>
>> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
>>>>
>>>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>>>> that yet. This option can be explored.
>>>>
>>> I don't know what "pure lisp" means here.
>>> What's the difference between https://github.com/oldk1331/fricas0
>>> and "standard" Fricas?
>>> I understand Fricas language (spad?) runs on top of a Lisp, just as
>>> Maxima's language runs on top of a Lisp.
>>> But perhaps it's not quite so.
>>>
>>
>> "Pure lisp" build means lacking a few FFI C functions, especially
>> socket functions, so no communication with C components: hyperdoc,
>> graphics.
>>
>> fricas0 is pure lisp, but not via ASDF, unlike maxima:
>> https://github.com/calyau/maxima/blob/master/src/maxima.asd
>
> isn't it more or less trivial to create fricas.asd ?
> Basically, listing files into appropriate slots, no?
>
Maybe, maybe not. I haven't tried. I guess the dependency
> On Tue, Jul 21, 2026 at 7:45 PM Qian Yun <oldk...@gmail.com> wrote:
>>
>> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
>>>>
>>>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>>>> that yet. This option can be explored.
>>>>
>>> I don't know what "pure lisp" means here.
>>> What's the difference between https://github.com/oldk1331/fricas0
>>> and "standard" Fricas?
>>> I understand Fricas language (spad?) runs on top of a Lisp, just as
>>> Maxima's language runs on top of a Lisp.
>>> But perhaps it's not quite so.
>>>
>>
>> "Pure lisp" build means lacking a few FFI C functions, especially
>> socket functions, so no communication with C components: hyperdoc,
>> graphics.
>>
>> fricas0 is pure lisp, but not via ASDF, unlike maxima:
>> https://github.com/calyau/maxima/blob/master/src/maxima.asd
>
> isn't it more or less trivial to create fricas.asd ?
> Basically, listing files into appropriate slots, no?
>
among lisp files should be specified, that could be a problem.
I can give it a try soon.
- Qian
Dima Pasechnik
4:20 AM (10 hours ago) 4:20 AM
to fricas...@googlegroups.com
> - Qian
>
> --
> 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 email to fricas-devel...@googlegroups.com.
Waldek Hebisch
9:50 AM (5 hours ago) 9:50 AM
to fricas...@googlegroups.com
executable code. It should not make much difference if the
code is in single piece or in several pieces.
Concerning many parts, various plugin architectures seem to be
quite popular, mayby not with 1400 parts, but certainly with
hundreds.
But if you have data showing that having code in one piece helps
then we can try to do something.
> >> I suggest we add an extra build mode that builds a single executable,
> >> instead of 1400+.
> >
> > That would add considerable complexity to the build system and
> > probably would increase space use.
> >
> >> It should also reduce the build size, because of all these duplicated
> >> PE headers. (On windows, ecl build is over 100MB while sbcl build
> >> is 34MB.)
> >
> > Current build process depends on ability to load freshly compiled
> > files. During compilation we load categories and core domains.
> > Database build loads everything.
> >
> I mean, don't change build step much, only change the final binary.
> I tried before that concat 1400+ lsp file into one and compile
> to one single fas file.
strigtforward, we have list of all NRLIB-s and there is question
of "linking" them. The question is how well ECL suports it. In
a sense it is just linking many object files. But there is some
magic on ECL side, for example ECL wants to run init routines in
each object files. So basically it is question of ECL.
When building interpreter with ECL we use modified compile command,
so that we get linkable files. In algebra we use normal command
so that we get loadable .fas. In principle we could try third
command that produces both.
Another thing is using such a .fas. One way is to load it at
startup, but I am not sure if this would work well (once you
clear LOADED property on NRLIB name FriCAS will try to load
it second time).
> Also, this approach can help fricas on ecl on wasm, because loading
> domains one by one via network is too slow. Loading all domains
> at once is faster.
set up connection can transfer hundreds of files. Also, typical
FriCAS run should only use part of algebra, not the whole. So
there is less data to transfer and less compute time spend in
LOAD.
--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages