finding underlying lisp

[Dima Pasechnik]

What is the best way to find the Lisp used to build FriCAS?

I know that "fricas --version" outputs it (at least on sufficiently new releases),

but it still needs code to get to it.

Asked in connection to https://github.com/sagemath/sage/pull/41231

where an attempt is made to allow Sage to use GCL-compiled friCAS.

Thanks

Dima

[Dima Pasechnik]

I found out the following:

)lisp (lisp-implementation-type)

will output

Value = <type>

E.g.

sage: fricas.eval(")lisp (lisp-implementation-type)") 

'\nValue = "SBCL"'

How does one modify the call to remove "Value =" ?

[Kurt Pagani]

You may call LISP functions and variables as below, returning
"SExpression", which can processed further ....

(4) -> LISP_-IMPLEMENTATION_-TYPE()$Lisp

(4) "SBCL"
Type:
SExpression
(5) -> LISP_-IMPLEMENTATION_-VERSION()$Lisp

(5) "2.2.9.debian"
Type:
SExpression


Notice, that the underlines ("_") are necessary to deal with dashes "-"
in FriCAS.

> --
> You received this message because you are subscribed to the Google
> Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fricas-devel...@googlegroups.com <mailto:fricas-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-
> devel/3fe080b2-88e3-4221-9dbc-5f7faabc246an%40googlegroups.com <https://
> groups.google.com/d/msgid/fricas-
> devel/3fe080b2-88e3-4221-9dbc-5f7faabc246an%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Dima Pasechnik]

Thanks. Is there an option to suppress output of types?

[Kurt Pagani]

Yes,

)set messages type off

Type )set mess to see more options.

Example:
(1) -> lisp(s:String):SExpression == EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
Function declaration lisp : String -> SExpression has been added to
workspace.

Type: Void
(2) -> lisp "(+ 2 3 4)"
Compiling function lisp with type String -> SExpression

(2) 9
Type:
SExpression

(3) -> )set mess type off
(3) -> lisp "(+ 2 3 4)"

(3) 9

(4) ->

[Dima Pasechnik]

On Tuesday, November 25, 2025 at 1:18:32 PM UTC-6 Kurt Pagani wrote:

Yes,

)set messages type off

Type )set mess to see more options.

Example:
(1) -> lisp(s:String):SExpression == EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
Function declaration lisp : String -> SExpression has been added to
workspace.

Unfortunately I cannot seem to get anything suppressed in FriCAS 1.3.11 built with gcl 2.7.1,

as well as in 1.3.12 built with sbcl 2.5.8

$ fricas
(HyperDoc) Cannot connect to the X11 server!
openServer result 0
                       FriCAS Computer Algebra System
                 Version: FriCAS 1.3.11 built with gcl 2.7.1
                   Timestamp: Sun Apr 27 01:41:50 UTC 2025
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
 

(1) -> )set mess type off

(1) -> lisp(s:String):SExpression == EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
   Function declaration lisp : String -> SExpression has been added to
      workspace.

(2) -> lisp "(+ 2 3 4)"
   Compiling function lisp with type String -> SExpression

   (2)  9

 # fricas
(HyperDoc) Cannot connect to the X11 server!
Checking for foreign routines
FRICAS="/usr/lib64/fricas/target/x86_64-pc-linux-gnu"
spad-lib="/usr/lib64/fricas/target/x86_64-pc-linux-gnu/lib/libspad.so"
foreign routines found
openServer result 0
                       FriCAS Computer Algebra System
                Version: FriCAS 1.3.12 built with sbcl 2.5.8
                   Timestamp: Sun Oct 26 00:48:03 CDT 2025
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
 

(1) -> )set mess type off
(1) -> )lisp (+ 1 2)

Value = 3

(1) -> lisp(s:String):SExpression == EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
   Function declaration lisp : String -> SExpression has been added to
      workspace.

Dima

[Ralf Hemmecke]

Dima,

Isn't

$ sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 10.4, Release Date: 2024-07-19 │
│ Using Python 3.12.3. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
sage: fricas("LISP_-IMPLEMENTATION_-TYPE()$Lisp")
"SBCL"

working for you as Kurt suggested?

Ralf

[Dima Pasechnik]

This was only a tip of the problem.

We would like to have Sage working with GCL-compiled FriCAS, but it leaks messages on things added to the workspace asynchronously, without a way to suppress them via ")set mess".

sage: fricas('3')

ends with

TypeError: An error occurred when FriCAS evaluated '3':
Function declaration sageprint : InputForm -> String has been added to
workspace.

see <https://github.com/sagemath/sage/issues/40569>

Is this a FriCAS bug?

[Grégory Vanuxem]

Hello,

Le mer. 26 nov. 2025 à 15:59, Dima Pasechnik <dim...@gmail.com> a écrit :
>
> This was only a tip of the problem.
>
> We would like to have Sage working with GCL-compiled FriCAS, but it leaks messages on things added to the workspace asynchronously, without a way to suppress them via ")set mess".
>
> sage: fricas('3')
>
> ends with
>
> TypeError: An error occurred when FriCAS evaluated '3':
> Function declaration sageprint : InputForm -> String has been added to
> workspace.
>
> see <https://github.com/sagemath/sage/issues/40569>
>
> Is this a FriCAS bug?

I may be wrong but with quick tests on FriCAS built on top of GCL (the
packaged FriCAS on Debian based system) and FriCAS built with Clozure
CL or SBCL, the handling of default options at startup and via
.fricas.input are different. Personally my .fricas.input contains
')set message time on', it is not taken into account at startup with
GCL based FriCAS, contrary to the ones with SBCL or Clozure CL. So I
would say it's an issue with FriCAS on top of GCL with startup
options.

Regards,

Greg

PS: I tested packaged FriCAS on Debian-based system (1.3.11). Also
1.3.12 on SBCL or Clozure CL. And a recent version of FriCAS built on
top of recent GCL.

[Waldek Hebisch]

On Wed, Nov 26, 2025 at 08:59:02AM -0600, Dima Pasechnik wrote:
> This was only a tip of the problem.
>
> We would like to have Sage working with GCL-compiled FriCAS, but it leaks messages on things added to the workspace asynchronously, without a way to suppress them via ")set mess".
>
> sage: fricas('3')
>
> ends with
>
> TypeError: An error occurred when FriCAS evaluated '3':
> Function declaration sageprint : InputForm -> String has been added to
> workspace.
>
> see <https://github.com/sagemath/sage/issues/40569>
>
> Is this a FriCAS bug?

ATM there is no way to supress messages like 'Function declaration...'
or 'Compiling function...'. One user asked for way to disable
'Compiling function...' messages, but quickly found a workaround and
dropped the request. If sage needs to disable those message
we can add appropriate control.

However, concerning Sage use, output markers are supposed to delimit
parts that are intersting to Sage. So it would be good to know
what really does not work.

Note that to change settings FriCAS must be at least partially
initialized and you will get earlier messages, printend
before you changed settings. There are confliciting demands
how much initialization is done before user code gets first
chance to intervene.

--
Waldek Hebisch

[Ralf Hemmecke]

Waldek,

I cannot believe that suppression of certain output is their problem.
Otherwise, it should be possible to extract some code from jfricas in
order to mark the various output types and do separate things with them
just as I do in jfricas.

The reason seems to be that the connection sage <--> fricas seems to be
broken with the fricas debian package that lives on GCL.

Maybe I haven't yet understood their real problem, but I can reproduce

that

sage: fricas('3')

leads to (see attachment) on xubuntu 22.04.

I very much believe that it is
/usr/lib/python3/dist-packages/sage/interfaces/fricas.py where the
problem is to be located, because

sage: fricas_console()

seems to work fine with GCL.

