- May 17, 2019
-
-
Damien George authored
-
Paul Sokolovsky authored
For modules I initially created or made substantial contributions to.
-
- Jul 31, 2017
-
-
Alexander Steffen authored
There were several different spellings of MicroPython present in comments, when there should be only one.
-
- Jul 18, 2017
-
-
Alexander Steffen authored
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
-
- Jun 27, 2017
-
-
Alexander Steffen authored
-
- May 02, 2017
-
-
Paul Sokolovsky authored
The with semantics of this function is close to pkg_resources.resource_stream() function from setuptools, which is the canonical way to access non-source files belonging to a package (resources), regardless of what medium the package uses (e.g. individual source files vs zip archive). In the case of MicroPython, this function allows to access resources which are frozen into the executable, besides accessing resources in the file system. This is initial stage of the implementation, which actually doesn't implement "package" part of the semantics, just accesses frozen resources from "root", or filesystem resource - from current dir.
-
- May 21, 2016
-
-
Paul Sokolovsky authored
Now frozen modules is treated just as a kind of VFS, and all operations performed on it correspond to operations on normal filesystem. This allows to support packages properly, and potentially also data files. This change also have changes to rework frozen bytecode modules support to use the same framework, but it's not finished (and actually may not work, as older adhox handling of any type of frozen modules is removed).
-
- Apr 13, 2016
-
-
Damien George authored
The config variable MICROPY_MODULE_FROZEN is now made of two separate parts: MICROPY_MODULE_FROZEN_STR and MICROPY_MODULE_FROZEN_MPY. This allows to have none, either or both of frozen strings and frozen mpy files (aka frozen bytecode).
-
- Jan 20, 2015
-
-
Paul Sokolovsky authored
Only modules (not packages) supported now. Source modules can be converted to frozen module structures using tools/make-frozen.py script.
-
- Jan 07, 2015
-
-
Damien George authored
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.
-
- May 09, 2014
-
-
stijn authored
-
- May 03, 2014
-
-
Damien George authored
Blanket wide to all .c and .h files. Some files originating from ST are difficult to deal with (license wise) so it was left out of those. Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
-
Damien George authored
-
stijn authored
By default mingw outputs 3 digits instead of the standard 2 so all float tests using printf fail. Using setenv at the start of the program fixes this. To accomodate calling platform specific initialization a MICROPY_MAIN_INIT_FUNC macro is used which is called in mp_init()
-