goredo в AUR и 0.11.0 релиз

Что: 28e6b067426cea52051603de47345f3dac6018a4

Когда: 2021-01-10 18:19:44+03:00

Темы: redo

https://aur.archlinux.org/packages/goredo/
http://www.goredo.cypherpunks.ru/News.html#Release-0_002e11_002e0
Kai Hendry взял и запилил AUR порт goredo для Arch Linux. А мне пока
влом делать порт для FreeBSD. Очень уж меня напрягает тот факт, что
порты похоже нужно регулярно и постоянно собирать на всё обновляемых
версиях FreeBSD, что тот ещё геморрой (точнее бремя maintainer-а).
Даже NNCP и GoVPN за меня делают другие люди по сути а я и не знаю
откуда они берут всю эту информацию и прочее.

А ещё сделал 0.11.0 релиз, где поправил корявое поведение при указании
кол-ва параллельных задач: REDO_JOBS перебивал -j опцию и мне
приходилось делать REDO_JOBS= redo -j... пока перестал это терпеть. Ну и
заодно взял и добавил BLAKE3, вместо BLAKE2b. Вряд ли у кого упор был бы
в хэш, но всё же почему бы побыстрее штуку не впилить, потенциально
вскоре ещё и получающую (конкретная реализация) неограниченное
распараллеливание из-за Меркле деревьев. Тем более что тут нужна
проверка именно целостности только.

Но я взял не github.com/zeebo/blake3
(4c02094d684f2a9ac2736a67532a8f97eeec527c), а lukechampine.com/blake3,
хотя код последнего мне меньше нравится. Но у zeebo среди зависимых
библиотек есть пара без какой-либо лицензионной информации, что
автоматом является не свободным ПО. Хотя они используются и только для
внутри тестов, но геморрой возиться с созданием fork-а без них. Скорость
lukechampine.com/blake3 всё равно в два раза выше у меня чем у
golang.org/x/blake2b.

оставить комментарий

комментарий 0:

From: David Rabkin
Date: 2021-01-11 12:48:54Z

Молодец! Я буду пользоваться AUR портом на моем Artix Linux. FreeBSD
тоже надо, я, например, практически никогда руками не собираю. Порты —
это круто.

Пошел смотреть на daemontools, сходу обнаружил забавную оптимизацию:
unsigned int str_len(const char *s)
{
  register const char *t;

  t = s;
  for (;;) {
    if (!*t) return t - s; ++t;
    if (!*t) return t - s; ++t;
    if (!*t) return t - s; ++t;
    if (!*t) return t - s; ++t;
  }
}

Повторение строчки, видимо, экономит jump-ы, но почему четыре раза? А
не сорок четыре?
Стиль кода классный у него, я пытаюсь так писать. (Вертикальные
пробелы я не люблю.)

комментарий 1:

From: Sergey Matveev
Date: 2021-01-11 13:02:52Z

	** David Rabkin [2021-01-11 14:46]:

>Я буду пользоваться AUR портом на моем Artix Linux.

Только автор пока его ещё не обновляет до следующей версии. Пока он
вообще планирует для homebrew сделать порт (или что там ну их?).

>FreeBSD тоже надо, я, например, практически никогда руками не собираю.
>Порты — это круто.

Ну даже когда я порт отправлю в FreeBSD, то на пратике проходят месяцы
(полгода в лёгкую) прежде чем кто-то его добавит в дерево. Да и то фигня
какая-то там у них в FreeBSD в портах с Go: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249946
Даже прежде я совершенно не понимал как надо проверять и тестировать
порт и не мог повторить баги возникающие у тех кто возится с портом там.
Как maintainer-у мне не нравятся порты ибо не понимаю как с ними
образаться (будучи maintainer-ом) :-). Либо это везде жуткая головная
боль с ними, чёрт его знает.

>Повторение строчки, видимо, экономит jump-ы, но почему четыре раза? А
>не сорок четыре?

Могу предположить что связано с 32-битами (минимум на котором
предполагается запуск программы), где четыре раза 8-бит character
умещается. Но мысли в слух, без понимания полного.

>Стиль кода классный у него, я пытаюсь так писать. (Вертикальные
>пробелы я не люблю.)

Вертикальные пробелы это как в GNU? https://en.wikipedia.org/wiki/Indentation_style#GNU_style
По моему худшее что я видел :-), хотя вроде слышал это всё нормально и
привычно для Lisp-еров, кем изначально RMS и является. Я по сути также
пишу как и DJB, только в "новом" описания фунок:

    unsigned int byte_chr(char *s, register unsigned int n, intc)

вместо "старого":

    unsigned int byte_chr(s,n,c)
    char *s;
    register unsigned int n;
    int c;

Ну и теперь я стараюсь возвращаемый тип данных писать на отдельной
строке, чтобы функу можно было найти по "^funcname" regexp-у:

    unsigned int
    byte_chr(char *s, register unsigned int n, intc)

Изначально я ещё фигурную скобку начала функции писал на той же строке
что и сигнатура функи, но в 8e49bec8beb1c745ef756855ca3c693e96524ed0
дошло в чём профит (упрощение навигации в редакторе).

комментарий 2:

From: David Rabkin
Date: 2021-01-11 13:39:41Z

> проходят месяцы (полгода в лёгкую) прежде чем кто-то его добавит в дерево
Да, не хорошо.

> Могу предположить что связано с 32-битами (минимум на котором
> предполагается запуск программы), где четыре раза 8-бит character
> умещается. Но мысли в слух, без понимания полного.
Видимо, так и есть. Я сначала написал тебе, а потом тоже про это
подумал. Тогда, можно улучшить функцию: восемь строк для 64-битной
архитектуры :-) С другой стороны, зачем все эти игры разума при
современных компиляторах и СиПиЮ?

