CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=3.0.0-beta.1 2018-05-06T17:31:54+00:00 2018-05-06T17:31:54+00:00 Jeff Epler jepler@gmail.com 2018-05-06T17:29:55+00:00 urn:sha1:11a97bdffeedb933939514a7e6e27ac8796cb978 2018-05-06T17:31:54+00:00 Jeff Epler jepler@gmail.com 2018-05-06T17:28:36+00:00 urn:sha1:005226ae548a45bde03a2b2400998185aa68495e .. this maybe should be subject to MICROPY_CPYTHON_COMPAT, except that is not defined in the main circuitpython ports so it would be a change that makes no difference. 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. 2016-09-21T14:23:16+00:00 Damien George damien.p.george@gmail.com 2016-09-21T00:52:53+00:00 urn:sha1:93c4a6a3f70e389b466fbc7a4f1ad2e1df87c93f One can instead lookup __name__ in the modules dict to get the value. 2016-01-24T22:49:00+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-01-24T22:48:25+00:00 urn:sha1:f5c42dd9d199aa61b16ad54a73531eefbb0be3eb 2016-01-24T18:55:09+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-01-24T18:52:54+00:00 urn:sha1:ee1656e148f81d48989393d7ed579e2eb5d63b1b SHA1 is used in a number of protocols and algorithm originated 5 years ago or so, in other words, it's in "wide use", and only newer protocols use SHA2. The implementation depends on axTLS enabled. TODO: Make separate config option specifically for sha1(). 2016-01-11T00:49:27+00:00 Damien George damien.p.george@gmail.com 2016-01-03T15:55:55+00:00 urn:sha1:5b3f0b7f39bd67cc9182993c288f09f67a0890df The first argument to the type.make_new method is naturally a uPy type, and all uses of this argument cast it directly to a pointer to a type structure. So it makes sense to just have it a pointer to a type from the very beginning (and a const pointer at that). This patch makes such a change, and removes all unnecessary casting to/from mp_obj_t. 2016-01-11T00:48:41+00:00 Damien George damien.p.george@gmail.com 2016-01-03T09:59:18+00:00 urn:sha1:a0c97814dfcb0debbde8be99539e3d5ca2334e54 This patch changes the type signature of .make_new and .call object method slots to use size_t for n_args and n_kw (was mp_uint_t. Makes code more efficient when mp_uint_t is larger than a machine word. Doesn't affect ports when size_t and mp_uint_t have the same size. 2015-12-20T21:14:47+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2015-12-20T14:57:57+00:00 urn:sha1:1b7f62241023fdd000ee011824679a34d615c722 Everyone loves to names similar things the same, then there're conflicts between different libraries. The namespace prefix used is "CRYAL_", which is weird, and that's good, as that minimizes chance of another conflict.