GitLab

Can now have null bytes in strings.  Can define ROM qstrs per port using
qstrdefsport.h

Currently, MicroPython strings are mix between CPython byte and unicode
strings. So, conversion is null so far. This dummy implementation is
intended for compatibility with CPython (so, same code can run on both).

These are micropython.mem_total(), .mem_current(), .mem_peak(). These are 3
individual functions with simple scalar return value to make sure that
calls to these functions themselves have minimal (hopefully zero) impact on
memory allocation.

Exceptions know source file, line and block name.

Also tidy up some debug printing functions and provide a global
flag to enable/disable them.

Now searches both locals_dict and methods.  Partly addresses Issue #145.

So far, only storage, initialization, repr() and buffer protocol is
implemented - alredy suitable for passing binary data around.

Change state layout in VM so the stack starts at state[0] and grows
upwards.  Locals are at the top end of the state and number downwards.
This cleans up a lot of the interface connecting the VM to C: now all
functions that take an array of Micro Python objects are in order (ie no
longer in reverse).

Also clean up C API with keyword arguments (call_n and call_n_kw
replaced with single call method that takes keyword arguments).  And now
make_new takes keyword arguments.

emitnative.c has not yet been changed to comply with the new order of
stack layout.

Implicit "micropython" module contains (at least) codegeneration decorators.
Make it explicit, so an app could have "import micropython". On MicroPython,
that will be no-op. On CPython, that will give a chance to have a module
with placeholder decorators.

So far, don't work for strings as expected.

We likely should make mp_obj_new_int() inline, and rely on its
encapsulated check rather than inline checks everywhere explicitly.

Also, parser for big small int values is still broken.

Currently it would report "operation not supported" which is confusing. Overall,
this is thinko leading to undefined behavior.

Still need to make built-ins by these names, and write tests.

Creating of classes (types) and instances is much more like CPython now.
You can use "type('name', (), {...})" to create classes.

Addresses issue #104.