Asciinema: Zeitquantisierung

Erstellt am 20. Mai 2016  ·  7Kommentare  ·  Quelle: asciinema/asciinema

Basierend auf der Nummer 156, die kürzlich zusammengeführt wurde, möchte ich die folgende Funktion vorschlagen: Die Option --max-wait könnte eine Folge von maximalen Wartezeiten annehmen (oder es könnte eine andere Option dafür geben). Zum Beispiel:

asciinema rec -w 0.4 0.8 1 3

(das Format ist diskutabel, wahrscheinlich ist etwas mit einem Nicht-Leerzeichen-Trennzeichen besser/einfacher zu analysieren: 0.4,0.8,1,3 )

Das würde bedeuten, dass

  • Zeitverzögerungen zwischen 400ms und 800ms werden auf 400ms reduziert
  • Zeitverzögerungen zwischen 800ms und 1s werden auf 800ms reduziert
  • Zeitverzögerungen zwischen 1s und 3s werden auf 1s gekürzt
  • Zeitverzögerungen über 3s werden auf 3s reduziert (wie beim einwertigen max-wait )

Dies würde es ermöglichen, den zeitlichen Ablauf der Aufnahme noch etwas anzupassen, z.

Was halten Sie von dieser Funktion? Ich denke, es ist nicht schwer zu tun und ich könnte es umsetzen.

idea

Hilfreichster Kommentar

Hey @laughedelic ,

Ich hatte so ziemlich die gleichen Anforderungen wie Sie, also habe ich diese https://github.com/cirocosta/asciinema-edit erstellt

Es dauert einen Asciinema-Cast (v2) und ändert dann den Ereignisstrom entsprechend Ihren Anforderungen.

Ich habe gerade die Quantisierung so hinzugefügt, wie Sie es beschrieben haben, übrigens

Hoffe, es ist nützlich für Sie!

Danke!

Alle 7 Kommentare

@sickill eine Meinung dazu?

Das ist eine interessante Idee. Ich habe das Gefühl, dass dies von sehr wenigen Benutzern verwendet wird. -w wie es heute ist, ist bereits sehr nützlich, aber soweit ich weiß, verwenden es nicht viele Leute - die Leute verwenden nur Standardeinstellungen.

Ich bin hier am Zaun ... Einerseits mag ich die Idee wirklich, andererseits weiß ich, dass es eine Menge Code hinzufügen würde, Code, der für wahrscheinlich 1% der Benutzer gewartet werden muss (beweisen Sie mich falsch .) was die Schätzungen hier angeht ;))

Was ist damit:

Ich hatte schon seit einiger Zeit die Idee, einen separaten Satz von Werkzeugen für die Verarbeitung von ASCII-Dateien zu erstellen. Sachen wie 2x beschleunigen, -w Algorithmus auf bereits aufgezeichnete ASCII-Datei anwenden, beliebigen Text suchen+löschen (sichtbare Passwörter).

Wir könnten einen Mechanismus zum Hinzufügen zusätzlicher Befehle zu asciinema , der auf die gleiche Weise wie in git - wenn Sie asciinema foo ausführen, wird überprüft, ob foo seine ist internen Befehl, wenn nicht, sucht er nach der Binärdatei asciinema-foo in $PATH und führt sie stattdessen aus. Sie können zusätzliche Befehle in jeder Sprache schreiben.

Mit dem oben genannten können wir asciinema-quantize oder allgemeinere asciinema-process erstellen, die verschiedene Schalter unterstützen könnten (wie verbessertes -w , vielleicht -s um die Geschwindigkeit des ganze Aufnahme). Es würde Eingabe-Json lesen, gemäß Optionen verarbeiten und Ausgabe-Json schreiben. Wenn es ein beliebter Befehl wäre, könnte er zu einem internen Befehl hochgestuft werden (oder in asciinema-Paketen als asciinema-* Binärdateien geliefert werden).

Für andere Vorschläge bin ich offen!

Eigentlich dachte ich über das gleiche nach: es extern zu tun, nur die json-Datei des Datensatzes zu verarbeiten. Die andere Sache ist, dass ich im Moment nicht viel Zeit habe, um Go zu lernen, aber wenn diese Integration externer Befehle mit allen von der Konvention benannten ausführbaren Dateien funktionieren würde, könnte dies die Erweiterung von Asciinema viel einfacher machen.

Übrigens, ich denke, Sie kennen asciinema2gif, das sehr nützlich ist und einfach funktioniert. Ich habe hier einige Diskussionen über die GIF-Konvertierung gesehen und dass dies nicht in den Plänen enthalten ist, und ich verstehe es vollkommen, aber da Benutzer unterschiedliche Bedürfnisse haben können, könnte eine solche Erweiterbarkeit eine sehr gute Möglichkeit sein, Benutzer ihre spezifischen Bedürfnisse selbst erfüllen zu lassen.

Freue mich über eine ähnliche Meinung. Kennen Sie Python besser? In welcher Sprache würden Sie das implementieren?

@sickill Nun , eigentlich habe ich bisher jq mit einigen primitiven Filtern verwendet. Zum Beispiel:

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

Erzeugt einen Json, der von asciinema play zweimal schneller gespielt wird. Oder

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

entspricht der Einstellung von max-wait time auf 1.234 . Ich bin kein jq-Guru, also geht es wahrscheinlich einfacher, aber das ist ziemlich einfach (wenn man mit jq im Allgemeinen vertraut ist) und es funktioniert. Die vorgeschlagene Zeitquantisierungsfunktion auf diese Weise zu implementieren ist etwas komplizierter, aber auch trivial.

Dies kann natürlich in jede Art von Shell-Skript mit festgelegten Optionen eingebunden werden. Wenn Sie jedoch mehr Integration wünschen, kann dies auch auf _sehr ähnliche_ Weise mit JMESPath erfolgen , das verschiedene Implementierungen enthält, darunter Python und Go.

Hey @laughedelic ,

Ich hatte so ziemlich die gleichen Anforderungen wie Sie, also habe ich diese https://github.com/cirocosta/asciinema-edit erstellt

Es dauert einen Asciinema-Cast (v2) und ändert dann den Ereignisstrom entsprechend Ihren Anforderungen.

Ich habe gerade die Quantisierung so hinzugefügt, wie Sie es beschrieben haben, übrigens

Hoffe, es ist nützlich für Sie!

Danke!

Hallo @cirocosta! Danke, dass du mich angepingt hast! Es ist großartig, dass Sie es zu einem Tool gemacht haben und dass es mit dem v2-Format funktioniert. Ich werde es das nächste Mal versuchen, wenn ich einen Asciinema-Gips aufnehme.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Edo78 picture Edo78  ·  5Kommentare

yuvalif picture yuvalif  ·  10Kommentare

maphew picture maphew  ·  12Kommentare

TyrfingMjolnir picture TyrfingMjolnir  ·  7Kommentare

Bux42 picture Bux42  ·  9Kommentare