Sun, 08 Apr 2018 11:55:46 +0900 wireproto: convert python literal to object without using unsafe eval()
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 11:55:46 +0900] rev 37476
wireproto: convert python literal to object without using unsafe eval() Follows up cc5a040fe150. At this point, I don't think we need a real eval(). If we want to support a set literal, maybe we can vendor ast.literal_eval(), which is relatively simple function.
Sun, 08 Apr 2018 12:30:59 +0900 tests: quote variable passed to shell test command
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 12:30:59 +0900] rev 37475
tests: quote variable passed to shell test command
Sun, 08 Apr 2018 11:23:55 +0900 py3: system-stringify repr(frame)
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 11:23:55 +0900] rev 37474
py3: system-stringify repr(frame) That's the Py3 requirement.
Sun, 08 Apr 2018 11:21:58 +0900 wireproto: show unknown id and flags in repr(frame)
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 11:21:58 +0900] rev 37473
wireproto: show unknown id and flags in repr(frame) Perhaps we'll want it for debugging.
Sun, 08 Apr 2018 11:14:47 +0900 wireproto: fix repr(frame) to not crash by unknown type id
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 11:14:47 +0900] rev 37472
wireproto: fix repr(frame) to not crash by unknown type id Follows up 5ef2da00e935.
Sun, 08 Apr 2018 15:39:08 +0900 py3: use s.startswith() instead of s[n] while parsing patches
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 15:39:08 +0900] rev 37471
py3: use s.startswith() instead of s[n] while parsing patches I know 'bytes[n] in bytes' magically works, but I'm tired of finding which one breaks the tests.
Sun, 08 Apr 2018 15:32:09 +0900 py3: do not try to byte-stringify None in cmdutil.tryimportone()
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 15:32:09 +0900] rev 37470
py3: do not try to byte-stringify None in cmdutil.tryimportone() It's a debug message, so just use '' instead.
Sun, 08 Apr 2018 15:22:30 +0900 py3: work around weird handling of bytes/unicode in decode_header()
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 15:22:30 +0900] rev 37469
py3: work around weird handling of bytes/unicode in decode_header() Basically decode_header() works as follows, and on Python 3, email headers ARE UNICODE. def decode_header(header): if not ecre.search(header): # ecre is unicode regexp return [(header, None)] # so header is unicode string ... decode header into [(bytes_data, unicode_charset_name)] return collapsed
Sun, 08 Apr 2018 15:03:00 +0900 py3: use system string to access email headers
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 15:03:00 +0900] rev 37468
py3: use system string to access email headers
Sun, 08 Apr 2018 14:59:12 +0900 py3: fix string issues of email message in test-import.t
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 14:59:12 +0900] rev 37467
py3: fix string issues of email message in test-import.t - payload can be bytes - headers must be unicode on Python 3 - need to call msg.as_bytes() on Python 3, but msg.as_string() on Python 2, where bytes(msg) magic works
Sun, 08 Apr 2018 14:46:24 +0900 py3: use lower-cased module 'email.message' in test-import.t
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 14:46:24 +0900] rev 37466
py3: use lower-cased module 'email.message' in test-import.t
Sun, 08 Apr 2018 15:41:40 +0900 py3: drop b'' from error message of fancyopts
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Apr 2018 15:41:40 +0900] rev 37465
py3: drop b'' from error message of fancyopts
Sat, 07 Apr 2018 21:26:37 +0900 procutil: drop unused 'newlines' option from popen*() (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Apr 2018 21:26:37 +0900] rev 37464
procutil: drop unused 'newlines' option from popen*() (API) It's unlikely for us to use the universal_newlines option.
Sat, 07 Apr 2018 21:23:42 +0900 procutil: make explainexit() simply return a message (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Apr 2018 21:23:42 +0900] rev 37463
procutil: make explainexit() simply return a message (API) Almost all callers want it.
Sat, 07 Apr 2018 21:21:03 +0900 procutil: do not convert return code of signal exit to positive number (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Apr 2018 21:21:03 +0900] rev 37462
procutil: do not convert return code of signal exit to positive number (API) The docstring states that "codes from kill are negative", and it doesn't make sense to make exit/signal code ambiguous. .. api:: ``hook.hook()`` and ``hook.runhooks()`` may return a negative integer to denote that the process was killed by signal.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip