Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 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.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.
Разумеется. Так работает примерно вся математика и в значительной мере тестирование ПО.
Мне не очень важно знать, насколько хорошо система кодогенерации работает на happy path и насколько много кода она может при этом нагенерить и насколько сложные задачи он будет решать. Допускаю, что есть должности в разработке, где это имеет значение, но это не мой случай. Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно
У вас очень своеобразная интерпретация того, что такое понимание модели вычислений. Понимание это когда я 100 раз даю LLM на вход тот код, который я дал выше копилоту - вывод этого кода детерминированный - прошу её предсказать этот вывод, и она даёт корректное предсказание в 100 случаях, потому что берёт и исполняет код в этой модели, ну или хотя бы пытается организовать эту модель и действовать в её рамках. Иначе это правдоподобные рассуждения, вайбкодинг, гадание, но никак не понимание.
Ну слава богу догадался наконец, но говорить "решит любую задачу" про систему, которая с одинаковой легкостью выдаёт и правильный анализ и решение, меняющее поведение программы, и не видящую в этом проблемы, - это перебор.
И если придираться, то решение с вектором тоже так себе. Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
А вы можете решить любую задчу?
Я-то нет, но вы вроде говорили, что LLM на это способна?
поверьте, эти дискуссии в самом начале.
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Нет, неправильно, так как исходная задача (если убрать отладочную печать "pay for processing") выведет result: 2, result: 4, result: 6, а ваше изменение приводит к выводу: "result: 3, result: 5". Патч изменил наблюдаемое поведение. На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
Главная неэффективность: платная операция делается до фильтра
Это by design. В условии задачи не говорится, что в общем случае возможно произвести фильтрацию до платной операции. Run_paid_request я сделал операцией увеличения на единицу для простоты, в реальности это чёрный ящик.
2-3 формально верно, но несущественно.
4 просто неверно. Второй раз уже это говорю. Static const это прямое указание как компилятору, так и читающему код человеку, что лямбда одна и та же при любом запуске, и во многих похожих случаях приводит к инлайнингу лямбды. Что хочет выразить автор кода, сделав run_paid_request неконстантной или нестатической? Она может измениться между запусками? Она может быть переприсвоена?
В целом рефакторинг конечно замечательный, но напомню, что в исходный вопрос входило также "Что напечатает данный конкретный код"?
Если скажете, что именно в реальном коде является “платной” операцией (I/O? сеть? CPU?)
Поэтому нет никаких гарантий что даже дорогие модели смогут решить вашу задачу.
что ж, неплохой прогресс по сравнению с исходным посылом "попробуйте показать мне задачу, которую не решит LLM"
Документация по классам, которые используются в вашем коде, и документации по тем классам, которые использует эта библиотека... вам ведь комплексный анализ нужен производительности?
Нет там используемых классов с документацией. Там код в 10 строчек, 1 функция, вызывающая ranges::transform и ranges::filter. Весь нужный здесь контекст - это указание на возможную дороговизну ф-и run_paid_request. Никакой комплексный анализ не нужен, это не про ассемблерную оптимизацию вопрос. Там тупо дорогая функция вызывается больше раз чем надо.
а раз не помогают мне уровню мидл (правда на c/c++ я не писал уже много лет), то модели, тупее среднестатистического человека, хоть и эрудированной, тем более не поможет.
Говорят, помогает запустить код и проверить, правильно ли LLM его предсказала? https://godbolt.org/z/e783T6sq5 - дорогая функция вызывается для нечётных элементов 2 раза.
Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?
Первый раз слышу модный термин “дринкап”, но мне кажется он означает, что в бутылках на столах будет отнюдь не минералка!
Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 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.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.
Разумеется. Так работает примерно вся математика и в значительной мере тестирование ПО.
Мне не очень важно знать, насколько хорошо система кодогенерации работает на happy path и насколько много кода она может при этом нагенерить и насколько сложные задачи он будет решать. Допускаю, что есть должности в разработке, где это имеет значение, но это не мой случай. Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
У вас очень своеобразная интерпретация того, что такое понимание модели вычислений. Понимание это когда я 100 раз даю LLM на вход тот код, который я дал выше копилоту - вывод этого кода детерминированный - прошу её предсказать этот вывод, и она даёт корректное предсказание в 100 случаях, потому что берёт и исполняет код в этой модели, ну или хотя бы пытается организовать эту модель и действовать в её рамках. Иначе это правдоподобные рассуждения, вайбкодинг, гадание, но никак не понимание.
Ну слава богу догадался наконец, но говорить "решит любую задачу" про систему, которая с одинаковой легкостью выдаёт и правильный анализ и решение, меняющее поведение программы, и не видящую в этом проблемы, - это перебор.
И если придираться, то решение с вектором тоже так себе. Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
Я-то нет, но вы вроде говорили, что LLM на это способна?
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Нет, неправильно, так как исходная задача (если убрать отладочную печать "pay for processing") выведет result: 2, result: 4, result: 6, а ваше изменение приводит к выводу: "result: 3, result: 5". Патч изменил наблюдаемое поведение. На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
Это by design. В условии задачи не говорится, что в общем случае возможно произвести фильтрацию до платной операции. Run_paid_request я сделал операцией увеличения на единицу для простоты, в реальности это чёрный ящик.
2-3 формально верно, но несущественно.
4 просто неверно. Второй раз уже это говорю. Static const это прямое указание как компилятору, так и читающему код человеку, что лямбда одна и та же при любом запуске, и во многих похожих случаях приводит к инлайнингу лямбды. Что хочет выразить автор кода, сделав run_paid_request неконстантной или нестатической? Она может измениться между запусками? Она может быть переприсвоена?
В целом рефакторинг конечно замечательный, но напомню, что в исходный вопрос входило также "Что напечатает данный конкретный код"?
Платной операцией является run_paid_request.
что ж, неплохой прогресс по сравнению с исходным посылом "попробуйте показать мне задачу, которую не решит LLM"
Нет там используемых классов с документацией. Там код в 10 строчек, 1 функция, вызывающая ranges::transform и ranges::filter. Весь нужный здесь контекст - это указание на возможную дороговизну ф-и run_paid_request. Никакой комплексный анализ не нужен, это не про ассемблерную оптимизацию вопрос. Там тупо дорогая функция вызывается больше раз чем надо.
Говорят, помогает запустить код и проверить, правильно ли LLM его предсказала? https://godbolt.org/z/e783T6sq5 - дорогая функция вызывается для нечётных элементов 2 раза.
Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?