Guard: Ctrl-C bloquea la guardia

También estoy experimentando esto en 2.2.5.

También estoy experimentando esto (efectivamente, el mismo seguimiento de pila), pero usando Ruby v2.3.0 , Guard v2.13.0 .

Si ejecuto Guard a través de bundle exec guard y luego presiono Ctrl-C en el indicador, veo el problema. Sin embargo, si ejecuto guard no a través del paquete, presionar Ctrl-C no causa el problema.

Versiones completas de Ruby y 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

Después de que aparezcan los errores del indicador de palanca, obtengo una corrupción de terminal similar a la que se describe aquí:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

Si instalo manualmente la gema rb-readline , esto soluciona el problema de corrupción que ocurre después, pero Ctrl-C produce el mismo seguimiento de pila. Con esta gema instalada, guard informa mi versión de Readline de la siguiente manera:

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

Obteniendo exactamente el mismo problema aquí ... como sugiere @WilHall , el paquete externo está bien.

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

Mi versión de Readline es 6.3 tanto dentro como fuera de la guardia.

Parece una combinación de algunas cosas.

Probablemente crearé una rama de "corrección rápida" y luego descubriré cómo integrarla.

Ok, creo una rama con algunos trucos: https://github.com/guard/guard/tree/experimental_fixes

Aquí se explica cómo usar en un Gemfile :

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

Luego, agregue la actualización y bundle exec guard como de costumbre.

Además, es posible que desee intentar deshabilitar las notificaciones para ver si eso también ayuda:

bundle exec guard -n f

Informe los problemas y las soluciones.

Algunos problemas que esto debería solucionar:

1. La palanca debe dejar de chocar al salir de guardia con ctrl-C
2. La salida después de las últimas líneas no debería ocultar el indicador de shell debajo
3. Los notificadores TMux y TerminalTitle parecen causar problemas con la salida
4. No lo he comprobado, pero es posible que el registro de LumberJack esté usando el tiempo de descarga cuando no debería.
5. La transmisión STDERR ya no está cerrada
6. Pry ya no se mata ni se une, sino que se activa (por lo que no debería "colgarse" debido a los otros ajustes)

Algunas regresiones / problemas:

1. Si un guardia / tarea estropea la salida de color, no se solucionará (el reinicio de la consola se ha desactivado).
2. No hay pruebas para esto (estoy tratando de ver si puedo solucionar los problemas primero)
3. No probado en otros Rubies distintos a MRI 2.3.1

Otras soluciones:

Si está desesperado, puede intentar usar Guard sin Pry y sin notificaciones:

bundle exec guard -n f -i

Avísame si esto ayuda o tiene otros problemas, para que pueda trabajar para solucionarlo y publicarlo oficialmente.

Siéntase libre de enviar PR que usen selectivamente cualquiera de estas correcciones (aunque las pruebas serían buenas).

Hice algunos ajustes.

Puede extraer esos cambios (o bundle update si usa la línea Gemfile ) agregue esto a su Guardfile para ver si ayuda:

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

También registrará los errores en guard.log . (Aunque eso puede desencadenar el escaneo de todo el directorio en OSX).

Gracias @ e2 , lamentablemente no he tenido mucha suerte:

• El comportamiento de bloqueo en Ctrl-C sigue siendo el mismo con la rama "experimental_features" cuando se ejecuta sin indicadores adicionales.
• Proporcionar -n f no hace ninguna diferencia.
• El uso del parámetro -i evita fallas cuando se hace Ctrl-C en las pruebas (¡aunque es difícil salir!).

A menudo obtengo una de las siguientes excepciones ahora cuando salgo con Ctrl-D, tal vez una condición de carrera:

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'
[...]

Y

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'
[...]

Las líneas Guardfile con bundle exec guard -n f parecen introducir un retraso en el error. Al presionar Ctrl-C durante una ejecución de prueba, Pry se desconecta y la prueba continúa escribiendo en STDOUT combinado con un indicador activo. Pero termina de la misma manera:

