An Experimental Port of FriCAS to WebAssembly

[Yanshu Wang]

Hello.

I succeeded in porting FriCAS to WebAssembly so that it can run in browser in client side.

Try it here: https://wangyenshu.github.io/FriCAS-in-Browser/

See more details in the github repo: https://github.com/wangyenshu/FriCAS-in-Browser

It takes about one minute to load FriCAS in my Browser.

This port use cheerpx, which is a WebAssembly based runtime to execute x86 binaries on browser. Briefing speaking, it runs a container with ecl installed and load Qian Yun's pure common-lisp build of FriCAS by in browser.

Yanshu Wang

screenshot:

[Kurt Pagani]

Congrats! Awesome, indeed.
I hoped someone will do this sooner or later :)

On 18/01/2026 09:07, Yanshu Wang wrote:
> Hello.
>
> I succeeded in porting FriCAS to WebAssembly so that it can run in
> browser in client side.
>

> Try it here: https://wangyenshu.github.io/FriCAS-in-Browser/ <https://
> wangyenshu.github.io/FriCAS-in-Browser/>

> See more details in the github repo: https://github.com/wangyenshu/

> FriCAS-in-Browser <https://github.com/wangyenshu/FriCAS-in-Browser>

>
> It takes about one minute to load FriCAS in my Browser.
>
> This port use cheerpx, which is a WebAssembly based runtime to execute
> x86 binaries on browser. Briefing speaking, it runs a container with ecl
> installed and load Qian Yun's pure common-lisp build of FriCAS by in
> browser.
>
> Yanshu Wang
>
> screenshot:
>

> --
> 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 <mailto:fricas-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-
> devel/11dfc458-c601-4c44-a48d-9d7c0fadd90fn%40googlegroups.com <https://
> groups.google.com/d/msgid/fricas-devel/11dfc458-c601-4c44-
> a48d-9d7c0fadd90fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Old K]

Thanks for sharing.

I wonder if you know about that ECL can be cross compiled to WebAssembly directly,

and someone on the Maxima maillist did it that way. I believe that similar thing can be

done to FriCAS, although I haven’t tried yet. Maybe you are interested in that information.

BTW, I get errors when doing integration, fails at loading files:

  pthread_kill failed at suspend: errcode= 38

- Best,

- Qian

On Jan 18, 2026, at 4:47 PM, Yanshu Wang <wangyen...@gmail.com> wrote:



Hello.

I succeeded in porting FriCAS to WebAssembly so that it can run in browser in client side.

Try it here: https://wangyenshu.github.io/FriCAS-in-Browser/

See more details in the github repo: https://github.com/wangyenshu/FriCAS-in-Browser

It takes about one minute to load FriCAS in my Browser.

This port use cheerpx, which is a WebAssembly based runtime to execute x86 binaries on browser. Briefing speaking, it runs a container with ecl installed and load Qian Yun's pure common-lisp build of FriCAS by in browser.

Yanshu Wang

screenshot:

--
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/11dfc458-c601-4c44-a48d-9d7c0fadd90fn%40googlegroups.com.

[Kurt Pagani]

On 18/01/2026 12:09, Old K wrote:
> Thanks for sharing.
>
> I wonder if you know about that ECL can be cross compiled to WebAssembly
> directly,
> and someone on the Maxima maillist did it that way. I believe that
> similar thing can be
> done to FriCAS, although I haven’t tried yet. Maybe you are interested
> in that information.

Yes, e.g. Maxima runs in the browser this way (ECL).
https://maxima-on-wasm.pages.dev/

However, the Maxima pure Lisp build is "smoother" (IMO), in the sense
that it has less external dependencies. But of course, it should also be
possible for Fricas when we improved the lisp build ...

>
> BTW, I get errors when doing integration, fails at loading files:
>   pthread_kill failed at suspend: errcode= 38

