CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=5.3.1 2017-09-01T20:12:26+00:00 2017-09-01T20:12:26+00:00 Dan Halbert halbert@halwitz.org 2017-09-01T20:12:26+00:00 urn:sha1:a0d0b27faf0bc76ede0fbc595f641fdceb04ac56 The frozen module `_boot.py` was not being loaded on restart because `pyexec_frozen_module()` did not know about the new `.frozen` pseudo-directory. Updated lower-level routine to look in the right place. Also made ".frozen" and related values be `#define`s. 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-08-10T22:46:17+00:00 Scott Shawcroft scott@chickadee.tech 2017-08-10T22:46:17+00:00 urn:sha1:f6a702538a0b3dd72879d65e3acc32520d4371f5 This makes it clear when frozen modules are loaded as opposed to the empty path which represents the current working directory. Furthermore, by splitting the two apart this allows one to control in what order frozen modules are loaded. This is a prerequisite for #56. 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 2017-06-27T21:51:45+00:00 Alexander Steffen webmeister@users.noreply.github.com 2017-06-27T14:21:45+00:00 urn:sha1:cd0987f5b7ad8b93278b9fbef4fe2f43e5cdc586 2017-05-02T22:47:08+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-05-02T22:47:08+00:00 urn:sha1:d7da2dba07778fa3c0c7873b7c253bde48066e9c 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. 2016-05-21T18:38:50+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-05-21T18:33:42+00:00 urn:sha1:fb742cdc1215c5444cbe9e10f37fecb4ffce0006 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). 2016-04-13T15:07:47+00:00 Damien George damien.p.george@gmail.com 2016-01-31T22:24:16+00:00 urn:sha1:0a2e9650f5383bc1190d6b27a3d923e313c3d879 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). 2015-01-20T09:52:12+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2015-01-20T09:52:12+00:00 urn:sha1:640e0b221e972f9a2da2d870bf3fc5a93c18f0ec Only modules (not packages) supported now. Source modules can be converted to frozen module structures using tools/make-frozen.py script.