This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Modify the _struct module to use FASTCALL and Argument Clinic
Type: performance Stage: resolved
Components: Argument Clinic Versions: Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: larry, martin.panter, methane, python-dev, serhiy.storchaka, skrah, vstinner
Priority: normal Keywords: patch

Created on 2017-01-17 16:31 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
struct_fastcall.patch vstinner, 2017-01-17 16:31 review
struct_fastcall-2.patch vstinner, 2017-01-26 17:27 review
struct_fastcall-3.patch vstinner, 2017-01-27 08:53 review
struct_fastcall-4.patch vstinner, 2017-01-27 14:40 review
struct_fastcall-5.patch vstinner, 2017-01-27 15:22 review
struct_fastcall-6.patch vstinner, 2017-01-27 15:46 review
struct_fastcall-7.patch serhiy.storchaka, 2017-02-02 10:02 review
cache_struct.patch serhiy.storchaka, 2017-02-02 12:22 review
unpack_buffer.patch vstinner, 2017-02-02 12:25 review
cache_struct-2.patch serhiy.storchaka, 2017-02-02 14:52 review
Messages (48)
msg285663 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-17 16:31
Attached patch modify the _struct module to use FASTCALL and Argument Clinic.

AC requires a summary line, so I duplicated the first sentence of iter_unpack() docstring:

iter_unpack(fmt, buffer, /)
    Return an iterator yielding tuples unpacked from the given bytes.
    
    Return an iterator yielding tuples unpacked from the given bytes
    source according to the format string, like a repeated invocation of
    unpack_from().  Requires that the bytes length be a multiple of the
    format struct size.
msg285669 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-17 17:07
Why not just convert the struct module to Argument Clinic?
msg286326 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-26 17:27
Patch version 2 converts most functions and methods to Argument Clinic, except of unpack() and unpack_into() which require "*args" support in Argument Clinic: see the issue #20291.
msg286327 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-26 17:27
I reformatted docstrings, and wrote a summary line.
msg286329 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-26 18:04
It looks to me that the Py_buffer converter can be used for all the buffer parameter and special purposed converter can be used for the fmt parameter.
msg286346 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 08:53
Patch version 3:

* Use also Argument Clinic for Struct.__init__()
* Rename fmt to format: in the code and docstring. By the way, Struct docstring was wrong: Struct() accepts a 'format' keyword argument, not 'fmt'
* Use Py_buffer converter for the buffer parameter, except for iter_unpack()
* Document that unpack_from() now accepts keywords and write an unit test
* Fix Struct.__init__() error message: the method accepts also Unicode
* Document that Struct accepts str encodable to ASCII and bytes

I would be nice to use Py_buffer format for the "buffer" argument of iter_unpack(), but Argument Clinic calls PyBuffer_Release(&buffer), whereas the buffer should stay alive after the function exit. Is there a way to clone/copy a Py_buffer?

For the fmt/format argument: s_init() uses custom code to accept Unicode encodable to ASCII and bytes objects. Using Argument Clinic to check fmt type would require to write a converter. I would prefer to not make too many changes in a single patch, and I don't know how to write such converter. I suggest to do that later and keep the existing code. It seems like all functions getting a format ends in s_init() to check the format argument.
msg286348 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-27 09:49
The converter for the format parameter already exists. It is cache_struct(). You just need to change its interface.

> * Fix Struct.__init__() error message: the method accepts also Unicode
> * Document that Struct accepts str encodable to ASCII and bytes

I think this should be backported to older versions. Maybe there is an open issue for this.

> I would be nice to use Py_buffer format for the "buffer" argument of iter_unpack(), but Argument Clinic calls PyBuffer_Release(&buffer), whereas the buffer should stay alive after the function exit. Is there a way to clone/copy a Py_buffer?

I agreed that the Py_buffer converter is not applicable here. Just object is good.
msg286349 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 10:16
> The converter for the format parameter already exists. It is cache_struct(). You just need to change its interface.

The code to convert the format string is in s_init(). The code increases the reference counter, I don't see how to produce the Py_DECREF() code.

Again, I would prefer to do that later. The change is already big enough :-)


> I think this should be backported to older versions.

Ok, will do once this change is accepted.
msg286350 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-27 10:40
static int
cache_struct_converter(PyObject *arg, PyObject **s_object)
{
    if (arg == NULL) {
        Py_DECREF();
        return 1;
    }
    *s_object = cache_struct(arg); // actually inline this
    if (*s_object == NULL)
        return 0;
    return Py_CLEANUP_SUPPORTED;
}
msg286351 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-27 10:42
See also ascii_buffer_converter in Modules/binascii.c for example.
msg286357 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 14:40
Thank you for your reviews Serhiy :-) Here is a new patch to take in account your latest comments.

I didn't change the API anymore: Struct.unpack_from() accepts keywords, unpack_from() doesn't.
msg286358 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 14:45
> See also ascii_buffer_converter in Modules/binascii.c for example.

Nice. I didn't know the "def cleanup" feature. I used it in my patch version 4.
msg286364 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-27 15:05
I said not about the converter that converts format to bytes (it is needed only in Struct.__init__), but about the converter that converts format to the Struct object. It is used in all module-level functions.
msg286367 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 15:22
New patch version 5 without the "format_converter".


Serhiy Storchaka: I said not about the converter that converts format to bytes (it is needed only in Struct.__init__),

For me, it makes sense to check format type earlier than Struct.__init__(), but since you like the current code, I'm also ok to leave this part of the code unchanged :-)


Serhiy: but about the converter that converts format to the Struct object. It is used in all module-level functions.

Sorry, but I dislike this change. Even if multiple functions do the same, for me creating a Struct object is not something part of the argument parsing. I prefer to keep the following 3 lines in each C function *body* to ease debugging:

    PyObject *s_object = cache_struct(format);
    if (s_object == NULL)
        return NULL;

IMHO my struct_fastcall-5.patch is already big enough. I prefer incremental changes.

I have no strong opinion on cache_struct(), just a matter of taste :-) And others may like your change!

Feel free to write your own patch on top of mine, once mine is merged ;-)
msg286373 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 15:46
Updated patch, version 6:

* Rename "obj" variable to "iter"
* Fix unpack_from() signature: only the first parameter is positional only
msg286645 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-01 16:16
Serhiy: Would you mind to review my latest patch, struct_fastcall-6.patch? It should address all your remarks, except your proposal to write a converter for cache_struct(): see my previous comment about this idea. Thanks in advance ;)
msg286659 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-01 17:13
It looks to me that the type of the self parameter can be changed from PyObject* to PyStructObject*. This will make the patch larger but the final code simpler.

    class Struct "PyStructObject *" "&PyStructType"
msg286712 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-01 22:01
> It looks to me that the type of the self parameter can be changed from PyObject* to PyStructObject*. This will make the patch larger but the final code simpler.

I like the idea, but I prefer to do in a separated change, once the first big one is merged. Otherwise, the first patch will do too many unrelated things at the same time IMHO.
msg286756 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 10:02
This doesn't make the patch much bigger. Usually such kind of changes are made in one patch.

Here is a patch that also changes the type of the self parameter to PyStructObject*.

struct_fastcall-6.patch LGTM, but I prefer struct_fastcall-7.patch.
msg286761 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 10:57
-    if (PyObject_GetBuffer(input, &vbuf, PyBUF_SIMPLE) < 0)
-        return NULL;

Oh by the way, I forgot to mention a subtle change. PyObject_GetBuffer(PyBUF_SIMPLE) is less strict that PyArg_Parse("y#") / "buffer" converter of Argument Clinic: getargs.c also checks that the buffer is contiguous, extract of getbuffer():

    if (!PyBuffer_IsContiguous(view, 'C')) {
        PyBuffer_Release(view);
        *errmsg = "contiguous buffer";
        return -1;
    }

I don't know well the buffer protocol. I don't know any object which provide a non-contiguous buffer. At least, I can say that the last time I looked at this dark part of Python, the documentation was between tiny and non-existent :-/ The buffer protocol is complex but not well documented :-(
msg286766 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-02-02 11:32
New changeset f3ff4a3ce77c by Victor Stinner in branch 'default':
Issue #29300: Convert _struct module to Argument Clinic
https://hg.python.org/cpython/rev/f3ff4a3ce77c
msg286767 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 11:37
I also prefer Serhiy's struct_fastcall-7.patch over my struct_fastcall-6.patch.

Serhiy Storchaka: "This doesn't make the patch much bigger. Usually such kind of changes are made in one patch."

Well, it's just that you prefer to reduce the number of commits and so fold tiny changes into a single big commit, whereas I now prefer multiple tiny commits. I have not strong preferences between the two ways to commit, so I pushed your patch.

Here is the full commit message, since Roundbot bot only shows the first line:
---
Issue #29300: Convert _struct module to Argument Clinic

* The struct module now requires contiguous buffers.
* Convert most functions and methods of the _struct module to Argument Clinic
* Use "Py_buffer" type for the "buffer" argument. Argument Clinic is
  responsible to create and release the Py_buffer object.
* Use "PyStructObject *" type for self to avoid explicit conversions.
* Add an unit test on the _struct.Struct.unpack_from() method to test passing
  arguments as keywords.
* Rephrase docstrings.
* Rename "fmt" argument to "format" in docstrings and the documentation.

As a side effect, functions and methods which used METH_VARARGS calling
convention like struct.pack() now use the METH_FASTCALL calling convention
which avoids the creation of temporary tuple to pass positional arguments and
so is faster. For example, struct.pack("i", 1) becomes 1.56x faster (-36%)::

    $ ./python -m perf timeit \
        -s 'import struct; pack=struct.pack' 'pack("i", 1)' \
        --compare-to=../default-ref/python
    Median +- std dev: 119 ns +- 1 ns -> 76.8 ns +- 0.4 ns: 1.56x faster (-36%)
    Significant (t=295.91)

Patch co-written with Serhiy Storchaka.
---

So yeah, the "side effect" is that struct.pack("i", 1) becomes 1.56x faster (-36%). Ok, maybe it was my main goal ;-) I also mentioned the "new" (?) contiguous requirement on buffers.

