Re: [Python-Dev] Spurious Buildbot Reports

[Nick Coghlan]

Raymond Hettinger wrote:
> The bots are kicking-off so many false alarms that it is becoming
> difficult to tell whether a check-in genuinely broke a build.

It would also be nice if the checkins list only got spammed for actual 
compile or test failures. I'm not all that interested in getting an 
email just because a box got rebooted or lost its net connection for a 
while.

In terms of checking the buildbot status page itself, it would be a lot 
more convenient if the "current/last build" field on the buildbot slave 
details page was a hyperlink to that build's results page rather than a 
mere number as it is now.

> At the root of the problem is a number of tests in the test suite
> that randomly blow-up.  I now tend to automatically dismiss failures
> in test_logging and test_threading for example.

I haven't noticed that so much as the fact that a few of the buildbots 
have been pretty much permanently red for quite some time. Some examples:

alpha tru64:
   Checking the build results for this machine usually shows quite a few 
different errors, although the latest addition to the collection is a 
segfault in test_ctypes. Do we really support tru64 well enough to have 
it as a build slave?

ppc debian unstable:
   test_xmlrpc failing with connection reset by peer errors. I think 
I've seen that on other platforms as well, but this one seems to do it 
nearly constantly. (I don't know enough about the structure of that test 
to know if a GHOP student could figure out the problem without access to 
a machine where the test fails consistently - might be worth a try though)

MIPS debian:
   test_urllib2net FTP tests are failing, apparently complaining that 
SocketType expects two arguments rather than three. Probably a hard one 
to figure out without access to a machine where the test is actually 
failing (even my description of the problem involves some guesswork 
based on reading the code near where the failure occurs).

I think a few of the others (such as hppa Ubuntu) also have issues.

It's gotten to the point where I only pay any real attention to about 
half the trunk buildbots (looking at the status summary page, I would 
probably investigate further if sparc solaris, g4 osx 10, XP-3, XP-4 or 
x86 FreeBSD turned red after one of my checkins) and pretty much ignore 
the rest.

Would it be possible to distinguish the reliable buildbots from the 
problematic ones in the build master? If such a distinction can be made, 
it might then be possible to arrange for email to be sent to the checkin 
list only if one of the reliable buildbots fail.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Possible bug related with Tkinter ?

[Quentin Gallet-Gilles]

While testing the tkFileDialog, I encountered a strange error :

~/dev/trunk$ ./python Lib/lib-tk/tkFileDialog.py
Traceback (most recent call last):
  File "Lib/lib-tk/tkFileDialog.py", line 202, in 
openfilename=askopenfilename(filetypes=[("all files", "*")])
  File "Lib/lib-tk/tkFileDialog.py", line 125, in askopenfilename
return Open(**options).show()
  File "/home/quentin/dev/trunk/Lib/lib-tk/tkCommonDialog.py", line 48, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: expected floating-point number but got "0.0"

Investigating a little, I discovered this is a known issue for some
applications like Pyraf and that the following workaround is effective
: "env LC_NUMERIC=C ./python Lib/lib-tk/tkFileDialog.py".

Looking further, this seems to resolve an atof issue and the fact that
Python assumes a C locale while my Linux box actually uses
fr_FR.UTF-8, but I have a hard time determining if that a Python
issue, a TCL issue or something else.

Has someone already encountered this ?

Quentin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug related with Tkinter ?

[Nick Coghlan]

Quentin Gallet-Gilles wrote:
> Has someone already encountered this ?

Without any version numbers, it's hard to say. More recent versions of 
Python don't assume LC_NUMERIC is set to the C locale, but older 
versions did.

Cheers,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] epoll() and kqueue wrapper for the select module

[Christian Heimes]

Linux Kernel 2.6+ and BSD (including Mac OS X) have two I/O event
notification systems similar but superior to select() and poll(). From
the manuals:

kqueue, kevent -- kernel event notification mechanism

The kqueue() system call provides a generic method of notifying the user
when an event happens or a condition holds, based on the results of
small pieces of kernel code termed filters.  A kevent is identified by
the (ident, filter) pair; there may only be one unique kevent per kqueue.


epoll - I/O event notification facility

epoll  is  a variant of poll(2) that can be used either as an
edge-triggered or a level-triggered interface and scales well to large
numbers of watched file descriptors.


I've written wrappers for both mechanisms. Both wrappers are inspired
from Twisted and select.poll()'s API. The interface is more Pythonic
than the available wrappers and it reduced the burden on the user. The
users don't have to deal with low level control file descriptors and the
fd is closed automatically when the object is collected.

