Sun, 15 Sep 2019 16:04:45 +0900 rust-cpython: store leaked reference to PySharedState in $leaked struct
Yuya Nishihara <yuya@tcha.org> [Sun, 15 Sep 2019 16:04:45 +0900] rev 43176
rust-cpython: store leaked reference to PySharedState in $leaked struct I want to move it out of the macro, and allow multiple sharable objects per PyObject.
Tue, 17 Sep 2019 07:59:25 +0900 rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send
Yuya Nishihara <yuya@tcha.org> [Tue, 17 Sep 2019 07:59:25 +0900] rev 43175
rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send The goal is to store &'static PySharedState in $leaked struct, which allows us to move the $leaked struct out of the macro. Currently, it depends on inner.$data_member(py), which can't be generalized. PySharedState is Sync because any mutation or read operation is synchronized by the Python GIL, py: Python<'a>, which should guarantee that &'PySharedState can be sent to another thread.
Sat, 14 Sep 2019 23:17:19 +0900 rust-cpython: move borrow_mut() to PySharedRefCell
Yuya Nishihara <yuya@tcha.org> [Sat, 14 Sep 2019 23:17:19 +0900] rev 43174
rust-cpython: move borrow_mut() to PySharedRefCell PySharedRefCell() will host almost all py_shared public functions. This change is the first step. borrow_mut() can be safely implemented since PySharedRefCell knows its inner object is managed by its own py_shared_state.
Sat, 14 Sep 2019 23:01:51 +0900 rust-cpython: move py_shared_state to PySharedRefCell object
Yuya Nishihara <yuya@tcha.org> [Sat, 14 Sep 2019 23:01:51 +0900] rev 43173
rust-cpython: move py_shared_state to PySharedRefCell object The goal of this series is to encapsulate more "py_shared" thingy and reduce the size of the macro, which is hard to debug. Since py_shared_state manages the borrowing state of the object owned by PySharedRefCell, this change makes more sense. If a PyObject has more than one data to be leaked into Python world, each PySharedState should incref the parent PyObject, and keep track of the corresponding borrowing state.
Thu, 10 Oct 2019 21:37:12 +0200 py3: decode username and password before SMTP login
Denis Laxalde <denis@laxalde.org> [Thu, 10 Oct 2019 21:37:12 +0200] rev 43172
py3: decode username and password before SMTP login smtplib.SMTP.login() requires str on Python 3. For 'password', we only need to decode when value comes from config as getpass() returns the correct type already.
Thu, 10 Oct 2019 21:30:44 +0200 py3: use socket.makefile() instead of dropped smtplib.SSLFakeFile
Denis Laxalde <denis@laxalde.org> [Thu, 10 Oct 2019 21:30:44 +0200] rev 43171
py3: use socket.makefile() instead of dropped smtplib.SSLFakeFile The latter (undocumented internal) class got removed in Python 3.3. Use socket.makefile() as suggested: https://docs.python.org/3/whatsnew/3.3.html#porting-python-code
Thu, 10 Oct 2019 21:05:34 +0200 py3: call SMTP.docmd() with an str
Denis Laxalde <denis@laxalde.org> [Thu, 10 Oct 2019 21:05:34 +0200] rev 43170
py3: call SMTP.docmd() with an str Otherwise, this always returns (502, '5.5.2 Error: command not recognized').
Thu, 10 Oct 2019 21:00:13 +0200 py3: call SMTP.has_extn() with an str
Denis Laxalde <denis@laxalde.org> [Thu, 10 Oct 2019 21:00:13 +0200] rev 43169
py3: call SMTP.has_extn() with an str Passing a bytes on Python 3 always returns False, thus starttls is not properly detected.
Thu, 10 Oct 2019 20:27:34 +0200 py3: fix sorting of obsolete markers when building bundle
Denis Laxalde <denis@laxalde.org> [Thu, 10 Oct 2019 20:27:34 +0200] rev 43168
py3: fix sorting of obsolete markers when building bundle Last item of marker tuple (parents) is either None or tuple. Comparison thus fails on Python 3 with: TypeError: '<' not supported between instances of 'tuple' and 'NoneType' Fixing this by coercing None to the empty tuple when sorting markers in exchange._getbundleobsmarkerpart().
Thu, 10 Oct 2019 04:34:58 +0200 sidedata: rename the configuration option to `exp-use-side-data`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 10 Oct 2019 04:34:58 +0200] rev 43167
sidedata: rename the configuration option to `exp-use-side-data` We don't want setup configured to use the final version that would end using the experimental one while using and older version. Differential Revision: https://phab.mercurial-scm.org/D7040
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip