Opustags

Это не вендор лок, а просто готовая среда для разработки большей части того из чего стостоит система.

А что тебе мешает упомянуть в ридми что это форк?

Там лицензия явно запрещает использовать имя оригинального разработчика для продвижения форка

Neither the name of the author nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

https://github.com/rust-lang-nursery/rust-bindgen

Очень гуд! А где б ещё глянуть применение помасштабнее так сказать? Когда целые либы полностью «пользуются». Конкретно интересует libpng.

ты предъвил за C автору случайного проекта на гитхабе

Не случайного, а нового. А дальше начинается спор о преимуществах разработки на современном ЯП по сравнению с Си. Не обязательно Rust. Впринципе, любой язык с нормальными абстракциями парадигмами современнее процедурного програмирования

https://crates.io/crates/bindgen

Нажать на ссылку «Dependent crates» вверху страницы

Есть даже что-то готовое https://crates.io/crates/opus

Это масштабный вендор-лок в головах линуксоидов-староверов )

Это же обычная BSD 3-clause, подобной наркомании она не подразумевает. Во-первых, у поминание разработчика в ридми не является способом продвижения. Во-вторых, он даже не сменил название, так что упоминание того, что это форк одноимённой софтины тем более ничему бы не противоречило, можно даже это сделать не упоминая автора.

Камон, ты проигнорировал весь мой посыл. Проблемы разработки — проблемы разработчика.

какой профит и для кого бы был, если бы он был написан на Rust?

Кому какое дело на чём он написан? Даже если речь о библиотке, а ты как разраб хочешь её юзать, то сишечка опять таки лучше любого раста, ffi для сишечки есть везде. А если ты просто юзер, то тебе и подавно удобней, если оно на сях (возвращаясь аргументу про с борку).

Это обычная рациональность.

У кого больше посоны

У него.

1) Убогие человеческие мозги более сложные графы исполнения не умещают.

2) Цикломатическая сложность функции - типа нижняя граница на количество тестов, необходимых для полного покрытия функции.

Ясен пень это не жесткое правило, и где-то в гайдлайнах - 15, а то и 20, и контрпример придумать можно, и программирование с тех пор шагнуло вперед, и понятие ветвления оказалось немного резиновым... Но блин, вон то 114 просто не может скрывать за собой что-то хорошее.

Два чая этому неадеквату.

Не случайного, а нового.

Не нового, а «воскрешённого».

Очнись и осознай, что в 2019 никто, кроме парочки любителей KOI8, более не желает контрибьютить в сишные проекты.

тыщи разработчиков коммитят каждый день в ядро этого самого нашего линукса, и они по твоей версии не существуют

да он вроде и не умирал, не далее как 16 часов назад последний коммит был

да он вроде и не умирал

Умирал, умирал. Где то в 2013 сдох. Теперь «воскрес».

Что-то не очень похоже на «воскрешение» с твоей стороны.

user@localhost ~/src/github.com/fmang/opustags (master) $ git log | grep Date
Date:   Fri Nov 2 16:56:53 2018 -0400
Date:   Wed Oct 31 18:24:58 2018 -0400
Date:   Wed Oct 31 18:22:48 2018 -0400
Date:   Wed Oct 31 18:21:47 2018 -0400
Date:   Tue Oct 30 19:14:34 2018 -0400
Date:   Tue Oct 30 19:12:58 2018 -0400
Date:   Tue Oct 30 18:29:08 2018 -0400
Date:   Tue Oct 30 18:28:12 2018 -0400
Date:   Mon Oct 29 18:37:14 2018 -0400
Date:   Mon Oct 29 18:26:21 2018 -0400
Date:   Sun Oct 28 20:02:38 2018 -0400
Date:   Sun Oct 28 20:01:57 2018 -0400
Date:   Sun Oct 28 20:00:48 2018 -0400
Date:   Sun Oct 28 19:55:39 2018 -0400
Date:   Sun Oct 28 19:54:29 2018 -0400
Date:   Sun Oct 28 18:42:21 2018 -0400
Date:   Sun Oct 28 18:41:26 2018 -0400
Date:   Sun Oct 28 18:17:52 2018 -0400
Date:   Sun Oct 28 14:12:55 2018 -0400
Date:   Sat Oct 27 20:36:18 2018 -0400
Date:   Sat Oct 27 20:30:11 2018 -0400
Date:   Tue Oct 23 18:11:42 2018 -0400
Date:   Sat Oct 27 20:23:24 2018 -0400
Date:   Sat Oct 27 20:23:16 2018 -0400
Date:   Wed Oct 24 18:27:57 2018 -0400
Date:   Wed Sep 19 14:42:27 2018 +0300
Date:   Wed Sep 19 14:31:38 2018 +0300
Date:   Sun Oct 1 12:26:56 2017 +0200
Date:   Wed Jan 2 10:59:43 2013 +0100

user@localhost ~/src/github.com/zvezdochiot/opustags (master) $ git log | grep Date
Date:   Wed Oct 31 23:12:18 2018 +0300
Date:   Tue Oct 30 20:21:56 2018 +0300
Date:   Sun Oct 28 03:48:10 2018 +0300
Date:   Sun Oct 28 03:45:14 2018 +0300
Date:   Sun Oct 28 03:43:06 2018 +0300
Date:   Sun Oct 28 03:40:00 2018 +0300
Date:   Sun Oct 28 03:36:16 2018 +0300

Так все же — зачем нужно было стирать историю изменений?

зачем нужно было стирать историю изменений?

Разногласия с АВТОРОМ. Я так и не понял куда его несёт, а мои PR он игнорил. Кстати, не только я. Aarni Koskela тоже на него забил.

он там в комментах к ним по хардкору пояснил всё

он там в комментах к ним по хардкору пояснил всё

И чего? Комментарии - это гуд. А где результат? Его opustags бажный.

А в виде библиотеки оно существует?

Теперь существует. 1.2.3.

зачем нужно было стирать историю изменений?

Разногласия с АВТОРОМ.

Давно это стало поводом стирать историю изменений? Почему нельзя было сделать нормальный форк и добавить к названию постфикс «-ng»?

Я так и не понял куда его несёт, а мои PR он игнорил.

Вижу на GitHub всего 2 Pull Request'а, из которых содержит какие-то значимые изменения только один, и при этом ответ автора явно не содержит признаков игнорирования.

https://github.com/fmang/opustags/pull/21

fmang commented 7 days ago

Sounds promising, but I can't review 1k lines of code like that. Please split your pull request into meaningful chunks, and give your commits better names. Never bump the version number, that's like begging for merge conflicts.

If you're not familiar with git, I can show you a few tricks to manipulate commits. Just send me an email.

Мне кажется, что ты делаешь что-то нехорошее.

не содержит признаков игнорирования

Ты не учёл мыло.

Мне кажется, что ты делаешь что-то нехорошее.

«Хорошее» - не мой критерий. Я по Кнуту. «Плохость» того что я делаю мала.

ТС вообще знатный чудак. А автор верно сдедал, что не принял такой патч.

Ты не учёл мыло.

Окей, хорошо.

Тем не менее — зачем стирать историю изменений, и почему нельзя добавить постфикс «-ng», чтобы люди не путали?

ТС вообще знатный чудак. А автор верно сдедал, что не принял такой патч.

Я сомневаюсь, что хоть кто-то бы принял pull request, где у тебя вместо нормальных commit message одни бампы версий, причем на каждый кормит.

зачем стирать историю изменений

А зачем она мне. Она АВТОРУ нужна. А мне нужна работающая прога.

чтобы люди не путали

1.2.3 - теперь не спутают.

А зачем она мне. Она АВТОРУ нужна. А мне нужна работающая прога.

Детский сад.

хоть кто-то бы принял pull request

Не совпадает с реальностью. Нормально мои PR принимают. Но не данный АВТОР. Кстати PR #21 ты упомянул, а PR #20.

тебе от него припекло штоле

ты там даже стиль скобочек поменял без спроса на свой в том пуллреквесте, это вообще за рамками разумного

Ясно.

В общем в новостях этому действительно делать нечего.

это вообще за рамками разумного

К этому времени я уже принял решение отпочковываться. Про PR #20 никто не забыл?

Про PR #20 никто не забыл?

а зачем ты меняешь нумерацию версий без спроса

зачем ты меняешь нумерацию версий без спроса

Как это «без спроса»? Мы это обсудили и он таки пришёл к выводу, что моё решение разумно. Но PR принимать не стал. А версию поменял. И ???

Во времена SVN каждый коммит по сути был релизом

Пользуюсь SVN, делаю мелкие коммиты, УМВР.

Автохрен тебе, я даже с другими модераторами обсудил. Сказали - нужно.

Ты же сам сказал что пусть живёт?

Или это было по поводу другой такой же штуковины?

Ты же сам сказал что пусть живёт?
Или это было по поводу другой такой же штуковины?

По поводу другой, ибо в рассылке об этом ни слова, а в чате единственное сообщение на эту тему — ссылка на пост Harald'а.

Автохрен тебе

Как сказано-то!

Видишь, я все перепутал!

Вышло уточнение, действительно что попало.

В git ты можешь коммитить нерабочий код, а пушить уже когда он рабочий, в svn такой возможности нет.

А почему в толксы-то? Вполне техническая тема, под тематику форум -> мультимедия подпадает.

А, ну значит, мы под мелкими коммитами разное понимаем. Я-то имел в виду сколь угодно мелкое, но осмысленное и описываемое изменение, даже уровня «добавлена настройка цвета фона». Но это, конечно, не синоним релиза.

А зачем коммитить заведомо нерабочие правки, я не понимаю. Безотносительно к типу VCS.

Ну пилишь ты объёмную фичу, какую-то логически обособленную часть написал, закоммитил. Даже если код после этого не рабочий, какая проблема-то? Коммитишь да пушишь переодически в отдельную ветку, никому не мешаешь.

Да пофиг вообще хоть как прономеруй , но только что бы это как в случае с не которыми пакетами сути какого то переизобретения не играло и не надо было восемясят милионов зависимостей тянуть

Сколько человек с тобой над проектами в svn работает? Каждую мелочь коммитить там не удобно, мерджи там боль. Про релизы я, конечно, утрировал, но суть-то примерно такая: доделываешь запланированное изменение целиком и только тогда коммитишь.

Сколько человек с тобой над проектами в svn работает?

Ну около 5 человек на одном проекте было.

мерджи там боль

Имхо, мерджи пересекающегося кода не должны быть повседневным занятием. Это решается организационными методами. Нет, конечно, всякое бывает, но когда разные люди постоянно правят одни и те же модули — на мой взгляд это ненормальная практика.

Ну да, в гите с ветками работать удобнее, но если их постоянно сливать, боль всё равно вылезет, крайним окажется тот, кому придётся сливать.