Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"mergiraf - AST-оринтированный инструмент для трёхстороннего слияния в Git"	+/–
Сообщение от opennews (??), 14-Дек-24, 09:57
Опубликован релиз проекта mergiraf 0.4, развивающего драйвер для Git с реализацией возможности трёхстороннего слияния. Mergiraf поддерживает разрешение различных видов конфликтов при слиянии и может использоваться для различных языков программирования и форматов файлов. Возможно как отдельный вызов mergiraf для обработки конфликтов, возникающих при работе со штатным Git, так и замена в Git обработчика слияний для расширения возможностей таких команд, как merge,  revert,  rebase и cherry-pick. Код распространяется под лицензией GPLv3. В новой версии добавлена поддержка языков Python, TOML,  Scala и Typescript, а также проведена оптимизация производительности... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62402
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от pyphon (?), 14-Дек-24, 10:05	+2 +/–
Как я увидел функционал: 1. Обрабатываем код black`ом. 2. Прогоняем линтеры. 3. Задаём правила форматирования. 4. Прогоняем код black`ом. 5. Чтоб не жать одни и теже кнопки используем pre-commit. 6. ... 7. Profit. Никто в своём уме не будет тратить несколько дней на сведения одновременно нескольких веток с почти отрицательным результатом. Поэтому никто и не знает про эти инструменты, кроме нескольких деятелей искусства и науки от компьютерных наук.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #11

3. Сообщение от Аноним (3), 14-Дек-24, 10:20	–6 +/–
Дочитал новость до "развивается проект mergiraf. Этот написанный на Rust инструмент (занимает 21 MiB!)" и прекратил чтение.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #12, #29, #68

5. Сообщение от Аноним (5), 14-Дек-24, 10:25	+6 +/–
Мне понравилась вся суть продукта в одной картинке. https://mergiraf.org/img/scene_3.png из двух разработчиков эта штука сделала сиамских близнецов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (6), 14-Дек-24, 10:27	+7 +/–
Да, на дискету не поместится. Плак плак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #30, #49

7. Сообщение от Аноним (7), 14-Дек-24, 10:47	+1 +/–
Сильно не хватает такого инструмента. Постоянно конфликты в тех же resx файлах. Хотя там простейший xml.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

8. Сообщение от nilsys (?), 14-Дек-24, 11:20	+4 +/–
> ... примером чрезвычайно сложной системы. Сложные системы имеют одно общее свойство - они сложны - и вы не можете ожидать, что нужное сложное поведение возникнет само собой, случайно чего?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #42

10. Сообщение от Аноним (10), 14-Дек-24, 11:33	–3 +/–
Сайт OpenNET - не сайт сугубо для программистов, а об СПО в общем, для дилетантов тоже, для того, чтобы использовать СПО, не только можно не быть программистом, но и даже лицензию можно не читать. Более того, это один из крупных сайтов, и новости с него копируют на сайты самых разных тематик. Системы контроля версий - это не инструмент сугубо для программистов. Один мой знакомый документы ворда в них версионирует. Всё лучше, чем папочка с десятком файлов и потенциалом для путаницы. Отсюда - описание для непрограммистов. Программисты знают, что это и зачем нужно и так. А вот непрограммисты без пояснения скажут "какая-то мутная программистская хрень, мне не нужно", хотя в этот инструмент можно приделать и бэкенд для документов ворда при желании. Текст написан в субъективном и неформальном стиле. Как автор текста - мне и решать. Не казённым же официозом писать? В тексте присутствуют некоторые проблемы. В частности "направленный граф" по-русски будет ориентированным. Это потому, что я написал текст сначала на английском, потом дал задание нейросети улучшить его стиль, сохраняя контент, а потом дал ей же задание перевести на русский. Не смотря на применение нейросети, текст оригинальный. Преамбула для дилетантов тоже писалась мною. Собственно, нейросетью в основном именно она и была обработана с целью сделать более доступной для массовой аудитории. Потом сидел и правил текст на русском, но у меня крашнулся браузер и часть работы была потеряна. Пришлось восстанавливать из истории буфера обмена, через который копировал с вкладки с нейросетью. У нейросети, кстати, куча огрехов была, и я их видимо не все выловил (таких как оставшиеся слова "снимок" и "наборы изменений", ну уж нет, если "снимок" ещё более менее нормально, то "набор изменений" - это слишком длинно, не годится, давайте использовать просто не будем переводить компьютерные термины, промаркировав их английским, а снимки оставим фотографам). В процессе выяснилось, что значительный кусок, который я писал уже изначально на русском, потерялся, так как в буфер вообще не попадал. Так правка перевода термина DAG вообще вышла из фокуса, каюсь. Весь субъективный стиль, который вы видите в статье, включая КАПС и некоторые саркастические ремарки, намерен, его пришлось восстанавливать вручную там, где я считаю, что он нужен. Как автор статьи - имею право так считать, не находите? Когда свою статью будете писать на этот сайт (а у меня тут довольно много было статей опубликовано) - тогда и вы будете решать, стоит ли переводить терминологию или собственные существительные, что вы хотите сказать, какой стиль использовать, и какая правильная доза сарказма и его едкости. А когда статью пишу я - это мне решать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #22, #40

11. Сообщение от Аноним (11), 14-Дек-24, 11:40	+7 +/–
Каноникализаторы и editorconfig - не панацея. Он помогает уменьшить число конфликтов от того, что один разраб предпочитает одно, другой - другое, и у каждого редактор настроен по-своему. Но конфликты слияния проистекают не только из этого. Это ОГРОМНАЯ ГОЛОВНАЯ БОЛЬ, когда ты не можешь заапстримить свои патчи, потому что апстрим - чудак. Самый ужас начинается, когда апстрим рефакторит структуру проекта одновременно с рефакторингом кода. В результате все файлы с твоими изменениями превращаются в почти сплошной конфликт слияния. ЗАПОМНИТЕ, ДЕТИ, ПЕРЕМЕЩЕНИЯ ФАЙЛОВ - СТРОГО В ОДНОМ КОММИТЕ, ЧИСТО ПОД ПЕРЕМЕЩЕНИЯ, А ИЗМЕНЕНИЯ ХОТЬ ОДНОГО СИМВОЛА КОДА - В ДРУГОМ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #16, #26

12. Сообщение от Аноним (11), 14-Дек-24, 11:48	–3 +/–
Вы уловили мой сарказм. В оригинале там было `(занимает целых 21 MiB!)`. На самом деле проект по исходникам всего-ничего занимает. С помощью нейросети вы сможете с весьма небольшими затратами переписать его на C++, на Си, на питон, на любой язык, какой вам нравится. Но зачем? Проект активно развивается. У меня план получше. Вместо переписывания проекта на Rust мы заменим Cargo на CMake. Если выкинуть всё дерево статически-линкуемых зависимостей, заменив его на сишные динамически-линкуемые библиотеки, сильно должен похудеть. И компилятор Rust можно вызывать из командной строки. Cargo - не особо нужен. Можно с небольшими затратами запилить полную поддержку Rust для CMake. Я имею в виду без участия Cargo вообще в каком-либо виде. И программить как на сишке. Программы должны от этого сильно похудеть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #13, #34, #98

13. Сообщение от Аноним (11), 14-Дек-24, 11:53	+1 +/–
>Проект активно развивается. Я имею в виду, что ну вот вы перепишете проект на си. А дальше что? Разрабы запилят ещё десяток функций и перелопатят архитектуру. И вам придётся всё это портировать. Причём уже не нейросетью, а почти вручную, чтобы не превратить историю коммитов уже ВАШЕГО проекта в говно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #31

14. Сообщение от Аноним (11), 14-Дек-24, 12:05	+/–
Ещё забыл написать в статью парочку своих мыслей (тоже уже написанных, но потерянных при краше). Нужен инструмент для применения патчей. Для этого патчи надо как-то хранить. Патчи gumtree привязаны к оригинальному исходнику. Соответственно, для сериализации патчей в файл придётся сохранять оригинальный исходник в каком-то виде, чтобы патч применить даже на изменённый исходник. Вы заметьте: инструмент делает строго трёхстороннее слияние. Потому что для понимания семантики важно понимать, что изменилось, а что сохранилось. Соответственно, для патча между двумя файлами нужно будет сформировать синтетическую базу на основе обеих версий. Файл патча должен содержать в себе как эту синтетическую базу, так и изменения поверх этой синтетической базы. При этом, синтетическую базу можно в некоторой степени подрезать, заменяя части, соседи которых не были затронуты, на плейсхолдеры. Но важно понимать - любая подрезка дерева обрезает возможности применения патчей в случае, если обрезанные части будут перенесены в другое место дерева или переименованы. Как компромисс можно обрезаемые части векторизовать с помощью нейросети, и хранить именно векторы.
Ответить | Правка | Наверх | Cообщить модератору

16. Сообщение от Аноним (5), 14-Дек-24, 12:17	+4 +/–
Если проект нормально административно устроен все перемещения делает один человек он же по совместительству самый главный человек. Все остальное делают остальные люди и слушают что говорит главный человек. Все остальные перемещатели в очереди на прием к главному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #62

18. Сообщение от Анониссимус (?), 14-Дек-24, 12:27	+4 +/–
Звучит интересно! Использовать это я, конечно, не буду...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

19. Сообщение от eugener (ok), 14-Дек-24, 12:29	+2 +/–
вот-вот, я тоже с интересом прочитал и то же самое подумал.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

21. Сообщение от НейроАноним (?), 14-Дек-24, 12:32	+3 +/–
- Опубликован релиз проекта Mergiraf 0.4 с поддержкой трёхстороннего слияния и разрешения конфликтов в Git. - Mergiraf поддерживает различные языки программирования и форматы файлов, а также может использоваться как отдельный инструмент для обработки конфликтов. - В новой версии добавлена поддержка Python, TOML, Scala и TypeScript, а также оптимизация производительности. - Программное обеспечение иллюстрирует эволюцию сложных систем, где каждая версия представляет собой набор функций, а изменения — мутации, формирующие граф. - Snapshot-ы, полученные в результате слияния коммитов, сложно обрабатывать, что приводит к необходимости избегать их. - Современные системы контроля версий, такие как Git, организуют snapshot-ы в виде ориентированных ациклических графов, что помогает создавать семантически значимую историю проекта. - Проблемы построчного алгоритма могут привести к нерабочему коду при слиянии изменений, и разработчику необходимо вручную разрешать конфликты. - Для применения патчей необходим инструмент, который будет хранить патчи, привязанные к оригинальному исходнику, с сериализацией оригинала. - Инструмент должен выполнять трёхстороннее слияние, учитывая изменения и сохранённые элементы, с возможностью оптимизации синтетической базы.
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от НейроАноним (?), 14-Дек-24, 12:36	+4 +/–
Да вы что! У вас в голове полный бардак! Сайт OpenNET – это не просто сайт для каких-то бездельников или дилетантов! Он создан для людей, которые хотят знать больше, хотят развиваться, а не для тех, кто сидит с пивом на диване и не понимает, что происходит в мире технологий. Системы контроля версий - это не игрушки для программистов, это инструменты для всех, кто хочет организовывать свою работу! Вы думаете, что только программистам нужны такие решения? Да нет, любой нормальный человек, который хоть раз создавал документы, поймет, как это полезно! Забудьте о стихийном беспорядке на вашем компьютере, а используйте нормальные системы, которые упрощают жизнь! Ваши попытки сделать это "доступным" и "простым" - это просто отмазка! Настоящий специалист должен уметь разбираться в терминах и алгоритмах, а не прятаться за множеством неуместных шуток и сарказма. Если вы хотите, чтобы вас серьезно воспринимали, ведите себя соответственно! А ваша "невежественная" лень в отношении перевода и терминологии – это просто позор! Вы пишете, как будто вся эта информация для какого-то абсолютного идиота, который не знает, что такое "ориентированный граф"! Человек, который хочет учиться, сможет разобраться, а не будет плюнуть на всё и говорить, что это "программистская хрень"! Так что, хватит уже оправдываться! Беритесь за ум и начинайте писать так, чтобы каждому было понятно – и программисту, и простому пользователю! Никаких отговорок!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #23

23. Сообщение от freehck (ok), 14-Дек-24, 13:03	+1 +/–
> Сайт OpenNET – это не просто сайт для каких-то бездельников или дилетантов! Отличная формулировка. То есть, всё-таки для бездельников и дилетантов. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #36

24. Сообщение от Вы забыли заполнить поле Name (?), 14-Дек-24, 13:41	+2 +/–
Когда в описании к софтине начинает объясняться почему она такая сложная, то кажется, что дальше можно не читать.
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от fuggy (ok), 14-Дек-24, 13:41	+1 +/–
А какая разница в скольких коммитах сделано перемещение и рефакторинг. Ведь мержим мы всё равно с итоговым результатом. То есть конфликты будут уже на этапе с перемещением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #38

27. Сообщение от Аноним (43), 14-Дек-24, 13:43	+/–
В разрабатываемой ветке устраивают параллельную реальность, а потом она не мержится в основную (продакшеновую), потому что в ней уже половина кода из разрабатываемой. Ясен пень, нужны сложные инструменты. Вместо того, чтобы ответственных за возникновение такой ситуации выгнать из профессии с волчьим билетом! Из моей собственной практики, манагерам абсолютно пофиг, что программисты делают в гите. Рак с ветками разводят сами разработчики, по собственной же инициативе. Попытки прекратить бардак всячески саботируют. "Мне сказали в прод сделать хотфикс и я зделол" brainlet.png Кому любопытно, нужно иметь ровно одну разрабатываемую ветку и никогда не пихать в основную дублируя коммиты (вместо этого фиксы в разрабатываемую и чери пих из разрабатываемой в основную). Чтобы это получалось, нельзя допускать серьезных расхождений между разрабатываемой и основной. Ломающие изменения в разрабатываемой - значит должен произойти релиз (основная подтягивается до этой редакции). Тогда фиксы легко зайдут черипиком из разрабатываемой. В 99.9% проектов не нужно никаких более сложных процессов. Кому интересно, это адаптация транковой модели "для тупых". Саму транковую модель народ массово неверно интерпретирует, разводя старый добрый рак с параллельными реальностями. >ответов на вопросы вроде "Зачем была введена эта низкоуровневая деталь (например, переменная)?", В переменной хардкодятся креды или эндпойнт апи, какое значение должно зайти? И тому подобный кретинизм.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

29. Сообщение от Аноним (-), 14-Дек-24, 13:49    Скрыто ботом-модератором	+/–
> Дочитал новость до "развивается проект mergiraf. Этот написанный на Rust > инструмент (занимает 21 MiB!)" и прекратил чтение. У питонистов и хрустиков есть кое-что общее: они пафосно решают навороченными тулсами какие-то совершенно левые задачи - решение которых кроме них никому нахрен не вперлось, навертев каких-то баззвордов, фреймворков, и будучи железно уверены что все это - круто. Хотя название у проекта прикольное конечно. Что-что, жираф для мержей? Это для тех до кого долго доходит чтоли? Хотя да, у этих проблема с заменой пробелов на табы будет, конечно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

30. Сообщение от adolfus (ok), 14-Дек-24, 13:52	–1 +/–
Причем тут дискеты? Программа всегда загружается в физическую память и всегда там занимает места больше, чем на диске. Соответсвенно, всем остальным зело плохеет и все притормаживается из-за ужимания буферов и возросших в связи с этим обращений к дискам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #33, #91, #97

31. Сообщение от Аноним (57), 14-Дек-24, 13:54	+/–
Вы один из разработчиков? Скажем так, если ваш проект будет успешно собираться посредством gccrs, то портировать его я ни на что не буду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #41

32. Сообщение от fuggy (ok), 14-Дек-24, 14:00	+1 +/–
Это новость или словоблудие. Какие-то рассуждения с введением в историю тулзов. Этому не место в новости. А вот примеров как включить и настроить или полный список языков и возможность добавить свой язык можно было добавить. > слияние же - это почти как rebase, просто структурирует граф коммитов по-другому, в результате чего им становится неудобно манипулировать, поэтому от слияний стараются отказаться в пользу rebase-ов Сильное заявление. Разводить холивар я не буду, но у ребейзов свои проблемы, потому что это переписывание истории. Я понимаю почему для лучшего применения этой тулзы хорошо когда изменения идут одно за одним. Почему бы тогда не применить Patch theory и было бы отличное решение из смеси Darcs с математическим подходом на основе популярного git. Я определённо попробую это в деле. Список поддерживаемых языков больше чем написано в новости. Но кто гарантирует что после этого слияния проект будет билдится и работать также. Когда возникает конфликт при мерже это уже звоночек что нужно обратить внимание и вчитаться в код. Тут же это будет происходить тихо автоматом, а эвристики могут и ошибаться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #47

33. Сообщение от Аноним (6), 14-Дек-24, 14:01	+/–
Факт 1. У разработчиков обычно очень неплохое железо в связи с высокими зарплатами. Лично у меня 64 гига оперативочки, про OOM забыл как страшный сон, у меня весь рут "/" в tmpfs. Факт 2. Сабж висит в оперативке не 24/7, а во время мерджей, что происходит от силы 5 минут в день. Мой вопрос тебе: ты оперативку брал для того, чтобы любоваться ей, или чтобы использовать ее на максимум? Ты же надеюсь не покупаешь сервиз лишь для того, чтобы круглый год он пылился где-то на полке, а потом на новый год БОХАТО отведать оттуда оливье?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #35, #39, #57, #79

34. Сообщение от adolfus (ok), 14-Дек-24, 14:15	+3 +/–
"Если выкинуть всё дерево статически-линкуемых зависимостей, заменив его на сишные динамически-линкуемые библиотеки, сильно должен похудеть." Это такое всеобщее заблуждение относительно динамического связывания и статического. На самом деле все полностью наоборот. 1) Приложение с динамической линковкой занимает места в памяти больше, чем со статической. И если те .so, что оно загрузило в память, больше никем не используются, то по всем параметрам будет проигрыш. 2) Динамическая линковка требует дополнительных расходов на создание таблиц процедур и настройку при загрузке, плюс дополнительных расходов на косвенный вызов функций из .so в этих таблицах при каждом их вызове. 3) При первом вызове функции из даже загруженной в память другим приложением .so, динамический загрузчик делает достаточно сложную и требующую времени работу по выделению трех, как минимум трех страниц в памяти, где он разместит секции .text, .data и .bss для этой .so. На пользовательском уровне это лаг до нескольких секунд. Кстати, именно поэтому программа с динамической линковкой занимает больше места в памяти -- для каждой .so требуется своя такая, как минимум, тройка страниц. В программе со статической линковкой все, укладывается плотно и смежно, причем только то, что требуется программе -- не вся библиотека линкуется, а только та часть, к которой есть обращения. Так что если у вас есть .so, где есть помимо остального пара функций, типа преобразования градусов в радианы и наоборот, в память будет загружена вся .so, даже если кроме этих двух вы из этой .so ничего больше не используете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #44

35. Сообщение от Аноним (5), 14-Дек-24, 14:16	+4 +/–
А причем тут зарплаты. Нормальным разработчикам железо покупает работодатель. И уж нормальные разработчик как то обходятся без сабжевых костылей просто нормально организовывая работу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

36. Сообщение от Я не Аноним (?), 14-Дек-24, 14:20    Скрыто ботом-модератором	+/–
Но не для каких-то, а для вполне конкретных переписанных и зафиксированных. Все остальные бездельники и дилетанты идут лесом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

37. Сообщение от adolfus (ok), 14-Дек-24, 14:23	–1 +/–
> Сильно не хватает такого инструмента. Постоянно конфликты в тех же resx файлах. > Хотя там простейший xml. xml специально придуман, чтобы осложнить программистам жизнь и раздуть код, как и его младший брат -- json.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #53

38. Сообщение от Аноним (38), 14-Дек-24, 14:28	+2 +/–
Если файл просто 100%-перемещён, конфликтов именно с коммитом перемещения не будет, git поймёт, что изменение нужно перенаправить на другой файл. Когда же перемещение и рефакторинг свалили в кучу, то получаем дифф, где одна сторона /dev/null, и иди сам ищи, куда переместили. И вручную всё сливай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #54

39. Сообщение от Аноним (38), 14-Дек-24, 14:30    Скрыто ботом-модератором	+1 +/–
Ну раз у вас такая высокая зряплата, может вы всем нам по hi-end машине купите, каждому?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

40. Сообщение от adolfus (ok), 14-Дек-24, 14:31	+/–
> Системы контроля версий - это не инструмент сугубо для программистов. Один мой > знакомый документы ворда в них версионирует. Всё лучше, чем папочка с > десятком файлов и потенциалом для путаницы. Интересно, как бинарники можно в систех управления версиями (СУВ) хранить. Даже если .docx или .odt развернуть, то получится каталог из нескольких xml и бинарников, которые на сегодня никто из СУВ адекватно обрабатывать не умеет. Ну или я проспал лет десять-пятнадцать и за это время кто0-то что-то напсал на эту тему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #50, #100

41. Сообщение от Аноним (38), 14-Дек-24, 14:36	+/–
Нет, просто недавно провёл кое-какие эксперименты по компиляции программ без cargo (своих, без сторонних крейтов, с использованием сишных либ). Нет, gccrs нормально не соберёт вообще ничего. На данном этапе gccrs - это просто бесполезный хлам, который не может собрать тривиальнейшие программы по типу hello worldа. Я даже специально максимально её изувечил, насрав на все гарантии раста и обмазав unsafeом (в нём нет стандартной библиотеки раста - сюрприз! так что приходится на libc писать, с полным unsafeом, и и то не хватает фич (в расте всё очень сильно завязано на поддержку комилятора) даже для этого), чтобы gccrs компилировал. А он не компилирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #51

42. Сообщение от Аноним (-), 14-Дек-24, 14:50	–1 +/–
> чего? Чего чего? Пора повышать свой уровень образования, доводя его до минимально необходимого уровня для айтишника. В контексте этого твоего вопроса, я рекомендую начать с https://en.wikipedia.org/wiki/Complex_system Ещё я бы рекомендовал ознакомиться с теорией хаоса, хотя бы определение хаотической системы понять и переварить. Сложные системы, софт в частности, очень напоминают хаос, минимальные изменения в коде могут порождать сколь угодно масштабные изменения в поведении программы. Про "случайно" возникающее сложное поведение -- это к самоорганизации и эволюции. Системы выстроенные из людей, часто способны к самоорганизации и эволюции (часто настойчиво не в том направлении, которое задумано дизайнером системы), они могут через итеративный отбор небольших изменений сходится к какому-то новому состоянию. Инженерные же системы чаще наоборот, реагируют на минимальные изменения отказом работать. Но чем читать википедию, лучше конечно будет получить профильное образование, которое заложит все такие азы в голову, и не придётся потом сталкиваться с тем, что тебе непонятен текст рассчитанный не на PhD в Computer Science, а на заурядного хомяка от IT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #43

43. Сообщение от Аноним (43), 14-Дек-24, 15:02	+/–
Надо быть не "айтишником", а человеком со здравым смыслом и логикой. Программа не должна быть хаотичной системой. В ней не должна происходить самоорганизация. Написание кода - это проектирование и управление сложностью происходит как во время него, так и в процессе написания реализации. Применяя логику и здравый смысл всегда можно поддерживать сложность на приемлемом уровне. >непонятен текст рассчитанный не на PhD в Computer Science, а на заурядного хомяка от IT Применяя к написанию программ неприменимые понятия, ты расписываешься в фактической профнепригодности. пиэйчди блджад. Просто смехотворно!!! Техник с самомнением и корочкой, которую в наше время чатгпт получить может. Лет через 10 ты со своим детским пафосом будешь просто лишним ртом в экономике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #46

44. Сообщение от Аноним (38), 14-Дек-24, 15:08	+/–
1) если. А вы не используйте крейты - эта экосистема заточена под bloatware. Она годится только в мусор. Используйте сишные либы. 2) да, требует. С лихвой окупается уже тем, что программу не надо перекомпилировать при обновлениях либ. 3) при указании нужных -Wl,-z,now линковщика все либы будут загружены сразу при загрузке программы в память. Это считается best prectices и поэтому является настройкой по-умолчанию , так как это позволяет -Wl,-z,relro сделать GOT read-only. И вы проигнорили важный факт: при динамической линковке версия каждой библиотеки ровно одна. И насрать, если несовместима - это проблема апстрима и мейнтейнеров. А не программа-контейнер, всосавшая по десятку разных версий одной и той же либы ... и так для многих либ. И ещё: >если у вас есть .so, где есть помимо остального пара функций, типа преобразования градусов в радианы и наоборот, в память будет загружена вся .so такие простые функции (одно умножение, Карл!) обычно в хедерах и инлайнятся компилятором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #89

45. Сообщение от Аноним (50), 14-Дек-24, 15:37	+/–
>у ребейзов свои проблемы, потому что это переписывание истории Как-бы это "ненастоящие" истории. "настоящая" - это главная ветка. Во всех остальных можно хоть на ушах стоять, пока они не часть основной - всем на них вообще пофиг. >Я понимаю почему для лучшего применения этой тулзы хорошо когда изменения идут одно за одним Да не только этой. Иногда бывает удобно превратить часть истории (а иногда - и всю!) в кучу patch-файлов, отредактировать их скриптами, после чего эту кучу patch-файлов за-git-amить. Если у вас коммиты не выстроены в линию, то история будет переструктурирована.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #82

46. Сообщение от Аноним (46), 14-Дек-24, 15:37	+1 +/–
> Лет через 10 ты А ты, ничем от камнеукладчика отличаться не будешь со своим ийтишеством или думаешь за тебя чатгопота работать будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Аноним (50), 14-Дек-24, 15:41	+/–
>Когда возникает конфликт при мерже это уже звоночек что нужно обратить внимание и вчитаться в код. Тут же это будет происходить тихо автоматом, а эвристики могут и ошибаться. Да, меня, как автора новости, это тоже волнует слегка. Но несильно. Ты и для line-based алгоритмов слияния сможешь влёгкую придумать случай, когда код сломается. От перебазирований и слияний это никого не останавливает. Этот риск просто принимают. Указанный же инструмент дополнительного риска не несёт: он фактически просто делает слияние в конфликтных регионах, которые на самом деле не конфликтные, а просто алгоритм на основе строк слишком тупой для них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #90

48. Сообщение от Аноним (50), 14-Дек-24, 15:45	+/–
Слушай, вот ты контрибьютер. Ты сделал изменение для себя. Послал Pull Request. Мейнтейнер-судак тебя игнорил 5 лет, а потом закрыл твой Pull Request со словами "мне лично - не нужно". При этом он продолжал развивать проект у себя в репозитории, постоянно gkjlz rjyakbrns. АО каких процессах тут речь идёт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #65

49. Сообщение от Аноним (49), 14-Дек-24, 15:46	+2 +/–
Он и на болванку не поместится, если со всеми ржавозависимостями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

50. Сообщение от Аноним (50), 14-Дек-24, 15:48	+/–
Очень просто. Они хоть и не пребазируются и не диффятся, но как бекапы с меньшим геморроем - сойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #52, #77

51. Сообщение от Аноним (57), 14-Дек-24, 15:52	+/–
Я не имел ввиду, вот прямо сейчас. Когда в GCC заявят, что теперь готов, хотя бы для сборки модулей ядра, когда они на Расте появятся, и хоть каких-то юзерспейсных библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

52. Сообщение от adolfus (ok), 14-Дек-24, 16:09	+/–
> Очень просто. Они хоть и не пребазируются и не диффятся, но как > бекапы с меньшим геморроем - сойдёт. Ну разве только для этого. Я пару лет назад, когда была одна работа, связанная, в том числе и с разработкой кучей программной документации по GOST19, использовал git для .odt. Но для большего удобства (для diff) дополнительно делал с помощью odttotxt для каждого .odt текстовый файл, а сам  .odt заворачивал в tar, чтобы метаданные не потерять. Плюс все рисунки отдельно от .odt рядом держал. Каждый коммит сопровождался сообщением. В принципе, работало более менее. Но если бы был нормальный xmldiff, то все было бы гораздо проще. Увы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #66, #78

53. Сообщение от Аноним (5), 14-Дек-24, 16:32	+/–
Чем заменить плейнтекстом? Или нейросетями файлы читать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #55

54. Сообщение от Аноним (54), 14-Дек-24, 16:35	+/–
А если не гит? или эта поделка только и гитом работаь умеет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #59

55. Сообщение от Аноним (54), 14-Дек-24, 16:36	+/–
а чатгпт закинул свой файл и попросил отформатировать. чем не  "я у мамы погромист"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

57. Сообщение от Аноним (57), 14-Дек-24, 18:03	–1 +/–
>У разработчиков обычно очень неплохое железо в связи с высокими зарплатами. Лично у меня 64 гига оперативочки Ну это про корполративных разработчиков проприетарщины. А если раработчик опенсорсного проекта? >у меня весь рут "/" в tmpfs Тут напрашивается известный в интернетиках мем: "Чегооооо, .ля?!" Проблема курицы и яйца, однако.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #94

58. Сообщение от YetAnotherOnanym (ok), 14-Дек-24, 18:04	–1 +/–
Мержей быть не должно. Вообще. От слова "совсем". То есть абсолютно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64, #72

59. Сообщение от Аноним (59), 14-Дек-24, 18:16	+5 +/–
> А если не гит? А если не гит, то там с большой вероятностью один разработчик, и конфликты у него только с бабушкой, да и те на счёт того когда спать идти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #71

62. Сообщение от Аноним (62), 14-Дек-24, 19:49	+1 +/–
какие ещё остальные люди? все остальные рабы делают всё остальное
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #73

63. Сообщение от xsignal (ok), 14-Дек-24, 21:00	+1 +/–
Что-то как-то слишком всё сложно, "трёхмерные шахматы" какие-то...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76

64. Сообщение от xsignal (ok), 14-Дек-24, 21:50	+1 +/–
100% Мержи - источник хаоса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

65. Сообщение от Аноним (43), 14-Дек-24, 22:14	+/–
Инструмент позволит легче мержить апстрим в свой форк? До первых структурных изменений в апстриме, но возможно. Все равно это капля в море по сравнению с корпоративной разработкой, где веткобесие принимает гротескные формы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #69

66. Сообщение от Аноним (66), 14-Дек-24, 22:49	+/–
> odt заворачивал в tar, чтобы метаданные не потерять. > то все было бы гораздо проще. Увы. Может, чуть проще будет с git-cache-meta или metastore. А может и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

68. Сообщение от Аноним (68), 15-Дек-24, 00:52	+/–
Кстати, интересно. Текст новости, похоже, целиком написан нейросетью. Может и сама утилита тоже? В весёлые времена живём!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #70

69. Сообщение от Аноним (71), 15-Дек-24, 08:27	+/–
Проблемы в Microsoft - это личные проблемы разработчиков, решивших связать себя с Microsoft. А также компании и их менеджемента. Мы тут причём? >До первых структурных изменений в апстриме, но возможно Да. Тут нужно трекать что происходит во всём проекте, а не на уровне отдельных файлов работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #88

70. Сообщение от Аноним (71), 15-Дек-24, 08:30	+/–
Текст любой новостной статьи написан нейросетью. Ещё в 1800-лохматом году так было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

71. Сообщение от Аноним (71), 15-Дек-24, 08:31	+/–
Мозилла с вами не согласна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #74, #96

72. Сообщение от Аноним (72), 15-Дек-24, 08:35	–1 +/–
fix> YetAnotherOnanym быть не должно. Вообще. От слова "совсем". То есть абсолютно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

73. Сообщение от Аноним (5), 15-Дек-24, 09:52	+1 +/–
Наконец то ты понял суть современного общества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

74. Сообщение от Аноним (5), 15-Дек-24, 09:54	+/–
Пора проснутся мозилла давно перешла на гит с меркуриала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #87

76. Сообщение от Аноним (5), 15-Дек-24, 10:02	+2 +/–
Что-то из разряда смотрите как я могу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

77. Сообщение от fuggy (ok), 15-Дек-24, 10:12	+/–
Они легко дифятся, достаточно прописать в git конфиге драйвер odt2txt. Но вот не мержаться, потому что бинарные файлы не имеют понятия строк и не получиться смержить просто объединив две последовательности. Поэтому документацию, если с ней предстоит много работать лучше хранить в markdown в репозитории. В случаи если всё же нужно много работать с бинарными файлами, то тут используем принцип из прошлого: лочим файл, чтобы никто другой в это время не мог с ним работать. Конечно git лочить не умеет, но вот git lfs что-то подобное может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #86

78. Сообщение от fuggy (ok), 15-Дек-24, 10:15	+/–
Не обязательно plain text трансформацию хранить как отдельный файл. Можно в конфиге тот же odttotxt драйвер указать и тогда при команде git diff они будет корректно отображать нужный diff.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

79. Сообщение от InuYasha (??), 15-Дек-24, 11:46	+/–
> лично у меня 64 гига оперативочки, про OOM забыл как страшный сон Вот уж похвастался - так похвастался :D Ну, давай и я тогда тоже - 256ГБ в проде и ООМ раз в 12 часов (в среднем). Сколько Жабу ни корми - всё равно мало будет. А для себя пишу софт, которому и 8МБ за глаза будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #95, #109

80. Сообщение от InuYasha (??), 15-Дек-24, 11:48	+2 +/–
Пишите сразу, в начале статьи, пожалуйста, что "здрасьте - на Расте". А то время только зря потрачено и надежды разбиты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #81, #83

81. Сообщение от Аноним (81), 15-Дек-24, 13:35	–3 +/–
Такие инструменты только на memory safe и нужно писать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

82. Сообщение от fuggy (ok), 15-Дек-24, 14:00	+/–
Ребейзы обманывают. Если разработчик написал строки +A +B, после ребейза может превратиться в несвязанные -B +C. И это всё попадает в мастер. В то время как мерж его видно сразу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

83. Сообщение от fuggy (ok), 15-Дек-24, 14:10	+/–
Не всё ли равно на чём внутри написано. Если есть бинарник, ты же не собираешься всё компилировать сам. А вот с python или go гораздо хуже. Там начинается веселье поставь pip, поставь go потом качай библиотеки сам которых не хватает. Не говоря уже про nodejs где цепочка может быть многоуровневым, поставь npm, через него поставь yarn, через него поставь webpack, ой на этой неделе вышел новый инструмент vite поэтому ставь его.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #85

85. Сообщение от Аноним (87), 15-Дек-24, 15:05	+/–
Нет, с питоном как раз проще всего. Там библиотеки ВСЕ динамические, статической линковки просто не существует в принципе (существует "вендорирование" - аналог включения чужого проекта в своё дерево исходников, за такое надо из профессии с волчьим билетом гнать), поэтому в большинстве случаев достаточно одного git-репозитория проекта, и одного git-репозитория с зависимостью из числа тех, что уже не были установлены раньше. Goвно же имеет ту же модель, что и Cargo, Bazel и npm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #102

86. Сообщение от Аноним (87), 15-Дек-24, 15:08	+/–
Доку вообще лучше иметь в markdown виде. Я первым делом когда имею дело с докой в других форматах конверчу её в markdown. Так удобнее прямо в текстовом редакторе с ней работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

87. Сообщение от Аноним (87), 15-Дек-24, 15:17	+/–
Да?! Открываем свежий баг, https://bugzilla.mozilla.org/show_bug.cgi?id=1933053 . Видим ссылку https://hg.mozilla.org/mozilla-central/rev/53607a3f25aa . `hg`, Карл!. Ну давайте перейдём, вдруг там гит под капотом? Ан нет, английским языком написано: `Mercurial`. А вдруг врут, и всё же git?! hg clone https://hg.mozilla.org/mozilla-central каталог назначения: mozilla-central applying clone bundle from https://hg.cdn.mozilla.net/mozilla-central/1083ef88fba7b6b77... добавляем наборы изменений Работает. Значит всё же Mercurial. Значит это увас неверная информация. Подозреваю, что вы с запрещённой в РФ социальной сетью перепутали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

88. Сообщение от Аноним (43), 15-Дек-24, 16:52	+/–
Корпоративная разработка - это в принципе любая коммерческая. Даже в проекте с тремя инвалидами комитерами в самой занюханной галере воссоздаются в меру понимания практики больших корпораций (если бы микрософт - было бы хорошо, там скорее что-то из фаанг, приправленное фентези о стартапах). В карго варианте, естественно. В частности, копируется практика использования так называемого гитфлоу, но без понимания, что в ее рамках делать можно, и что ни при каких условиях делать нельзя (дублировать коммиты). Эффективной работе с гитом не учат ни на хабре, нигде. Потому что никто не умеет, но все стесняются об этом говорить. Сплошь и рядом ситуации, когда проще дропнуть отставшую конфликтующую основную ветку и заменить ее разрабатываемой (или взять весь код при мерже из разрабатываемой). Понятно, что это не афишируется. Жаба в костюме с превеликим удовольствием об этом не докладывает. Проблема айти в том, что немножко обучают только программистов, и только программировать. Все остальные методики и практики либо по статьям в блогах, либо по корпоративному регламенту, написанному инфоцыганами от айти. Когда работают в основном тупые, все это приводит к удручающим результатам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

89. Сообщение от Аноним (-), 15-Дек-24, 16:57	+/–
> Используйте сишные либы. Сишные либы неспособны даже структуры данных экспортировать. Например, динамический массив. В каждой сишной программе, которой нужен динамический массив, есть своя собственная реализация его, и часто не одна (кто-то что-то сказал про блоатварь?). Иногда сишные либы экспортируют структуры данных, но это большая редкость, потому что как правило это приводит в рантайме к множеству лишних указателей и их разадресаций, а это кешпромахи, тормоза и никуда не годится. Или возьмём алгоритмы. Ты читал man 3 qsort? Вот почитай, и ужаснись тому, как неэффективно C библиотеки экспортируют алгоритмы. > С лихвой окупается уже тем, что программу не надо перекомпилировать при обновлениях либ. "это проблема апстрима и мейнтейнеров", не? > насрать, если несовместима - это проблема апстрима и мейнтейнеров. Ну это как сказать. Когда мейнтейнеры не дают тебе поставить более новую версию программы, потому что иначе сломаются депендансы к другой программе, то это уже твоя проблема. > такие простые функции (одно умножение, Карл!) обычно в хедерах и инлайнятся компилятором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #93

90. Сообщение от Аноним (-), 15-Дек-24, 19:42	+/–
> Указанный же инструмент дополнительного риска не несёт Я позволю себе не согласиться, пускай и чисто умозрительно (у меня нет конкретных примеров, сорри). Запоротый rebase/merge с большой (или хотя бы с большей) вероятностью приведёт к ошибке компиляции. Здесь же эти ошибки могут быть преодолены утилитой, и косяк останется незамеченным. То есть сама по себе идея инструмента очень интересна. Более того, я давно думаю о том, что могло бы быть полезно diff и hash реализовать с оглядкой на синтаксис, чтобы лишний, ни на что не влияющий пробел, не менял бы ни diff'ы, ни hash сорца. С этим конечно есть очевидные проблемы, с которыми бороться непонятно как лучше, но например можно нормализовать код, прежде чем коммитить, а форматирование хранить отдельно. В большинстве случаев лучше вовсе ничего не делать, пускай программисты работают с нормализованным форматированием, которое строго увязано с синтаксисом. Но как бы там ни было, разработчикам этого мержирафа следовало бы взять какой-нибудь большой реп с огроменной историей, восстановить там всю историю ребейзов и мергов, про каждый собирая информацию о ручном постпроцессинге конфликтов, а потом посмотреть как их утилита показала бы себя во всех этих случаях. Я, например, не знаю, что получится в результате, вижу три возможных сценария: 1. мержираф делает всё збс, снижая количество ручных устранений конфликтов и не создавая новых проблем 2. мержираф иногда усложняет ситуацию (например, скрывая какие-то баги от компилятора), но таких случаев немного, и их можно отогнать ограниченным количеством костылей, добавив эвристик, которые детектируют такие случаи 3. мержираф иногда усложняет ситуацию, но невозможно обойтись парой костылей как в (2), надо создавать неограниченно большое количество костылей, морально готовясь к тому, что в будущем эти костыли начнут странным образом накладываться друг на друга, приводя к совершенно неожиданным ситуациям. Так вот если замена человека мержирафом на всей git-истории ядра linux покажет, что в перспективе маячит сценарий (3), то мержираф бесполезен. Если возможно избежать сценария (3), то мержираф реально начнёт выглядеть перспективной тулзой. А до того, как такое исследование проведено, мержираф не более чем любопытная поделка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #99

91. Сообщение от morphe (?), 15-Дек-24, 21:55	+/–
В память программы паммятся в CoW режиме, соответственно за вычетом релокаций большая часть программы у тебя может загружаться лениво с диска, а раз у нас тут статическая линковка - областей памяти с релокациями тут минимум, а потому потребление тут будет меньше чем если бы эти 20мбайт были разбиты на несколько shared objectов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

92. Сообщение от Аноним (92), 15-Дек-24, 23:30    Скрыто ботом-модератором	+1 +/–
Почему эта ИИ-генерённая параша в новостях? Очевидно же, нормальный чел так не пишет - столько словоблудия, что нехватает только лирического отступления о том, как бабушка пекла яблочный пирог.
Ответить | Правка | Наверх | Cообщить модератору

93. Сообщение от Аноним (93), 16-Дек-24, 04:58	+/–
>"это проблема апстрима и мейнтейнеров", не? Не передёргивайте. Когда я сказал "проблема апстрима и мейнтейнеров", я имель в виду не то, что это проблема, какую они реашют, а нам о ней заботиться не надо. А то, что гнать поганой метлой таких апстримов и мэйнтейнеров, имеющих такие недостатки. >Ну это как сказать. Когда мейнтейнеры не дают тебе поставить более новую версию программы, потому что иначе сломаются депендансы к другой программе, то это уже твоя проблема. Проблема решаемая - берёшь и сам компилишь нужную зависимость. ломаемую программу - не ставишь, вообще в мусор её, если не сопровождается. Это если нужной программе нужна 146% новая версия. Если не нужна - просто используешь ту, что есть в репах. А вот когда программа жрёт память - это проблема не решаемая иначе, как выкинуть эту программу ффтопку и написать свою, и самому её сопровождать. А если что-то завязано на жрущий хлам - то и его переписать. Ну ты понял. Эта проблема - нерешаемая. В отличии от. >Сишные либы неспособны даже структуры данных экспортировать. Например, динамический массив. В каждой сишной программе, которой нужен динамический массив, есть своя собственная реализация его, и часто не одна (кто-то что-то сказал про блоатварь?). Вы от темы не отходите. Сишные либы используют для доступа к преаллоцированной памяти интерфейс указатель - размер. А если нужно управлять на стороне либы - либо коллбэки для аллокации/деаллокации вызывающей стороной, либо проброс mallocа, с которым либа компилировалась через публичное API. Не проблема в общем. >Иногда сишные либы экспортируют структуры данных, но это большая редкость, потому что как правило это приводит в рантайме к множеству лишних указателей и их разадресаций, а это кешпромахи, тормоза и никуда не годится. Что вы имеете в виду? Любые структуры данных построены на указателях. Если это не шаблоноbloatware, построенное на экспоненциально и суперэкспоненциально большом количестве специализаций. Всё это критично только для числодробилок, а числодробилки вообще стараются всё почти чисто на регистрах делать. А если память нужна - обычно кастомный arena allocator. Обычно с выделением части регистров чисто под него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

94. Сообщение от Andrey (??), 16-Дек-24, 17:13	+/–
64Гб стоят чуть больше 100 долларов. Если опенсорсный проект хоть кому-то нужен, то разработчик может и донатами набрать, раз уж у него так туго с деньгами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #104

95. Сообщение от Andrey (??), 16-Дек-24, 17:23	+/–
Одно дело для себя писать, другое дело для большой аудитории.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

96. Сообщение от Аноним (96), 16-Дек-24, 18:18	+/–
Один проект оставшийся на недо-vcs никому не интересен. Просто он не будет пользоваться mergiraf'ом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #105

97. Сообщение от Аноним (96), 16-Дек-24, 18:28	+/–
> Причем тут дискеты? Программа всегда загружается в физическую память и всегда там занимает места больше, чем на диске Нет, не всегда и не всегда. Программа mmap'ится, при этом не обязательно все страницы подтягиваются в физическую память, а выглядит страница в памяти и на диске совершенно одинаково, поэтому занимает столько же места. Много это или мало для бинарника - хороший вопрос, и посчитать ответ на него сложно. По крайней мере то что россыпь сошек, которая не факт что используется более чем одним проектом, которую дольше загружать со всего диска и которая не поддаётся LTO как статически собранный код, эффективнее, совсем не очевидно. Но никто это не считает потому никого кроме некомпетентных параноиков видящих только циферки, а как оно работает не имеющих даже приблизительного представления, размеры бинарников в десятки мегабайт не беспокоят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

98. Сообщение от Аноним (96), 16-Дек-24, 18:34	+/–
> Программы должны от этого сильно похудеть. Схрена ли это они должны похудеть? Зависимости от этого куда-то денутся? Сишный хелловорлд весит меньше потому что у него рантайм в отдельной сошке, с сошкой он весит больше чем растовый бинарник на порядок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

99. Сообщение от Аноним (99), 16-Дек-24, 21:14	+/–
>Но как бы там ни было, разработчикам этого мержирафа следовало бы взять какой-нибудь большой реп с огроменной историей, восстановить там всю историю ребейзов и мергов, про каждый собирая информацию о ручном постпроцессинге конфликтов, а потом посмотреть как их утилита показала бы себя во всех этих случаях. 1. Для этого нужно серьёзное финансирование. 2. Как я уже сказал, многие конфликты слияния корректно разрешимы только на уровне всего проекта. То есть с переименованием символов глобально, или вообще реструктуризацией файлового дерева. А также дописыванием кода, примиряющего логически конфликтующие вещи, но не конфликтующие даже на уровне строк. Простейший пример - доступ к общему ресурсу. Последовательный, в одном потоке. И на сишке. Где в в каждой из веток этот ресурс для одного захватывается в одном месте, а освобождается после, но как только - так сразу. Ветка А SharedResource *x; AAAA BBBB CCCC DDDD GGGG *x = acquire(); // a HHHH EEEE aaaa // a FFFF JJJJ KKKK LLLL MMMM NNNN dddd // a OOOO PPPP free(x); // a QQQQ Ветка Б SharedResource *x; AAAA *x = acquire(); // b BBBB CCCC bbbb // b DDDD GGGG HHHH EEEE aaaa // a FFFF JJJJ cccc // b KKKK LLLL free(x); // b NNNN OOOO PPPP QQQQ Автоматическое слияние (на уровне строк, заметь!) SharedResource *x; AAAA *x = acquire(); // b BBBB CCCC bbbb // b DDDD GGGG *x = acquire(); // a HHHH EEEE aaaa // a FFFF JJJJ cccc // b KKKK LLLL free(x); // b MMMM NNNN dddd // a OOOO PPPP free(x); // a QQQQ И тут же сразу комбо: * утечка ресурса в *x = acquire(); // a * double free в free(x); // a * use-after-free в dddd // a * потенциал для дедлока, если ресурс - мьютекс И без всяких мердж-жирафов и латексоносных молочаев! А вариантов корректного разрешения может быть множество. От переиспользования захваченного ресурса, до разбитие на ветки, Никакой инструмент без AGI тебе такие конфликты мало того что не разрешит, а даже не сдетектирует. Отседова, как сказано в статье: merge considered harmful. Вместо этого 1. в мастер перебазируют сначала одну из веток 2. автор второй ветки перебазируют свою ветку поверх мастер, и проверяет её 3. в мастер перебазируют её. Инструмент на основе AST позволяет делать такие перебазирования с меньшей болью. Поэтому - нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #107

100. Сообщение от нах. (?), 16-Дек-24, 23:39	+/–
Ты больше проспал. Название я уже давно забыл за ненадобностью, но такая софтина существовала этак в 2010м. А, ну да, ну да - под винду и разумеется платная (причем как-то сильно платная, без лицензий для ло... частных лиц) Делала именно это - diff/merge офисных форматов. (естественно - в человекочитаемом виде а не вот тебе два xml с блобами - на какой сам сядешь, на какой мать посадишь?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

102. Сообщение от Аноним (102), 17-Дек-24, 09:44	+/–
Вендорирование возникло из-за требований к повторяемости сборки. А как ты повторишь сборку обычного проекта, если автор leftpad свой проект удалил, заблокировал или вставил постороннюю функциональность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #103

103. Сообщение от Аноним (105), 17-Дек-24, 13:18	+/–
А я хочу именно НЕ-ПОВТОРЯЕМОСТЬ, когда Я ЛИЧНО контролирую зависимости, а не автор пакета за меня решает, какой блоатварью меня накормить. Кому нужно обеспечить для своего пакета "повторяемость" - могут её легко достичь без вендорирования, просто записав все версии всех зависимостей в requirements.txt, который, к счастью, необязателен. Кому она нужна из пользователей - могут просто поставить всё в виртуальное окружение (всё равно для прода вся эта "повторяемость" абсолютно неприменима и годится только для игр вида "в повторяемой сборке тесты проходят - а мы иного и не обещали, wontfix, notabug").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #106, #108

104. Сообщение от Аноним (105), 17-Дек-24, 13:21	+/–
Опенсорсный проект, за который пользователю хоть цент платить придётся, никому не нужен. Так что тот дебил, который написал программу, требующую от каждого пользователя по "$100" (на самом деле намного больше, и есть вещи, которые ты даже за лимон не купишь), не наберёт донатов даже себе на кофе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #111

105. Сообщение от Аноним (105), 17-Дек-24, 13:25	+/–
А вот в этом ты ошибся, в обеих пунктах. >Один проект оставшийся на недо-vcs никому не интересен. Сам, небось, с Файрфокса сидишь. Если не с Файрфокса, а с Хрома, то с тобой общаться вообще смысла не имеет. >Просто он не будет пользоваться mergiraf'ом. К гиту гвоздями mergiraf не прибит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

106. Сообщение от Аноним (-), 17-Дек-24, 13:35	+/–
> А я хочу именно НЕ-ПОВТОРЯЕМОСТЬ, когда Я ЛИЧНО контролирую зависимости, а не автор пакета за меня решает, какой блоатварью меня накормить. Твои хотелки - твои проблемы. Пример либы XZ показывает, что тебе могут подсунуть специальный пакет и ты его получишь прям от мейнтенеров дистрибутива.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

107. Сообщение от Аноним (-), 17-Дек-24, 22:14	+/–
> Для этого нужно серьёзное финансирование. Зачем? Для этого не потребуется какого-то особого железа, кордвадуо справится легко. Единственная проблема, которая может встать, это автоматизация процесса: я не уверен, что можно извлечь из git историю ребейзов и восстановить ручные правки, которые при этом проводились для разрешения конфликтов, не копаясь в списках рассылки чтобы извлечь оттуда патчи, отслеживая при этом чётко коммиты, на которых патчи разрабатывались и на которые они потом ребейзились. Но с мергами должно получиться, а это значит что процесс полностью автоматизируется. При этом по большей части автоматизируется и сравнение результата работы мержирафа с git-merge+ручные-разрешения-конфликтов. Если результат совпадает побайтово, или может не побайтово, а после минификации (чтобы пробелы и коменты не мешали), то мержираф отработал свои обещания, если не совпадает, то надо заглянуть и посмотреть. Это вот дело тянет на курсовую работу, вряд ли на дипломную. Вот если добавить разбор случаев, когда мержираф фейлится, классификацию этих случаев, и не только по одному проекту/одному языку, а по нескольким проектам на разных языках, то это уже стопроцентов будет дипломной работой или может даже кандидатской, тут сложно судить наперёд, потому что неясно какие трудности на пути возникнут. Ежегодно огромные тысячи студентов пишут курсовые и дипломные работы _бесплатно_. Проблема лишь в том, чтобы заловить студента и уболтать его заняться этой темой. Это правда при условии, что тот найдёт себе научрука, который будет отвешивать ему оплеух, когда тот ленится. Это вот чувака пишущего диссертацию сложнее заловить, потому что тот будет губы раскатывать на гранты, и вероятно его научрук может ему подкинуть этих грантов, а значит и выбор темы для него не совсем произвольный. > Никакой инструмент без AGI тебе такие конфликты мало того что не разрешит, а даже не сдетектирует. Это слишком общее высказывание, оно не может быть верным. Есть древняя техника, позволяющая такие проблемы решать, и она называется "структурное программирование". Зырь: Mutex<SharedResource> res; ...    res.run_lambda_with_exclusive_access_to_inner(|exclusive_handle_to_res| {        exclusive_handle_to_res.use();    }); merge-конфликтов это не снимет, конечно, но зато оно насоздаёт тебе merge-конфликтов там, где чисто итеративный код на одном уровне выравнивания смержится молча. Того же результата можно достигать макросами, причём даже в C: LOCK_MUTEX { } UNLOCK_MUTEX #define LOCK_MUTEX бла-бла-бла; do #define UNLOCK_MUTEX while(0); бла-бла-бла; Другое дело, что если структурное программирование не используется для таких вещей, то потребуется статический анализатор, который будет отлавливать ошибки автоматического разрешения конфликтов мергов, и возможно этот статистический анализатор должен быть если не AGI, то хотя бы специализированным AI, с возможностью и распознавания паттернов, и выстраивания формальных доказательств, и CoT. Мне вдруг стало любопытно, как интересно программисты на ассемблере ребазят и мержат, у них структурности вообще нет, и там вероятно даже при отсутствии конфликтов придётся весь код глазами проверять, чтобы убедиться что не случилось ничего кошмарного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #112

108. Сообщение от Аноним (-), 17-Дек-24, 22:21	+/–
> А я хочу именно НЕ-ПОВТОРЯЕМОСТЬ, когда Я ЛИЧНО контролирую зависимости "Ваше мнение очень важно для нас." Тот кто пишет код, тот и решает как ему удобнее обходиться с зависимостью. Тебе как потребителю остаётся только кушать, чем кормят. Впрочем, ты можешь выкинуть завендоренные версии, и попытаться использовать другие. В gentoo некоторые ebuild'ы позволяют такое без плясок с бубном, достаточно USE флаги правильные указать. Но я заверяю тебя, можно и без ебилдов, плясками с бубном, повесив себе на шею табличку "я не потребитель, кушаю что сам готовлю, а не то чем кормят". > всё равно для прода вся эта "повторяемость" абсолютно неприменима Она даёт тебе возможность пользоваться бинарными сборками, и в то же время проверять эти сборки на отсутствие дополнительных бекдоров внедрённых сборщиком. Ты можешь легко убедиться, что бинарь собран именно из этих сорцов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #113

109. Сообщение от Котофалк (?), 18-Дек-24, 01:23	+/–
Айтишников жаба не душит, а ставит на деньги. Прогресс неумолим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

111. Сообщение от Andrey (??), 18-Дек-24, 21:02	+/–
Почему с каждого? Всего 100 баксов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

112. Сообщение от Аноним (112), 19-Дек-24, 10:55	+/–
> Зачем? Для этого не потребуется какого-то особого железа, кордвадуо справится легко. Если на Амазоне инстансы арендовать - да. Иначе вечность ждать придётся. >Единственная  проблема, которая может встать, это автоматизация процесса Без оплаты никто и не почешется на эту тему. Тестировать неинтересно. >: я не уверен, что  можно извлечь из git историю ребейзов Зафетчить pull-requestы через API. >не копаясь в списках рассылки Почти всё на гитхабе разрабатывается. > если не совпадает, то надо заглянуть и посмотреть. Кто будет? Без оплаты - никто и не почешется. > Это вот дело тянет на курсовую работу, вряд ли на дипломную. Вот если добавить разбор случаев, когда мержираф фейлится, классификацию этих случаев, и не только по одному проекту/одному языку, а по нескольким проектам на разных языках, то это уже стопроцентов будет дипломной работой или может даже кандидатской, тут сложно судить наперёд, потому что неясно какие трудности на пути возникнут. Сомневаюсь. Кандидатская всё-таки подразумевает хоть-какую-то научную новизну. > Ежегодно огромные тысячи студентов пишут курсовые и дипломные работы _бесплатно_. Проблема лишь в том, чтобы заловить студента и уболтать его заняться этой темой. Студенты и аспиранты обычно на научрука вкалывают. >> Никакой инструмент без AGI тебе такие конфликты мало того что не разрешит, а даже не сдетектирует. > Это слишком общее высказывание, оно не может быть верным. Есть древняя техника, позволяющая такие проблемы решать, и она называется "структурное программирование". Зырь: Да знаю. Но вот есть сишники головного мозга. У них проект на Си, и почти всегда написан очень грязно - те, кто пишет в энтерпрайзном стиле, давно на Java, C# и C++ перебрались. >Того же результата можно достигать макросами, причём даже в C: За макросы гнать надо взашей. Они обфусцируют структуру исходника. Каждый макрос - это потенциально часы отладки, где всё ясно становится только когда задолбанный в край программер решит сказать компилятору раскрыть препроцессор и начнёт копаться в этой простыне. > Мне вдруг стало любопытно, как интересно программисты на ассемблере ребазят и мержат Подозреваю, что никак. Один файл просто одним человеком редактируется в один момент времени. А коммит идёт fast-forwardом. И ничего сливать не надо. В следующий раз, когда надо асм подправить - его открывают, и заново вникают в него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

113. Сообщение от Аноним (112), 19-Дек-24, 10:59	+/–
>Впрочем, ты можешь выкинуть завендоренные версии, и попытаться использовать другие Так и делаю. Больно, правда. >в то же время проверять эти сборки на отсутствие дополнительных бекдоров внедрённых сборщиком 1. Динамические библиотеки в отдельных пакетах как раз и дают 2. а проаудитить завендоренные бэкдоры, и их выковырять без пересборки - проблиматично. В вендоренный код вообще никто никогда не заглядывает. только те, кому его выковырять надо. Ито лишь постольку, поскольку надо для выковыривания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема