1. 02 Mar, 2017 1 commit
  2. 28 Feb, 2017 1 commit
  3. 27 Feb, 2017 7 commits
  4. 25 Feb, 2017 1 commit
  5. 24 Feb, 2017 9 commits
    • Paul Sokolovsky's avatar
      extmod/modurandom: Use mp_raise_ValueError(). · 09828846
      Paul Sokolovsky authored
      For the standard unix x86_64 build, this saves 11 bytes on object file
      level, but no difference in executable size due to (bloaty) code alignment.
    • Paul Sokolovsky's avatar
      py/runtime: mp_raise_msg(): Accept NULL argument for message. · 4b3da603
      Paul Sokolovsky authored
      In this case, raise an exception without a message.
      This would allow to shove few code bytes comparing to currently used
      mp_raise_msg(..., "") pattern. (Actual savings depend on function code
      alignment used by a particular platform.)
    • Damien George's avatar
    • Damien George's avatar
    • Paul Sokolovsky's avatar
      cc3200/moduos: Remove uos.sep, as it's strictly optional. · f5ee4d95
      Paul Sokolovsky authored
      In MicroPython, the path separator is guaranteed to be "/", extra unneeded
      things take precious code space (in the port which doesn't have basic things
      like floating-port support).
    • Damien George's avatar
      py/parse: Simplify handling of errors by raising them directly. · f615d82d
      Damien George authored
      The parser was originally written to work without raising any exceptions
      and instead return an error value to the caller.  But it's now required
      that a call to the parser be wrapped in an nlr handler, so we may as well
      make use of that fact and simplify the parser so that it doesn't need to
      keep track of any memory errors that it had.  The parser anyway explicitly
      raises an exception at the end if there was an error.
      This patch simplifies the parser by letting the underlying memory
      allocation functions raise an exception if they fail to allocate any
      memory.  And if there is an error parsing the "<id> = const(<val>)" pattern
      then that also raises an exception right away instead of trying to recover
      gracefully and then raise.
    • Damien George's avatar
      py: Create str/bytes objects in the parser, not the compiler. · 5255255f
      Damien George authored
      Previous to this patch any non-interned str/bytes objects would create a
      special parse node that held a copy of the str/bytes data.  Then in the
      compiler this data would be turned into a str/bytes object.  This actually
      lead to 2 copies of the data, one in the parse node and one in the object.
      The parse node's copy of the data would be freed at the end of the compile
      stage but nevertheless it meant that the peak memory usage of the
      parse/compile stage was higher than it needed to be (by an amount equal to
      the number of bytes in all the non-interned str/bytes objects).
      This patch changes the behaviour so that str/bytes objects are created
      directly in the parser and the object stored in a const-object parse node
      (which already exists for bignum, float and complex const objects).  This
      reduces peak RAM usage of the parse/compile stage, simplifies the parser
      and compiler, and reduces code size by about 170 bytes on Thumb2 archs,
      and by about 300 bytes on Xtensa archs.
    • Damien George's avatar
    • Damien George's avatar
      py/parse: Allow parser/compiler consts to be bignums. · 74f4d2c6
      Damien George authored
      This patch allows uPy consts to be bignums, eg:
          X = const(1 << 100)
      The infrastructure for consts to be a bignum (rather than restricted to
      small integers) has been in place for a while, ever since constant folding
      was upgraded to allow bignums.  It just required a small change (in this
      patch) to enable it.
  6. 22 Feb, 2017 9 commits
  7. 21 Feb, 2017 9 commits
  8. 20 Feb, 2017 3 commits
    • Damien George's avatar
    • Rami Ali's avatar
    • Rami Ali's avatar
      tools: Add gen-cpydiff.py to generate docs differences. · b7fa63c7
      Rami Ali authored
      This patch introduces the a small framework to track differences between
      uPy and CPython.  The framework consists of:
      - A set of "tests" which test for an individual feature that differs between
        uPy and CPy.  Each test is like a normal uPy test in the test suite, but
        has a special comment at the start with some meta-data: a category (eg
        syntax, core language), a human-readable description of the difference, a
        cause, and a workaround.  Following the meta-data there is a short code
        snippet which demonstrates the difference.  See tests/cpydiff directory
        for the initial set of tests.
      - A program (this patch) which runs all the tests (on uPy and CPy) and
        generates nicely-formated .rst documenting the differences.
      - Integration into the docs build so that everything is automatic, and the
        differences appear in a way that is easy for users to read/reference (see
        latter commits).
      The idea with using this new framework is:
      - When a new difference is found it's easy to write a short test for it,
        along with a description, and add it to the existing ones.  It's also easy
        for contributors to submit tests for differences they find.
      - When something is no longer different the tool will give an error and
        difference can be removed (or promoted to a proper feature test).