| 1.1, A.Stahl (ok), 20:44, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 Кто же так делает-то? Нужно: "Представлен новый выпуск Linux дистрибутива reGrep (кодовое имя: Грёпаный Файл), на базе которого развивается утилита для организации поиска данных в текстовых файлах."
Берите пример с разработчиков ДЕ и весёленьких обоев. У всех есть свои дистрибутивы, а у грепа нет :(
| | |
| |
| 2.8, Dzen Python (ok), 21:07, 28/09/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Фу. Снова неправильно. Держи исправленную новость:
"Представлен выпуск electron-утилиты для организации поиска данных в текстовых файлах - YAMLGrep 64.1. В новой версии возвращено старая модель сборки с npm-модулем FilesWithoutMatch (вызываемого при конфигурировании строкой в общем json "files-without-match = true"), который в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep, а затем возвращен в выпуске 3.5. Если в
ранних версиях и без явного включения опции поиск считался успешным при упоминании обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки..."
| | |
| |
| 3.11, Аноним (11), 23:07, 28/09/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Фу. Снова неправильно. Держи исправленную новость:
"Мы пересали grep на раст, так предыдущая версия сегфолтилась и текла, но теперь мы пьем смузи, а наш поиск встал крепким и шелковистым..."
| | |
| |
| 4.12, Аноним (11), 23:08, 28/09/2020 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> встал крепким
Блин, прям по Фрейду опечатка. Хотел сказал: "стал крепким и шелковистым". Как у ТВ-Парк.
| | |
| |
| 5.35, Аноним84701 (ok), 13:49, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Блин, прям по Фрейду опечатка. Хотел сказал: "стал крепким и шелковистым". Как у ТВ-Парк.
Учитывая что, вроде бы, всегда было "... станут мягкими и шелковистыми", там "по Фрейду" не одна опечатка, кхе ;-)
| | |
|
|
|
|
| 1.2, б.б. (?), 20:46, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
зачем ещё нужен grep, если microsoft открыли код собачки из windows xp? кто теперь в здравом уме после этого будет grep-ом пользоваться?
| | |
| |
| |
| |
| 4.33, Аноним (33), 18:38, 30/09/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
echo findstr %1 %2 %3 %4 %5 > %systemroot%\grep.cmd
грепайте на здоровье
| | |
| |
| 5.34, IRASoldier_registered (ok), 22:18, 30/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Спасибо, Кэп. Без твоей мудрости никто бы не знал, как сделать батник для Винды, назвать его грепом и потом заявить, что в Винде есть греп.
| | |
|
|
|
|
| 1.3, Аноним (3), 20:47, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
А мне вот больше по душе такая нумерация версий. Утилите 10 миллионов лет, а она 3.5, а не 82.0.1.398.
| | |
| |
| 2.10, Аноним (10), 21:54, 28/09/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
> нумерация версий
> по душе
Выбирать нумерацию версий "по душе" и прочим "душевным" смузи-критериям -- первый признак хипстера. Версии следует выбирать исходя из целей:
- там, где важно обозначать обратную (не)совместимость и давать какие-то гарантии на уровне API — выбираем semver;
- там, где клиентам не интересен никакой API (или его вообще как такового нет), и релизы вообще привязаны к дате, и приложение включает в себя буквально сотни библиотек, и все это дело развивается слишком стремительно — выбираем тупой ежемесячный бамп или указываем время непосредственно в версии (Chromium 85, IntelliJ IDEA 2020.2.2).
Для библиотек и утилит берем semver x.y.z, для конечных приложений для широких масс — YYYY.QQ.
| | |
| |
| 3.13, Аноним (11), 23:10, 28/09/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Chromium 85
Так тут тоже привязыывают к версии API/ABI движка V8. В данном случае это V8 v8.5, и каждая верия V8 ломает совместимость.
| | |
| 3.15, Аноним (15), 23:51, 28/09/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Может и удобно пользователям, но неудобно для разработки. Для разработки удобно увеличивать y для каждой "готовой" версии со значительными изменениями. Final public release назвать 1.0.0 и менять x только если большая часть кода переписана и всё слишком уж несовместимо. Это и пользователям удобно.
| | |
| |
| 4.23, Ordu (ok), 19:52, 29/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Кто тебе сказал, что это неудобно для разработки? Для разработки, как раз, совершенно фиолетово. Для разработчика софтины, все эти версии -- не более чем tag'и для некоторых из коммитов. Что именно в этих tag'ах написано совершенно не важно, до тех пор, пока эти имена легко сравнивать по критерию "раньше/позже". Дело в том, что ежели ты занят разработкой, если ты в git заглядываешь каждый день или хотя бы раз в неделю, если ты просматриваешь новые коммиты, следишь за багами, обсуждениями и прочими вещами, то как бы там не назывались релизы, ты будешь их помнить и будешь в них ориентироваться. semver -- это для человека не вовлечённого в разработку, которому тем не менее хочется ориентироваться в версиях. То есть не для разработчика.
Semver может быть удобнее для мейнтейнера дистрибутива, который разгребает dll hell, да и то только в тех случаях, которые подпадают под "там, где важно обозначать обратную (не)совместимость и давать какие-то гарантии на уровне API".
| | |
| |
| 5.24, Аноним (15), 19:57, 29/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это только для своего кода, никто не будет разгребать все зависимости и уж тем более следить за всеми коммитами, если те тебя вообще не касаются -- разрабатывают и пусть разрабатывают, тебя это начнёт волновать только когда выйдет новая версия с изменениями, которые тебе придётся учитывать.
| | |
| |
| 6.25, Ordu (ok), 20:32, 29/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Это только для своего кода, никто не будет разгребать все зависимости и
> уж тем более следить за всеми коммитами, если те тебя вообще
> не касаются
Если ты участвуешь в разработке, то тебя касаются не только изменения внешнего API, но и внутреннего. Изменения внутреннего API могут происходить при любом изменении версии, даже если это багфикс. Если ты участвуешь в разработке, ты в любом случае вынужден следить за этими изменениями.
Изменения внешнего API тебе при этом не то чтоб совсем неинтересны, но они интересны не больше, чем изменения внутренних. А может и меньше.
> разрабатывают и пусть разрабатывают, тебя это начнёт волновать
> только когда выйдет новая версия с изменениями, которые тебе придётся учитывать.
Не. Во-первых, эти изменения тебя начнут волновать ещё до того, как выйдет новая версия. Ещё до того, как появится новый тег для версии тебе придётся учитывать изменения API. Во-вторых, semver отражает только изменения внешнего API, а тебе будут интересны изменения внутренних API. Если ты разработчик какой-нибудь библиотки, то вполне вероятна ситуация, когда внешние API этой библиотеки тебя вообще не трогают: ты может быть пилишь какой-нибудь там код взаимодействия в /proc, и твоя задача вынуть оттуда нужную информацию и сделать её доступной для другого кода библиотеки, то есть выставить наружу API, которым библиотека будет пользоваться для извлечения информации из /proc. Этот API запросто может не выставляться наружу из библиотеки, и таким образом _никакие_ изменения внешних API тебя не затронут напрямую. А вот изменения внутренние запросто могут затронуть.
| | |
| |
| 7.26, Аноним (15), 21:09, 29/09/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Видимо, мы подразумеваем разной сложности продукты -- в реальной жизни у тебя вполне вероятно не будет даже доступа к исходникам, и тебя никак не может волновать внеочередная перестановка кроватей (тем более, планирующаяся -- это не твоя задача!). Я всё ещё не вижу как код разрабатываемый соседним отделом касается тебя, ты ведь даже не будешь копаться в кишках, да и платят тебе вовсе не за это.
ps наверное первый раз в жизни употребил слово "планирующаяся" -- выглядит странно, но я почти уверен, что оно должно писаться именно так.
| | |
| |
| 8.27, Ordu (ok), 22:12, 29/09/2020 [^] [^^] [^^^] [ответить] | +/– | Если я не копаюсь в кишках кода, то я не являюсь его разработчиком В лучшем слу... большой текст свёрнут, показать | | |
| |
| 9.28, Аноним (15), 23:22, 29/09/2020 [^] [^^] [^^^] [ответить] | +/– | Пользователь кода, но разработчик одного и того же продукта Индикация изменений... текст свёрнут, показать | | |
| |
| 10.29, Ordu (ok), 23:35, 29/09/2020 [^] [^^] [^^^] [ответить] | +/– | Так Я выше изложил тебе выдержанную и здравую позицию Если ты не хочешь понима... текст свёрнут, показать | | |
| |
| |
| 12.31, Ordu (ok), 23:47, 29/09/2020 [^] [^^] [^^^] [ответить] | +/– | Приведи пример хамства я работаю над тем, чтобы снизить количества хамства с мо... текст свёрнут, показать | | |
|
|
|
|
| |
| 9.37, Аноним (15), 19:04, 03/10/2020 [^] [^^] [^^^] [ответить] | +/– | Но ведь это совсем другое слово Смысл первого в том, что оно само, а во втором ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 3.32, Zlo (??), 11:12, 30/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
Почему вспоминают Chromium c его жалкой 85 версией, и никто не вспоминает нвидию с 456.55
| | |
|
|
| 1.7, OpenEcho (?), 20:59, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep
Т.е. git теперь стал первичен ? не git под grep а наоборот... :)
| | |
| |
| 2.18, Аноним (18), 10:01, 29/09/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я тебе больше скажу, я patch-файлы только в git-формате использую. Потому что они при накладывании поверх репозитория превращаются в коммиты. А дебианы всякие пусть свой quilt используют.
| | |
|
| 1.22, Аноним (22), 14:14, 29/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>В новой версии возвращено старое поведение опции "--files-without-match" (-L), которое в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep. Если в grep 3.2 поиск стал считаться успешным при упоминании обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки.
Игорь всплыл
| | |
|
