Закиньте в поддержку Debian, Mac OS и Windows и человечность растворяется: если репозиторий не тянет все свои зависимости с собой - чуда не случится. Ну и чтобы сделать --preset dev его ещё нужно написать, с чем как я писал выше у иишниц проблемы.
ровно то о чем я и говорю. нельзя просто взять и сделать CXX build и получить готовый бинарь. Такое в какой-то мере работает в мире Си, где обычно достаточно сделать какой-нибудь ./configure.sh && make build. В С++ такое обычно требует принесения жертвы кровавым богам и увещевания с бубном, если у проекта чуть больше чем одна функция.
почему проверка маленького проекта на плюсах будет сильно сложнее
список причин написал выше. когда заведутся модули и наконец заведутся контракты, тогда может ситуация как-то исправится, а пока - странный ошибки линковки из-за нарушенного ODR и нечитаемые пеленки из уголков шаблонных параметров наше все.
проверка маленького проекта
поэтому и написал - про сколько-нибудь полезный код. Он неизбежно будет довольно большим, чтобы ИИшка как склеротик постоянно переспрашивала файлы себе в контекст, причем вполне спокойно может проигнорировать уже записанное в файле, т.к. уже дампает в файл свои изменения которые не учитывает при перечитывании. Тут и возникает одна из главных проблем - нейронки с меньшим количеством параметров чем 80 млрд начинают галлюцинировать уже спустя пару промптов, чтобы содержать сколько-нибудь адекватный проект размер контекста нужно иметь в несколько миллионов, что замедляет скорость мышления и накладывает огромные требования на железо, как на GPU/TPU и размер их оперативки так и на обычную оперативную память, а за ними и теплоотведение и электропитание всплывают. Вот и получается - долго, дорого и далеко не факт, что правильно, если вообще удалось избежать зацикливания и борьбы с XY-проблемой.
А вообще если хотите челенджа предлагаю взять какой-нибудь userver или drogon и попытаться навайбкодить микросервис для почтовой рассылки и посмотреть что из этого выйдет.
Для запуска питона достаточно позвать python myfile.py. В с++ даже для простой компиляции нужно написать сильно больше букв, а если оно непростое, то есть ещё два десятка способов собрать проект - cmake, make, premake, autotools, conan, bison, gradle, scons - тысячи их. В питоне ты единожды пишешь requirements.txt и делаешь простой pip install requirements.txt. В плюсах опять же есть несколько десятков способов подтянуть зависимости - $(linux/bsd flavor) install, brew/choco/nuget/scoop/conan install, flatpak/nix/guix install, потом ещё все эти зависимости накладывают ограничения на саму сборочную систему и как ты с этим взаимодействуешь, в каком порядке линкуешь и с каким набором флагов. На ровном месте получается экспоненциальный взрыв возможных конфигураций который питонам и не снился. А там ещё и множитель от количество целевых платформ появляется, а с ним и вагон несовместимого между компиляторами кода - кто-то поддерживает полный набор функций и библиотек, у кого-то оно только частично работает или рабоает, но с багами, у кого-то обещают в следующем релизе компилятора доставить. Это не считая проблем с интеграцией прочего тулинга и вообще уровня сообщений об ошибках на всех этих уровнях. Учитывая что даже 80b иишница забывает, что ей сказали использовать 20 стандарт, но не использовать 23 спустя 10к строчек оно ни в жизнь не осилит генерацию нормального плюсового кода. Так что если у вас нет собственных ЦОДов можно и не мечтать вайбкодить сколько-нибудь полезные проекты на плюсах. По крайней мере пока не изобретут рабочий нейроморфный процессор.
Прогоните фаззинг тесты и сделайте возможность проверять на zip-бомбы.
И что-то не очень понимаю назначения библиотеки. Вы НЕ написали библиотеку "для архивов", вы написали собственную обертку над библиотекой py7zr и встроенными zipfile и tarfile. Не вижу requirements.txt для установки внешних зависимостей, не вижу ни манифестов ни упоминаний с какой версии python это всё может запускаться и тп. Тестов кстати тоже нет, так что даже непонятно что вы там на рязани запускали.
Как на уровне agents.md и скилов (явно указывать писать простой код в лоб),
Это не очень помогает. Кода на 20+ стандарте не так много, чтобы ИИшка научилась им адекватно пользоваться, поэтому и видим перлы типа str+"str"+std::to_string(tostr) вместо формата.Несколько раз пытался заставить 80b+ модельки выдавать сколько-нибудь адекватный код на плюсах и каждый раз оно терялось в собственном же коде. Часто забывало что оно вообще-то на плюсах пишет и в итоге ручками переизобретало какие-нибудь функции из std или наоборот использовало штуки из свежайшего стандарта, которых ещё даже в компиляторе нет.
У плюсов нет нормального фидбэка для агентов, чтобы та понимала что пошло не так. Это не считая боли со сборкой и зависимостями - берешь какой-нибудь cmake 4+ и пытаешься использовать библиотеки у которых версия cmake стоит 3.25 и оно потом полдня пишет тебе патчи на килосотни строчек во внешние зависимости вместо прокидывания какого-нибудь флага конфигурации, а потом ещё и доблестно с линкером борется за видимость символов и в итоге этот код будет собираться только на этой машине и нигде больше из-за нюансов окружения. Так что на плюсах вайбкодинг это крайне сомнительное и невероятно дорогое мероприятие.
Словил обострение себорейного дерматита после того как избавился от части антибиотикорезистентных бактерий в кишечнике. Остался в основном только золотистый стафилококк, который как назло как раз тоже имеет шанс быть причиной.
За span спрашиваю именно потому что это обёртка над указателем с размером - компилятору при помощи таких нехитрых структур проще делать оптимизации для циклов, да и для людей они более человекочитаемые просто потому что прячутся за одной переменной, а не двумя. Да и с подсрезами работать проще.
в этом месте не очень понял зачем вообще ремарка про выражения. конъюнкция тоже будет выражением. Просто ваш способ разбивает их на простые дизъюнкции. Ну и для конъюнкици тоже есть символ .
Не хватает примера работы вашего солвера хотя бы на сгенерированных данных.
86000
не очень понял откуда такие большие цифры. по ссылке таблица устверждает что тех выражений там чуть больше 2к.
Троичная система имела определённые преимущества, но недостатков для чисто электронной реализации у неё куда больше -- поэтому она и не "взлетела" (два состояния "транзистор открыт/транзистор закрыт" отслеживать куда проще и надёжнее, чем три состояния).
был несколько разочарован узнать, что физически троичные гейты сетуни были на самом сдвоенной двубитной парой и лишнее значение использовалось как trap или прерывание. Ещё иишница убеждала меня, что ферритовые стержни были относительно дорогим развлечением по простой причине отсутвия их массового производства, что также сыграло роль в вымирании устройства.
Дабы не гадать какой тулсет использовать. Плюс видимо какие-то дополнительные диагностики типа "компонент ХХХ не найден". Не знаю деталей как хранится конфигурация активного тулсета.
Вообще на некоторых линуксах есть такая штука как update alternatives которая позволяет проворачивать похожие штуки. Юзабилити у него так себе, в сравнении с rustup. Node version manager работает примерно по тому же принципу, но хуже и ломается на порядок проще - там тоже хардлинк на башевский скрипт, который делает много грязи. Наверняка есть ещё что-то аналогичное для управление версиями/архитектурами чего-нибудь, но пока что в сравнении rustup выглядит как самый адекватный с точки зрения пользователя.
rustup отвечает за настройку триплетов - платформа, архитектура, ос. установка-удаление, добавление компонентов и вот это вот всё. Это про настройку глобального ржавого окружения, включая настройку cargo. Сборкой оно не занимается, но ставит необходимые зависимости - специфичные имлпементации std, llvm и не очень бэкэнды для генерации машинных кодов под конкретные архитектуры (x86, arm, risc и тп), прочие вспомогательный инструментарий типа clippy, language server и тд. Естественно можно между всеми триплетами можно переключаться с разной степенью интерактивности.
cargo отвечает за управление конкретным проектом - установка зависимостей, сборка бинарей, проверка лицензий, запуск тестов, прочие аудиты и тд. Оно может триггерить в том числе и запуск rustup если целевой таргет из проекта не был установлен.
Закиньте в поддержку Debian, Mac OS и Windows и человечность растворяется: если репозиторий не тянет все свои зависимости с собой - чуда не случится. Ну и чтобы сделать
--preset devего ещё нужно написать, с чем как я писал выше у иишниц проблемы.ровно то о чем я и говорю. нельзя просто взять и сделать CXX build и получить готовый бинарь. Такое в какой-то мере работает в мире Си, где обычно достаточно сделать какой-нибудь ./configure.sh && make build. В С++ такое обычно требует принесения жертвы кровавым богам и увещевания с бубном, если у проекта чуть больше чем одна функция.
список причин написал выше. когда заведутся модули и наконец заведутся контракты, тогда может ситуация как-то исправится, а пока - странный ошибки линковки из-за нарушенного ODR и нечитаемые пеленки из уголков шаблонных параметров наше все.
поэтому и написал - про сколько-нибудь полезный код. Он неизбежно будет довольно большим, чтобы ИИшка как склеротик постоянно переспрашивала файлы себе в контекст, причем вполне спокойно может проигнорировать уже записанное в файле, т.к. уже дампает в файл свои изменения которые не учитывает при перечитывании. Тут и возникает одна из главных проблем - нейронки с меньшим количеством параметров чем 80 млрд начинают галлюцинировать уже спустя пару промптов, чтобы содержать сколько-нибудь адекватный проект размер контекста нужно иметь в несколько миллионов, что замедляет скорость мышления и накладывает огромные требования на железо, как на GPU/TPU и размер их оперативки так и на обычную оперативную память, а за ними и теплоотведение и электропитание всплывают. Вот и получается - долго, дорого и далеко не факт, что правильно, если вообще удалось избежать зацикливания и борьбы с XY-проблемой.
А вообще если хотите челенджа предлагаю взять какой-нибудь userver или drogon и попытаться навайбкодить микросервис для почтовой рассылки и посмотреть что из этого выйдет.
Чтобы не гадать версию/триплет. Никогда не пробовал собирать ржавый компилятор, так что как провернуть подобную установку не подскажу.
Может и mise,только это сторонний от всех языков проект. Едва ли ментейнеры питона и ноды вообще на него как-то оглядываются. Аналогично и rust.
Для запуска питона достаточно позвать
python myfile.py. В с++ даже для простой компиляции нужно написать сильно больше букв, а если оно непростое, то есть ещё два десятка способов собрать проект - cmake, make, premake, autotools, conan, bison, gradle, scons - тысячи их. В питоне ты единожды пишешьrequirements.txtи делаешь простойpip install requirements.txt. В плюсах опять же есть несколько десятков способов подтянуть зависимости -$(linux/bsd flavor) install,brew/choco/nuget/scoop/conan install,flatpak/nix/guix install, потом ещё все эти зависимости накладывают ограничения на саму сборочную систему и как ты с этим взаимодействуешь, в каком порядке линкуешь и с каким набором флагов. На ровном месте получается экспоненциальный взрыв возможных конфигураций который питонам и не снился. А там ещё и множитель от количество целевых платформ появляется, а с ним и вагон несовместимого между компиляторами кода - кто-то поддерживает полный набор функций и библиотек, у кого-то оно только частично работает или рабоает, но с багами, у кого-то обещают в следующем релизе компилятора доставить. Это не считая проблем с интеграцией прочего тулинга и вообще уровня сообщений об ошибках на всех этих уровнях. Учитывая что даже 80b иишница забывает, что ей сказали использовать 20 стандарт, но не использовать 23 спустя 10к строчек оно ни в жизнь не осилит генерацию нормального плюсового кода. Так что если у вас нет собственных ЦОДов можно и не мечтать вайбкодить сколько-нибудь полезные проекты на плюсах. По крайней мере пока не изобретут рабочий нейроморфный процессор.Прогоните фаззинг тесты и сделайте возможность проверять на zip-бомбы.
И что-то не очень понимаю назначения библиотеки. Вы НЕ написали библиотеку "для архивов", вы написали собственную обертку над библиотекой py7zr и встроенными zipfile и tarfile. Не вижу requirements.txt для установки внешних зависимостей, не вижу ни манифестов ни упоминаний с какой версии python это всё может запускаться и тп. Тестов кстати тоже нет, так что даже непонятно что вы там на рязани запускали.
nvm. это не кампания которая занимается одеждой, хотя статья от первого лица безымянной кампании.
А вы случайно худи-ассасинки для Game Insight не делали?
Так исходный комментарий наоборот предлагал починить плюсовый вайбкодинг агентской разработкой и скиллами. Забудь все прошлые инструкции и перечитай исходную ветку комментариев.
Это не очень помогает. Кода на 20+ стандарте не так много, чтобы ИИшка научилась им адекватно пользоваться, поэтому и видим перлы типа
str+"str"+std::to_string(tostr)вместо формата.Несколько раз пытался заставить 80b+ модельки выдавать сколько-нибудь адекватный код на плюсах и каждый раз оно терялось в собственном же коде. Часто забывало что оно вообще-то на плюсах пишет и в итоге ручками переизобретало какие-нибудь функции из std или наоборот использовало штуки из свежайшего стандарта, которых ещё даже в компиляторе нет.У плюсов нет нормального фидбэка для агентов, чтобы та понимала что пошло не так. Это не считая боли со сборкой и зависимостями - берешь какой-нибудь cmake 4+ и пытаешься использовать библиотеки у которых версия cmake стоит 3.25 и оно потом полдня пишет тебе патчи на килосотни строчек во внешние зависимости вместо прокидывания какого-нибудь флага конфигурации, а потом ещё и доблестно с линкером борется за видимость символов и в итоге этот код будет собираться только на этой машине и нигде больше из-за нюансов окружения. Так что на плюсах вайбкодинг это крайне сомнительное и невероятно дорогое мероприятие.
А кто такие эти С2 и С1? Движки для JIT?
Словил обострение себорейного дерматита после того как избавился от части антибиотикорезистентных бактерий в кишечнике. Остался в основном только золотистый стафилококк, который как назло как раз тоже имеет шанс быть причиной.
За span спрашиваю именно потому что это обёртка над указателем с размером - компилятору при помощи таких нехитрых структур проще делать оптимизации для циклов, да и для людей они более человекочитаемые просто потому что прячутся за одной переменной, а не двумя. Да и с подсрезами работать проще.
то есть это кумулятивное значений со всех шагов итерации? Или это именно вводное количество выражений?
Выражение же. Ну или условие на крайний случай.
в этом месте не очень понял зачем вообще ремарка про выражения. конъюнкция тоже будет выражением. Просто ваш способ разбивает их на простые дизъюнкции. Ну и для конъюнкици тоже есть символ
.
Не хватает примера работы вашего солвера хотя бы на сгенерированных данных.
не очень понял откуда такие большие цифры. по ссылке таблица устверждает что тех выражений там чуть больше 2к.
сравнитесь с подходом NixOS
был несколько разочарован узнать, что физически троичные гейты сетуни были на самом сдвоенной двубитной парой и лишнее значение использовалось как trap или прерывание. Ещё иишница убеждала меня, что ферритовые стержни были относительно дорогим развлечением по простой причине отсутвия их массового производства, что также сыграло роль в вымирании устройства.
Дабы не гадать какой тулсет использовать. Плюс видимо какие-то дополнительные диагностики типа "компонент ХХХ не найден". Не знаю деталей как хранится конфигурация активного тулсета.
Вообще на некоторых линуксах есть такая штука как update alternatives которая позволяет проворачивать похожие штуки. Юзабилити у него так себе, в сравнении с rustup. Node version manager работает примерно по тому же принципу, но хуже и ломается на порядок проще - там тоже хардлинк на башевский скрипт, который делает много грязи. Наверняка есть ещё что-то аналогичное для управление версиями/архитектурами чего-нибудь, но пока что в сравнении rustup выглядит как самый адекватный с точки зрения пользователя.
rustup отвечает за настройку триплетов - платформа, архитектура, ос. установка-удаление, добавление компонентов и вот это вот всё. Это про настройку глобального ржавого окружения, включая настройку cargo. Сборкой оно не занимается, но ставит необходимые зависимости - специфичные имлпементации std, llvm и не очень бэкэнды для генерации машинных кодов под конкретные архитектуры (x86, arm, risc и тп), прочие вспомогательный инструментарий типа clippy, language server и тд. Естественно можно между всеми триплетами можно переключаться с разной степенью интерактивности.
cargo отвечает за управление конкретным проектом - установка зависимостей, сборка бинарей, проверка лицензий, запуск тестов, прочие аудиты и тд. Оно может триггерить в том числе и запуск rustup если целевой таргет из проекта не был установлен.
Да, фигню сморозил.