| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
This commit adds support for RV32IMC native modules, as in embedding native
code into a self-contained MPY module and and make its exported functions
available to the MicroPython environment.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
| |
|
|
|
|
|
| |
Python code is no longer needed to implement keyword arguments in
`btree.open()`, it can now be done in C.
Signed-off-by: Damien George <damien@micropython.org>
|
| |
|
|
|
|
|
|
|
|
| |
This provides a MicroPython-specific berkeley-db configuration in
extmod/berkeley-db/berkeley_db_config_port.h, and cleans up the include
path for this library.
Fixes issue #13092.
Signed-off-by: Damien George <damien@micropython.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STATIC macro was introduced a very long time ago in commit
d5df6cd44a433d6253a61cb0f987835fbc06b2de. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
| |
|
|
|
|
|
|
|
|
|
| |
These files all use decorators (@asm_thumb, @asm_pio) that add names to the
function scope, that the linter cannot see.
It's useful to clear them in the file not in pyproject.toml as example code
will be copied and adapted elsewhere, and those developers may also use
Ruff (we hope!)
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal here is to remove a slot (making way to turn make_new into a slot)
as well as reduce code size by the ~40 references to mp_identity_getiter
and mp_stream_unbuffered_iter.
This introduces two new type flags:
- MP_TYPE_FLAG_ITER_IS_ITERNEXT: This means that the "iter" slot in the
type is "iternext", and should use the identity getiter.
- MP_TYPE_FLAG_ITER_IS_CUSTOM: This means that the "iter" slot is a pointer
to a mp_getiter_iternext_custom_t instance, which then defines both
getiter and iternext.
And a third flag that is the OR of both, MP_TYPE_FLAG_ITER_IS_STREAM: This
means that the type should use the identity getiter, and
mp_stream_unbuffered_iter as iternext.
Finally, MP_TYPE_FLAG_ITER_IS_GETITER is defined as a no-op flag to give
the default case where "iter" is "getiter".
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
| |
|
|
|
|
|
| |
This is a no-op, but sets the stage for changing the mp_obj_type_t
representation.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
| |
|
|
|
|
|
| |
This will always have the maximum/minimum size of a mp_obj_type_t
representation and can be used as a member in other structs.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ports that have a system malloc which is not garbage collected (eg
unix, esp32), the stream object for the DB must be retained separately to
prevent it from being reclaimed by the MicroPython GC (because the
berkeley-db library uses malloc to allocate the DB structure which stores
the only reference to the stream).
Although in some cases the user code will explicitly retain a reference to
the underlying stream because it needs to call close() on it, this is not
always the case, eg in cases where the DB is intended to live forever.
Fixes issue #5940.
|
| |
|
|
| |
So this setting could be used by other source files if needed.
|
| |
|
