#10295: Upgrading pexpect
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner: was
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.7
Component: interfaces | Resolution:
Keywords: pexpect upgrade | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/fbissey/pexpect3.3 | a24eab3ce985874ab8445ed5e362bbeead76fd40
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by leif):
Replying to [comment:44 fbissey]:
> Replying to [comment:43 leif]:
> > Of course continually polling without delay isn't nice either; it will
significantly increase the CPU load.
>
> Will it?
[http://en.wikipedia.org/wiki/Busy_waiting].
I'll have to look closer at the code. Haven't tested yet, but I guess
it'll get worse the longer the net computation in the subprocess takes;
the examples above only do short toy computations and don't take the
overall CPU time into account. (It may lead to effectively doubling
`SAGE_NUM_THREADS` in ptestlong.)
> After all unless there are quite a number of other changes, it is the
current situation with 2.0, isn't it? Upgrading without patching would
decrease the CPU load if I am not mistaken.
Probably. In fact, for me ptestlong with 3.3 (unpatched) went faster than
with 2.0, although only slightly, under the same conditions (constant low
load). (But in both cases I had some process apparently still waiting for
Singular after all other tests had already finished, so the wall time got
messed up a bit.)
But I'm ok with first upgrading here and removing the `sleep`, then
checking what else we could tweak on another ticket.
> Anyway, I like Jeroen's idea but we will need to upgrade pexpect in any
case. I am all in favour of upgrading now with a patch and working on some
cythonized elements for pexpect in a follow up ticket. We could remove the
patch when we have something satisfactory in place.
Subclassing, probably with individual changes for different interfaces or
dynamically changing parameters is the way to go I think.
While we could perhaps do some parts in Cython, leaving Python of course
puts more burden of portablility on us, depending on what exactly we do.
--
Ticket URL: <http://trac.sagemath.org/ticket/10295#comment:45>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
