An error occurred fetching the project authors.
- 27 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
Not completely correct/working yet, but finally start doing classes the right way.
-
- 26 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 24 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 19 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
Implementation is pretty straightforward for now: - find all names that get accessed from a nested function - if any, create a closure object at function entry - any time we set a name accessed from a nested function, update its value in the closure - when evaluating a functiondef that needs a closure, attach the created closure to the created function object. Closures are currently passed as an extra argument before any python-level args, which I'm not convinced is the right strategy. It's works out fine but it feels messy to say that functions can have different C-level calling conventions. It felt worse to include the closure as part of the python-level arg passing. Maybe it should be passed after all the other arguments? Closures are currently just simple objects, on which we set and get Python-level attributes. The performance (which I haven't tested) relies on attribute access being made fast through the hidden-class inline caches. There are a number of ways that this could be improved: - be smarter about when we create the closure object, or when we update it. - not create empty pass-through closures - give the closures a pre-defined shape, since we know at irgen-time what names can get set. could probably avoid the inline cache machinery and also have better code.
-
- 17 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
Add some basic locking to: - code generation (one lock for all of it) - garbage collection (spin lock for allocations, global serialization for collections) - lists (mutex per list object) Can run the GRWL on some simple tests (microbenchmarks/thread_contention.py and thread_uncontended.py) Performance is not great yet
-
- 09 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
Well, the thread-creating should work, but nothing is threadsafe.
-
- 07 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
Not all exposed to python code yet This commit is pretty large because it contains two separate but interrelated changes: - Rewrite the function argument handling code (callCompiledFunction and resolveCLFunc) into a single callFunc that does its own rewriting, and support the new features. -- this required a change of data representations, so instead of having each function consist of variants with unrelated signatures, we can only have a single signature, but multiple type specializations of that signature - To do that, had to rewrite all of the stdlib functions that used signature-variation (ex range1 + range2 + range3) to be a single function that took default arguments, and then took action appropriately.
-
- 04 Jun, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 03 Jun, 2014 2 commits
-
-
Kevin Modzelewski authored
-
Krzysztof Klinikowski authored
-
- 01 Jun, 2014 1 commit
-
-
Marius Wachtler authored
-
- 31 May, 2014 3 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
If you throw an unhandled exception, you'll see a traceback from the top-level handler. Doesn't enable us to run any additional programs, since this functionality isn't available to Python-level code, but hopefully should make debugging easier.
-
- 30 May, 2014 2 commits
-
-
Kevin Modzelewski authored
Python inheritance is remarkably complicated... this commit implements the basics. There are still a fair number of things that are unimplemented, and some things like inheriting from all the basic types haven't been added yet.
-
Kevin Modzelewski authored
Similar to the location of the dict attribute in CPython, the 'hc attrs list' in Pyston will end up being located at different offsets, depending on the class that's being subclassed from. This commit removes the HCBox class, which assumes that it always lives at the same offset and so can be statically described with a C++ class, and instead uses a runtime lookup. This should hopefully make things a fair bit closer to supporting inheritance.
-
- 21 May, 2014 2 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
- 20 May, 2014 3 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Will add them back later
-
xiafan_linux authored
add the python test file for del statement fix the ic enable macro of delitem make the implementation of del statement exception-aware
-
- 17 May, 2014 2 commits
-
-
Kevin Modzelewski authored
There's still vestiges of the libunwind experiment; I'm leaving those in even though they're dead since I think we should move soon back to that approach.
-
Kevin Modzelewski authored
-
- 13 May, 2014 1 commit
-
-
Kevin Modzelewski authored
Changed the indentation of pretty much the entire codebase. It did some things that I don't like that seem not configurable, but overall it seems like an improvement, and nice to have a canonical format going forward.
-
- 09 May, 2014 1 commit
-
-
Leandro Lameiro authored
As I touched the module repr, I added some tests to it. Turned out that cpython normalizes the path of a module and uses the pyc file in the repr string. That part is ignored in this test.
-
- 30 Apr, 2014 1 commit
-
-
Marius Wachtler authored
-
- 25 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 24 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
Doesn't handle packages or anything other than importing a .py file (ex zip import, .so, .pyc), but has some basic support for sys.path and sys.modules.
-
- 23 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
Turn on some more warnings, though the ones that don't have many false positives aren't very helpful
-
- 21 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
-
- 16 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
Found some bugs in the name analyzer around listcomps; got the unittests back up and running so I can write some more
-
- 03 Apr, 2014 1 commit
-
-
Kevin Modzelewski authored
-