Re: [Python-Dev] Python tickets summary
* This didn't show up when I sent it the other day, so I'm resending it. Facundo Batista wrote: 2007/12/10, Ron Adam [EMAIL PROTECTED]: This is from the search page of the tracker. select name=resolution id=resolution option value=don't care/option option value= disabled=disabled/option option value=1accepted/option option value=2duplicate/option option value=3fixed/option option value=4invalid/option option value=5later/option option value=6out of date/option option value=7postponed/option option value=8rejected/option option value=9remind/option option value=10wont fix/option option value=11works for me/option /select There are items in the tracker that have a resolutions set, but are still open. So the resolution field is the process status field. I don't think it needs to be mandatory. And the status field includes open/pending/close. Some resolutions imply that the issue is still open, and some imply that the issue should be closed. For example, I won't expect to see the issue still open if it's marked as won't fix, duplicate, fixed, invalid, out of date, or rejected. There are open items with those items set. won't fix 4 duplicate 0 fixed 3 invalid2 out of date3 rejected 2 Some of these may have been closed and reopened at some point. OTOH, it should be still open if the resolution is later, or remind. I'm not decided with works for me. Anyway, as I only show the open issues, Is it Open issues or Not Closed issues? The later would include pending issues as well. the resolution should be one of the later. Do you think that is useful the color to change if it is in later or remind? What's the benefit of this? Note that if we find open issues that are in the first group of resolutions, something should be corrected there. With 1,328 Open issues, anything that may help move things along would be good. I was thinking of maybe 4 background colors + grey, (Trying to use the existing resolution terms.) light grey: no resolution yet works for me? (can't reproduce?) Positive Progression points: light green works for me? (working patch/fix available?) accepted (patch accepted) fixed (patch applied) Don't close yet: light yellow later remind postponed pending out of date? (patch no longer works?) ready to close: light red duplicate won't fix rejected invalid With darker color vertical marks for status/resolution change points. Furthermore, I remember that somewhere there was a discussion of these values, and if we should keep all of them or not, but I can't find that thread. Possibly Here ... http://mail.python.org/pipermail/python-dev/2007-November/075160.html It was pointed out that these are hold-overs for SourceForge's bug tracker, and redesigning the work flow triage is something that needs to be done. It refers to ... http://wiki.python.org/moin/TrackerDocs/ Thank you! You're Welcome! Ron ___ 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] Summary of Tracker Issues
ACTIVITY SUMMARY (12/07/07 - 12/14/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1355 open (+41) / 11756 closed (+19) / 13111 total (+60) Open issues with patches: 423 Average duration of open issues: 689 days. Median duration of open issues: 901 days. Open Issues Breakdown open 1347 (+40) pending 8 ( +1) Issues Created Or Reopened (61) ___ Add VS CRT redist to the MSI installer 12/07/07 http://bugs.python.org/issue1569created tiran py3k Backport sys.maxsize to Python 2.6 12/07/07 http://bugs.python.org/issue1570created tiran Better description of 'L' repr removal in What's New 12/08/07 CLOSED http://bugs.python.org/issue1571created salty-horse py3k 404 report of SimpleXMLRPCServer is broken 12/08/07 CLOSED http://bugs.python.org/issue1572created tiran py3k Improper use of the keyword-only syntax makes the parser crash 12/08/07 CLOSED http://bugs.python.org/issue1573reopened amaury.forgeotdarc py3k Touchpad 2 Finger scroll does not work in IDLE on Mac (But scrol 12/09/07 http://bugs.python.org/issue1574created arorap typo in README 12/09/07 CLOSED http://bugs.python.org/issue1575created dalke [Patch] Working post import hook and lazy modules12/09/07 http://bugs.python.org/issue1576created tiran py3k, patch shutil.move() does not use os.rename() if dst is a directory 12/09/07 http://bugs.python.org/issue1577created init Problems in win_getpass 12/10/07 CLOSED http://bugs.python.org/issue1578created vizcayno py3k logging documentation is unclear 12/10/07 http://bugs.python.org/issue1579created Kylotan Use shorter float repr when possible 12/11/07 http://bugs.python.org/issue1580reopened gvanrossum py3k, patch xmlrpclib.ServerProxy() doesn't use x509 data12/10/07 http://bugs.python.org/issue1581created ahasenack Documentation patch for reversed() and __reversed__()12/10/07 http://bugs.python.org/issue1582created mark_t_russell Patch for signal.set_wakeup_fd 12/10/07 http://bugs.python.org/issue1583created rhamphoryncus patch Mac OS X: building with X11 Tkinter 12/11/07 http://bugs.python.org/issue1584created ceball IDLE uses non-existent xrange() function (Py30a2)12/11/07 CLOSED http://bugs.python.org/issue1585created mark py3k IDLE no longer shows colour syntax highlighting in the Shell (Py 12/11/07 CLOSED http://bugs.python.org/issue1586created mark py3k instancemethod wrapper for PyCFunctions 12/11/07 CLOSED http://bugs.python.org/issue1587created tiran py3k, patch str.format() wrongly formats complex() numbers (Py30a2) 12/11/07
Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).
On Dec 14, 2007 9:38 AM, Isaac Morland [EMAIL PROTECTED] wrote: I think we successfully resolved this. Adam Olsen will produce a patch that allows one to specify a single file descriptor to which a zero byte will be written by the C-level signal handler. Twisted and PyGTK I'm surprised that the byte is zero, rather than being the signal number. This would reflect the way C-level signal handlers work, where they are I believe called with the signal number. Is any discussion of this point conveniently available online? I ask for my own understanding, and definitely not out of a desire to re-open any settled issues! Yes, this was discussed previously in this thread. Go find it on mail.python.org/pipermail/python-dev/ -- --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] Signals+Threads (PyGTK waking up 10x/sec).
On Mon, 10 Dec 2007, Guido van Rossum wrote: I think we successfully resolved this. Adam Olsen will produce a patch that allows one to specify a single file descriptor to which a zero byte will be written by the C-level signal handler. Twisted and PyGTK I'm surprised that the byte is zero, rather than being the signal number. This would reflect the way C-level signal handlers work, where they are I believe called with the signal number. Is any discussion of this point conveniently available online? I ask for my own understanding, and definitely not out of a desire to re-open any settled issues! Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] Issues 1559298 and 1475 consolidation
Should these two issues be consolidated? It looks as if they are attacking the same problem. Thoughts? Joseph Armbruster ___ 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] Call for Project Participation in Development Sprints at PyCon 2008
Python-related projects: join the PyCon Development Sprints! The development sprints are a key part of PyCon, a chance for the contributors to open-source projects to get together face-to-face for up to four days of intensive learning and development. Newbies sit at the same table as the gurus, go out for lunch and dinner together, and have a great time while advancing their project. At PyCon 2007 in Dallas we must have had 20 projects sprinting. If your project would like to sprint at PyCon, now is the time to let us know. We need to collect the info and publish it, so participants will have time to make plans. We need to get the word out early, because no matter what we do during the conference, most people who haven't already decided to sprint won't be able to stay, because they have a planes to catch and no hotel rooms. In the past, many people have been reluctant to commit to sprinting. Some may not know what sprinting is all about; others may think that they're not qualified to sprint. We want to change that perception. * We want to help promote your sprint. The PyCon website, the PyCon blog, the PyCon podcast, and press releases will be there for you. * PyCon attendees will be asked to commit to sprints on the registration form, which will include a list of sprints with links to further info. * We will be featuring a How To Sprint session on Sunday afternoon, followed by sprint-related tutorials, all for free. * Some sponsors are helping out with the sprints as well. There's also cost. Although the sprinting itself is free, sprints have associated time and hotel costs. We can't do anything about the time cost, but we may have some complimentary rooms and funding available for sprinters. We will have more to say on financial aid later. Those who want to propose a sprint should send the following information to [EMAIL PROTECTED]: * Project/sprint name * Project URL * The name and contact info (email telephone) for the sprint leader(s) and other contributors who will attend the sprint * Instructions for accessing the project's code repository and documentation (or a URL) * Pointers to new contributor information (setup, etc.) * Any special requirements (projector? whiteboard? flux capacitor?) We will add this information to the PyCon website and set up a wiki page for you (or we can link to yours). Projects need a list of goals (bugs to fix, features to add, docs to write, etc.), especially some goals for beginners, to attract new sprinters. The more detail you put there, the more prepared your sprinters will be, and the more results you'll get. In 2007 there were sprints for Python, Jython, Zope, Django, TurboGears, Python in Education, SchoolTool, Trac, Docutils, the Python Job Board, PyCon-Tech, and other projects. We would like to see all these and more! The sprints will run from Monday, March 17 through Thursday, March 20, 2008. You can find more details here: http://us.pycon.org/2008/sprints/. Thank you very much, and happy coding! Facundo Batista, PyCon 2008 Sprint Coordinator David Goodger, PyCon 2008 Chair ___ 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] Signals+Threads (PyGTK waking up 10x/sec).
On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote: On 05:20 pm, [EMAIL PROTECTED] wrote: The best solution I can think of is to add a new API that takes a signal and a file descriptor and registers a C-level handler for that signal which writes a byte to the file descriptor. You can then create a pipe, connect the signal handler to the write end, and add the read end to your list of file descriptors passed to select() or poll(). The handler must be written in C in order to avoid the race condition referred to by Glyph (signals arriving after the signal check in the VM main loop but before the select()/poll() system call is entered will not be noticed until the select()/poll() call completes). This paragraph jogged my memory. I remember this exact solution being discussed now, a year ago when I was last talking about these issues. Ayup. I am extremely far from an expert here, but anyone wanting to have an informed opinion should really re-read the threads after these posts: http://mail.python.org/pipermail/python-dev/2006-September/068569.html http://mail.python.org/pipermail/python-dev/2007-January/070772.html I would recommend requesting review from either Nick Maclaren or Tim Peters as well. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Typing is cheap. Thinking is expensive. --Roy Smith ___ 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] Signals+Threads (PyGTK waking up 10x/sec).
On Dec 14, 2007 2:12 PM, Aahz [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote: On 05:20 pm, [EMAIL PROTECTED] wrote: The best solution I can think of is to add a new API that takes a signal and a file descriptor and registers a C-level handler for that signal which writes a byte to the file descriptor. You can then create a pipe, connect the signal handler to the write end, and add the read end to your list of file descriptors passed to select() or poll(). The handler must be written in C in order to avoid the race condition referred to by Glyph (signals arriving after the signal check in the VM main loop but before the select()/poll() system call is entered will not be noticed until the select()/poll() call completes). This paragraph jogged my memory. I remember this exact solution being discussed now, a year ago when I was last talking about these issues. Ayup. I am extremely far from an expert here, but anyone wanting to have an informed opinion should really re-read the threads after these posts: http://mail.python.org/pipermail/python-dev/2006-September/068569.html http://mail.python.org/pipermail/python-dev/2007-January/070772.html I would recommend requesting review from either Nick Maclaren or Tim Peters as well. Oh no, not Nick Maclaren! Anyway, did you see that we resolved this and have a patch ready for review? http://bugs.python.org/issue1583 -- --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] Signals+Threads (PyGTK waking up 10x/sec).
[private] On Fri, Dec 14, 2007, Guido van Rossum wrote: On Dec 14, 2007 2:12 PM, Aahz [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2007, [EMAIL PROTECTED] wrote: On 05:20 pm, [EMAIL PROTECTED] wrote: The best solution I can think of is to add a new API that takes a signal and a file descriptor and registers a C-level handler for that signal which writes a byte to the file descriptor. You can then create a pipe, connect the signal handler to the write end, and add the read end to your list of file descriptors passed to select() or poll(). The handler must be written in C in order to avoid the race condition referred to by Glyph (signals arriving after the signal check in the VM main loop but before the select()/poll() system call is entered will not be noticed until the select()/poll() call completes). This paragraph jogged my memory. I remember this exact solution being discussed now, a year ago when I was last talking about these issues. Ayup. I am extremely far from an expert here, but anyone wanting to have an informed opinion should really re-read the threads after these posts: http://mail.python.org/pipermail/python-dev/2006-September/068569.html http://mail.python.org/pipermail/python-dev/2007-January/070772.html I would recommend requesting review from either Nick Maclaren or Tim Peters as well. Oh no, not Nick Maclaren! ;-) Note carefully that I did not say you should necessarily follow Nick's advice. Still, having an expert tell you what you're doing wrong usually helps even if their advice isn't relevant. Anyway, did you see that we resolved this and have a patch ready for review? http://bugs.python.org/issue1583 Yeah, I saw that after the fact, but I still think referring to the previous threads should be useful for anyone wanting to review the patch. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Typing is cheap. Thinking is expensive. --Roy Smith ___ 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
