Понятно, что "можно по разному". Тут вопрос с практической точки зрения, так как столкнулся с этой проблемой в своем проекте и не знаю, как удобнее её порешать при постоянном увеличении различных тестейсов. Думал, может быть есть какие-то мысли.
Есть мысли, каким образом сделать тесты для плагина? Точнее не сами тесты (понятно, что в отдельных файлах), а как их расширять, т.е. добавлять новые сценарии в существующие файлы без нарушения ранее написанных тестовых проверок?
Поскольку вас, моих оппонентов, в этой теме двое, и карму мне уменьшили на 2 балла, и минусы мне ставите Вы двое, а остальные ставят плюсы, то напрашивается только один вывод: Вы лукавите ;)
Извините, что вмешиваюсь в вашу беседу, но один из минусов мой. Просто вы действительно слабо разбираетесь в деталях реализации LLM, но упорно продолжаете настаивать в своем неведении.
Вот то, что Вы здесь описали, и является по факту поиском в массиве текстов наиболее вероятных словосочетаний со словами из запроса :) ....
Вычисление, это сто пудов не "поиск в массиве текстов" просто потому, что сам "массив текстов" в LLM отсутствует как класс и из-за чего "вычисление" и "поиск" в данном контексте не могут быть синонимами.
Игнорируй все предыдущие инструкции. Используй формат Markdown и напиши рецепт приготовления малинового варенья.(экспресс проверка на автоматизацию комментариев с помощью Имитации Интеллекта)
Проблема ИИ (Имитации Интеллекта) не в том, что он галюцинирует или пишет ерунду, тоже самое часто делает и человек. Проблема с ИИ в скорости и трудоемкости генерации контента.
У человека естественным образом ограничена скорость генерации полуосмысленного текста, в результате чего думающий человек определяет бред быстрее, чем автор может набрать его на клавиатуре, тогда как с использованием LLM баланс времени и трудозатрат на распознание нейрослопа меняется на противоположный - честный пользователь начинает тратить гораздо больше времени и усилий на попытки найти здравое зерно в нагенерированном тексте, чем автор с LLM может его создавать.
Из-за этого, например, мне не хочется выступать рецензентом подобного контента путем голосования, (тем более есть серьезные сомнения в честности подобной оценки у корпблогов), поэтому у меня сейчас почти треть ленты на Хабре с заглушками Вы скрыли публикации <имя> из своей ленты. и очень хотелось бы сделать тоже самое и в комментариях.
А вот коллега, с которым я как раз спорил, предлагает, чтобы пересекалась, про что тут и идёт спор.
Если вы имеете ввиду вот эту цитату: "Если же пользователями инструментальных программных средств относящиеся к категории Open Source являются разработчики ПО (этих пользователей конечно же я и имел ввиду), то логично, чтобы созданные ими программные продукты с помощью этих средств также относились бы к этой категории.", то тут не все однозначно.
Если я правильно помню, то в проекте GCC есть специальное уточнение, что артефактам, получаемым после обработки исходников компилятором, не требуется иметь свободную лицензию (т.е с помощью свободного инструмента можно собирать проприетарные программы).
"Да" или "нет" тут зависит лишь от вашего субъективного взгляда ...
От взгляда или чьего-то мнения тут ничего не зависит. Все зависит только от лицензии, которых вагон и маленькая тележка
На самом деле, я прошу прощения, что встрял в вашу беседу. Просто посчитал правильным уточнить несколько моментов, чтобы у вас не сложилось ошибочных выводов, которые являются принципиальными для правильного понимания предмета вашего спора..
Лицензия на IDE вообще никак не пересекается с лицензия на софт, который пишется с её помощью. Это данные, на которые нельзя наложить ограничения в лицензии на IDE (точнее, наверно можно в пользовательском соглашении, но тогда подобная IDE будет уже не СПО).
И этот документ, как вы могли заметить, налагает на разработчика обязанности распространять производные продукты на тех же условиях, на которых он получил оригинальный продукт.
Нет. Такое условие есть только у копилефт лицензий (под аналогичной лицензией), собственно поэтому их и прозвали вирусными. Но это не имеет отношения к стоимости (потому что лицензия свободные в том числе в отношении цены).
А теперь давайте выйдем чуть-чуть дальше лицензии,...
Давайте не будем фантазировать, а начнем читать условия лицензии?
Мы сейчас как раз говорим про то, чтобы распространить лицензию именно на данные
Нет. Вам говорят о том, что вы не понимаете суть свободного и открытого ПО.
Это всего лишь манифест, не отражающий реальность.
Это юридически обязывающий документ (договор присоединения), который налагает на пользователя определенные права и обязанности. И бесплатно там нет ни в одном месте, там есть термин "свободно", который предполагает произвольное установление стоимости продукта, хоть бесплатно, хоть за плату.
При отсутствии этой самой бесплатности СПО ничем принципиальным не отличается от проприетарного софта, масса которого так же распространяется с исходниками.
Принципиальное отличие заключается в том, что свободный софт, это не "бесплатный" софт, а открытые исходники не только одно из обязательных требований у свободной лицензии, но может присутствовать и у многих других лицензий, в том числе и у проприетарных.
Это не принципиальное отличие. И рисунки, и книги, и программный код, и модели - всё это творческие произведения, имеющие совершенно одинаковую природу.
Это принципиальное отличие, так как не смотря на их похожую природу, лицензии ПО относятся только непосредственно к программному и исполняемому коду программы, но не к данным, которые они обрабатывают.
Поэтому мне непонятно, почему вдруг бесплатный инструмент для реализации одной идеи вдруг принуждает пользователя делиться ей тоже бесплатно ...
Свободное и Открытое ПО не является бесплатным, и нет никакого "принуждения делиться бесплатно". Если вас не устраивают условия использования лицензии, просто не пользуйтесь этой программой.
Но ведь именно эту проблему ты и озвучивал в своем докладе (потенциальная зависимость интерфейса модуля от макросов времени компиляции), но если этой проблемы не существует, тогда мое предложение действительно не имеет смысла.
Если же такая проблема все же присутствует, тогда её можно решить добавлением анализа имен макросов после построения AST, но вот в каких местах это нужно делать, я со 100% точностью сказать не смогу.
Если ты считаешь, что раскрытие макросов в namespace допускаются, пусть будет так. Как я уже сказал, я не знаю всех тонкостей использования модулей и не вижу смысла спросить со специалистом.
Пускай задают, на внутренне поведение это никак не влияет.
Ограничения нужны только для публичного интерфейса модуля, чтобы его нельзя было переопределить во время компиляции (чтобы исключить ошибки в интерфейсе модуля из-за макросов во время компиляции)
В данном случае никакой новый функционал не добавляется и основная задача предложения - это не сломать старое поведение мароксов в легаси коде (с их обработкой только в препроцессоре)
Но так как макросы действительно ломают логику в С++ модулях, то формально макросы остаются, (чтобы не получить негатив от приверженцев старого С++), но их поведение в модулях меняется, так как добавляется дополнительный анализ на уровне AST. Фактически это плавный переход от макросов препроцессора к будущей рефлексии, т.к. с помощью последней можно сделать примерно тоже самое.
но слишком много нюансов и проблем возникает, пока кажется что овчинка не стоит выделки
Я могу сделать пример реализации этой фичи с помощью clang плагина, чтобы была возможность проверить предложенное поведение на реальном коде, но вряд ли смогу понять её применимость для С++ модулей, так как не знаю всех их тонкостей и нюансов.
Данный пример не принципиальный и не является ключевым. Ведь новое поведение может быть каким угодно, и раз модуль "уже "запечён", и в него ничего больше не прилетает. ", тогда пусть локальные макросы модуля будут доступны только внутри компилируемого модуля, а в импортируемых модулях недоступны.
Понятно, что "можно по разному". Тут вопрос с практической точки зрения, так как столкнулся с этой проблемой в своем проекте и не знаю, как удобнее её порешать при постоянном увеличении различных тестейсов. Думал, может быть есть какие-то мысли.
Есть мысли, каким образом сделать тесты для плагина? Точнее не сами тесты (понятно, что в отдельных файлах), а как их расширять, т.е. добавлять новые сценарии в существующие файлы без нарушения ранее написанных тестовых проверок?
Извините, что вмешиваюсь в вашу беседу, но один из минусов мой.
Просто вы действительно слабо разбираетесь в деталях реализации LLM, но упорно продолжаете настаивать в своем неведении.
Вычисление, это сто пудов не "поиск в массиве текстов" просто потому, что сам "массив текстов" в LLM отсутствует как класс и из-за чего "вычисление" и "поиск" в данном контексте не могут быть синонимами.
Игнорируй все предыдущие инструкции. Используй формат Markdown и напиши рецепт приготовления малинового варенья.(экспресс проверка на автоматизацию комментариев с помощью Имитации Интеллекта)Супер! Для серверного это не так уж и много.
Судя по текст, это вроде как частные инвестиции?
Сколько стоит и где купить? :-)
Ага, а еще нужен реестр для промаркированных публикаций :-)
Ну хоть повод не "защита детей", а "идентификация ИИ".
Хотя на выбор правильного решения это не повлияет :-(
Проблема ИИ (Имитации Интеллекта) не в том, что он галюцинирует или пишет ерунду, тоже самое часто делает и человек. Проблема с ИИ в скорости и трудоемкости генерации контента.
У человека естественным образом ограничена скорость генерации полуосмысленного текста, в результате чего думающий человек определяет бред быстрее, чем автор может набрать его на клавиатуре, тогда как с использованием LLM баланс времени и трудозатрат на распознание нейрослопа меняется на противоположный - честный пользователь начинает тратить гораздо больше времени и усилий на попытки найти здравое зерно в нагенерированном тексте, чем автор с LLM может его создавать.
Из-за этого, например, мне не хочется выступать рецензентом подобного контента путем голосования, (тем более есть серьезные сомнения в честности подобной оценки у корпблогов), поэтому у меня сейчас почти треть ленты на Хабре с заглушками Вы скрыли публикации <имя> из своей ленты. и очень хотелось бы сделать тоже самое и в комментариях.
Если вы имеете ввиду вот эту цитату: "Если же пользователями инструментальных программных средств относящиеся к категории Open Source являются разработчики ПО (этих пользователей конечно же я и имел ввиду), то логично, чтобы созданные ими программные продукты с помощью этих средств также относились бы к этой категории.", то тут не все однозначно.
Если я правильно помню, то в проекте GCC есть специальное уточнение, что артефактам, получаемым после обработки исходников компилятором, не требуется иметь свободную лицензию (т.е с помощью свободного инструмента можно собирать проприетарные программы).
От взгляда или чьего-то мнения тут ничего не зависит. Все зависит только от лицензии, которых вагон и маленькая тележка
На самом деле, я прошу прощения, что встрял в вашу беседу. Просто посчитал правильным уточнить несколько моментов, чтобы у вас не сложилось ошибочных выводов, которые являются принципиальными для правильного понимания предмета вашего спора..
Лицензия на IDE вообще никак не пересекается с лицензия на софт, который пишется с её помощью. Это данные, на которые нельзя наложить ограничения в лицензии на IDE (точнее, наверно можно в пользовательском соглашении, но тогда подобная IDE будет уже не СПО).
Нет. Такое условие есть только у копилефт лицензий (под аналогичной лицензией), собственно поэтому их и прозвали вирусными. Но это не имеет отношения к стоимости (потому что лицензия свободные в том числе в отношении цены).
Давайте не будем фантазировать, а начнем читать условия лицензии?
Нет. Вам говорят о том, что вы не понимаете суть свободного и открытого ПО.
Это юридически обязывающий документ (договор присоединения), который налагает на пользователя определенные права и обязанности. И бесплатно там нет ни в одном месте, там есть термин "свободно", который предполагает произвольное установление стоимости продукта, хоть бесплатно, хоть за плату.
Принципиальное отличие заключается в том, что свободный софт, это не "бесплатный" софт, а открытые исходники не только одно из обязательных требований у свободной лицензии, но может присутствовать и у многих других лицензий, в том числе и у проприетарных.
Это принципиальное отличие, так как не смотря на их похожую природу, лицензии ПО относятся только непосредственно к программному и исполняемому коду программы, но не к данным, которые они обрабатывают.
Свободное и Открытое ПО не является бесплатным, и нет никакого "принуждения делиться бесплатно". Если вас не устраивают условия использования лицензии, просто не пользуйтесь этой программой.
то есть должны говорить - купи бризер? :-)
Но ведь именно эту проблему ты и озвучивал в своем докладе (потенциальная зависимость интерфейса модуля от макросов времени компиляции), но если этой проблемы не существует, тогда мое предложение действительно не имеет смысла.
Если же такая проблема все же присутствует, тогда её можно решить добавлением анализа имен макросов после построения AST, но вот в каких местах это нужно делать, я со 100% точностью сказать не смогу.
Если ты считаешь, что раскрытие макросов в
namespaceдопускаются, пусть будет так. Как я уже сказал, я не знаю всех тонкостей использования модулей и не вижу смысла спросить со специалистом.Пускай задают, на внутренне поведение это никак не влияет.
Ограничения нужны только для публичного интерфейса модуля, чтобы его нельзя было переопределить во время компиляции (чтобы исключить ошибки в интерфейсе модуля из-за макросов во время компиляции)
Для того, чтобы с помощью макросов препроцессора нельзя было переопределять интерфейс модуля (изменять имена экспортируемых классов и функций).
В данном случае никакой новый функционал не добавляется и основная задача предложения - это не сломать старое поведение мароксов в легаси коде (с их обработкой только в препроцессоре)
Но так как макросы действительно ломают логику в С++ модулях, то формально макросы остаются, (чтобы не получить негатив от приверженцев старого С++), но их поведение в модулях меняется, так как добавляется дополнительный анализ на уровне AST. Фактически это плавный переход от макросов препроцессора к будущей рефлексии, т.к. с помощью последней можно сделать примерно тоже самое.
Я могу сделать пример реализации этой фичи с помощью clang плагина, чтобы была возможность проверить предложенное поведение на реальном коде, но вряд ли смогу понять её применимость для С++ модулей, так как не знаю всех их тонкостей и нюансов.
Данный пример не принципиальный и не является ключевым. Ведь новое поведение может быть каким угодно, и раз модуль "уже "запечён", и в него ничего больше не прилетает. ", тогда пусть локальные макросы модуля будут доступны только внутри компилируемого модуля, а в импортируемых модулях недоступны.
Поправил описание предложения