А вы точно читали статью? Метр был изначально опеределен не через меридиан, а через длину маятника, и только после этого - через меридиан. И получилось круглое число, поэтому и вопрос.
Интересно, ещё, что метр, определенный через маятник, оказался почти равен одной 40000000 доле меридиана (следующее определение). Как бы объяснить это круглое число?
У меня что-то даже верстка обложки вызывает сомнения в качестве книги. Как будто в Ворде слова раскидали по странице, шрифт ткнули, и готово, в продакшн!
Консульства без проблем возвращали их законным владельцам при обращении
С лета 2023 больше не возвращают. Видимо, желающих стало слишком много, а сотрудников - слишком мало. Вот их ответ на мой запрос (сентябрь 2023):
Обращаем Ваше внимание, что консульский отдел прекратил выдачу ВУ. Все ВУ, которые поступят или уже поступили к нам, будут отправлены в Главное управление по обеспечению безопасности дорожного движения (г. Москва, ул. Мясницкая, д. 3). Дальнейшую судьбу этих документов мы не отслеживаем.
Спасибо за коментарий! Ну вроде бы похожий функционал еще обеспечивает Qt for MCUs со стандартными для qt сигналами и слотами. Но оно требуют довольно толстых микроконтроллеров, ориентировано в основном на UI, и навязывает структуру проекта, системы сборки и т.п. Я сам не пользовался.
В клавиатурах обычно больше кнопок, чем остается у МК на работу с ней, так что применяются разные техники мультиплексирования, как в статье. Как в таких случаях реализовывать прерывания?
Извините, но у вас какая-то дурацкая архитектура вышла. Очереди в принципе нужны, чтобы организовать FIFO-обработку, а блокирующие очереди еще для того, чтобы один поток ждал, пока от другого что-то придет. Было бы логично, если бы таска кнопок выполняла свою низкоуровневю логику и выдавала в очередь события типа "кнопка 1 нажата", "повтороное нажатие кнопки 5". У вас же каждый тик таска выплевывает в очередь внутренне состояние всех кнопок, и в итоге от очереди нет никакого толку; порядок элементов в очереди не важен, и таска-читатель не ждет событий, т.к. они все равно идут непрерывным потоком. Код в главной такске вышел такой же, как если бы состояние кнопок хранилось в массиве, к которому имеют доступ обе таски (только потокобезопасный).
Поэтому тут и от двух тасок нет особой пользы, проще и дешевле было бы в главной таске вызывать фцнкцию вроде "update_buttons_states()" и дальше делать то, что и сейчас. Не было бы накладных расходов на переключание между тасками и на копирование памяти в очередь и из нее.
Второй случай. Ситуация становится сложнее, если вы хотите, чтобы было сразу несколько задач-получателей. Курниц называет такую задачу нетривиальной. Мне пришлось решать эту проблему самостоятельно, поэтому поднимаю ее здесь. Решение, которое предлагает интернет в таком случае - совместное использование функций синхронизации групп событий и просмотр элемента очереди без удаления.
Это выглядит как неправильный выбор инструмента и попытка натянуть его на задачу. Очередь с несколькими слушателями работает, когда слушатели равноправны и нужно доставить элемент только одному. Традиционный пример - пул потоков-воркеров, которые берут задачи из очереди. Если одно событие должно уходить нескольким слушателям, и они еще и выбирают, какие кому нужны, то тогда лучше взять другой паттерн, publish-subscribe там, или observer. Или просто сделать состояние кнопок доступным на чтение всем желающим.
И да, это все уже изобретено до нас, например, есть бибилотека ETL (embedded template library), там есть и observer, и message router, и миллион других готовых велосипедов.
Возможно, выйдет меньше, если какие-то бинарники заменить на BusyBox. Или вообще строить всё не из alpine, а из busybox. Правда, тогда с установкой туда пакетов придется повозиться.
А вы точно читали статью? Метр был изначально опеределен не через меридиан, а через длину маятника, и только после этого - через меридиан. И получилось круглое число, поэтому и вопрос.
Ну не знаю... До этого лье и миля тоже были определены через меридиан, так что это определение не с потолка взято.
Интересно, ещё, что метр, определенный через маятник, оказался почти равен одной 40000000 доле меридиана (следующее определение). Как бы объяснить это круглое число?
У меня что-то даже верстка обложки вызывает сомнения в качестве книги. Как будто в Ворде слова раскидали по странице, шрифт ткнули, и готово, в продакшн!
А если с кем-то голосом поговорить, не записывая на диктофон - это тоже будет халатность, да ещё и преднамеренная?
Дак он же правильно подсовывает, ключ - динамометрический, в нем динамо(-)метр
Дак это же управление положением вала с помощью мотора. Скорее как руль в лодке можно применить, чем как мотор в стиральной машине.
С лета 2023 больше не возвращают. Видимо, желающих стало слишком много, а сотрудников - слишком мало. Вот их ответ на мой запрос (сентябрь 2023):
А иксы, проброшенные через ssh, тоже будут резаться? Там тоже клавиатурный ввод не будет прослеживаться.
Спасибо за коментарий! Ну вроде бы похожий функционал еще обеспечивает Qt for MCUs со стандартными для qt сигналами и слотами. Но оно требуют довольно толстых микроконтроллеров, ориентировано в основном на UI, и навязывает структуру проекта, системы сборки и т.п. Я сам не пользовался.
В клавиатурах обычно больше кнопок, чем остается у МК на работу с ней, так что применяются разные техники мультиплексирования, как в статье. Как в таких случаях реализовывать прерывания?
Извините, но у вас какая-то дурацкая архитектура вышла. Очереди в принципе нужны, чтобы организовать FIFO-обработку, а блокирующие очереди еще для того, чтобы один поток ждал, пока от другого что-то придет. Было бы логично, если бы таска кнопок выполняла свою низкоуровневю логику и выдавала в очередь события типа "кнопка 1 нажата", "повтороное нажатие кнопки 5". У вас же каждый тик таска выплевывает в очередь внутренне состояние всех кнопок, и в итоге от очереди нет никакого толку; порядок элементов в очереди не важен, и таска-читатель не ждет событий, т.к. они все равно идут непрерывным потоком. Код в главной такске вышел такой же, как если бы состояние кнопок хранилось в массиве, к которому имеют доступ обе таски (только потокобезопасный).
Поэтому тут и от двух тасок нет особой пользы, проще и дешевле было бы в главной таске вызывать фцнкцию вроде "update_buttons_states()" и дальше делать то, что и сейчас. Не было бы накладных расходов на переключание между тасками и на копирование памяти в очередь и из нее.
Это выглядит как неправильный выбор инструмента и попытка натянуть его на задачу. Очередь с несколькими слушателями работает, когда слушатели равноправны и нужно доставить элемент только одному. Традиционный пример - пул потоков-воркеров, которые берут задачи из очереди. Если одно событие должно уходить нескольким слушателям, и они еще и выбирают, какие кому нужны, то тогда лучше взять другой паттерн, publish-subscribe там, или observer. Или просто сделать состояние кнопок доступным на чтение всем желающим.
И да, это все уже изобретено до нас, например, есть бибилотека ETL (embedded template library), там есть и observer, и message router, и миллион других готовых велосипедов.
Mail.Ru Group даже переименовалась в 2021 и теперь называется VK
Это с виду станок формата 3018 или его родственник, его за 10 тыр можно было купить пару лет назад
Возможно, выйдет меньше, если какие-то бинарники заменить на BusyBox. Или вообще строить всё не из alpine, а из busybox. Правда, тогда с установкой туда пакетов придется повозиться.
-
А как оно в сравнении с cython? Тоже же для этого проект, вроде бы.
Добрый день! Это никак не отвечает на вопрос)
Почему такой толстый продакт-плейсмент эпла? Это нейросеть сама дорисовала или в промте заказали?
Ну я имел в виду панели вроде той, что в статье, вряд ли под это используются высококачественные панели, скорее дешевые.