GCL and FriCAS

10 views
Skip to first unread message

Qian Yun

unread,
Feb 4, 2024, 7:44:28 PM2/4/24
to fricas-devel, ca...@maguirefamily.org
Hi Camm,

Nice to see you again on fricas-devel.

So here's some questions on GCL and FriCAS:

1. Can you update the Debian packaging for FriCAS? It is still 1.3.8.

2. Can you make "si:run-process" synchronous?

3. Is "init-memory-config" defined in src/interp/util.lisp still useful?

4. Can you do a review of the various "#+:GCL" to see if they are still
needed after gcl-2.6.14?

- Best,
- Qian

Camm Maguire

unread,
Feb 5, 2024, 12:44:59 PM2/5/24
to Qian Yun, ca...@maguirefamily.org, gcl-...@gnu.org, fricas-devel
Greetings!

Qian Yun <oldk...@gmail.com> writes:

> Hi Camm,
>
> Nice to see you again on fricas-devel.
>
> So here's some questions on GCL and FriCAS:
>
> 1. Can you update the Debian packaging for FriCAS? It is still 1.3.8.
>

Thanks for the reminder -- uploaded.

> 2. Can you make "si:run-process" synchronous?

Anything is possible, but have you tried #'si::system, or opening a file
with name beginning in "|" to read or write from/to pipes? run-process
is meant to return control to the lisp prompt so the user might interact
with the process running in the background.

>
> 3. Is "init-memory-config" defined in src/interp/util.lisp still
> useful?

Most likely not. GCL used to have a static number of heap pages
determined at runtime, and fixed bounds on pages per gc type which were
only increased when the allocation grew full. The #'si::allocate
function was there to give the type more room so all the build time was
not used up in GC. This of course was a design failure, as the load per
GC was the entire heap, and not just the space reserved for the type, so
the overhead multiple on tiny portions could increase without bound. A
long time ago we added the variable si::*optimize-maximum-pages*, which
set these limits dynamically and statistically to balance the load among
the types. One essentially never runs without this setting, except when
one wants a tiny heap for a temporary command, like (progn (load ..)
(si::save-system "out")).

>
> 4. Can you do a review of the various "#+:GCL" to see if they are still
> needed after gcl-2.6.14?

Yes, will do, as well as commit the items (all gcl specific) I alluded
to in a previous email.

Take care,

>
> - Best,
> - Qian

--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply all
Reply to author
Forward
0 new messages