I got this to (bit less when using "brave" instead of "firefox". The
current fricas lisp build loads on demand. Preloading might be safer?

>
> - Best,
> - Qian
>
>> On Jan 18, 2026, at 4:47 PM, Yanshu Wang <wangyen...@gmail.com>
>> wrote:
>>
>> 
>> Hello.
>>
>> I succeeded in porting FriCAS to WebAssembly so that it can run in
>> browser in client side.
>>

>> Try it here: https://wangyenshu.github.io/FriCAS-in-Browser/ <https://
>> wangyenshu.github.io/FriCAS-in-Browser/>

>> See more details in the github repo: https://github.com/wangyenshu/

>> FriCAS-in-Browser <https://github.com/wangyenshu/FriCAS-in-Browser>

>>
>> It takes about one minute to load FriCAS in my Browser.
>>
>> This port use cheerpx, which is a WebAssembly based runtime to execute
>> x86 binaries on browser. Briefing speaking, it runs a container with
>> ecl installed and load Qian Yun's pure common-lisp build of FriCAS by
>> in browser.
>>
>> Yanshu Wang
>>
>> screenshot:
>>

>> --
>> 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 <mailto:fricas-
>> devel+un...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/
>> fricas-devel/11dfc458-c601-4c44-a48d-9d7c0fadd90fn%40googlegroups.com

>> <https://groups.google.com/d/msgid/fricas-devel/11dfc458-c601-4c44-
>> a48d-9d7c0fadd90fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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 <mailto:fricas-
> devel+un...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-

> devel/67A80AA6-C712-4AD5-A3CB-F8E24227DCFF%40gmail.com <https://
> groups.google.com/d/msgid/fricas-devel/67A80AA6-C712-4AD5-A3CB-
> F8E24227DCFF%40gmail.com?utm_medium=email&utm_source=footer>.

[Yanshu Wang]

Thanks for your feedback.

I increase the initial heap to about 1GB. Now the integration works.

Screenshot of integrate(x*sqrt(x^2+1),x):

Complicated integration like integrate((x^20)*sqrt(x^2+1),x) also works.

However, Boehm garbage collector does not work in cheerpx. I guess cheerpx cannot handle some signals used by Boehm garbage collector. So it might be a problem how to clean up memory. The command )clear all works, though. I don't know if it can clear memory that is used in previous computation without Boehm garbage collector.

> Preloading might be safer?

I can try to use preloading when I have time. I hope preloading everything will not take too much memory.

> I wonder if you know about that ECL can be cross compiled to WebAssembly directly

This looks promising. I can try that way when I have time.

Best,

Yanshu Wang

[Qian Yun]

Now I can confirm integration works on my side.

This is an interesting project, so a few more questions:

1. the download seems rather big. Does the cheerpx
approach include an entire OS?

2. have you tried other lisps? Like SBCL?

3. you are using fricas0-1.3.10. I can try to update fricas0
to latest version.

- Best,
- Qian

[Yanshu Wang]

Hello Qian.

> 1. the download seems rather big. Does the cheerpx
approach include an entire OS?

Almost. It downloads the container built using dockerfile https://github.com/wangyenshu/FriCAS-in-Browser/blob/main/Dockerfile. Cheerpx can load ext2 images. Also I have to split that image into pieces so that it can be hosted on github pages. (the split script is in https://github.com/wangyenshu/FriCAS-in-Browser/blob/main/build.sh.) There file index.html has the script to glue them.

> 2. have you tried other lisps? Like SBCL?

No.

> 3. you are using fricas0-1.3.10. I can try to update fricas0
to latest version.

Thanks. You can modify the dockerfile and the cx.run parameter in index.html to do that.

Currently, cheerpx only support x86 binaries. And I heard that most browser has 2GB memory limit for WebAssembly. These are two difficulties for this method. I initially try to port sagemath to WebAssembly using the same manner. But I failed due to the 2GB limit. Maybe there are methods to bypass that, like storing disks in Indexdb rather than in memory. I haven't tried that. Another thing to mention is that several sagemath components are successfully ported to WebAssembly in this manner, like Singular CAS.

Best,

Yanshu Wang

[Yanshu Wang]

