- Apr 15, 2019
-
-
Damien George authored
The issue described in the comment added here can be seen by forcing a gc_collect() at the start of each call to gc_alloc().
-
Damien George authored
-
Damien George authored
-
- Apr 12, 2019
-
-
Damien George authored
In case (user) source code contains utf-8 encoded data and the default locale is not utf-8. See #4592.
-
- Mar 26, 2019
-
-
Romain Goyet authored
-
Andrew Leech authored
This means the schedule operates on a first-in, first-executed manner rather than the current last-in, first executed.
-
- Mar 19, 2019
-
-
Damien George authored
In 1808b2e8 it was replaced by MICROPY_VFS and related code.
-
- Mar 14, 2019
-
-
Damien George authored
-
Damien George authored
-
Damien George authored
-
Damien George authored
-
Damien George authored
-
- Mar 08, 2019
-
-
Andrew Leech authored
How to use this feature is documented in docs/develop/cmodules.rst.
-
Ayke van Laethem authored
This system makes it a lot easier to include external libraries as static, native modules in MicroPython. Simply pass USER_C_MODULES (like FROZEN_MPY_DIR) as a make parameter.
-
Andrew Leech authored
During make, makemoduledefs.py parses the current builds c files for MP_REGISTER_MODULE(module_name, obj_module, enabled_define) These are used to generate a header with the required entries for "mp_rom_map_elem_t mp_builtin_module_table[]" in py/objmodule.c
-
Damien George authored
-
Damien George authored
This commit adds support for saving and loading .mpy files that contain native code (native, viper and inline-asm). A lot of the ground work was already done for this in the form of removing pointers from generated native code. The changes here are mainly to link in qstr values to the native code, and change the format of .mpy files to contain native code blocks (possibly mixed with bytecode). A top-level summary: - @micropython.native, @micropython.viper and @micropython.asm_thumb/ asm_xtensa are now allowed in .py files when compiling to .mpy, and they work transparently to the user. - Entire .py files can be compiled to native via mpy-cross -X emit=native and for the most part the generated .mpy files should work the same as their bytecode version. - The .mpy file format is changed to 1) specify in the header if the file contains native code and if so the architecture (eg x86, ARMV7M, Xtensa); 2) for each function block the kind of code is specified (bytecode, native, viper, asm). - When native code is loaded from a .mpy file the native code must be modified (in place) to link qstr values in, just like bytecode (see py/persistentcode.c:arch_link_qstr() function). In addition, this now defines a public, native ABI for dynamically loadable native code generated by other languages, like C.
-
Damien George authored
-
Damien George authored
n_obj no longer includes a count for mp_fun_table to make it a bit simpler.
-
Damien George authored
-
Damien George authored
Simplifies the code and fixes handling of the Ellipsis const in native code generation (which also needs the constant table so must set this flag).
-
Damien George authored
The new compile-time option is MICROPY_DEBUG_MP_OBJ_SENTINELS, disabled by default. This is to allow finer control of whether this debugging feature is enabled or not (because, for example, this setting must be the same for mpy-cross and the MicroPython main code when using native code generation).
-
- Mar 05, 2019
-
-
Damien George authored
When encoded in the mpy file, if qstr <= QSTR_LAST_STATIC then store two bytes: 0, static_qstr_id. Otherwise encode the qstr as usual (either with string data or a reference into the qstr window). Reduces mpy file size by about 5%.
-
Damien George authored
Instead of emitting two bytes in the bytecode for where the linked qstr should be written to, it is now replaced by the actual qstr data, or a reference into the qstr window. Reduces mpy file size by about 10%.
-
Damien George authored
This is an implementation of a sliding qstr window used to reduce the number of qstrs stored in a .mpy file. The window size is configured to 32 entries which takes a fixed 64 bytes (16-bits each) on the C stack when loading/saving a .mpy file. It allows to remember the most recent 32 qstrs so they don't need to be stored again in the .mpy file. The qstr window uses a simple least-recently-used mechanism to discard the least recently used qstr when the window overflows (similar to dictionary compression). This scheme only needs a single pass to save/load the .mpy file. Reduces mpy file size by about 25% with a window size of 32.
-
Damien George authored
POP_BLOCK and POP_EXCEPT are now the same, and are always followed by a JUMP. So this optimisation reduces code size, and RAM usage of bytecode by two bytes for each try-except handler.
-
Damien George authored
After the previous commit it is no longer needed.
-
Damien George authored
This patch fixes a bug in the VM when breaking within a try-finally. The bug has to do with executing a break within the finally block of a try-finally statement. For example: def f(): for x in (1,): print('a', x) try: raise Exception finally: print(1) break print('b', x) f() Currently in uPy the above code will print: a 1 1 1 segmentation fault (core dumped) micropython Not only is there a seg fault, but the "1" in the finally block is printed twice. This is because when the VM executes a finally block it doesn't really know if that block was executed due to a fall-through of the try (no exception raised), or because an exception is active. In particular, for nested finallys the VM has no idea which of the nested ones have active exceptions and which are just fall-throughs. So when a break (or continue) is executed it tries to unwind all of the finallys, when in fact only some may be active. It's questionable whether break (or return or continue) should be allowed within a finally block, because they implicitly swallow any active exception, but nevertheless it's allowed by CPython (although almost never used in the standard library). And uPy should at least not crash in such a case. The solution here relies on the fact that exception and finally handlers always appear in the bytecode after the try body. Note: there was a similar bug with a return in a finally block, but that was previously fixed in b7352084
-
- Mar 04, 2019
-
-
Damien George authored
Also, to make it possible for ports to provide their own lwipopts.h, the default include directory of extmod/lwip-include is no longer added and instead a port should now make sure the correct include directory is included in the list (can still use extmod/lwip-include).
-
Tom Collins authored
-
- Mar 01, 2019
-
-
Damien George authored
This optimisation eliminates the need to create a temporary normal dict. The optimisation is enabled via MICROPY_COMP_CONST_LITERAL which is enabled by default (although only has an effect if OrderdDict is enabled). Thanks to @pfalcon for the initial idea and implementation.
-
- Feb 26, 2019
-
-
Damien George authored
All exceptions that unwind through the async-with must be caught and BaseException is the top-level class, which includes Exception and others. Fixes issue #4552.
-
- Feb 25, 2019
-
-
Damien George authored
-
- Feb 20, 2019
-
-
Damien George authored
-
Damien George authored
-
- Feb 19, 2019
-
-
Damien George authored
Q_GET_HASH may evaluate its argument more than once.
-
- Feb 13, 2019
-
-
Yonatan Goldschmidt authored
As mentioned in #4450, `websocket` was experimental with a single intended user, `webrepl`. Therefore, we'll make this change without a weak link `websocket` -> `uwebsocket`.
-
- Feb 12, 2019
-
-
Damien George authored
This change makes it so that python3 is required by default to build MicroPython. Python 2 can be used by specifying make PYTHON=python2. This comes about due to a recent-ish change to PEP 394 that makes the python command more optional than before (even with Python 2 installed); see https://github.com/python/peps/commit/cd59ec03c8ff1e75089d5872520cd0706774b35b#diff-1d22f7bd72cbc900670f058b1107d426 Since the command python is no longer required to be provided by a distribution we need to use either python2 or python3 as commands. And python3 seems the obvious choice.
-
Damien George authored
-
Damien George authored
These macros could in principle be (inline) functions so it makes sense to have them lower case, to match the other C API functions. The remaining macros that are upper case are: - MP_OBJ_TO_PTR, MP_OBJ_FROM_PTR - MP_OBJ_NEW_SMALL_INT, MP_OBJ_SMALL_INT_VALUE - MP_OBJ_NEW_QSTR, MP_OBJ_QSTR_VALUE - MP_OBJ_FUN_MAKE_SIG - MP_DECLARE_CONST_xxx - MP_DEFINE_CONST_xxx These must remain macros because they are used when defining const data (at least, MP_OBJ_NEW_SMALL_INT is so it makes sense to have MP_OBJ_SMALL_INT_VALUE also a macro). For those macros that have been made lower case, compatibility macros are provided for the old names so that users do not need to change their code immediately.
-