2009/9/5 William Stein <[email protected]>:
>
> 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".
Oops, I think I extended one behavior as if it were generalized,
should have confused with some test with newer pexpect, sorry. But one
way to reproduce the problem can be to do something like:
% mkdir -p
/tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage
<<make sure DOT_SAGE will point to that directory>>
% sage
<<exit sage>>
% ls
/tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage/gap/
README.txt
<<change DOT_SAGE to something like just /tmp/0123456789/>>
% sage
<<exit sage>>
% ls /tmp/0123456789/.sage/gap
README.txt workspace-1328071335
This happens because the SaveWorkspace() call had more then 80 characters,
and it severely bugs out when trying to build the documentation, because I would
set DOT_SAGE to the rpm buildroot, but now it uses a hack to
export DOT_SAGE=/tmp/sage$$
> 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.
I reverted to pexpect used by sage due to too many noise in the notebook
output, with blanks in the 80th character. But, usually it only happened when
needing to load something like gap or maxima. After repeating the execution
in the notebook, it would work.
>> 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.
The patch is somewhat simple, difficult was to find the reason of the
problem :-)
-%<-
--- gap4r4/pkg/xgap/PackageInfo.g.orig 2009-06-12 19:22:11.000000000 -0300
+++ gap4r4/pkg/xgap/PackageInfo.g 2009-06-12 19:23:22.000000000 -0300
@@ -242,7 +242,7 @@
## tests of other packages, as given above, will be done automatically and
## need not be included here.)
# AvailabilityTest := ReturnTrue,
-AvailabilityTest := function() return GAPInfo.CommandLineOptions.p; end,
+AvailabilityTest := ReturnFalse,
## If the default banner does not suffice then provide a string that is
## printed when the package is loaded (not when it is autoloaded or if
@@ -253,7 +253,7 @@
## started. This should usually be 'false'. Say 'true' only if your package
## provides some improvements of the GAP library which are likely to enhance
## the overall system performance for many users.
-Autoload := true,
+Autoload := false,
## *Optional*, but recommended: path relative to package root to a file which
## contains as many tests of the package functionality as sensible.
-%<-
> 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 :-).
Thanks. Another problem is that gap4r4/etc/emacs/comint.el is
outdated, and I temporarily bugged the emacs package by installing all
emacs files (and overwritting the emacs version of comint.el), but now
it only installs gap-*el
You can see the patches I added at
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gap-system/current/SOURCES/
There is also an XGap file, that adds some resources for a slightly
better look&feel, but it is kind hard to get that with Xaw widgets...
Also, xgap doesn't work very well with accents (I can't even get
quotes printed in it), but I think it is not much used...
Paulo
> William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---