An error occurred fetching the project authors.
- 04 Dec, 2015 1 commit
-
-
Marius Wachtler authored
because when calling a function with return type BOOL we currently expect it to return a i64. This got triggered by the inliner
-
- 02 Nov, 2015 1 commit
-
-
Kevin Modzelewski authored
and a couple of the other related functions: - addRTFunction is now an overload of FunctionMetadata::addVersion - boxFunctionMetadata is now createFunctionFromMetadata (it doesn't return a box) - createRTFunction was just a wrapper around new FunctionMetadata(), so get rid of it - boxRTFunction is now FunctionMetadata::create "CLFunction" never really made sense as a name, and some of the other related functions didn't make sense either (especially after a couple refactorings happened). Hopefully this makes it less confusing.
-
- 18 Sep, 2015 1 commit
-
-
Marius Wachtler authored
-
- 16 Sep, 2015 1 commit
-
-
Kevin Modzelewski authored
It's supposed to mean "whether this type is heap allocated", but it gets used as "is this a builtin/extension type". We heap-allocate our builtin types so we were setting HEAPTYPE, but this keeps on causing issues. I don't think anything actually uses HEAPTYPE to mean it's on the stack or heap, so let's just set them all to be HEAPTYPE=0. For better or worse, I ended up implementing this by changing the builtin types from BoxedHeapClasses to BoxedClasses, which seems to make sense. This had the effect of changing the existence of the tp_as_foo structs, which get automatically created for HeapClasses but not for non-heap classes. So most of the changes in this commit are trying to make sure that we have those when CPython has them.
-
- 04 Sep, 2015 1 commit
-
-
Rudi Chen authored
Moving gcs will need this to update pointers. There should not be any extra dereference, it will just happen on the other side of the function. Use templates to avoid direct (void**) casts -- make sure we're always passing an pointer of the form T**.
-
- 30 Aug, 2015 1 commit
-
-
Rudi Chen authored
-
- 10 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 06 Aug, 2015 2 commits
-
-
Rudi Chen authored
-
Rudi Chen authored
This serves two purposes. 1) Improve naming consistency (follow the format TYPENAME::gcHandler) 2) In the source file, the visit function declaration is closer to the fields of the objects. If a field is added, hopefully it will be easier to remember to update the GC visit function.
-
- 28 Jul, 2015 1 commit
-
-
Kevin Modzelewski authored
For use of PyObject_GetItem django_template3 ends up calling this a fair amount via unicode_translate (ie it checks to see if certain entries are in the translation table).
-
- 03 Jul, 2015 1 commit
-
-
Travis Hance authored
-
- 26 Jun, 2015 2 commits
-
-
Kevin Modzelewski authored
ie try to avoid api conversion.
-
Marius Wachtler authored
in order to save one register. This makes it possible to pass up to 3 args to a runtimc IC callattr (Runtime ICs currently don't support passing args on the stack)
-
- 10 Jun, 2015 1 commit
-
-
Kevin Modzelewski authored
Convert to BoxedString much sooner, and have any functions that might need to box a string take a BoxedString. This means that on some paths, we will need to box when previously we didn't, but for callsites that we control we can just intern the string and not have to box again. The much more common case is that we passed in unboxed string data, but then ran into a branch that required boxing. BoxedString shouldn't be that much more costly than std::string, and this should cut down on string allocations. For django-template.py, the number of strings allocated drops from 800k to 525k; for virtualenv_test.py, it goes from 1.25M to 1.0M A couple things made this not 100% mechanical: - taking advantage of places that we could eliminate unbox/rebox pairs - different null-termination assumptions between StringRef and the c api.
-
- 05 May, 2015 1 commit
-
-
Marius Wachtler authored
-
- 26 Mar, 2015 1 commit
-
-
Marius Wachtler authored
-
- 21 Mar, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 06 Mar, 2015 1 commit
-
-
Kevin Modzelewski authored
Also add instance.__contains__
-
- 04 Mar, 2015 1 commit
-
-
Chris Toshok authored
-
- 03 Mar, 2015 1 commit
-
-
Kevin Modzelewski authored
Our class-creation code is getting pretty unruly, since there are four places we can create new classes: 1) extension classes 2) Python-defined classes 3) builtin-defined classes 4) classes created during bootstrapping Then, there are multiple different sets of initialization functions that can be called, each of which initializes different sets of the class attributes. It's not easy to tell what a given initialization function should actually initialize. This change just cleans this up slightly: it renames PystonType_Ready to commonClassSetup to hopefully be more clear about its goal, as well as adds a BoxedClass::finishInitialization() function. It also moves some work out of the BoxedClass() constructor, since this causes issues because it happens before the BoxedHeapClass() constructor runs, which sets certain class slots that affect other parts of class initialization. Things are still pretty complicated but this should help with the multiple inheritance changes that are coming.
-
- 13 Feb, 2015 3 commits
-
-
Kevin Modzelewski authored
-
Marius Wachtler authored
-
Chris Toshok authored
-
- 05 Feb, 2015 1 commit
-
-
Travis Hance authored
-
- 21 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
ExcInfo is a triple of exc_type, exc_value, exc_traceback - analogous to Python's sys.exc_info(). Previously, we were just throwing exc_value. I still don't understand all the rules for when type(exc_value) is not necessarily exc_type. But this also makes it easier to pass exc_traceback around, and should make it possible to make our handling more consistent. This commit just changes the runtime; the generated code currently still expects a Box* to be thrown and will crash.
-
- 11 Jan, 2015 2 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
At runtime, we can detect if something supports the new Pyston iteration protocol (__hasnext__) or not. Statically, when we lower a for loop, we assume that the iterator supports the new protocol, and we can't check it This commit adds a check to getiter() which wraps a Python-style iterator with an IterWrapper which adds the __hasnext__ method.
-
- 09 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
Use operator new() to get access to tp_alloc in a C++-ish way. Instead of passing the object's class to the constructor, pass it to new(). We need to do this since the class gets to pick how the object gets allocated, including how large it will end up being. Unfortunately it looks like defining an operator new on a subclass hides the operator new from a superclass, even if they have different signatures. Macros to the rescue.
-
- 05 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
(update copyright notices)
-
- 13 Dec, 2014 1 commit
-
-
Kevin Modzelewski authored
This is so that we can add the CAPI slots for things like tp_as_sequence, so that C extensions will work properly. I don't think there are very many extensions that would do this but let's still support it for now; it further bloats the type objects but only as much as it does in CPython as well.
-
- 15 Oct, 2014 1 commit
-
-
Kevin Modzelewski authored
Most code wants to have access to the basic types (INT, STR, etc) but doesn't need to know anything about what methods they support. Move the commonly-accessed parts of compvars.h into the always-included core/types.h, and remove almost all of the includes of compvars.h
-
- 27 Aug, 2014 1 commit
-
-
Kevin Modzelewski authored
We actually had most of the base support in place; this commit just adds the ability to specify a metaclass other than type_cls, and the ability to determine which metaclass to use when defining a new class. But just like how we have the base functionality to inherit from all the builtin types but haven't updated all the functions yet, I bet there are more places that assume the type of a class is always type_cls.
-
- 22 Aug, 2014 1 commit
-
-
Kevin Modzelewski authored
ie if you just have a __getitem__ method, you are still iterable. This patch is unfortunately yet another performance regression, since we obscure the behavior for known types (ie no longer try to go directly to the __iter__). Should make this into a call into type-specific behavior, so that known types can use __iter__ if they have one?
-