-
-
Notifications
You must be signed in to change notification settings - Fork 704
Make the interface to be compatible with GCL-compiled fricas package #41231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
|
@whoami730 I fixed it now. Can you help me test with sbcl fricas or sage's fricas? |
|
The PR title is misleading. It's clearly about GCL-compiled FriCAS, nothing to do with Ubuntu. |
|
There are much better ways to detect the underlying lisp, e.g. by looking at the output of I asked on https://groups.google.com/g/fricas-devel/c/a2aqmO58pA4/m/hDgfRlqVBgAJ whether there are better ways. |
I just ask them. They said I should raise an issue in Debian community |
|
To get the Lisp type, use Lisp! |
dimpase
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
simplify Lisp detection
This is my implementation. and for gcl compiled fricas, it also should let the buffer clear before we get this |
| E.expect(self._prompt, timeout=0.1) | ||
| except pexpect.TIMEOUT: | ||
| break | ||
| E.sendline(')lisp (lisp-implementation-type)') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dimpase in this line I ask that lisp-implementation-type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And there are other message like
this Function declaration sageprint : InputForm -> String has been added to workspace.
When the fricas running.
So we need to clean this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# GCL-based FriCAS may output function declaration messages
# asynchronously after the prompt appears.
Maybe there is a FriCAS way to suppress these?
Please ask on the FriCAS forum, before starting to mess around with all these timeouts, which are really a weapon of last resort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we need to ask this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is added when init fricas. But sbcl version of fricas does not output that.
| E = self._expect | ||
| # First, consume any buffered output from previous commands | ||
| # to ensure we get a clean response to the lisp command | ||
| while True: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's going on in this loop then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do that for all other messages is clean. So we can run this list-umplementation-type safely
Updated command execution for FriCAS to use stdin for quitting instead of -eval to avoid misinterpretation by GCL-compiled FriCAS.
|
@dimpase Can you help me test the new change can work on sbcl fricas? |
Reduce timeout for subprocess call to fricas from 30 to 1 second.
Refactor subprocess call to avoid timeout handling.
|
I have completed test, it is OK for sbcl version |
|
I don't understand where the types messages are coming from. If you see types printed it is a bug |
|
I think it is a problem caused in GCL's fricas As you see, I turn off this. But it still raise a NIL block output and value = NIL block. And for gcl compiled FriCAS messages can not close. I think it is a bug for upstream fix. we can use this fix it. And it will cause 0.2 s slow down when init the FriCAS |
|
I also test the set can proper deal with fricas |
|
In my opinion it is an absolute no-go to special case gcl. The interface to fricas is fragile, mostly because we use communication via strings. Apparently this is hard to change, nobody has done it in many years. Passing very long input and receiving long output may lead to failure, which can be a real pain, because you would usually use FriCAS for computationally expensive stuff. It is an upstream bug that gcl prints messages after |
I think it is no side effects. And it is used in Ubuntu and Debian as system's packages. I think many users may meet this problem |
|
It seems fricas in sbcl can also have the same input but it works well with sage, so what exactly the root cause? |
|
If you add -eval it like |
The problem looks like in gcl different behavior. not fricas. |
Can one monkey-patch FriCAS in a way one can do with Python? We can disable the use of system - wide GCL Fricas until we have a fix. |
But fricas developer also do not know what is the exact issue. |
|
They haven't really looked yet, and it's not something that looks hard to debug. |
May be I change it to directly throw an error if gcl is detected, then modify the is_present method. Can you describe it to fricas developer? I think they do not understand. In fact, it do not affect the computing part. |
Most people use the Ubuntu or Debian system. But they do not provide a compatible fricas compiled by sbcl. So I fix it with gcl's fricas compatibility.
Fix #40569
📝 Checklist
⌛ Dependencies