Но в моей задаче (и кажется, во многих практических задачах тоже) такая проблема не может возникнуть, так что у меня не стояло цели её решать. Цель была только в компактности.
Занятно, в тексте дважды используется прилагательное «важный» в местах, где по смыслу явно должно быть «значительный»:
обратите внимание, что эффект каустики менее важен на акуле
(тут подошло бы и «менее выражен»)
Такое ограничение приводит к неверным результатам каустики, если преломление оказывается слишком важным.
Сначала подумал, что это ошибка переводчика, но оказалось, что в оригинале 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 как слово — да, оно бы выполнилось вместо ."
Тоже допустимый вариант, но на один символ длиннее :)
Слово ." берёт последующую за ним строку (до закрывающей кавычки) и сразу же выводит его в стандартный вывод. Посмотрите в примере кода (в статье) — там есть использования этой конструкции.
Воркчейны решают другую задачу: возможность иметь несколько независимых блокчейнов с разными конфигурациями.
Проблема масштабирования решается следующим уровнем: дроблением воркчейнов на шардчейны. Каждый шардчейн ответственнен за хранения состояния своего диапазона аккаунтов (подобно шардированию в обычных БД).
Да, это верно как для 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 что-то пошло не так.
Проблема масштабирования решается следующим уровнем: дроблением воркчейнов на шардчейны. Каждый шардчейн ответственнен за хранения состояния своего диапазона аккаунтов (подобно шардированию в обычных БД).