Guard: Ctrl-C bloque la garde

Je vis également cela sur 2.2.5.

Je rencontre également cela (en fait la même trace de pile), mais en utilisant Ruby v2.3.0 , Guard v2.13.0 .

Si je lance Guard via bundle exec guard , puis appuyez sur Ctrl-C à l'invite, je vois le problème. Cependant, si j'exécute guard pas via bundle, appuyer sur Ctrl-C ne cause pas le problème.

Versions complètes Ruby et 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

Après l'erreur de l'invite Pry, j'obtiens une corruption du terminal similaire à ce qui est décrit ici :
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

Si j'installe manuellement le gem rb-readline , cela résout le problème de corruption qui se produit par la suite, mais Ctrl-C génère le même stacktrace. Une fois ce joyau installé, guard signale ma version Readline comme suit :

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

Obtenir exactement le même problème ici... comme le suggère @WilHall , un bundler externe convient parfaitement.

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

Ma version Readline est 6.3 fois à l'intérieur de la garde et à l'extérieur.

Cela ressemble à une combinaison de plusieurs choses.

Je vais probablement créer une branche "quickfix" et plus tard trouver comment l'intégrer.

Ok, je crée une branche avec quelques hacks : https://github.com/guard/guard/tree/experimental_fixes

Voici comment utiliser in dans un Gemfile :

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

Ensuite, mise à jour du bundle et bundle exec guard comme d'habitude.

Vous pouvez également essayer de désactiver les notifications pour voir si cela vous aide également :

bundle exec guard -n f

Veuillez signaler les problèmes ainsi que les correctifs.

Certains problèmes que cela devrait résoudre :

1. Pry devrait cesser de planter en quittant la garde avec ctrl-C
2. La sortie après les dernières lignes ne doit pas masquer l'invite du shell en dessous
3. Les notificateurs TMux et TerminalTitle semblent causer des problèmes de sortie
4. Je n'ai pas vérifié, mais il est possible que la journalisation de LumberJack utilise le temps de vidage alors qu'elle ne devrait pas.
5. Le flux STDERR n'est plus fermé
6. Pry n'est plus tué et rejoint - il est réveillé à la place (il ne devrait donc pas "se bloquer" compte tenu des autres réglages)

Quelques régressions/problèmes :

1. Si un garde/une tâche bousille la sortie colorée, cela ne sera pas corrigé (la réinitialisation de la console a été désactivée).
2. Aucun test pour cela (j'essaie de voir si je peux d'abord résoudre les problèmes)
3. Non testé sur d'autres rubis que l'IRM 2.3.1

Autres solutions de contournement :

Si vous êtes désespéré, vous pouvez essayer d'utiliser Guard sans Pry et sans notifications :

bundle exec guard -n f -i

Faites-moi savoir si cela aide ou a d'autres problèmes, afin que je puisse travailler à la réparation et à la publication officielles.

N'hésitez pas à soumettre des PR qui utilisent sélectivement l'un de ces correctifs (bien que des tests soient bien).

J'ai poussé quelques ajustements.

Vous pouvez extraire ces modifications (ou bundle update si vous utilisez la ligne Gemfile ci-dessus), puis ajouter ceci à votre Guardfile pour voir si cela aide :

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

Il enregistrera également les erreurs dans guard.log . (Bien que cela puisse déclencher l'analyse de l'ensemble du répertoire sur OSX).

Merci @e2 , malheureusement je n'ai pas eu beaucoup de chance :

• Le comportement de plantage sur Ctrl-C reste le même avec la branche "experimental_features" lorsqu'il est exécuté sans drapeaux supplémentaires.
• Fournir -n f ne fait aucune différence.
• L'utilisation du paramètre -i empêche le plantage lors de l'utilisation de Ctrl-C dans les tests (bien qu'il soit difficile de quitter !).

J'obtiens souvent l'une des exceptions suivantes lorsque je quitte avec Ctrl-D, peut-être une condition de concurrence :

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

Et

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

Les lignes Guardfile avec bundle exec guard -n f semblent introduire un retard dans l'erreur. Appuyer sur Ctrl-C pendant une exécution de test provoque toujours le détachement de Pry, le test continuant d'écrire sur STDOUT mélangé avec une invite active. Mais ça se termine de la même façon :

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

Merci @Odaeus d' avoir vérifié cela.

D'abord, j'ai foiré l'interacteur non indiscret. (Je viens de pousser un commit, pour résoudre ce problème).

Deuxièmement, vous avez rencontré ce bogue rb-inotify : https://github.com/nex3/rb-inotify/pull/59

Pour lequel j'ai créé un correctif (pas encore fusionné ou publié).

Jusque-là, vous l'utilisez dans votre Gemfile :

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

Cela résoudra le problème 2.

Pour le problème 3 - c'est probablement un travail en cours, mais assurez-vous d'avoir dans votre Guardfile :

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

Et vous pouvez utiliser tail -f guard.log sur la sortie dans une autre fenêtre.

Je crains que toute la gestion de la session Pry doive être repensée pour résoudre ce problème correctement. Cela prendra probablement tout un samedi pour travailler :(

Si j'ai d'autres correctifs, je le ferai savoir à tout le monde ici dès que possible.

Ok, cela devrait fonctionner (pour autant que je sache):

Dans votre 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"

C'est pas mal de correctifs - n'hésitez pas à revoir, commenter et envoyer des PR pour m'aider à tester et à publier ces correctifs le plus rapidement possible.

Merci!

@e2 Ce comportement est bien meilleur, vous pouvez voir où j'appuie sur ctrl-c, il revient à l'invite de commande mais le processus est en train de quitter. Il soulève une exception à la fin, et il semble sortir du bûcheron, mais les spécifications cessent de fonctionner. Merci d'avoir regardé ça. J'espère que cela t'aides!

^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 - merci d'avoir testé cela.

Je n'aurai pas le temps de me renseigner trop tôt :(

Je suis content que ce soit plus utilisable cependant.

Sur la base de votre exemple, RSpec devrait simplement s'arrêter et Guard devrait revenir à l'invite Pry.

Je pense que le problème ici est que Guard piège le signal INT. Cela ne devrait pas. Il ne devrait être utilisé que pour tuer Pry, mais il ne devrait rien faire si Pry n'est pas en cours d'exécution (et qu'il n'y a pas de travail).

J'accepterais un PR pour cela si quelqu'un veut tester. (Fondamentalement, le "Tâche Guard Pry: pas de thread, interruption de Guard" ne devrait pas se produire - l'interruption devrait simplement être ignorée dans le PryWrapper).

@e2 merci ! Je vais jeter un oeil à la création d'un PR la semaine prochaine.

@jetheredge - Je pense que c'est suffisant pour remplacer cette ligne :

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

avec juste un "retour".

De plus, Ctrl-C ne devrait pas quitter la garde de toute façon.

@e2 - Merci pour les conseils, cette semaine a été étonnamment chargée, je vais bientôt créer un PR.

Nous le sommes tous, croyez-moi ;)

(Si vous ne me croyez pas, consultez la liste des problèmes dans Guard -
presque tous sont des fonctionnalités).

Le jeu. 11 août 2016 à 04:10:08 -0700, Justin Etheredge a écrit :

@e2 - Merci pour les conseils, cette semaine a été étonnamment chargée, je vais bientôt créer un PR.

Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/guard/guard/issues/842#issuecomment -239132345

Je m'excuse, je n'ai toujours pas oublié ça, c'est sur ma liste que je viens de me faire enterrer ces derniers temps. Je prévois toujours de le faire, cela prend juste plus de temps que prévu.

Je suis enterré aussi. J'espère que les correctifs seront terminés et publiés.

Je ne sais pas si c'est lié, mais lorsque je CTRL-C pendant RSpec, je retombe en indiscret, mais la garde ne fera plus jamais rien. Je n'ai pas beaucoup essayé de le déboguer. Le comportement est le même avec et sans bundle exec. J'ai essayé de courir avec les branches que vous avez spécifiées ci-dessus et cela a fait une différence où ma garde sortirait après avoir arrêté RSpec.

Une idée? Est-ce lié à cela ? Je suis heureux de creuser dans les internes si vous n'avez pas une idée immédiate à ce sujet. Nous avons beaucoup de spécifications lentes et pouvoir arrêter une spécification à mi-chemin nous ferait gagner beaucoup de temps. :)

J'ai également ce problème sur MacOs Sierra.

Lorsque j'annule un test, les prochaines modifications apportées au fichier n'exécutent pas les tests. Il arrête de regarder.

J'ai le même problème. Des mises à jour à ce sujet ?

Même problème ici. Utilisation de macOS Catalina.