Вот я вернулся, и тупая телега расположила посты в неправильном порядке -_- Сорян.

В свободное время я продолжаю развивать olytest - прогу для быстрого тестирования программ во время олимпиадного программирования.

Последние фичи:
1. Возможность тестировать конкретный экзешник - a, b, e1. Раньше тестирование запускалось только из main.rs файла, и прошлый код приходилось стирать.
2. Появились CLI команды для генерации и удаления кода экзешников.

Следующие фичи будут обозначаться отдельно, потому что я хочу их прокомментировать.

Фича #3: Автоматический парсинг страницы на codeforces, извлечение имён всех задач и тестов с входными и выхоными данными.

Я парсю html через соответствующие библиотеки, и обращаюсь к результату через селекторы, например все входные данные описываются так: "div.input pre". Что удивительно, для растишки все такие библиотеки есть, и подключаются в два клика.

Фича #4: Возможность указывать в тесте чекер (который ты напишешь как обычный экзешник), который будет интерактивно общаться с программой, и проверять её результат.

А вот это уже интересно. Чтобы понимать что такое интерактивное общение, можете прочитать условия этой задачи: https://codeforces.com/contest/1451/problem/E2. Очевидно, что такую задачу тестировать довольно нетривиально. Нужно написать две программы: одна решает саму задачу, другая осуществляет интерактивное общение для заданного массива.

То есть, у нас есть программы А и Б. А решает задачу, а Б общается с А, предоставляя ей информацию на вход. Что есть тест? Например, у нас есть массив 0 0 2 3. Как нам протестировать что программа А способна получить этот массив? Можно подать его на вход Б, Б выведет нужную информацию и далее будет общаться с А.

Значит, изначально, тест мы записываем в stdin Б, затем stdout от Б мы направляем на stdin А, а stdout от A направляем на stdin Б. А как можно после этого узнать правильный ли выдала ответ программа А или нет? Б может записывать вердикт в свой stderr.

И существует два вида тестов:
* Обычный тест: вход теста подаётся на stdin программы, а выход теста сравнивается с stdout программы.
* Тест с чекером: вход теста подаётся чекеру на вход, а выход теста сравнивается с stderr чекера.

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

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

А теперь самое интересно, как это запрограммировать? Окей, создаём два процесса через std::process::Command, берём их входы и выходы, и пытаемся читать и писать через read-write. И сталкиваемся с проблемой, что ввод в расте по умолчанию блокирующий. Это означает, что если прямщас байтов нету, то вызов read будет ждать пока программа не выведет данные.

А это серьёзная проблема, ведь как можно видеть по этой задаче E2, одна программа начинает выводить результат исключительно после того как получит информацию от другой. При этом у нас вывод может быть неизвестного размера, и может не поместиться в буфер сразу, а может и вообще быть кратен буферу. И у нас нет способа узнать когда мы прочитали все байты что программа вывела прям щас, а когда нет.

Это приводит к тому, что нужно использовать неблокирующий ввод-вывод. А как я понял, официально, и кросс-платформенно он существует только в виде машинерии async/await, и, например, в tokio.

⬇️

Я про async/await не знал абсолютно ничего, и очень тяжело было прийти к первому рабочему прототипу. Я всё же хотел сделать всё очень императивно, найти такой метод, который мне мог бы чётко сказать: ПРЯМ_ЩАС_БАЙТОВ_НЕТУ. Такой метод правда есть, и он называется poll_read, но он какой-то очень сложный, ему нужен какой-то контекст, какой-то waker, а я не знаю откуда всё это взять. Поэтому пришлось извращаться как есть, и несложными измышлениями, и поверхностным чтением документации я пришёл к тому, что нужно использовать макрос select!{}, который из нескольких футур выбирает ту, которая завершится первой.

У нас может быть две главные футуры:
* Чтение stdout чекера
* Чтение stdout программы

После того как мы прочитали хоть сколько-нибудь информации из каждого источника, мы можем сразу записывать в stdin другого. Так что макрос select!{} вполне подходит, но он мне как-то не нравится, ибо с ним надо было иметь для каждого читателя по отдельному буферу, и я хотел прийти всё же к ПРЯМ_ЩАС_БАЙТОВ_НЕТУ.

Затем благодаря помощи Вафеля обнаружился метод futures::poll_fn, который позволяет вызывать сложнющий poll_read без ручного создания всяких контекстов итд. Я как увидел этот метод, сразу понял, что мне нужен был именно он, и недоумевал, почему такой прекрасный метод не суют во все туториалы и вводные по async/await'у в расте.

В итоге я пришёл к такому коду: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=163960a0f7031364984e2099c0a4de66 .

Он вроде работал, и всё было хорошо, но затем я заметил, что когда один из процессов начинает паниковать и выводить кучу инфы в stderr, которая не умещается в буфер, у меня переставало работать считывание. Тупо зависало. Когда я пытался локализовать в каком месте оно зависало, и писал макрос dbg!(), ОНО НЕ ЗАВИСАЛО. Когда я пытался сделать работу помедленней, и ставил sleep(100ms), ОНО НЕ ЗАВИСАЛО. Я погрешил на async/await, что из-за своей сложности они создают какие-то квантовые эффекты, измерение которых приводит к их исчезновению.

