I understand that the tests are in the test directory, but the issue I'm currently trying to figure out is that when I invoke either of: /usr/bin/python test_all.py test_all.py module/micronumpy/test/test_flagsobj.py /usr/bin/python pytest.py pypy/module/micronumpy/test/test_flagsobj.py (a directory level up) With any of system cpython, venv cpython, venv pypy, etc. then the changes that I've made locally to micronumpy aren't used, since inside of the tests "import numpy" grabs the numpy from whatever interpreter the tests were invoked with. I'm sure there's something simple that I'm missing about the environment that's needed to make this work, but I haven't figured it out yet. Do I need to be doing something with the PYTHONPATH prior to running the tests? Cheers, Eli On Fri, May 20, 2016 at 11:43 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
the option is --withmod-micronumpy or --allworkingmodules
but the tests are in the test directory and *that's* how you should run tests (not by playing with interactive)
On Fri, May 20, 2016 at 7:44 PM, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:
More questions! :)
When I run
pypy> /usr/bin/python bin/pyinteractive.py
I get to a (presumably interpreted, given the startup time) pypy prompt, but I cannot import numpy. Is the intent that I somehow install numpy into the source checkout's site-packages directory (the one listed in sys.path from that interpreted pypy prompt)?
Also, it's pretty clear that when running the tests that "import numpy" just gets the numpy from the base interpreter, not from the micronumpy included in the pypy source. Is it possible to run the numpy tests without doing a full translation?
Thanks, Eli
On Thu, May 19, 2016 at 1:36 PM, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:
Looks like I need to do something along the lines of:
def descr_set_writeable(self, space, w_value): if space.is_true(w_value) != bool(self.flags & NPY.ARRAY_WRITEABLE): self.flags ^= NPY.ARRAY_WRITEABLE
(Though I probably need more robust checking to see if the flag *can* be turned off)
def descr_setitem(self, space, w_item, w_value): # This function already exists, but just contains the last line with the raise key = space.str_w(w_item) value = space.bool_w(w_value) if key == "W" or key == "WRITEABLE": return self.descr_set_writeable(space, value) raise oefmt(space.w_KeyError, "Unknown flag")
... writeable = GetSetProperty(W_FlagsObject.descr_get_writeable, W_FlagsObject.descr_set_writeable),
However I'm not entirely confident about things like space.bool_w, etc. I've read http://doc.pypy.org/en/latest/objspace.html but am still working on internalizing it.
Setting the GetSetProperty still results in the TypeError, which makes me wonder how to tell if I'm getting the right flagsobj.py. I don't think that I am. The results of the tests should be the same no matter what python interpreter I'm using, correct? Would running the tests with a virtualenv that has a stock pypy/numpy installed cause issues? What if the virtualenv is cpython?
When I run py.test, I see:
pytest-2.5.2 from /Users/elis/edit/play/pypy/pytest.pyc
Which looks correct (.../play/pypy is my source checkout). But I get the same thing when using cpython to run test_all.py, and there the test passes, so I don't think it's indicative. When I print out np.__file__ inside the test, I get
/Users/elis/venv/droidblue-pypy/site-packages/numpy/__init__.pyc
Which is the pypy venv I am using to run the tests in the first place, but I'm not sure what the on-disk relationship between numpy and micronumpy actually is. Is there a way from the test_flagobjs.py file to determine what the on-disk location of micronumpy is?
I strongly suspect I've got something basic wrong. I also think that the information at http://doc.pypy.org/en/latest/getting-started-dev.html#running-pypy-s-unit-t... and http://doc.pypy.org/en/latest/coding-guide.html#command-line-tool-test-all conflict somewhat, or are at least unclear as to which approach is the right way in what situation. I'll attempt to clarify whatever it is that's tripping me up once I've got it sorted out.
Some other questions I have, looking at micornumpy/concrete.py line 37:
class BaseConcreteArray(object): _immutable_fields_ = ['dtype?', 'storage', 'start', 'size', 'shape[*]', 'strides[*]', 'backstrides[*]', 'order', 'gcstruct', 'flags'] start = 0 parent = None flags = 0
Does that immutable status cascade down into the objects, or is that saying only that myInstance.flags cannot be reassigned (but myInstance.flags.foo = 3 is fine)?
interpreter/typedef.py 221:
@specialize.arg(0) def make_objclass_getter(tag, func, cls): if func and hasattr(func, 'im_func'): assert not cls or cls is func.im_class cls = func.im_class return _make_objclass_getter(cls)
What's the purpose of the tag argument? It doesn't seem to be used here or in _make_descr_typecheck_wrapper, both of which are called from GetSetProperty init. Based on docstrings on _Specialize, it seems like they might be JIT hints. Is that correct?
Matti: If it's okay, I'd like to keep the discussion on the list, as I've actively searched through discussions here to avoid asking questions a second time. Hopefully this thread can help the next person.
Sorry for the mega-post; thanks for reading. Eli
On Thu, May 19, 2016 at 8:23 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Eli,
On 19 May 2016 at 08:58, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:
I've got a pypy clone and checkout, and have added TestFlags. When I run it, I see:
a.flags.writeable = False
E TypeError: readonly attribute
But nothing that looks like it should raise a TypeError in either of:
Grep for 'writable'. You'll see that it is defined as a GetSetProperty() with a getter but no setter so far.
A bientôt,
Armin.
pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev