The 'S' typecode is a uPy extension so it should be grouped with the other
extension (namely 'O' typecode). Testing 'S' needs uctypes which is an
extmod module and not always available, so this test is made optional and
will only be run on ports that have (u)struct and uctypes. Otherwise it
will be silently skipped.
This is so that the filename of the test doesn't clash with the module name
itself (being "websocket"), and lead to potential problems executing the
test.
MICROPY_LONGINT_IMPL_LONGLONG doesn't have overflow detection, so just
parsing a large number won't give an error, we need to print it out
to check that the whole number was parsed.
These short unit tests test the base uPy methods as well as parts of the
websocket protocol, as implemented by uPy.
@dpgeorge converted the original socket based tests by @hosaka to ones
that only require io.BytesIO.
This test just tests that the basic functions/methods can be called with
the appropriate arguments. There is no real test of underlying
functionality.
Thanks to @hosaka for the initial implementation of this test.
I.e. they don't run successfully with MICROPY_LONGINT_IMPL_NONE
and MICROPY_LONGINT_IMPL_LONGLONG (the problem is that they generate
different output than CPython, TODO to fix that).
The use of large literal numbers is a big no-no when it comes to writing
programs which work with different int representations. Also, some checks
are pretty adhoc (e.g using struct module to check for 64-bitness). This
change bases entire detection on sys.maxsize and integer operarions, and
thus more correct, even if longer.
Note that this change doesn't mean that any of these tests can pass with
anything but MPZ - even despite checking for various int representations,
the tests aren't written to be portable among them.
Tests which don't work with small ints are suffixed with _intbig.py. Some
of these may still work with long long ints and need to be reclassified
later.
Previous to this patch any non-interned str/bytes objects would create a
special parse node that held a copy of the str/bytes data. Then in the
compiler this data would be turned into a str/bytes object. This actually
lead to 2 copies of the data, one in the parse node and one in the object.
The parse node's copy of the data would be freed at the end of the compile
stage but nevertheless it meant that the peak memory usage of the
parse/compile stage was higher than it needed to be (by an amount equal to
the number of bytes in all the non-interned str/bytes objects).
This patch changes the behaviour so that str/bytes objects are created
directly in the parser and the object stored in a const-object parse node
(which already exists for bignum, float and complex const objects). This
reduces peak RAM usage of the parse/compile stage, simplifies the parser
and compiler, and reduces code size by about 170 bytes on Thumb2 archs,
and by about 300 bytes on Xtensa archs.
These tests are intended to fail, as they provide a programatic record of
differences between uPy and CPython. They also contain a special comment
at the start of the file which has meta-data describing the difference,
including known causes and known workarounds.
Depending on the thread scheduler, a busy-wait loop can hog the CPU and
make the tests very slow. So convert such loops to loops that have an
explicit sleep, allowing the worker threads to do their job.
This allows using the test runner for other scenarios than just
testing uPy itself.
The principle of comparing either to CPython or else to a .exp
file is really handy but to be able to test custom modules not
built into micropython.exe one needs to be able to specify the
module search path a.k.a MICROPYPATH.
This patch implements support for class methods __delattr__ and __setattr__
for customising attribute access. It is controlled by the config option
MICROPY_PY_DELATTR_SETATTR and is disabled by default.
A few tests still fail on PYBLITE, and that's due to differences in the
available peripheral block numbers on the different MCUs (eg I2C(2)
exists on one, but it's I2C(3) on the other).
This new function controls what happens on a hard-fault:
- debugging disabled: board will do a reset
- debugging enabled: board will print registers and stack and flash LEDs
The default is disabled, ie to do a reset. This is different to previous
behaviour which flashed the LEDs and waited indefinitely.
machine.time_pulse_us() is intended to provide very fine timing, including
while working with signal bursts, where each transition is tracked in row.
Throwing and handling an exception may take too much time and "signal loss".
So instead, in case of a timeout, just return negative value. Cases of
timeout while waiting for initial signal stabilization, and during actual
timing, are recognized.
The documentation is updated accordingly, and rewritten somewhat to clarify
the function behavior.
Updated modbuiltin.c to add conditional support for 3-arg calls to
pow() using MICROPY_PY_BUILTINS_POW3 config parameter. Added support in
objint_mpz.c for for optimised implementation.
