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.

Make variable MICROPY_SSL_AXTLS=1 should be defined to activate modussl_axtls
and link with -laxtls.

Otherwise gcc 6.1.1 raises a misleading-indentation error.

The minimum thread stack size is set by pthreads (16k bytes) so we must
use that value for our minimum.  The stack limit check is also adjusted
to work correctly for 32-bit builds.

LTO can't "see" inside naked functions, but we can mark `nlr_push_tail` as used.

Since "read-exactly" stream refactor, where stream.read(N) will read
exactly N bytes (unless EOF), http_server* examples can't any longer do
client_socket.read(4096) and expect to get full request (it will block
on HTTP/1.1 client). Instead, read request line by line, as the HTTP
protocol requires.

They will fail because the GIL is disabled on the unix build.

Threading support is still very new so stay conservative at this point
and enable threading without the GIL.  This requires users to protect
concurrent access of mutatable Python objects (eg lists) with locks at
the Python level (something you should probably do anyway).  The
advantage is that there is less of a performance hit for non-threaded
code, because the VM does not need to constantly release/acquire the GIL.

In the future the GIL will be made more efficient.  There is also room to
improve the efficiency of non-GIL code by not using mutex's if there is
only one thread active.

Due to the way modern compilers work (allocating space for stack vars once
at tha start of function, and deallocating once on exit from), using
intermediate stack buffer of big size caused blockage of 4K (PATH_MAX)
on stack for the entire duration of MicroPython execution.

E.g. -X heapsize=16Kfoo, -X heapsize=1G will lead to error.

Instead of allocating new array object header again and again, causing
memory fragmentation.

This follows source code/header file organization similar to few other
objects, and intended to be used only is special cases, where efficiency/
simplicity matters.

It's memory fragmentation hazard to allocate 1-char string each time by
calling read() method.

Allocating it for each read/write operation is a memory fragmentation
hazard.

By adjusting parser allocation policy.

Leads to less fragmentation at teh time user code starts.

But disable it for coverage build, as its extra warninsg aren't compatible
with K&R C BerkeleyDB uses.

However, as it requires linking with external libraries, it actually
should be ste on Makefile level.

Namespace packages are natural part of Python3, CPython3 doesn't have such
warning, it made sense only from point of view of Python2 legacy.