Гепардово гнездо

PR, кстати, приняли 🎉🎉🎉

https://github.com/boostorg/beast/pull/2878

☕️☕️☕️

Как думаете, примут ли PR? :) :)

Как я в Nim коммитил

Немного расскажу про то, как я коммитил (раз, два) в язык программирования Nim.

Сначала кратко про сам язык. Если бегло посмотреть на примеры кода, то может показаться, что это компилируемый и типизированный Python. Однако такое описание не совсем точное: на самом деле, кроме Python, язык позаимстововал кучу полезных штук из C++, Pascal (из моего любимого — возможность легко делать индексы массивов enum'ами) и не только. В языке еще есть своя система отслеживания эффектов и гибкие макросы (из интересного — конструкция => для простого создания лямбд задана не как часть синтаксиса, а в виде макроса). Borrow checker'а и подобных штук для memory safety, как в Rust, нет, зато есть сборщик мусора (впрочем, можно писать код и на сырых указателях без него, если хочется)

Авторы языка не стали делать компиляцию через LLVM, а компилируют через трансляцию кода в C, C++ или JavaScript (что позволяет легко интегрироваться с существующими либами на этих языках)

В общем, язык довольно интересный, и я решил попробовать на нем написать какой-нибудь код. За это время я обнаружил пару интересных багов и решил занести фиксы в upstream.

Чтобы пофиксить баг, надо сначала научиться собирать компилятор. Как полагается современным языкам, компилятор Nim написан на нем самом :) Поэтому собирают его так: сначала надо взять предварительно оттранслированные в Си исходники и собрать компилятор из них, а затем уже, используя собранный из исходников на Си компилятор, собрать его еще раз, но теперь уже из исходников на Nim. Кажется довольно нестандартным, потому что обычно self-hosted языки можно собрать предыдущей стабильной версией компилятора. Но не в случае Nim: здесь сборка последней стабильной версией оказалась not supported and I don't know if it's fixable 🐳

После сборки компилятора все пошло довольно просто: надо написать код и прогнать тесты. Для удобной работы с репозиторием компилятора придумали утилиту koch, которая «a replacement for make and shell scripting», но «much more portable.» [угадайте, на чем эта portable утилита написана? :)]

Дальше осталось только сделать PR'ы (раз, два) и ждать, пока мейнтейнеры обратят на тебя внимание и заставят все переделывать. К счастью, здесь все прошло довольно гладко, и мои PRы влили без вопросов. Разве что их CI довольно любит флапать 🐳

Пост уже и так получился длинный, поэтому впечатления от самого языка, наверное, описывать здесь подробно не буду. Поделюсь лишь кратко: видно, что проект интересный, и потенциал у него есть, но в то же время у языка куда меньше пользователей и разработчиков, чем у Go, Rust и других мейнстримных языков, поэтому с библиотеками все сложнее (хотя пакетный менеджер имеется). Еще из минусов — язык местами слишком гибкий, и позволяет писать одинаковые вещи очень по-разному. А в остальном выглядит неплохо :)

master vs main

В интернетах давно существуют споры про то, как называть главную ветку в Git проектах — master или main. Предлагаю альтернативный вариант — называть главную ветку в git'е просто m.

Плюсы:
- легко запомнить
- быстро набирать
- коротко и ясно
- не несет никаких негативных смыслов

Минусы:
- непривычно
- больше не нашел

Что думаете? :)

Для контекста: есть старое видео про то, почему нельзя кричать на HDD'шки в датацентре

(стоит отметить при этом, что SSD'шки на крик так не реагируют)

Смотрите, что нашел:
https://crates.io/crates/unicode_categories

> всего лишь 16 звезд на гитхабе
> пакет давно заброшен, последний релиз был 7 лет назад, последний коммит — 3 года назад
> ссылка на доку ведет на несуществующий более сайт
> тем не менее, пакет имеет почти 20 млн скачиваний на crates.io и доходит до 60000 скачиваний в день, из-за того, что от него зависит https://crates.io/crates/sqlx

Кандидат на новый leftpad? 🤔🤔

Каналу исполняется год!

Ровно год назад я совершил ошибку и создал этот замечательный канал. Поздравляю всех подписчиков [и себя тоже :)] с этим событием 🎉🎉🎉

В комментариях можете писать любую критику, пожелания и предложения насчет канала, а также гневные отзывы насчет малого количества постов :) :) :) Скажу честно: я не обещаю, что учту весь фидбек, но узнать мнение читателей всегда бывает интересно

Кстати, насчет количества постов: я понял, что мне довольно трудно постить что-либо по графику. Когда канал только создавался, у меня была куча всякого накопленного за много лет материала (в виде закладок в браузере и заметок в markdown-файликах). Поскольку контента было достаточно много, я изначально писал посты каждый день или через день, а точнее, писал сразу много постов за один день и ставил их с интервалом в один-два дня в отложку

