Asciinema: الوقت الكمي

sickill أي رأي حول هذا؟

هذه فكرة مثيرة للاهتمام. لدي شعور بأن هذا سيستخدم من قبل عدد قليل جدًا من المستخدمين. -w كما هو عليه اليوم مفيد جدًا بالفعل ولكن مما أعرف أنه لا يستخدمه الكثير من الناس - يستخدم الناس الإعدادات الافتراضية فقط.

أنا على الحياد هنا ... من ناحية ، تعجبني الفكرة حقًا ، ومن ناحية أخرى أعلم أنها ستضيف قدرًا معقولاً من الكود ، والرمز الذي سيتعين صيانته لـ 1٪ من المستخدمين على الأرجح (أثبت أنني مخطئ بالنسبة للتقديرات هنا ؛))

ماذا عن هذا:

خطرت لي هذه الفكرة لفترة من الوقت لإنشاء مجموعة منفصلة من الأدوات لمعالجة الإرسال المتصاعد. أشياء مثل تسريعها مرتين ، قم بتطبيق خوارزمية -w على ملف تصاعدي مسجل بالفعل ، حدد موقع + محو النص التعسفي (كلمات المرور المرئية).

يمكن أن يكون لدينا آلية لإضافة أوامر إضافية إلى asciinema ، ويتم ذلك بنفس الطريقة كما في git - عند تشغيل asciinema foo فإنه يتحقق مما إذا كان foo هو أمر داخلي ، إذا لم يكن الأمر كذلك ، فإنه يبحث عن asciinema-foo ثنائي في $PATH ويقوم بتشغيله بدلاً من ذلك. يمكنك كتابة أوامر إضافية بأي لغة.

بعد ما سبق ، يمكننا إنشاء asciinema-quantize ، أو بشكل عام asciinema-process ، والذي يمكن أن يدعم مفاتيح مختلفة (مثل تحسين -w ، ربما -s لتغيير سرعة تسجيل كامل). يقرأ الإدخال json ، ويعالجها وفقًا للخيارات ، ويكتب الإخراج json. إذا كان أمرًا شائعًا ، فيمكن ترقيته إلى أمر داخلي (أو يتم شحنه في حزم asciinema كـ asciinema-* ثنائيات).

أنا منفتح على اقتراحات أخرى!

في الواقع كنت أفكر في الأمر نفسه: القيام بذلك خارجيًا ، فقط معالجة ملف json القياسي. الشيء الآخر هو أنه ليس لدي الكثير من الوقت في الوقت الحالي لتعلم Go ، ولكن إذا كان تكامل الأوامر الخارجية هذا سيعمل مع أي ملفات تنفيذية مسماة في الاتفاقية ، فإن هذا قد يجعل تمديد asciinema أسهل بكثير.

بالمناسبة ، أعتقد أنك تعرف عن asciinema2gif وهو مفيد جدًا ويعمل فقط. لقد رأيت بعض المناقشات هنا حول تحويل gif وأنه ليس في الخطط ، وأنا أفهم ذلك تمامًا ، ولكن لا يزال نظرًا لأن المستخدمين قد يكون لديهم احتياجات مختلفة ، فقد تكون هذه القابلية للتوسعة طريقة لطيفة جدًا للسماح للمستخدمين بتلبية احتياجاتهم الخاصة بأنفسهم.

سعيد لسماع رأي مماثل. هل أنت أكثر دراية ببايثون؟ ما هي اللغة التي ستطبق فيها هذا؟

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-guru ، لذا من المحتمل أن يكون ذلك أسهل ، لكن هذا واضح تمامًا (إذا كان الشخص على دراية بـ jq بشكل عام) وهو يعمل. يعد تنفيذ ميزة تكميم الوقت المقترحة بهذه الطريقة أكثر تعقيدًا ، ولكنه تافه أيضًا.

يمكن أن يكون هذا ، بالطبع ، ملفوفًا في أي نوع من البرامج النصية للقذيفة مع خيارات محددة. ولكن إذا كنت تريد المزيد من التكامل ، فيمكن إجراؤه أيضًا بطريقة متشابهة جدًا باستخدام JMESPath ، والذي يحتوي على تطبيقات مختلفة بما في ذلك Python و Go.

مرحبًا laughedelic ،

كان لدي نفس متطلباتك إلى حد كبير ، لذلك انتهى بي الأمر بإنشاء هذا https://github.com/cirocosta/asciinema-edit

يستغرق هذا المصبوب Asciinema (v2) ثم يغير تدفق الحدث وفقًا لما تحتاجه.

لقد انتهيت للتو من إضافة التكميم بالطريقة التي وصفتها ، بالمناسبة 👍

آمل أن يكون مفيدًا لك!

شكرا!

مرحباcirocosta! شكرا على ping لي! إنه لأمر رائع أنك قمت بتحويلها إلى أداة وأنها تعمل بتنسيق v2. سأحاول ذلك في المرة القادمة التي أسجل فيها فريق عمل أسكي.