sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.45k stars 480 forks source link

problem with newlines in gap eval #13178

Open kcrisman opened 12 years ago

kcrisman commented 12 years ago

See this sage-support thread.

Basically,

str1 = r"""

for n in [1..10] do
   for m in [1..10] do
      Print(m*n);
      Print(" - ");
   od;
od;
"""
gap.eval(str1)

erroneously adds newlines, while

str = r"""
for n in [1..10] do
   for m in [1..10] do
      Print(m*n);
      Print(" - ");
    od;
   Print("\n");
od;
"""
gap.eval(str)

doesn't return anything at all (well, the empty string).

gap.eval(str,newlines=False)

doesn't help, though it seems like there must be something going on related to it, given the first command.

This makes (for instance) a lot of stuff not work in the notebook with %gap.

Component: interfaces

Keywords: gap

Issue created by migration from https://trac.sagemath.org/ticket/13178

kcrisman commented 12 years ago

Description changed:

--- 
+++ 
@@ -33,4 +33,6 @@

gap.eval(str,newlines=False)

+doesn't help, though it seems like there must be something going on related to it, given the first command.
+
 This makes (for instance) a lot of stuff not work in the notebook with %gap.
kcrisman commented 12 years ago
comment:2

Yeah, this is maddening.

sage: gap.eval('  for n in [1..10] do       for m in [1..10] do             Print(m*n);             Print(" - ");         od;       Print("n"); od;')
''
sage: gap_console()
GAP4, Version: 4.4.12 of 17-Dec-2008, i686-apple-darwin10.8.0-gcc
gap>   for n in [1..10] do       for m in [1..10] do             Print(m*n);             Print(" - ");         od;       Print("n"); od;        
1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - n2 - 4 - 6 - 8 - 10 - 12 - 14 - 16 - 
18 - 20 - n3 - 6 - 9 - 12 - 15 - 18 - 21 - 24 - 27 - 30 - n4 - 8 - 12 - 16 - 
20 - 24 - 28 - 32 - 36 - 40 - n5 - 10 - 15 - 20 - 25 - 30 - 35 - 40 - 45 - 
50 - n6 - 12 - 18 - 24 - 30 - 36 - 42 - 48 - 54 - 60 - n7 - 14 - 21 - 28 - 
35 - 42 - 49 - 56 - 63 - 70 - n8 - 16 - 24 - 32 - 40 - 48 - 56 - 64 - 72 - 
80 - n9 - 18 - 27 - 36 - 45 - 54 - 63 - 72 - 81 - 90 - n10 - 20 - 30 - 40 - 
50 - 60 - 70 - 80 - 90 - 100 - ngap> 
sage: 
gvol commented 12 years ago
comment:3

There are two ways that sage sends data to GAP. The first is to send it line by line, and the second is to send it via a file. This last is used when there is a lot of data because, IIRC, it's faster. However, this messes up the use of stdout e.g. Print. So what's happening is if the input is long enough, it goes to a file. That's why removing some of the prints makes a difference. You can also get the same effect by adding a bunch of spaces in the middle (they are stripped from the beginning and the end).

One way around this is to use

gap.eval(...., allow_use_file=False)

which allows you to see that this is in fact the cause of the problem. The second method is to change the cutoff (default is 100)

gap._eval_using_file_cutoff = 1000

or disable it entirely

self._eval_using_file_cutoff = None

You can set it in ~/.sage/init.sage to make it "permanent".

As for a truly permanent solution, we could try disabling it if we see a function that prints to stdout like Print or Display, but it wouldn't work for custom functions. I don't think there is a way around this based on how GAP is currently written (except not using a file), but I could be wrong.

kcrisman commented 12 years ago
comment:4

Hmm, I don't know that one would want to completely disable it, but at least MUCH better documentation on exactly when to expect this problem - and how to work around it, like your suggestions - would be really helpful to close this ticket.

Also, how horrible would it be to expand the cutoff to something higher in general?