Увы, старый интересный материал за пару месяцев закончился, а новое появляется не так быстро :( Сейчас я по-прежнему использую отложку, но обычно с очень небольшой задержкой, не более часа [угадайте, кстати, почему так :)]. Только иногда, когда интересного сразу накопилось много, я пишу много постов сразу с задержкой где-то в четыре дня

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

Stay tuned ;)

How to sound smart in your TEDx Talk

https://www.youtube.com/watch?v=8S0FDjFBj8o

Посмотрите, очень забавно :) Спойлер: там спикер своей манерой выступления и речи производит впечатление, будто он рассказывает что-то важное, а на самом деле он несет чепуху и рассказывает о том, как он притворяется

(для тех, кто cannot unsterstand English speech good enough, есть неплохие русские субтитры)

Канал про C++: дайте буст
C++: у нас уже есть буст дома
Буст дома: boost

Тонкости парсинга JSON

Казалось бы, JSON — формат очень простой, и сложно его интерпретировать неправильно. Но на самом деле у него есть свои тонкости, которые в разных языках и библиотеках учитываются очень по-разному. Например:

* 1, false, null, "valid json" — валидные JSON'ы? Или на верхнем уровне могут встречаться лишь массивы и объекты?
* насколько большие числа допускаются в JSON? Обязан ли парсер обрабатывать целые числа больше 2^31? А целые числа больше 2^53 без округления? А больше 2^63?
* повторяющиеся ключи — это ошибка или валидный JSON? Если второе, то какое значение стоит брать?
* какова должна быть кодировка самого JSON-файла? Произвольная? UTF-8? UTF-16?
* что считать валидными строками? Любая ли последовательность байт допустима? Если строка состоит из Unicode-кодпоинтов, то допустимо ли в ней нахождение суррогатных пар UTF-16?
* какие символы в JSON-файле считать пробелами? Допустимы ли '\r' и '\n'? А таб? А U+2060, который по стандарту Unicode считается пробелом?

Чтобы ответить на многие из этих вопросов, были придуманы разные RFC: RFC 7159, RFC 7493 (I-JSON) и, наконец, RFC 8259.

Более подробно можно почитать здесь. Автор этого поста сравнивает огромное число парсеров JSON на соответствие RFC 8259 на указанных выше (и других!) примерах.

Очень захотелось сделать вот такие вот два мема

Итак, разгадка

Функция из предыдущего поста принимает год, месяц и день, и возвращает порядковый номер дня с 1 января 1 года. При этом високосные годы учтены правильно:

foo(1, 1, 1) = 1
foo(1, 1, 31) = 31
foo(1, 2, 1) = 32
foo(2000, 2, 28) = 730178
foo(2000, 3, 1) = 730180
foo(2100, 2, 28) = 766703
foo(2100, 3, 1) = 766704
foo(2023, 8, 16) = 738748

Объяснение, как это работает, можно почитать здесь: https://dotat.at/@/2008-09-10-counting-the-days.html

Там же описана и обратная операция (по номеру дня вычислить дату), но она уже производится несколько сложнее: https://dotat.at/@/2008-09-15-the-date-of-the-count.html

Код для обратной операции выглядит вот так:

void G(int d, int *py, int *pm, int *pd) {
  int y, m;
  d += 305;
  y = d*400/146097 + 1;
  y -= y*1461/4 - y/100 + y/400 > d;
  d -= y*1461/4 - y/100 + y/400 - 31;
  m = d*17/520;
  d -= m*520/17;
  if (m < 11) m += 2; else m -= 10, y += 1;
  *py = y, *pm = m, *pd = d;
}

Угадайте, что делает следующий код:

int foo(int b, int a, int r) {
if (a > 2) a += 1; else a += 13, b -= 1;
return b*1461/4 - b/100 + b/400 + a*153/5 + r - 428;
}

Названия переменных здесь специально изменены, чтобы чуть затруднить угадывание :)

Разгадка (и объяснение!) будет завтра

Так, автор канала вышел из творческого кризиса длиною в месяц, и теперь здесь снова будут посты 🎉

Falsehoods Programmers Believe About Phone Numbers

https://github.com/google/libphonenumber/blob/master/FALSEHOODS.md

Забавно, кстати, что эта статья лежит прямо в репозитории libphonenumber — библиотеки для работы с телефонными номерами :)

Every cloud has a server lining.

(за пояснительной бригадой сюда)

http://lib.ru/INOFANT/BRAUN_F/etaoin.txt

Нашел вот такой вот фантастический рассказ 1942 года. Забавно, насколько он связан с современными большими языковыми моделями :)

Update: мой (наполовину мой) pull request в Poco наконец-то залили 🎉

Осталось только дождаться, когда они выкатят очередной релиз