The idea is that it should be possible to pass any additional params for
experimentation without need to patch sources (and without need to deviate
from or repeat baseline options).
Some people want to enable even more warnings. Let them do it without putting
burden on everyone. Some people vice versa think that current settings should
be relaxed. In this regard, -Werror is the most problematic, it disallows to
use #warning directive, and disallows to pass configuration settings on make
command lines. Again, until decided how to deal with these globally, allow to
work around these problems locally.
Both "bound" (like, length known) and "unbound" (length unknown) are tested.
All of list, tuple, bytes, bytesarray offer approximately the same
performance, with "unbound" case being 30 times slower.
As we are building with -nostdlib gcc features like the stack protector
will fail linking, because the failure handlers are in gcc's internal
libs. Such features are implicitly disabled during compilation when
-nostdlib is used in CFLAGS too.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
-nostdlib is the correct option, gcc recognizes the double dash version
when in link-only mode, but not when compiling.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
This adds a hook to get/set pyb_uart_global_debug from Python, using
pyb.repl_uart(). You can set it to an arbitrary UART object, and then
the REPL (in and out) is repeated on this UART object (as well as on USB
CDC).
Ultimately, this will be replaced with a proper Pythonic interface to
set sys.stdin and sys.stdout.
char can be signedness, and using signedness types is dangerous - it can
lead to negative offsets when doing table lookups. We apparently should just
ban char usage.
This will allow roughly the same behavior as Python3 for non-ASCII strings,
for example, print("<phrase in non-Latin script>".split()) will print list
of words, not weird hex dump (like Python2 behaves). (Of course, that it
will print list of words, if there're "words" in that phrase at all, separated
by ASCII-compatible whitespace; that surely won't apply to every human
language in existence).
Functionality we provide in builtin io module is fairly minimal. Some
code, including CPython stdlib, depends on more functionality. So, there's
a choice to either implement it in C, or move it _io, and let implement other
functionality in Python. 2nd choice is pursued. This setup matches CPython
too (_io is builtin, io is Python-level).
