[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
Mike Coleman added the comment: Just to confirm, the real problem here was that tiny packets were being sent out by default, and the obvious fix (altering ac_out_buffer_size) didn't work. Looking at the code, it appears that the change by Josiah Carlson (#64062) causes ac_out_buffer_size (which currently defaults to 4096) to be obeyed. Should that 4096 be larger? MTU for jumbo packets is ~9000, I think, plus there's less system call overhead for larger values. (I use 62000 for my app, but I haven't studied alternatives lately.) Also, there are still two constants '512' in asyncore/asynchat. Shouldn't these be changed to match the 4096 default? -- ___ Python tracker <http://bugs.python.org/issue2073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3392] subprocess fails in select when descriptors are large
Mike Coleman added the comment: My original report didn't mention it specifically, but I believe I was hitting the FD_SETSIZE limit that Frank mentioned. (Thanks for working on this!) -- ___ Python tracker <http://bugs.python.org/issue3392> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3392] subprocess fails in select when descriptors are large
Mike Coleman added the comment: I also ran into this bug. In my case I'm able to work around this by "reserving" some fds at the start of my program (open 20 reserved fds, open 2000 real fds, close 20 reserved fds), but this is both a kludge and not a general solution. Probably virtually all uses of 'select' (both in Python and C) should be replaced under Linux with poll or epoll. (Also, until/unless this is fixed, it'd be nice to mention it in the 'communicate' doc.) -- nosy: +mkc ___ Python tracker <http://bugs.python.org/issue3392> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5320] I/O error during one-liner gives bad diagnostic (and fails to return OS error status)
Mike Coleman added the comment: Also, as with the other python versions, notice that the error status is EXIT_SUCCESS (which it should not be). ___ Python tracker <http://bugs.python.org/issue5320> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5321] I/O error during one-liner gives no (!) diagnostic (and fails to return OS error status)
New submission from Mike Coleman :
$ python3.0 -c 'print((1, 2, 3))' > /dev/full || echo error status
$
This command gives no indication whatsoever that anything has gone
wrong. Following this with strace demonstrates that the interpreter is
in fact ignoring these errors:
2589 write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589 rt_sigaction(SIGINT, {SIG_DFL}, {0x47aa49, [], SA_RESTORER,
0x7fd5aa9da080}, 8) = 0
2589 write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589 exit_group(0) = ?
--
components: Interpreter Core
messages: 82486
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner gives no (!) diagnostic (and fails to return
OS error status)
type: behavior
versions: Python 3.0
___
Python tracker
<http://bugs.python.org/issue5321>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5320] I/O error during one-liner gives bad diagnostic (and fails to return OS error status)
New submission from Mike Coleman : $ python2.6 -c 'print 1, 2, 3' > /dev/full || echo error status close failed in file object destructor: Error in sys.excepthook: Original exception was: $ It seems like something other than blank lines should be printed here. -- components: Interpreter Core messages: 82485 nosy: mkc severity: normal status: open title: I/O error during one-liner gives bad diagnostic (and fails to return OS error status) type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5320> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] I/O error during one-liner fails to return OS error status
Mike Coleman added the comment: Oops, I should have used the old python print syntax. Nonetheless, the behavior is the same: $ python2.5 -c 'print 1, 2, 3' > /dev/full || echo error status close failed: [Errno 28] No space left on device $ -- components: +Interpreter Core ___ Python tracker <http://bugs.python.org/issue5319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] I/O error during one-liner fails to return OS error status
New submission from Mike Coleman : $ python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status close failed: [Errno 28] No space left on device $ The above sequence should also output 'error status' before the next prompt. That is, python should not be returning EXIT_SUCCESS in this situation. -- messages: 82482 nosy: mkc severity: normal status: open title: I/O error during one-liner fails to return OS error status type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue5319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue727732] getpath.c-generated prefix wrong for Tru64 scripts
Mike Coleman added the comment: I'll go down to the cemetery and see if I can dig one up. :-) All of our Tru64 machines have been powered-down for over three years now, so as far as I'm concerned you can mark this one as no longer relevant. ___ Python tracker <http://bugs.python.org/issue727732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4731] suggest change to "Failed to find the necessary bits to build these modules" message
New submission from Mike Coleman : I was thrown by the "Failed to find the necessary bits to build these modules" message at the end of newer Python builds, and thought that this indicated that the Python executable itself was not built. That's arguably stupidity on my part, but I wonder if others will not trip on this, too. Would it be possible to change this wording slightly, to something like Python built, but failed to find the necessary bits to build these modules ? -- components: Build messages: 78245 nosy: mkc severity: normal status: open title: suggest change to "Failed to find the necessary bits to build these modules" message type: feature request versions: Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3262] re.split doesn't split with zero-width regex
Mike Coleman <[EMAIL PROTECTED]> added the comment: Okay. For what it's worth, note that my original 2004 patch for this (#988761) is completely backward compatible (a flag must be set in the call to get the new behavior). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3262] re.split doesn't split with zero-width regex
Mike Coleman <[EMAIL PROTECTED]> added the comment: I think it's probably both. The original design was incorrect, though this probably wasn't apparent to the designer. But as a significant user of 're', it really stands out as a problem. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3262] re.split doesn't split with zero-width regex
Mike Coleman <[EMAIL PROTECTED]> added the comment: I don't want to discourage you, but #852532, which is essentially the same bug report, was closed--without explanation--as 'wont fix' in April, after four-plus years. I wish you good luck--this is an important and irritating bug, in my opinion... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3262] re.split doesn't split with zero-width regex
Changes by Mike Coleman <[EMAIL PROTECTED]>: -- nosy: +mkc ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue852532] ^$ won't split on empty line
Mike Coleman <[EMAIL PROTECTED]> added the comment: I'd feel better about this bug being 'wont fix'ed if I had a sense that several people considered the patch and thought that it sucked. At the moment, it seems more like it just fell off of the end without ever being seriously contemplated. :-( Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue852532> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
Mike Coleman <[EMAIL PROTECTED]> added the comment: [Tracker bounced this the first time...] > I haven't run it, but just browsing the trunk source, it appears to > still be present. In fact, asynchat.py and asyncore.py have > apparently not been changed in two years. Andrew Kuchling would seem > to be the closest to this code (?), since medusa is apparently dead. > > (More broadly, if these modules are going to stay, they really need to > be preened and better documented. It's not at all obvious, for > example, how the handle_error, handle_expt, and handle_close functions > all fit together. Is handle_error supposed to call handle_close, or > will the modules make that happen internally? etc.) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2073> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
Mike Coleman added the comment: The other place I see the constant is in asyncore.py: class dispatcher_with_send(dispatcher): def __init__(self, sock=None, map=None): dispatcher.__init__(self, sock, map) self.out_buffer = '' def initiate_send(self): num_sent = 0 num_sent = dispatcher.send(self, self.out_buffer[:512]) self.out_buffer = self.out_buffer[num_sent:] This code seems to be undocumented and perhaps unused, but until/unless it's deleted, it probably ought to be fixed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2073> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
Mike Coleman added the comment: The value is used there, but this is not effective in causing larger packets to be sent, which I noticed by watching with strace. I think the reason for this is that 'refill_buffer' will only make at most one call to simple_producer.more, and that call will produce at most 512 bytes, because that's the default value of that argument, and its not overridden in the call that creates the simple_producer inside of 'push'. In addition, I see at least one other place in the code where the constant '512' appears. Probably all of these should be changed to use the 'ac_*' values, or at least a larger constant. Looking at the big picture, though, I don't understand why we're trying to break this stuff up in the first place. That seems like the job of the OS, and it may well do it faster and better anyway. I would think that every call to socket 'send' should try to ram as much data through as possible. The return value will let us know what actually happened. (In my application, send's of size >200K are regularly succeeding, as seen with strace. I got this behavior by overriding 'push' with a fixed version.) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2073> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
New submission from Mike Coleman: In asynchat, 'push' doesn't specify 'buffer_size', so the default of 512 is used. This is bogus and causes poor performance--it should use the value of 'ac_out_buffer_size' instead. -- components: Library (Lib) messages: 62294 nosy: mkc severity: normal status: open title: asynchat push always sends 512 bytes (ignoring ac_out_buffer_size) type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2073> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue852532] ^$ won't split on empty line
Mike Coleman added the comment: Well, I think we can conclude that it's expected by *them*. :-) I still find it surprising, and it somewhat lessens the utility of re.split for my use cases. (I think re.finditer may also suffer from the same problem, but I don't recall.) If you look at the comments attached to the patch for this bug, it looks like akuchling and rhettinger more or less saw this as being a bug worth fixing, though there were questions about exactly what the correct fix should be. http://bugs.python.org/issue988761 One comment about the your doc fix: You highlight a fairly useless zero-character match (e.g., "x*") to demonstrate the behavior, which might leave the user scratching his head. (I think this case was originally mentioned as a corner case, not one that would be useful.) It'd be nice to highlight a more useful case like '^(?=S)' or perhaps a little more generically something like '^(?=HEADER)' or '^(?=BEGIN)' which is a usage that tripped me up in the first place. Thanks for working on this! Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue852532> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
