Asciinema: Cuantización de tiempo

@sickill alguna opinión sobre esto?

Esa es una idea interesante. Tengo la sensación de que esto sería utilizado por una cantidad muy pequeña de usuarios. -w como está hoy ya es muy útil, pero por lo que sé, no mucha gente lo usa, la gente simplemente usa valores predeterminados.

Estoy en la valla aquí ... Por un lado, me gusta mucho la idea, por el otro, sé que agregaría una buena cantidad de código, código que probablemente deberá mantenerse para el 1% de los usuarios (demuestre que estoy equivocado en cuanto a las estimaciones aquí;))

¿Qué pasa con esto?

Tuve esta idea por un tiempo para crear un conjunto separado de herramientas para procesar asciicasts. Cosas como acelerarlo 2x, aplicar el algoritmo -w al archivo asciicast ya registrado, localizar + borrar texto arbitrario (contraseñas visibles).

Podríamos tener un mecanismo para agregar comandos adicionales a asciinema , hecho de la misma manera que en git - cuando ejecuta asciinema foo comprueba si foo es su comando interno, si no, busca asciinema-foo binario en $PATH y lo ejecuta en su lugar. Puede escribir comandos adicionales en cualquier idioma.

Teniendo lo anterior, podríamos crear asciinema-quantize , o asciinema-process más generales, que podrían admitir varios conmutadores (como -w mejorados, tal vez -s para cambiar la velocidad del grabación completa). Leería json de entrada, lo procesaría de acuerdo con las opciones y escribiría json de salida. Si fuera un comando popular, podría promoverse a comando interno (o enviarse en paquetes asciinema como asciinema-* binarios).

¡Estoy abierto a otras sugerencias!

En realidad, estaba pensando en lo mismo: hacerlo externamente, solo procesando el archivo json de registro. La otra cosa es que no tengo mucho tiempo en este momento para aprender Go, pero si esta integración de comandos externos funciona con cualquier ejecutable nombrado por la convención, esto podría hacer que la extensión de asciinema sea mucho más fácil.

Por cierto, supongo que conoces asciinema2gif, que es bastante útil y simplemente funciona. Vi algo de discusión aquí sobre la conversión de gif y que no está en los planes, y lo entiendo perfectamente, pero aún así como los usuarios pueden tener diferentes necesidades, dicha extensibilidad podría ser una forma muy agradable de permitir que los usuarios satisfagan sus necesidades específicas por sí mismos.

Me alegra escuchar una opinión similar. ¿Está más familiarizado con Python? ¿En qué idioma implementaría esto?

@sickill bueno, en realidad estaba usando jq con algunos filtros primitivos hasta ahora. Por ejemplo:

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

Producirá un json que será reproducido por asciinema play dos veces más rápido. O

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

es lo mismo que establecer max-wait tiempo en 1.234 . No soy un jq-guru, por lo que probablemente se pueda hacer más fácilmente, pero esto es bastante sencillo (si uno está familiarizado con jq en general) y funciona. Implementar la función de cuantificación del tiempo propuesta de esta manera es un poco más complicado, pero también trivial.

Por supuesto, esto puede estar envuelto en cualquier tipo de script de shell con opciones específicas. Pero si desea un poco más de integración, también se puede hacer de una manera _muy similar_ utilizando JMESPath , que tiene varias implementaciones, incluidas Python y Go.

Hola @laughedelic ,

Tenía prácticamente el mismo requisito que el tuyo, así que terminé creando este https://github.com/cirocosta/asciinema-edit

Se necesita un elenco de asciinema (v2) y luego muta el flujo de eventos según lo que necesite.

Acabo de terminar de agregar la cuantificación de la forma que describiste, por cierto 👍

¡Espero que te sea útil!

¡Gracias!

¡Hola @cirocosta! ¡Gracias por enviarme un ping! Es increíble que la hayas convertido en una herramienta y que funcione con el formato v2. Lo intentaré la próxima vez que grabe un elenco de asciinema.