Guard: حارس أعطال Ctrl-C

أواجه هذا أيضًا في 2.2.5.

أواجه هذا أيضًا (نفس تتبع المكدس بشكل فعال) ، ولكن باستخدام Ruby v2.3.0 ، Guard v2.13.0 .

إذا قمت بتشغيل Guard عبر bundle exec guard ثم ضغطت على Ctrl-C عند المطالبة ، أرى المشكلة. ومع ذلك ، إذا قمت بتشغيل guard خلال الحزمة ، فإن الضغط على Ctrl-C لا يسبب المشكلة.

إصدارات كاملة من Ruby و Readline:

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15.5.0]

$ ruby -rreadline -e 'puts Readline::VERSION'
6.3

بعد ظهور أخطاء مطالبة Pry ، أحصل على تلف طرفي مشابه لما هو موصوف هنا:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

إذا قمت بتثبيت جوهرة rb-readline يدويًا ، فإن هذا يعمل على إصلاح مشكلة الفساد التي تحدث بعد ذلك ، ولكن Ctrl-C ينتج نفس تتبع المكدس. مع تثبيت هذه الأحجار الكريمة ، يبلغ الحارس عن إصدار Readline الخاص بي على النحو التالي:

[1] guard(main)> Readline::VERSION
=> "5.2"

الحصول على نفس المشكلة بالضبط هنا ... كما يقترح WilHall ، التجميع الخارجي جيد.

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14]
$ guard -v
Guard version 2.14.0

إصدار Readline الخاص بي هو 6.3 داخل الحارس وخارجه.

يبدو أنه مزيج من عدة أشياء.

من المحتمل أن أقوم بإنشاء فرع "quickfix" ثم أعمل لاحقًا على كيفية دمجه.

حسنًا ، لقد قمت بإنشاء فرع مع بعض الاختراقات: https://github.com/guard/guard/tree/experimental_fixes

إليك كيفية الاستخدام في Gemfile :

gem 'guard', github: 'guard/guard', branch: 'experimental_fixes'

ثم تحديث الحزمة و bundle exec guard كالمعتاد.

قد ترغب أيضًا في محاولة تعطيل الإشعارات لمعرفة ما إذا كان ذلك يساعد أيضًا:

bundle exec guard -n f

الرجاء الإبلاغ عن المشاكل وكذلك الإصلاحات.

بعض المشكلات التي يجب حلها:

1. يجب أن يتوقف Pry عن الانهيار عند الخروج من الحارس باستخدام ctrl-C
2. يجب ألا يخفي الإخراج بعد السطور الأخيرة موجه الغلاف تحته
3. يبدو أن كل من مُخطِّري TMux و TerminalTitle يسببان مشاكل في الإخراج
4. لم أقم بالتحقق ولكن من المحتمل أن تسجيل LumberJack يستخدم تدفق الوقت في حين أنه لا ينبغي.
5. لم يعد تيار STDERR مغلقًا
6. لم يعد القراصنة يقتلون وينضمون - يستيقظون بدلاً من ذلك (لذلك لا ينبغي أن "يتعطل" نظرًا للتعديلات الأخرى)

بعض الانحدارات / القضايا:

1. إذا قام حارس / مهمة بربط الإخراج الملون ، فلن يتم إصلاحه (تم تعطيل إعادة ضبط وحدة التحكم).
2. لا توجد اختبارات لهذا (أحاول معرفة ما إذا كان بإمكاني إصلاح المشكلات أولاً)
3. لم يتم اختباره على أنواع الياقوت الأخرى بخلاف التصوير بالرنين المغناطيسي 2.3.1

الحلول الأخرى:

إذا كنت يائسًا ، يمكنك تجربة استخدام Guard بدون Pry وبدون إشعارات:

bundle exec guard -n f -i

اسمحوا لي أن أعرف ما إذا كان هذا يساعد أو لديه مشاكل أخرى ، حتى أتمكن من العمل من أجل الإصلاح والإفراج رسميًا.

لا تتردد في إرسال تقارير العلاقات العامة التي تستخدم بشكل انتقائي أيًا من هذه الإصلاحات (على الرغم من أن الاختبارات ستكون جيدة).

لقد ضغطت على بعض التعديلات.

يمكنك سحب هذه التغييرات (أو bundle update إذا كنت تستخدم السطر أعلاه Gemfile ) أضف هذا إلى Guardfile لترى ما إذا كان يساعدك:

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

سيتم أيضًا تسجيل الأخطاء في guard.log . (على الرغم من أن ذلك قد يؤدي إلى مسح الدليل بالكامل على OSX).

شكرًا @ e2 ، للأسف لم يحالفني الحظ كثيرًا:

