Re: [Python-Dev] Python tickets summary
2007/12/8, Ron Adam [EMAIL PROTECTED]: Looks much improved! :-) Thanks! Maybe components and keywords could be combined together and use check boxes so more than one item at a time can be selected? Regarding the combination, I don't think so: I'm just showing the info from the Tracker differently, I don't want to change its concepts. Regarding the check-more-than-one: It could be done, but I don't know if it actually will prove useful (it's always nice to be in more control of the filters, but overcomplicating the searchs does not help anybody, there's a point there in the middle, :) ). Ideally the temporal bar could be more like a mini gant/status chart which indicates the status as well as th activity. Maybe the background color can change when the status changes. For this the concept of process need to be added to the Tracker. Today there's no such mandatory process for the issues. As I just show that info differently, I won't create an artificial process here. Thanks for your different proposals!! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Bug Day in January?
On Fri, Dec 07, 2007 at 10:04:38PM +0100, Georg Brandl wrote: there wasn't much response to the bug day proposal, but I still think it's a good idea. I'd propose a date in January, when Christmas etc. is over. It would also be nice if someone did the organizing who hasn't got a daily batch of GHOP tasks to review and commit :) I agree that a bug day would be a good idea, and am happy to help with the organizing. What needs to be done, once a date has been set and a bunch of announcements have been sent out? --amk ___ 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] Missing _sqlite checkin on trunk?
[EMAIL PROTECTED] wrote: On Nov 25 Gerhard Haering checked in a change to the release25-maint branch: Author: gerhard.haering Date: Sun Nov 25 18:40:35 2007 New Revision: 59184 Modified: python/branches/release25-maint/Modules/_sqlite/statement.c python/branches/release25-maint/Modules/_sqlite/util.c Log: - Backported a workaround for a bug in SQLite 3.2.x/3.3.x versions where a statement recompilation with no bound parameters lead to a segfault - Backported a fix necessary because of an SQLite API change in version 3.5. This prevents segfaults when executing empty queries, like our test suite does. This bug is also present on the trunk, yet I saw no indication that he checked in such a fix there. Gerhard's patch applies cleanly. I sent him an email after I saw the checkin and verified that the patch worked on the trunk, but have yet to hear back from him. Yes, I remember. I postponed updating the trunk because I planned sync it with the lastest pysqlite release instead. I've updated my TODO list. Is there some different method for getting sqlite changes into the trunk? ?! From my point of view it's a module like all the others, except it's also maintained externally as 'pysqlite'. -- Gerhard ___ 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] patching asyncore and asynchat
I've posted a new patch with the documentation for handle_expt and handle_error adjusted, thanks to the feedback from Giampaolo Rodola and James Y Knight. http://bugs.python.org/issue1563 ___ 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] Python tickets summary
Facundo Batista wrote: 2007/12/8, Ron Adam [EMAIL PROTECTED]: Looks much improved! :-) Thanks! Maybe components and keywords could be combined together and use check boxes so more than one item at a time can be selected? Regarding the combination, I don't think so: I'm just showing the info from the Tracker differently, I don't want to change its concepts. Regarding the check-more-than-one: It could be done, but I don't know if it actually will prove useful (it's always nice to be in more control of the filters, but overcomplicating the searchs does not help anybody, there's a point there in the middle, :) ). Ok, looking at it again, I agree. Ideally the temporal bar could be more like a mini gant/status chart which indicates the status as well as th activity. Maybe the background color can change when the status changes. For this the concept of process need to be added to the Tracker. Today there's no such mandatory process for the issues. As I just show that info differently, I won't create an artificial process here. Thanks for your different proposals!! Regards, 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. Do you have access to these and the times they are set? Cheers, 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
Re: [Python-Dev] Python tickets summary
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. 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, 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. 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. Thank you! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] patching asyncore and asynchat
On Dec 10, 2007 8:20 AM, Daniel Arbuckle [EMAIL PROTECTED] wrote: I've posted a new patch with the documentation for handle_expt and handle_error adjusted, thanks to the feedback from Giampaolo Rodola and James Y Knight. http://bugs.python.org/issue1563 Can someone else who understands asynchat please review this? -- --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 Dec 9, 2007 10:16 AM, [EMAIL PROTECTED] wrote: On 12:21 am, [EMAIL PROTECTED] wrote: Anyway, I would still like to discuss this on #python-dev Monday. Adam, in what time zone are you? (I'm PST.) Who else is interested? I'm also interested. I'm EST, but my schedule is very flexible (I'm on IRC pretty much all day for work anyway). Just let me know when it is. Adam I are now on #python-dev. Can you join? -- --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] patching asyncore and asynchat
I remembered right now that there's a patch pending which should be included in the trunk before solving issues related to py3k and/or applying other changes: http://bugs.python.org/issue1736190 Since it solves a lot of older and newer asyncore/chat issues I guess you should work on that one instead of using the current asyncore/chat versions available in the trunk. ___ 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).
Adam I are now on #python-dev. Can you join? 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 will have to coordinate about this file descriptor. Glyph believes this is possible and sufficient. (A preliminary version of the patch may be found here: http://dpaste.com/27576/ ) We considered two alternatives: (a) A patch by myself where the file descriptor would instead be passed together with a signal handler. This was eventually rejected because it places an extra burden on every piece of code that registers a signal handler. (b) A more elaborate patch by Adam which would allow many file descriptors to be registered. This was rejected for being more code and solving a problem that most likely doesn't exist (multiple independent main loops running in different threads). We also located the exact source of the 100 msec timeout in PyGTK: http://svn.gnome.org/viewvc/pygtk/trunk/gtk/gtk.override?annotate=2926 line 1075: *timeout = 100; The recommendation for the OLPC XO project is to remove this line or make the timeout much larger, as the only reason why this was even added to PyGTK is wanting a fast response to ^C from the console, which doesn't represent a viable use case on the XO. -- --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 Dec 10, 2007 4:26 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? 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 will have to coordinate about this file descriptor. Glyph believes this is possible and sufficient. http://bugs.python.org/issue1583 (A preliminary version of the patch may be found here: http://dpaste.com/27576/ ) We considered two alternatives: (a) A patch by myself where the file descriptor would instead be passed together with a signal handler. This was eventually rejected because it places an extra burden on every piece of code that registers a signal handler. (b) A more elaborate patch by Adam which would allow many file descriptors to be registered. This was rejected for being more code and solving a problem that most likely doesn't exist (multiple independent main loops running in different threads). We also located the exact source of the 100 msec timeout in PyGTK: http://svn.gnome.org/viewvc/pygtk/trunk/gtk/gtk.override?annotate=2926 line 1075: *timeout = 100; The recommendation for the OLPC XO project is to remove this line or make the timeout much larger, as the only reason why this was even added to PyGTK is wanting a fast response to ^C from the console, which doesn't represent a viable use case on the XO. -- --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/rhamph%40gmail.com -- Adam Olsen, aka Rhamphoryncus ___ 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] Non-portable address length calculation for AF_UNIX sockets in socketmodule.c
Hi all. I recently stumbled upon an address length calculation problem in socketmodule.c, for UNIX sockets and anonymous linux sockets, that is triggered on some embedded platforms due to padding issues. I have submitted a patch dealing with the issue about 4 months ago, but it is still unassigned, and the bug remains even in 3.0: http://bugs.python.org/issue1754489 I would be very grateful if some of the core developers can take a look at the issue so this can be fixed in time for 2.6. Vlado ___ 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 10/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? 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 will have to coordinate about this file descriptor. Glyph believes this is possible and sufficient. Great that a solution was found at last. But to be honest I don't understand why my patch (the second one) is not good. Why is it preferable for libraries to provide their own file descriptor? Are people concerned about the overhead of always creating a pipe even it may not be used? Always creating a pipe would at least avoid the need for any coordination between PyGTK and Twisted. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ 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 10, 2007 4:07 PM, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 10/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? 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 will have to coordinate about this file descriptor. Glyph believes this is possible and sufficient. Great that a solution was found at last. But to be honest I don't understand why my patch (the second one) is not good. Why is it preferable for libraries to provide their own file descriptor? So the app is in charge of creating the pipe if it wants it. We expect that if the pipe is always created, apps that assume only fds 0, 1 and 2 are open may get confused or accidentally close it, etc. Are people concerned about the overhead of always creating a pipe even it may not be used? Always creating a pipe would at least avoid the need for any coordination between PyGTK and Twisted. I don't think that anyone involved though the need for coordination was an issue. Please let this rest. We have a solution. -- --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 11/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 10, 2007 4:07 PM, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 10/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? 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 will have to coordinate about this file descriptor. Glyph believes this is possible and sufficient. Great that a solution was found at last. But to be honest I don't understand why my patch (the second one) is not good. Why is it preferable for libraries to provide their own file descriptor? So the app is in charge of creating the pipe if it wants it. We expect that if the pipe is always created, apps that assume only fds 0, 1 and 2 are open may get confused or accidentally close it, etc. It's the first time I hear about this problem, but sounds plausible. Are people concerned about the overhead of always creating a pipe even it may not be used? Always creating a pipe would at least avoid the need for any coordination between PyGTK and Twisted. I don't think that anyone involved though the need for coordination was an issue. Yeah. Thinking again on this, I don't think this is a problem, not because coordination between PyGTK and Twisted can be done, but because no such coordination is needed. PyGTK can have one FD, Twisted another FD. Since only one of the main loops can be running, there's no conflict. Please let this rest. We have a solution. Sure. :-) -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ 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] patching asyncore and asynchat
I provided a patch for the last issue I mentioned in the ticket a month ago: http://bugs.python.org/issue1736190 ___ 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] Python tickets summary
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/status 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
