| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous to this patch the printing mechanism was a bit of a tangled
mess. This patch attempts to consolidate printing into one interface.
All (non-debug) printing now uses the mp_print* family of functions,
mainly mp_printf. All these functions take an mp_print_t structure as
their first argument, and this structure defines the printing backend
through the "print_strn" function of said structure.
Printing from the uPy core can reach the platform-defined print code via
two paths: either through mp_sys_stdout_obj (defined pert port) in
conjunction with mp_stream_write; or through the mp_plat_print structure
which uses the MP_PLAT_PRINT_STRN macro to define how string are printed
on the platform. The former is only used when MICROPY_PY_IO is defined.
With this new scheme printing is generally more efficient (less layers
to go through, less arguments to pass), and, given an mp_print_t*
structure, one can call mp_print_str for efficiency instead of
mp_printf("%s", ...). Code size is also reduced by around 200 bytes on
Thumb2 archs.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
splitlines() occurs ~179 times in CPython3 standard library, so was
deemed worthy to implement. The method has subtle semantic differences
from just .split("\n"). It is also defined as working for any end-of-line
combination, but this is currently not implemented - it works only with
LF line-endings (which should be OK for text strings on any platforms,
but not OK for bytes).
|
| | |
|
| |
|
|
|
|
|
|
| |
There was really weird warning (promoted to error) when building Windows
port. Exact cause is still unknown, but it uncovered another issue:
8-bit and unicode str_make_new implementations should be mutually exclusive,
and not built at the same time. What we had is that bytes_decode() pulled
8-bit str_make_new() even for unicode build.
|
| | |
|
| |
|
|
| |
Addresses issue #1022.
|
| |
|
|
| |
This should pretty much resolve issue #50.
|
| |
|
|
|
| |
The JSON specs are relatively flexible and allow us to use one function
to print strings, be they ascii, bytes or utf-8 encoded.
|
| |
|
|
| |
Part of code cleanup, working towards resolving issue #50.
|
| |
|
|
| |
Part of code cleanup, working towards resolving issue #50.
|
| |
|
|
| |
Addressing issue #50, still some way to go yet.
|
| |
|
|
|
| |
This allows to make strings longer than 64k. It doesn't use any more
RAM with current GC because a str object still fits in a GC block.
|
| |
|
|
| |
See discussion in issue #50.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Reorder interning logic in mp_obj_new_str, to be more efficient.
str_new is globally accessible, so should be prefixed with mp_obj_.
|
| |
|
|
|
| |
Done in generalized manner, allowing any stream class to be specified as
working with bytes.
|
| |
|
|
|
|
|
| |
Blanket wide to all .c and .h files. Some files originating from ST are
difficult to deal with (license wise) so it was left out of those.
Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
|
| | |
|
|
|
Similar to tuples, lists, dicts. Statically allocated strings don't have hash
computed.
|
