Change by Cornelius Diekmann <c.diekm...@googlemail.com>:
--
pull_requests: +4136
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Cornelius Diekmann <c.diekm...@googlemail.com> added the comment:
Yes, I get the AssertionError with the latest version of PR 3802. From the high
load avg of my system, you can see that the error occurs very rarely and that I
need to stress my system to trigger it. With PR 3802, the
Change by Cornelius Diekmann <c.diekm...@googlemail.com>:
--
pull_requests: +3792
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Cornelius Diekmann <c.diekm...@googlemail.com> added the comment:
I also added a pull request which I cannot get to fail on my system. What do
you think, haypo?
Sorry for the noise!
--
___
Python tracker <rep...@bugs.python.or
Cornelius Diekmann <c.diekm...@googlemail.com> added the comment:
Oh, one more thing, since it is unclear whether read or write is causing the
error. I replaced
os.write(slave_fd, TEST_STRING_1)
by
pty._writen(slave_fd, TEST_STRING_1)
which makes sure all bytes are written.
After som
Cornelius Diekmann <c.diekm...@googlemail.com> added the comment:
>> Does reading the string b'I wish to buy a fish license.\n' not cause a
>> problem, too?
>
>This string TEST_STRING_1 is used for a single os.write() call, whereas
>TEST_STRING_2 is splitted and wr
Cornelius Diekmann <c.diekm...@googlemail.com> added the comment:
Regarding PR 3802:
* Does reading the string b'I wish to buy a fish license.\n' not cause a
problem, too?
* Is reading len(expected) bytes the correct behavior for systems where
normalize_output is needed?
I also
Cornelius Diekmann added the comment:
I observed the same issue, but the problem occurs mainly when reading data. In
my proposed patch in issue29070, I use the existing pty._writen() to make sure
all data is written. As Martin mentioned, reading is a problem. My patch
proposes
Cornelius Diekmann added the comment:
Thank you Martin for your comments in the code review tool. I prepared a new
patch for the code review tool.
The github changelog from patch v4 (Feb 2017) to my HEAD (currently patch v5,
Apr 2017) is at:
https://github.com/python/cpython/compare/master
Cornelius Diekmann added the comment:
Uploaded a new version of the patch.
Changelog of this patch (compared to v3):
* Fixed reliability issue of existing pty tests.
* pty.fork() should now also work on systems without os.forkpty(). Added code
to test this backup path of pty.fork
Cornelius Diekmann added the comment:
Dear Martin, now I understand your intention. I merged my test suite with
Chris's fix and documented our insights. SmallPtyTests contains regression
tests for this issue.
While testing, I found a subtle change in behavior introduced by Chris's patch
Cornelius Diekmann added the comment:
Thank you Martin very much for this very helpful review. I updated and
simplified the tests and implemented your suggestions.
There are three open issues left.
1)
> It looks like you depend on fixing Issue 26228, but the patch there will
> co
Cornelius Diekmann added the comment:
[no status change, this issue currently does NOT need any attention]
To keep issues separate, I just wanted to document a comment about this issue
mentioned in issue29070. It refers to the _copy loop.
if STDIN_FILENO in rfds:
data
Cornelius Diekmann added the comment:
Status change: I proposed a generic test suite for pty.spawn() in issue29070.
Once we have agreed on the current behavior of pty.spawn() and the test suite
is merged, I would like to come back to this issue which requests for a change
in behavior
Cornelius Diekmann added the comment:
I just tested pty.spawn() on OS X 10.6.8 and FreeBSD 11 and it also hangs. It
works on Linux.
Your patch solves the problem. I proposed a test suite for pty.spawn() in
issue29070. The test suite currently only exposes the problem, as suggested by
Martin
Cornelius Diekmann added the comment:
I did a larger update to my proposed patch. I read the pty man pages and posix
standard and designed a test suite which documents the expected behavior of the
pty module. The test suite is biased towards my Linux system, but I respect the
posix standard
New submission from Cornelius Diekmann:
As Martin Panter noted, "it doesn’t look like pty.spawn() is tested at all"
[issue26228]. So I wrote some very basic integration tests for pty.spawn.
They work perfectly on my Linux machine. Line 4 of the library module under
test (pty.py) sta
Cornelius Diekmann added the comment:
Thank you Martin very much. To resolve this issue, I decided to document the
current behavior and add test cases for it. No change in behavior is
introduced. This hopefully allows to close this issue. The test cases for the
current behavior ensure that we
Cornelius Diekmann added the comment:
Make review tool happy by giving it less broken patch format :)
`make patchcheck` is already happy.
Sorry for the noise :(
--
Added file: http://bugs.python.org/file46015/pty_and_tests.patch
___
Python tracker
Cornelius Diekmann added the comment:
Review tool still did not show the test_pty.py file. Sry.
--
Added file: http://bugs.python.org/file46013/pty.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Cornelius Diekmann added the comment:
Removed git patch header from pty.patch to make python code review tool happy.
Sorry, this is my first contribution.
--
Added file: http://bugs.python.org/file46012/pty.patch
___
Python tracker <
Cornelius Diekmann added the comment:
I wrote a proper patch for the issue of handling EOF in STDIN, including tests.
My patch is against the github mirror head, but don't worry, the files I touch
haven't been touched in recent years ;-)
I only tested on Linux. My patch only addresses
New submission from Cornelius Diekmann:
My OS: Debian GNU/Linux 8.6 (jessie)
Python 3.4.2
pty.py from Python-3.5.2/Lib (pty.py is just a tiny, portable python file which
did not see many changes)
Bug Report
Steps to Reproduce:
I wrote a very simple python remote shell:
#!/usr/bin/env
23 matches
Mail list logo
