These are chat archives for dropbox/pyston

7th
Jun 2015
Travis Hance
@tjhance
Jun 07 2015 02:46
Check unit tests? I'm pretty sure I left some descriptor test cases that fail in some obscure cases
Also not a correctness issue but I'm pretty sure we still don't patchpoint rewrite a.f () when f is a descriptor
That's all I can think of
Travis Hance
@tjhance
Jun 07 2015 02:53
Descriptors_nonfunc_types fails
Bob Fang
@dorafmon
Jun 07 2015 15:57
hi just want to ask this: what does the code in folder src/capi do?
Marius Wachtler
@undingen
Jun 07 2015 18:02
AFAIK when we started to implement CPython CAPI to support extensions we put the code into the capi folder. But over the time a lot of the C API functions got also implemented outside of the capi folder. Like for example code which cpython has inside intobject.c got implemented inside runtime/int.cpp. So I don't thing there is a strict separation, but if something is implemented only for the capi it should probably go into the subfolder.
Kevin Modzelewski
@kmod
Jun 07 2015 18:39
the previous strategy was putting all the capi-related code into runtime/capi.cpp :P
but yeah now capi-related code can appear in many places, either from_cpython, src/capi, src/runtime/capi.cpp, or directly next to non-capi code
as we've gotten tighter integration with the c api (using it internally too), the distinction betwee c api and not-capi has gotten pretty blurred
but anyway, I think the current strategy is roughly: from_cpython is for things that have very little modifications
and things that will get left as C
Bob Fang
@dorafmon
Jun 07 2015 18:42
cool thanks
Kevin Modzelewski
@kmod
Jun 07 2015 18:43
src/capi mostly just corresponds to a couple CPython files that we didn't have equivalents of
it probably makes sense to move that all into runtime/
Marius Wachtler
@undingen
Jun 07 2015 18:55
damn I'm searching since about an hour for a strange crash. And now I found it: I created a Assembler object but gave it a too small buffer and didn't notice because it just sets internally a failed flag which I didn't check :-(
Bob Fang
@dorafmon
Jun 07 2015 20:27
in object.cpp line 944
extern "C" PyObject* PyObject_RichCompare(PyObject* v, PyObject* w, int op) noexcept {
    PyObject* res;

    assert(Py_LT <= op && op <= Py_GE);
    if (Py_EnterRecursiveCall(" in cmp"))
        return NULL;

    /* If the types are equal, and not old-style instances, try to
       get out cheap (don't bother with coercions etc.). */
    if (v->cls == w->cls && !PyInstance_Check(v)) {
        cmpfunc fcmp;
        richcmpfunc frich = RICHCOMPARE(v->cls);
whats the diefference fcmp and frich?
Marius Wachtler
@undingen
Jun 07 2015 20:41
tp_compare returns -1, 0 or 1 depending on which of the 2 objects is larger. (similar to memcmp). While the richcomp support different comparison types: eg. <, <=,.... It's best to read cpythons doc about it. (e.g. https://www.python.org/dev/peps/pep-0207/)
tp_compare is __cmp__ while richcmp is __eq__, __lt__ etc
Bob Fang
@dorafmon
Jun 07 2015 20:44
cool thanks :)
Bob Fang
@dorafmon
Jun 07 2015 21:16
when you are developing something, what do you use for logging? plain printf?
Travis Hance
@tjhance
Jun 07 2015 22:59
Usually plain print