epoll interface

>>> ep = select.epoll(1)
>>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)
>>> ep.modify(fd, select.EPOLL_OUT)
>>> events = ep.wait(1, 1000)
>>> ep.unregister(fd)

kqueue interface

The kqueue interface is more low level than the epoll interface. It has
too many options.
>>> kq = select.kqueue()
>>> ev = [select.kevent(fd, select.KQ_FILTER_WRITE,
  select.KQ_EV_ONESHOT | select.KQ_EV_ADD)]
>>> kq.control(ev, 0, 0)
>>> events = kq.control([], 1, None)

I already talked to some Twisted guys and they really like it. A patch
is available at http://bugs.python.org/issue1657. The code needs more
unit tests and documentation updates.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] epoll() and kqueue wrapper for the select module

[Ross Cohen]

On Thu, Dec 20, 2007 at 06:08:47PM +0100, Christian Heimes wrote:

> I've written wrappers for both mechanisms. Both wrappers are inspired
> from Twisted and select.poll()'s API. The interface is more Pythonic
> than the available wrappers and it reduced the burden on the user. The
> users don't have to deal with low level control file descriptors and the
> fd is closed automatically when the object is collected.

Did you look at the python-epoll module which has been in the Cheese
Shop for quite some time? There is no messing with a low level control
file descriptor and it presents an identical interface to select.poll().

I would claim this whole new interface:

> epoll interface
> 
> >>> ep = select.epoll(1)
> >>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)
> >>> ep.modify(fd, select.EPOLL_OUT)
> >>> events = ep.wait(1, 1000)
> >>> ep.unregister(fd)

Is a greater burden on the user than:

>>> import epoll as select

I would also claim that adding a new interface to accomplish the same
task is not more pythonic. But I did write the python-epoll module in
question, so I may be a bit biased.

Ross
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] test_sys failures

[Guido van Rossum]

When I build from scratch and run most tests (regrtest.py -uall) I get
some strange failures with test_sys.py:

test test_sys failed -- Traceback (most recent call last):
  File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py",
line 302, in test_43581
self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding)
AssertionError: 'ascii' != 'ISO-8859-1'

The same test doesn't fail when run in isolation.

Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6!

Any ideas?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_sys failures

[Joseph Armbruster]

I am unable to reproduce this in windows with:

Python 3.0a2 (py3k:59584M, Dec 20 2007, 16:24:12) [MSC v.1500 32 bit
(Intel)] on win32

Running the test via rt and in isolation does not appear to fail.  In
isolation produces 16 OKs.

Joe

On Dec 20, 2007 3:58 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> When I build from scratch and run most tests (regrtest.py -uall) I get
> some strange failures with test_sys.py:
>
> test test_sys failed -- Traceback (most recent call last):
>  File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py",
> line 302, in test_43581
>self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding)
> AssertionError: 'ascii' != 'ISO-8859-1'
>
> The same test doesn't fail when run in isolation.
>
> Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6!
>
> Any ideas?
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] epoll() and kqueue wrapper for the select module

[Gregory P. Smith]

On 12/20/07, Ross Cohen <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 20, 2007 at 06:08:47PM +0100, Christian Heimes wrote:
>
> > I've written wrappers for both mechanisms. Both wrappers are inspired
> > from Twisted and select.poll()'s API. The interface is more Pythonic
> > than the available wrappers and it reduced the burden on the user. The
> > users don't have to deal with low level control file descriptors and the
> > fd is closed automatically when the object is collected.
>
> Did you look at the python-epoll module which has been in the Cheese
> Shop for quite some time? There is no messing with a low level control
> file descriptor and it presents an identical interface to select.poll().
>
> I would claim this whole new interface:
>
> > epoll interface
> >
> > >>> ep = select.epoll(1)
> > >>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)
> > >>> ep.modify(fd, select.EPOLL_OUT)
> > >>> events = ep.wait(1, 1000)
> > >>> ep.unregister(fd)
>
> Is a greater burden on the user than:
>
> >>> import epoll as select
>
> I would also claim that adding a new interface to accomplish the same
> task is not more pythonic. But I did write the python-epoll module in
> question, so I may be a bit biased.
>
> Ross


Providing a compatibility layer that mirrors the select.select or
select.poll interface using the best underlying syscall may be nice but...
In order to gain the most benefit from any of these system calls they should
be exposed directly.  Do the compatibility wrapping in python but leave the
low level calls exposed for those that want them, they make a big difference
to what an application can do.  (i believe kqueue/kevent can handle signals,
etc)

I like this patch.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com