However, why fricas.py would behave differently with GCL in contrast to
SBCL, is a mystery for me. I somehow fear that it is a problem with the
expect function and the fricas.py script not understanding what comes
back from FriCAS (in the GCL case). It would probably be worthwhile to
test whether fricas.py receives the same in SBCL vs. GCL case.

Ralf

[Dima Pasechnik]

There ought to be a startup option to be able to **start** FriCAS with the
settings which suppress the messages needed to be suppressed,
including these which cannot currently be suppressed.

The current GCL-FriCAS issue shows that the messages appear out of sync with
the read/write on FriCAS console.

>> TypeError: An error occurred when FriCAS evaluated '3':
>> Function declaration sageprint : InputForm -> String has been added to

^^^^^^^^^^^^^^
> > workspace.

(see "sage" getting in the middle of the message I underlined with ^^^^ above ?)

While it's possible to work around this by adding various timeouts in
the communication
loop, it's all getting even more fragile than it is now.

Dima



>
> --
> Waldek Hebisch

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

[Ralf Hemmecke]

On 11/27/25 05:29, Dima Pasechnik wrote:
> There ought to be a startup option to be able to **start** FriCAS with the
> settings which suppress the messages needed to be suppressed,
> including these which cannot currently be suppressed.

Yes, a "--silent" option would be good, but you have to deal with legacy
fricas debian packages anyway.

> The current GCL-FriCAS issue shows that the messages appear out of sync with
> the read/write on FriCAS console.
>
>>> TypeError: An error occurred when FriCAS evaluated '3':
>>> Function declaration sageprint : InputForm -> String has been added to
> ^^^^^^^^^^^^^^
>>> workspace.

> (see "sage" getting in the middle of the message I underlined with ^^^^ above ?)

I don't see sage getting in the middle here. It seems that sage starts a
FriCAS session, the first time that a fricas(...) call appears. And
then, obviously, the output does not come in the order that Sage expects
it. Finding the reason why it comes dis-ordered, would be a good start.

> While it's possible to work around this by adding various timeouts in
> the communication loop, it's all getting even more fragile than it is now.

Maybe, possible, but unreliable. I had to deal with a similar issue (as
far as I remember) in jFriCAS. In particular, I wanted to capture error
messages and print them differently in the notebook. They were hard to
detect althoug one could write them on different streams in FriCAS. I
then switched to a different idea: everything goes to ONE stream. Then
you see messages in the same order that you would see them in a FriCAS
session. And (I very much bet) that

Function declaration sageprint : InputForm -> String ...

would come before the TypeError (which actually shouldn't appear at all).

Study,

https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp#L60

and the accompanying fricaskernel.py.

The idea is, to load a lisp file at startup that does all the ioHook
settings in such a way that

a) every output basically goes to stdout,
b) different output types are tagged with '--FORMAT:BEG:...' and
'--FORMAT:END:...'
c) fricaskernel.py then takes from this tagged output what it needs.

I think if you follow this idea in Sage's fricas.py, you should also be
fine with GCL.



BTW, I haven't looked too deep into Sage's fricas.py, but it seems that
the sageprint function only serves the purpose of transforming an
InputForm of FriCAS into something that can be shown nicely in Sage.
I wonder whether perhaps

setFormat!(Format1D)$JFriCASSupport

or

setFormats!([Formatter Format1D] pretend _
List(OutputFormatterCategory))$FormattedOutput
systemCommand("set output formatted on")$MoreSystemCommands

could serve that purpose. I.e. instead of the relatively unparsable 2D
standard output of FriCAS, you get a 1D output, that in most cases can
be understood by a CAS that does not use the weird syntax of
Mathematica. I also have a package that translates FriCAS output into
Mathematica syntax, if this would be of any help. Not perfect, but if it
helps to get a nice sage-fricas connection... Or maybe (probably a
better idea), I can write a FormatSage formatter that would translate
FriCAS OutputForm into something that Sage can handle (oh, that would
anyway be very close to Format1D).

setFormat $ JFriCASSupport would even add the markers around the output,
i.e., no other ioHook is needed.

