2015-05-30 18:11:16 -04:00
|
|
|
"""
|
|
|
|
Process raw qstr file and output qstr data with length, hash and data bytes.
|
|
|
|
|
2020-05-28 08:40:56 -04:00
|
|
|
This script works with Python 2.7, 3.3 and 3.4.
|
2020-05-28 12:29:28 -04:00
|
|
|
|
|
|
|
For documentation about the format of compressed translated strings, see
|
|
|
|
supervisor/shared/translate.h
|
2015-05-30 18:11:16 -04:00
|
|
|
"""
|
|
|
|
|
2014-03-10 03:07:35 -04:00
|
|
|
from __future__ import print_function
|
|
|
|
|
2014-01-21 16:40:13 -05:00
|
|
|
import re
|
2014-03-08 10:03:25 -05:00
|
|
|
import sys
|
2014-01-24 17:22:00 -05:00
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
import collections
|
|
|
|
import gettext
|
2018-08-16 03:27:01 -04:00
|
|
|
import os.path
|
2018-07-31 19:53:54 -04:00
|
|
|
|
2018-08-16 03:27:01 -04:00
|
|
|
py = os.path.dirname(sys.argv[0])
|
|
|
|
top = os.path.dirname(py)
|
|
|
|
|
|
|
|
sys.path.append(os.path.join(top, "tools/huffman"))
|
2018-08-15 21:32:37 -04:00
|
|
|
|
|
|
|
import huffman
|
|
|
|
|
2016-04-14 09:37:04 -04:00
|
|
|
# Python 2/3 compatibility:
|
|
|
|
# - iterating through bytes is different
|
|
|
|
# - codepoint2name lives in a different module
|
2014-01-24 17:22:00 -05:00
|
|
|
import platform
|
|
|
|
if platform.python_version_tuple()[0] == '2':
|
2016-09-02 00:32:47 -04:00
|
|
|
bytes_cons = lambda val, enc=None: bytearray(val)
|
2014-01-24 17:22:00 -05:00
|
|
|
from htmlentitydefs import codepoint2name
|
|
|
|
elif platform.python_version_tuple()[0] == '3':
|
2016-09-02 00:32:47 -04:00
|
|
|
bytes_cons = bytes
|
2014-01-24 17:22:00 -05:00
|
|
|
from html.entities import codepoint2name
|
2016-09-02 00:32:47 -04:00
|
|
|
# end compatibility code
|
|
|
|
|
2014-04-12 22:28:46 -04:00
|
|
|
codepoint2name[ord('-')] = 'hyphen';
|
2014-01-21 16:40:13 -05:00
|
|
|
|
2014-02-15 06:34:50 -05:00
|
|
|
# add some custom names to map characters that aren't in HTML
|
2015-01-11 09:16:24 -05:00
|
|
|
codepoint2name[ord(' ')] = 'space'
|
|
|
|
codepoint2name[ord('\'')] = 'squot'
|
|
|
|
codepoint2name[ord(',')] = 'comma'
|
2014-02-15 06:34:50 -05:00
|
|
|
codepoint2name[ord('.')] = 'dot'
|
2014-02-17 17:06:37 -05:00
|
|
|
codepoint2name[ord(':')] = 'colon'
|
2016-04-13 17:12:39 -04:00
|
|
|
codepoint2name[ord(';')] = 'semicolon'
|
2014-02-17 17:06:37 -05:00
|
|
|
codepoint2name[ord('/')] = 'slash'
|
2014-04-15 07:42:52 -04:00
|
|
|
codepoint2name[ord('%')] = 'percent'
|
2014-04-15 07:50:21 -04:00
|
|
|
codepoint2name[ord('#')] = 'hash'
|
2015-01-11 09:16:24 -05:00
|
|
|
codepoint2name[ord('(')] = 'paren_open'
|
|
|
|
codepoint2name[ord(')')] = 'paren_close'
|
|
|
|
codepoint2name[ord('[')] = 'bracket_open'
|
|
|
|
codepoint2name[ord(']')] = 'bracket_close'
|
2014-04-15 17:03:55 -04:00
|
|
|
codepoint2name[ord('{')] = 'brace_open'
|
|
|
|
codepoint2name[ord('}')] = 'brace_close'
|
2014-04-27 14:23:46 -04:00
|
|
|
codepoint2name[ord('*')] = 'star'
|
2015-01-11 09:16:24 -05:00
|
|
|
codepoint2name[ord('!')] = 'bang'
|
2015-04-01 18:09:24 -04:00
|
|
|
codepoint2name[ord('\\')] = 'backslash'
|
2015-08-30 17:20:38 -04:00
|
|
|
codepoint2name[ord('+')] = 'plus'
|
2016-04-13 17:12:39 -04:00
|
|
|
codepoint2name[ord('$')] = 'dollar'
|
|
|
|
codepoint2name[ord('=')] = 'equals'
|
|
|
|
codepoint2name[ord('?')] = 'question'
|
|
|
|
codepoint2name[ord('@')] = 'at_sign'
|
|
|
|
codepoint2name[ord('^')] = 'caret'
|
|
|
|
codepoint2name[ord('|')] = 'pipe'
|
|
|
|
codepoint2name[ord('~')] = 'tilde'
|
2014-02-15 06:34:50 -05:00
|
|
|
|
2018-08-09 18:58:45 -04:00
|
|
|
C_ESCAPES = {
|
|
|
|
"\a": "\\a",
|
|
|
|
"\b": "\\b",
|
|
|
|
"\f": "\\f",
|
2018-08-10 19:17:03 -04:00
|
|
|
"\n": "\\n",
|
2018-08-09 18:58:45 -04:00
|
|
|
"\r": "\\r",
|
|
|
|
"\t": "\\t",
|
|
|
|
"\v": "\\v",
|
|
|
|
"\'": "\\'",
|
|
|
|
"\"": "\\\""
|
|
|
|
}
|
|
|
|
|
2014-01-21 16:40:13 -05:00
|
|
|
# this must match the equivalent function in qstr.c
|
2015-07-20 07:03:13 -04:00
|
|
|
def compute_hash(qstr, bytes_hash):
|
2014-03-25 11:27:15 -04:00
|
|
|
hash = 5381
|
2016-09-02 00:32:47 -04:00
|
|
|
for b in qstr:
|
|
|
|
hash = (hash * 33) ^ b
|
2014-06-06 16:55:27 -04:00
|
|
|
# Make sure that valid hash is never zero, zero means "hash not computed"
|
2015-07-20 07:03:13 -04:00
|
|
|
return (hash & ((1 << (8 * bytes_hash)) - 1)) or 1
|
2014-01-21 16:40:13 -05:00
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
def translate(translation_file, i18ns):
|
|
|
|
with open(translation_file, "rb") as f:
|
|
|
|
table = gettext.GNUTranslations(f)
|
|
|
|
|
2018-08-09 18:58:45 -04:00
|
|
|
translations = []
|
|
|
|
for original in i18ns:
|
|
|
|
unescaped = original
|
|
|
|
for s in C_ESCAPES:
|
|
|
|
unescaped = unescaped.replace(C_ESCAPES[s], s)
|
2018-08-15 21:32:37 -04:00
|
|
|
translation = table.gettext(unescaped)
|
|
|
|
# Add in carriage returns to work in terminals
|
|
|
|
translation = translation.replace("\n", "\r\n")
|
|
|
|
translations.append((original, translation))
|
2018-08-09 18:58:45 -04:00
|
|
|
return translations
|
2018-07-31 19:53:54 -04:00
|
|
|
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
def frequent_ngrams(corpus, sz, n):
|
|
|
|
return collections.Counter(corpus[i:i+sz] for i in range(len(corpus)-sz)).most_common(n)
|
|
|
|
|
2020-09-02 20:09:23 -04:00
|
|
|
def encode_ngrams(translation, ngrams):
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
if len(ngrams) > 32:
|
|
|
|
start = 0xe000
|
|
|
|
else:
|
|
|
|
start = 0x80
|
|
|
|
for i, g in enumerate(ngrams):
|
|
|
|
translation = translation.replace(g, chr(start + i))
|
|
|
|
return translation
|
|
|
|
|
2020-09-02 20:09:23 -04:00
|
|
|
def decode_ngrams(compressed, ngrams):
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
if len(ngrams) > 32:
|
|
|
|
start, end = 0xe000, 0xf8ff
|
|
|
|
else:
|
2020-09-02 16:52:02 -04:00
|
|
|
start, end = 0x80, 0x9f
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
return "".join(ngrams[ord(c) - start] if (start <= ord(c) <= end) else c for c in compressed)
|
|
|
|
|
2018-08-15 21:32:37 -04:00
|
|
|
def compute_huffman_coding(translations, qstrs, compression_filename):
|
|
|
|
all_strings = [x[1] for x in translations]
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
all_strings_concat = "".join(all_strings)
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
ngrams = [i[0] for i in frequent_ngrams(all_strings_concat, 2, 32)]
|
2020-09-02 20:09:23 -04:00
|
|
|
all_strings_concat = encode_ngrams(all_strings_concat, ngrams)
|
2018-08-15 21:32:37 -04:00
|
|
|
counts = collections.Counter(all_strings_concat)
|
|
|
|
cb = huffman.codebook(counts.items())
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
values = []
|
2018-08-15 21:32:37 -04:00
|
|
|
length_count = {}
|
|
|
|
renumbered = 0
|
|
|
|
last_l = None
|
|
|
|
canonical = {}
|
|
|
|
for ch, code in sorted(cb.items(), key=lambda x: (len(x[1]), x[0])):
|
|
|
|
values.append(ch)
|
|
|
|
l = len(code)
|
|
|
|
if l not in length_count:
|
|
|
|
length_count[l] = 0
|
|
|
|
length_count[l] += 1
|
|
|
|
if last_l:
|
|
|
|
renumbered <<= (l - last_l)
|
|
|
|
canonical[ch] = '{0:0{width}b}'.format(renumbered, width=l)
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
s = C_ESCAPES.get(ch, ch)
|
|
|
|
print("//", ord(ch), s, counts[ch], canonical[ch], renumbered)
|
2018-08-15 21:32:37 -04:00
|
|
|
renumbered += 1
|
|
|
|
last_l = l
|
|
|
|
lengths = bytearray()
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
print("// length count", length_count)
|
2020-09-02 16:52:02 -04:00
|
|
|
print("// bigrams", ngrams)
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
for i in range(1, max(length_count) + 2):
|
2018-08-15 21:32:37 -04:00
|
|
|
lengths.append(length_count.get(i, 0))
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
print("// values", values, "lengths", len(lengths), lengths)
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
ngramdata = [ord(ni) for i in ngrams for ni in i]
|
|
|
|
print("// estimated total memory size", len(lengths) + 2*len(values) + 2 * len(ngramdata) + sum((len(cb[u]) + 7)//8 for u in all_strings_concat))
|
2018-08-15 21:32:37 -04:00
|
|
|
print("//", values, lengths)
|
2019-12-02 15:49:23 -05:00
|
|
|
values_type = "uint16_t" if max(ord(u) for u in values) > 255 else "uint8_t"
|
2020-05-28 08:40:56 -04:00
|
|
|
max_translation_encoded_length = max(len(translation.encode("utf-8")) for original,translation in translations)
|
2018-08-15 21:32:37 -04:00
|
|
|
with open(compression_filename, "w") as f:
|
|
|
|
f.write("const uint8_t lengths[] = {{ {} }};\n".format(", ".join(map(str, lengths))))
|
2019-12-02 15:49:23 -05:00
|
|
|
f.write("const {} values[] = {{ {} }};\n".format(values_type, ", ".join(str(ord(u)) for u in values)))
|
2020-05-28 08:40:56 -04:00
|
|
|
f.write("#define compress_max_length_bits ({})\n".format(max_translation_encoded_length.bit_length()))
|
2020-09-08 20:07:53 -04:00
|
|
|
f.write("const {} bigrams[] = {{ {} }};\n".format(values_type, ", ".join(str(u) for u in ngramdata)))
|
|
|
|
if len(ngrams) > 32:
|
|
|
|
bigram_start = 0xe000
|
|
|
|
else:
|
|
|
|
bigram_start = 0x80
|
|
|
|
bigram_end = bigram_start + len(ngrams) - 1 # End is inclusive
|
|
|
|
f.write("#define bigram_start {}\n".format(bigram_start))
|
|
|
|
f.write("#define bigram_end {}\n".format(bigram_end))
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
return values, lengths, ngrams
|
2018-08-15 21:32:37 -04:00
|
|
|
|
2020-05-28 08:40:56 -04:00
|
|
|
def decompress(encoding_table, encoded, encoded_length_bits):
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
values, lengths, ngrams = encoding_table
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
dec = []
|
2018-08-15 21:32:37 -04:00
|
|
|
this_byte = 0
|
|
|
|
this_bit = 7
|
|
|
|
b = encoded[this_byte]
|
2020-05-28 08:40:56 -04:00
|
|
|
bits = 0
|
|
|
|
for i in range(encoded_length_bits):
|
|
|
|
bits <<= 1
|
|
|
|
if 0x80 & b:
|
|
|
|
bits |= 1
|
|
|
|
|
|
|
|
b <<= 1
|
|
|
|
if this_bit == 0:
|
|
|
|
this_bit = 7
|
|
|
|
this_byte += 1
|
|
|
|
if this_byte < len(encoded):
|
|
|
|
b = encoded[this_byte]
|
|
|
|
else:
|
|
|
|
this_bit -= 1
|
|
|
|
length = bits
|
|
|
|
|
|
|
|
i = 0
|
|
|
|
while i < length:
|
2018-08-15 21:32:37 -04:00
|
|
|
bits = 0
|
|
|
|
bit_length = 0
|
|
|
|
max_code = lengths[0]
|
|
|
|
searched_length = lengths[0]
|
|
|
|
while True:
|
|
|
|
bits <<= 1
|
|
|
|
if 0x80 & b:
|
|
|
|
bits |= 1
|
|
|
|
|
|
|
|
b <<= 1
|
|
|
|
bit_length += 1
|
|
|
|
if this_bit == 0:
|
|
|
|
this_bit = 7
|
|
|
|
this_byte += 1
|
|
|
|
if this_byte < len(encoded):
|
|
|
|
b = encoded[this_byte]
|
|
|
|
else:
|
|
|
|
this_bit -= 1
|
|
|
|
if max_code > 0 and bits < max_code:
|
|
|
|
#print('{0:0{width}b}'.format(bits, width=bit_length))
|
|
|
|
break
|
|
|
|
max_code = (max_code << 1) + lengths[bit_length]
|
|
|
|
searched_length += lengths[bit_length]
|
|
|
|
|
|
|
|
v = values[searched_length + bits - max_code]
|
2020-09-02 20:09:23 -04:00
|
|
|
v = decode_ngrams(v, ngrams)
|
2020-05-28 08:40:56 -04:00
|
|
|
i += len(v.encode('utf-8'))
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
dec.append(v)
|
|
|
|
return ''.join(dec)
|
2018-08-15 21:32:37 -04:00
|
|
|
|
2020-05-28 08:40:56 -04:00
|
|
|
def compress(encoding_table, decompressed, encoded_length_bits, len_translation_encoded):
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
if not isinstance(decompressed, str):
|
2018-08-15 21:32:37 -04:00
|
|
|
raise TypeError()
|
add bigram compression to makeqstrdata
Compress common unicode bigrams by making code points in the range
0x80 - 0xbf (inclusive) represent them. Then, they can be greedily
encoded and the substituted code points handled by the existing Huffman
compression. Normally code points in the range 0x80-0xbf are not used
in Unicode, so we stake our own claim. Using the more arguably correct
"Private Use Area" (PUA) would mean that for scripts that only use
code points under 256 we would use more memory for the "values" table.
bigram means "two letters", and is also sometimes called a "digram".
It's nothing to do with "big RAM". For our purposes, a bigram represents
two successive unicode code points, so for instance in our build on
trinket m0 for english the most frequent are:
['t ', 'e ', 'in', 'd ', ...].
The bigrams are selected based on frequency in the corpus, but the
selection is not necessarily optimal, for these reasons I can think of:
* Suppose the corpus was just "tea" repeated 100 times. The
top bigrams would be "te", and "ea". However,
overlap, "te" could never be used. Thus, some bigrams might actually
waste space
* I _assume_ this has to be why e.g., bigram 0x86 "s " is more
frequent than bigram 0x85 " a" in English for Trinket M0, because
sequences like "can't add" would get the "t " digram and then
be unable to use the " a" digram.
* And generally, if a bigram is frequent then so are its constituents.
Say that "i" and "n" both encode to just 5 or 6 bits, then the huffman
code for "in" had better compress to 10 or fewer bits or it's a net
loss!
* I checked though! "i" is 5 bits, "n" is 6 bits (lucky guess)
but the bigram 0x83 also just 6 bits, so this one is a win of
5 bits for every "it" minus overhead. Yay, this round goes to team
compression.
* On the other hand, the least frequent bigram 0x9d " n" is 10 bits
long and its constituent code points are 4+6 bits so there's no
savings, but there is the cost of the table entry.
* and somehow 0x9f 'an' is never used at all!
With or without accounting for overlaps, there is some optimum number
of bigrams. Adding one more bigram uses at least 2 bytes (for the
entry in the bigram table; 4 bytes if code points >255 are in the
source text) and also needs a slot in the Huffman dictionary, so
adding bigrams beyond the optimim number makes compression worse again.
If it's an improvement, the fact that it's not guaranteed optimal
doesn't seem to matter too much. It just leaves a little more fruit
for the next sweep to pick up. Perhaps try adding the most frequent
bigram not yet present, until it doesn't improve compression overall.
Right now, de_DE is again the "fullest" build on trinket_m0. (It's
reclaimed that spot from the ja translation somehow) This change saves
104 bytes there, increasing free space about 6.8%. In the larger
(but not critically full) pyportal build it saves 324 bytes.
The specific number of bigrams used (32) was chosen as it is the max
number that fit within the 0x80..0xbf range. Larger tables would
require the use of 16 bit code points in the de_DE build, losing savings
overall.
(Side note: The most frequent letters in English have been said
to be: ETA OIN SHRDLU; but we have UAC EIL MOPRST in our corpus)
2020-09-01 18:12:22 -04:00
|
|
|
values, lengths, ngrams = encoding_table
|
2020-09-02 20:09:23 -04:00
|
|
|
decompressed = encode_ngrams(decompressed, ngrams)
|
translation: Compress as unicode, not bytes
By treating each unicode code-point as a single entity for huffman
compression, the overall compression rate can be somewhat improved
without changing the algorithm. On the decompression side, when
compressed values above 127 are encountered, they need to be
converted from a 16-bit Unicode code point into a UTF-8 byte
sequence.
Doing this returns approximately 1.5kB of flash storage with the
zh_Latn_pinyin translation. (292 -> 1768 bytes remaining in my build
of trinket_m0)
Other "more ASCII" translations benefit less, and in fact
zh_Latn_pinyin is no longer the most constrained translation!
(de_DE 1156 -> 1384 bytes free in flash, I didn't check others
before pushing for CI)
English is slightly pessimized, 2840 -> 2788 bytes, probably mostly
because the "values" array was changed from uint8_t to uint16_t,
which is strictly not required for an all-ASCII translation. This
could probably be avoided in this case, but as English is not the
most constrained translation it doesn't really matter.
Testing performed: built for feather nRF52840 express and trinket m0
in English and zh_Latn_pinyin; ran and verified the localized
messages such as
Àn xià rènhé jiàn jìnrù REPL. Shǐyòng CTRL-D chóngxīn jiāzài.
and
Press any key to enter the REPL. Use CTRL-D to reload.
were properly displayed.
2019-12-02 09:41:03 -05:00
|
|
|
enc = bytearray(len(decompressed) * 3)
|
2018-08-15 21:32:37 -04:00
|
|
|
#print(decompressed)
|
|
|
|
#print(lengths)
|
|
|
|
current_bit = 7
|
|
|
|
current_byte = 0
|
2020-05-28 08:40:56 -04:00
|
|
|
|
|
|
|
code = len_translation_encoded
|
|
|
|
bits = encoded_length_bits+1
|
|
|
|
for i in range(bits - 1, 0, -1):
|
|
|
|
if len_translation_encoded & (1 << (i - 1)):
|
|
|
|
enc[current_byte] |= 1 << current_bit
|
|
|
|
if current_bit == 0:
|
|
|
|
current_bit = 7
|
|
|
|
#print("packed {0:0{width}b}".format(enc[current_byte], width=8))
|
|
|
|
current_byte += 1
|
|
|
|
else:
|
|
|
|
current_bit -= 1
|
|
|
|
|
2018-08-15 21:32:37 -04:00
|
|
|
for c in decompressed:
|
|
|
|
#print()
|
|
|
|
#print("char", c, values.index(c))
|
|
|
|
start = 0
|
|
|
|
end = lengths[0]
|
|
|
|
bits = 1
|
|
|
|
compressed = None
|
|
|
|
code = 0
|
|
|
|
while compressed is None:
|
|
|
|
s = start
|
|
|
|
e = end
|
|
|
|
#print("{0:0{width}b}".format(code, width=bits))
|
|
|
|
# Binary search!
|
|
|
|
while e > s:
|
|
|
|
midpoint = (s + e) // 2
|
|
|
|
#print(s, e, midpoint)
|
|
|
|
if values[midpoint] == c:
|
|
|
|
compressed = code + (midpoint - start)
|
|
|
|
#print("found {0:0{width}b}".format(compressed, width=bits))
|
|
|
|
break
|
|
|
|
elif c < values[midpoint]:
|
|
|
|
e = midpoint
|
|
|
|
else:
|
|
|
|
s = midpoint + 1
|
|
|
|
code += end - start
|
|
|
|
code <<= 1
|
|
|
|
start = end
|
|
|
|
end += lengths[bits]
|
|
|
|
bits += 1
|
|
|
|
#print("next bit", bits)
|
|
|
|
|
|
|
|
for i in range(bits - 1, 0, -1):
|
|
|
|
if compressed & (1 << (i - 1)):
|
|
|
|
enc[current_byte] |= 1 << current_bit
|
|
|
|
if current_bit == 0:
|
|
|
|
current_bit = 7
|
|
|
|
#print("packed {0:0{width}b}".format(enc[current_byte], width=8))
|
|
|
|
current_byte += 1
|
|
|
|
else:
|
|
|
|
current_bit -= 1
|
|
|
|
if current_bit != 7:
|
|
|
|
current_byte += 1
|
|
|
|
return enc[:current_byte]
|
|
|
|
|
2016-01-31 07:59:59 -05:00
|
|
|
def qstr_escape(qst):
|
2016-04-13 17:12:39 -04:00
|
|
|
def esc_char(m):
|
|
|
|
c = ord(m.group(0))
|
|
|
|
try:
|
|
|
|
name = codepoint2name[c]
|
|
|
|
except KeyError:
|
|
|
|
name = '0x%02x' % c
|
|
|
|
return "_" + name + '_'
|
|
|
|
return re.sub(r'[^A-Za-z0-9_]', esc_char, qst)
|
2016-01-31 07:59:59 -05:00
|
|
|
|
|
|
|
def parse_input_headers(infiles):
|
2014-01-21 16:40:13 -05:00
|
|
|
# read the qstrs in from the input files
|
2015-01-11 12:52:45 -05:00
|
|
|
qcfgs = {}
|
2014-01-23 17:22:00 -05:00
|
|
|
qstrs = {}
|
2018-07-31 19:53:54 -04:00
|
|
|
i18ns = set()
|
2014-01-21 16:40:13 -05:00
|
|
|
for infile in infiles:
|
|
|
|
with open(infile, 'rt') as f:
|
|
|
|
for line in f:
|
2015-01-11 12:52:45 -05:00
|
|
|
line = line.strip()
|
|
|
|
|
|
|
|
# is this a config line?
|
|
|
|
match = re.match(r'^QCFG\((.+), (.+)\)', line)
|
|
|
|
if match:
|
|
|
|
value = match.group(2)
|
|
|
|
if value[0] == '(' and value[-1] == ')':
|
|
|
|
# strip parenthesis from config value
|
|
|
|
value = value[1:-1]
|
|
|
|
qcfgs[match.group(1)] = value
|
|
|
|
continue
|
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
|
|
|
|
match = re.match(r'^TRANSLATE\("(.*)"\)$', line)
|
|
|
|
if match:
|
|
|
|
i18ns.add(match.group(1))
|
|
|
|
continue
|
|
|
|
|
2014-05-02 15:10:47 -04:00
|
|
|
# is this a QSTR line?
|
2015-01-11 12:52:45 -05:00
|
|
|
match = re.match(r'^Q\((.*)\)$', line)
|
2014-05-02 15:10:47 -04:00
|
|
|
if not match:
|
2014-04-13 08:16:51 -04:00
|
|
|
continue
|
2014-01-21 16:40:13 -05:00
|
|
|
|
|
|
|
# get the qstr value
|
|
|
|
qstr = match.group(1)
|
2016-04-14 10:22:36 -04:00
|
|
|
|
|
|
|
# special case to specify control characters
|
|
|
|
if qstr == '\\n':
|
|
|
|
qstr = '\n'
|
|
|
|
|
|
|
|
# work out the corresponding qstr name
|
2016-01-31 07:59:59 -05:00
|
|
|
ident = qstr_escape(qstr)
|
2014-01-21 16:40:13 -05:00
|
|
|
|
|
|
|
# don't add duplicates
|
2014-01-23 17:22:00 -05:00
|
|
|
if ident in qstrs:
|
2014-01-21 16:40:13 -05:00
|
|
|
continue
|
|
|
|
|
2014-01-24 17:22:00 -05:00
|
|
|
# add the qstr to the list, with order number to retain original order in file
|
2017-10-21 04:06:32 -04:00
|
|
|
order = len(qstrs)
|
|
|
|
# but put special method names like __add__ at the top of list, so
|
|
|
|
# that their id's fit into a byte
|
|
|
|
if ident == "":
|
|
|
|
# Sort empty qstr above all still
|
|
|
|
order = -200000
|
2018-05-10 09:10:46 -04:00
|
|
|
elif ident == "__dir__":
|
|
|
|
# Put __dir__ after empty qstr for builtin dir() to work
|
|
|
|
order = -190000
|
2017-10-21 04:06:32 -04:00
|
|
|
elif ident.startswith("__"):
|
|
|
|
order -= 100000
|
|
|
|
qstrs[ident] = (order, ident, qstr)
|
2014-01-21 16:40:13 -05:00
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
if not qcfgs and qstrs:
|
2015-10-11 04:09:57 -04:00
|
|
|
sys.stderr.write("ERROR: Empty preprocessor output - check for errors above\n")
|
|
|
|
sys.exit(1)
|
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
return qcfgs, qstrs, i18ns
|
2016-01-31 07:59:59 -05:00
|
|
|
|
|
|
|
def make_bytes(cfg_bytes_len, cfg_bytes_hash, qstr):
|
2016-09-02 00:32:47 -04:00
|
|
|
qbytes = bytes_cons(qstr, 'utf8')
|
|
|
|
qlen = len(qbytes)
|
|
|
|
qhash = compute_hash(qbytes, cfg_bytes_hash)
|
2016-05-23 10:18:55 -04:00
|
|
|
if all(32 <= ord(c) <= 126 and c != '\\' and c != '"' for c in qstr):
|
2016-04-14 09:20:25 -04:00
|
|
|
# qstr is all printable ASCII so render it as-is (for easier debugging)
|
|
|
|
qdata = qstr
|
|
|
|
else:
|
|
|
|
# qstr contains non-printable codes so render entire thing as hex pairs
|
2016-09-02 00:32:47 -04:00
|
|
|
qdata = ''.join(('\\x%02x' % b) for b in qbytes)
|
2016-01-31 07:59:59 -05:00
|
|
|
if qlen >= (1 << (8 * cfg_bytes_len)):
|
|
|
|
print('qstr is too long:', qstr)
|
|
|
|
assert False
|
|
|
|
qlen_str = ('\\x%02x' * cfg_bytes_len) % tuple(((qlen >> (8 * i)) & 0xff) for i in range(cfg_bytes_len))
|
|
|
|
qhash_str = ('\\x%02x' * cfg_bytes_hash) % tuple(((qhash >> (8 * i)) & 0xff) for i in range(cfg_bytes_hash))
|
|
|
|
return '(const byte*)"%s%s" "%s"' % (qhash_str, qlen_str, qdata)
|
|
|
|
|
2018-08-15 21:32:37 -04:00
|
|
|
def print_qstr_data(encoding_table, qcfgs, qstrs, i18ns):
|
2015-01-11 17:27:30 -05:00
|
|
|
# get config variables
|
|
|
|
cfg_bytes_len = int(qcfgs['BYTES_IN_LEN'])
|
2015-07-20 07:03:13 -04:00
|
|
|
cfg_bytes_hash = int(qcfgs['BYTES_IN_HASH'])
|
2015-01-11 17:27:30 -05:00
|
|
|
|
2015-07-31 07:57:36 -04:00
|
|
|
# print out the starter of the generated C header file
|
2014-01-21 16:40:13 -05:00
|
|
|
print('// This file was automatically generated by makeqstrdata.py')
|
2014-01-21 18:28:27 -05:00
|
|
|
print('')
|
2015-01-11 17:27:30 -05:00
|
|
|
|
2015-01-11 12:52:45 -05:00
|
|
|
# add NULL qstr with no hash or data
|
2015-07-20 07:03:13 -04:00
|
|
|
print('QDEF(MP_QSTR_NULL, (const byte*)"%s%s" "")' % ('\\x00' * cfg_bytes_hash, '\\x00' * cfg_bytes_len))
|
2015-01-11 17:27:30 -05:00
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
total_qstr_size = 0
|
2018-08-15 21:32:37 -04:00
|
|
|
total_qstr_compressed_size = 0
|
2015-01-11 17:27:30 -05:00
|
|
|
# go through each qstr and print it out
|
2014-04-11 13:36:08 -04:00
|
|
|
for order, ident, qstr in sorted(qstrs.values(), key=lambda x: x[0]):
|
2016-01-31 07:59:59 -05:00
|
|
|
qbytes = make_bytes(cfg_bytes_len, cfg_bytes_hash, qstr)
|
|
|
|
print('QDEF(MP_QSTR_%s, %s)' % (ident, qbytes))
|
2018-07-31 19:53:54 -04:00
|
|
|
total_qstr_size += len(qstr)
|
|
|
|
|
|
|
|
total_text_size = 0
|
2018-08-15 21:32:37 -04:00
|
|
|
total_text_compressed_size = 0
|
2020-05-28 08:40:56 -04:00
|
|
|
max_translation_encoded_length = max(len(translation.encode("utf-8")) for original, translation in i18ns)
|
|
|
|
encoded_length_bits = max_translation_encoded_length.bit_length()
|
2018-07-31 19:53:54 -04:00
|
|
|
for original, translation in i18ns:
|
2018-08-15 21:32:37 -04:00
|
|
|
translation_encoded = translation.encode("utf-8")
|
2020-05-28 08:40:56 -04:00
|
|
|
compressed = compress(encoding_table, translation, encoded_length_bits, len(translation_encoded))
|
2018-08-15 21:32:37 -04:00
|
|
|
total_text_compressed_size += len(compressed)
|
2020-05-28 08:40:56 -04:00
|
|
|
decompressed = decompress(encoding_table, compressed, encoded_length_bits)
|
|
|
|
assert decompressed == translation
|
2018-08-15 21:32:37 -04:00
|
|
|
for c in C_ESCAPES:
|
2018-11-09 19:41:08 -05:00
|
|
|
decompressed = decompressed.replace(c, C_ESCAPES[c])
|
2020-05-28 08:40:56 -04:00
|
|
|
print("TRANSLATION(\"{}\", {}) // {}".format(original, ", ".join(["{:d}".format(x) for x in compressed]), decompressed))
|
2018-08-15 21:32:37 -04:00
|
|
|
total_text_size += len(translation.encode("utf-8"))
|
2016-01-31 07:59:59 -05:00
|
|
|
|
2018-07-31 19:53:54 -04:00
|
|
|
print()
|
|
|
|
print("// {} bytes worth of qstr".format(total_qstr_size))
|
|
|
|
print("// {} bytes worth of translations".format(total_text_size))
|
2018-08-15 21:32:37 -04:00
|
|
|
print("// {} bytes worth of translations compressed".format(total_text_compressed_size))
|
|
|
|
print("// {} bytes saved".format(total_text_size - total_text_compressed_size))
|
2018-07-31 19:53:54 -04:00
|
|
|
|
|
|
|
def print_qstr_enums(qstrs):
|
|
|
|
# print out the starter of the generated C header file
|
|
|
|
print('// This file was automatically generated by makeqstrdata.py')
|
|
|
|
print('')
|
|
|
|
|
|
|
|
# add NULL qstr with no hash or data
|
|
|
|
print('QENUM(MP_QSTR_NULL)')
|
|
|
|
|
|
|
|
# go through each qstr and print it out
|
|
|
|
for order, ident, qstr in sorted(qstrs.values(), key=lambda x: x[0]):
|
|
|
|
print('QENUM(MP_QSTR_%s)' % (ident,))
|
2014-01-21 16:40:13 -05:00
|
|
|
|
|
|
|
if __name__ == "__main__":
|
2018-07-31 19:53:54 -04:00
|
|
|
import argparse
|
|
|
|
|
|
|
|
parser = argparse.ArgumentParser(description='Process QSTR definitions into headers for compilation')
|
|
|
|
parser.add_argument('infiles', metavar='N', type=str, nargs='+',
|
|
|
|
help='an integer for the accumulator')
|
|
|
|
parser.add_argument('--translation', default=None, type=str,
|
|
|
|
help='translations for i18n() items')
|
2018-08-15 21:32:37 -04:00
|
|
|
parser.add_argument('--compression_filename', default=None, type=str,
|
|
|
|
help='header for compression info')
|
2018-07-31 19:53:54 -04:00
|
|
|
|
|
|
|
args = parser.parse_args()
|
|
|
|
|
|
|
|
qcfgs, qstrs, i18ns = parse_input_headers(args.infiles)
|
|
|
|
if args.translation:
|
2020-05-28 08:40:56 -04:00
|
|
|
i18ns = sorted(i18ns)
|
2018-07-31 19:53:54 -04:00
|
|
|
translations = translate(args.translation, i18ns)
|
2018-08-15 21:32:37 -04:00
|
|
|
encoding_table = compute_huffman_coding(translations, qstrs, args.compression_filename)
|
|
|
|
print_qstr_data(encoding_table, qcfgs, qstrs, translations)
|
2018-07-31 19:53:54 -04:00
|
|
|
else:
|
|
|
|
print_qstr_enums(qstrs)
|