Вертикальными пробелами, мне кажется, называют пустые строки, как в
str_len после register const char *t;. Считается, что это улучшает
читаемость. Я не согласен. Разбиение на короткие функции, где не нужны
пустые строки, улучшает читаемость. А бесконечные функции, где без
пустых строк глаза в кучу, — в топку.

GNU style мне тоже не нравится.

> "новом" описания фунок
Я удивился, что «старый» стиль поддерживается, я такое только в книжках видел.

> я ещё фигурную скобку начала функции писал на той же строке
Я пока пишу.

> Для форматирования кода я использую clang-format, у которого очень много
> ручек настройки этого форматирования.
Не знал, что такое есть. Каждый сам настроит, как хочет, а как же унификация?

комментарий 3:

From: Sergey Matveev
Date: 2021-01-11 13:53:53Z

	** David Rabkin [2021-01-11 15:36]:

>Я удивился, что «старый» стиль поддерживается, я такое только в книжках видел.
>С другой стороны, зачем все эти игры разума при
>современных компиляторах и СиПиЮ?

Думаю потому что daemontools был написан в конце 90-х. И думаю что на
тот момент запросто существовало куча каких-нибудь HP-UX, AIX, SunOS
систем, вполне эксплуатируемых, которые не понимали бы по другому. Ну и
оптимизации не имели какие есть сейчас. Просто предположения. Ну и может
DJB просто так привык и не хотел переучиваться.

>Тогда, можно улучшить функцию: восемь строк для 64-битной
>архитектуры :-)

Типа того :-). Хотя в некоторых процессорах (IA64 например) вообще есть
отдельные ассемблерные команды для поиска позиции нулевого байта.

>Вертикальными пробелами, мне кажется, называют пустые строки, как в
>str_len после register const char *t;. Считается, что это улучшает
>читаемость. Я не согласен. Разбиение на короткие функции, где не нужны
>пустые строки, улучшает читаемость. А бесконечные функции, где без
>пустых строк глаза в кучу, — в топку.

Ага, понял. Солидарен. Блоки внутри функи я бывает и разбиваю пробелами,
но редко. А у у DJB действительно почти все функи достаточно коротки
чтобы ничего подобного не надо было делать.

>Я пока пишу.

Она мне визуально всё равно не нравится, но другого способа нормально
"прыгать" на след/пред функции в Vi я не нашёл. В каком-нибудь Go,
Python можно понимать где начало функци по "func" и "def"/"class"
всяким, а в Си в общем случае регулярным выражением не получится
понять что начало функции. Поэтому делаю (только для фунок!) фигурную на
новой строке (ну точнее не я, а clang-format). Такая мелочь как
func/fun/def/class -- а сколько пользы от них :-)!

>Не знал, что такое есть. Каждый сам настроит, как хочет, а как же унификация?

Ну предполагается что конфиг для него общий для всех во всём проекте и
все его используют. Закоммичен куда-нибудь. Там много "profile"-ов уже
вбито даже из коробки, типа: LLVM, GNU, Google, Chromium, Microsoft,
Mozilla, WebKit.

комментарий 4:

From: Sergey Matveev
Date: 2021-01-11 13:55:53Z


	** Sergey Matveev [2021-01-11 16:53]:

>Блоки внутри функи я бывает и разбиваю пробелами,

Пустыми строками, конечно же.

комментарий 5:

From: David Rabkin
Date: 2021-01-11 17:11:43Z

>А у у DJB действительно почти все функи достаточно коротки
>чтобы ничего подобного не надо было делать.
Именно. Я, кстати, не сразу к этому пришел, и писать короткие функции
с понятными именами сложнее, чем хреначить подряд. К сожалению, в
промышленном программировании чаще встречается последние.

Как-то в коде продукта, которым пользуется Путин
(https://www.google.com/search?q=polycom+putin), я заметил два соурс
файла: Conf.cpp и Conf1.cpp. На вопрос, что за хрень, последовало
гениальное (а потом и начальство подтвердило):
— Тут настолько много важной логики, что разделить нельзя, а компайлер
падает из-за размера сорца. Поэтому разделили на два файла.

Каждый из файлов был по двадцать тысяч строк! Вот это сила! Компания с
таким подходом в последний раз продалась за два миллиарда.

>Она мне визуально всё равно не нравится
Мне тоже.

>а в Си в общем случае регулярным выражением не получится
>понять что начало функции
Кстати, в CLion прыгает нормально в любом стиле, так что можно как-то
распарсить.

комментарий 6:

From: Sergey Matveev
Date: 2021-01-11 17:27:56Z

	** David Rabkin [2021-01-11 19:08]:

>— Тут настолько много важной логики, что разделить нельзя, а компайлер
>падает из-за размера сорца. Поэтому разделили на два файла.

Нашли проблему -- решили проблему, все довольны :-). Для меня это из той
же серии что в Unix и ранних Си программах использовали всякие короткие
названия переменных ("a", вместо "first" какого-нибудь), потому что
иначе в память не влезало бы при компиляции/парсинге/whatever.

>Кстати, в CLion прыгает нормально в любом стиле, так что можно как-то
>распарсить.

Ну это уже полноценный синтаксический анализ и именно парсинг. Само
собой его можно проделать, но... это уже то, что я называю IDE. Когда в
руках не просто редактор, а нечто уже понимающее что за текст перед ним.
Так то и через LSP наверное у Clangd (LSP сервер от Clang/LLVM) можно
узнать расположение фунок в файле и прыгать по ним.

Сгенерирован: SGBlog 0.34.0