Правым пальцем и надо. Обоснование: на ортолинейных клавиатурах придётся печатать правым пальцем (тк 6 там, как и следует ожидать, находится в ряду для правого пальца) –
– а на скошенных клавиатурах придётся делать то же для единообразия рефлекса.
Скучно… Ai ai ai ai, какие-то помощники которые лезут под руку и что-то предлагают, какой-то курсор который на лету генерит кучу контекста от малейшего движения (кошмар ux/ui имхо), странная логика одновременного открывания документа на многих устройствах, NIH экосистема вместо проверенных десктопных программ. А могли бы просто сделать сверхдешёвый ноут, не прибивая к нему гвоздями свою ос, чтобы на нём работал Windows и пара основных дистрибутивов Linux, - и получить всенародную любовь и заодно съесть в стиле Android сегмент дешёвых офисных лэптопов. Но видимо сейчас не навернув AI и неведомой хрени, образующей ✨экосистему✨, никакую линейку продуктов не запустить. Хромбуки после удаления ChromeOS это отличные устройства, у меня до сих пор Toshiba chromebook 2 с Debian основная печатная для работы вне дома, 2015 год, 200$ стоил на тот момент.
За два года было разработано примерно сто внутренних расширений. Это позволило реализовать множество сценариев, раньше казавшихся невозможными.
Ну конечно, легко и приятно писать с нуля. Как “техлиду внутренней расширяемости” IDE (не вполне понимаю что этот титул означает), ему бы стоило знать, что чтобы догнать экосистему плагинов некоторых редакторов, нужны годы и рабочее время разрабов, и при этом надо ещё заниматься строгим контролем и стандартизацией всех эти 100+ расширений, иначе они превратятся в гору велосипедов с сильным разбросом по качеству.
Эти 100 расширений образуют строгую и расширяемую систему, которая хотя бы в теории или в обозримом будущем может соревноваться с большими экосистемами плагинов вроде Emacs? Я в этой экосистеме 100 расширений могу сделать стандартным способом что-либо? Например, подключить подсветку синтаксиса нового ЯП, новый дебаггер (DAP), новый движок нечёткого выбора в менюшках (fzf frizbee итд)? Или всё же накоммитили каких-то 100 расширений для конечных задач и думают, что решить проблему фрагментации IDE и накопленного в других IDE функционала так просто?
Или я вот пользуюсь модальным редактированием на постоянной основе, у них в этом супер-редакторе есть плагин, имитирующий поведение Vim с той же точностью, с которой это делает например Emacs Evil mode? И таких требований, которые реализовать в редакторе с нуля затратно, у каждого разработчика по несколько штук, они все разные, и про каждое он заявит что это must have.
Стандартизовать IDE на работе - бессмысленно, в этом я 100% согласен с Jeff Dean.
Это довольно узкое понимание… Для начала, копилотов два. Есть Microsoft Copilot, ранее Copilot, изначально был чатботом над GPT, мог использоваться в тч для автодополнения в IDE, но сейчас разросся до агента для экосистемы MS 365, умеющего дёргать функции офисных приложений. И есть Github Copilot, это отдельный продукт, полноценный агент, не чатбот делающий автодополнение.
PS: Всратость заглавной картинки просто поражает воображение!
Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 1ю клавишу ещё не отпустили, а 2я уже нажата. Как вы отличите включение модификатора от быстрого набора?
это назначить Shift на клавиши, которые уже под мизинцами
Плохое решение. Мизинцы вам не скажут спасибо, что вы их назначаете на удерживаемую клавишу (модификатор). Эргоклавиатуры и эргораскладки как раз стремятся разгрузить мизинцы. На эргоклавиатурах это делается например созданием 2 островов доп. клавиш под большой палец (thumb pad), на обычных клавиатурах это обычно или ремап Alt на Shift или путешествие в зыбкий мир Mod-tap (назначение какой-л. буквенной клавиши, только всё же не той что под мизинцем, модификатором при зажатии), с необходимостью бороться с неоднозначностью описанной выше.
Не принимается. Косвенный доступ по указателю не существенный, учитывая, что потом всё равно будет куча обращений к памяти для чтения строк и их конкатенации. Перерасход памяти выглядит куда более существенной проблемой.
Экономия на спичках. В реальности скорее всего потеряете в производительности в несколько раз. Массив смартпоинтеров - это куча лишних аллокаций и структура данных с непредсказуемым и нелокальным расположением элементов, крайне враждебная к оптимизациям.
Так и вышло: для большого города наш деревенский сервер выглядел как подозрительный тип с рынка — вроде живой, а верить ему никто не спешит. Письмо лежало в папке «Спам»
Боже какая чушь. Гугл просто не примет письмо с SMTP нонейма.
Одной из самых раздражающих проблем стали фризы интерфейса при загрузке 4K-изображений. Сейчас я работаю над внедрением std::jthread из стандарта C++20.
Каким образом jthread может решить вашу проблему, явно происходящую от того, что UI и загрузка не распараллелены?
так как проект использует современные фичи вроде std::format (в планах) и асинхронные потоки
ни того ни другого в коде нет
я реализовал обертку CurlWrapper с использованием принципов RAII.
не изобретайте велосипед, используйте библиотеку
стандарт C++20. Это критично, так как проект использует современные фичи вроде std::format
Вы удивитесь насколько слабая поддержка std::format в STL C++20. Используйте libfmt лучше сразу
Системное программирование — это не страшно
У вас не системная а прикладная утилита, несмотря на то что C++
Извиняюсь, шутка слишком тонкая вышла) Я имею в виду, что весьма вероятно, что этот браузерный движок, равно как и его “глубокий технический анализ”, вышеупомянутый подросток сделал с помощью ИИ. В свете чего весьма забавно наблюдать его замес с ОП. Я не верю в 17-летних гениев, пишущих браузерные движки, а если они и есть, то последнее место, куда им интересно будет приходить, - это комменты к хайповой статье про очередной $productname, сделанный ИИ.
Респект конечно за превозмогание, но это очень очень сложный способ придти к известной банальщине "видишь странные плавающие глюки с отвалом разнообразных устройств - первый на подозрении это БП".
Что в ней плохого это неважно, если кто юзает macos значит знает за что, но смысла в подобных постах я не вижу. Графомания и неинтересные сентиментальные воспоминания. Он мог бы например написать про какое-нибудь своё ноухау для рабочего окружения на маке, или как он раскапывал почему на линуксе тормозило а на bsd нет.
Почему-то все посты про ОС от зарубежных авторов, написанные в этом же характерном сентиментальном стиле, этим заканчиваются. Я буквально знал, что эта фраза встретится в посте. Ещё эти товарищи часто переходят на Signal и ведут блог, в котором учат всех как делать правильно.
Всегда возникает отвращение после чтения подобного. Кто реально любит фряху/линукс/etc у того она настроена под себя так, что никакому маку не снилось. На личном ПК, не не рабочем. В чём ценность постов от таких людей как OP? Сообщать миру про банальный флаг во fstab которому сто лет в обед?
Я не понял, почему если бэкенд на Rust, то автодополнением ввода занимается js код?? Это же задача бэкенда? Особенно при том что у вас стоит цель выполнять запросы быстро на большом вводе. Есть готовые движки для нечёткого поиска, например fuzzy-matcher в skim (клон fzf на Rust) или превосходящий его в производительности nucleo.
хотел большего: толерантность к опечаткам
Имхо: это то, что называется "solves a non-problem". Очень редко бывает, что юзер опечатывается в коротком вводе который у него перед глазами, и ещё реже, что он не замечает опечатки - просто глядя на экран, или по результатам автодополнения по ошибочному вводу. Обработка опечаток заставляет вас реализовывать сложный и дорогой алгоритм нечёткой близости слов, при том что это нужно в 0.001% случаев. Кроме того нечёткий алгоритм часто даёт много нерелевантных результатов, кто пользуется нечётким поиском по Unix путям к файлов тот знает. Сделайте просто поиск по подстрокам (с нечёткостью только по отношению к регистру и к порядку паттернов, вводимых юзером, т.е. чтобы "def__AbC" подходило под запрос "abc def") и вам этого будет достаточно почти для всего. Ещё лучше сделать алгоритм с обработкой "frecency" - учитыванием как близости к поисковому запросу, так и частотой выигрыша в прежних запросах. Но ок, если вы хотите в эту кроличью нору с опечатками, то, ряд движков автодополнения реализуют подобные алгоритмы с устойчивостью к опечаткам, например frizbee. Fzf насколько я знаю так не умеет, но Skim умеет: https://www.reddit.com/r/neovim/comments/1qpary8/fzfluaskim_now_supports_typo_resistant_fuzzy/ Немного отсылок к теории по этим алгоритмам есть в доках к Nucleo и Frizbee. Известный алгоритм для этого это Smith-Waterman, он вообще для ДНК цепочек, но применим к текстовому поиску. Именно его вариации применяют nucleo и frizbee. Также классика это Levenshtein distance / Levenshtein algorithm.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.
Правым пальцем и надо. Обоснование: на ортолинейных клавиатурах придётся печатать правым пальцем (тк 6 там, как и следует ожидать, находится в ряду для правого пальца) –
– а на скошенных клавиатурах придётся делать то же для единообразия рефлекса.
Скучно… Ai ai ai ai, какие-то помощники которые лезут под руку и что-то предлагают, какой-то курсор который на лету генерит кучу контекста от малейшего движения (кошмар ux/ui имхо), странная логика одновременного открывания документа на многих устройствах, NIH экосистема вместо проверенных десктопных программ. А могли бы просто сделать сверхдешёвый ноут, не прибивая к нему гвоздями свою ос, чтобы на нём работал Windows и пара основных дистрибутивов Linux, - и получить всенародную любовь и заодно съесть в стиле Android сегмент дешёвых офисных лэптопов. Но видимо сейчас не навернув AI и неведомой хрени, образующей ✨экосистему✨, никакую линейку продуктов не запустить. Хромбуки после удаления ChromeOS это отличные устройства, у меня до сих пор Toshiba chromebook 2 с Debian основная печатная для работы вне дома, 2015 год, 200$ стоил на тот момент.
Ну конечно, легко и приятно писать с нуля. Как “техлиду внутренней расширяемости” IDE (не вполне понимаю что этот титул означает), ему бы стоило знать, что чтобы догнать экосистему плагинов некоторых редакторов, нужны годы и рабочее время разрабов, и при этом надо ещё заниматься строгим контролем и стандартизацией всех эти 100+ расширений, иначе они превратятся в гору велосипедов с сильным разбросом по качеству.
Эти 100 расширений образуют строгую и расширяемую систему, которая хотя бы в теории или в обозримом будущем может соревноваться с большими экосистемами плагинов вроде Emacs? Я в этой экосистеме 100 расширений могу сделать стандартным способом что-либо? Например, подключить подсветку синтаксиса нового ЯП, новый дебаггер (DAP), новый движок нечёткого выбора в менюшках (fzf frizbee итд)? Или всё же накоммитили каких-то 100 расширений для конечных задач и думают, что решить проблему фрагментации IDE и накопленного в других IDE функционала так просто?
Или я вот пользуюсь модальным редактированием на постоянной основе, у них в этом супер-редакторе есть плагин, имитирующий поведение Vim с той же точностью, с которой это делает например Emacs Evil mode? И таких требований, которые реализовать в редакторе с нуля затратно, у каждого разработчика по несколько штук, они все разные, и про каждое он заявит что это must have.
Стандартизовать IDE на работе - бессмысленно, в этом я 100% согласен с Jeff Dean.
У e-ink же частота обновления экрана низкая? Как скроллить текст, документы, веб-страницы? Есть подозрение, что глазки это будет убивать посильнее ЭЛТ
В источнике примеров у меня сомнений нет :) https://doc.rust-lang.org/unstable-book/language-features/coroutines.html
“Когда лень нормально добавить в систему бана сущность ‘вечный бан’ и ты пишешь говнокод с магической датой 9999”
Это довольно узкое понимание… Для начала, копилотов два. Есть Microsoft Copilot, ранее Copilot, изначально был чатботом над GPT, мог использоваться в тч для автодополнения в IDE, но сейчас разросся до агента для экосистемы MS 365, умеющего дёргать функции офисных приложений. И есть Github Copilot, это отдельный продукт, полноценный агент, не чатбот делающий автодополнение.
PS: Всратость заглавной картинки просто поражает воображение!
Первый раз слышу модный термин “дринкап”, но мне кажется он означает, что в бутылках на столах будет отнюдь не минералка!
Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 1ю клавишу ещё не отпустили, а 2я уже нажата. Как вы отличите включение модификатора от быстрого набора?
Плохое решение. Мизинцы вам не скажут спасибо, что вы их назначаете на удерживаемую клавишу (модификатор). Эргоклавиатуры и эргораскладки как раз стремятся разгрузить мизинцы. На эргоклавиатурах это делается например созданием 2 островов доп. клавиш под большой палец (thumb pad), на обычных клавиатурах это обычно или ремап Alt на Shift или путешествие в зыбкий мир Mod-tap (назначение какой-л. буквенной клавиши, только всё же не той что под мизинцем, модификатором при зажатии), с необходимостью бороться с неоднозначностью описанной выше.
Экономия на спичках. В реальности скорее всего потеряете в производительности в несколько раз. Массив смартпоинтеров - это куча лишних аллокаций и структура данных с непредсказуемым и нелокальным расположением элементов, крайне враждебная к оптимизациям.
Судя по тексту, настройка SPF DKIM итд произошла уже после того, как gmail якобы принял письмо
Боже какая чушь. Гугл просто не примет письмо с SMTP нонейма.
Каким образом jthread может решить вашу проблему, явно происходящую от того, что UI и загрузка не распараллелены?
ни того ни другого в коде нет
не изобретайте велосипед, используйте библиотеку
Вы удивитесь насколько слабая поддержка std::format в STL C++20. Используйте libfmt лучше сразу
У вас не системная а прикладная утилита, несмотря на то что C++
Извиняюсь, шутка слишком тонкая вышла) Я имею в виду, что весьма вероятно, что этот браузерный движок, равно как и его “глубокий технический анализ”, вышеупомянутый подросток сделал с помощью ИИ. В свете чего весьма забавно наблюдать его замес с ОП. Я не верю в 17-летних гениев, пишущих браузерные движки, а если они и есть, то последнее место, куда им интересно будет приходить, - это комменты к хайповой статье про очередной $productname, сделанный ИИ.
Я открою вам страшную правду…
Респект конечно за превозмогание, но это очень очень сложный способ придти к известной банальщине "видишь странные плавающие глюки с отвалом разнообразных устройств - первый на подозрении это БП".
Что в ней плохого это неважно, если кто юзает macos значит знает за что, но смысла в подобных постах я не вижу. Графомания и неинтересные сентиментальные воспоминания. Он мог бы например написать про какое-нибудь своё ноухау для рабочего окружения на маке, или как он раскапывал почему на линуксе тормозило а на bsd нет.
Почему-то все посты про ОС от зарубежных авторов, написанные в этом же характерном сентиментальном стиле, этим заканчиваются. Я буквально знал, что эта фраза встретится в посте. Ещё эти товарищи часто переходят на Signal и ведут блог, в котором учат всех как делать правильно.
Всегда возникает отвращение после чтения подобного. Кто реально любит фряху/линукс/etc у того она настроена под себя так, что никакому маку не снилось. На личном ПК, не не рабочем. В чём ценность постов от таких людей как OP? Сообщать миру про банальный флаг во fstab которому сто лет в обед?
У меня сильное впечатление что архитектуру ему делала ллм =) очень в её стиле, и велосипеды и UI на Tauri и характерный оверинженеринг в целом.
Из аккаунт-менеджера в iot и сразу с солидно выглядящим коммерческим продуктом на рынок. ЛЛМ - мечты сбываются
Я не понял, почему если бэкенд на Rust, то автодополнением ввода занимается js код?? Это же задача бэкенда? Особенно при том что у вас стоит цель выполнять запросы быстро на большом вводе. Есть готовые движки для нечёткого поиска, например fuzzy-matcher в skim (клон fzf на Rust) или превосходящий его в производительности nucleo.
Имхо: это то, что называется "solves a non-problem". Очень редко бывает, что юзер опечатывается в коротком вводе который у него перед глазами, и ещё реже, что он не замечает опечатки - просто глядя на экран, или по результатам автодополнения по ошибочному вводу. Обработка опечаток заставляет вас реализовывать сложный и дорогой алгоритм нечёткой близости слов, при том что это нужно в 0.001% случаев. Кроме того нечёткий алгоритм часто даёт много нерелевантных результатов, кто пользуется нечётким поиском по Unix путям к файлов тот знает. Сделайте просто поиск по подстрокам (с нечёткостью только по отношению к регистру и к порядку паттернов, вводимых юзером, т.е. чтобы "def__AbC" подходило под запрос "abc def") и вам этого будет достаточно почти для всего. Ещё лучше сделать алгоритм с обработкой "frecency" - учитыванием как близости к поисковому запросу, так и частотой выигрыша в прежних запросах. Но ок, если вы хотите в эту кроличью нору с опечатками, то, ряд движков автодополнения реализуют подобные алгоритмы с устойчивостью к опечаткам, например frizbee. Fzf насколько я знаю так не умеет, но Skim умеет: https://www.reddit.com/r/neovim/comments/1qpary8/fzfluaskim_now_supports_typo_resistant_fuzzy/ Немного отсылок к теории по этим алгоритмам есть в доках к Nucleo и Frizbee. Известный алгоритм для этого это Smith-Waterman, он вообще для ДНК цепочек, но применим к текстовому поиску. Именно его вариации применяют nucleo и frizbee. Также классика это Levenshtein distance / Levenshtein algorithm.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.