[PATCH] more verbose error message in parseAndEvalString* (server.boot)

8 views
Skip to first unread message

Grégory Vanuxem

unread,
May 21, 2026, 10:39:23 PMMay 21
to fricas...@googlegroups.com
Hello,

Actually when an error is encountered during parsing and evaluation in
parseAndEvalString and parseAndEvalStringEqNum the output is just:
"error". I modified the throwed output to be the one of the interpreter.
I may be wrong but nothing is affected (src/hyper/*, jFRiCAS or
TeXmacs extensions). I just see one concern about
the overhead but I believe for their use it
is acceptable.

Below is to show here the mechanism:

parseAndEvalToString str ==
$collectOutput:local := true
$outputLines: local := nil
$IOindex: local := nil
- v := CATCH('SPAD_READER, CATCH('top_level, parseAndEvalStr str))
- v = 'restart => ['"error"]
+ str_stream := MAKE_-STRING_-OUTPUT_-STREAM()
+ old_stream := $algebra_out_rec.$stream_off
+ $algebra_out_rec.$stream_off := cons(false, str_stream)
+ v := UNWIND_-PROTECT(
+ CATCH('SPAD_READER, CATCH('top_level, parseAndEvalStr str)),
+ ($algebra_out_rec.$stream_off := old_stream)
+ )
+ captured_msg := GET_-OUTPUT_-STREAM_-STRING(str_stream)
+ v = 'restart =>
+ captured_msg = '"" => ['"Unknown error during parsing in BOOT
function parseAndEvalToString"]
+ string2Lines(captured_msg)
NREVERSE $outputLines

Personally, I use these two functions for the FriCAS MCP server and
therefore the FriCAS extension I am
working on for the VS Code compatible editors. They have an integrated
pseudo terminal which can be tightly related to the editor (think
about a .input file you are working on).

BTW, I always like informative error messages.

Patch attached.

Greg
server.boot.patch

Waldek Hebisch

unread,
Jun 1, 2026, 8:52:08 AMJun 1
to fricas...@googlegroups.com
On Fri, May 22, 2026 at 04:38:44AM +0200, Grégory Vanuxem wrote:
> Hello,
>
> Actually when an error is encountered during parsing and evaluation in
> parseAndEvalString and parseAndEvalStringEqNum the output is just:
> "error". I modified the throwed output to be the one of the interpreter.
> I may be wrong but nothing is affected (src/hyper/*, jFRiCAS or
> TeXmacs extensions). I just see one concern about
> the overhead but I believe for their use it
> is acceptable.

It seems to work well. I am thinking about assignment to algebra
output stream, it looks somewaht unclean.
> --
> 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/CAHnU2dZ4raqxTQu0%3DHkobgDW%2BUjdWFnhYsSexJR1kY4ecAuK2g%40mail.gmail.com.



--
Waldek Hebisch

Grégory Vanuxem

unread,
Jun 2, 2026, 7:38:46 AMJun 2
to fricas...@googlegroups.com
Hello,

Yes, I also think so. That would be good from my point of view, actual code is lacunar. 

Greg



Reply all
Reply to author
Forward
0 new messages