GitLab

Required to pass bytes_compare3.py (opptional warnings) on devices.

This allows to use printf() in a any source file with unix port, for quick
debugging.

Order out-of-bounds check, completion check, and increment in the right way.

There's single str_index_to_ptr() function, called for both bytes and
unicode objects, so should handle each properly.

We have adopted POSIX-compatible error numbers as MicroPython's native.

The idea behind decrease is: bytecode and other static data is also kept on
heap, and can easily become half of heap, then setting threshold to half of
heap will have null effect - GC will happen on complete heap exhaustion like
before. But exactly in such config maintaining heap defragmented is very
important, so lower threshold to accommodate that.

Otherwise, on bare-metal/RTOS systems can lead to resource leaks.

Should keep good chunk of heap unfragmented, if a user application allows
that at all.

Because they may use dupterm functionality (e.g. WebREPL running on boot).

This is a fix for https://github.com/micropython/micropython/issues/2209:
by default a file created using open() uses text translation mode so writing
\n to it will result in the file having \r\n. This is obviously problematic
for binary .mpy files, so provide functions for setting the open mode
and use binary mode in mpy-cross' main().

This may produce a warning, depending on MicroPython configuration.

Also, fix a warning text (remove "duplicate" BytesWarning).

Something like:

if foo == "bar":

will be always false if foo is b"bar". In CPython, warning is issued if
interpreter is started as "python3 -b". In MicroPython,
MICROPY_PY_STR_BYTES_CMP_WARN setting controls it.

Currently, MicroPython runs GC when it could not allocate a block of memory,
which happens when heap is exhausted. However, that policy can't work well
with "inifinity" heaps, e.g. backed by a virtual memory - there will be a
lot of swap thrashing long before VM will be exhausted. Instead, in such
cases "allocation threshold" policy is used: a GC is run after some number of
allocations have been made. Details vary, for example, number or total amount
of allocations can be used, threshold may be self-adjusting based on GC
outcome, etc.

This change implements a simple variant of such policy for MicroPython. Amount
of allocated memory so far is used for threshold, to make it useful to typical
finite-size, and small, heaps as used with MicroPython ports. And such GC policy
is indeed useful for such types of heaps too, as it allows to better control
fragmentation. For example, if a threshold is set to half size of heap, then
for an application which usually makes big number of small allocations, that
will (try to) keep half of heap memory in a nice defragmented state for an
occasional large allocation.

For an application which doesn't exhibit such behavior, there won't be any
visible effects, except for GC running more frequently, which however may
affect performance. To address this, the GC threshold is configurable, and
by default is off so far. It's configured with gc.threshold(amount_in_bytes)
call (can be queries without an argument).

Allows to build the library variant for other ports in parallel.

Allows to build the library variant for other archs in parallel.

Shares the code with remove() method due to the same underlying f_unlink()
FatFs operation.

Accepts only value of True.

3-arg form:

stream.write(data, offset, length)

2-arg form:

stream.write(data, length)

These allow efficient buffer writing without incurring extra memory
allocation for slicing or creating memoryview() object, what is
important for low-memory ports.

All arguments must be positional. It might be not so bad idea to standardize
on 3-arg form, but 2-arg case would need check and raising an exception
anyway then, so instead it was just made to work.