FriCAS 1.3.10 is released

[Waldek Hebisch]

I have put sources and binaries of FriCAS 1.3.10 on Sourceforge.

--
Waldek Hebisch

[Nasser M. Abbasi]

Thanks for the release. I installed new Linux mint 21.2 and extracted the tar file.  When I do 

./configure

it gives error 

./configure
checking build system type... x86_64-linux-gnu
checking host system type... x86_64-linux-gnu
checking target system type... x86_64-linux-gnu
checking for make... make
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/me/TMP/fricas-1.3.10':
configure: error: C compiler cannot create executables
See `config.log' for more details
>

I do have gcc installed. It is part of the system

>which gcc
/usr/bin/gcc
>gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Here is link to the config.log generated 

Why does it say that gcc can't create exe? 

--Nasser

[Nasser M. Abbasi]

The ./configure does  

gcc -V
But it should be  gcc --version or gcc -v
>gcc -V
gcc: error: unrecognized command-line option ‘-V’
gcc: fatal error: no input files
compilation terminated.

>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

>gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Why is it using uppercase -V ?

--Nasser

[Qian Yun]

There's no problem on my machine.

The actual error is this:

====
configure:3373: checking whether the C compiler works
configure:3395: gcc conftest.c >&5
/usr/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
configure:3399: $? = 1
configure:3439: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "FriCAS"
| #define PACKAGE_TARNAME "fricas"
| #define PACKAGE_VERSION "1.3.10"
| #define PACKAGE_STRING "FriCAS 1.3.10"
| #define PACKAGE_BUGREPORT "fricas...@googlegroups.com"
| #define PACKAGE_URL "https://fricas.github.io"
| /* end confdefs.h. */
|
| int
| main (void)
| {
|
| ;
| return 0;
| }
configure:3444: error: in `/home/me/TMP/fricas-1.3.10':
configure:3446: error: C compiler cannot create executables
====

Can you confirm that your gcc can compile a "hello world"?

- Qian

On 1/10/24 07:32, 'Nasser M. Abbasi' via FriCAS - computer algebra

>> Here is link <https://12000.org/tmp/01092024/config.log> to the

[Nasser M. Abbasi]

Yes, it was system thing. On Linux mint, after installation one has to also manually do

sudo apt-get install build-essential

On Linux Manjaro, I never had to do this.  Now Fricas config runs ok
(I need to install LISP, but that is OK, will do that next)

>./configure
checking build system type... x86_64-linux-gnu
checking host system type... x86_64-linux-gnu
checking target system type... x86_64-linux-gnu
checking for make... make
checking for gcc... gcc

checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking for touch... touch
checking for mktemp... mktemp
checking for gawk... gawk
checking for gtar... no
checking for tar... tar
checking for ranlib... ranlib
checking for ar... ar
checking for latex... no
checking for makeindex... no
checking PREGENERATED... "/home/me/TMP/fricas-1.3.10/pre-generated"
checking for sbcl... no
configure: error: sbcl not found and no Lisp specified.
                      Install supported Lisp implementation and
                      use --with-lisp option to tell FriCAS
                      how to invoke your Lisp


Different Linuxes behave different. Very confusing.  

Thanks
--Nasser

[Qian Yun]

Hi Waldek,

I see that you have not pushed 1.3.10 tag to Github and not created
release page.

I suggest you to cherry-pick this commit to branch r1.3.10 first,
then do the tagging, so that binary builds from tag 1.3.10 will be
uploaded to the nightly builds page. And then you can download them
and upload them to 1.3.10 release page.

https://github.com/fricas/fricas/commit/8ba0305330ea6001bbf92d182f75054cef8c49eb

BTW, the linux amd64 binary seems fine to me.

- Qian

[Waldek Hebisch]

On Wed, Jan 10, 2024 at 08:40:04AM +0800, Qian Yun wrote:
> Hi Waldek,
>
> I see that you have not pushed 1.3.10 tag to Github and not created
> release page.

Due to Github password policy 1.3.10 is only at Sourceforge.

--
Waldek Hebisch

[Qian Yun]

Well, many linux distros and many people's scripts probably points to
Github release page.

I can do the Github release page mirror of sourceforge download page,
do you agree?

- Qian

[Nasser M. Abbasi]

fyi, installed OK on Linux mint 21.2


>which fricas
/usr/local/bin/fricas
>fricas
viewman not present, disabling graphics
hypertex not present, disabling HyperDoc
Checking for foreign routines
FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"
spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"
foreign routines found
openServer result 0
                       FriCAS Computer Algebra System
            Version: FriCAS 1.3.10 built with sbcl 2.1.11.debian
                 Timestamp: Tue Jan  9 09:09:38 PM CST 2024
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
 
Just make sure to run

sudo apt-get install build-essential

After installing Linux mint.

--Nasser

[Andrey G. Grozin]

Hello *,

I'm trying to build fricas-1.3.10 with sbcl-2.4.0 on Gentoo Linux, and I
get

; compiling file
"/var/tmp/portage/sci-mathematics/fricas-1.3.10/work/fricas-1.3.10/pre-generated/src/algebra/RSIMP.lsp"
(written 09 JAN 2024 10:48:55 PM):
Heap exhausted during garbage collection: 32768 bytes available, 32784
requested.
Immobile Object Counts
Gen layout fdefn symbol code Boxed Cons Raw Code SmMix Mixed
LgRaw LgCode LgMix Waste% Alloc Trig Dirty GCs Mem-age
1 0 0 0 0 210 80 12806 0 10 25
0 0 0 48.9 219909472 10737418 13131 0 1.0217
2 0 1376 0 0 2645 651 5652 3 68 416
0 0 81 27.9 224818880 17375962 5749 1 0.2565
3 0 0 0 0 0 0 0 0 0 0
0 0 0 0.0 0 2000000 0 0 0.0000
4 0 0 0 0 0 0 0 0 0 0
0 0 0 0.0 0 2000000 0 0 0.0000
5 0 0 0 0 0 0 0 0 0 0
0 0 0 0.0 0 2000000 0 0 0.0000
6 786 23661 26541 25734 424 133 13 3 32 17
0 0 63 2.3 21922912 2000000 26 0 0.0000
7 0 0 0 0 203 63 9158 0 7 4
0 0 0 48.5 159160480 2000000 9435 0 0.0000
Tot 786 25037 26541 25734 3482 927 27629 6 117 462
0 0 144 41.7 625810912 [58.3% of 1073741824 max]
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-FOR-GC-PENDING* = false
Collection trigger variables:
dynamic_space_size = 1073741824
bytes_allocated = 625810912
auto_gc_trigger = 484526147
bytes_consed_between_gcs = 53687091
fatal error encountered in SBCL pid 3144 tid 3144:
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
(GC in progress, oldspace=1, newspace=7)
ldb>

Any idea how to increase the memory for sbcl? My notebook has 16 Gb
memory, hope this is enough.

Andrey

[Qian Yun]

You can build with

./configure --with-lisp="sbcl --dynamic-space-size 4096"

BTW, I believe parallel build is not a problem anymore, can you
enable it for Gentoo?

- Qian

[Waldek Hebisch]

On Wed, Jan 10, 2024 at 09:00:38AM +0800, Qian Yun wrote:
> Well, many linux distros and many people's scripts probably points to
> Github release page.
>
> I can do the Github release page mirror of sourceforge download page,
> do you agree?

OK.

--
Waldek Hebisch

[Qian Yun]

I guess you can't login to Github web interface, right?

Can you still push tags to Github?

If so, please cherry-pick
https://github.com/fricas/fricas/commit/8ba0305330ea6001bbf92d182f75054cef8c49eb
to branch r1.3.10, do the tag and push to origin.

- Qian

[Waldek Hebisch]

On Tue, Jan 09, 2024 at 07:16:16PM -0800, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote:
> fyi, installed OK on Linux mint 21.2
>
>
> >which fricas
> /usr/local/bin/fricas
> >fricas
> viewman not present, disabling graphics
> hypertex not present, disabling HyperDoc

I am not sure if this is what you want, but you have build FriCAS
without graphic and HyperDoc support. If you want them you need
to install "development" X libraries. From INSTALL:

On Debian (or Ubuntu) install the following packages.

sudo apt install libx11-dev libxt-dev libice-dev \
libsm-dev libxau-dev libxdmcp-dev libxpm-dev

mint may have different package names, hopefully Google will
help to find correct names.

--
Waldek Hebisch

[Waldek Hebisch]

On Wed, Jan 10, 2024 at 04:34:41PM +0700, Andrey G. Grozin wrote:
> Hello *,
>
> I'm trying to build fricas-1.3.10 with sbcl-2.4.0 on Gentoo Linux, and I get
>
> ; compiling file "/var/tmp/portage/sci-mathematics/fricas-1.3.10/work/fricas-1.3.10/pre-generated/src/algebra/RSIMP.lsp"
> (written 09 JAN 2024 10:48:55 PM):
> Heap exhausted during garbage collection: 32768 bytes available, 32784
> requested.

