'uname' is asking about the version of the kernel; you want the version of Mac
OS X.
10.8.0 is pretty old; up-to-date Darwin kernel is 13.0.2.
If you want the whole-OS product version, the relevant command line is 'sw_vers
-productVersion'.
-glyph
On Jan 10, 2014, at 4:23 PM, Guido van Rossum
On 01/11/2014 12:52 AM, Tobias Oberstein wrote:
Am 11.01.2014 00:35, schrieb Victor Stinner:
Hi,
The new test fails on Mac OS X with the kqueue selector (it pass with
the select selector).
kqueue for pipes/processes is notoriously buggy on osx. in general: osx
sucks big regarding networking,
It's also possible that it's a 32-bit vs. 64-bit issue? My mac is 64 bit.
On Fri, Jan 10, 2014 at 2:23 PM, Guido van Rossum wrote:
> Oh wait, maybe we're not even talking about versions of the same
> thing. The 10.8.5 I quote is from the "About this Mac" dialog. My
> uname has 12.5.0. Your 10.8.0
Oh wait, maybe we're not even talking about versions of the same
thing. The 10.8.5 I quote is from the "About this Mac" dialog. My
uname has 12.5.0. Your 10.8.0 is from uname, so that's a completely
unrelated sequence of versions.
I doubt the Python or Tulip versions matter.
On Fri, Jan 10, 2014
Can you upgrade your OSX? 10.8.0 seems really old. Your uname -a
output says June 2011; mine has
Darwin guido-mba.corp.dropbox.com 12.5.0 Darwin Kernel Version 12.5.0:
Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64
x86_64
On Fri, Jan 10, 2014 at 2:10 PM, Victor Stinner
wrote:
2014/1/11 Guido van Rossum :
> On Fri, Jan 10, 2014 at 1:35 PM, Victor Stinner
> wrote:
>> The new test fails on Mac OS X with the kqueue selector (it pass with
>> the select selector).
>
> What OSX version? Other info? It passes with all three types of
> selectors for me on OS X 10.8.5.
$ uname
On Fri, Jan 10, 2014 at 1:35 PM, Victor Stinner
wrote:
> The new test fails on Mac OS X with the kqueue selector (it pass with
> the select selector).
What OSX version? Other info? It passes with all three types of
selectors for me on OS X 10.8.5.
> ==
Am 11.01.2014 00:35, schrieb Victor Stinner:
Hi,
The new test fails on Mac OS X with the kqueue selector (it pass with
the select selector).
kqueue for pipes/processes is notoriously buggy on osx. in general: osx
sucks big regarding networking, and in particular Apple's kqueue
implementation
Hi,
The new test fails on Mac OS X with the kqueue selector (it pass with
the select selector).
==
ERROR: test_read_pty_output (__main__.KqueueEventLoopTests)
--
One last question. Have you filled out a PSF contribution form? If
not, would you mind doing so? (Ideally you'd also tell me your
bugs.python.org username, so I can check.)
On Thu, Jan 9, 2014 at 1:28 PM, Jonathan Slenders wrote:
> Super. It's working on my real application code.
> The tests also
Super. It's working on my real application code.
The tests also run successfully on my ubuntu machine.
Thank you!
2014/1/9 Guido van Rossum
> OK, I think I get it now. I've worked up a simpler version of the
> patch, because I realized that the issue in _read_ready() is just that
> we don't wan
OK, I think I get it now. I've worked up a simpler version of the
patch, because I realized that the issue in _read_ready() is just that
we don't want the EIO exception to be logged. Your test still passes.
Let me know if your real code works with this version.
https://codereview.appspot.com/48350
2014/1/7 Guido van Rossum
> On Mon, Jan 6, 2014 at 10:57 PM, Jonathan Slenders
> wrote:
> > It was the code I meant, not the test.
> >
> > But I just tested your revised version, and now the unit tests succeed
> here
> > as well. Thanks.
>
> OK, but I'm not at all convinced that catching EIO and
On Mon, Jan 6, 2014 at 10:57 PM, Jonathan Slenders
wrote:
> It was the code I meant, not the test.
>
> But I just tested your revised version, and now the unit tests succeed here
> as well. Thanks.
OK, but I'm not at all convinced that catching EIO and treating it the
same as EOF is correct. I do
It was the code I meant, not the test.
But I just tested your revised version, and now the unit tests succeed here
as well. Thanks.
The master should be non blocking indeed. I my project i called
""io.open(self.master,
'wb', 0)""
Something related about blocking vs. non blocking. I don't kno
I looked into this. The tests pass on OSX (10.8), but fail indeed on
my Ubuntu VM. I can make them pass by catching the OSError with
errno==EIO and pretending it's an EOF *and* using
test_utils.run_until() instead of run_briefly() in the test (in both
places).
Here's a revised version of the patch
I created a patch: https://codereview.appspot.com/38500044/
That works, but the unit test still fails, I'm not sure how to correctly
close this pipe.
[tulip] > python runtests.py
Skipping 'test_windows_events': Windows only
Skipping 'test_windows_utils': Windows only
..
Why do you report a bug using a rhetorical question? :-)
Please file a bug either at http://code.google.com/p/tulip/issues/list
or bugs.python.org (the former gets my attention, the latter might get
other developers' attention). If you want to submit a patch with a
test that would be super. (See
h
Hi all,
Why does loop.connect_read_pipe not support the pipes that openpty()
creates, but is does for os.pipe()
master, slave = os.openpty()
shell_out = io.open(master, 'rb', 0)
transport, protocol = yield from loop.connect_read_pipe(MyProtocol,
shell_out)
In unix_events.py, there's the foll
19 matches
Mail list logo
