CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=4.0.0-rc.2 2019-05-07T16:30:55+00:00 2019-05-07T16:30:55+00:00 Kathryn Lingel kathryn@lingel.net 2019-05-07T16:30:55+00:00 urn:sha1:eb3cb4d99bc324d941e4fd32fd30c86ebf4c44e3 2019-05-06T22:13:28+00:00 Kathryn Lingel kathryn@lingel.net 2019-05-06T22:13:28+00:00 urn:sha1:33b5cff8db0915875d7c45c467bff3c77b7d9532 2019-05-06T21:19:07+00:00 Kathryn Lingel kathryn@lingel.net 2019-05-06T21:19:07+00:00 urn:sha1:77f177be9c52deea63de544701fa476239249dcd 2018-02-19T05:12:44+00:00 Damien George damien.p.george@gmail.com 2018-02-15T07:12:31+00:00 urn:sha1:165aab12a3918004325238c794e27e7f4adbb401 This patch changes the way REPL autocomplete finds matches. It now probes the target object for all qstrs via mp_load_method_maybe to look for a match with the given input string. Similar to how the builtin dir() function works, this new algorithm now find all methods and instances of user-defined classes including attributes of their parent classes. This helps a lot at the REPL prompt for user-discovery and to autocomplete names even for classes that are derived. The downside is that this new algorithm is slower than the previous one, and in particular will be slower the more qstrs there are in the system. But because REPL autocomplete is primarily used in an interactive way it is not that important to make it fast, as long as it is "fast enough" compared to human reaction. On a slow microcontroller (CPU running at 16MHz) the autocomplete time for a list of 35 names in the outer namespace (pressing tab at a bare prompt) takes about 160ms with this algorithm, compared to about 40ms for the previous implementation (this time includes the actual printing of the names as well). This time of 160ms is very reasonable especially given the new functionality of listing all the names. This patch also decreases code size by: bare-arm: +0 minimal x86: -128 unix x64: -128 unix nanbox: -224 stm32: -88 cc3200: -80 esp8266: -92 esp32: -84 2017-12-19T05:13:00+00:00 Damien George damien.p.george@gmail.com 2017-12-19T05:13:00+00:00 urn:sha1:35a759dc1dae33d62d005fe44f3cda4599a3c297 2017-10-04T23:49:44+00:00 Damien George damien.p.george@gmail.com 2017-10-03T12:34:28+00:00 urn:sha1:0864a6957fe4717c3ec40ceeb373b19614a18434 2 non-bytecode binary ops (NOT_IN and IN_NOT) are moved out of the bytecode group, so this change will change the bytecode format. 2017-09-25T23:35:19+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-09-25T23:35:19+00:00 urn:sha1:9d836fedbdb1d28bdfc4ba475bbdfc1adb3f007a Not all can, so we don't need to reserve bytecodes for them, and can use free slots for something else later. 2017-09-07T21:10:10+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-09-07T21:10:10+00:00 urn:sha1:b8ee7ab5b988f424e34e778fe3a679710d675efa This is to allow to place reverse ops immediately after normal ops, so they can be tested as one range (which is optimization for reverse ops introduction in the next patch). 2017-09-07T08:26:42+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-09-07T08:26:42+00:00 urn:sha1:50b9329eba29a36b6948699aaea9473681d4f46b It starts a dichotomy of mp_binary_op_t values which can't appear in the bytecode. Another reason to move it is to VALUES of OP_* and OP_INPLACE_* nicely adjacent. This also will be needed for OP_REVERSE_*, to be soon introduced. 2017-09-07T07:55:43+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-09-07T07:55:43+00:00 urn:sha1:d4d1c45a553c6361a72053383f0fe242f05cad3d This is to allow to encode arithmetic operations more efficiently, in preparation to introduction of __rOP__ method support.