On Friday, June 29, 2012 5:42:14 AM UTC-4, Ivan Andrus wrote:
>
> 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
>
>
Ivan, do you mean gap._eval... ?
> You can set it in ~/.sage/init.sage to make it "permanent".
>
>
Considering that this will be on lab machines, I figure that this is
something that could be hard-coded into the machine image that is
distributed. They are using the notebook, so it is imperative that it be
somewhere where they don't have to do "gap.eval" all the time.
Walter,
> I also find it odd that an expression like 2 + 3 (without an
ending semicolon) produces output 5. In Gap this expression
would not produce output until a closing semicolon is entered. Hence, I
wonder if Sage is adding semicolons in unexpected
places. (Double semicolons suppress output.)
Yes, the string that Sage produces replaces all newlines with spaces (in
fact, indentation didn't seem to matter at all, syntactically), and adds a
semicolon at the very end, so that things like
sage: gap('2+2')
work. We do the same thing with Maxima.
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.
>
>
I think that documenting the kind of problem this makes, and how to avoid
it, much better would be sufficient.
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
