These are chat archives for dropbox/pyston

May 2016
Kevin Modzelewski
May 09 2016 00:20
Hi @McWeda, would it work to change our code from #include <cmath> to #include <math.h>?
If we can' it's good to not change the headers in from_cpython/Include
since those are the ones that C extensions build against as well
so there may be C++ extensions out there that have isinf but not std::isinf, which work with the CPython headers but wouldn't work with ours
May 09 2016 00:23
I think that's best and I guess it would work. I'm not in a position to test that right now.
Dong-hee Na
May 09 2016 04:32
Can I get review about #1164 ??
Kevin Modzelewski
May 09 2016 20:41
Hey @undingen how are you testing numpy? is it through
May 09 2016 21:08
With this fix: dropbox/pyston@f6760ac
And build Pyston normally. Then use ./pyston_release test/integration/
I think that will be enough.
Kevin Modzelewski
May 09 2016 21:40
I'm getting some errors about PyGC_AddNonHeapRoot... do you guys have some changes to the numpy patch? (that function is gone on the refcounting branch)
maybe I will just let you two keep working on it :)
May 09 2016 21:42
Clear the test/lib/numpy, then git submodule update, apply the patch in this PR dropbox/pyston#1157
Yeah, I will keep working on it. Just the random module was annoying...
Marius Wachtler
May 09 2016 21:59
I was testing it using my wip: dropbox/pyston#1157 patch and running ./pyston_release test/integration/
and than going inside the virtualenv and activiating it and than executing import numpy as np; np.test(verbose=2)
I once run into a problem where numpy failed to run but deleting the numpy directory and git submodule update fixed the issue AFAIK
Marius Wachtler
May 09 2016 22:05
I will make sure to get the integration tests fixes in tomorrow. got today a little bit site tracked with perf investigations...
Marius Wachtler
May 09 2016 23:45
with the sys.getsizeof() we are now down to:
Ran 5469 tests in 24.138s

FAILED (KNOWNFAIL=3, SKIP=10, errors=28, failures=11)
I think about half of the remaining issues are related to refcounting in the sense that the test is checking for a specific refcount and we have more references
Traceback (most recent call last):
  File "/home/malloc/pyston/numpy_test_env_pyston_release/site-packages/numpy/core/tests/", line 1748, in test_object_array_self_copy
    assert_equal(sys.getrefcount(a[()]), 2)
  File "/home/malloc/pyston/numpy_test_env_pyston_release/site-packages/numpy/testing/", line 354, in assert_equal
    raise AssertionError(msg)
Items are not equal:
    x.resize((5, 5))
ValueError: cannot resize an array that references or is referenced
by another array in this way.  Use the resize function
Kevin Modzelewski
May 09 2016 23:48
oh interesting
so maybe it is important that we don't have the extra refs
so that the mutate-if-only-1-ref code still works
Sun mentioned that for us sys.getrefcount(object()) gives 2
It looks like 1 is in the interpreter, one is from rearrangeArguments
Marius Wachtler
May 09 2016 23:52
oh, yeah I forgot that rearrangeArguments increfs currently too
Kevin Modzelewski
May 09 2016 23:52
we could change it to only incref *args and **kwargs
which probably makes more sense anyway
but there are some subtleties about what if we load a default
and don't incref it
but then calling the function changes the function's defaults
Marius Wachtler
May 09 2016 23:54
:-( you mean like in the case the default only has 1 ref and we do one of this 1 ref mutation optimizations?
Kevin Modzelewski
May 09 2016 23:58
oh I meant something like
def f(x=[]):
  print x
  f.func_defaults = ()
  print x
so 'x' may need to be an owned reference coming into this function
I think CPython is safe (or somewhat safe) because any functions that can take defaults will take their arguments via an args tuple, which will hold an extra reference to the object