I did some experiments with WebAssembly version of ECL. I think running FriCAS on that is pretty doable.

I have written a build script to build the WebAssembly version of ECL. The repository is here:

https://github.com/wangyenshu/ecl-wasm

 

And there is a demo of ECL in browser:

https://wangyenshu.github.io/ecl-wasm/

It suffices to pack the pure lisp version of FriCAS into the virtual filesystem of emscripten. Maybe adding "--preload-file" flag to "emmake make" and modify the startup script of ECL to load FriCAS.

[Yanshu Wang]

Hello. This is what I could achieve with wasm version of ecl: 

It always stucks at br-saturn.lisp even when I allocate 1GB initial heap. I don't have a clue. Maybe the recursion is too much for WebAssembly to handle and patching the pure lisp version of fricas (I use https://github.com/oldk1331/fricas0) will work?

The repository is renamed and is here:

https://github.com/wangyenshu/fricas-wasm

The demo web page is here:

https://wangyenshu.github.io/fricas-wasm/

[Qian Yun]

First, you can skip loading the br-saturn file.

Second, you can try to load compiled lisp object file instead
of lisp source file.

- Qian

On 4/10/26 2:37 PM, Yanshu Wang wrote:
> Hello. This is what I could achieve with wasm version of ecl: 

> Screenshot_2026-04-10_14-20-14.png
> It always stucks at br-saturn.lisp even when I allocate 1GB initial
> heap. I don't have a clue. Maybe the recursion is too much for
> WebAssembly to handle and patching the pure lisp version of fricas (I

> use https://github.com/oldk1331/fricas0 <https://github.com/oldk1331/
> fricas0>) will work?

> The repository is renamed and is here:

> https://github.com/wangyenshu/fricas-wasm <https://github.com/
> wangyenshu/fricas-wasm>

> The demo web page is here:

> https://wangyenshu.github.io/fricas-wasm/ <https://wangyenshu.github.io/
> fricas-wasm/>

[Qian Yun]

With compiling lisp files to byte-code files "fasc",
I can get interpreter loading and compute very simple math,
loading more algebra files will OOM.

I highly suspect that this default ECL settings only have
a few hundred MB of memory available.
(As firefox tools showed me it only uses 130MB.)

The error message is:

Aborted(OOM) ecl.js:1:3888
abort http://127.0.0.1:8000/ecl.js:1
abortOnCannotGrowMemory http://127.0.0.1:8000/ecl.js:1
_emscripten_resize_heap http://127.0.0.1:8000/ecl.js:1

Can you try ALLOW_MEMORY_GROWTH with emscripten?

- Qian

[Yanshu Wang]

Hello Qian.

The flag ALLOW_MEMORY_GROWTH is already enabled. You can see the complete flag here:

https://github.com/wangyenshu/fricas-wasm/blob/main/build.sh

This script will build the wash version of ecl.

I can try to load the compiled files.

[Qian Yun]

I can't build wasm version of ecl. Can you tweak the various
memory related flags on your side and see if it makes a difference?

To bytecode compile fricas0, try to add following to fricas.lisp:

(ext:install-bytecodes-compiler)
(setq |$lisp_bin_filetype| "fasc")

ecl --load fricas ## then type: )lisp (load "lisp/compile-interp.lisp")

then modify lisp/interp.lisp to load fasc instead of lisp,
and regenerate fricas-fs.json.

