On November 27, 2025 5:16:42 AM CST, Waldek Hebisch <[email protected]> wrote:
>On Wed, Nov 26, 2025 at 10:29:57PM -0600, Dima Pasechnik wrote:
>> On Wed, Nov 26, 2025 at 4:28 PM Waldek Hebisch <[email protected]> wrote:
>> >
>> > 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.
>>
>> 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.
>
>One trouble is that enough needs to be initialized before there is
>a chance to do any option processing.
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.
> 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.
>
--
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/3C1CD60F-76CD-4A93-9F7E-959A1F21F9FC%40gmail.com.
