Юникод уже был: в какой-то момент вместо шрифтов koi8r я стал подключать юникодные, и это было как раз в 2000х. Цвета, очевидно, тоже были, всё тот же десяток, что используется и сейчас.
Ну и по-стариковски покряхчу про "свистелки и перделки": и практически бесконечный scrollback, и многооконность тоже были, но их реализовывал не терминал, а screen/tmux. Вот рендеринга на 140 Hz не было, это факт. Зачем терминалу рендеринг на вдвое более высокой частоте, чем у при игре в шутеры, и даже чем в принципе поддерживает мой монитор - это вообще загадка.
А тупящий терминал я вспомнил, да. Это было окошко command.com под виндой. Там я видел как вывод простыни текста тормозил. Больше нигде.
Что вы вообще делаете с терминалом такое, что он тормозит. Это же относительно простая штука, в 90х и 2000х ни о каких задержках в ней и не слышали: если что-то тормозит, то или Ctrl-S нажали, или сами процессы в сессии тупят.
protobuf это отличная штука, но в данном случае возможно слишком мощная. К тому же придётся искать библиотеку, которая умеет работать без аллокатора и с no_std.
Вы никогда не видели подтекста решений того же комитета по стандартизации C, например? Когда кто-то предлагает "давайте выкинем вот эту грёбаную адову херню", а им другие дружно отвечают "на эту хрень у пользователей нашего копмилятора из автостроения/авиации/финансов/военных/хзчего завязан тулчейн, которым они собирают сертифицированый код из 1997 года, и если вы его сломаете в новом стандарте, то им починить и пересертифицировать будет стоить сто тыщ миллионов и пять лет времени".
Срач между разработчиками ядра FreeBSD и чуваком из комитета по поводу mutex API был когда-то совершенно в духе подростковых форумов.
Если вы не знакомы с корутинами, то перед прочтением "как оно там устроено под капотом" всё-таки стоит познакомиться с ними. Какой смысл изучать хтонические потроха компилятора, если не представляете, какой результат от них ожидается?
А для человека, который понимает что делают корутины, и хорошо бы как они реализованы в других языках, это вполне полезное описание. В C++ довольно запутаный API, у меня чуть голова не лопнула в своё время даже простенькую реализацию корутин написать.
Нельзя в сетевых сервисах падать от ненадёжного мира. Триста кривых клиентов пришло, процесс от них упал - и отвалились соединения ещё с миллионом. А восстанавливать их долго и дорого.
Юникод уже был: в какой-то момент вместо шрифтов koi8r я стал подключать юникодные, и это было как раз в 2000х. Цвета, очевидно, тоже были, всё тот же десяток, что используется и сейчас.
Ну и по-стариковски покряхчу про "свистелки и перделки": и практически бесконечный scrollback, и многооконность тоже были, но их реализовывал не терминал, а screen/tmux. Вот рендеринга на 140 Hz не было, это факт. Зачем терминалу рендеринг на вдвое более высокой частоте, чем у при игре в шутеры, и даже чем в принципе поддерживает мой монитор - это вообще загадка.
А тупящий терминал я вспомнил, да. Это было окошко command.com под виндой. Там я видел как вывод простыни текста тормозил. Больше нигде.
Как печально, что ОС неспособна догадаться задрать приоритет терминалу. Пропали все полимеры (c)
Что вы вообще делаете с терминалом такое, что он тормозит. Это же относительно простая штука, в 90х и 2000х ни о каких задержках в ней и не слышали: если что-то тормозит, то или Ctrl-S нажали, или сами процессы в сессии тупят.
Никто уже не помнит классику.
Но для этого надо уметь писать код руками. А как известно, для C++ обучение этому навыку занимает как минимум 21 день.
protobuf это отличная штука, но в данном случае возможно слишком мощная. К тому же придётся искать библиотеку, которая умеет работать без аллокатора и с no_std.
Вы никогда не видели подтекста решений того же комитета по стандартизации C, например? Когда кто-то предлагает "давайте выкинем вот эту грёбаную адову херню", а им другие дружно отвечают "на эту хрень у пользователей нашего копмилятора из автостроения/авиации/финансов/военных/хзчего завязан тулчейн, которым они собирают сертифицированый код из 1997 года, и если вы его сломаете в новом стандарте, то им починить и пересертифицировать будет стоить сто тыщ миллионов и пять лет времени".
Срач между разработчиками ядра FreeBSD и чуваком из комитета по поводу mutex API был когда-то совершенно в духе подростковых форумов.
Не допускать старых ошибок для новых технологий можно. Не допускать новых ошибок для новых технологий вряд ли получится.
Мне было бы более интересно узнать, много ли счётчиков именно измеряют напряжение, а не просто считают его константой.
Как вы память на стеке освобождаете вручную в программе на C? В куче всё-таки, наверное.
https://en.wikipedia.org/wiki/Pentium_FDIV_bug ещё никто не приносил, потому что не застали? К вопросу о золотом стандарте точности :)
AI компании смотрят на вас с недоумением и закупают ещё один грузовик GPU.
Если вы не знакомы с корутинами, то перед прочтением "как оно там устроено под капотом" всё-таки стоит познакомиться с ними. Какой смысл изучать хтонические потроха компилятора, если не представляете, какой результат от них ожидается?
А для человека, который понимает что делают корутины, и хорошо бы как они реализованы в других языках, это вполне полезное описание. В C++ довольно запутаный API, у меня чуть голова не лопнула в своё время даже простенькую реализацию корутин написать.
Если бы вместо `int state_;` там было `enum State { state1, state2, state3 } state_;` -- вам понятнее было бы? Это функционально идентичный код.
Ну какой же это Rust, это Haskell :)
Нельзя в сетевых сервисах падать от ненадёжного мира. Триста кривых клиентов пришло, процесс от них упал - и отвалились соединения ещё с миллионом. А восстанавливать их долго и дорого.
"Ты не должен этого хотеть" (c) Яндекс
Позволю себе процитировать анекдот: "Ути какие мы оптимисты"
Всё вышеперечисленное может быть - и не сработать.
Сейчас вам расскажут про Теслу. Которая, правда, работает ну так... не везде и не всегда.
Я, кстати, сделал для своих поделок на STM32. Не так уж сложно.