Но затем мне всё же удалось найти место, куда можно поставить dbg!() без исчезновения квантовых эффектов, но это ничего не дало. Затем я нарушил своё отстранение от телеги и зашёл в async-чатик и задал там свой вопрос (и сейчас понял что там в коде неправильная ссылка): https://xn--r1a.website/rust_async/29266 (можно не читать). Мне никто не отвечал, поэтому я продолжил решать проблему самостоятельно. И как это обычно у меня бывает, благодаря тому что для чатика я очень хорошо сформулировал вопрос, я начал понимать свою проблему лучше, и потом размышлениями пришёл к такому:

В моём методе poll_read вызывается внутри цикла постоянно и через очень короткие промежутки времени. Когда я ставил задержку или dbg!(), эти промежутки времени увеличивались. А у async/await есть такая штука как waker, и по идее poll_методы нужно вызывать только после того как твоего waker'а ткнут носом что всё закончилось. А я их вызывал в цикле. И видимо, на внутреннюю машинерию асинхронного кода и регистрацию этих waker'ов тратилось время больше, чем мои промежутки времени в цикле, поэтому у меня "неблокирующее" чтение никак не могло выдать результат, который бы отличался от Pending.

В общем я осознал свою ошибку и вернулся на select!{}. И как я потом замерил, select!{} использует минимальное число обращений к чтению, потому что блокируется на всех футурах, если они все не дают результат прямщас. А это значит, что он и эффективней.

⬇️

Фича #5: Модифицировал синтаксис тестов. Теперь он хранится в одном файле, поддерживает экранирование, поддерживает задание чекера, и состоит всего из трёх символов.

Более подробно:
* Вход и выход теста теперь находится в одном файле по совету Сергея Совы.
* Разные тесты разделяются символом \.
* Вход и выход разделяются либо символом ~, либо символом %. Первый символ пишется в случае обычного теста, а второй в случае наличия чекера. Если нужно, чтобы тест не сравнивался с чем-то, а его результат просто вывелся на экран, то выход может быть просто набором пробельных символов.
* Так же я сделал токенизацию выхода программы и теста, чтобы лишние пробелы и лишние пустые строки не влияли на результат, и чтобы легко было сравнивать.
* Экранировать один из трёх управляющих символов можно тупо написав его два раза.

Для синтаксиса тестов я старался выбирать символы, которые практически никогда не встречаются в тестах олимпиадных задачек, но иногда всё же могут встретиться, и экранировать их - важно. Я часто замечаю, что экранированию синтаксиса уделяется мало внимания при проектировании языка описания чего-то. Для меня растовские строки с r#"text"# стали откровением в области экранирования, ведь это гениально, сделать хэши, чтобы можно было без проблем писать кавычки. Жаль что эти строки являются raw, и внутри них нельзя писать \n чтобы обознчаить перенос строки. Я бы хотел обычную строку, но с хэшами: #" "hi" - says\nsimon "#.

Далее в olytest у меня осталось три жирных пункта:
* Добавить возможность писать в олимпиадной программе include!(), чтобы вместо этого подставлялся нужный текст, и генерировался в отдельный файл, чтобы вручную не копипастить.
* Добавить поддержку ЯП: C++ и Python/PyPy. Это самые частые языки для олимпиадного программирования.
* Написать доку на английском и русском.

После этих трёх пунктов я отлажу программу на себе, своих знакомых, и затем можно будет её официально представить на codeforces, ибо у людей спрос на что-то такое есть: они на стримах с разборами у neal'а постоянно спрашивают что у него там за скрипты и где их можно взять (кто не помнит, я вдохновился именно его скриптами).

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

⬇️

Тестирование всех экзешников.

⬇️

Тестирование той самой задачи с использованием чекера.

⬇️

Так же происходит замер времени, если указать флаг -t.

С НГ! Желаю в этом году чтобы произошёл качественный переход, после которого от тебя все отстанут и будут меньше трепать нервы и отнимать время

В копилочку о том почему шкалам оценки нужно переосмысление, которое я описывал в этом посте.

How gamers see review scores now.

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

https://optozorax.github.io/5-point-ratings-are-wrong

Как известно, я очень упорот по клавиатурам.

И в этой области я развиваюсь уже много лет, поэтому мне есть что сказать. И вот думал что неплохо было бы написать статью о своей раскладке (а она довольно уникальна). Получилась, конечно, статья о раскладке, но случайно я параллельно рассказал про десятипальцевый метод, про неверность стандартных клавиатур и историю своего развития. Получилась огромная статья на 200к символов, которую читать, наверное, 2 часа.

Так что приятного чтения! 🍿

#клавиатуры

ДР Канала! Вчера, 24 января, данному каналу исполнился год. И как раз аккурат к этому событию количество подписчиков перевалило за 4 сотни. За этот год сюда было написано почти 300 сообщений.

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

