It was intended that the `f.load_glyphs` line was fast and did most of
the work. However, it actually didn't, because it's necessary to pass
in a code point by number, not by string.
Additionally, a little light layer violation is needed to make the check
for missing characters fast. This used to be less important, as no
fonts had missing characters. However, it would take an appreciable
length of time on the Korean translation when failing to find hundreds
of different code points.
Testing performed: built
build-circuitplayground_express_displayio/autogen_display_resources.c with ko
translation before and after change. verified the file content was identical.
Time went from about 7s on my machine to way under 1 second.
By having an order-only dependency on the directory itself, the directory
is sure to be created before the rule to create a .mo file is.
This fixes a low-freqency error on github actions such as
> msgfmt: error while opening "build/genhdr/en_US.mo" for writing: No such file or directory
Apparently sometimes, a proper "frame info" block is not found after
a "sync word". Keep looking for one as needed, instead of giving up
after one try.
This was one reason that the "bartlebeats" mp3s would not play.
In conversion I missed these arguments were being passed, but noticed
it when an implausible value for audio_channel was sent to mp3's
reset_buffer method.
It's not clear whether there was any negative impact to this, but it
should be fixed!
These s16-s21 registers are used by gcc so need to be saved. Future
versions of gcc (beyond v9.1.0), or other compilers, may eventually need
additional registers saved/restored.
See issue #4844.
Recent versions of gcc perform optimisations which can lead to the
following code from the MP_NLR_JUMP_HEAD macro being omitted:
top->ret_val = val; \
MP_NLR_RESTORE_PYSTACK(top); \
*_top_ptr = top->prev; \
This is noticeable (at least) in the unix coverage on x86-64 built with gcc
9.1.0. This is because the nlr_jump function is marked as no-return, so
gcc deduces that the above code has no effect.
Adding MP_UNREACHABLE tells the compiler that the asm code may branch
elsewhere, and so it cannot optimise away the code.
There were several problems with the way this worked -- the read_count
approach was too complicated and I made a mistake "simplifying" it from
WaveFile. And when the right channel was returned, it was off by 1 byte,
making it into static.
Instead, directly track which is the "other" channel that has data
available, and by using the right data type make the "+ channel"
arithmetic give the right result.
This requires a double cast (int16_t*)(void*) due to an alignment warning;
the alignment is now ensured manually, but the compiler doesn't make the
necessary inference that the low address bit must be clear.