Thanks Serhiy for your multiple reviews, very useful as usual. I like the final result: better documentation, better docstrings and better code!
msg286768 - (view) Author: Roundup Robot (python-dev) (Python triager) Date:
New changeset e552e185f3087204d326409e8631eb33dd0e7958 by Victor Stinner in branch 'master':
Issue #29300: Convert _struct module to Argument Clinic
https://github.com/python/cpython/commit/e552e185f3087204d326409e8631eb33dd0e7958
msg286770 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-02-02 12:16
Shouldn’t the top-level unpack() parameter be called “buffer” like the other functions and methods, not “inputstr”?
msg286771 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 12:22
Propose for your consideration a patch that uses Argument Clinic for getting possible cached struct object from the format. This simplifies the implementation of module level functions.
msg286772 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-02-02 12:24
FYI Victor, you can make non-C-contiguous buffers by slicing memoryview:

>>> struct.unpack(">L", memoryview(b"1234")[::-1])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

Can also use the built-in _testbuffer module to create stranger buffers.
msg286773 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 12:25
Martin> Shouldn’t the top-level unpack() parameter be called “buffer” like the other functions and methods, not “inputstr”?

Hum. I reopen the issue.

Attached patch renames unpack() "inputstr" argument to "buffer" and uses the Py_buffer type for it. I had to fix unit tests which passed str instead of bytes to buffer. Before this error was missed because the unit test is written to test the format string value, not the type of arguments.
msg286774 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 12:37
> Oh by the way, I forgot to mention a subtle change.
> PyObject_GetBuffer(PyBUF_SIMPLE) is less strict that PyArg_Parse("y#") /
> "buffer" converter of Argument Clinic: getargs.c also checks that the
> buffer is contiguous, extract of getbuffer():

We already made such changes in the past. The difference is subtle and I have 
doubts that choosing any of ways was deliberate.
msg286775 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 12:43
> So yeah, the "side effect" is that struct.pack("i", 1) becomes 1.56x faster
> (-36%). Ok, maybe it was my main goal ;-) I also mentioned the "new" (?)
> contiguous requirement on buffers.

struct.pack() always was faster than int.to_bytes(). I wanted to speed up 
int.to_bytes(), and after converting to Argument Clinic in issue20185 it have 
became faster than struct.pack(). But after converting the struct module to 
Argument Clinic struct.pack() is faster than int.to_bytes() again! Now I need 
to find other ways to make int.to_bytes() even faster to win this chase.
msg286776 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 12:49
unpack_buffer.patch LGTM. Please backport test changes and other changes discussed before to other branches.
msg286781 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 13:15
Serhiy Storchaka: "But after converting the struct module to Argument Clinic struct.pack() is faster than int.to_bytes() again!"

Sorry about that ;-)


Serhiy Storchaka: "Now I need to find other ways to make int.to_bytes() even faster to win this chase."

I ran a microbenchmark:

$ ./python -m perf timeit -s 'to_bytes=int.to_bytes' 'to_bytes(1, 4, "little")'

Reference: ~154 ns

Replace int_to_bytes_impl() body with:
   PyBytes_FromStringAndSize("1", 1)
=> ~120 ns (-34 ns)

Replace int_to_bytes() body with:
   return int_to_bytes_impl(self, 4, NULL, 1);
=> ~76 ns (-44 ns)

_PyArg_ParseStackAndKeywords() with _PyArg_Parser{"nU|$p:to_bytes"} takes 44 ns on a total of 154 ns. 29% of the runtime is spent on parsing arguments.