• يظل سلوك الأعطال على Ctrl-C كما هو مع فرع "الميزات التجريبية" عند التشغيل بدون علامات إضافية.
• توفير -n f لا يحدث فرقًا.
• استخدام المعلمة -i يمنع التعطل عند Ctrl-C'ing في الاختبارات (على الرغم من صعوبة الإنهاء!).

غالبًا ما أحصل على أحد الاستثناءات التالية الآن عند الإقلاع باستخدام Ctrl-D ، ربما تكون حالة سباق:

19:56:17 - INFO - Bundle already up-to-date
19:56:17 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^Clog writing failed. can't modify frozen IOError
➜  joinly-app git:(master) ✗
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:69:in `stop': undefined method `destroy' for #<Guard::Jobs::Sleep:0x0056104497dd80> (NoMethodError)
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:53:in `start'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli/environments/valid.rb:16:in `start_guard'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli.rb:122:in `start'
[...]

و

19:56:29 - INFO - Bundle already up-to-date
19:56:30 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^CE, [2016-08-01T19:56:38.584021 #10597] ERROR -- : run() in thread failed: stream closed:\n /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:271:in `read_events'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:238:in `process'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:221:in `run'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
[...]

يبدو أن الخطوط Guardfile ذات bundle exec guard -n f تسبب تأخيرًا في الخطأ. لا يزال الضغط على Ctrl-C أثناء التشغيل التجريبي يتسبب في فصل Pry مع استمرار الاختبار في الكتابة إلى STDOUT ممزوجًا بموجه نشط. لكنها تنتهي بنفس الطريقة:

[1] guard(main)> Error: Input/output error - read
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `block in input_readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/input_lock.rb:115:in `interruptible_region'

شكرا Odaeus للتحقق من هذا.

أولاً ، لقد أفسدت المتفاعل غير الملتصق. (لقد دفعت للتو إلى الالتزام ، لإصلاح هذا).

ثانيًا ، واجهت هذا الخطأ rb-inotify: https://github.com/nex3/rb-inotify/pull/59

التي قمت بإنشاء إصلاح لها (لم يتم دمجها أو إصدارها بعد).

حتى ذلك الحين ، يمكنك استخدام هذا في Gemfile :

gem 'rb-inotify', github: 'e2/rb-inotify', branch: 'e2-fix_ioerror_when_closed'

هذا سوف يحل المشكلة 2.

بالنسبة للمشكلة 3 - من المحتمل أن يكون هذا عملًا قيد التقدم ، ولكن تأكد من أن لديك في Guardfile :

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

ويمكنك استخدام tail -f guard.log على الإخراج في نافذة أخرى.

أشعر بالقلق من إعادة تصميم معالجة جلسة Pry بالكامل لإصلاح ذلك بشكل صحيح. من المحتمل أن يستغرق ذلك يوم السبت بأكمله لممارسة:

إذا كان لدي المزيد من التصحيحات ، فسأخبر الجميع هنا في أسرع وقت ممكن.

حسنًا ، يجب أن يعمل هذا (بقدر ما أستطيع أن أقول):

في Gemfile :

 gem "guard", github: "guard/guard",
                branch: "experimental_fixes", ref: "c6ab8a0"

 gem "listen", require: false, github: "guard/listen",
                branch: "advanced_thread_debugging", ref: "31053de"

  gem "guard-rspec", require: false, github: "guard/guard-rspec",
                     branch: "ctrl_c_workaround", ref: "ee0b21d"

  gem "rb-inotify", require: false, github: "e2/rb-inotify",
                    branch: "e2-fix_ioerror_when_closed", ref: "99d2101"

إنه عدد كبير من التصحيحات - لا تتردد في المراجعة والتعليق وإرسال العلاقات العامة لمساعدتي في اختبار هذه التصحيحات وإصدارها في أسرع وقت ممكن.

شكرا!

@ e2 هذا السلوك أفضل بكثير ، يمكنك أن ترى حيث قمت بالضغط على ctrl-c ، فإنه يسقط مرة أخرى إلى موجه الأوامر ولكن العملية في منتصف الخروج. إنه يثير استثناءً في النهاية ، ويبدو أنه يخرج من الحطاب ، لكن المواصفات تتوقف عن العمل. شكرا لإلقاء نظرة على هذا. أتمنى أن يساعدك هذا!

^CGuard: INT signal, handling inside trap...                                                                                                             |  ETA: 00:02:03
Guard Pry job: handling interrupt
Guard Pry job: no thread, interrupting Guard

RSpec is shutting down and will print the summary report... Interrupt again to force quit.
Guard::RSpec: Interrupted by user. Waiting for RSpec to die...
➜  source_code git:(development) ✗  3/17 |========== 17 ==========>                                                                                                                         |  ETA: 00:02:28
Pending: (Failures listed here are expected and do not affect your suite's status)

  1) items can export items pdf export
     # Temporarily skipped with xit
     # ./spec/features/items_spec.rb:38


Top 3 slowest examples (25.2 seconds, 83.1% of total time):
  items can click export button and walk through modals
    14.92 seconds ./spec/features/items_spec.rb:26
  items appear in proper time periods
    10.28 seconds ./spec/features/items_spec.rb:51
  items can export pdf export
    0.00005 seconds ./spec/features/items_spec.rb:38

Finished in 30.33 seconds (files took 1.14 seconds to load)
3 examples, 0 failures, 1 pending

Randomized with seed 54136

Coverage report generated for RSpec to /Users/justin/dev/source_code/coverage. 1759 / 3324 LOC (52.92%) covered.

➜  source_code git:(development) ✗
10:18:10 - INFO - Inspecting Ruby code style: spec/features/items_spec.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

10:18:11 - INFO - Bye bye...
/Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close': closed stream (IOError)
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close'
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/logger.rb:140:in `close'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:51:in `execute'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:20:in `execute!'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/bin/_guard-core:11:in `<main>'

jetheredge - شكرًا لاختبار هذا.

لن يكون لدي الوقت للنظر في هذا قريبًا :(

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

بناءً على المثال الخاص بك ، يجب أن يتوقف RSpec ويجب أن يعود Guard إلى موجه Pry.

أعتقد أن المشكلة هنا هي أن Guard يحبس إشارة INT. لا ينبغي. يجب استخدامه فقط لقتل Pry ، لكن لا ينبغي أن يفعل أي شيء إذا لم يعمل Pry (ولا توجد وظائف).

سأقبل العلاقات العامة لهذا إذا أراد شخص ما الاختبار. (في الأساس ، لا ينبغي أن تحدث "مهمة Guard Pry: لا يوجد مؤشر ترابط ، مقاطعة Guard" - يجب فقط تجاهل المقاطعة في PryWrapper).

@ e2 شكرا! سألقي نظرة على إنشاء علاقات عامة الأسبوع المقبل.

jetheredge - أعتقد أنه يكفي استبدال هذا الخط:

https://github.com/guard/guard/blob/c6ab8a0/lib/guard/jobs/pry_wrapper.rb#L108

مع مجرد "عودة".

أيضًا ، يجب ألا يخرج Ctrl-C من الحارس على أي حال.

@ e2 - شكرًا على الإرشادات ، كان هذا الأسبوع مشغولًا بشكل غير متوقع ، وسأقوم بإنشاء علاقات عامة قريبًا.

نحن جميعا ، صدقني ؛)

(إذا كنت لا تصدقني ، فراجع قائمة المشكلات في Guard -
كلها تقريبًا ميزات).

في الخميس ، 11 آب (أغسطس) 2016 الساعة 04:10:08 صباحًا -0700 صباحًا ، كتب جاستن إيثردج:

@ e2 - شكرًا على الإرشادات ، كان هذا الأسبوع مشغولًا بشكل غير متوقع ، وسأقوم بإنشاء علاقات عامة قريبًا.

أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/guard/guard/issues/842#issuecomment -239132345

أعتذر ، ما زلت لم أنس هذا الأمر ، لقد دفنت مؤخرًا في قائمتي. ما زلت أخطط للقيام بذلك ، الأمر يستغرق وقتًا أطول من المتوقع.

أنا أيضا مدفونة. آمل أن أكمل التصحيحات وأطلقها.

لست متأكدًا مما إذا كانت مرتبطة ، ولكن عندما أضغط على CTRL-C أثناء RSpec ، أعود إلى النقب ، لكن الحارس لن يقوم بأي شيء مرة أخرى. لم أحاول تصحيحه كثيرًا. السلوك هو نفسه مع exec الحزمة وبدونها. لقد حاولت الجري مع الفروع التي حددتها أعلاه وقد أحدثت فرقًا حيث سيخرج حارسي بعد إيقاف RSpec.

اي فكرة؟ هل هو متعلق بهذا؟ يسعدني أن أتعمق في التفاصيل الداخلية إذا لم يكن لديك فكرة فورية عن هذا. لدينا الكثير من المواصفات البطيئة والقدرة على إيقاف المواصفات في منتصف الطريق ستوفر الكثير من الوقت. :)

أواجه هذه المشكلة أيضًا على MacOs Sierra.

عندما ألغي اختبارًا ، فإن التغييرات التالية في الملف لا تُشغل الاختبارات. توقف عن المشاهدة.

لدي نفس المشكلة. أي تحديثات على هذا؟

نفس المشكلة هنا. باستخدام macOS Catalina.