An error occurred fetching the project authors.
  1. 04 Dec, 2015 1 commit
  2. 02 Nov, 2015 1 commit
    • Kevin Modzelewski's avatar
      Rename CLFunction->FunctionMetadata · c8360f6d
      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.
      c8360f6d
  3. 18 Sep, 2015 1 commit
  4. 16 Sep, 2015 1 commit
    • Kevin Modzelewski's avatar
      Match cpython's HEAPTYPE flag · 3b40ed33
      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.
      3b40ed33
  5. 04 Sep, 2015 1 commit
    • Rudi Chen's avatar
      Pass address of pointer instead of pointer directly. · 3451880d
      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**.
      3451880d
  6. 30 Aug, 2015 1 commit
  7. 10 Aug, 2015 1 commit
  8. 06 Aug, 2015 2 commits
  9. 28 Jul, 2015 1 commit
    • Kevin Modzelewski's avatar
      Templatize getitemInternal · ed14dd77
      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).
      ed14dd77
  10. 03 Jul, 2015 1 commit
  11. 26 Jun, 2015 2 commits
  12. 10 Jun, 2015 1 commit
    • Kevin Modzelewski's avatar
      Change the way we store and pass string data · 95ad7ffc
      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.
      95ad7ffc
  13. 05 May, 2015 1 commit
  14. 26 Mar, 2015 1 commit
  15. 21 Mar, 2015 1 commit
  16. 06 Mar, 2015 1 commit
  17. 04 Mar, 2015 1 commit
  18. 03 Mar, 2015 1 commit
    • Kevin Modzelewski's avatar
      Rearrange some class creation and initialization functions · dad2675f
      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.
      dad2675f
  19. 13 Feb, 2015 3 commits
  20. 05 Feb, 2015 1 commit
  21. 21 Jan, 2015 1 commit
    • Kevin Modzelewski's avatar
      Change from throwing a Box* to an ExcInfo triple · 44b63a61
      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.
      44b63a61
  22. 11 Jan, 2015 2 commits
  23. 09 Jan, 2015 1 commit
    • Kevin Modzelewski's avatar
      Large refactor for basic tp_alloc support · 0c20808b
      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.
      0c20808b
  24. 05 Jan, 2015 1 commit
  25. 13 Dec, 2014 1 commit
    • Kevin Modzelewski's avatar
      Change our type creation to add the extra PyHeapTypeObject fields · 198d0f6b
      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.
      198d0f6b
  26. 15 Oct, 2014 1 commit
    • Kevin Modzelewski's avatar
      Separate the CompilerType objects from the class definitions · 204b1da6
      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
      204b1da6
  27. 27 Aug, 2014 1 commit
    • Kevin Modzelewski's avatar
      Basic metaclass support · 17cbc7ab
      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.
      17cbc7ab
  28. 22 Aug, 2014 1 commit
    • Kevin Modzelewski's avatar
      Implement the sequence iterator protocol · 4cf93f94
      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?
      4cf93f94