I also need to put (ext:set-limit 'ext:heap-size 256000000)
at the top of fricas.lisp.

- Qian

On 4/10/26 7:23 PM, Yanshu Wang wrote:
> Hello Qian.
>
> The flag ALLOW_MEMORY_GROWTH is already enabled. You can see the
> complete flag here:

> https://github.com/wangyenshu/fricas-wasm/blob/main/build.sh <https://
> github.com/wangyenshu/fricas-wasm/blob/main/build.sh>

> This script will build the wash version of ecl.
>
> I can try to load the compiled files.
> On Friday, April 10, 2026 at 4:41:32 PM UTC+8 oldk1331 wrote:
>
> With compiling lisp files to byte-code files "fasc",
> I can get interpreter loading and compute very simple math,
> loading more algebra files will OOM.
>
> I highly suspect that this default ECL settings only have
> a few hundred MB of memory available.
> (As firefox tools showed me it only uses 130MB.)
>
> The error message is:
>
> Aborted(OOM) ecl.js:1:3888

> abort http://127.0.0.1:8000/ecl.js:1 <http://127.0.0.1:8000/ecl.js:1>

> abortOnCannotGrowMemory http://127.0.0.1:8000/ecl.js:1
> <http://127.0.0.1:8000/ecl.js:1>
> _emscripten_resize_heap http://127.0.0.1:8000/ecl.js:1
> <http://127.0.0.1:8000/ecl.js:1>
>
> Can you try ALLOW_MEMORY_GROWTH with emscripten?
>
> - Qian
>
> On 4/10/26 3:04 PM, Qian Yun wrote:
> > First, you can skip loading the br-saturn file.
> >
> > Second, you can try to load compiled lisp object file instead
> > of lisp source file.
> >
> > - Qian
> >
> > On 4/10/26 2:37 PM, Yanshu Wang wrote:
> >> Hello. This is what I could achieve with wasm version of ecl: 
> >> Screenshot_2026-04-10_14-20-14.png
> >> It always stucks at br-saturn.lisp even when I allocate 1GB initial
> >> heap. I don't have a clue. Maybe the recursion is too much for
> >> WebAssembly to handle and patching the pure lisp version of
> fricas (I
> >> use https://github.com/oldk1331/fricas0 <https://github.com/

> oldk1331/fricas0> <https://github.com/oldk1331/ <https://github.com/
> oldk1331/>

> >> fricas0>) will work?
> >> The repository is renamed and is here:
> >> https://github.com/wangyenshu/fricas-wasm <https://github.com/

> wangyenshu/fricas-wasm> <https://github.com/ <https://github.com/>

> >> wangyenshu/fricas-wasm>
> >> The demo web page is here:
> >> https://wangyenshu.github.io/fricas-wasm/ <https://

> wangyenshu.github.io/fricas-wasm/> <https://wangyenshu.github.io/
> <https://wangyenshu.github.io/>
> >> fricas-wasm/>

>
> --
> 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 <mailto:fricas-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-

> devel/2978c30f-5d7a-4684-b504-7056a5959d93n%40googlegroups.com <https://
> groups.google.com/d/msgid/fricas-devel/2978c30f-5d7a-4684-
> b504-7056a5959d93n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Yanshu Wang]

Thanks. It works! Although startup time takes 2min. FS.createLazyFile is too slow when loading a large amount of files. Preloading them into IDBFS is much faster. I may implement this when I have free time.

Try it here:

https://wangyenshu.github.io/fricas-wasm/

[Qian Yun]

The startup time is fine on my side: around 8 seconds, since
it is hosted locally. Maybe we can speed it up further by
combining several lisp files into one.

About the memory issue: your LD_FLAGS didn't take effect,
you should export it before emconfigure. I can now build
wasm version of ecl locally, and it does not have memory
issues, it now can do big computation like integration.

Just like "lisp/compile-interp.lisp", you can use
"lisp/compile-algebra.lisp" to pre-compile algebra files
into bytecode.

BTW, I've update fricas0 to 1.3.13.

- Qian

On 4/11/26 12:22 AM, Yanshu Wang wrote:
> Thanks. It works! Although startup time takes 2min. FS.createLazyFile is
> too slow when loading a large amount of files. Preloading them into
> IDBFS is much faster. I may implement this when I have free time.
> Try it here:

> https://wangyenshu.github.io/fricas-wasm/ <https://wangyenshu.github.io/
> fricas-wasm/>

> On Friday, April 10, 2026 at 7:56:14 PM UTC+8 oldk1331 wrote:
>
> I can't build wasm version of ecl. Can you tweak the various
> memory related flags on your side and see if it makes a difference?
>
> To bytecode compile fricas0, try to add following to fricas.lisp:
>
> (ext:install-bytecodes-compiler)
> (setq |$lisp_bin_filetype| "fasc")
>
> ecl --load fricas ## then type: )lisp (load "lisp/compile-interp.lisp")
>
> then modify lisp/interp.lisp to load fasc instead of lisp,
> and regenerate fricas-fs.json.
>
> I also need to put (ext:set-limit 'ext:heap-size 256000000)
> at the top of fricas.lisp.
>
> - Qian
>
> On 4/10/26 7:23 PM, Yanshu Wang wrote:
> > Hello Qian.
> >
> > The flag ALLOW_MEMORY_GROWTH is already enabled. You can see the
> > complete flag here:
> > https://github.com/wangyenshu/fricas-wasm/blob/main/build.sh
> <https://github.com/wangyenshu/fricas-wasm/blob/main/build.sh>

> <https://
> > github.com/wangyenshu/fricas-wasm/blob/main/build.sh <http://

> github.com/wangyenshu/fricas-wasm/blob/main/build.sh>>
> > This script will build the wash version of ecl.
> >
> > I can try to load the compiled files.
> > On Friday, April 10, 2026 at 4:41:32 PM UTC+8 oldk1331 wrote:
> >
> > With compiling lisp files to byte-code files "fasc",
> > I can get interpreter loading and compute very simple math,
> > loading more algebra files will OOM.
> >
> > I highly suspect that this default ECL settings only have
> > a few hundred MB of memory available.
> > (As firefox tools showed me it only uses 130MB.)
> >
> > The error message is:
> >
> > Aborted(OOM) ecl.js:1:3888
> > abort http://127.0.0.1:8000/ecl.js:1 <http://127.0.0.1:8000/

> ecl.js:1> <http://127.0.0.1:8000/ecl.js:1 <http://127.0.0.1:8000/

> ecl.js:1>>
> > abortOnCannotGrowMemory http://127.0.0.1:8000/ecl.js:1
> <http://127.0.0.1:8000/ecl.js:1>
> > <http://127.0.0.1:8000/ecl.js:1 <http://127.0.0.1:8000/ecl.js:1>>
> > _emscripten_resize_heap http://127.0.0.1:8000/ecl.js:1
> <http://127.0.0.1:8000/ecl.js:1>
> > <http://127.0.0.1:8000/ecl.js:1 <http://127.0.0.1:8000/ecl.js:1>>
> >
> > Can you try ALLOW_MEMORY_GROWTH with emscripten?
> >
> > - Qian
> >
> > On 4/10/26 3:04 PM, Qian Yun wrote:
> > > First, you can skip loading the br-saturn file.
> > >
> > > Second, you can try to load compiled lisp object file instead
> > > of lisp source file.
> > >
> > > - Qian
> > >
> > > On 4/10/26 2:37 PM, Yanshu Wang wrote:
> > >> Hello. This is what I could achieve with wasm version of ecl: 
> > >> Screenshot_2026-04-10_14-20-14.png
> > >> It always stucks at br-saturn.lisp even when I allocate 1GB
> initial
> > >> heap. I don't have a clue. Maybe the recursion is too much for
> > >> WebAssembly to handle and patching the pure lisp version of
> > fricas (I
> > >> use https://github.com/oldk1331/fricas0 <https://github.com/

> oldk1331/fricas0> <https://github.com/ <https://github.com/>

> > oldk1331/fricas0> <https://github.com/oldk1331/ <https://

> github.com/oldk1331/> <https://github.com/ <https://github.com/>

> > oldk1331/>
> > >> fricas0>) will work?
> > >> The repository is renamed and is here:
> > >> https://github.com/wangyenshu/fricas-wasm <https://github.com/
> wangyenshu/fricas-wasm> <https://github.com/ <https://github.com/>

> > wangyenshu/fricas-wasm> <https://github.com/ <https://github.com/>

> <https://github.com/ <https://github.com/>>
> > >> wangyenshu/fricas-wasm>
> > >> The demo web page is here:
> > >> https://wangyenshu.github.io/fricas-wasm/ <https://
> wangyenshu.github.io/fricas-wasm/> <https://

> > wangyenshu.github.io/fricas-wasm/ <http://wangyenshu.github.io/

> fricas-wasm/>> <https://wangyenshu.github.io/ <https://
> wangyenshu.github.io/>
> > <https://wangyenshu.github.io/ <https://wangyenshu.github.io/>>
> > >> fricas-wasm/>
> >
> > --
> > 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 <mailto:fricas-
> > devel+un...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> fricas- <https://groups.google.com/d/msgid/fricas->
> > devel/2978c30f-5d7a-4684-b504-7056a5959d93n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/fricas-devel/2978c30f-5d7a-4684-
> <http://groups.google.com/d/msgid/fricas-devel/2978c30f-5d7a-4684->
> > b504-7056a5959d93n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.

>
> --
> 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 <mailto:fricas-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-

> devel/fc611009-3324-4e4c-8a9b-454056caa03cn%40googlegroups.com <https://
> groups.google.com/d/msgid/fricas-devel/
> fc611009-3324-4e4c-8a9b-454056caa03cn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Yanshu Wang]

