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
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.
@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.
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!