Opened 8 years ago
Last modified 12 months ago
#16688 new enhancement
Meta-ticket: replace pexpect interface calls with library where possible
Reported by: | rws | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-wishlist |
Component: | interfaces | Keywords: | expect, pexpect, library |
Cc: | fbissey, frederichan, leif, slelievre | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
This meta-ticket tracks efforts to replace pexpect interface calls with library calls, in order to minimize the usage of expect for time-critical code. Packages used by Sage where this seems possible include
- mwrank
- GAP (#26902)
- Singular (no ticket but see related #11957)
- ECL/Maxima (#17753)
- PARI/GP (a few scripts #16687)
The following packages are used via pexpect in the Sage library (noninteractively) and these calls should be replaced somehow in the long term (this is a wishlist):
- Axiom (through fricas)
- giac (first step: make
giacpy_sage
standard: #28918, second step: integration #31873) - kash
- Macaulay2
- Octave
- qepcad
- Scilab (two unused functions in
matrix/matrix1.pyx
)
Related:
Change History (15)
comment:1 follow-up: ↓ 5 Changed 8 years ago by
- Cc fbissey added
comment:2 Changed 8 years ago by
- Cc frederichan added
comment:3 Changed 7 years ago by
Further motivation for this:
sage: scilab(str(range(20))) # works sage: scilab(str(range(30))) # BOOM!
(Note -- scilab(range(20)) doesn't work but should!)
And also
sage: r(range(30)) # works sage: r(range(10000)) # boom
Worksheet with the above: https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2015-02-04-062417-scilab-limits.sagews
These sorts of problems were reported by many people over the years, most recently by JC Boulet of INRA.
comment:4 Changed 7 years ago by
comment:5 in reply to: ↑ 1 ; follow-up: ↓ 6 Changed 7 years ago by
Replying to fbissey:
The notebook also uses pexpect. I am not sure there is much of an alternative there but at least we should try to move it to a more modern pexpect. Trying to do so results in breakages that I have no idea how to solve currently.
There is, especially when you're programming both sides. You can have two processes communicate through a pipe or stream without one of the parties pretending to be a terminal.
That said, the fact that the notebook *does* use pexpect makes it easier to use it to interface with R, octave, magma, etc, so we do get some benefit from it.
comment:6 in reply to: ↑ 5 Changed 7 years ago by
Replying to nbruin:
Replying to fbissey:
The notebook also uses pexpect. I am not sure there is much of an alternative there but at least we should try to move it to a more modern pexpect. Trying to do so results in breakages that I have no idea how to solve currently.
There is, especially when you're programming both sides. You can have two processes communicate through a pipe or stream without one of the parties pretending to be a terminal.
I completely agree. IPython and also https://github.com/sagemath/cloud/blob/master/sage_server.py are both examples of better ways of communication between two processes without using pexpect. Basically, you setup a traditional client/server and a messaging protocol. Python and many other languages makes that sort of thing pretty easy. But... it would be harder to implement something like that in a special purpose system like Pari or Magma. It might be impossible with Magma without source code access (not sure what the status of networking is now).
That said, the fact that the notebook *does* use pexpect makes it easier to use it to interface with R, octave, magma, etc, so we do get some benefit from it.
As the author of exactly the part of the notebook that uses pexpect, etc., I don't agree with this statement so much -- instead, the two are somewhat orthogonal. The connection (1) "notebook_server <--> python processes" is done using pexpect in sagenb. The interfaces to R/octave/magma, etc. are connections (2) "python processes <--> R/octave/magma/etc.". You can certainly swap out (1) for a connection built using TCP (rather than pexpect) with no impact on (2); in fact, that's precisely what I did with SageMathCloud?.
That said, maybe you just meant that work on the abstract base class Expect for the interfaces benefits both sagenb and the R/octave/magma, etc., interfaces...
comment:7 Changed 7 years ago by
I do agree that when alternatives to pexpect are available, we should use the alternatives. But for the programs which don't offer alternatives, pexpect should be able to work.
comment:8 Changed 7 years ago by
- Description modified (diff)
comment:9 Changed 6 years ago by
- Cc leif added
comment:10 Changed 3 years ago by
- Cc slelievre added
- Description modified (diff)
comment:11 Changed 2 years ago by
- Description modified (diff)
comment:12 Changed 12 months ago by
- Description modified (diff)
comment:13 Changed 12 months ago by
- Summary changed from replace pexpect interface calls with library where possible to Meta-ticket: replace pexpect interface calls with library where possible
comment:14 Changed 12 months ago by
- Description modified (diff)
comment:15 Changed 12 months ago by
- Description modified (diff)
The notebook also uses pexpect. I am not sure there is much of an alternative there but at least we should try to move it to a more modern pexpect. Trying to do so results in breakages that I have no idea how to solve currently.