Hello Qian,

Thanks for your work. Could you share your build script or make a pull request to https://github.com/wangyenshu/fricas-wasm? After compiling algebra files, which file should be updated to let fricas use compiled bytecode?

[Qian Yun]

You can see:

https://github.com/oldk1331/fricas-wasm

for the main branch and gh-pages branch.

I combined interp/ into one, so now the fricas can be
ready in 2 seconds (once the files are cached).

https://oldk1331.github.io/fricas-wasm/

As for the compiled algebra files, fricas can autoload them.

I wonder how to load those numerous small algebra files faster?

- Qian

[Yanshu Wang]

That is great. But I cannot do integrate(x*sqrt(x^2+1),x), it gives the following error:

fricas-fs.js:48 Failed to initialize FriCAS FS: RangeError: Maximum call stack size exceeded
    at ecl.wasm:0x36ebc
    at ecl.wasm:0x3616a
    at ecl.wasm:0x367fb
    at ecl.wasm:0x6278f
    at ecl.wasm:0x2273e
    at ecl.wasm:0x36028
    at invoke_iii (ecl.js:1:86734)
    at ecl.wasm:0x38a3e
    at ecl.wasm:0x3616a
    at invoke_iii (ecl.js:1:86734)

> I wonder how to load those numerous small algebra files faster?

You can preload them into IDBFS. I see you already add the flag -lidbfs which is required. You can see this implementation in wasm version of gap-system for a reference:

https://github.com/wangyenshu/gap-wasm/tree/gap-wasm-lazyloading/etc/emscripten

Briefly speaking, here the gap-fs.js will preload all files in startup_manifest.json into IDBFS, and use lazy loading for other files.

You can modify fricas-fs.js like that. To build startup_manifest.json, put the nodejs script build_startup_manifest.js in web root and run it. Then visit localhost:9999. The script build_startup_manifest.js will record every resource that is loaded to startup_manifest.json.

To see the effect, you can try this wasm version of gap-system demo:

https://wangyenshu.github.io/gap-wasm/

[Qian Yun]

On 4/11/26 12:41 PM, Yanshu Wang wrote:
> That is great. But I cannot do integrate(x*sqrt(x^2+1),x), it gives the
> following error:
> fricas-fs.js:48 Failed to initialize FriCAS FS: RangeError: Maximum call
> stack size exceeded
>     at ecl.wasm:0x36ebc
>     at ecl.wasm:0x3616a
>     at ecl.wasm:0x367fb
>     at ecl.wasm:0x6278f
>     at ecl.wasm:0x2273e
>     at ecl.wasm:0x36028
>     at invoke_iii (ecl.js:1:86734)
>     at ecl.wasm:0x38a3e
>     at ecl.wasm:0x3616a
>     at invoke_iii (ecl.js:1:86734)

> Screenshot_2026-04-11_12-28-49.png
>

I saw this error as well. When I was using Chromium for a while.

I can compute this integral in firefox and freshly opened Chromium.

I guess this error is related to "fileList.forEach(function(appPath) {"
in fricas-fs.js, when fricas-fs.json is too long?

- Qian

[Qian Yun]

>
> I wonder how to load those numerous small algebra files faster?
>

Some thoughts:

1. use "--with-extra-files" flag of ECL, to build fricas as wasm
file. I haven't tried, this should give best performance but
need some engineer work.

https://gitlab.com/spaghettisalat/maxima/-/blame/emscripten-port-deployed/wasm/build.sh?ref_type=heads#L26

2. I just tried, you can easily cat all algebra files into one 34MB
lisp file, load it and modify "|load_quietly|" to do nothing and
you are good to go.

It will be relatively slow, but a few improvements:

2.1 gzip the file gives 3.9MB, much faster to download. You'll need
to decompress it in JS.

2.2 preload only the most popular domains, and lazy load the rest.

2.3 slice up the file into smaller chunks to get bytecode compiled.

- Qian

[Qian Yun]

>
> 2. I just tried, you can easily cat all algebra files into one 34MB
> lisp file, load it and modify "|load_quietly|" to do nothing and
> you are good to go.
>
> It will be relatively slow, but a few improvements:
>
> 2.1 gzip the file gives 3.9MB, much faster to download. You'll need
> to decompress it in JS.
>
> 2.2 preload only the most popular domains, and lazy load the rest.
>
> 2.3 slice up the file into smaller chunks to get bytecode compiled.
>
> - Qian
>

Just found out in ECL manual, that "Portable FASL files may be
concatenated, what leads to bundles."

So we can easily concatenate the 1406 small FASC file into one
27MB file.

(But the same does not work for interp/, here the file order matters,
we can split lisp/interp.lisp and build interp/ as 2 FASC files.)

Now at https://oldk1331.github.io/fricas-wasm/
You can have the full power of FriCAS, in 10 seconds and 55MB of
Internet transfer.

With more optimization, the limit should be around 4 seconds and
20MB of data download. That's more work to do. I believe current
result is already pretty usable and useful.

- Qian

[Yanshu Wang]

That is great. I have tried to preload all files into IDBFS. 

Web demo:

https://wangyenshu.github.io/fricas-wasm/

The performance is almost the same, 6s and 60MB transfer on firefox. It will be great to have multiple solutions. I switched back to raw lisp because I get this error when doing integration with compiled code:

   >> System error:

   The variable BLANK is unbound.

The remaining issue is that integration does not work on chrome. I get this :

