CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.5.2 2015-12-18T12:35:44+00:00 2015-12-18T12:35:44+00:00 Damien George damien.p.george@gmail.com 2015-12-18T12:35:44+00:00 urn:sha1:dd5353a4054024a411aa343a22ffcd16195a16ad MICROPY_ENABLE_COMPILER can be used to enable/disable the entire compiler, which is useful when only loading of pre-compiled bytecode is supported. It is enabled by default. MICROPY_PY_BUILTINS_EVAL_EXEC controls support of eval and exec builtin functions. By default they are only included if MICROPY_ENABLE_COMPILER is enabled. Disabling both options saves about 40k of code size on 32-bit x86. 2015-08-17T11:51:26+00:00 Damien George damien.p.george@gmail.com 2015-08-14T11:24:11+00:00 urn:sha1:65dc960e3b22a8426e369607e47c19b380ce30ea unix-cpy was originally written to get semantic equivalent with CPython without writing functional tests. When writing the initial implementation of uPy it was a long way between lexer and functional tests, so the half-way test was to make sure that the bytecode was correct. The idea was that if the uPy bytecode matched CPython 1-1 then uPy would be proper Python if the bytecodes acted correctly. And having matching bytecode meant that it was less likely to miss some deep subtlety in the Python semantics that would require an architectural change later on. But that is all history and it no longer makes sense to retain the ability to output CPython bytecode, because: 1. It outputs CPython 3.3 compatible bytecode. CPython's bytecode changes from version to version, and seems to have changed quite a bit in 3.5. There's no point in changing the bytecode output to match CPython anymore. 2. uPy and CPy do different optimisations to the bytecode which makes it harder to match. 3. The bytecode tests are not run. They were never part of Travis and are not run locally anymore. 4. The EMIT_CPYTHON option needs a lot of extra source code which adds heaps of noise, especially in compile.c. 5. Now that there is an extensive test suite (which tests functionality) there is no need to match the bytecode. Some very subtle behaviour is tested with the test suite and passing these tests is a much better way to stay Python-language compliant, rather than trying to match CPy bytecode. 2015-01-01T20:32:09+00:00 Damien George damien.p.george@gmail.com 2015-01-01T20:27:54+00:00 urn:sha1:51dfcb4bb7613ed164952712d9a5235a7b833cde Addresses issue #1022. 2014-12-21T17:26:45+00:00 Damien George damien.p.george@gmail.com 2014-12-21T17:26:45+00:00 urn:sha1:584ba6762f5f41b3ebaabc060d0db18b7954103f This patch gives proper SyntaxError exceptions for bad global/nonlocal declarations. It also reduces code size: 304 bytes on unix x64, 132 bytes on stmhal. 2014-09-08T22:05:16+00:00 Damien George damien.p.george@gmail.com 2014-09-08T22:05:16+00:00 urn:sha1:7ff996c2377b191ff829e6e03815acf9bfe85a14 Towards resolving issue #50. 2014-08-30T13:59:21+00:00 Damien George damien.p.george@gmail.com 2014-08-30T13:59:21+00:00 urn:sha1:4abff7500fb05430a2ce952a2430d4d0ba16047e Part of code cleanup, working towards resolving issue #50. 2014-08-15T13:30:52+00:00 Damien George damien.p.george@gmail.com 2014-08-15T13:30:52+00:00 urn:sha1:6be0b0a8ec9a6badc601190ccee876755ce7efb7 Some small code clean-ups that result in about 80 bytes ROM saving for stmhal. 2014-06-21T19:43:22+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-06-21T19:43:22+00:00 urn:sha1:59c675a64c1d9757d50ad4627da67a6f996a99fb It defines types used by all other headers. Fixes #691. 2014-05-21T19:32:59+00:00 Damien George damien.p.george@gmail.com 2014-05-21T19:32:59+00:00 urn:sha1:58ebde46646dd49d22b2accfa9c7a78e15921e48 MP_ALLOC_* -> MICROPY_ALLOC_* MICROPY_PATH_MAX -> MICROPY_ALLOC_PATH_MAX MICROPY_ENABLE_REPL_HELPERS -> MICROPY_HELPER_REPL MICROPY_ENABLE_LEXER_UNIX -> MICROPY_HELPER_LEXER_UNIX MICROPY_EXTRA_* -> MICROPY_PORT_* See issue #35. 2014-05-05T12:19:03+00:00 Damien George damien.p.george@gmail.com 2014-05-05T12:19:03+00:00 urn:sha1:66e18f04d811197854c0ce970b2dc8ac17deaebc There are 2 locations in parser, and 1 in compiler, where memory allocation is not precise. In the parser it's the rule stack and result stack, in the compiler it's the array for the identifiers in the current scope. All other mallocs are exact (ie they don't allocate more than is needed). This patch adds tuning options (MP_ALLOC_*) to mpconfig.h for these 3 inexact allocations. The inexact allocations in the parser should actually be close to logarithmic: you need an exponentially larger script (absent pathological cases) to use up more room on the rule and result stacks. As such, the default allocation policy for these is now to start with a modest sized stack, but grow only in small increments. For the identifier arrays in the compiler, these now start out quite small (4 entries, since most functions don't have that many ids), and grow incrementally by 6 (since if you have more ids than 4, you probably have quite a few more, but it wouldn't be exponentially more). Partially addresses issue #560.