Я тут вдохновился статьёй про однорукую раскладку OPRI, и решил придумать что-то аккордовое, чтобы можно было одной рукой нажимать любой хоткей.

И получилось такая клавиатура - Hotkeypad. Тут вся основная инфа написана на картинке. Главное отличие от Кладенца - это то, что любой хоткей нажимается одним аккордом, когда как на Кладенце хоткеи одной рукой нажимаются при помощи залипающих модификаторов.

А я вспомнил, что существует #fopply! Я немного посидел над ним и приделал нормальные сообщения об ошибках. Для этого пришлось немного подредачить парсер и написать тонну кода обработки ошибок. В будущем для этого планирую заюзать библиотеку codespan.

У меня выводится сразу несколько сообщений об ошибках, которые можно получить на текущем этапе проверки. Некоторые самописные ЯП'ы таким похвастаться не могут!

Чтобы получить сообщения об ошибках, которые указывают на место ошибки, пришлось сделать такую структурку:

struct Spanned<T> {
    span: Range<usize>,
    inner: T,
}

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

Так же через новую версию, благодаря сообщениям об ошибках, которые указывают на проблему, я смог доказать (a+b)*(a-b) = a*a-b*b.

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

Как известно, я решил задачу "что будет если поместить портал в портал". Я написал программу, которая проводит вычисление этого, и срендерил результат.

По этому поводу я опубликовал маленькое видео на ютубе, а затем запостил это видео на реддите, и оно там не взлетело, набрав 29 лайков.

Сейчас, спустя год, я решил предпринять попытку №2, и залил видео, чтобы оно было просматриваемо через встроенный в реддит плеер, и сразу переместил указатель начала видео к сути, параллельно ускорив его. Надеюсь это увеличит эффект.

Вот ссылка на новый пост в реддите. Прошу оценить.

Спасибо всем за поддержку, пост набрал 2.8к апвоутов и остановился в подъёме. А теперь немного размышлений по поводу реддита.

Я опубликовал данный пост в r/Portal, где находится 98к подписчиков, и где за всё время самый успешный пост набрал 5к апвоутов. Это означает, что насколько бы хорош мой пост ни был, он вряд ли наберёт больше 5к, потому что на это влияет не только качество поста, но ещё и много других критериев, которые должны сойтись вместе одновременно. А я видел, что обычно всякие крутые вещи на реддите набирают >40к апвоутов, и рассчитывал примерно на это. Я думал, что у реддита есть аналог трендов, и что любой пост может взлететь до небес, если он хорош. А оказывается, нет, и если хочется взлететь до небес, нужно публиковаться в изначально популярном сабреддите.

Ещё пост набрал 2.8к апвоутов, и 70 комментариев, в то время, как тот же самый пост на пикабу набрал 2.4к апвоутов, но 469 комментариев. Плюс на пикабу я опубликовал это с предысторией и приложил видео на ютубе, в котором до момента входа ждать наверное секунд 30. Но, тем не менее, его оценило много людей, и посмотрело много людей. Отсюда можно сделать вывод что пикабу является хорошей площадкой с лояльной и активной аудиторией.

Ещё один вариант как можно увеличить охват на реддите - это кросс-посты. Как я выяснил, нельзя кросс-постить в самые релевантные для моего поста сабреддиты: r/gifs, r/gaming, r/interestingasfuck, r/nextfuckinglevel. Туда можно постить только "оригинальный" контент.

Но можно кросс-постить в менее поулярные сабреддиты, и я постнул в r/DrosteEffect, и какой-то чувак кросс-постнул в r/Recursion.

Теперь я обнаруживаю, что мою гифку перезалили, и опубликовали в r/interestingasfuck, и там пост набрал 4.3к апвоутов.

Я принял правильное решение, что разместил ватермарку посередине картинки, потому что учитывая масштабы копипасты постов, это единственный способ как можно найти оригинал. В будущем думаю сразу размещать ссылку на этот телеграм-канал, написав: t.me/optozorax_dev. Раньше у меня ватермарка была слабо видно, и она была в левом углу картинки, благодаря этому какое-то сообщество в вк, обрезало мою анимацию квадратом, и моей ватермарки как и не бывало.

Так же я принял правильное решение, что в гифке сразу перешёл к делу и показываю процесс входа через 1 секунду от старта, а весь нужный контекст предоставляю в заголовке. Так часто делают, и это работает. В этом плане мою ютубовское видео просто ужасно, потому что оно повторяет заголовок, вводит много ненужной информации в начале, и вообще там всё медленно происходит. Весь процесс можно ускорить в 1.5 раза, и ничего плохого не случится. Так же, если бы я сделал видео максимально коротким, то на ютубе шансов завируситься было бы намного больше, потому что люди на ютубе всегда пишут: "If this video less than a minute, and YouTube recommends it to me, I definitely watch it.".

Будущие посты-гифки по этой теме я планирую публиковать в r/gaming, или r/nextfuckinglevel, и уже потом кросс-постить это в r/Portal (туда кросс-пост разрешён).

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