GAP does not start if the path to the GAP workspace file contains more than 82 characters

[saliola]

As pointed out in ​thread, on some machines one there is a problem starting GAP from within Sage:

sage: gap('3+2')
A workspace appears to have been corrupted... automatically rebuilding (this is harmless).
---------------------------------------------------------------------------
...
TypeError: Unable to start gap

The problem is in Sage's attempt to rebuild the GAP workspace. It turns out that Sage calls GAP's SaveWorkspace command incorrectly in a particular case.

To explain the problem, first recall the process used by the GAP interface to evaluate a line of GAP code, say LineOfGapCode. It begins by checking the length LineOfGapCode (as a string). If this length is greater than 100 (a pre-defined cut-off value), then a file is created containing:

Print(LineOfGapCode);

This file is read into GAP using the expect interface and the output is parsed and returned to Sage. (There is no problem if the length is less than 100, because the interface does not use a file.)

Let's apply this to the case where we need to rebuild a workspace. The workspace is just a file contained in a user's .sage directory. If the number of characters in the path to the workspace is greater than the cut-off, then Sage tries to execute the following command:

Print(SaveWorkspace("PathToWorkspaceFile"));

This is not permitted by GAP, as explained in the ​GAP Reference Manual:

SaveWorkspace can only be used at the main gap> prompt. It cannot be included in the body of a loop or function, or called from a break loop.

So to fix this, we need to force the interface not to use a file to execute the SaveWorkspace command.

(This problem has plagued all the computers in our computer lab for months since a user's home directory is located on a network drive with a long name.)

This is reproducible:

sage: ws = sage.interfaces.gap.WORKSPACE
sage: sage.interfaces.gap.WORKSPACE += "0"*(83-len(ws))
sage: gap = Gap()
sage: gap('3+2')

Boom!

[saliola]

apply only this patch!

[slabbe]

Applies over the precedent patch

[slabbe]

I was able to reproduce the problem on my osx 10.5 running sage-4.5.3. The patch fixes the problem. All tests pass on sage/interfaces/gap.py. Documentation builds fine.

I added a review patch that simply puts back the constant sage.interfaces.gap.WORKSPACE to its original value since the new value was used in all the rest of the doctests.

I am giving a positive review to Franco's patch. I let him change the status of this ticket to positive review if he agrees with my small fix.

I did not manage to apply a patch on the sage install of LaCIM laboratory by ssh. Maybe Jérôme could test the patch on Monday.

[saliola]

I'm okay with your changes, Sébastien.

Apply patches in this order:

1. trac9938.patch​
2. trac9938-review-sl.patch​

[slabbe]

I did not manage to apply a patch on the sage install of LaCIM laboratory by ssh. Maybe Jérôme could test the patch on Monday.

Last Monday, I tested the patch on one of the computer in the lab and I can confirm the patches solve the problem. Great!

[mpatel]

Thanks for fixing this! I encountered just this problem about two days ago when doctesting with a long DOT_SAGE.