2009/9/5 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andr...@gmail.com>:
>
> 2009/9/5 William Stein <wst...@gmail.com>:
>>
>> 2009/9/5 Paulo César Pereira de Andrade
>> <paulo.cesar.pereira.de.andr...@gmail.com>:
>>>
>>> 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$$
Can you please please post this stuff to trac.sagemath.org? I won't
be able to work on sage development for the next few weeks, and I
don't want this to get lost in the shuffle.
William
>
>> 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
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
