| Commit message (Collapse) | Author | Age |
|
|
|
| |
The GIL macros are needed even if threading is not enabled.
|
| |
|
|
|
|
|
| |
There is no need since the GIL already makes gc and qstr operations
atomic.
|
|
|
|
|
| |
This makes the VM/runtime thread safe, at the cost of not being able to
run code in parallel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
GC_EXIT() can cause a pending thread (waiting on the mutex) to be
scheduled right away. This other thread may trigger a garbage
collection. If the pointer to the newly-allocated block (allocated by
the original thread) is not computed before the switch (so it's just left
as a block number) then the block will be wrongly reclaimed.
This patch makes sure the pointer is computed before allowing any thread
switch to occur.
|
|
|
|
| |
So the underlying thread implementation can do any necessary bookkeeping.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
By using a single, global mutex, all memory-related functions (alloc,
free, realloc, collect, etc) are made thread safe. This means that only
one thread can be in such a function at any one time.
|
| |
|
| |
|
|
|
|
| |
Simply raises the SystemExit exception.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This allows to define an abstract base class which would translate
C-level protocol to Python method calls, and any subclass inheriting
from it will support this feature. This in particular actually enables
recently introduced machine.PinBase class.
|
|
|
|
|
|
|
| |
Allows to translate C-level pin API to Python-level pin API. In other
words, allows to implement a pin class and Python which will be usable
for efficient C-coded algorithms, like bitbanging SPI/I2C, time_pulse,
etc.
|
|
|
|
|
| |
It's now used for more than just stream protocol (e.g. pin protocol), so
don't use false names.
|
|
|
|
|
| |
It has more usages than just qstr extraction, for example, embedding (where
people don't care about efficient predefined qstrs).
|
|
|
|
| |
"lib" happened to be defined inside block conditional on $(PROG).
|
|
|
|
|
|
| |
That's arbitrary restriction, in case of embedding, a source file path may
be absolute. For the purpose of filtering out system includes, checking
for ".c" suffix is enough.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Assignments of the form "_id = const(value)" are treated as private
(following a similar CPython convention) and code is no longer emitted
for the assignment to a global variable.
See issue #2111.
|
|
|
|
|
| |
Since not all ports that enable the machine module have the pin HAL
functions.
|
|
|
|
| |
The C implementation is taken from the DHT driver.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Using usual method of virtual method tables. Single virtual method,
ioctl, is defined currently for all operations. This universal and
extensible vtable-based method is also defined as a default MPHAL
GPIO implementation, but a specific port may override it with its
own implementation (e.g. close-ended, but very efficient, e.g. avoiding
virtual method dispatch).
|
|
|
|
| |
Useful to check file/dir operations result, in particular used by upip.
|
|
|
|
|
| |
So the documentation's example works. Besides, a tuple can be more
memory efficient.
|
|
|
|
|
| |
When rendering the qstr for a C header file, the double-quate character
must be escaped.
|
|
|
|
| |
Freezing mpy files using mpy-tool.py now works again.
|
| |
|
| |
|
|
|
|
|
|
| |
Disabled by default, enabled in unix port. Need for this method easily
pops up when working with text UI/reporting, and coding workalike
manually again and again counter-productive.
|
| |
|
|
|
|
|
| |
These are workarounds required until frozen .mpy loading following standard
frozen modules code path.
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
Similar to existing mp_hal_delay_ms/mp_hal_ticks_ms.
|
| |
|
|
|
|
|
| |
Otherwise some compilers (eg without optimisation) will put this read-only
data in RAM instead of ROM.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|