See:
https://github.com/fricas/fricas/blob/master/src/algebra/fmtjfricas.spad

I hope you can adapt the sage-fricas interface accordingly.

Ralf

[Waldek Hebisch]

One trouble is that enough needs to be initialized before there is
a chance to do any option processing. Let me add that fatal errors
can happen in various stages of startup and usually only startup
messages give hints which step failed.

> The current GCL-FriCAS issue shows that the messages appear out of sync with
> the read/write on FriCAS console.
>
> >> TypeError: An error occurred when FriCAS evaluated '3':
> >> Function declaration sageprint : InputForm -> String has been added to
> ^^^^^^^^^^^^^^
> > > workspace.
>
> (see "sage" getting in the middle of the message I underlined with ^^^^ above ?)

AFAIK this message appears both when using sbcl and GCL. And it was
there 18 years ago, when GCL interface worked.

> While it's possible to work around this by adding various timeouts in
> the communication
> loop, it's all getting even more fragile than it is now.

--
Waldek Hebisch

[Dima Pasechnik]

I understand this argument, but it doesn't mean the startup must inevitably be noisy.
It would be valid if the initialisation was not fully under our control, but this is not the case.

Having a startup option to send all the startup noise to /dev/null should be easy to implement, and it should be the default, for typically one is not interested in what happens before the system has the chance to process the options it is given.

[Grégory Vanuxem]

Hello,

Le mer. 26 nov. 2025 à 17:58, Grégory Vanuxem <g.va...@gmail.com> a écrit :
>
> Hello,
>
> Le mer. 26 nov. 2025 à 15:59, Dima Pasechnik <dim...@gmail.com> a écrit :
> >
> > This was only a tip of the problem.
> >
> > We would like to have Sage working with GCL-compiled FriCAS, but it leaks messages on things added to the workspace asynchronously, without a way to suppress them via ")set mess".
> >
> > sage: fricas('3')
> >
> > ends with
> >
> > TypeError: An error occurred when FriCAS evaluated '3':
> > Function declaration sageprint : InputForm -> String has been added to
> > workspace.
> >
> > see <https://github.com/sagemath/sage/issues/40569>
> >
> > Is this a FriCAS bug?
>
> I may be wrong but with quick tests on FriCAS built on top of GCL (the
> packaged FriCAS on Debian based system) and FriCAS built with Clozure
> CL or SBCL, the handling of default options at startup and via
> .fricas.input are different. Personally my .fricas.input contains
> ')set message time on', it is not taken into account at startup with
> GCL based FriCAS, contrary to the ones with SBCL or Clozure CL. So I
> would say it's an issue with FriCAS on top of GCL with startup
> options.
>
> Regards,
>
> Greg
>

> PS: I tested packaged FriCAS on a Debian-based system (1.3.11). Also

> 1.3.12 on SBCL or Clozure CL. And a recent version of FriCAS built on
> top of recent GCL.

After some further investigations, what I pointed out is not related
to SAGE, sorry, but to the official Debian-based gcl27 package.
'.fricas.input' is not processed at startup with the actual official
fricas package. I tested the gcl package (2.6.14 - git:
Version_2_6_15pre18) to build FriCAS and the .fricas.input is
effectively processed. So since there was recently a discussion on
gcl-devel about pathname
(https://mail.gnu.org/archive/html/gcl-devel/2025-11/msg00001.html) I
gave a try to the GCL git version commit: HEAD master Version_2_7_2pre
(Account for possible #\. in pathname-type when compiling) and this
issue is solved, I don't know if this discussion is related to this
issue though. FriCAS built with this version of GCL no longer exhibits
this issue.

For information.

Greg

[Camm Maguire]

Greetings, and thanks so much for the update! Glad to hear the
fricas.input is working now. I was under the impression that the
correct behavior was restored by Waldek some time ago in accounting for
GCL's different pathname-type semantics. I would be surprised if the
commit you reference were responsible, as it only affects the compiler.

Take care,

--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah