GCL ANSI image needed to build FriCAS (commit f5fafaa)

[Grégory Vanuxem]

Hello,

From commit f5fafaa on Feb. 11, "Remove old GCL specific code",

https://github.com/fricas/fricas/commit/f5fafaa29785fb0fd83bd974096e4e316762f31b

src/interp/utils.lisp was modified as this:
319-326
==============================================
(setq |$formattedOutputStream| (|mkOutputConsoleStream|))
(fricas-init)
- #+(or :GCL :poplog)
+ #+:poplog
(|spad|)
- #-(or :GCL :poplog)
+ #-:poplog
(let ((*debugger-hook*
(lambda (condition previous-handler)
(spad-system-error-handler condition))
(setq |$texOutputStream| (|mkOutputConsoleStream|))
==============================================
and after, in this code branch (handler-bind ...) is called with (|spad|).

The problem I would like to highlight here is that, since this change,
GCL is no longer able to compile this file. Namely, the CLtL1 image
that, by default GCL use, does not support (handle-bind ...) and
probably more ((handle-case ..) also for example).

So to have this routine defined you have to switch to the ANSI image.
For that, a GCL_ANSI environnent variable needs to be set to
something. On Debian-like distributions, at least, this is necessary.
See below an excerpt of the README.Debian file.

So I would suggest to explain this in the INSTALL.rst file or do
something about that.

By the way, I have 'make check'ed FriCAS against SBCL, GNU Common
Lisp, CLISP, ECL and no problem occurs. For CMU Common Lisp, I need
more time, I have used a version with a modified startup and I do not
know for now, it was late. For Clozure CL some issues remain but
integration was improved and it remains only one issue.Thanks for
this!

Greg

==========================================
The Debian package gcl
----------------------

GCL is one of the oldest free common lisp systems still in use. Several
production systems have used it for over a decade. The common lisp
standard in effect when GCL was first released is known as "Common Lisp,
the Language" (CLtL1) after a book by Steele of the same name providing
this specification. Subsequently, a much expanded standard was adopted by
the American National Standards Institute (ANSI), which is still
considered the definitive common lisp language specification to this day.

Debian GCL now installs both the small 'traditional' lisp image
designed to conform to a pre-ANSI Lisp standard, and an experimental
ANSI image. Please note that ANSI support in GCL is still
preliminary. On an ansi-test suite written by a GCL developer, GCL
fails on a little under 3 percent of the tests. Details can be found
in /usr/share/doc/gcl/test_results.gz.

To toggle the use of the ANSI image, set the environment variable
GCL_ANSI to any non-empty string.
================================================
I think the original modification comes from:

2008-01-21 Waldek Hebisch <heb...@math.uni.wroc.pl>
Martin Rubey <martin...@univie.ac.at>

* src/interp/util.lisp: Attach 'spad-system-error-handler' to
*debugger-hook* (needed to trap Ctrl-C in sbcl).

[Waldek Hebisch]

On Tue, Aug 01, 2023 at 08:38:35PM +0200, Grégory Vanuxem wrote:
> Hello,
>
> >From commit f5fafaa on Feb. 11, "Remove old GCL specific code",
>
> https://github.com/fricas/fricas/commit/f5fafaa29785fb0fd83bd974096e4e316762f31b
>
> src/interp/utils.lisp was modified as this:
> 319-326
> ==============================================
> (setq |$formattedOutputStream| (|mkOutputConsoleStream|))
> (fricas-init)
> - #+(or :GCL :poplog)
> + #+:poplog
> (|spad|)
> - #-(or :GCL :poplog)
> + #-:poplog
> (let ((*debugger-hook*
> (lambda (condition previous-handler)
> (spad-system-error-handler condition))
> (setq |$texOutputStream| (|mkOutputConsoleStream|))
> ==============================================
> and after, in this code branch (handler-bind ...) is called with (|spad|).
>
> The problem I would like to highlight here is that, since this change,
> GCL is no longer able to compile this file. Namely, the CLtL1 image
> that, by default GCL use, does not support (handle-bind ...) and
> probably more ((handle-case ..) also for example).

Yes, currently only ANSI GCL can build FriCAS. We need to handle
erros and ANSI gives a way. In the past we used GCL-specific
method for "traditional GCL", but it no longer works.

> So to have this routine defined you have to switch to the ANSI image.
> For that, a GCL_ANSI environnent variable needs to be set to
> something. On Debian-like distributions, at least, this is necessary.
> See below an excerpt of the README.Debian file.
>
> So I would suggest to explain this in the INSTALL.rst file or do
> something about that.

The best we can do is to reject non-ANSI gcl at configure stage.
ATM our gcl support is at experimental stage, things generaly
work but are less polished than other parts of FriCAS. For
example configure accepts gcl versions which have no chance
of working.

Yes, we should explain that FriCAS build only with ANSI GCL.
Concerning GCL_ANSI environnent variable, that is specific
to GCL distibuted with Debian. If you build GCL from
sources, then you need to configure ANSI image.

> By the way, I have 'make check'ed FriCAS against SBCL, GNU Common
> Lisp, CLISP, ECL and no problem occurs. For CMU Common Lisp, I need
> more time, I have used a version with a modified startup and I do not
> know for now, it was late. For Clozure CL some issues remain but
> integration was improved and it remains only one issue.Thanks for
> this!

Concerning errors with GCL: probably the most serious issue
is need to artifically limit memory used by GCL to 2G.

> ==========================================
> The Debian package gcl
> ----------------------
>
> GCL is one of the oldest free common lisp systems still in use. Several
> production systems have used it for over a decade. The common lisp
> standard in effect when GCL was first released is known as "Common Lisp,
> the Language" (CLtL1) after a book by Steele of the same name providing
> this specification. Subsequently, a much expanded standard was adopted by
> the American National Standards Institute (ANSI), which is still
> considered the definitive common lisp language specification to this day.
>
> Debian GCL now installs both the small 'traditional' lisp image
> designed to conform to a pre-ANSI Lisp standard, and an experimental
> ANSI image. Please note that ANSI support in GCL is still
> preliminary. On an ansi-test suite written by a GCL developer, GCL
> fails on a little under 3 percent of the tests. Details can be found
> in /usr/share/doc/gcl/test_results.gz.
>
> To toggle the use of the ANSI image, set the environment variable
> GCL_ANSI to any non-empty string.
> ================================================
> I think the original modification comes from:
>
> 2008-01-21 Waldek Hebisch <heb...@math.uni.wroc.pl>
> Martin Rubey <martin...@univie.ac.at>
>
> * src/interp/util.lisp: Attach 'spad-system-error-handler' to
> *debugger-hook* (needed to trap Ctrl-C in sbcl).

No, it is already in 1.0.1 from December 2007. The above just
added binding of *debugger-hook*.

--
Waldek Hebisch

[Grégory Vanuxem]

Ok.

> So to have this routine defined you have to switch to the ANSI image.
> For that, a GCL_ANSI environnent variable needs to be set to
> something. On Debian-like distributions, at least, this is necessary.
> See below an excerpt of the README.Debian file.
>
> So I would suggest to explain this in the INSTALL.rst file or do
> something about that.

The best we can do is to reject non-ANSI gcl at configure stage.

I agree, that's better. With a non technical explanation in the INSTALL file I would say. Testing the Common Lisp implementation (config.lisp) can be of help. 

ATM our gcl support is at experimental stage, things generaly
work but are less polished than other parts of FriCAS.  For
example configure accepts gcl versions which have no chance
of working.

Yes, we should explain that FriCAS build only with ANSI GCL.
Concerning GCL_ANSI environnent variable, that is specific
to GCL distibuted with Debian.  If you build GCL from
sources, then you need to configure ANSI image.

I didn't know, I only noticed someone who encountered this issue on the web.

> By the way, I  have 'make check'ed FriCAS against SBCL, GNU Common
> Lisp, CLISP, ECL and no problem occurs. For CMU Common Lisp, I need
> more time, I have used a version with a modified startup and I do not
> know for now, it was late. For Clozure CL some issues remain but
> integration was improved and it remains only one issue.Thanks for
> this!

Concerning errors with GCL: probably the most serious issue
is need to artifically limit memory used by GCL to 2G.

No errors with the latest GCL from Debian (testing I guess) but I saw that in the INSTALL file.

__

Greg