This is now http://trac.sagemath.org/15631
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send ema
On Tuesday, December 31, 2013 8:23:35 PM UTC-8, Volker Braun wrote:
>
> I also agree that it would be much better if the pexpect interfaces would
> have been written against non-echoing tty. Of course that'll only work if
> the subprocess doesn't turn echoing back on. The downside is of course th
Yes, agree that this is slightly different.
I also agree that it would be much better if the pexpect interfaces would
have been written against non-echoing tty. Of course that'll only work if
the subprocess doesn't turn echoing back on. The downside is of course that
you have to rewrite the way
On Monday, December 30, 2013 9:09:38 AM UTC-8, Volker Braun wrote:
>
> That is exactly what I am talking about: The pexpect pattern must match at
> a point where the subprocess has stopped processing and is just waiting for
> further input. But if you match for a prompt, say, and then the subproc
On Monday, December 30, 2013 8:33:57 AM UTC, Nils Bruin wrote:
>
> I don't think that's the issue here. The problem here seems to be that the
> subprocess sends output before the pty is done echoing. That doesn't seem
> to within pexpect's control: it's the subprocess that's too fast.
>
That is
On Sunday, December 29, 2013 10:50:31 PM UTC-8, Volker Braun wrote:
>
> This is similar to http://trac.sagemath.org/15440, the problem boils down
> to: The expect pattern must(!) trigger at a place where all input has been
> eaten. Including newline/spaces. If not then there is still input coming
This is similar to http://trac.sagemath.org/15440, the problem boils down
to: The expect pattern must(!) trigger at a place where all input has been
eaten. Including newline/spaces. If not then there is still input coming
into the subprocess, and the echo of that further input will show up at
r
OK, I think the following clearly indicates the sync problem we're running
into. This is a tiny example of a program that prompt for input and then
returns (fixed) output.
$cat hiho.c
#include
#include
int main(int argc, char** argv) {
char *line[1000];
size_t len = 0;
ssize_t readl
On Sunday, December 29, 2013 11:08:53 AM UTC-8, Nils Bruin wrote:
>
> I don't see why 31307 and 31305 decide to do different things.
>
In fact, it may be the following: Singular at some point does this write:
read(0, "print(sage698);\n", 1024) = 16
write(1, "x2^2-x0^2", 9)= 9
On Sunday, December 29, 2013 1:30:33 AM UTC-8, Nils Bruin wrote:
> The strace log directory sits in:
>
> http://sage.math.washington.edu/home/nbruin/strace.tgz
>
More specifically, I think the python process experiencing the error is
31307 and the singular process it is communicating with is 31
On Saturday, December 28, 2013 6:43:49 PM UTC-8, Volker Braun wrote:
>
> I can't reproduce it on my ssd, but might be timing related. Can you
> trigger it when you run as
>
> strace -s 1024 -ff -o tmpdir/log sage -tp2 tt*.py
>
> If there is a temp file conflict then we can figure it out from the
I can't reproduce it on my ssd, but might be timing related. Can you
trigger it when you run as
strace -s 1024 -ff -o tmpdir/log sage -tp2 tt*.py
If there is a temp file conflict then we can figure it out from the log...
On Saturday, December 28, 2013 11:33:59 PM UTC, Nils Bruin wrote:
>
> O
On Friday, December 27, 2013 10:16:06 AM UTC-8, Nils Bruin wrote:
>
> I'm finding that "sandpiles.py" often fails for me for varous reasons
> while doing `make ptest`. Testing the file individually or via `sage -tp
> src/sage/sandpiles` (i.e., just the relevant directory) seems fine.
>
It seems
13 matches
Mail list logo
