CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=2.3.1 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-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-28T18:54:59+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-07-28T18:41:42+00:00 urn:sha1:456450437fc572d0296d52be0035e135ab6814d8 2017-05-06T15:42:35+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-05-06T15:42:35+00:00 urn:sha1:4a4490ffcc906fe88e157dc926be54030c6fbf72 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-10-07T02:31:59+00:00 Damien George damien.p.george@gmail.com 2016-10-07T02:31:59+00:00 urn:sha1:3a0a7717304cc34a4d6ef55f767666c918c185b5 This is an often used code pattern, and its use reduces code size of the core by about 100 bytes. 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-06-18T15:44:57+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-06-18T15:19:24+00:00 urn:sha1:07209f8592f15435d6abbccaad5347cea2c7722e It's now used for more than just stream protocol (e.g. pin protocol), so don't use false names. 2016-05-17T23:41:45+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-05-17T23:40:03+00:00 urn:sha1:7f7c84b10a5f3b2f783955b01f55e0f913ac459f Both read and write operations support variants where either a) a single call is made to the undelying stream implementation and returned buffer length may be less than requested, or b) calls are repeated until requested amount of data is collected, shorter amount is returned only in case of EOF or error. These operations are available from the level of C support functions to be used by other C modules to implementations of Python methods to be used in user-facing objects. The rationale of these changes is to allow to write concise and robust code to work with *blocking* streams of types prone to short reads, like serial interfaces and sockets. Particular object types may select "exact" vs "once" types of methods depending on their needs. E.g., for sockets, revc() and send() methods continue to be "once", while read() and write() thus converted to "exactly" versions. These changes don't affect non-blocking handling, e.g. trying "exact" method on the non-blocking socket will return as much data as available without blocking. No data available is continued to be signaled as None return value to read() and write(). From the point of view of CPython compatibility, this model is a cross between its io.RawIOBase and io.BufferedIOBase abstract classes. For blocking streams, it works as io.BufferedIOBase model (guaranteeing lack of short reads/writes), while for non-blocking - as io.RawIOBase, returning None in case of lack of data (instead of raising expensive exception, as required by io.BufferedIOBase). Such a cross-behavior should be optimal for MicroPython needs.