CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=5.0.0-beta.3 2017-08-30T11:02:00+00:00 2017-08-30T11:02:00+00:00 Damien George damien.p.george@gmail.com 2017-08-30T11:02:00+00:00 urn:sha1:0102ee092b590be2736521ebf165c96bcf0bcbe6 This comment style is no longer used because the docs are written by hand, not generated. 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-07-20T21:37:30+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-07-20T21:37:30+00:00 urn:sha1:93e353e3844f7116088a1a105ba588cade0e6783 Currently, MicroPython runs GC when it could not allocate a block of memory, which happens when heap is exhausted. However, that policy can't work well with "inifinity" heaps, e.g. backed by a virtual memory - there will be a lot of swap thrashing long before VM will be exhausted. Instead, in such cases "allocation threshold" policy is used: a GC is run after some number of allocations have been made. Details vary, for example, number or total amount of allocations can be used, threshold may be self-adjusting based on GC outcome, etc. This change implements a simple variant of such policy for MicroPython. Amount of allocated memory so far is used for threshold, to make it useful to typical finite-size, and small, heaps as used with MicroPython ports. And such GC policy is indeed useful for such types of heaps too, as it allows to better control fragmentation. For example, if a threshold is set to half size of heap, then for an application which usually makes big number of small allocations, that will (try to) keep half of heap memory in a nice defragmented state for an occasional large allocation. For an application which doesn't exhibit such behavior, there won't be any visible effects, except for GC running more frequently, which however may affect performance. To address this, the GC threshold is configurable, and by default is off so far. It's configured with gc.threshold(amount_in_bytes) call (can be queries without an argument). 2015-12-17T13:20:40+00:00 Damien George damien.p.george@gmail.com 2015-12-17T13:20:40+00:00 urn:sha1:02fa8dff859be40443f16baf9bc7431878f34ec1 2015-11-29T14:25:04+00:00 Damien George damien.p.george@gmail.com 2015-11-27T13:38:15+00:00 urn:sha1:cbf7674025814797f5c537d6d1c195efe58ccaaf 2015-10-11T12:18:15+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2015-10-11T09:09:43+00:00 urn:sha1:1b586f3a734c27c78080fb2173bbde17168cb9e4 2015-02-07T17:24:10+00:00 Damien George damien.p.george@gmail.com 2015-02-07T17:24:10+00:00 urn:sha1:e1e359ff59d6bbf09441cc1f3965be63f1046182 Without mp_sys_path and mp_sys_argv in the root pointer section of the state, their memory was being incorrectly collected by GC. 2015-01-07T20:33:00+00:00 Damien George damien.p.george@gmail.com 2015-01-01T23:30:53+00:00 urn:sha1:b4b10fd350852e321624d74983cca286091b55a1 This patch consolidates all global variables in py/ core into one place, in a global structure. Root pointers are all located together to make GC tracing easier and more efficient. 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.