An error occurred fetching the project authors.
- 11 Feb, 2016 1 commit
-
-
Kevin Modzelewski authored
-
- 04 Feb, 2016 1 commit
-
-
Kevin Modzelewski authored
-
- 18 Nov, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 06 Nov, 2015 2 commits
-
-
Boxiang Sun authored
-
Kevin Modzelewski authored
joinRuntime+teardownRuntime->Py_Finalize remove the individual teardownFoo(), which had all become empty anyway.
-
- 02 Nov, 2015 2 commits
-
-
Kevin Modzelewski authored
-
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.
-
- 04 Oct, 2015 1 commit
-
-
Marius Wachtler authored
when we know that the rewrite_args are NULL origin/rewritable~: origin/rewritable: django_template3.py 2.7s (4) 2.7s (4) -1.3% pyxl_bench.py 2.2s (4) 2.2s (4) -1.7% sqlalchemy_imperative2.py 2.7s (4) 2.6s (4) -2.4% geomean 2.5s 2.5s -1.8%
-
- 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.
-
- 09 Sep, 2015 1 commit
-
-
Kevin Modzelewski authored
We already supported changing the values, but not the number of them. The main trickiness here is - We had been assuming that the number of defaults was immutable, so I had to find the places that we used it and add invalidation. - We assumed that all functions based on the same source function would have the same number of defaults. For the first one, I found all the places that looked at the defaults array, which should hopefully be all the places that need invalidation. One tricky part is that we will embed the num_defaults data into code produced by the LLVM tier, and we currently don't have any mechanism for invalidating those functions. This commit side-steps around that since the only functions that we can inline are the builtins, and those you aren't allowed to change the defaults anyway. So I added a "can_change_defaults" flag. For the second part, I moved "num_defaults" from the CLFunction (our "code" object) to the BoxedFunction (our "function" object), and then changed the users to pull it from there.
-
- 29 Aug, 2015 1 commit
-
-
Boxiang Sun authored
-
- 12 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
ie everything that the linter was warning about
-
- 11 Aug, 2015 1 commit
-
-
Rudi Chen authored
-
- 04 Aug, 2015 1 commit
-
-
Boxiang Sun authored
-
- 03 Aug, 2015 1 commit
-
-
Boxiang Sun authored
-
- 24 May, 2015 1 commit
-
-
Marius Wachtler authored
(was throwing a c++ exception)
-
- 16 Apr, 2015 1 commit
-
-
Marius Wachtler authored
-
- 05 Feb, 2015 1 commit
-
-
Travis Hance authored
-
- 09 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
Add a PYSTON_NOEXCEPT define that gets defined to "noexcept" in C++ mode, and to the empty string in C mode. I don't think 'extern "C"' implies noexcept. This is partly for better performance when we know that a function cannot throw an exception, but also as an annotation for us since the exception model is the main difference between C land and Pyston land. Vim substitution: %s/\(\<PyAPI_FUNC\>(.*).*(\([^)]\|\n\)*)\);/\1 PYSTON_NOEXCEPT;/gc - This will catch almost all cases, except for functions not marked with PyAPI_FUNC and function definitions that have extra paretheses (in comments, usually)
-
- 05 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
(update copyright notices)
-
- 18 Dec, 2014 2 commits
-
-
Kevin Modzelewski authored
Starting to really hit critical mass in terms of having enough API support that it's easier to copy additional API functions over.
-
Kevin Modzelewski authored
Required a small amount of object changes, and then a large number of replacements where we directly compared the class to int_cls. We now check that it's a subclass, since you are allowed to use True/False anywhere that you could use an int. ex "xrange(0, n, step=True)"
-
- 14 Dec, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 29 Oct, 2014 1 commit
-
-
Travis Hance authored
-
- 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
-
- 08 Sep, 2014 1 commit
-
-
Kevin Modzelewski authored
reduce(), some float precision issues, string interpolation improvements
-
- 27 Aug, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 23 Aug, 2014 1 commit
-
-
Travis Hance authored
-
- 22 Aug, 2014 1 commit
-
-
Travis Hance authored
-