- 1
гитхаб говно. Давайте ругать его-
Куча / Говнокод #25294
0
По этому я за SourceForge
Запостил:
3oJIoTou_xyu,
08 Января 2019
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Я просто гитхаб неосилил. Не нашел ебучию кнопку как добавить девилопидоров. Хотя в 16 году как-то добавил. А сейчас не нашел.
Вот в соурсфордж сразу нашел. По этому я за него, да он и гит и свн поддерживает и ручки.
Заходишь в репу, жмёшь settings -> collaborators.
Тем более в SourceForge тоже можно приватную сделать и сколько угодно чел. Да и нет ограничение на размер диструбутива.
Пока тут пейсали комментарии, они разрешили бесплатно соображать на троих в приватных репозиториях.
я раньше всё приватное держал на bitbucket, но потихоньку перелажу с него, ибо он кривой, как и все поделия Atlassian.
Для компаний и богатых (5€) разработчиков - уместно и полезно.
А так для мелкой питушни -- всё, что угодно сгодится.
Не нужно ничего разворачивать, сервис у них есть.
Туда GHC недавно переехал, им там система код-ревью больше понравилась, чем у Github.
В моём случае ответ простой: он умеет подсвечивать хаскель-код.
Битбакет не умеет, но внезапно начинает подсвечивать, когда включаешь blame. Видимо, эту часть другая команда делала. Короче, типикал Atlassian.
Пусть петухи и курицы - это шары (или кубы, если легче считать) диаметра S, струя - цилиндр диаметра D, ось которого удалена от центра шара на расстояние S1, насесты - цилиндры диаметра W.
Надо вычислить конфигурацию расположения насестов - множество точек (xs, ys) в плоскости стены курятника такое, что курятник размерами X, Y, Z может вместить максимальное количество петухов и куриц, весь помёт которых будет достигать только пола.
К сожалению, я слаб в математике, но идеи для старта местные математики могут почерпнуть в https://www.youtube.com/watch?v=CROeIGfr3gs.
Тупо почему-то не осилили написание программы такой сложности или не пробовали? (написано уже много пакетных менеджеров, писать свой, который отличается только хранением нескольких версий - лень)
Или авторы не могут протестировать корректную работу со всеми комбинациями зависимостей в декларируемом диапазоне из-за большой кобенаторной сложности (если мой пакет зависит от пяти пакетов, для каждого из которых допустимо по 10 версий, а эти пакеты в свою очередь зависят от двух пакетов каждый с допустимым диапазоном в 10 версий, то всего выходит 10^5 кобенаций допустимых версий пакетов, если мы все честные и используем только документированные возможности и 10^7 кобенаций допустивых версий всех пакетов, которые нужно проверить, если есть подозрение на использование недокументированного поведения), а при подходе с дублированием разброс версий заметно уменьшается, т.к. программист и пользователь по умолчанию устанавливают последние возможные версии зависимостей в системе, поведение для которых легко тестируется, нет багов от того, что уже установленные версии зависимостей образуют кобенацию версий, которая допустима, но не была протестирована?
Т.е., иными словами, на практике плохо работает декларирование диапазонов допустимых версий зависимостей.
Автор пакета A говорит, что подходят зависимости B1 версий [1; 10] и B2 версий [1; 10]
Авторы B1, B2 говорят, что им подходят зависимости C11, C12, C21, C22 версий [1; 10]
И так далее по графу зависимостей.
Значит A должен работать при всех комбинациях версий - декартово произведение диапазонов.
10 версий B1 * 10 версий B2 * 10 версий C11 * ...
В идеале достаточно протестировать 10 версий B1 * 10 версий B2. Хотя, это уже почти нереально.
Но на практике нельзя сказать, что комбинация A, B1, B2 будет вести себя как следует для произвольной версии C11, C12, C21, C22 даже если авторы B1, B2 протестировали все комбинации версий C11, C12, C21, C22.
Может, дело в каких-то "юридических" тонкостях документации или использовании недокумментированных функций; может -- в тонкостях императивной программы и несовместимостей из-за более низких уровней абстракции (скажем, все комбинации версий внутри A-B и внутри B-C работали нормально, но для какой-то комбинации A-B-C вдруг в стек попал толстый массив, и всё сломалось).
А дальше оказывается, что у пользователей установлен заранее весь спектр допустимых версий пакетов-зависимостей B, C, к которым доустановится наш пакет A.
Если устанавливать отдельно, будет высокая вероятность получить последние возможные версии A,B,C и у программиста, и у пользователя, который с большой вероятностью получит комбинацию, протестированную у программиста.
Оно не идиотское. Более того, apt умеет устанавливать несколько версий одной библиотеки, это вовсе не проблема (см. so version).
Что сложно сделать — так это линковать разные версии библиотеки в одно приложение. Если у тебя библиотека A использует C1, B использует несовместимую C2, а приложение E использует A и B, то мы в беде. Потому что
1. E может случайно передать объекты, созданные C1, в функции из C2, будет взрыв.
2. Динамический линкер разрешает ссылки на функции по именам, и имена в C1 и C2 могут конфликтовать.
Поэтому в дереве зависимостей у каждой библиотеки должна быть одна определённая версия.
Я примерно понимаю, как ЖС-серы решают проблему 2 — используют загрузчик, который грузит определённую копию из поддерева, а все символы живут в замыканиях. Но вот что происходит с проблемой 1?
Пример проблемы 1 из жизни: у меня было 2 библиотеки на C++, одна возвращала фьючеры (из стандартной библиотеки!), другая принимала фьючеры. Приложение передавало фьючеры из одной библиотеки в другую. Из-за бага системы сборки они собирались с разными версиями стандартной библиотеки (разница была в минорной версии). Программа зависала при вызове.
В C++ разрешили использовать несколько функций с одним именем, впихнув в их настоящее имя сигнатуру сигнатуры. Соответственно, ничего не мешает втиснуть в имя функции/класса ещё и версию библиотеки, всё равно эти шизофазийные имена никто не читает.
> E может случайно передать объекты, созданные C1, в функции из C2, будет взрыв
Это КГ/АМ и использование недокументированных внутренностей A/B или принципиально неразрешимая ситуация?
Передаст ли E несовместимую психозу, если будет честно пользоваться только интерфейсами A/B, а конфликт имён C1/C2 будет устранён способом, указанным выше?