If you want to optimize further int.to_bytes(), IMHO we should explore the issue #29419: "Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)?".
msg286782 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-02-02 13:19
New changeset 32380d41e788 by Victor Stinner in branch '3.5':
Issue #29300: test_struct tests unpack_from() with keywords
https://hg.python.org/cpython/rev/32380d41e788
msg286783 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-02-02 13:24
New changeset faa1e4f4b156 by Victor Stinner in branch 'default':
Rename struct.unpack() 2nd parameter to "buffer"
https://hg.python.org/cpython/rev/faa1e4f4b156
msg286784 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 13:25
Serhiy Storchaka: "We already made such changes in the past. The difference is subtle and I have 
doubts that choosing any of ways was deliberate."

Right. IMHO it's safe to make sure that the buffer is contiguous. I'm quite sure that the code doesn't support non-contiguous buffers.


Serhiy Storchaka: "Please backport test changes and other changes discussed before to other branches."

Done. Sorry, I forgot this part.


Serhiy Storchaka: "unpack_buffer.patch LGTM."

Thanks for the review, it's now merged. It was a regression in unpack() docstring, Python 3.5 docstring contains "unpack(fmt, buffer)".
msg286785 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 13:34
Martin Panter: """FYI Victor, you can make non-C-contiguous buffers by slicing memoryview:

>>> struct.unpack(">L", memoryview(b"1234")[::-1])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous"""

Oh, it means that the Argument Clinic change doesn't add new checks on the buffer? In Python 3.6, memory_getbuf() raises an exception in the following code:

    if (!REQ_STRIDES(flags)) {
        if (!MV_C_CONTIGUOUS(baseflags)) {
            PyErr_SetString(PyExc_BufferError,
                "memoryview: underlying buffer is not C-contiguous");
            return -1;
        }
        view->strides = NULL;
    }

I undersrtand that memory_getbuf() is smart enough to raise an exception becaues the buffer is not contiguous. But a weaker implementation of getbuffer may not implement such check, whereas getbuffer() double check that the buffer is C-contiguous. Am I right?
msg286786 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 13:36
I like the overall cache_struct.patch change, but I have questions: see my review.
msg286789 - (view) Author: Roundup Robot (python-dev) (Python triager) Date:
New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch 'master':
Issue #29300: test_struct tests unpack_from() with keywords
https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784

New changeset dcd4b1af2c59b0aae33cbac00d9f6fb47782ac57 by Victor Stinner in branch 'master':
Rename struct.unpack() 2nd parameter to "buffer"
https://github.com/python/cpython/commit/dcd4b1af2c59b0aae33cbac00d9f6fb47782ac57
msg286790 - (view) Author: Roundup Robot (python-dev) (Python triager) Date:
New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch '3.5':
Issue #29300: test_struct tests unpack_from() with keywords
https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784
msg286791 - (view) Author: Roundup Robot (python-dev) (Python triager) Date:
New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch '3.6':
Issue #29300: test_struct tests unpack_from() with keywords
https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784
msg286792 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-02-02 14:04
PyBUF_SIMPLE implies C-contiguous for a conforming buffer provider.
msg286795 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 14:15
Stefan Krah: "PyBUF_SIMPLE implies C-contiguous for a conforming buffer provider."

Oh ok, thanks for the confirmation. So my change didn't add new checks and my commit message is wrong :-) Only non-conforming objects are impacted, but in such case, it's more a bug in the object than a bug in struct. I guess that non-conforming non-contiguous objects are very rare in the wild ;-)

The new code is more strict, so is safe in all corner cases.
msg286799 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-02 14:52
Dear Roundup Robot, please don't close issues.
msg286800 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 14:54
Serhiy Storchaka: "Dear Roundup Robot, please don't close issues."

For what it's worth, I reported issues of this robot to python-dev:

https://mail.python.org/pipermail/python-dev/2017-February/147317.html

https://mail.python.org/pipermail/python-dev/2017-February/147325.html
msg286834 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-02 23:40
cache_struct-2.patch LGTM.
msg286934 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-02-04 09:15
New changeset 9245894af223 by Serhiy Storchaka in branch 'default':
Issue #29300: Use Argument Clinic for getting struct object from the format.
https://hg.python.org/cpython/rev/9245894af223
msg286943 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-02-04 10:00
New changeset e21cda70a3a13eb6e6238e436a5c0e2c4e4bebef by Serhiy Storchaka in branch 'master':
Issue #29300: Use Argument Clinic for getting struct object from the format.
https://github.com/python/cpython/commit/e21cda70a3a13eb6e6238e436a5c0e2c4e4bebef
msg287125 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-06 13:17
@Serhiy: Can we please now close this issue? Or is there still something to do?
msg287517 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-10 11:33
I'm not aware of any pending issues, buildbots are happy, I'm happy, I close the issue :-) Don't hesitate to reopen it if I missed something.
History
Date User Action Args
2022-04-11 14:58:42adminsetgithub: 73486
2017-02-10 11:33:37vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg287517

stage: patch review -> resolved
2017-02-06 13:17:47vstinnersetmessages: + msg287125
2017-02-04 10:00:31python-devsetmessages: + msg286943
2017-02-04 09:15:16python-devsetmessages: + msg286934
2017-02-02 23:40:18vstinnersetmessages: + msg286834
2017-02-02 14:54:19vstinnersetmessages: + msg286800
2017-02-02 14:52:30serhiy.storchakasetstatus: closed -> open
files: + cache_struct-2.patch
messages: + msg286799

resolution: fixed -> (no value)
stage: resolved -> patch review
2017-02-02 14:15:21vstinnersetmessages: + msg286795
2017-02-02 14:04:32skrahsetnosy: + skrah
messages: + msg286792
2017-02-02 14:00:31python-devsetmessages: + msg286791
2017-02-02 14:00:29python-devsetmessages: + msg286790
2017-02-02 14:00:26python-devsetstage: patch review -> resolved
2017-02-02 14:00:26python-devsetresolution: fixed
2017-02-02 14:00:26python-devsetstatus: open -> closed
2017-02-02 14:00:26python-devsetmessages: + msg286789
2017-02-02 13:36:03vstinnersetmessages: + msg286786
2017-02-02 13:34:51vstinnersetmessages: + msg286785
2017-02-02 13:25:50vstinnersetmessages: + msg286784
2017-02-02 13:24:52python-devsetmessages: + msg286783
2017-02-02 13:19:49python-devsetmessages: + msg286782
2017-02-02 13:15:48vstinnersetmessages: + msg286781
2017-02-02 12:49:16serhiy.storchakasetmessages: + msg286776
2017-02-02 12:43:13serhiy.storchakasetmessages: + msg286775
2017-02-02 12:37:24serhiy.storchakasetmessages: + msg286774
2017-02-02 12:25:09vstinnersetfiles: + unpack_buffer.patch
resolution: fixed -> (no value)
messages: + msg286773
2017-02-02 12:24:30martin.pantersetresolution: fixed
messages: + msg286772
2017-02-02 12:22:43serhiy.storchakasetstatus: closed -> open
files: + cache_struct.patch
messages: + msg286771

resolution: fixed -> (no value)
stage: resolved -> patch review
2017-02-02 12:16:38martin.pantersetnosy: + martin.panter
messages: + msg286770
2017-02-02 12:00:26python-devsetstage: resolved
2017-02-02 12:00:26python-devsetmessages: + msg286768
2017-02-02 11:37:15vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg286767
2017-02-02 11:32:01python-devsetnosy: + python-dev
messages: + msg286766
2017-02-02 10:57:05vstinnersetmessages: + msg286761
2017-02-02 10:02:55serhiy.storchakasetfiles: + struct_fastcall-7.patch

messages: + msg286756
2017-02-01 22:01:59vstinnersetmessages: + msg286712
2017-02-01 17:13:16serhiy.storchakasetmessages: + msg286659
2017-02-01 16:16:55vstinnersetmessages: + msg286645
2017-01-27 15:46:27vstinnersetfiles: + struct_fastcall-6.patch

messages: + msg286373
2017-01-27 15:22:21vstinnersetfiles: + struct_fastcall-5.patch

messages: + msg286367
2017-01-27 15:05:15serhiy.storchakasetmessages: + msg286364
2017-01-27 14:45:51vstinnersetmessages: + msg286358
2017-01-27 14:40:05vstinnersetfiles: + struct_fastcall-4.patch

messages: + msg286357
2017-01-27 10:42:23serhiy.storchakasetmessages: + msg286351
2017-01-27 10:40:47serhiy.storchakasetmessages: + msg286350
2017-01-27 10:16:46vstinnersetmessages: + msg286349
2017-01-27 09:49:13serhiy.storchakasetmessages: + msg286348
2017-01-27 08:53:57vstinnersetfiles: + struct_fastcall-3.patch

messages: + msg286346
2017-01-26 18:04:18serhiy.storchakasetmessages: + msg286329
2017-01-26 17:27:58vstinnersetmessages: + msg286327
2017-01-26 17:27:24vstinnersetfiles: + struct_fastcall-2.patch

messages: + msg286326
2017-01-17 17:07:07serhiy.storchakasetmessages: + msg285669
2017-01-17 16:31:45vstinnercreate