Uncaught (in promise) RangeError: Maximum call stack size exceeded
    at ecl.wasm:0x361da
    at ecl.wasm:0x36821
    at ecl.wasm:0x627b5
    at ecl.wasm:0x22764
    at ecl.wasm:0x3604e

    at invoke_iii (ecl.js:1:86734)

    at ecl.wasm:0x38a64
    at ecl.wasm:0x36190

    at invoke_iii (ecl.js:1:86734)

    at ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x361da
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x3885b
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
$func324 @ ecl.wasm:0x36821
$func710 @ ecl.wasm:0x627b5
$func318 @ ecl.wasm:0x22764
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x361c9
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38c77
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x361c9
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38c77
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x361c9
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38c77
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x361c9
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38c77
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func320 @ ecl.wasm:0x36190
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func400 @ ecl.wasm:0x476d8
invoke_vii @ ecl.js:1
$func397 @ ecl.wasm:0x46a00
invoke_iiii @ ecl.js:1
$func2303 @ ecl.wasm:0x126ef9
$func320 @ ecl.wasm:0x2e8d8
$func322 @ ecl.wasm:0x364fa
$func2306 @ ecl.wasm:0x1290c4
$func709 @ ecl.wasm:0x622e1
$func318 @ ecl.wasm:0x22709
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func400 @ ecl.wasm:0x476d8
invoke_vii @ ecl.js:1
$func397 @ ecl.wasm:0x46a00
invoke_iiii @ ecl.js:1
$func2303 @ ecl.wasm:0x126ef9
$func320 @ ecl.wasm:0x2e8d8
$func322 @ ecl.wasm:0x364fa
$func2306 @ ecl.wasm:0x1290c4
invoke_iiii @ ecl.js:1
$func2312 @ ecl.wasm:0x12bdad
invoke_iii @ ecl.js:1
$func4035 @ ecl.wasm:0x2c62e1
$func318 @ ecl.wasm:0x22709
$func320 @ ecl.wasm:0x3604e
invoke_iii @ ecl.js:1
$func331 @ ecl.wasm:0x38a64
$func400 @ ecl.wasm:0x476d8
invoke_vii @ ecl.js:1
$func397 @ ecl.wasm:0x46a00
invoke_iiii @ ecl.js:1
$func4031 @ ecl.wasm:0x2c3c53
invoke_iiiii @ ecl.js:1
$__main_argc_argv @ ecl.wasm:0x464c
callMain @ ecl.js:1
doRun @ ecl.js:1
run @ ecl.js:1
removeRunDependency @ ecl.js:1
(anonymous) @ fricas-fs.js:90
await in (anonymous)
doCallback @ ecl.js:1
done @ ecl.js:1
transaction.oncomplete @ ecl.js:1

[Kurt Pagani]

+1

I tried and it already exceeds my expectations :)

I'm wondering why timing (set mess time on) always showing 0 sec?
There's no clue in the web console, but never mind, not so important.

---

6) -> )system ls

>> System error:
Could not spawn subprocess to run "sh".
C library explanation: Function not implemented.

(6) -> )lisp (lisp-implementation-type)

Value = "ECL"
(6) -> )lisp (lisp-implementation-version)

Value = "26.3.27"
(6) -> )lisp (get-universal-time)

Value = 3984890188
(6) -> )lisp (get-universal-time)

Value = 3984890211
(6) ->

>
> - Qian
>

[Ralf Hemmecke]

On 4/11/26 12:03, Yanshu Wang wrote:
> That is great. I have tried to preload all files into IDBFS.
>
> Web demo:
> https://wangyenshu.github.io/fricas-wasm/

WOW! Guys, that is pretty remarkable!!! Not that I will use it that way,
but still it's cool.

Is it somehow possible to get commandline history into this app?
I would like to press the arrow-up key to get the previous command I typed.

Ralf

[Kurt Pagani]

On 11/04/2026 12:11, 'Ralf Hemmecke' via FriCAS - computer algebra

system wrote:
> On 4/11/26 12:03, Yanshu Wang wrote:
>> That is great. I have tried to preload all files into IDBFS.
>>
>> Web demo:
>> https://wangyenshu.github.io/fricas-wasm/
>
> WOW! Guys, that is pretty remarkable!!!

Not that I will use it that way,
> but still it's cool.

Who knows? Anyhow it'll be beneficial for edu- and demo purposes (à la
SymPy live or Web REDUCE for instance).

>
> Is it somehow possible to get commandline history into this app?
> I would like to press the arrow-up key to get the previous command I typed.

There's https://www.npmjs.com/package/xterm-readline, an xterm.js addon,
and there are other terminal/console emulations, i.e certainly feasible
(at the moment it's like nosman ;).

>
> Ralf
>

[Yanshu Wang]

I think the next thing worth exploring could be integrating fricas with jupyterlite, the jupyterlab distribution powered by WebAssembly. The roadmap could be first write a ecl kernel for jupyterlab using xeus framework. Then compile it to WebAssembly. As a reference, there are integration of octave and jupyterlite in that way: https://blog.jupyter.org/gnu-octave-meets-jupyterlite-compute-anywhere-anytime-8b033afbbcdc

More referece:

https://xeus.readthedocs.io/en/latest/

https://github.com/jupyterlite/jupyterlite