Видимо, под «обычным текстом» подразумевается текст преимущественно на каком-то одном языке, чтобы под него можно было выбрать удобную однобайтовую кодировку?)
Мне вот хотелось уметь хорошо хранить строчки, язык которых заранее неизвестен.
Кстати, Википедия говорит, что вот SQL Server 2008 R2 как раз SCSU внутри себя использует, чтобы компактно строчки хранить.
Но в моей задаче (и кажется, во многих практических задачах тоже) такая проблема не может возникнуть, так что у меня не стояло цели её решать. Цель была только в компактности.
Занятно, в тексте дважды используется прилагательное «важный» в местах, где по смыслу явно должно быть «значительный»:
обратите внимание, что эффект каустики менее важен на акуле
(тут подошло бы и «менее выражен»)
Такое ограничение приводит к неверным результатам каустики, если преломление оказывается слишком важным.
Сначала подумал, что это ошибка переводчика, но оказалось, что в оригинале important в обоих случаях. Похоже, ошибся сам автор: кажется, он француз, а во французском слово important действительно имеет второе значение, significant.
Почему нет? Не знаю, как конкретно это API устроено, но не звучит как какая-то непосильная задача. Может ребята из Postuf снова заморочатся и пришлют пулл-реквест для андроид-версии тоже :)
Эксперименты с трёхмерными клавиатурами и дизерингом это, конечно, занятно, но всё-таки очень непрактично. Больше напоминает 3D-демки, нежели постоянно используемый способ ввода.
Вот применение генетических алгоритмов для оптимизации расположения клавиш это уже интересно. Правда, я увидел упоминания файлов layouts.html и layouts-more.html, но не увидел ссылок :) Я бы предложил всё-таки разделить раскладки и оптимизировать их для каждого языка отдельно. Ну и прогонять стоит, конечно, не на паре рандомных статей из вики, а на частотных словарях.
Но все равно кажется, что пользователю будет удобнее ориентироваться на привычной QWERTY, чем на какой-то новой (пусть и оптимальной) раскладке.
А вообще я за предиктивный ввод + то, что выше предложили (с разбивкой на круговые секторы) или что-то наподобие ввода на старых кнопочных мобильники. Зачем оптимизировать расположение кнопок заранее, если можно их подбирать прямо по мере ввода? :)
Конечно, это ещё зависит и от разновидности штрихкода.
Я тут глянул несколько карточек, которые были под рукой, и оказалось, что, например, Магнит и Икеа используют QR-коды версии 1 (21x21 пиксель), Лента и Helix — Code 128 (его ширина может быть разной, у Ленты оказался 12-значный номер, на который хватит 101 пикселя, у Helix — 16-значный, 123 пикселя). В общем, в большинстве случаев дисплейчика вполне должно хватать.
A complete UPC-A is 95 modules wide: 84 modules for the digits (L and R sections) combined with 11 modules for the S (start), M (middle), and E (end) guard patterns.
Ещё можно писать на диск только состояние (какой-то небольшой процент от трафика), а основную часть канала тратить на перекидывание сообщений между нодами.
Есть непоколебимаявера людей в то, что молчание — знак согласия. Мол, если Павел Дуров не отрицает новости про TON, то TON существует.
Я не совсем понимаю, что дало поводы автору объявлять мою статью (ссылкой на которую является слово «вера») подтверждением какой-то там «непоколебимой веры».
В вышеупомянутой статье с обзором тестового клиента (как и в предыдущих статьях на тему TON) — специально для зануд и конспирологов — присутствуют следующие оговорки:
Тогда стал доступен объемный технический документ, который, предположительно, был написан Николаем Дуровым и описывал структуру будущей сети.
...
Повторюсь, официальных подтверждений страницы и всех этих документов со стороны Телеграма не было, но объем этих материалов делает их достаточно правдоподобными.
То есть с начала текущей строки откусывается максимальный префикс, который был до этого определён как слово (и далее это слово выполняется). Если бы мы определили ."Hello как слово — да, оно бы выполнилось вместо ."
Тоже допустимый вариант, но на один символ длиннее :)
Слово ." берёт последующую за ним строку (до закрывающей кавычки) и сразу же выводит его в стандартный вывод. Посмотрите в примере кода (в статье) — там есть использования этой конструкции.
Видимо, под «обычным текстом» подразумевается текст преимущественно на каком-то одном языке, чтобы под него можно было выбрать удобную однобайтовую кодировку?)
Мне вот хотелось уметь хорошо хранить строчки, язык которых заранее неизвестен.
Кстати, Википедия говорит, что вот SQL Server 2008 R2 как раз SCSU внутри себя использует, чтобы компактно строчки хранить.
Да, это верно как для SCSU, так и для моей UTF-C.
Но в моей задаче (и кажется, во многих практических задачах тоже) такая проблема не может возникнуть, так что у меня не стояло цели её решать. Цель была только в компактности.
(тут подошло бы и «менее выражен»)
Сначала подумал, что это ошибка переводчика, но оказалось, что в оригинале important в обоих случаях. Похоже, ошибся сам автор: кажется, он француз, а во французском слово important действительно имеет второе значение, significant.
Почему нет? Не знаю, как конкретно это API устроено, но не звучит как какая-то непосильная задача. Может ребята из Postuf снова заморочатся и пришлют пулл-реквест для андроид-версии тоже :)
Что мешает просто не использовать API андроида для хранения скрытых аккаунтов, чтобы они не отображались в системных настройках?
Там корпус уже почти финализирован, посмотрите фото. Четыре кнопки-стрелки, одна по центру, и одна «назад».
Эксперименты с трёхмерными клавиатурами и дизерингом это, конечно, занятно, но всё-таки очень непрактично. Больше напоминает 3D-демки, нежели постоянно используемый способ ввода.
Вот применение генетических алгоритмов для оптимизации расположения клавиш это уже интересно. Правда, я увидел упоминания файлов layouts.html и layouts-more.html, но не увидел ссылок :) Я бы предложил всё-таки разделить раскладки и оптимизировать их для каждого языка отдельно. Ну и прогонять стоит, конечно, не на паре рандомных статей из вики, а на частотных словарях.
Но все равно кажется, что пользователю будет удобнее ориентироваться на привычной QWERTY, чем на какой-то новой (пусть и оптимальной) раскладке.
А вообще я за предиктивный ввод + то, что выше предложили (с разбивкой на круговые секторы) или что-то наподобие ввода на старых кнопочных мобильники. Зачем оптимизировать расположение кнопок заранее, если можно их подбирать прямо по мере ввода? :)
Конечно, это ещё зависит и от разновидности штрихкода.
Я тут глянул несколько карточек, которые были под рукой, и оказалось, что, например, Магнит и Икеа используют QR-коды версии 1 (21x21 пиксель), Лента и Helix — Code 128 (его ширина может быть разной, у Ленты оказался 12-значный номер, на который хватит 101 пикселя, у Helix — 16-значный, 123 пикселя). В общем, в большинстве случаев дисплейчика вполне должно хватать.
95 монохромных пикселей по идее должно хватать:
(Отсюда)
Ещё можно писать на диск только состояние (какой-то небольшой процент от трафика), а основную часть канала тратить на перекидывание сообщений между нодами.
В оригинальной документации Николая Дурова (это первоисточник, но продираться через него тяжелее) и в доках, которые уже TON Labs написали.
Так разговор-то про разницу между RGB и HSL, а три числа есть и там, и там.
Я не совсем понимаю, что дало поводы автору объявлять мою статью (ссылкой на которую является слово «вера») подтверждением какой-то там «непоколебимой веры».
В вышеупомянутой статье с обзором тестового клиента (как и в предыдущих статьях на тему TON) — специально для зануд и конспирологов — присутствуют следующие оговорки:
...
Видимо, тестовую ноду выключили
Вот как это описывает документация:
То есть с начала текущей строки откусывается максимальный префикс, который был до этого определён как слово (и далее это слово выполняется). Если бы мы определили
."Helloкак слово — да, оно бы выполнилось вместо."Это т.н. префиксное слово (которое обращается к последующему за ним тексту); для таких слов — нет, пробельный символ не нужен.
Тоже допустимый вариант, но на один символ длиннее :)
Слово
."берёт последующую за ним строку (до закрывающей кавычки) и сразу же выводит его в стандартный вывод. Посмотрите в примере кода (в статье) — там есть использования этой конструкции.Согласен, Fift может быть довольно нечитабельным, но вот с лаконичностью у него вроде проблем нет :)
Тестовый. Не думаю, что в основном будут смарт-контракты для раздачи грамов за просто так :)
У меня файл "auto/tl/ton_api.h" сгенерировался на одном из предыдущих этапов сборки, вот этот кусок лога:
Видимо, у вас на этапе tl_generate_common что-то пошло не так.