Skip to content

Conversation

rudi-c
Copy link
Contributor

@rudi-c rudi-c commented Jul 29, 2015

Depends on #767

These are just a few small changes that help run NumPy which should be useful independently of the rest of the NumPy work.

@rudi-c rudi-c force-pushed the numpy_fix branch 6 times, most recently from 5c536e9 to 5bf904b Compare August 3, 2015 17:22
@rudi-c
Copy link
Contributor Author

rudi-c commented Aug 3, 2015

@kmod This got rebased on the ctypes changes and should be ready for review now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm this is a bit odd to me -- why do we have to do this when cpython doesn't?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is in PyType_Ready, typeobject.cpp:4123

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok, right (not sure why I didn't see that).

@kmod
Copy link
Collaborator

kmod commented Aug 5, 2015

Sorry, we really should get around to adding an exception-style linter :/

btw, how hard would it be to get it to the point that we can actually enable the numpy test?

@rudi-c
Copy link
Contributor Author

rudi-c commented Aug 5, 2015

There's almost nothing to do besides adding a line to the script that applies a patch to NumPy.

@rudi-c
Copy link
Contributor Author

rudi-c commented Aug 5, 2015

That being said the NumPy test currently only tests if NumPy crashes, not if it produces the same output.

@rudi-c rudi-c force-pushed the numpy_fix branch 2 times, most recently from f52dd00 to f3636f2 Compare August 7, 2015 18:21
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there actually anything to do here? I think we should avoid putting this in if it will silently handle ellipses the wrong way, but it looks like this might actually be all we need and we can remove the TODO? Same for the serializer.

@kmod
Copy link
Collaborator

kmod commented Aug 7, 2015

Ok I merged the testsuite change, could you update this PR to include the new submodule commit?

@rudi-c rudi-c force-pushed the numpy_fix branch 2 times, most recently from 417a31d to a52252e Compare August 7, 2015 22:45
@kmod kmod added the wip label Aug 10, 2015
rudi-c added 6 commits August 11, 2015 10:32
NumPy is huge, bigger than our previous (arbitrary) number by an order
of magnitude.
C extensions (NumPy) might inherit classes in C code and expect to find
tp_number. This is just copied from CPython's PyType_Ready.

This requires assigning some of the runtime functions to thesq_ and mp_ slots
otherwise there are infinite loops from Pyston attributes.
Those should never exist because all Python objects should be created
through the CPython API except for type objects. Unfortunately, some
places like NumPy do that so we need a mean of patching it for now.
@rudi-c
Copy link
Contributor Author

rudi-c commented Aug 11, 2015

Cool this is passing again.

kmod added a commit that referenced this pull request Aug 12, 2015
Some work on the NumPy test
@kmod kmod merged commit 109df64 into pyston:master Aug 12, 2015
@kmod
Copy link
Collaborator

kmod commented Aug 12, 2015

awesome!

@kmod kmod removed the wip label Aug 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants