- 1
гитхаб говно. Давайте ругать его
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
гитхаб говно. Давайте ругать его
По этому я за SourceForge
Lorip1971 08.01.2019 12:10 # 0
3oJIoTou_xyu 08.01.2019 14:28 # 0
Я просто гитхаб неосилил. Не нашел ебучию кнопку как добавить девилопидоров. Хотя в 16 году как-то добавил. А сейчас не нашел.
Вот в соурсфордж сразу нашел. По этому я за него, да он и гит и свн поддерживает и ручки.
bormand 08.01.2019 14:32 # 0
Заходишь в репу, жмёшь settings -> collaborators.
3oJIoTou_xyu 08.01.2019 14:47 # 0
bormand 08.01.2019 14:49 # 0
3oJIoTou_xyu 08.01.2019 14:54 # 0
Lorip1971 08.01.2019 15:09 # 0
3oJIoTou_xyu 08.01.2019 15:26 # 0
Тем более в SourceForge тоже можно приватную сделать и сколько угодно чел. Да и нет ограничение на размер диструбутива.
Lorip1971 08.01.2019 15:45 # 0
1024-- 09.01.2019 13:10 # +1
Пока тут пейсали комментарии, они разрешили бесплатно соображать на троих в приватных репозиториях.
roman-kashitsyn 09.01.2019 13:23 # 0
я раньше всё приватное держал на bitbucket, но потихоньку перелажу с него, ибо он кривой, как и все поделия Atlassian.
1024-- 09.01.2019 13:32 # 0
Для компаний и богатых (5€) разработчиков - уместно и полезно.
А так для мелкой питушни -- всё, что угодно сгодится.
roman-kashitsyn 09.01.2019 13:47 # 0
Не нужно ничего разворачивать, сервис у них есть.
Туда GHC недавно переехал, им там система код-ревью больше понравилась, чем у Github.
guest8 09.01.2019 21:41 # −999
roman-kashitsyn 10.01.2019 00:15 # −1
В моём случае ответ простой: он умеет подсвечивать хаскель-код.
Битбакет не умеет, но внезапно начинает подсвечивать, когда включаешь blame. Видимо, эту часть другая команда делала. Короче, типикал Atlassian.
stepanPlus7 08.01.2019 23:11 # −3
TOPT 09.01.2019 09:41 # +2
guest8 09.01.2019 18:56 # −999
HoBorogHuu_nemyx 09.01.2019 20:52 # +1
guest8 09.01.2019 21:04 # −999
HoBorogHuu_nemyx 09.01.2019 21:19 # +1
guest8 09.01.2019 21:28 # −999
1024-- 09.01.2019 21:47 # +1
Пусть петухи и курицы - это шары (или кубы, если легче считать) диаметра S, струя - цилиндр диаметра D, ось которого удалена от центра шара на расстояние S1, насесты - цилиндры диаметра W.
Надо вычислить конфигурацию расположения насестов - множество точек (xs, ys) в плоскости стены курятника такое, что курятник размерами X, Y, Z может вместить максимальное количество петухов и куриц, весь помёт которых будет достигать только пола.
К сожалению, я слаб в математике, но идеи для старта местные математики могут почерпнуть в https://www.youtube.com/watch?v=CROeIGfr3gs.
guest8 09.01.2019 21:29 # −999
HoBorogHuu_nemyx 09.01.2019 21:31 # 0
guest8 09.01.2019 21:34 # −999
HoBorogHuu_nemyx 09.01.2019 21:41 # 0
guest8 09.01.2019 21:46 # −999
1024-- 10.01.2019 01:18 # −1
Тупо почему-то не осилили написание программы такой сложности или не пробовали? (написано уже много пакетных менеджеров, писать свой, который отличается только хранением нескольких версий - лень)
Или авторы не могут протестировать корректную работу со всеми комбинациями зависимостей в декларируемом диапазоне из-за большой кобенаторной сложности (если мой пакет зависит от пяти пакетов, для каждого из которых допустимо по 10 версий, а эти пакеты в свою очередь зависят от двух пакетов каждый с допустимым диапазоном в 10 версий, то всего выходит 10^5 кобенаций допустимых версий пакетов, если мы все честные и используем только документированные возможности и 10^7 кобенаций допустивых версий всех пакетов, которые нужно проверить, если есть подозрение на использование недокументированного поведения), а при подходе с дублированием разброс версий заметно уменьшается, т.к. программист и пользователь по умолчанию устанавливают последние возможные версии зависимостей в системе, поведение для которых легко тестируется, нет багов от того, что уже установленные версии зависимостей образуют кобенацию версий, которая допустима, но не была протестирована?
Т.е., иными словами, на практике плохо работает декларирование диапазонов допустимых версий зависимостей.
bormand 10.01.2019 01:29 # +3
1024-- 10.01.2019 02:00 # +1
Автор пакета 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 и у программиста, и у пользователя, который с большой вероятностью получит комбинацию, протестированную у программиста.
roman-kashitsyn 10.01.2019 01:43 # +1
Оно не идиотское. Более того, apt умеет устанавливать несколько версий одной библиотеки, это вовсе не проблема (см. so version).
Что сложно сделать — так это линковать разные версии библиотеки в одно приложение. Если у тебя библиотека A использует C1, B использует несовместимую C2, а приложение E использует A и B, то мы в беде. Потому что
1. E может случайно передать объекты, созданные C1, в функции из C2, будет взрыв.
2. Динамический линкер разрешает ссылки на функции по именам, и имена в C1 и C2 могут конфликтовать.
Поэтому в дереве зависимостей у каждой библиотеки должна быть одна определённая версия.
Я примерно понимаю, как ЖС-серы решают проблему 2 — используют загрузчик, который грузит определённую копию из поддерева, а все символы живут в замыканиях. Но вот что происходит с проблемой 1?
Пример проблемы 1 из жизни: у меня было 2 библиотеки на C++, одна возвращала фьючеры (из стандартной библиотеки!), другая принимала фьючеры. Приложение передавало фьючеры из одной библиотеки в другую. Из-за бага системы сборки они собирались с разными версиями стандартной библиотеки (разница была в минорной версии). Программа зависала при вызове.
1024-- 10.01.2019 02:11 # 0
В C++ разрешили использовать несколько функций с одним именем, впихнув в их настоящее имя сигнатуру сигнатуры. Соответственно, ничего не мешает втиснуть в имя функции/класса ещё и версию библиотеки, всё равно эти шизофазийные имена никто не читает.
> E может случайно передать объекты, созданные C1, в функции из C2, будет взрыв
Это КГ/АМ и использование недокументированных внутренностей A/B или принципиально неразрешимая ситуация?
Передаст ли E несовместимую психозу, если будет честно пользоваться только интерфейсами A/B, а конфликт имён C1/C2 будет устранён способом, указанным выше?
1024-- 10.01.2019 02:21 # 0
roman-kashitsyn 10.01.2019 00:16 # 0
guest8 09.01.2019 22:06 # −999
guest8 09.01.2019 22:11 # −999
guest8 09.01.2019 22:20 # −999
OlegYch 10.01.2019 01:33 # 0
3oJIoTou_xyu 10.01.2019 12:46 # 0
gost 10.01.2019 12:59 # +2
3oJIoTou_xyu 10.01.2019 13:10 # 0