These are chat archives for dropbox/pyston

8th
Jun 2016
Sun
@Daetalus
Jun 08 2016 06:31
Hi @kmod what do you think of copy CPython's slot_tp_call to Pyston? https://github.com/python/cpython/blob/2.7/Objects/typeobject.c#L5509.
Or call something like return runtimeCall<CAPI, NOT_REWRITABLE>(self, ArgPassSpec(0, 0, true, true), args, kwds, NULL, NULL, NULL); In pyston slot_tp_call? Cython trigger that functions lots of times.
Kevin Modzelewski
@kmod
Jun 08 2016 06:34
Sorry, I'm not sure exactly what you're suggesting
it looks like our version is already copied from CPython's
is it being slow?
Kevin Modzelewski
@kmod
Jun 08 2016 06:36
Oh, sorry
I misread and thought you had linked to our version at first :)
Sun
@Daetalus
Jun 08 2016 06:36
:smile:
Kevin Modzelewski
@kmod
Jun 08 2016 06:37
yeah we should either switch to their implementation or at the very least switch it to a CAPI-style runtimeCall
it looks like this function dates to before we could call functions with either exception style
I think copying is probably a better approach here
Sun
@Daetalus
Jun 08 2016 06:38
ok. got it.
Just FYI, I collecting the Cython problems with current Pyston codebase. I trying to use the Cython codes under CPython directive as much as possible, Cython have directives CYTHON_COMPILING_IN_CPYTHON and CYTHON_COMPILING_IN_PYPY. I also add CYTHON_COMPLING_IN_PYSTON.
Kevin Modzelewski
@kmod
Jun 08 2016 06:42
oh ok cool
I'm not a huge fan of adding "if pyston" checks to a bunch of upstream projects
it feels like we're just furthering a bad part of the ecosystem if we do that :(
I wonder if we could do something like CYTHON_COMPILING_WITH_EXTENDED_API?
Sun
@Daetalus
Jun 08 2016 06:44
I see it from an issue that you proposed.
Kevin Modzelewski
@kmod
Jun 08 2016 06:44
though maybe that would be the same thing but with a different name
Sun
@Daetalus
Jun 08 2016 06:45
Maybe that need a meeting to discuss with some extension authors?
Kevin Modzelewski
@kmod
Jun 08 2016 06:46
I guess my thinking was that as long as all the new API functions are implementable in terms of the original API, it wouldn't be that controversial
I guess "extended api" is a bad name since it implies adding new functionality
Sun
@Daetalus
Jun 08 2016 06:47
Luckly, Pyston could use most Cython code either under CPython or under PyPy directive.
Kevin Modzelewski
@kmod
Jun 08 2016 06:47
but instead this is just moving more of the functionality behind an actual API
maybe another idea is to use more specific flags than IS_PYSTON. like maybe if there are a few different changes we have to make, we put each of them behind a different ifdef
Sun
@Daetalus
Jun 08 2016 06:49
I will file issues for the problems in Cython with Pyston. Let's see how many are they.
Kevin Modzelewski
@kmod
Jun 08 2016 06:49
anyway, that's my vision for how we could play nicely. but adding an IS_PYSTON check is definitely the past of least resistance. and that kind of thing already happens all over the place (for the other implementations) so maybe it would not hurt the status quo anyway :)
Sun
@Daetalus
Jun 08 2016 06:52
I think your thought is focus on long term, and it is reasonable for me.
An Long
@aisk
Jun 08 2016 15:17
Hi do we need any plan to upgrade cpython deps to 2.7.11?
I tried to build pyston on more platforms but seems have a lot of works to do if we still uses cpython 2.7.9(?)
Kevin Modzelewski
@kmod
Jun 08 2016 18:21
I think migrating to 2.7.11 is a great idea :)
It hasn't been a burning priority for us, so we've only been dealing with things as they come up, but doing a more systematic merge-with-upstream would be great
I'm not sure when marius/I will have time for it, but if you are interested it would be very very helpful
Kevin Modzelewski
@kmod
Jun 08 2016 18:30
most of our stuff is copied from 2.7.7, which is a few years old now