suspect-devices/circuitpython/py, branch 6.0.0-alpha.3

Merge pull request #3318 from jepler/interrupt-serial-rx

2020-08-26T02:01:33+00:00

supervisor: check for interrupt during rx_chr

mp_obj_print_helper: Handle a ctrl-c that comes in during printing

2020-08-25T16:47:50+00:00

In #2689, hitting ctrl-c during the printing of an object with a lot of sub-objects could cause the screen to stop updating (without showing a KeyboardInterrupt). This makes the printing of such objects acutally interruptable, and also correctly handles the KeyboardInterrupt: ``` >>> l = ["a" * 100] * 200 >>> l ['aaaaaaaaaaaaaaaaaaaaaa...aaaaaaaaaaa', Traceback (most recent call last): File "", line 1, in KeyboardInterrupt: >>> ```

Split pulseio.PWMOut into pwmio

2020-08-18T20:08:33+00:00

This gives us better granularity when implementing new ports because PWMOut is commonly implemented before PulseIn and PulseOut. Fixes #3211

Merge pull request #3295 from tannewt/turn_off_terminalio

2020-08-18T19:10:31+00:00

Turn off terminalio for ja and ko

Calculate the Huffman codebook without MP_QSTRs

2020-08-18T14:21:14+00:00

Turn off terminalio for ja and ko

2020-08-18T00:17:59+00:00

The font is missing many characters and the build needs the space. We can optimize font storage when we get a good font. The serial output will work as usual.

makeqstrdata: don't print "compression incrased length" messages

2020-08-17T01:50:48+00:00

This check as implemented is misleading, because it compares the compressed size in bytes (including the length indication) with the source string length in Unicode code points. For English this is approximately fair, but for Japanese this is quite unfair and produces an excess of "increased length" messages. This message might have existed for one of two reasons: * to alert to an improperly function huffman compression * to call attention to a need for a "string is stored uncompressed" case We know by now that the huffman compression is functioning as designed and effective in general. Just to be on the safe side, I did some back-of-the-envelope estimates. I considered these three replacements for "the true source string size, in bytes": + decompressed_len_utf8 = len(decompressed.encode('utf-8')) + decompressed_len_utf16 = len(decompressed.encode('utf-16be')) + decompressed_len_bitsize = ((1+len(decompressed)) * math.ceil(math.log(1+len(values), 2)) + 7) // 8 The third counts how many bits each character requires (fewer than 128 characters in the source character set = 7, fewer than 256 = 8, fewer than 512 = 9, etc, adding a string-terminating value) and is in some way representative of the best way we would be able to store "uncompressed strings". The Japanese translation (largest as of writing) has just a few strings which increase by this metric. However, the amount of loss due to expansion in those cases is outweighed by the cost of adding 1 bit per string to indicate whether it's compressed or not. For instance, in the BOARD=trinket_m0 TRANSLATION=ja build the loss is 47 bytes over 300 strings. Adding 1 bit to each of 300 strings will cost about 37 bytes, leaving just 5 Thumb instructions to implement the code to check and decode "uncompressed" strings in order to break even.

Don't define SHARPDISPLAY when !DISPLAYIO

2020-08-12T12:39:28+00:00

.. even if FULL_BUILD

sharpmemory: Implement support for Sharp Memory Displays in framebufferio

2020-08-12T12:32:18+00:00

"pop from empty %q"

2020-08-04T23:42:09+00:00

Saves 12 bytes code on trinket m0