Asciinema: Квантование по времени

Созданный на 20 мая 2016  ·  7Комментарии  ·  Источник: asciinema/asciinema

Основываясь на недавно объединенном # 156, я хочу предложить следующую функцию: --max-wait option может принимать последовательность максимальных границ ожидания (или для этого может быть другой вариант). Например:

asciinema rec -w 0.4 0.8 1 3

(формат обсуждается, возможно, что-то с разделителем, отличным от пробела, лучше / легче разобрать: 0.4,0.8,1,3 )

Это означало бы, что

  • время задержки от 400 мс до 800 мс сокращено до 400 мс
  • временные задержки от 800 мс до 1 сокращены до 800 мс
  • время задержки между 1 и 3 с сокращается до 1 с
  • временные задержки более 3 секунд сокращаются до 3 секунд (как и в случае однозначного max-wait )

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

Что вы думаете об этой функции? Думаю, сделать это несложно и я смог бы это реализовать.

Самый полезный комментарий

Привет @laughedelic ,

У меня были примерно те же требования, что и у вас, поэтому я создал этот https://github.com/cirocosta/asciinema-edit

Он принимает asciinema cast (v2), а затем мутирует поток событий в соответствии с тем, что вам нужно.

Я только что закончил добавлять квантование, как вы описали, кстати 👍

Надеюсь, это будет полезно для вас!

Спасибо!

Все 7 Комментарий

@sickill есть

Это интересная идея. У меня есть ощущение, что это будет использовать очень небольшое количество пользователей. -w в том виде, в каком он есть сегодня, уже очень полезен, но, насколько я знаю, не многие люди используют его - люди просто используют значения по умолчанию.

Я здесь на заборе ... С одной стороны, мне очень нравится эта идея, с другой - я знаю, что она добавит изрядное количество кода, кода, который нужно будет поддерживать, вероятно, для 1% пользователей (докажите, что я ошибаюсь насчет оценок тут;))

Как насчет этого:

Какое-то время у меня возникла идея создать отдельный набор инструментов для обработки асцикастов. Такие вещи, как ускорение в 2 раза, применение алгоритма -w к уже записанному файлу asciicast, поиск + удаление произвольного текста (видимые пароли).

У нас может быть механизм для добавления дополнительных команд в asciinema , выполняемый так же, как в git - когда вы запускаете asciinema foo он проверяет, является ли foo его внутренняя команда, в противном случае она ищет двоичный файл asciinema-foo в $PATH и запускает его вместо этого. Вы можете писать дополнительные команды на любом языке.

Имея вышеуказанное, мы могли бы создать asciinema-quantize или более общий asciinema-process , который может поддерживать различные переключатели (например, улучшенный -w , возможно, -s для изменения скорости вся запись). Он будет читать входной json, обрабатывать его в соответствии с параметрами и записывать выходной json. Если бы это была популярная команда, ее можно было бы превратить в внутреннюю команду (или поставлять в пакетах asciinema как двоичные файлы asciinema-* ).

Я открыт для других предложений!

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

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

Рад слышать похожее мнение. Вы больше знакомы с Python? На каком языке вы бы это реализовали?

@sickill ну, на самом деле я до сих пор использовал jq с некоторыми примитивными фильтрами. Например:

jq '.stdout |= map(.[0] *= 0.5)' record.json > record.twice-faster.json

Создаст json, который asciinema play будет воспроизводить в два раза быстрее. Или

jq '.stdout |= map(.[0] |= ([., 1.234] | min))' record.json > record.cut.json

аналогично установке max-wait time на 1.234 . Я не jq-гуру, так что, вероятно, это можно сделать проще, но это довольно просто (если кто-то знаком с jq в целом), и это работает. Реализация предлагаемой функции квантования времени таким способом немного сложнее, но также тривиальна.

Это, конечно, может быть заключено в любой сценарий оболочки с указанными параметрами. Но если вам нужна дополнительная интеграция, это также можно сделать _ очень похожим_ способом, используя JMESPath , который имеет различные реализации, включая Python и Go.

Привет @laughedelic ,

У меня были примерно те же требования, что и у вас, поэтому я создал этот https://github.com/cirocosta/asciinema-edit

Он принимает asciinema cast (v2), а затем мутирует поток событий в соответствии с тем, что вам нужно.

Я только что закончил добавлять квантование, как вы описали, кстати 👍

Надеюсь, это будет полезно для вас!

Спасибо!

Привет @cirocosta! Спасибо, что позвонили мне! Замечательно, что вы превратили его в инструмент и что он работает с форматом v2. Я попробую это сделать в следующий раз, когда запишу асинематографический состав.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги