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
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/8e68b37f-1fda-40fa-acb8-231c29b9bd94%40hemmecke.org.
