> > > I don't know why, but maybe that can help you track it down.
>
> > Thanks - that definitely helps, since pexpect is actually passing
> > strings.
>
> Well, searching for "1024" in r.py results in two hits, and I think the
I don't know why that didn't occur to me.
> relevant one is
The other one seems to be a dud left over from interfaces/gp.py,
incidentally.
>
> # If an input is longer than this number of characters,
> then
> # try to switch to outputting to a file.
> eval_using_file_cutoff=1024)
>
> If you input a string longer than 1024 characters, it writes it to a file
> and then tries to read that file. It looks to me as though the method
> _read_in_file_command in r.py isn't doing the right thing: the correct
> string is getting written to the correct file, but then it's not getting
> imported properly. That is, in expect.py, it's executing this code:
>
> try:
> s = self._eval_line(self._read_in_file_command(tmp_to_use),
> allow_use_file=False)
>
> and it's returning an empty string, even though tmp_to_use is set to the
> correct file name and that file has the correct contents. I don't know R
> syntax, so I don't know what's going wrong.
Yeah, I'm investigating this, and somehow we are using source and file
not quite correctly. I've been trying a number of variations in the R
command line of Sage, and only can get something if I ask for verbose
output.
> source(file=file("/Users/.../.sage//temp/.../48141//interface//tmp48141",open="r"),verbose=TRUE)
'envir' chosen:<environment: R_GlobalEnv>
--> parsed 1 expressions; now eval(.)ing them:
>>>> eval(expression_nr. 1 )
=================
> c(1, 2, 3)
curr.fun: symbol c
[1] 1 2 3
.. after ‘expression(c(1, 2, 3))’
Hopefully I can track it down relatively quickly. Thank you very
much for your help on this.
- kcrisman
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