<sbip>

> Any idea how to increase the memory for sbcl? My notebook has 16 Gb memory,
> hope this is enough.

I built sbcl-2.4.0 using

sh make.sh --dynamic-space-size=56Gb

That is enough to build FriCAS (this is on machine with 64Gb RAM, so
I tried close to max).
--
Waldek Hebisch

[Andrey G. Grozin]

On Wed, 10 Jan 2024, Qian Yun wrote:
> You can build with
> ./configure --with-lisp="sbcl --dynamic-space-size 4096"

./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/fricas-1.3.10
--htmldir=/usr/share/doc/fricas-1.3.10/html --libdir=/usr/lib64
--disable-aldor --with-lisp="sbcl --dynamic-space-size 4096" --with-x
--with-gmp
configure: error: unrecognized option: `--dynamic-space-size'
Try `./configure --help' for more information

Andrey

[Andrey G. Grozin]

On Wed, 10 Jan 2024, Waldek Hebisch wrote:
> I built sbcl-2.4.0 using
>
> sh make.sh --dynamic-space-size=56Gb
>
> That is enough to build FriCAS (this is on machine with 64Gb RAM, so
> I tried close to max).

My notebook has 16Gb RAM. Is there a chance that something smaller than
56Gb can be sufficient?

Andrey

[oldk1331]

Looks like a bash quoting problem. You may need to escape the quotes.

BTW, the default is 1GB. I usually test with 4GB. Not sure what the minimal is.

- 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 on the web visit https://groups.google.com/d/msgid/fricas-devel/aa5cc496-fc3d-b77a-a66c-da597a81512e%40starnew.inp.nsk.su.

[Waldek Hebisch]

I did another try, 2Gb is enough.

--
Waldek Hebisch

[Nasser M. Abbasi]

I think there is something not right here.  I am also getting same problem as posted above with sbcl

fatal error encountered in SBCL pid 6123 tid 6123:
Heap exhausted, game over.

I tried it on Linux manjaro, latest version with KDE version and XFCE version, and they both fail with same error.

Then I tried to build fricas 1.3.10 on same linux box where I now have a running 1.3.9, and it also gave same error.

>which sbcl
/usr/bin/sbcl
>sbcl --version
SBCL 2.3.11

But I build 1.3.9 OK on this same Linux with same lisp. So why 1.3.10 fail to build?

Using the suggested workaround

./configure --with-lisp="sbcl --dynamic-space-size 4096"

also did not work for me. escaping or now escaping. I could not get it to work.

Building sbcl from source it not practical. Asking people to search the net for lisp and download source files and
figure how to build it.

I never had to do this before with Fricas. I always install lisp using the package manager. One click and done.

And it always worked and caused no problem. I never had to play with memory sizes and any of this.

So something changed in 1.3.10.

Only on Linux mint 21.2 did I get clean build. But not on Linux Manjaro.  So will stick to Linux mint for now.

My linux box has 40 GB RAM. 

--Nasser

[Dima Pasechnik]

Perhaps something should be put into ~/.sbclrc to set this default bigger?

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAGBJN92vgLc4JufmEP%2BENNw%3DR7RpF1ww%2BhLfGRKri3WL-0hYrA%40mail.gmail.com.

[Nasser M. Abbasi]

fyi;

I just verified this again. I installed brand new Linux mint 21.2 again and installed SBCL from the package manager and did

sudo apt-get install build-essential
./configure
make

And it finished with no problem.  Same exact 1.3.10 tar file. Only difference I see is that Linux mint uses


e@me-VirtualBox:~/TMP/fricas-1.3.10$ which sbcl
/usr/bin/sbcl
me@me-VirtualBox:~/TMP/fricas-1.3.10$ sbcl --version
SBCL 2.1.11.debian

And Linux Manjaro where it gives error building is

>sbcl --version
SBCL 2.3.11

So it could be the different lisp is the problem conflicting with 1.3.10

--Nasser

[Waldek Hebisch]

On Wed, Jan 10, 2024 at 04:37:21PM +0000, Dima Pasechnik wrote:
> Perhaps something should be put into ~/.sbclrc to set this default bigger?

AFAIK it will not work: in sbcl size of woring area is determined
before any Lisp code is run (in a "loader" program).

--
Waldek Hebisch

[Dima Pasechnik]

On Wed, Jan 10, 2024 at 2:50 PM oldk1331 <oldk...@gmail.com> wrote:
>

> Looks like a bash quoting problem. You may need to escape the quotes.

I guess it was using pairs of single quotes (') rather than single
double quotes (")
Otherwise I don't know how to reproduce this error.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAGBJN92vgLc4JufmEP%2BENNw%3DR7RpF1ww%2BhLfGRKri3WL-0hYrA%40mail.gmail.com.

[Waldek Hebisch]

On Wed, Jan 10, 2024 at 07:57:55AM -0800, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote:
> I think there is something not right here. I am also getting same problem
> as posted above with sbcl
>
> fatal error encountered in SBCL pid 6123 tid 6123:
> Heap exhausted, game over.
>
> I tried it on Linux manjaro, latest version with KDE version and XFCE
> version, and they both fail with same error.
>
> Then I tried to build fricas 1.3.10 on same linux box where I now have a
> running 1.3.9, and it also gave same error.
>
> >which sbcl
> /usr/bin/sbcl
> >sbcl --version
> SBCL 2.3.11
>
> But I build 1.3.9 OK on this same Linux with same lisp. So why 1.3.10 fail
> to build?

The file causing failure was added in FriCAS 1.3.10, it is not present
in earlier versions.

> Using the suggested workaround
>
> ./configure --with-lisp="sbcl --dynamic-space-size 4096"
>
> also did not work for me. escaping or now escaping. I could not get it to
> work.

You can use your own sbcl "executable" (that is shell script). Put
the following into a file called 'my_sbcl' (or whatever you prefer):

#!/bin/sh
exec sbcl --dynamic-space-size 4096 "$@"


and do 'chmod 755 my_sbcl'. After that you can use 'my_sbcl'
as your Lisp.

> Building sbcl from source it not practical.

Actually, this is quite easy:

1) Dowwnload sbcl sources from www.sbcl.org
2) Unpack (untar) sources
3) cd to sbcl-x.y.z (where x.y.z is sbcl version)
4) sh make.sh --dynamic-space-size=8Gb --prefix=/path/to/install/directory
where /path/to/install/directory points to place where you want it
to live
5) sh install.sh

> Asking people to search the net
> for lisp and download source files and
> figure how to build it.
>
> I never had to do this before with Fricas. I always install lisp using the
> package manager. One click and done.
>
> And it always worked and caused no problem. I never had to play with memory
> sizes and any of this.

Good for you. 'sbcl' running out of memory during compliation is old
news. Some old versions had insane memory use (IIRC somebody tried
to give 200Gb to sbcl and it was still not enough), our 'configure'
refuses to build FriCAS with affected versions. I have built
FriCAS 1.3.10 using sbcl-2.3.9, so in last few version sbcl got
more memory hungry.

> So something changed in 1.3.10.

Something changed between sbcl-2.3.9 and sbcl-2.4.0. File added
to FriCAS 1.3.10, that is RSIMP.spad compiles fine using sbcl-2.3.9.

--
Waldek Hebisch

[Dima Pasechnik]

On Wednesday, January 10, 2024 at 12:40:08 AM UTC oldk1331 wrote:

Hi Waldek,

I see that you have not pushed 1.3.10 tag to Github and not created
release page.

there is still an incosistency wrt tags. There is no 1.3.10 tag,

only an r1.3.10 branch.

[Nasser M. Abbasi]

I did exactly as your suggested. Build sbcl 2.4.0 from sources. typed same commands you showed.

Verified it is installed ok. Added it to the path  and to LD_LIBRARY_PATH . Removed the earlier sbcl on the system.

export PATH=/usr/local/texlive/2023/bin/x86_64-linux:/mnt/g/public_html/scripts:/usr/local/bin:/usr/bin:/bin:$SAGE_ROOT:$SAGE_ROOT/local/bin:/home/me/TMP/Reduce-svn6658-src/bin:/home/me/TMP/sbcl_install/bin:$PATH


export LD_LIBRARY_PATH=/usr/local/lib:/mnt/g/public_html/scripts:/home/me/TMP/sbcl_install/lib:$LD_LIBRARY_PATH

>which sbcl
/home/me/TMP/sbcl_install/bin/sbcl
>sbcl --version
SBCL 2.4.0

Then from new session went to fricas 1.3.10 and did

./configure 

make

and it still gives same error