[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'

Gracias @Odaeus por comprobar esto.

Primero, arruiné al interactor no palanca. (Acabo de presionar un compromiso para arreglar esto).

En segundo lugar, se encontró con este error de rb-inotify: https://github.com/nex3/rb-inotify/pull/59

Para lo cual creé una solución (aún no fusionada ni lanzada).

Hasta entonces, usa esto en tu Gemfile :

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

Eso resolverá el problema 2.

Para el problema 3, probablemente sea un trabajo en progreso, pero asegúrese de tener en su Guardfile :

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

Y puede usar tail -f guard.log en la salida en otra ventana.

Me preocupa que todo el manejo de la sesión de Pry deba rediseñarse para solucionar este problema correctamente. Probablemente tomará todo un sábado para hacer ejercicio :(

Si tengo más parches, se lo haré saber a todos los que están aquí lo antes posible.

Ok, esto debería funcionar (por lo que puedo decir):

En su 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"

Son bastantes parches: siéntase libre de revisar, comentar y enviar PR para ayudarme a probar y lanzar estos parches lo más rápido posible.

¡Gracias!

@ e2 Este comportamiento es mucho mejor, puede ver donde presiono ctrl-c, vuelve al símbolo del sistema pero el proceso está en medio de salir. Genera una excepción al final, y parece que está saliendo del leñador, pero las especificaciones dejan de funcionar. Gracias por mirar esto. ¡Espero que esto ayude!

^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 - gracias por probar esto.

No tendré tiempo para investigar esto demasiado pronto :(

Sin embargo, me alegro de que sea más útil.

Según su ejemplo, RSpec debería detenerse y Guard debería volver al indicador de palanca.

Creo que el problema aquí es que Guard atrapa la señal INT. No debería. Solo debería usarse para matar a Pry, pero no debería hacer nada si Pry no se está ejecutando (y no hay trabajos).

Aceptaría un PR por esto si alguien quiere hacer la prueba. (Básicamente, el "trabajo Guard Pry: sin hilo, interrumpiendo Guard" no debería estar sucediendo; la interrupción debería ignorarse en el PryWrapper).

@ e2 gracias! Echaré un vistazo a la creación de un PR la semana que viene.

@jetheredge - Creo que es suficiente para reemplazar esta línea:

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

con solo un "retorno".

Además, Ctrl-C no debería salir de guardia de todos modos.

@ e2 - Gracias por la orientación, esta semana ha estado inesperadamente ocupada, crearé un PR pronto.

Todos lo somos, créeme;)

(Si no me cree, consulte la lista de problemas en Guard -
casi todas son características).

El jueves 11 de agosto de 2016 a las 04:10:08 AM -0700, Justin Etheredge escribió:

@ e2 - Gracias por la orientación, esta semana ha estado inesperadamente ocupada, crearé un PR pronto.

Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/guard/guard/issues/842#issuecomment -239132345

Pido disculpas, todavía no me he olvidado de esto, está en mi lista que acabo de ser enterrado últimamente. Todavía estoy planeando hacer esto, solo está demorando más de lo esperado.

Yo también estoy enterrado. Con suerte, completaré y lanzaré los parches.

No estoy seguro de si estoy relacionado, pero cuando hago CTRL-C durante RSpec vuelvo a hacer palanca, pero la guardia nunca volverá a ejecutar nada. No he intentado depurarlo mucho. El comportamiento es el mismo con y sin paquete ejecutivo. Intenté ejecutar con las ramas que especificó anteriormente y marcó una diferencia por dónde saldría mi guardia después de detener RSpec.

¿Alguna idea? ¿Está relacionado con esto? Me complace profundizar en los aspectos internos si no tiene una idea inmediata sobre esto. Tenemos muchas especificaciones lentas y poder detener una especificación a mitad de camino ahorraría mucho tiempo. :)

También tengo este problema en MacOs Sierra.

Cuando cancelo una prueba, los siguientes cambios en el archivo no ejecutan pruebas. Deja de mirar.

Tengo el mismo problema. ¿Alguna actualización sobre esto?

El mismo problema aqui. Usando macOS Catalina.