Нужно не забывать, что мессенджер постоянно развивается, пополняясь новыми функциями и настройками, которые делают общение, работу и управление информацией удобнее. Многие функции остаются незаметными, хотя могут существенно упростить повседневные задачи или обеспечить комфортное общение с собеседниками.
Удобнее? "Ой, смотрите, у пользователя обновилась фоточка! Ой, смотрите, у пользователя день рождения!!! Ой, смотрите, новая версия приложения. Давайте обновимся?! Ой, смотрите, РЕКЛАМА! Ой, смотрите, ваше сообщение лайкнули!
Можно мне настройку, которая заставит Телеграм ПРОСТО БЫТЬ МЕССЕНДЖЕРОМ? А не асоциальной сетью?
Нет, МАХ мне не интересен. И "Давать МАХУ" я чёт не хочу.
Вот какую фишку я бы хотел для себя - возможность отключить к чёртовой бабушке все эти "инновации" и придумочки. Чтобы оно снова стало чатиком, а не хрен пойми чем.
alan@srv:~$ free -m
total used free shared buff/cache available
Mem: 16025 495 14683 23 846 15226
Swap: 0 0 0
alan@srv:~$ uptime
21:13:05 up 8 days, 12:59, 1 user, load average: 0,00, 0,00, 0,00
alan@srv:~$ uname -a
Linux srv 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux
alan@srv:~$ cat /etc/issue
Debian GNU/Linux 10 \n \l
Ну не знаю. Linux без входа пользователя в графический режим - едва ли потребляет память. В примере выше - относительно старый ПК, Debian 10 (странно, мне казалось, я ставил что-то более старое) в роли роутера и... и вот. ОСь спокойно работает уже неделю (если бы кулер не заклинило - было бы больше), а используется 495 МегаБайт оперативной памяти. Где-то был сервер на ещё более старой системе, но там набросано несколько сервисов, и по памяти чуть больше потребляет, естественно.
Нужно исходить из наихудшего сценария, когда правила "писаны вилами по воде", то есть как в детстве (или как в Манчкине в спорные моменты - прав тот кто громче кричит, или хозяин колоды).
Я даже ещё раз процитирую начальные условия:
Ваш друг загадал число от 0 до 100 включительно, которое вам надо угадать. Каждый раз он отвечает либо «угадал», либо «моё число больше», «моё число меньше». Вы знаете, что он перезагадывает число до тех пор, пока может это делать, не прибегая ко лжи.
А про восстановление контекста речи не было. Хотя и этот вариант покрывается бинарным поиском за 7 итераций. А именно в наихудшем варианте - пытаться угадать можно бесконечно долго, так как "Я же не соглал на последний вопрос!"
Нигде не сказано, что оппонент не может перезагадать число так, чтобы выполнялись ВСЕ предыдущие ответы. Так что берём наихудший вариант. Ну и вот. В таком случае - он всё ещё играет по правилам (как и мы), но наш шанс угадать число, которое меняется стремится к нулю.
Но в предыдущий раз уже было отвечено, что загаданное число больше 75.
Просто я не очень удачно выбрал первое число 80 и пошёл к нему бинарным поиском. Могла бы быть последовательность "68" -> "92" -> "77" -> "15", которая так же удовлетворяет первоначальным условиям и вроди как не нарушает описанных.
Вообще, в некоторых случаях условия должен писать не программист, а юрист >_< А то будет как в шутках с плохим джинном, который использует ваши же слова в свою пользу.
> Вы знаете, что он перезагадывает число до тех пор, пока может это делать, не прибегая ко лжи.
То есть, решается задача бинарным перебором, с условием того, что неизвестное число может смещаться, но так, чтобы попадать в ответы "Больше" / "Меньше" / "Равно"? Тогда 7. Подобное же решение демонстрировалось в училище (мной, как увлекавшимся программированием). Собственно, так работают мультиметры с регистром последовательного приближения.
Но если мы "промахиваемся" с ответом и игрок может перезагадать другое число, то... только удачей.
Допустим: Загадано 80.
Вопрос: Это 50? Больше (осталось 80 - истина) Вопрос: Это 75? Больше (осталось 80 - истина) Вопрос: Это 82? Меньше (может загадать 12? - ведь это истина) А мы продолжаем "искать" число, которое уплыло из диапазона поиска. :\
Вот эта библиотека работает с целочисленными значениями для построения FFT спектра. На STM32F030, запущенного на 20МГц (пришлось выбирать рабочую частоту так, чтобы можно было управлять через SPI "умными" светодиодами (WS2812 в микро корпусе). Буфер на 512 сэмплов обрабатывает быстро (хотя и не замерял), но его заполнение, обработка, поиск нужной частоты (среднее + сравнение его с пятью "нужными" сэмплами) довольно неоптимальным кодом... спокойно укладывается в 50мс. Да, всё крутится вокруг DMA при этом.
Настроили АЦП, прикрутили к нему DMA. Настроили SPI на отправку буфера для светодиодов, чуть-чуть заполнили его, запустили DMA, пусть он запрашивает следующие 48(24) байт. Начали читать данные через I2C? Ну... а на этом чипе так не получилось. Ну ой.
Традиционно торчащий блок камер. Могли бы сделать "Вровень выпирает" и за одно увеличить ёмкость аккумулятора, т.к. корпус бы стал толщиной с блок камер. Или поставить камеры тоньше. И экран с пулевым ранением в лоб. Мода, чтоб её. :\
Если в массиве состояния уже "2", то "1" туда складывать нет смысла.
А сбросом этого значения будет заниматься основной поток. Так что нет. Ну и мелкие проверки "на идиота" никто не отменял, а расписывать их все без псевдокода сильно долго.
В общем, таким алгоритмом я спокойно пользуюсь в своих проектах и сбоев пока замечено не было. И длительное нажатие (даже слишком длительное, которое ошибка) не считается как "длительное нажатие + короткое".
ИМХО. Конечнный автомат, это, конечно круто, но.. ЗАЧЕМ так сложно? Берём массив кнопок. Каждый квант времени (в случае моих устройств - каждую милисекунду, сразу после обработчика SysTick, возвращаемся в main() и читаем состояния кнопок (либо внутри самого SysTick'а) проверяем состояние пинов.
Если надата - увеличиваем счётчик. Если отпущена - сбрасываем (ееееее, антидребезг!). Если при чтении нуля с пина в соответствующей ячейке массива значение больше порогового для кнопки - в другой массив кладём "1". Если же досчитали до длительного нажатия - "2". Если превышен порог залипания - "3" или "0" - в зависимости от желания. Всё. Особого конечного автомата нет, а код видит нажатие кнопки.
Я засвечиваю китайским УФ фонариком https://aliexpress.ru/item/33043819149.html Хватает 20-30 секунд для платы размерами 10*10 см для равномерной засветки с расстояния около 60см (кладу плату, фотошаблон на неё, выравниваю, вытягиваю руку с фонариком вверх, и засвечиваю плавными круговыми движениями, стараясь держать фонарик в одной точке). Боковых засветов нет. Искажений нет. Результат повторяемый. 0.25/0.3мм - вообще без напряга выходит, а лучше не может обеспечить принтер, который эпизодически засыхает.
Вообще, засветка на малой мощности, как показала практика, малоэффективна и слабо дубит фоторезист. С другой стороны, мощный источник УФ может пробиться через неплотный фотошаблон.
Собрал как раз на SPI. Частота ядра - 20МГц, предделитель SPI - /4 (5МГц). 8 бит-слотов занимают 12.8мкс, 1 бит-слот - 1.6мкс (по какой-то причине светодиоды лучше всего заработали именно с этой скоростью). Данные отправляются по DMA. Используется 48 байт. 0x70 = '1', 0x40 = 0. Буфер кольцевой, 2*24 байта (бита). По прерыванию DMA уже отправленная половина буфера заполняется новыми значениями для передачи. 20 светодиодов вообще без сбоев приёма обновляются.
Диоды работают от того же питания 3.3В и чувствуют себя хорошо, как минимум, не отключаются и даже выходят на полную яркость (но ток потребления в батарейном устройстве для такого режима черезмерен, как и яркость для индикаторов).
Размер доступной памяти был всего 40кБ, что куда как меньше 64кБ у окна. Приходилось изголяться. А для снижения нагрузки на процессорную часть пытался описать подобие Delayed-ACK, но выходила какая-то фигня. В итоге проект так и не заработал как надо из-за сложности и смены потребностей.
У меня когда-то была обратная задача: собрать на минималистичном железе устройство для теста скорости. И из-за ограниченного объёма памяти для буфера приёма (микроконтроллер) мало что получилось. Хотя обмен данными по кабелю между ПК и устройством таки смог выжать почти 90МБит при TCP соединении.
Надеялся найти что-то интересное для железных отладчиков для микроконтроллеров. Ну да, чего я вообще хотел? :) Хотя у некоторых тоже есть интересые штуки типа "шага назад", но такие возможности имеют большое количество ограничений, как раз из-за микроконтроллера.
Так что иногда проще с трассировкой "Лол, мы сюда попали %потому что%".
Частенько в таких блоках питания всего один полноценный преобразователь напряжения. И блок питания, следует одной ему ведомой логике. Обычно - если потребителей больше одного - они сваливаются в режим 5V ?A. Количество доступных ампер - сильно разнится.
Значительно реже - блок выбирает общее напряжение для нагрузок из максимально рабочих для них. Но прямо ОЧЕНЬ редко.
Бывают блоки с парой независимых разъёмов - те могут работать полноценно раздельно.
Удобнее? "Ой, смотрите, у пользователя обновилась фоточка! Ой, смотрите, у пользователя день рождения!!! Ой, смотрите, новая версия приложения. Давайте обновимся?! Ой, смотрите, РЕКЛАМА! Ой, смотрите, ваше сообщение лайкнули!
Можно мне настройку, которая заставит Телеграм ПРОСТО БЫТЬ МЕССЕНДЖЕРОМ? А не асоциальной сетью?
Нет, МАХ мне не интересен. И "Давать МАХУ" я чёт не хочу.
Вот какую фишку я бы хотел для себя - возможность отключить к чёртовой бабушке все эти "инновации" и придумочки.
Чтобы оно снова стало чатиком, а не хрен пойми чем.
Они развернули Twike наоборот о_О
Ну не знаю. Linux без входа пользователя в графический режим - едва ли потребляет память.
В примере выше - относительно старый ПК, Debian 10 (странно, мне казалось, я ставил что-то более старое) в роли роутера и... и вот. ОСь спокойно работает уже неделю (если бы кулер не заклинило - было бы больше), а используется 495 МегаБайт оперативной памяти. Где-то был сервер на ещё более старой системе, но там набросано несколько сервисов, и по памяти чуть больше потребляет, естественно.
Amazfit Bip? С автономностью в режиме "часы + уведомления + будильник + измерение пульса в фоне" около 3-4 недель?
Ну да, ну да, снова не WearOS.
Нужно исходить из наихудшего сценария, когда правила "писаны вилами по воде", то есть как в детстве (или как в Манчкине в спорные моменты - прав тот кто громче кричит, или хозяин колоды).
Я даже ещё раз процитирую начальные условия:
А про восстановление контекста речи не было. Хотя и этот вариант покрывается бинарным поиском за 7 итераций. А именно в наихудшем варианте - пытаться угадать можно бесконечно долго, так как "Я же не соглал на последний вопрос!"
Нигде не сказано, что оппонент не может перезагадать число так, чтобы выполнялись ВСЕ предыдущие ответы. Так что берём наихудший вариант. Ну и вот. В таком случае - он всё ещё играет по правилам (как и мы), но наш шанс угадать число, которое меняется стремится к нулю.
Просто я не очень удачно выбрал первое число 80 и пошёл к нему бинарным поиском. Могла бы быть последовательность "68" -> "92" -> "77" -> "15", которая так же удовлетворяет первоначальным условиям и вроди как не нарушает описанных.
Вообще, в некоторых случаях условия должен писать не программист, а юрист >_< А то будет как в шутках с плохим джинном, который использует ваши же слова в свою пользу.
Примерно как "Когда твой папа Тестировщик", или "последнее желание джинна".
> Вы знаете, что он перезагадывает число до тех пор, пока может это делать, не прибегая ко лжи.
То есть, решается задача бинарным перебором, с условием того, что неизвестное число может смещаться, но так, чтобы попадать в ответы "Больше" / "Меньше" / "Равно"? Тогда 7. Подобное же решение демонстрировалось в училище (мной, как увлекавшимся программированием). Собственно, так работают мультиметры с регистром последовательного приближения.
Но если мы "промахиваемся" с ответом и игрок может перезагадать другое число, то... только удачей.
Допустим: Загадано 80.
Вопрос: Это 50? Больше (осталось 80 - истина)
Вопрос: Это 75? Больше (осталось 80 - истина)
Вопрос: Это 82? Меньше (может загадать 12? - ведь это истина)
А мы продолжаем "искать" число, которое уплыло из диапазона поиска. :\
https://gist.github.com/Tomwi/3842231
Вот эта библиотека работает с целочисленными значениями для построения FFT спектра. На STM32F030, запущенного на 20МГц (пришлось выбирать рабочую частоту так, чтобы можно было управлять через SPI "умными" светодиодами (WS2812 в микро корпусе). Буфер на 512 сэмплов обрабатывает быстро (хотя и не замерял), но его заполнение, обработка, поиск нужной частоты (среднее + сравнение его с пятью "нужными" сэмплами) довольно неоптимальным кодом... спокойно укладывается в 50мс. Да, всё крутится вокруг DMA при этом.
Настроили АЦП, прикрутили к нему DMA.
Настроили SPI на отправку буфера для светодиодов, чуть-чуть заполнили его, запустили DMA, пусть он запрашивает следующие 48(24) байт.
Начали читать данные через I2C? Ну... а на этом чипе так не получилось. Ну ой.
Традиционно торчащий блок камер. Могли бы сделать "Вровень выпирает" и за одно увеличить ёмкость аккумулятора, т.к. корпус бы стал толщиной с блок камер. Или поставить камеры тоньше.
И экран с пулевым ранением в лоб. Мода, чтоб её. :\
Если в массиве состояния уже "2", то "1" туда складывать нет смысла.
А сбросом этого значения будет заниматься основной поток. Так что нет.
Ну и мелкие проверки "на идиота" никто не отменял, а расписывать их все без псевдокода сильно долго.
В общем, таким алгоритмом я спокойно пользуюсь в своих проектах и сбоев пока замечено не было. И длительное нажатие (даже слишком длительное, которое ошибка) не считается как "длительное нажатие + короткое".
Можно. А считая ещё реже можно пропустить нажатие.
ИМХО. Конечнный автомат, это, конечно круто, но.. ЗАЧЕМ так сложно?
Берём массив кнопок. Каждый квант времени (в случае моих устройств - каждую милисекунду, сразу после обработчика SysTick, возвращаемся в main() и читаем состояния кнопок (либо внутри самого SysTick'а) проверяем состояние пинов.
Если надата - увеличиваем счётчик. Если отпущена - сбрасываем (ееееее, антидребезг!). Если при чтении нуля с пина в соответствующей ячейке массива значение больше порогового для кнопки - в другой массив кладём "1". Если же досчитали до длительного нажатия - "2". Если превышен порог залипания - "3" или "0" - в зависимости от желания. Всё. Особого конечного автомата нет, а код видит нажатие кнопки.
Я засвечиваю китайским УФ фонариком https://aliexpress.ru/item/33043819149.html
Хватает 20-30 секунд для платы размерами 10*10 см для равномерной засветки с расстояния около 60см (кладу плату, фотошаблон на неё, выравниваю, вытягиваю руку с фонариком вверх, и засвечиваю плавными круговыми движениями, стараясь держать фонарик в одной точке).
Боковых засветов нет. Искажений нет. Результат повторяемый. 0.25/0.3мм - вообще без напряга выходит, а лучше не может обеспечить принтер, который эпизодически засыхает.
Вообще, засветка на малой мощности, как показала практика, малоэффективна и слабо дубит фоторезист. С другой стороны, мощный источник УФ может пробиться через неплотный фотошаблон.
Собрал как раз на SPI. Частота ядра - 20МГц, предделитель SPI - /4 (5МГц). 8 бит-слотов занимают 12.8мкс, 1 бит-слот - 1.6мкс (по какой-то причине светодиоды лучше всего заработали именно с этой скоростью). Данные отправляются по DMA. Используется 48 байт. 0x70 = '1', 0x40 = 0. Буфер кольцевой, 2*24 байта (бита). По прерыванию DMA уже отправленная половина буфера заполняется новыми значениями для передачи. 20 светодиодов вообще без сбоев приёма обновляются.
Диоды работают от того же питания 3.3В и чувствуют себя хорошо, как минимум, не отключаются и даже выходят на полную яркость (но ток потребления в батарейном устройстве для такого режима черезмерен, как и яркость для индикаторов).
Размер доступной памяти был всего 40кБ, что куда как меньше 64кБ у окна. Приходилось изголяться. А для снижения нагрузки на процессорную часть пытался описать подобие Delayed-ACK, но выходила какая-то фигня. В итоге проект так и не заработал как надо из-за сложности и смены потребностей.
У меня когда-то была обратная задача: собрать на минималистичном железе устройство для теста скорости. И из-за ограниченного объёма памяти для буфера приёма (микроконтроллер) мало что получилось. Хотя обмен данными по кабелю между ПК и устройством таки смог выжать почти 90МБит при TCP соединении.
Надеялся найти что-то интересное для железных отладчиков для микроконтроллеров. Ну да, чего я вообще хотел? :)
Хотя у некоторых тоже есть интересые штуки типа "шага назад", но такие возможности имеют большое количество ограничений, как раз из-за микроконтроллера.
Так что иногда проще с трассировкой "Лол, мы сюда попали %потому что%".
Частенько в таких блоках питания всего один полноценный преобразователь напряжения. И блок питания, следует одной ему ведомой логике. Обычно - если потребителей больше одного - они сваливаются в режим 5V ?A. Количество доступных ампер - сильно разнится.
Значительно реже - блок выбирает общее напряжение для нагрузок из максимально рабочих для них. Но прямо ОЧЕНЬ редко.
Бывают блоки с парой независимых разъёмов - те могут работать полноценно раздельно.
Разобрать PocketBook, вытащить карточку, вставить новую, получить ругань загрузчика, посмотреть серийник на экране. На моей было так.
Как вариант - linux + кард-ридер или ещё несколько вариантов, включая разные уровни извращений от Arduino+USB-TTL и разные другие.