Asciinema: Quantização do tempo

@sickill alguma opinião sobre isso?

É uma ideia interessante. Tenho a sensação de que isso seria usado por uma quantidade muito pequena de usuários. -w como é hoje já é muito útil, mas pelo que eu sei, muitas pessoas não o usam - as pessoas apenas usam os padrões.

Estou em cima do muro ... Por um lado eu gosto muito da ideia, por outro sei que acrescentaria uma boa quantidade de código, código que precisará ser mantido por provavelmente 1% dos usuários (prove que estou errado quanto às estimativas aqui;))

Que tal isso:

Por um tempo, tive a ideia de criar um conjunto separado de ferramentas para processar ascicatas. Coisas como acelerar 2x, aplicar algoritmo -w ao arquivo asciicast já gravado, localizar + apagar texto arbitrário (senhas visíveis).

Poderíamos ter um mecanismo para adicionar comandos extras a asciinema , feito da mesma maneira que em git - quando você executa asciinema foo ele verifica se foo é seu comando interno, se não, procura asciinema-foo binário em $PATH e o executa em seu lugar. Você pode escrever comandos extras em qualquer idioma.

Tendo acima, poderíamos criar asciinema-quantize , ou mais geral asciinema-process , que poderia suportar várias opções (como -w melhorado, talvez -s para alterar a velocidade do toda a gravação). Ele iria ler json de entrada, processá-lo de acordo com as opções e escrever json de saída. Se fosse um comando popular, ele poderia ser promovido a comando interno (ou enviado em pacotes asciinema como asciinema-* binários).

Estou aberto a outras sugestões!

Na verdade eu estava pensando o mesmo: fazer externamente, só processando o arquivo json do registro. A outra coisa é que não tenho muito tempo agora para aprender Go, mas se essa integração de comandos externos funcionasse com qualquer executável nomeado pela convenção, isso poderia tornar a extensão do asciinema muito mais fácil.

A propósito, acho que você conhece o asciinema2gif, que é bastante útil e funciona. Eu vi alguma discussão aqui sobre conversão de gif e que não está nos planos, e eu entendo perfeitamente, mas ainda como os usuários podem ter necessidades diferentes, tal extensibilidade pode ser uma maneira muito boa de permitir que os próprios usuários atendam às suas necessidades específicas.

Fico feliz em ouvir uma opinião semelhante. Você está mais familiarizado com Python? Qual é a linguagem em que você implementaria isso?

@sickill bem, na verdade eu estava usando jq com alguns filtros primitivos até agora. Por exemplo:

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

Irá produzir um json que será jogado por asciinema play duas vezes mais rápido. Ou

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

é o mesmo que definir max-wait time para 1.234 . Não sou um jq-guru, então provavelmente pode ser mais fácil, mas é bastante simples (se alguém estiver familiarizado com jq em geral) e funciona. Implementar o recurso de quantização de tempo proposto dessa forma é um pouco mais complicado, mas também trivial.

Isso pode ser, é claro, envolvido em qualquer tipo de script de shell com opções especificadas. Mas se você quiser um pouco mais de integração, também pode ser feito de uma maneira _muito semelhante_ usando JMESPath , que tem várias implementações, incluindo Python e Go.

Ei @laughedelic ,

Eu tinha praticamente os mesmos requisitos que o seu, então acabei criando este https://github.com/cirocosta/asciinema-edit

É necessário um elenco asciinema (v2) e, em seguida, altera o fluxo de eventos de acordo com o que você precisa.

Acabei de adicionar quantização da maneira que você descreveu, btw 👍

Espero que seja útil para você!

Valeu!

Olá @cirocosta! Obrigado por me enviar um ping! É incrível que você o tenha transformado em uma ferramenta e funcione com o formato v2. Vou tentar na próxima vez que gravar um elenco de asciinema.