CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=main 2021-03-15T13:57:36+00:00 2021-03-15T13:57:36+00:00 microDev 70126934+microDev1@users.noreply.github.com 2021-03-15T13:57:36+00:00 urn:sha1:a52eb88031620a81521b937f2a0651dbac2bb350 2021-02-15T18:05:57+00:00 Bernhard Boser boser@berkeley.edu 2021-02-15T18:05:57+00:00 urn:sha1:f8f59598c76653a47da101ed1044dfd35d2cfacc 2020-07-06T18:16:25+00:00 Diego Elio Pettenò flameeyes@flameeyes.com 2020-06-03T22:40:05+00:00 urn:sha1:34b4993d63a6b576f29d624385c681f679b4124c 2018-08-09T20:29:30+00:00 Scott Shawcroft scott@tannewt.org 2018-08-09T01:24:49+00:00 urn:sha1:96ebf5bc3fb455162286b9bc31e763f3c4f1c457 * Fix finding translations with escaped characters. * Add back \r to translations since its needed by screen. 2017-10-04T01:37:50+00:00 Damien George damien.p.george@gmail.com 2017-10-04T01:37:50+00:00 urn:sha1:a3dc1b1957d2c96d7c60c2c629c95077b03488a1 Header files that are considered internal to the py core and should not normally be included directly are: py/nlr.h - internal nlr configuration and declarations py/bc0.h - contains bytecode macro definitions py/runtime0.h - contains basic runtime enums Instead, the top-level header files to include are one of: py/obj.h - includes runtime0.h and defines everything to use the mp_obj_t type py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h, and defines everything to use the general runtime support functions Additional, specific headers (eg py/objlist.h) can be included if needed. 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-21T05:16:51+00:00 Tom Collins tom.collins@digi.com 2017-07-11T22:27:42+00:00 urn:sha1:bb3bddabb53e00965f9becba6df6af99c6c9bc77 2017-03-29T01:56:45+00:00 Damien George damien.p.george@gmail.com 2017-03-25T08:48:18+00:00 urn:sha1:6b341075376705ee1fe9e003b76b09afa59778f4 2017-03-28T11:37:26+00:00 Damien George damien.p.george@gmail.com 2017-03-28T11:37:26+00:00 urn:sha1:94c41bb06f6482ece0717c5bd63266b8da063caa Saves 168 bytes on bare-arm. 2017-03-14T00:52:05+00:00 Damien George damien.p.george@gmail.com 2017-03-14T00:16:31+00:00 urn:sha1:1831034be13fef5344583c557ff089df31788251 This patch refactors the error handling in the lexer, to simplify it (ie reduce code size). A long time ago, when the lexer/parser/compiler were first written, the lexer and parser were designed so they didn't use exceptions (ie nlr) to report errors but rather returned an error code. Over time that has gradually changed, the parser in particular has more and more ways of raising exceptions. Also, the lexer never really handled all errors without raising, eg there were some memory errors which could raise an exception (and in these rare cases one would get a fatal nlr-not-handled fault). This patch accepts the fact that the lexer can raise exceptions in some cases and allows it to raise exceptions to handle all its errors, which are for the most part just out-of-memory errors during construction of the lexer. This makes the lexer a bit simpler, and also the persistent code stuff is simplified. What this means for users of the lexer is that calls to it must be wrapped in a nlr handler. But all uses of the lexer already have such an nlr handler for the parser (and compiler) so that doesn't put any extra burden on the callers.