CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=3.x 2017-08-26T02:17:07+00:00 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-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-27T22:17:30+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2017-06-27T22:17:30+00:00 urn:sha1:778e975936b9e892c4f1b85ce73462a0ce6d36d2 os is a subset of CPython's os. storage contains additional file system mounting functionality based on UNIX's mount management. Fixes #140 2017-05-10T01:39:28+00:00 Damien George damien.p.george@gmail.com 2017-05-05T13:31:51+00:00 urn:sha1:87283c1974188707b436eebf2a04d4555a26dcca uos.ilistdir() is the core function, returning an iterator that yields 3-tuples. uos.listdir() is implemented in terms of ilistdir(). 2017-01-30T01:26:08+00:00 Damien George damien.p.george@gmail.com 2017-01-29T08:20:27+00:00 urn:sha1:b697c890096805d9ccaf7553dbff5b82f5332609 vfs.h is for generic VFS declarations, and vfs_fat.h is for VfsFat specific things. 2017-01-30T01:18:35+00:00 Damien George damien.p.george@gmail.com 2017-01-29T04:14:15+00:00 urn:sha1:6eafa544865a5d6dcb18f9161f7a18bd4fb6229f It can be useful for low-level lookup of paths by ports. 2017-01-27T12:22:15+00:00 Damien George damien.p.george@gmail.com 2017-01-27T11:40:15+00:00 urn:sha1:3f6b4e08e38d3205f7a5a21f7ff81ab9f3c3c497 It should only be used for low-level things and with caution, for example putting mounted VFS data in ROM or the static data section. 2017-01-27T06:19:06+00:00 Damien George damien.p.george@gmail.com 2017-01-27T04:10:09+00:00 urn:sha1:dcb9ea72157f1d9f3b0dc306c2c31cbd647f5ee1 This provides mp_vfs_XXX functions (eg mount, open, listdir) which are agnostic to the underlying filesystem type, and just require an object with the relevant filesystem-like methods (eg .mount, .open, .listidr) which can then be mounted. These mp_vfs_XXX functions would typically be used by a port to implement the "uos" module, and mp_vfs_open would be the builtin open function. This feature is controlled by MICROPY_VFS, disabled by default.