--------------------------------
; wrote /home/me/TMP/fricas-1.3.10/target/x86_64-linux-gnu/algebra/RSETGCD.fasl
; compilation finished in 0:00:00.096
Value = #P"/home/me/TMP/fricas-1.3.10/target/x86_64-linux-gnu/algebra/RSETGCD.fasl"
(1) ->
; compiling file "/home/me/TMP/fricas-1.3.10/pre-generated/src/algebra/RSIMP.lsp" (written 09 JAN 2024 09:48:55 AM):
Heap exhausted during garbage collection: 0 bytes available, 32784 requested.

        Immobile Object Counts
 Gen layout fdefn symbol   code  Boxed   Cons    Raw   Code  SmMix  Mixed  LgRaw LgCode  LgMix Waste%       Alloc        Trig   Dirty GCs Mem-age

  1      0      0      0      0    461    152  20090      0     14     53      0      0      0   48.4   351184640   224285322   20770   1  1.4203
  2      0   1376      0      0   1776    478   8504      3     42    310      0      0     82   37.3   230060864    18472746    9191   1  0.4782

  3      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  4      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  5      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000

  6    786  24394  27814  26389    472    153     55      3     34     18      0      0     68    2.2    25728768     2000000      27   0  0.0000
Tot    786  25770  27814  26389   2709    783  28649      6     90    381      0      0    150   43.5   606973888 [56.5% of 1073741824 max]

GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = true
   *STOP-FOR-GC-PENDING* = false
Collection trigger variables:
   dynamic_space_size = 1073741824

   bytes_allocated = 606973888
   auto_gc_trigger = 502833283
   bytes_consed_between_gcs = 53687091
fatal error encountered in SBCL pid 3856 tid 3856:

Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.

(GC in progress, oldspace=1, newspace=2)
--------------------------------------------------------------------------------

>which sbcl
/home/me/TMP/sbcl_install/bin/sbcl
>sbcl --version
SBCL 2.4.0

Here is the link to the config file

Any suggestion what else to try? I am on Linux manjaro, latest version.

>uname -a
Linux me-virtualbox 6.6.8-2-MANJARO #1 SMP PREEMPT_DYNAMIC Thu Dec 21 16:21:45 UTC 2023 x86_64 GNU/Linux

[Nasser M. Abbasi]

The link to the config file seems not be copied right. Here it is again

config.log

[Nasser M. Abbasi]

here is also the SBCL 2.4.0 build log file with all the commands and output 

[Ralf Hemmecke]

Why do you not add the "--with-lisp" option to configure as clearly
written here?

http://fricas.github.io/install.html#detailed-installation-instructions

Change 4096 to about 75% of your actual RAM. Since you said, you have
40GB, maybe you try with

../fricas/configure --with-lisp="sbcl --dynamic-space-size 30Gb"
--prefix=/tmp/usr --enable-gmp --enable-aldor

or provide a script as Waldek suggested.

https://groups.google.com/g/fricas-devel/c/LbB9fjm0110/m/dvA4N2rHBAAJ


You also said...

On 1/10/24 16:57, 'Nasser M. Abbasi' via FriCAS - computer algebra

system wrote:
> Using the suggested workaround
>
> ./configure --with-lisp="sbcl --dynamic-space-size 4096"
>
> also did not work for me. escaping or now escaping. I could not get
> it to work.

What exactly was the error if you compiled/make with

./configure --with-lisp="sbcl --dynamic-space-size 4096"

BTW, why don't you do an out-of-source build as suggested by the above URL?

Ralf

[Qian Yun]

Hi Andrey, Nasser:

This is the SBCL command to check heap size:

* (sb-ext:dynamic-space-size)
1073741824

Also note that this is wrong:
sbcl --dynamic-space-size=40Gb
sbcl --dynamic-space-size=4096

This is correct:
sbcl --dynamic-space-size 4096

* (sb-ext:dynamic-space-size)
4294967296

Please verify that you passed the correct
'--with-lisp="sbcl --dynamic-space-size 4096"'
to ./configure.

- Qian

[Waldek Hebisch]

On Thu, Jan 11, 2024 at 08:38:33AM +0800, Qian Yun wrote:
> Hi Andrey, Nasser:
>
> This is the SBCL command to check heap size:
>
> * (sb-ext:dynamic-space-size)
> 1073741824
>
> Also note that this is wrong:
> sbcl --dynamic-space-size=40Gb
> sbcl --dynamic-space-size=4096
>
> This is correct:
> sbcl --dynamic-space-size 4096
>
> * (sb-ext:dynamic-space-size)
> 4294967296
>
> Please verify that you passed the correct
> '--with-lisp="sbcl --dynamic-space-size 4096"'
> to ./configure.

There is possible confusion, when building sbcl

--dynamic-space-size=4Gb

is the correct way, see sbcl INSTALL:

: To configure SBCL with a non-standard default dynamic-space size,
: use the --dynamic-space-size option:
:
: $ sh make.sh --dynamic-space-size=4Gb

OTOH, on sbcl command line

--dynamic-space-size 4Gb

is the correct way.

AFAICS wrong way does not cause abort, so one may get quite far
without noticing that memory setting was ignored.

There is something messed up, to see what happened it would be
good to check is new buld sbcl has expected memory limit using
command that Qian gave, and if yes follow suggestion from Ralf
to give '--with-lisp' option to FriCAS configure.

FriCAS build log indicates that sbcl still has default memory
limit, so either wrong sbcl (but log indicates 2.4.0) or
something happened during sbcl build (but sbcl build log at
first glance looks OK).

--
Waldek Hebisch

[Andrey G. Grozin]

I've updated fricas to 1.3.10 in Gentoo Linux.

On Wed, 10 Jan 2024, Qian Yun wrote:
> You can build with
>
> ./configure --with-lisp="sbcl --dynamic-space-size 4096"

Thank you very much, after some experimentation with quoting, I've found a
variant which works.

> BTW, I believe parallel build is not a problem anymore, can you
> enable it for Gentoo?

I've removed the piece which suppressed parallel builds. seems to work
fine.

An alternative solution, which requires re-compiling sbcl with a larger
dynamic-space-size, is inconvenient for me. I'm the maintainer not only of
the fricas package, but also of the sbcl package in Gentoo. So,
technically, I could replace the sbcl package by a new revision, and to
make fricas depend on this new revision. But this sbcl package with a
larger dynamic-space-size might appear inconvenient for some Gentoo
users, e.g., with old or low-end hardware. It's much better to keep the
sbcl package as it was (with the default dynamic-space-size), and make
changes only in the fricas building process.

I thank everybody for suggestions,

Andrey

[Aravindh Krishnamoorthy]

Hello,

Thank you for the release!

Just chiming in to report that I (a FriCAS devel newbie) could successfully build and check the source code from GitHub on Windows 11/WSL2.0 Debian machine + use it with jFriCAS.

Configure command: ../fricas/configure --with-lisp="/home/ark/fricas/fricas/hsbcl_ql --dynamic-space-size 4096" --enable-gmp

FriCAS: https://github.com/fricas/fricas/releases/tag/1.3.10

jFriCAS: https://github.com/fricas/jfricas/commit/975273763c0d975e0014b43c0ba3733b3b327abd

I had two private changes on top of 1.3.0, which are as follows:

