2009/9/5 Paulo César Pereira de Andrade
<[email protected]>:
>
> Hi,
>
> I am not experienced with pexepect, but I played a bit trying to use
> a newer version in sage.
> But since it is one of the core packages of sage (and because it is
> one of the special cases where an older package is used, in my rpm
> package :-), I would like to know what is the state about upgrading it
> to a newer version, or using some alternate interface.
The only reason I didn't upgrade pexpect long ago is that at some
point it was greatly rewritten/refactored and the result was
*massively* slower than the version in Sage. So I stayed with the
version we were including. Nobody has succeeded in figuring out why
the new pexpect is thousands of times slower.
>
> The major problems I see are:
Major problems with upgrading? Or with pexpect in general?
> 1. pexpect uses a pty, but it is not a fully functional "terminal
> emulator", for example, try any gap command longer then 80 bytes; it
> will get completely wrong.
That is not true at all.
sage: a = '2'*90
sage: gap.eval('%s + 1'%a)
'222222222222222222222222222222222222222222222222222222222222222222222222222222222222222223'
That's a 90 character command and it is not "completely wrong".
The input size is limited though to about 3000 characters. The eval
command uses a file when the input is more than 100 characters.
This is configured in the __init__ method in gap.py. The cutoff could
be much higher than 100, but experimentally I found that it is faster
to use a file after about 100 characters.
> I found weird behavior at some point, and
> then, I noticed it when running sage to build documentation, where I
> would set DOT_SAGE to a long path, and when executing:
> SaveWorkspace("/some/very/long/pathname/.sage/gap/workspace-hash-of-SAGE_ROOT")
> it would add a space in the 80th character.
There is a bug there of course, but it is not some generic thing for
any input longer than 80 characters.
By the way, you might try changing the 100 to 75 as mentioned above
and see what happens.
> 2. I understand now sage will use ecl, but clisp uses a "magic" to
> detect it is running interactively, that is to check if "fileno(stdin)
> == fileno(stdout)", and pexpect just ensures that, so, either one
> would need to use a patch as suggested in
> http://sourceforge.net/mailarchive/message.php?msg_name=81329a955d5b59daeeccb0edc0e7b603.squirrel%40webmail.mandriva.com.br
> or do some trick like 'cat /dev/stdin | clisp "$@" > /dev/stdout"
We dumped clisp from Sage in early May... so I'm not thinking about
getting clisp to work with Sage anymore.
> 3. Newer/upstream version of pexpect is "almost" functional, but shows
> the problems in (1.) no only for gap, but for anything, and most
> worksheet files uses commands longer then 80 bytes.
You should also do speed tests with this new pexpect -- I never
noticed problems with it working, but with it just being insanely
slow.
>
> About gap, there is also another issue. Sage uses the "undocumented"
> -p option, but that is only used by xgap, and since I packaged xgap,
> it took me sometime to find out why gap would not work, and it was due
> to it failing to query the X Window System colormap, depth, etc. I
> "corrected" that by changing xgap to not be "autoloaded".
Interesting. How did you change xgap to not be autoloaded.
I've cc'd Steve Linton on this email -- he wrote the Sage<-->Gap
interface, and is the lead developer of GAP, so there is some chance
he'll have a comment. E.g., maybe -p can be documented? Maybe he
could document it right now in an email :-).
William
>
> --
> Paulo
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
