CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=3.0.0 2018-05-14T20:57:50+00:00 2018-05-14T20:57:50+00:00 Roy Hooper rhooper@toybox.ca 2018-05-14T20:57:50+00:00 urn:sha1:567f3e30a77f286713b697a0f8a85e8b31a4a27a 2018-01-24T18:33:46+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2018-01-24T00:22:05+00:00 urn:sha1:416abe33ed44e44d8f75342731080217e123278b This adapts the allocation process to start from either end of the heap when searching for free space. The default behavior is identical to the existing behavior where it starts with the lowest block and looks higher. Now it can also look from the highest block and lower depending on the long_lived parameter to gc_alloc. As the heap fills, the two sections may overlap. When they overlap, a collect may be triggered in order to keep the long lived section compact. However, free space is always eligable for each type of allocation. By starting from either of the end of the heap we have ability to separate short lived objects from long lived ones. This separation reduces heap fragmentation because long lived objects are easy to densely pack. Most objects are short lived initially but may be made long lived when they are referenced by a type or module. This involves copying the memory and then letting the collect phase free the old portion. QSTR pools and chunks are always long lived because they are never freed. The reallocation, collection and free processes are largely unchanged. They simply also maintain an index to the highest free block as well as the lowest. These indices are used to speed up the allocation search until the next collect. In practice, this change may slightly slow down import statements with the benefit that memory is much less fragmented afterwards. For example, a test import into a 20k heap that leaves ~6k free previously had the largest continuous free space of ~400 bytes. After this change, the largest continuous free space is over 3400 bytes. 2017-10-25T05:31:16+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2017-10-25T05:31:16+00:00 urn:sha1:73c15dcf8b1b927757a595a867334b38355ddb8f This is prep for merging in the NRF5 pull request. 2017-09-04T13:35:46+00:00 Damien George damien.p.george@gmail.com 2017-09-04T13:35:46+00:00 urn:sha1:77a48e8cd493c0b0e0ca2d2ad58a110a23c6a232 2017-09-02T20:05:24+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-09-02T18:19:01+00:00 urn:sha1:9950865c39044e9fef295d0676af7c5fd55289ea These are now returned as "operation not supported" instead of raising TypeError. In particular, this fixes equality for float vs incompatible types, which now properly results in False instead of exception. This also paves the road to support reverse operation (e.g. __radd__) with float objects. This is achieved by introducing mp_obj_get_float_maybe(), similar to existing mp_obj_get_int_maybe(). 2017-08-29T22:39:24+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-08-29T22:35:48+00:00 urn:sha1:784909ce1655bf8b2a97ac81a3842e844992082f NotImplemented means "try other fallbacks (like calling __rop__ instead of __op__) and if nothing works, raise TypeError". As MicroPython doesn't implement any fallbacks, signal to raise TypeError right away. 2017-08-29T03:16:30+00:00 Damien George damien.p.george@gmail.com 2017-08-29T03:04:01+00:00 urn:sha1:58321dd9854d71a96e5db2d361e0efc05d9de8cf The unary-op/binary-op enums are already defined, and there are no arithmetic tricks used with these types, so it makes sense to use the correct enum type for arguments that take these values. It also reduces code size quite a bit for nan-boxing builds. 2017-08-26T02:17:07+00:00 Dan Halbert halbert@halwitz.org 2017-08-26T02:17:07+00:00 urn:sha1:ef61b5ecb59e9b4e37e3e3c023c62d583c23eb16 cpx build compiles and loads and works in repl; test suite not run yet esp8266 not tested yet 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