1. A script to generate hsbcl_ql above, which uses SBCL and Hunchentoot loaded via QuickLisp (https://www.quicklisp.org/).

2. Updates to configure.ac to disable HyperDoc by default.

A branch with these two commits is here: https://github.com/aravindh-krishnamoorthy/fricas/commits/1.3.10-ark/

Next week, I'll review the developer build documentation, as indicated earlier. Furthermore, at Ralf's convenience, I'll setup a discussion/call about the documentation changes + (eventually) a way to get figures directly in Jupyter Notebooks.

Thanks and best regards,

Aravindh Krishnamoorthy

On Tuesday 9 January 2024 at 20:09:14 UTC+1 Waldek Hebisch wrote:

I have put sources and binaries of FriCAS 1.3.10 on Sourceforge.

--
Waldek Hebisch

[Waldek Hebisch]

On Thu, Jan 11, 2024 at 05:29:28PM +0700, Andrey G. Grozin wrote:
> An alternative solution, which requires re-compiling sbcl with a larger
> dynamic-space-size, is inconvenient for me. I'm the maintainer not only of
> the fricas package, but also of the sbcl package in Gentoo. So, technically,
> I could replace the sbcl package by a new revision, and to make fricas
> depend on this new revision. But this sbcl package with a larger
> dynamic-space-size might appear inconvenient for some Gentoo users, e.g.,
> with old or low-end hardware. It's much better to keep the sbcl package as
> it was (with the default dynamic-space-size), and make changes only in the
> fricas building process.

Just concerning "benefits": for long time default sbcl setting on
64-bit machines was 8Gb. Closure CL has 512Gb default setting and
I heard no complaints about this. Current setting happend after
Suse imposed default 4Gb limit (via ulimit in user startup)
on virtual memory on all user processes. Due to this limit
sbcl binaries failed to run on Suse. So main benefit is for
environment with low ulimit settings. There may be some benefit
in stopping runaway programs, but that should be doable in
much less heavy-handed way. Namely, actual memory use of sbcl
is determined by garbage collector and garbage collection is
triggered when memory allocated to Lisp objects crosses
certain threshold. In principle it should be quite easy to
modify garbage collector to report "out of memory" instead of
expanding memory pool. It could be controlled at runtime by user
settable parameter. I do not know if this is already implemented,
but whoever thinks that low limit is useful should ask sbcl
folks for such a feature and use it instead of dynamic space
size setting (which is changeable only at startup and even then
only if executable does not already contain dynamic-space-size
option).

--
Waldek Hebisch

[Waldek Hebisch]

On Tue, Jan 16, 2024 at 06:08:35AM -0800, Aravindh Krishnamoorthy wrote:
> 2. Updates to configure.ac to disable HyperDoc by default.

I am not sure why you want this. If you do not have X, or do not
want to use X, then there is '--with-x=no' option to 'configure'.
I use this option on servers where access is text-only.

Or for some reason you want FriCAS graphics but want to specifically
disable HyperDoc?

--
Waldek Hebisch

[Aravindh Krishnamoorthy]

Dear Waldek,

Sorry for my late response.

> Or for some reason you want FriCAS graphics but want to specifically disable HyperDoc?

Unfortunately, this seems to be my personal preference. 

The FriCAS CLI and HyperDoc GUI look very dated to me. So, I use FriCAS primarily as a kernel for Jupyter notebook.

For the future, my hope is that I can interface "jFriCAS" with "jlfricas" (FriCAS with Julia by gvanuxem) and use Julia's plotting commands to show FriCAS plots in Jupyter notebooks.

Best regards,

Aravindh Krishnamoorthy

[Ignat Insarov]

I am of one mind with Aravindh on this.

I spent all day setting up Jupyter to work with FriCAS. The documentation is poor on this topic. This page: <https://fricas.github.io/install.html#hunchentoot-optional> — does not explain nearly enough. I had to refer to a number of other web sites to figure out what is SBCL, Quicklisp, Hunchentoot, and how to make them work. At least there is some documentation on their home pages. What is documented nowhere is how to put these pieces together to get FriCAS built with Hunchentoot baked in. I allow that this is an easy matter for a Lisp developer. But there are very few Common Lisp programmers in the world. I have experience with a number of languages and build systems, but I do not think I could have figured out how to build FriCAS with Hunchentoot had I not found Aravindh's patch.

The HyperDoc system looks very dated to me as well. I do not see myself using it. To make matters worse, when I ask it to solve an equation, it tries to launch `xterm`, which is not available on my system, and hangs. Annoyingly, HyperDoc pops up every time I restart my FriCAS Jupyter notebook. This is an annoyance that I wish I knew how to disable. I looked at Aravindh's patch but it seems to contain a lot of other changes so I am reluctant to apply it. I wish there was some way to configure FriCAS not to open HyperDoc at startup.

I think FriCAS would benefit from making it easier to integrate with Jupyter and other third party tools. This does not seem like a hard problem in principle, since all the pieces are already here. But having to customize the build instead of simply grabbing the binaries provided by my Linux distribution requires both effort and expertise, and all the rough edges make this option unattractive. A little polish would go a long way in making FriCAS more accessible and attractive.

I am grateful to Aravindh for making the patch available on his GitHub account and writing a letter to this mailing list linking to it.

[Dima Pasechnik]

To not use HyperDoc, run

./configure --with-x=no

(HyperDoc uses X11 for its GUI).

By the way, "./configure -h" will print a complete list of options available.

[Ralf Hemmecke]

Welcome Ignat!

On 12/21/24 16:47, Ignat Insarov wrote:
> I spent all day setting up Jupyter to work with FriCAS.

Please immediately write to fricas-devel next time you run into
troubles. Only if we know where people struggle can we try to improve
the situation.

>  The documentation is poor on this topic. This page: https://

> fricas.github.io/install.html#hunchentoot-optional — does not
> explain nearly enough.

Hmmm... I don't see where this is not enough, except, maybe, that it
doesn't say that for

tar -xf hsbcl-1.3.9.tar
cd hsbcl
./build_hsbcl > build_hsbcl.log 2>&1

to work, you must have SBCL installed and available from your PATH. But
otherwise, it is completely sufficient. What exactly was your problem?
Do you have suggestions to improve the documentation?

>  I had to refer to a number of other web sites to figure out what is
> SBCL, Quicklisp, Hunchentoot, and how to make them work.

Quicklisp is not really necessary.

> What is documented nowhere is how to put these pieces together to
> get FriCAS built with Hunchentoot baked in.

I accept this criticism, if you can tell me more clearly what you were
actually missing. That would help me in formulating the steps in a way
that could not only help you but also others in the future.

> Annoyingly, HyperDoc pops up every time I restart my FriCAS Jupyter
> notebook. This is an annoyance that I wish I knew how to disable.

That is easy. jFriCAS starts a new fricas for every jupyter notebook
that you open. You find here

https://jfricas.readthedocs.io/en/latest/misc.html#fricas-start-options

that you would have to look into fricaskernel.py.

Read

https://github.com/fricas/jfricas/blob/master/jfricas/fricaskernel.py#L496

and then do the respective changes in the fricaskernel.py that you have
installed. I, for example, have installed jfricas into a virtual
environment under $HOME/virtualenv/jfricas. So for me it is the file
lib/python3.12/site-packages/jfricas/fricaskernel.py
inside that directory.

I usually run jfricas with

pid = Popen(['gnome-terminal', '--title=jfricas', '--'] +
['fricas','-nosman','-eval',prereq,'-eval',start])

That still pops up a gnome-terminal, but this terminal is connected to
the FriCAS session that underlies the jupyter notebook. So you could
even modify variables from outside of the jupyter notebook.

> But having to customize the build instead of simply grabbing the
> binaries provided by my Linux distribution requires both effort and
> expertise, and all the rough edges make this option unattractive.

Yep, that's unfortunate. Currently, you cannot have FriCAS from the
Debian repository and run in a jupyter notebook. Two reasons: (1) Debian
FriCAS builds on top of GCL not SBCL and jfricas only works with SBCL at
the moment. (2) An SBCL with Hunchentoot included is needed to build
FriCAS. Linux distributions do not do this, so you currently have to
build FriCAS yourself if you want to run jfricas.

> A little polish would go a long way in making FriCAS more
> accessible and attractive.

It's not so easy. Qian works into the direction of making Hunchentoot
superfluous. And perhaps that would also solve the problem of jfricas
currently not running on LISPs different from SBCL.
Although .deb packages are possible to build, I don't have the expertise
and we need someone to maintain it in the official Debian repository
(not just GCL based, but also based on other LISPs).

Ralf

[Ignat Insarov]

> To not use HyperDoc, run
>
> ./configure --with-x=no
>
> (HyperDoc uses X11 for its GUI).

Thank you Dima. But it is not so simple.

1. Graphs (commands like `draw`) also need X11, right? I do not want
HyperDoc (at this time) but I still want to have graphs.
2. Few people would go to the length of rebuilding the whole program,
especially when it is clear that a setting or a flag should be enough.

I also found the command line flag `fricas -nosman`. It switches off
the HyperDoc window. But it also switches off graphs.

[Ignat Insarov]

I am glad to hear that you are enthusiastic about improving the
documentation. Tell me if there is anything specific I can help with.

As a first step, I can offer a general suggestion. Surely you have a
family member or a friend who is digitally literate but not familiar
with Common Lisp and FriCAS. Ask them to set up a FriCAS Jupyter
notebook and watch. Will they even be able to find the installation
guide? It is not linked to from the table of contents! This method is
called «usability testing» and you can find more details, for example,
in the book _About Face 3_, chapter 4.

Overall, this problem calls for two items of documentation: a guide
and an explanation.

* The guide would be a list of steps that can be performed with
minimal research. The three commands listed right now are clearly not
enough. Whence do I get this `hsbcl-1.3.9.tar`? How do I check if all
the steps succeeded — what should happen? At what point in the build
process do I run these commands, in what folder? This is also where
you can mention Quicklisp if it is helpful, or not mention Quicklisp
if it is not helpful. Usability testing will help you figure out the
best way.

* The explanation would define all the terms and give links where
appropriate. It would put everything in perspective. Maybe it would
say that FriCAS is based on Common Lisp and it needs to be built with
a specially prepared Common Lisp executable that has a web server
baked in. You should also explain what a «FriCAS distribution area» is
— I could not find it. Again, you can use ethnographic methods to
figure out if the explanation is clear.

You can read [Divio Documentation
System](https://docs.divio.com/documentation-system/) for more and
better suggestions on the topic of documentation.

> > Annoyingly, HyperDoc pops up every time I restart my FriCAS Jupyter
> > notebook. This is an annoyance that I wish I knew how to disable.
>
> That is easy. jFriCAS starts a new fricas for every jupyter notebook
> that you open. You find here
>
> https://jfricas.readthedocs.io/en/latest/misc.html#fricas-start-options
>
> that you would have to look into fricaskernel.py.
>
> Read
>
> https://github.com/fricas/jfricas/blob/master/jfricas/fricaskernel.py#L496
>
> and then do the respective changes in the fricaskernel.py that you have
> installed. I, for example, have installed jfricas into a virtual
> environment under $HOME/virtualenv/jfricas. So for me it is the file
> lib/python3.12/site-packages/jfricas/fricaskernel.py
> inside that directory.
>
> I usually run jfricas with
>
> pid = Popen(['gnome-terminal', '--title=jfricas', '--'] +
> ['fricas','-nosman','-eval',prereq,'-eval',start])
>
> That still pops up a gnome-terminal, but this terminal is connected to
> the FriCAS session that underlies the jupyter notebook. So you could
> even modify variables from outside of the jupyter notebook.

Thank you for this detailed example. I read the page you linked to
earlier today in the course of my research, but I was intimidated by
the need to edit the source code so I gave up. I see now there are
friendly comments in there — this is nice.

* I am not sure about `nosman` since it seems to also disable graphs,
and I do want graphs.

* I think this is a situation that calls for a configuration file. I
do not believe editing the source code should be the preferred way of
configuration, at least for the following two reasons:

- If `jfricas` is installed via a package manager, such a
modification would be erased when it is updated.
- Many people will find this task intimidating.

How FriCAS and jFriCAS should be configured is of course an
architectural decision that requires deep understanding of the code
and the use cases that need to be handled, so I cannot be of much help
here. If I may suggest something, I should say there should be one
place where everything may be configured. Right now there are at least
four places — build configuration, command line flags, Python source
code and the start-up profile file. This complexity seems needless to
me.

[Waldek Hebisch]

On Thu, Oct 24, 2024 at 10:59:31PM -0700, Aravindh Krishnamoorthy wrote:
> Dear Waldek,
>
> Sorry for my late response.

Sorry for delayed answer. I lost the context and had to look up
old messages, so I did not answer immediately. Ignat's message
remaided me about your message.

> > Or for some reason you want FriCAS graphics but want to specifically
> disable HyperDoc?
>
> Unfortunately, this seems to be my personal preference.
> The FriCAS CLI and HyperDoc GUI look very dated to me. So, I use FriCAS
> primarily as a kernel for Jupyter notebook.

OK, I understand that you _normally_ do not want to use HyperDoc.
That still is not a reason to not building it: if you build it
you can use it if at some moment you decide that maybe it is
of some use.

I looked at the patch and apparently you want to disable building
HyperDoc by default, that I find unacceptable. First, HyperDoc
offer some functionality that ATM have no satisfactory replacement.
Second, currently HyperDoc build builds several examples that beside
being examples test FriCAS functionality and of course we also
want info if HyperDoc build breaks.

Of course, if you _really_ do not want to build HyperDoc, then
extra option to configure to disable HyperDoc is OK.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Dec 21, 2024 at 07:47:06AM -0800, Ignat Insarov wrote:
> I am of one mind with Aravindh on this.
>

> The HyperDoc system looks very dated to me as well. I do not see myself
> using it. To make matters worse, when I ask it to solve an equation, it
> tries to launch `xterm`, which is not available on my system, and hangs.

What does "not available" mean here? 'xterm' is standard component
of X11, available in all Linux distributions that I know about and
in many other systems. Current Linux distributions allow you choice
of installed packages and you may decide to not install xterm.
Or do you mean that you are not allowed to add system components
to system that you use?

Anyway, FriCAS and HyperDoc depend on components in your system,
and simplest way to resolve such troubles is to install needed
components.

> Annoyingly, HyperDoc pops up every time I restart my FriCAS Jupyter
> notebook. This is an annoyance that I wish I knew how to disable.

Hmm, I can not comment on Jupyter, but on command line you can define
shell alias like:

alias fricas='fricas -noht'

Or edit 'fricas' shell script (possibly copying to a private
directory). If you edit systemwise 'fricas' then Jupyter
should use it.

> I looked
> at Aravindh's patch but it seems to contain a lot of other changes so I am
> reluctant to apply it. I wish there was some way to configure FriCAS not to
> open HyperDoc at startup.

"Entry point" to FriCAS is a shell script, one can edit it to get
different behaviour.

> I think FriCAS would benefit from making it easier to integrate with
> Jupyter and other third party tools. This does not seem like a hard problem
> in principle, since all the pieces are already here. But having to
> customize the build instead of simply grabbing the binaries provided by my
> Linux distribution requires both effort and expertise, and all the rough
> edges make this option unattractive. A little polish would go a long way in
> making FriCAS more accessible and attractive.

Well, we can not force Linux distributions to provide FriCAS packages.
AFAIK currently Gentoo has an sbcl-based packege, but it probably does
not contain parts needed to use Jupyter. There is Debian package,
but this one is based on gcl and can not work with Jupyter.

If you fetch FriCAS binary, recent binaries have needed support included.
You still need extra parts, but there is no need to rebuild FriCAS.

You apparently had trouble with 'hsbcl-1.3.9.tar', but that is an easy
way if you want to build from source.

--
Waldek Hebisch

[Grégory Vanuxem]

Hello here,

If you really want to have hunchentoot in Git cloned fricas:

git clone --depth=1 https://github.com/fricas/fricas.git
install SBCL and hunchentoot (on a Debian like system 'apt install
sbcl libgmp-dev cl-hunchentoot') or install quicklisp and hunchentoot
with quicklisp, see quicklisp documentation, that's very simple.

I just git cloned FriCAS, I attached two files and a patch to modify
configure.ac, configure and src/interp/Makefile.in, otherwise the
Makefile.in and configure.ac is also attached (if you use the two
files and not the patch issue 'autoconf' in the source tree to
regenerate the ./configure script.

After, a simple ./configure --enable-gmp --enable-hunchentoot will do the trick.
Eventually, see ./configure --help for quicklisp use.

The code to build FriCAS with Hunchentoot is from Ralf Hemmecke and
Kurt Pagani. I think Waldek wants another way to interface with
Jupyter if this has to be done. I am not sure. In any case avoid
multiple dependencies
.
- Greg

> --
> 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/Z2dVnwbHZlGfdP8A%40fricas.org.

[Grégory Vanuxem]

--enable-gmp and its apt installation is not necessary of course, it's
just a habit.

[Waldek Hebisch]

On Sun, Dec 22, 2024 at 04:49:50AM +0700, Ignat Insarov wrote:
> I am glad to hear that you are enthusiastic about improving the
> documentation. Tell me if there is anything specific I can help with.
>
> As a first step, I can offer a general suggestion. Surely you have a
> family member or a friend who is digitally literate but not familiar
> with Common Lisp and FriCAS. Ask them to set up a FriCAS Jupyter
> notebook and watch. Will they even be able to find the installation
> guide? It is not linked to from the table of contents! This method is
> called «usability testing» and you can find more details, for example,
> in the book _About Face 3_, chapter 4.

Well, for me this is not a workable proposal: FriCAS is really
for people interested in/needing mathematics, and my family have
no such interest. OTOH some of my fellow mathematicians installed
FriCAS. I admit, I have created hsbcl-1.3.9.tar, but I did not
intall Jupyter myself (Jupyter needs _a lot_ of system componets
and on my old system it would be too much trouble to install
them. I have now new system which I am still setting up and
eventually I will install Jupyter).

> Overall, this problem calls for two items of documentation: a guide
> and an explanation.
>
> * The guide would be a list of steps that can be performed with
> minimal research. The three commands listed right now are clearly not
> enough. Whence do I get this `hsbcl-1.3.9.tar`?

In FriCAS distribution area:

https://sourceforge.net/projects/fricas/files/fricas/1.3.9/hsbcl-1.3.9.tar

(the first Google hit for hsbcl-1.3.9.tar). Or corresponding area
on Github.

It may be confusing that this tarball is in subdriectory for
release 1.3.9, but this code did not change between FriCAS
releases.

> How do I check if all
> the steps succeeded — what should happen?

Instruction says:

... creates executable binary "hsbcl" ...

You should see new binary called "hsbcl".

> At what point in the build
> process do I run these commands,

Before rest of FriCAS build. After part about creating "hsbcl"
instruction says:

After creating "hsbcl" one can then configure FriCAS like
...

I assumed (maybe wrongly) that textual order and the word "After"
in fragment above should make clear order of steps.

>in what folder?

That is your choice, any should work.

> This is also where
> you can mention Quicklisp if it is helpful, or not mention Quicklisp
> if it is not helpful.

In instruction above mentioning Quicklisp is probably not helpful:
the point of "hsbcl-1.3.9.tar" is that you get all extras that must
be present in FriCAS binares as one package. In particular,
Quicklisp is not needed. Quicklisp may be useful for people
that already use it, in particular to Lisp programmers.

> Usability testing will help you figure out the
> best way.
>
> * The explanation would define all the terms and give links where
> appropriate. It would put everything in perspective. Maybe it would
> say that FriCAS is based on Common Lisp and it needs to be built with
> a specially prepared Common Lisp executable that has a web server
> baked in.

Instruction says:

The jFriCAS interface needs a web server built into FRICASsys binary.
This can be done by using Lisp (currently only SBCL) containing
the Hunchentoot web server.

So it essentially says what you suggest, except for, it does not
use word "based" (which could be easily misunderstood) or
"baked in" (which is quite fuzzy). It gives you all keywords
to find more info if desirable.

You should be able to build FriCAS with Jupyter interface without
understanding paragraph above. Similarly, you should be able
build and use FriCAS without knowing what Lisp is. In fact,
you should be able to contribute to FriCAS developement without
knowing what Lisp is.

> You should also explain what a «FriCAS distribution area» is

Well, Sourceforge and Github provide per project areas to distribute
releases, both source and binaries. «FriCAS distribution area»
is such an area for FriCAS. In release 1.3.9 this should have
been obvious, as hsbcl-1.3.9.tar is in the same directory
as fricas-1.3.9-full.tar.bz2 (that is source tarball).

Now we probably should give a link.

> Thank you for this detailed example. I read the page you linked to
> earlier today in the course of my research, but I was intimidated by
> the need to edit the source code so I gave up. I see now there are
> friendly comments in there — this is nice.
>
> * I am not sure about `nosman` since it seems to also disable graphs,
> and I do want graphs.
>
> * I think this is a situation that calls for a configuration file. I
> do not believe editing the source code should be the preferred way of
> configuration, at least for the following two reasons:
>
> - If `jfricas` is installed via a package manager, such a
> modification would be erased when it is updated.

Well, when using package manager there is always question who
is in charge: package manager or a user. Modern approach
is to put user modifications in separate files which are
used from files provided by package. It makes little difference
it this is source code or configuration file. Rather, the
point is that information is in multiple files with differing
"authority" over files: some are "user" files, some possibly
for other packages, some maybe for system administrator,
some coming from base source. Linux distributions have
various policies with respect to such files, so I am not
sure what we (that is FriCAS project) should do. 'jfricas'
currently is not packaged, so this is not an issue.

> - Many people will find this task intimidating.

Using FriCAS is essentially writing source code in FriCAS
language (maybe line by line, but still). I hope that
people are not intimidated by this.

> How FriCAS and jFriCAS should be configured is of course an
> architectural decision that requires deep understanding of the code
> and the use cases that need to be handled, so I cannot be of much help
> here. If I may suggest something, I should say there should be one
> place where everything may be configured. Right now there are at least
> four places — build configuration, command line flags, Python source
> code and the start-up profile file. This complexity seems needless to
> me.

Part of this is thechnical neccesity (or maybe technical simplicity):
build configuration specifies info needed to compile FriCAS and some
hardcoded defaults. It is not possible to do this later: without
proper info build may fail and hardcoded things can not be changed
later. Command line flags are easily changable things which users
may wish to change. For technical reasons FriCAS user init file can
not be run very early, so it can not change some things which are
changable on command line.

You skipped enviroment variables: they affect what FriCAS is
doing. Build configuration, command line options, enviroment
variables and init file are normal mechanisms used by many
other programs. In FriCAS some small important parts are source
code, so changing them allows users to do changes that would
be hard otherwise. Certainly, we aim that commonly requested
changes of behaviour could be done by one of earlier mechanisms.
But modifying source fragments is useful way to do unexpected
modifications.

--
Waldek Hebisch

[Ignat Insarov]

> > The HyperDoc system looks very dated to me as well. I do not see myself
> > using it. To make matters worse, when I ask it to solve an equation, it
> > tries to launch `xterm`, which is not available on my system, and hangs.
>
> What does "not available" mean here? 'xterm' is standard component
> of X11, available in all Linux distributions that I know about and
> in many other systems. Current Linux distributions allow you choice
> of installed packages and you may decide to not install xterm.
> Or do you mean that you are not allowed to add system components
> to system that you use?

What I mean is that `xterm` is something our forefathers wielded. Even
X11 itself is optional now as Wayland is widely offered. Even if maybe
you can expect people to be able to install `xterm`, there is no
reason to think they will like your opening an `xterm` window for them
— this is one side of the _«dated»_ characteristic. A better way to
open a terminal is to consult the `TERM` environment variable and open
what it says.

To be concrete, here is the situation on my current system:

```
% which 'xterm'
xterm not found
% echo "$TERM"
alacritty
```

> > Annoyingly, HyperDoc pops up every time I restart my FriCAS Jupyter
> > notebook. This is an annoyance that I wish I knew how to disable.
>
> Hmm, I can not comment on Jupyter, but on command line you can define
> shell alias like:
>
> alias fricas='fricas -noht'

This is exactly what I needed! And it is listed in the help message. I
had not noticed.

```
% fricas -h
…
-ht | -noht use HyperDoc (default: -ht)
…
```

I just checked and this works great when added to `fricaskernel.py`.

[Kurt Pagani]

On Sunday, 22 December 2024 at 12:42:18 UTC+1 kin...@gmail.com wrote:

> > The HyperDoc system looks very dated to me as well. I do not see myself
> > using it. To make matters worse, when I ask it to solve an equation, it
> > tries to launch `xterm`, which is not available on my system, and hangs.
>
> What does "not available" mean here? 'xterm' is standard component
> of X11, available in all Linux distributions that I know about and
> in many other systems. Current Linux distributions allow you choice
> of installed packages and you may decide to not install xterm.
> Or do you mean that you are not allowed to add system components
> to system that you use?

What I mean is that `xterm` is something our forefathers wielded. Even
X11 itself is optional now as Wayland is widely offered. Even if maybe
you can expect people to be able to install `xterm`, there is no
reason to think they will like your opening an `xterm` window for them
— this is one side of the _«dated»_ characteristic. A better way to
open a terminal is to consult the `TERM` environment variable and open
what it says.

To be concrete, here is the situation on my current system:

```
% which 'xterm'
xterm not found
% echo "$TERM"
alacritty
```

I would install it immediately ;-) It's still one of the best terminals if properly configured (Xresources).

BTW, Wayland is just a parade example what will happen when people are to eager to reinvent the wheel.

https://www.reddit.com/r/linux/comments/1dl833i/the_wayland_breaks_everything_gist_still_has/

The "Wayland breaks everything" gist still has people actively commenting to this day, after almost 4 years of being up. 

I have it disabled on all machines.

You are certainly right in that one could do a lot more with respect to aesthetics and attractiveness, however, focus is on math in the first place and it's a matter of fact that many systems have been sunset because of too much deference to users wishes.

[Ignat Insarov]

Thank you for your detailed answer, Waldek!

> > As a first step, I can offer a general suggestion. Surely you have a
> > family member or a friend who is digitally literate but not familiar
> > with Common Lisp and FriCAS. Ask them to set up a FriCAS Jupyter
> > notebook and watch. Will they even be able to find the installation
> > guide? It is not linked to from the table of contents! This method is
> > called «usability testing» and you can find more details, for example,
> > in the book _About Face 3_, chapter 4.
>
> Well, for me this is not a workable proposal: FriCAS is really
> for people interested in/needing mathematics, and my family have
> no such interest.

They have interest in you! Ask them to set up a FriCAS Jupyter
notebook as a favour. Purchase their interest with an offering of
their favourite snack. Do not give up so easily!

> > Whence do I get this `hsbcl-1.3.9.tar`?
>

> In FriCAS distribution area: …

>
> It may be confusing that this tarball is in subdriectory for
> release 1.3.9, but this code did not change between FriCAS
> releases.

I believe this is indeed confusing. But you do not need to trust me —
you can do usability testing and reveal the truth.

What is important here is the mindset of reducing friction to the
minimum. Ideally you want to provide a guide detailed enough that no
other documents need to be consulted. If you want to make the case
that the documentation already available is enough to solve the
problem — I agree, the totality of information already available on
the Internet was enough for me to solve the problem. The question is —
how long it takes. Every recourse to other documents takes time, and
open-ended search takes unbounded time.

> > … I think this is a situation that calls for a configuration file. …
>
> … Linux distributions have

> various policies with respect to such files, so I am not

> sure what we (that is FriCAS project) should do. …

I am not an expert on this, but my experience tells me people tend to
follow this standard:

https://specifications.freedesktop.org/basedir-spec/latest/

If you want to offer a _«retro»_, _«classic»_, _«old school»_ feel,
you can put configuration in `~/.jfricasrc` or something like that.
Anything would be better than editing source files.

> Using FriCAS is essentially writing source code in FriCAS
> language (maybe line by line, but still). I hope that
> people are not intimidated by this.

I believe the experiences of typing commands to an interpreter and of
editing source files you have no understanding of are very different.
You do not need to believe me — you can do some ethnographic research.
Ask your friends:

* how often they use a command line interpreter of one kind or another
* how often they edit configuration files
* how often they configure their tools by hacking on the source code

> 'jfricas' currently is not packaged, so this is not an issue.

I installed `jfricas` using `pip`. Does `pip` count as a package manager?

What I meant to say is this:

* If there are many ways I can configure a program, this is good.
* If there are many ways I am forced to use all at once in order to
configure a program, this is bad.

In my Jupyter FriCAS setup quest, I had to use a few different ways of
configuration, from command line flags to patching source code. This
was not great experience — in truth, this is the first time I had to
be so creative setting up a program _for a standard use case_ since
the times I had Slackware on my Pentium Pro.

> For technical reasons FriCAS user init file can
> not be run very early, so it can not change some things which are
> changable on command line.

This is odd. Would you be willing to summarize in a few words why this
is a hard problem? As I understand, FriCAS currently reads
`~/.fricas.input` and I guess it needs to first start its Lisp
interpreter up. Maybe this is what needs to be changed. Say there was
another file `~/.fricasrc` that is not written in Lisp or Spad but
rather in some simple configuration language like Ini, Yaml or Toml.
This file would hold settings mirroring command line options. Is this
a good idea?

I do not have much experience maintaining programs with many options
and ways of configuration, but my limited experience tells me that
usually on start-up a program would read configuration files,
environment variables and command line options all into one structure,
in this order, overwriting fields as needed. This makes sure that
exactly the same set of configurations can be accomplished in whatever
way the user is comfortable with.

[Dima Pasechnik]

On Sat, Dec 21, 2024 at 6:48 PM Waldek Hebisch <de...@fricas.org> wrote:
>
> On Sat, Dec 21, 2024 at 07:47:06AM -0800, Ignat Insarov wrote:
> > I am of one mind with Aravindh on this.
> >
> > The HyperDoc system looks very dated to me as well. I do not see myself
> > using it. To make matters worse, when I ask it to solve an equation, it
> > tries to launch `xterm`, which is not available on my system, and hangs.
>
> What does "not available" mean here? 'xterm' is standard component
> of X11, available in all Linux distributions that I know about and
> in many other systems. Current Linux distributions allow you choice
> of installed packages and you may decide to not install xterm.
> Or do you mean that you are not allowed to add system components
> to system that you use?

In some case it does not make sense, or next to impossible, to
properly install and use X11.

If you run FriCAS on a remote server, you don't want to communicate via X11:
it's a graphical connection, quite slow compared to text.
In this sense, Jupyter (a Jupyter notebook where your FriCAS session runs)
is much faster - its client, on your local machine,
basically talks to the remote in the way the browser talks to a server.

Similarly, if FriCAS runs in a local VM, it's the same issue: the VM
might not have
a good way to communicate via X11 to your host system. E.g. if your VM is a WSL
on a Windows machine, you don't want to set up an X11 server on Windows;
you'd rather communicate with Jupyter.

Dima

> --
> 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/Z2dhv1U3M8qMY9GQ%40fricas.org.

[Ignat Insarov]

Hello Kurt!

> > … To make matters worse, when I ask it to solve an equation, it tries to

> > launch `xterm`, which is not available on my system, and hangs.
>

> I would install it immediately ;-) It's still one of the best terminals if properly configured (Xresources).

> BTW, Wayland is just a parade example what will happen when people are to eager to reinvent the wheel. … I have it disabled on all machines.

I have extensive experience configuring `xterm` — not for me to say if
properly or not. Wayland works great for me for many years and I do
not miss the old times. But I think this conversation is off the topic
of this mailing list.

> You are certainly right in that one could do a lot more with respect to aesthetics and attractiveness, however, focus is on math in the first place and it's a matter of fact that many systems have been sunset because of too much deference to users wishes.

* How many systems have been sunset because of too much deference?
* How many systems have been sunset because of too little deference?

I agree that chasing every fashion is stupid, especially for a
research project that only a few people in the world can meaningfully
contribute to. But scaring away prospective users is a vicious circle.

One way forward with respect to launching a terminal emulator is to
have a setting for this and try a few popular terminal emulators as a
fallback. As I understand, the story with configuration files is
difficult right now. But hanging the whole program in response to a
click is simply bad engineering. Why does it need another terminal
emulator anyway? It already has one.

To be specific, what I do is:

* start FriCAS with HyperDoc
* navigate: References — Topics — Solving Equations — Solution of a
Single Polynomial Equation
* click `solve(x^3 = 8, x)`

[Dima Pasechnik]

Demanding a "proper" X11 in 2024 is akin to demanding anonymous ftp and open smtp relays.

There are systems where Wayland is the only thing that works, e.g. on Chromebooks.

[Waldek Hebisch]

On Sun, Dec 22, 2024 at 06:42:01PM +0700, Ignat Insarov wrote:
> > > The HyperDoc system looks very dated to me as well. I do not see myself
> > > using it. To make matters worse, when I ask it to solve an equation, it
> > > tries to launch `xterm`, which is not available on my system, and hangs.
> >
> > What does "not available" mean here? 'xterm' is standard component
> > of X11, available in all Linux distributions that I know about and
> > in many other systems. Current Linux distributions allow you choice
> > of installed packages and you may decide to not install xterm.
> > Or do you mean that you are not allowed to add system components
> > to system that you use?
>
> What I mean is that `xterm` is something our forefathers wielded. Even
> X11 itself is optional now as Wayland is widely offered.

Well, there is fraction of open source developers that believe
that their moral duty is to break any software that is more than
few years old. However, there are also people who value
stability. Stability requires stable interfaces, and for
graphic current stable interface is X11. It is unfortunate, but
fact of the life that various "modern" layes quickly changed
in incompatible ways breaking software using it. 'xterm'
is part of that interface. It does not have to be actual
'xterm', but the issue is more tricky than you think. I tried
to start 'lxterminal' instead of 'xterm'. First trouble was
that 'lxterminal' does not accept some 'xterm' options and
fails to start due to unrecognized options. This can be worked
around with some loss of functionality (FriCAS passes window title
as an option to 'xterm', 'lxterminal' apparently makes up a silly
name without any way to change it). But after working around
this problem 'lxterminal' window pops up, but FriCAS output is
not there. ATM I do not know why, but there is protocol of
interaction between program and terminal emulator and
apparently it is different between 'xterm' and 'lxterminal'.
To be clear: FriCAS works fine when started from command line
in 'lxterminal', the trouble is when 'lxterminal' is started
from FriCAS.

Anyway, bottom line is: 'xterm' works, other terminal emulators
may require changes to FriCAS before they work.

> Even if maybe
> you can expect people to be able to install `xterm`, there is no
> reason to think they will like your opening an `xterm` window for them
> — this is one side of the _«dated»_ characteristic. A better way to
> open a terminal is to consult the `TERM` environment variable and open
> what it says.

Sorry, using TERM is quite wrong, TERM says how a program should
talk to a terminal, and not which _terminal emulator_ a program
should use. In particular, TERM may have values which correspond
to no terminal emulator.

I agree that it would be nice to have ability to start a different
terminal emulator, but ATM at least some terminal emulators do not
work.

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Dec 22, 2024 at 08:02:17PM +0700, Ignat Insarov wrote:
>
> > 'jfricas' currently is not packaged, so this is not an issue.
>
> I installed `jfricas` using `pip`. Does `pip` count as a package manager?

Right, I forgot about this. I was thinking about package containing
FriCAS and 'jfricas'. FriCAS is unlikely to be packaged as a pip
package in reasonable future, so what remains are various distributions.
AFAIK none currently provides FriCAS + jfricas, but hopefully this
will change.

Well, actually not so standard use case. jfricas exists for some
years, but initially it was very experimental with small number
of users. There are now more users and it will take some time
to make things easier and smoother.

And AFAUI need for patching was because you choose non-standard
way to buid FriCAS (due to confusion over hsbcl-1.3.9.tar) and
due to your dislike for 'xterm' and HyperDoc (which is standard
way of use).

Comparing with other programs, if you want non-standard build,
you need to run configure before build, that is simple casuality
principle (you can not change past from the future). I normally
use command line options, so I noticed a bunch of programs where
I had to use environment variables or a config file. I think
it is quite common that you can do some things only via command
line options.

I guess that we may differ here in 'what configure program' means.
I consider options to FriCAS program as changing what FriCAS
is doing, in similar way to say 'ls' program.

> > For technical reasons FriCAS user init file can
> > not be run very early, so it can not change some things which are
> > changable on command line.
>
> This is odd. Would you be willing to summarize in a few words why this
> is a hard problem? As I understand, FriCAS currently reads
> `~/.fricas.input` and I guess it needs to first start its Lisp
> interpreter up.

'.fricas.input' is in FriCAS language and is read by main
FriCAS binary, that is FRICASsys. '.fricas.input' is doing
things that in principle could be done by user commands at
FriCAS prompt, so in principle it is just a convenience
feature. There is some subtlety, as .fricas.input' runs
at time when user environment is not fully initialized,
but it is a reasonable.

Things like '-noht' option are handled by other parts of FriCAS,
that is 'fricas' shell script and 'sman' binary. Basically,
before FRICASsys starts it is already decided if HyperDoc
will be used or not.

Similar for graphic and other options like 'nosman'.

> Maybe this is what needs to be changed. Say there was
> another file `~/.fricasrc` that is not written in Lisp or Spad but
> rather in some simple configuration language like Ini, Yaml or Toml.
> This file would hold settings mirroring command line options. Is this
> a good idea?

There are already _many_ ways to provide changed command line options
and FriCAS has only a few of options. It is not clear to me if such
a config file add any value.

> I do not have much experience maintaining programs with many options
> and ways of configuration, but my limited experience tells me that
> usually on start-up a program would read configuration files,
> environment variables and command line options all into one structure,
> in this order, overwriting fields as needed. This makes sure that
> exactly the same set of configurations can be accomplished in whatever
> way the user is comfortable with.

Well, first such a program must check if the user gave an option
to use alternative configuration file (the only option for some
programs). So logic is a bit more complicated. In FriCAS case,
there are several binaries, with "entry point" being a shell
script. One attraction of this shell script is that is small and
easily changeable (we automatically modify it at install time).
Putting here code to handle config files is rather unattractive.

--
Waldek Hebisch

[Ignat Insarov]

> Sorry, using TERM is quite wrong, TERM says how a program should
> talk to a terminal, and not which _terminal emulator_ a program
> should use. In particular, TERM may have values which correspond
> to no terminal emulator.

I looked it up and it turns out there is no standard way to tell what
a user's preferred terminal emulator is. Looking at `TERM` is one way
to make an educated guess. Take a look at this answer on Stack
Exchange for example:

https://superuser.com/questions/1153988/find-the-default-terminal-emulator/1461079#1461079

I notice other paths through HyperDoc take me to buttons that use the
terminal that is already open, usually with the label «Do It». So,
there is a way for HyperDoc to talk to the instance of FriCAS that is
already running. In this light, is opening a new terminal necessary?

> Well, there is fraction of open source developers that believe
> that their moral duty is to break any software that is more than
> few years old.

I think this is an uncharitable description. If we never move on from
old things, we can never have new, better things. In the instances I
have been a witness of, the decision to break things was thoroughly
thought through and lead to improvement.

[Ignat Insarov]

> Well, actually not so standard use case. jfricas exists for some
> years, but initially it was very experimental with small number
> of users. There are now more users and it will take some time
> to make things easier and smoother.

I see. I think integrating FriCAS with Jupyter by setting up an HTTP
API was a great step forward.

> And AFAUI need for patching was because you choose non-standard

> way to buid FriCAS (due to confusion over hsbcl-1.3.9.tar) …

Can you say someone _«chose»_ something when they had no visible
alternative? There was no link to `hsbcl-1.3.9.tar` in sight and I
could not find it among release assets on GitHub _(because it was not
there for the latest version of FriCAS)_ — I had to do what I did.

> … and

> due to your dislike for 'xterm' and HyperDoc (which is standard
> way of use).

It is not that I do not like `xterm` and HyperDoc. I do not use any of
these tools for the fun of it. I have a goal that I need to accomplish
with the highest possible efficiency.

The way you are describing my inner world — _«choose a non-standard
way»_, _«your dislike»_ — makes it seem that this is a fancy. Making
such assumptions is not the right way to understand your users. One
good way to understand your users is by doing field research. Ask
people what their favourite terminal emulator is, or better even
observe what terminal emulator they use in their daily work. I expect
it will not be `xterm` — but I may be wrong!

> '.fricas.input' is in FriCAS language and is read by main
> FriCAS binary, that is FRICASsys. '.fricas.input' is doing
> things that in principle could be done by user commands at
> FriCAS prompt, so in principle it is just a convenience
> feature. There is some subtlety, as .fricas.input' runs
> at time when user environment is not fully initialized,
> but it is a reasonable.
>
> Things like '-noht' option are handled by other parts of FriCAS,
> that is 'fricas' shell script and 'sman' binary. Basically,
> before FRICASsys starts it is already decided if HyperDoc
> will be used or not.
>
> Similar for graphic and other options like 'nosman'.

I see. I had no idea `fricas` is a shell script, and a non-trivial one.

> > Maybe this is what needs to be changed. Say there was
> > another file `~/.fricasrc` that is not written in Lisp or Spad but
> > rather in some simple configuration language like Ini, Yaml or Toml.
> > This file would hold settings mirroring command line options. Is this
> > a good idea?
>
> There are already _many_ ways to provide changed command line options
> and FriCAS has only a few of options. It is not clear to me if such
> a config file add any value.

This is a vicious circle. If adding new settings is hard, people will
not add new settings so there will always be only a few.

An example of something that should be a setting is the name of the
terminal emulator that HyperDoc should open when it needs one.

> > I do not have much experience maintaining programs with many options
> > and ways of configuration, but my limited experience tells me that
> > usually on start-up a program would read configuration files,
> > environment variables and command line options all into one structure,
> > in this order, overwriting fields as needed. This makes sure that
> > exactly the same set of configurations can be accomplished in whatever
> > way the user is comfortable with.
>
> Well, first such a program must check if the user gave an option
> to use alternative configuration file (the only option for some
> programs). So logic is a bit more complicated. In FriCAS case,
> there are several binaries, with "entry point" being a shell
> script. One attraction of this shell script is that is small and
> easily changeable (we automatically modify it at install time).
> Putting here code to handle config files is rather unattractive.

I agree: if having a command line flag that changes the path to the
settings file is a requirement, then you need a less straightforward
way to handle settings. There is any number of ways in which
configuration logic may need to be complex. Highly configurable
programs, like some compilers and build systems I have been working
with, have hundreds of settings and thousands of lines of code
dedicated to configuration. What I offered is a simple semantics that
I believe would be easy to understand by the users.

One way you can handle the command line flag that changes the path to
the settings file is by splitting configuration into stages.

* Every stage is defined by a record with all fields optional.
* A stage record may have a field that refers to another, later stage.
* An unset field that refers to another stage is equivalent to a field
that refers to that stage with all its fields unset.

This way, earlier stages of execution do not need to be aware of the
complexities of the later stages. For example, the start-up script
does not need to be aware of Lisp and Spad, who are free to have any
number of settings of their own.

Observe also that records with all fields optional canonically have a
monoid structure. It is derived from the trivial _«update»_ semigroup
defined by ∀ x y. x ◇ y = y by adding a formal identity element and
computing pointwise.

The formula for the first stage will now be:

defaults ◇ command line options

— And for a later stage it will be:

defaults ◇ configuration file ◇ command line options

You can make these formulæ as complicated as you wish by adding
environment variables or whatever other sources of information there
may be.

I have seen this approach used in industrial programs of great
complexity — it works great.

I agree also that a shell script is not suitable to implement this
logic. This is where sound architectural decisions need to be made —
by someone wiser than me.

[Ralf Hemmecke]

On 12/23/24 08:03, Ignat Insarov wrote:
>> Well, actually not so standard use case. jfricas exists for some
>> years, but initially it was very experimental with small number
>> of users. There are now more users and it will take some time
>> to make things easier and smoother.

> I see. I think integrating FriCAS with Jupyter by setting up an HTTP
> API was a great step forward.

True. Communication over HTTP works great and this idea and first
prototype came from Kurt Pagani. Still jfricas is experimental. It
works, but it is (not yet) an integral part of FriCAS. In fact, you must
still see it more as an add-on. It does not live inside the official
FriCAS repository.

I understand Waldek in not wanting to make jfricas the default
interface. FriCAS can be interfaced in different ways. I often use it
from Emacs via the frimacs package.
https://github.com/pdo/frimacs

It would be good if jfricas were more independent of the way in which
fricas is built, but unfortunately, that is not the case. Reality is
that (in order to use jfricas) one must (re)build fricas on top of an
SBCL that has the hunchentoot webserver built-in.

Clearly, you are right, that all of this should be documented somewhere
and in such a way that it doesn't cost too much time for people to find
out the details. Your criticism is OK, but time and manpower is always
an issue. The current state of FriCAS is still that only people that
either have a sysadmin who installs FriCAS for them or people who
desparately fight through all the details to get it working will finally
be able to run "1+1" in the interpreter.

Yes, I have seen mathematicians that would be interested to learn how to
type FriCAS commands, but have never opened an ordinary UNIX terminal.
All of this in unfortunate and should be improved. However, and here I
can only speak for myself, it is done on best effort. I do something if
it helps in my own work and then invest a little more time so that
others can use it as well. Yes, I want more people to use FriCAS, but
more than that FriCAS needs more developers. Yes, you are welcome to
propose new ideas, to propose pull requests etc. Complaining that the
FriCAS developers do badly is understandable, but that unfortunately
does not improve the situation for other people.

FriCAS will stay at a slow pace until more people see the potential of
it and are willing to make their hands dirty to improve rough edges.

I know that one doesn't get more developers without getting more users
first (and vice versa), but that is the tragedy until a good marketing
guy comes along...

So in the interest of FriCAS, let's work together even if our views may
be slightly or massively different. Code/documentation is what counts in
the end.

Ralf