CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=2.x 2017-07-31T08:35:40+00:00 2017-07-31T08:35:40+00:00 Alexander Steffen devel.20.webmeister@spamgourmet.com 2017-06-30T07:22:17+00:00 urn:sha1:55f33240f3d7051d4213629e92437a36f1fac50e There were several different spellings of MicroPython present in comments, when there should be only one. 2017-07-18T01:57:39+00:00 Alexander Steffen devel.20.webmeister@spamgourmet.com 2017-06-29T21:14:58+00:00 urn:sha1:299bc625864b9e624ed599c94a5f95870516139a The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h 2016-09-30T03:53:00+00:00 Damien George damien.p.george@gmail.com 2016-09-30T03:53:00+00:00 urn:sha1:0d10517a45fc90e7da9fc527ccfe51ab10205548 Saves 50-100 bytes of code. 2016-09-30T02:45:00+00:00 Damien George damien.p.george@gmail.com 2016-09-30T02:45:00+00:00 urn:sha1:d5495966cea38f452646b2f171859f66bebcf05e On 32-bit archs this makes the scope_t struct 48 bytes in size, which fits in 3 GC blocks (previously it used 4 GC blocks). This will lead to some savings when compiling scripts because there are usually quite a few scopes, one for each function and class. Note that qstrs will fit in 16 bits, this assumption is made in a few other places. 2016-09-30T02:34:05+00:00 Damien George damien.p.george@gmail.com 2016-09-30T02:34:05+00:00 urn:sha1:3dea8c9e926d0c1b1049ff9d5abeedfb001fc201 Generates slightly smaller and more efficient code. 2015-11-13T12:49:18+00:00 Damien George damien.p.george@gmail.com 2015-10-22T22:45:37+00:00 urn:sha1:3a3db4dcf0400cffef860f61a84979cb1f7a7541 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.