Спустя три с половиной года с момента прошлого выпуска представлен (http://www.mail-archive.com/info-gnu@gnu.org/msg02156.html) релиз набора GNU Diffutils 3.4 (http://www.gnu.org/software/diffutils/), включающего утилиты для оценки различий в файлах, такие как diff, diff3, sdiff и cmp. В новой версии представлено два значительных улучшения:
- Добавлена опция "--color", при помощи которой можно сформировать наглядное выделение различий цветом. Опционально поддерживается передача параметра, определяющего в каких ситуациях применять подсветку строк: "--color=always", "--color=auto" и "--color=never".
Для настройки цветов предоставлена опция "--palette".
- Впервые с 1993 года внесены изменения в предлагаемый по умолчанию алгоритм выявления различий. Изменения позволили увеличить качество вывода результатов сравнения, ценой небольшого повышения нагрузки на CPU.URL: http://www.mail-archive.com/info-gnu@gnu.org/msg02156.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=44932
На самом деле все эти утили безбожно устарели. Например sort. Казалось бы - написано бородатым прогером 30 лет назад, на ansi C. Значит всяко быстрее всех!А на практике, скармливаешь ему гигабайтный файл (недействительные паспорта РФ, 100млн строк) и оно умирает на час с потреблением ОЗУ 8ГБ.
В то время как прога на java делает то же самое за 40 секунд и потреблением 4ГБ.
Так что модный порыв - переписать всё на GO вполне возможно, что и не глупость.
На 1С перепиши.
А по делу что скажете? Медленнее в сотни раз, зато православно? :)
> А по делу что скажете? Медленнее в сотни раз, зато православно? :)По делу на это говорят patches welcome.
Ещё из того что вызывает недоумение в 2016-м году:Argument list too long у большинства "старых добрых" утилей, например grep -R /dir-with-50k-files
Ты реально дурачек если незнаешь что это
Пусть я буду дурачком, но вы бы не могли пояснить?
Общая длина аргументов командной строки ограничивается ядром ОС.Вот почитайте для общего развития http://www.in-ulm.de/~mascheck/various/argmax/
> Общая длина аргументов командной строки ограничивается ядром ОС.Интересно, почему тогда
ls /home/xml/ | wc -l
прекрасно работает, а
grep -Ri 'blabla' /home/xml/*
/usr/bin/grep: Argument list too longу wc другое ядро? :)
ты будешь удивлен, но это не grep пишет
> ты будешь удивлен, но это не grep пишетА мы не будем удивлены - он честно написал что жабист. Поэтому он дуб и не понимает чем аргументы командлайна отличаются от перенаправления ввода. Не понимает человек чем массив от файла отличается. Что тут сказать? Програмер на жабе как есть.
Потому что в первом случае у команд по одному аргументу. Содержимое каталога из stdout ls в stdin wc летает. А во втором - шелл разворачивает звёздочку в собственно список файлов, и он же ругается.
Потому что в пером случае длинный список файлов едет в wc через пайп, и обе команды имеют ровно один аргумент. Сделайls /home/xml/*
и получишь ту же ошибку.
Откройте для себя xargs
>> А по делу что скажете?По делу скажу, что вы нас обманываете.
> Argument list too long у большинства "старых добрых" утилей, например grep -R
> /dir-with-50k-filesИ ведь врёте. Ну или кой-чего протеряли.
> Argument list too long у большинства "старых добрых" утилей, например grep -R
> /dir-with-50k-filesПредставь себе, максимальный размер argv и env - ограничен. Для "безразмерных" вещей есть такие вещи как перенаправление. Можешь попробовать из "новой" программы и даже писаной на яве отгружать огромный командлайн другим программам. Догадайся куда тебя пошлет система с этими начинаниями.
> На 1С перепиши.Зачем? Уже есть git diff. Он умеет и с цветом и даже сравнение файлов совсем без гитовых реп. А в гитовых репах еще и по ревизиям может сообразить. Superset diff'а.
Очень мило: единичный пример с одной старой утилитой (вы хоть в багтрекер отписались?) и тут же вывод о том, что ВСЕ "эти утили безбожно устарели".
если пользоваться "старым и проверенным", нынешним программистам будет не за что платить
присоединяюсь к - завязывай с наркотой.
Если "прога на жабе" гигабайт сортирует за 40 секунд - это мухоморы. Потому что даже у хороших дисков нынче 200mb/s в идеально-сферическом вакууме - она из этих сорока 20 только читать файл будет.Никаких прорывов в алгоритмах сортировки со времен первого тома Кнута нет.
Поэтому если у тебя действительно что-то получилось быстрее чем у sort - скорее всего, твоя программа делает (недопустимые) предположения о наборе исходных данных или об окружении (размере файла, количестве доступной памяти).
Если мы знаем заранее что в файле лежат номера паспортов, которые всегда начинаются с цифры и первые две всегда 45, причем длины строк тоже в предсказуемом диапазоне - да, можно сделать побыстрее чем sort. Только ничего кроме этого файла оно сортировать и не будет. Причем и с этим не все хорошо - его составляли люди, и им свойственно иногда вляпать z вместо 4. Или склеить две строки в одну.> Так что модный порыв - переписать всё на GO вполне возможно, что и не глупость.
глупость, увы - потому что пока кроме массы переписанных sort'ов ничего хорошего этот порыв не произвел. Все _большие_ проекты на go выглядят на редкость уныло. Возможно именно потому, что весь пар ушел в переписывание stdlib. Но скорее в виду специфики языка.
Потому что даже у хороших дисков нынче 200mb/s в идеально-сферическом вакуумеГигабайт со скоростью 200мб/с == 20 сек? И эти люди мне про наркоту говорят. :)
Остальное я даже комментировать не хочу. А что там в либе fastutils в LongOpenHashSet авторы придумали, мне не очень интересно. Но разумеется, ничего в духе "первые две всегда 45".
Так, навскидку... в fastutils какие-нибудь суровые красно-черные деревья, а в GNU sort плешивый пузырёк. :)
С каких пор пузырек стал разновидностью merge sort? Или ты из "я знаю ушу, кунг-фу и много других страшных слов"?
> Потому что даже у хороших дисков нынче 200mb/s в идеально-сферическом вакууме_в идеально сферическом вакууме_ - это sustained read, в однозадачной системе.
И то я очень сомневаюсь что у борца с паспортными данными - хорошие диски, а не забитая 100мегабитная локальная сеть с двадцатью буферами некратного размера по дороге.> Остальное я даже комментировать не хочу. А что там в либе fastutils
> в LongOpenHashSet авторы придумали, мне не очень интересно. Но разумеется, ничегосудя по названию - как минимум, они придумали что процессор имеет определенную длину long.
Что, разумеется, недопустимо для универсального переносимого софта - ему и на true-восьмибитном процессоре надо собираться и работать правильно. Где запросто окажется long=short=int, вот беда-то. Для C это вполне допустимо. go на таком железе не получается? Значит, это проблема go.> в духе "первые две всегда 45".
это лучшее предположение, чем предположение о длине long.
> не получается? Значит, это проблема go.а, стоп. У него жаба же. Ну да, ну да.
Слышь, борец за права С, ты вообще в курсе, что в С "the minimum size for short and int is 16 bits, for long it is 32 bits"
Так что, во-первых, со сборкой на true-восьмибитном процессоре для современного C возникнут сложности, во-вторых, равенство между этими тремя типами возможно минимум на 32-х битном процессоре, так как стандарт ограничивает только нижнюю границу и соотношение short<=int<=long
Ну а в Go типа long вообще нет. Плавающий типы там только int/uint/intptr, а все остальные целочисленные типы явно указывают количество бит(int8, int16...) или являются алиасами(byte/rune). Так что с Go ты вообще пролетел как фанера над парижем.
> борец за права С, ты вообще в курсе, что в С "the minimum size for short and int is 16 bits, for long it is 32 bits"сам-то умнее? тебе слово "minimum" увеличить? sizeof(short) == sizeof(int) == sizeof(long) == 32 вполне удовлетворяют тому, что ты написал.
ТруЪ-восьмибитный процессор с 32-битным short-ом? Wat?
Я так понимаю, что дальше первого предложения ты не прочитал и сразу бросился строчить гневный ответ. Попробуй все-таки прочитать второе предложение предыдущего поста, там почти то же самое: "во-вторых, равенство между этими тремя типами возможно минимум на 32-х битном процессоре, так как стандарт ограничивает только нижнюю границу и соотношение short<=int<=long ". Ну и остальное можешь тоже дочитать для самообразования.
> Я так понимаю, что дальше первого предложения ты не прочиталСлушай, вот, блин, честно так и было. Я не шучу. Поздно было, хотелось спать. Самому сейчас смешно. Прошу прощения :(
Тогда вопрос вдогонку: существует ли в стандарте информация о том, что на 8-битном процессоре не может быть 32-битного short? С точки зрения логики, конечно, никто так делать не будет, но есть ли формальное описание? Вот x32, например, предназначена для 64-битных процессоров, а все типы сделаны как в 32-битной архитектуре (кроме, вроде, time_t). Что помешает сделать такое же "наоборот" для 8-битных процессоров, чтобы существующий софт работал, как на полноценных процессорах?
В ранних стандартах си много странностей. А вменяемые типы с известными размерам - появились в C99. Пользуйтесь наздоровтье, они 17 лет с вами.
> Потому что даже у хороших дисков нынче 200mb/s в идеально-сферическом вакуумеА у хороших SSD и пара гигов в секунду бывает. Стоят они правда тоже хорошо.
> Потому что даже у хороших дисков нынче 200mb/s в идеально-сферическом вакуумеу меня два гига на чтение, гиг на запись. на лаптопе с одним ssd (он не sata, да). добро пожаловать в 2016 год.
Я даже не поленился проверить. 50kk строк с случайными 10-ти цифровыми значениями, 500MB. То есть всего в половину меньше. С записью результата в файл.
Command being timed: "sort -n data"
User time (seconds): 119.73
System time (seconds): 3.44
Percent of CPU this job got: 253%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.63
Maximum resident set size (kbytes): 2098020Как видно ни о каком часе речи не идет. Потребление памяти как и жабы в 4 раза больше объема сортировки. Если без указания -n, то работает раза в три дольше.
Ну пи**ит же как троцкий. Или руки у него закручены восходящей спиралью вокруг туловища.
> Я даже не поленился проверить. 50kk строк с случайными 10-ти цифровыми значениями,
> 500MB. То есть всего в половину меньше. С записью результата
> в файл.
> Как видно ни о каком часе речи не идет. Потребление памяти как
> и жабы в 4 раза больше объема сортировки. Если без указания
> -n, то работает раза в три дольше.env LC_ALL=C
в данной задаче нам очень вряд ли нужны правильные collate sequence и вообще знание о том, восьмибитный это файл или нет. (кстати, это место у gnu sort действительно заслуживает анализа и, возможно - багрепорта. Я еще помню, когда и откуда мы его выдирали (не из gnu исходника ни разу), когда, разумеется, приходилось радоваться что хоть такой есть. Поддержку юникода туда добавили позже, и, почти уверен, сделали это плохо.)P.S. кажется, я понял откуда часы - у товарисча банковского работничка дерьмоноут с недостаточной памятью - сорт туда просто не уместился, и сортировал своп, а вот go в силу использования другого алгоритма как-то влез, на грани фола. Ну и соответственно сравнивает он скорость своего недодиска со скоростью оперативки. Виноват, конечно же, язык си.
Качайте оригинал, не страдайте фигнёй.
http://guvm.mvd.ru/upload/expired-passports/list_of_expired_...Ключ -n не сработает, т.к. там есть и паспорта СССР :)))
[bla@vault13 /tmp]# hdparm -t /dev/md1/dev/md1:
Timing buffered disk reads: 956 MB in 3.00 seconds = 318.33 MB/sec#free
total used free shared buff/cache available
Mem: 32870168 14713236 12611568 456084 5545364 17234124
Swap: 0 0 0
Сделаем сишечке гандикапчик :)))) распаковал в TMPFS
[bla@vault13 /tmp]# time bzip2 -d list_of_expired_passports.csv.bz2
40.269u 0.436s 0:40.70 99.9% 0+0k 0+0io 0pf+0wЗапустили... чё-то оно быстро отработало, всего 2.20 минуты. Похоже я с uniq попутал.
time sort list_of_expired_passports.csv >list2
632.633u 4.176s 2:20.45 453.3% 0+0k 0+0io 0pf+0wТем не менее, жрало в процессе больше 12ГБ под конец. Ну и повторюсь, java - 40 сек :))))
[bla@vault13 go]# ps axu | grep sort
root 18756 621 30.7 11793172 10119724 pts/17 Rl+ 15:35 8:04 sort list_of_expired_passports.csv
root 18781 0.0 0.0 11996 2348 pts/10 S+ 15:36 0:00 grep sort
С -n таки отработало за 43 сек. Почти как жаба :) Но потребление ОЗУ по-прежнему 12ГБ[bla@vault13 /tmp]# time sort -n list_of_expired_passports.csv > list3
173.216u 4.126s 0:42.99 412.4% 0+0k 448+0io 3pf+0w
Всё,вспомнил. Задача была выделить дельту из последнего списка и недельной давности. И как раз diff час тупил и жрал озу.
> Всё,вспомнил.Да-да, и не в лотерею, а в покер, и не выиграл, а проиграл.
Вообще, мне уже очевидно, что в теме ни одного прогера кроме меня нет. :))) Потому что любой прогер бы первым делом спросил какая связь между hashmap и sort.Дело было с год назад, подумаешь детали не сразу вспомнились. Про задачу уже написал - выделать дельту из текущего списка и последнего. Сначала помаялся с ГНУтыми утилями (sort, diff), потом навелосипедил на жабе и было быстрее и по памяти экономичнее. В hash складывается весь первый файл, второй уже с хешем сравнивается.
Кто мне не верит или сочиняет про sort ест 3ГБ, флаг ему в его красные гнутые глаза :)
Ты про hashmap ни словом не обмолвился. И задачу про "выделить дельту"
только в этом своём последнем сообщении описал. Мне же вот вполне
очевидно, что ты что-то можешь написать для jvm, но простейший
shell-скрипт для тебя - адова работёнка.Твою задачу "выделать дельту из текущего списка и последнего" можно
было бы спокойно решить одной строчкой на shell:diff <(sort file1 | uniq) <(sort file2 | uniq)
Час твой скрипт работал, как же, как же. Выжрал 12 гигов рамы,
конечно. :)
> diff <(sort file1 | uniq) <(sort file2 | uniq)Во-первых, comm -3. Во-вторых, sort -u.
В-третьих, зачем Вы разговариваете с мебелью??!!
> Час твой скрипт работал, как же, как же. Выжрал 12 гигов рамы,
> конечно. :)
>> diff <(sort file1 | uniq) <(sort file2 | uniq)
> Во-первых, comm -3.О, спасибо. Не знал про неё.
> Во-вторых, sort -u.
Уточнения ради: я всегда использовал sort | uniq потому что мне не понятен алгоитм флага -u.
В доке написано "without -c, output only the first of an equal run". Вы не могли бы как-то это пояснить? А то я ведь и рад воспользоваться, было бы только полное понимание того, что оно делает.> В-третьих, зачем Вы разговариваете с мебелью??!!
Ну как сказать. Я прочитал огромный тред, поделал тесты, посооброжал. Захотелось оставить и свой вклад.
Ещё бы ты размер этого файла приложил. А то может у тебя 2 гига - это в архиве? :)А вообще, врёшь ведь, и не краснеешь. Вот у меня как раз во время всяческих тестов появился один чисто текстовый лог-файл на 26 гигов. Я выдираю из него ровно один гиг.
freehck@ws-kashin:~% ls -l 1gb-file.log
-rw-r--r-- 1 freehck freehck 1073741824 авг 10 12:37 1gb-file.log
freehck@ws-kashin:~% /usr/bin/time -v sort 1gb-file.log > 1gb-file.sorted.log
...
User time (seconds): 324.13
System time (seconds): 2.32
Percent of CPU this job got: 493%
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:06.15
...
Maximum resident set size (kbytes): 2044984
...Абсолютно разнородные строки. Минута реального времени (хотя реальное время - плохая метрика). 2 гига на пике потребления памяти.
export LC_ALL=C
time sort list_of_expired_passports.csv > list_of_expired_passports_s.csvreal 0m44.701s
user 1m19.532s
sys 0m3.836s
При этом потребление памяти 3ГиБ, в пике.
> На самом деле все эти утили безбожно устарели.Не поверишь, но линух без них не работает. И bsd. Поэтому срочно перелезай на windows 10 - он недавно обновился и там куча всего нового. Плюс он автоматически удаляет с компа всякий ненужный хлам вроде разделов безбожно устаревших линуксов.
Я правильно понимаю, что в твоем представлении без diff или sort ядро не запустится? Разочарую, запустится, а после ядра еще и init с шеллом или сразу какая-нибудь аппликуха. Линукс очень даже может существовать без этих утилит и особенно без gnu реализации этих утилит, которая заменяется на тот же busybox.
В доказательство своих слов приведите хоть один полноценный дистр, работающий без данных утилит.
> Я правильно понимаю, что в твоем представлении без diff или sort ядро не запустится?Нет, не правильно. Речь не про ядро, а про систему. Работать на голом ядре не любят не только пользователи убунты, но даже матёрые гентушники с арчевиками.
Линк на десктопный дистр без diff и sort - давай его фстудию, люто желаю посмотреть на него.
Да легко - alpinelinux. Они конечно там есть в репах, но без них отлично работает. Для понимания гугли про busybox.
Ну и для домохозяек сообщаю, что десктоп это ни разу не основная сфера использования линукса. И в каком-нибудь docker или openvz контейнере эти утилиты в большинстве случаев на фиг не нужны.
не поверите, но в busybox есть такие утилиты, которые sort и diff:$ busybox | grep 'sort\|diff'
delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname,
sha256sum, sha3sum, sha512sum, showkey, shuf, sleep, softlimit, sort,что-то мне подсказывает, что утилиты sort и diff в тех линухах всё-таки используются, иначе зачем это "старьё"(c) добавили в busybox?
про основную сферу применения линуха - речь не о ней, а о юзере, негодующем на устарелось утилит, используемых в его настольной системе (если, конечно, он не под виндой обитает);
и даже если система на busybox - она всё-равно использует diff и sort;
и - да - это не голое ядро.
Ты похоже вообще потерял нить рассуждений. Речь шла об устаревании _GNU реализации_ sort/diff/итд и соответственно ее жизненной необходимости для линукса. А ты похоже говоришь о необходимости существования произвольного бинарника, симлинки, шелл функции или алиаса с именем sort. Но даже необходимость этого не можешь доказать ничем кроме "здесь так повелось" или "вот в моем любимом дистре они есть, значит нужны".
цепляние за термины.
есть утилита sort, выполняющая сортировку, и есть утилита diff, выдающая различия в двух текстах - без этих утилит дистрибутив не построить.
не надо троллить фразами "ядро от них не зависит", "похожие названия", "gnu-реализация" и прочей чепухой - троллинг сути не меняет.
чел сказал, что оно устарело; я сказал, что используемый дистр без этих утилит работать не будет;
и в busybox они встроены, потому как для дистров реально необходимы, в числе остальных прочих утилит.не согласны - приведите хоть один весомый аргумент, доказывающий, что именно GNU-версия устарела; и приведите пример версии, которая современная;
или, опять-таки, пример дистра без применения данных утилит.ЗЫ. (на всякий случай) троллинг про diff с графическим интерфейсом просьба не начинать.
Показываю на пальцах, можешь повторить.# mv /usr/bin/sort /root/
# mv /usr/bin/diff /root/
Перегружаем машину и видим ЧУДО. Линукс загрузился. В графический режим. И работает. Даже браузер запускается, в котором я сейчас пишу этот пост. В консолькеangra@Falcon 02:21:38 ~ $ which diff
angra@Falcon 02:21:40 ~ $ which sort
angra@Falcon 02:21:42 ~ $Собирай шаблон по частям, "линуксоид".
> Не поверишь, но линух без них не работает.аллах с тобой, сто лет уже как он без них работает.
Без них не работало разьве что во времена slackware 3.1
(потому что чтобы что-то в конфиг добавить или удалить, надо было таки найти нужное место в файле, а не бросить очередной .conf в свалку в conf.d/ )Тем более что эта функциональность уже интегрирована в systemd. ;-)
У bsd все сложно - в принципе, в openbsd уже давно свой diff, но, как обычно, лучше б его там не было. patch у всех сто лет как свой. Со всем остальным - разно, и чаще лучше б ну его нафиг.
https://wiki.freebsd.org/GPLinBase
Аналогично предыдущему персонажу: приведите пример полноценного дистра, работающего без данных утилит. Или вы на голом ядре работать умудряетесь? Или довольствуетесь только использующими его прошивками? В большинстве случаев используются десктопные дистрибутивы - убунты, шляпы, арчи и т.п., - которые без данных утилит не работают.
Не верите - учите матчасть.
> Аналогично предыдущему персонажу: приведите пример полноценного дистра, работающего без
> данных утилит.ну хочешь - сделаю rm и он будет работать? (правда, что тогда такое "полноценный дистр" я хз)
> Или вы на голом ядре работать умудряетесь?
нет, оно ж давно даже само загружаться разучилось. Но именно гнутые текстутилиты (не говоря уж про дифф) практически не нужны ни для загрузки, ни для работы (системы).
Особенно в свете systemd и прочей мерзости, когда уже исчезает практика делания чего-нибудь типа "kill -USR2 `head -1 /var/run/чтототам.pid`" - не то что вручную, но и внутри системных механизмов тоже.Они еще нужны для работы отдельных человеков в системе, но их таких, если честно, все меньше и меньше. oowriter, полагаю, тоже без сорта с грепом вполне запустится. А это и есть настоящее и будущее - "как в виндовс, только на халяву".
> А на практике, скармливаешь ему гигабайтный файл (недействительные паспорта РФ, 100млн строк) и оно умирает на час с потреблением ОЗУ 8ГБ.Продемонстрируйте вывод top/ps. Вообще-то sort занимает не более определенного % ОЗУ (автоопределение, либо задать можно опциями), а дальше создает временные файлы в /tmp и выполняет слияние. По умолчанию настройки довольно консервативны в плане памяти.
Если у вас нет SSD, а ОЗУ точно много, можно предложить ему использовать побольше (опция -Ы), тогда скорость будет как программы на java. Тут sort просто постеснялся использовать больше нескольких сотен МБ. Сравнение непоказательно, дали бы ему столько же памяти - завершился бы быстрее.
А вот если бы вы сортировали 30 Гб данных, прога на джаве либо бы съела всю память и упала, либо тоже начала бы merge sort на временных файлах.
Товарищи модераторы, а почему я должен читать этого кретина?
> Товарищи модераторы, а почему я должен читать этого кретина?Не читайте. Имхо, такие комментарии надо оставлять хотя бы для того, чтобы ответы окончательно разубедили читающих тред в отсутствии у данных претензий качественной аргументации.
А ещё того гляди - удалим, и начнётся "модеры режут неугодные им сообщения, какой произвол, опеннет не хороший". :)
А они и так режут. :)Спасибо хоть такие как эти не режут, именно по той причине, что вы описали.
> Впервые с 1993 года внесены изменения в предлагаемый по умолчанию алгоритм выявления различийкак ща помню, как я 23 года назад жаловался на это
а на отсутствие каких именно изменений вы жаловались, если не секрет?
тех, которые про цветной вывод :D
Да что вы слушаете этого Лютого наркомана_. Вот я на С++ написал утилиту, которая его гигабайтный файл за 10 секунд сортирует, а его гнилой жаба-костыль только за 40!
Многие современные любители жаб, рубей и прочих новоявленных языков знают только один язык, остальных не понимают, в результате чего считают их недоязыками. Их пассажи напоминают высказывания об английском тов.Задорнова - в стиле "ну тупые, и язык у них ограничен и годится только для похода в супермаркет".PS. сейчас нарисуется разработчик на яве, который примет всё высказанное на свой счёт и примется доказывать, что знает много языков (ц) ванга.
Но код этой мегаутилиты ты нам конечно не покажешь, ведь существует она только в твоем воображении.
Вам бы, батенька, товарища Кнута почитать.
Представь себе читал. Давно только, не исключен вариант, что ты в это время еще пешком под стол ходил. И что же ты мне из него хочешь напомнить?
А может ты просто не знаешь, что алгоритмы можно не только копипастить из книжки, но еще и самостоятельно реализовывать на языке, отличном от используемого автором книги для примеров.
0. те, кто кнута читал, алгоритмы не копипастят.
1. те, кто кнута читал так давно, имеют несколько другой сленг.
2. монография - не книга для примеров.поэтому взвешенно думаю, что ты ещё школьник.
Предположим для смеху, что ты прав и я школьник, в жизни не видевший книг Кнута. Что дальше? Что ты сказать то хотел? Ты Кнута упомянул только как известное тебе страшное слово или все-таки с каким-то смыслом? Потрудись изложить смысл и при этом опять не забыть контекст.
> Предположим для смеху, что ты прав и я школьник, в жизни не
>и при этом опять не забыть контекст.Ты всё правильно говоришь, но, возможно, он ссылался на то место в первом кнуте, где он писал, что на иронию-сарказм и тем более риторический форумный наброс не нужно отвечать по смыслу -- прямо в лоб. А, если отвечаешь, нужно сарказм-иронию-риторику _удваивать_ минимум. Но не у всех выходит. Сам мучаюсь!
Правильно цитировать так:"Да что вы слушаете этого Лютого наркомана_. Вот я на С++ написал утилиту, которая его гигабайтный файл за 10 секунд сортирует, а его гнилой жаба-костыль только за 40!".
Алан Тьюринг, член ЦК ВКПБ, 1998г.
Пацаны наконец-то реализовали 'git diff' ?
> Пацaны наконец-то реализовали 'git diff' ?Скорее built-in замену colordiff.
> Пац аны наконец-то реализовали 'git diff' ?Там еще нету сравнения с тэгами/бранчами/ревизиями, так что им есть над чем поработать :)