Guard: Ctrl-C bloqueia o guarda

Também estou experimentando isso no 2.2.5.

Também estou experimentando isso (efetivamente mesmo rastreamento de pilha), mas usando Ruby v2.3.0 , Guard v2.13.0 .

Se eu executar o Guard por meio de bundle exec guard e pressionar Ctrl-C no prompt, vejo o problema. No entanto, se eu executar guard não através do pacote, pressionar Ctrl-C não causará o problema.

Versões completas de Ruby e 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

Depois que os erros do prompt do Pry saem, recebo corrupção do terminal semelhante ao que é descrito aqui:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

Se eu instalar manualmente a gema rb-readline , isso corrigirá o problema de corrupção que ocorre depois, mas Ctrl-C produz o mesmo rastreamento de pilha. Com esta gem instalada, o guarda relata minha versão Readline da seguinte forma:

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

Obtendo exatamente o mesmo problema aqui ... como sugere @WilHall ,

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

Minha versão Readline é 6.3 tanto dentro quanto fora da guarda.

Parece uma combinação de algumas coisas.

Provavelmente, vou criar um branch de "correção rápida" e, mais tarde, descobrir como integrá-lo.

Ok, eu criei um branch com alguns hacks: https://github.com/guard/guard/tree/experimental_fixes

Veja como usar em um Gemfile :

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

Em seguida, agrupe a atualização e bundle exec guard como de costume.

Além disso, você pode tentar desativar as notificações para ver se isso também ajuda:

bundle exec guard -n f

Por favor, relate os problemas, bem como as correções.

Alguns problemas que isso deve corrigir:

1. Pry deve parar de bater ao sair da guarda com ctrl-C
2. A saída após as últimas linhas não deve ocultar o prompt do shell embaixo
3. Ambos os notificadores TMux e TerminalTitle parecem causar problemas com a saída
4. Não verifiquei, mas é possível que o registro do LumberJack esteja usando a liberação de tempo, quando não deveria.
5. O stream STDERR não está mais fechado
6. Pry não está mais morto e unido - ele foi acordado em vez disso (então não deve "travar" devido aos outros ajustes)

Algumas regressões / problemas:

1. Se um guarda / tarefa estragar a saída colorida, ela não será corrigida (a reinicialização do console foi desabilitada).
2. Nenhum teste para isso (estou tentando ver se consigo consertar os problemas primeiro)
3. Não testado em outros Rubis além de MRI 2.3.1

Outras soluções alternativas:

Se você estiver desesperado, pode tentar usar o Guard sem Pry e sem notificações:

bundle exec guard -n f -i

Avise-me se isso ajudar ou tiver outros problemas, para que eu possa trabalhar para corrigir e lançar oficialmente.

Sinta-se à vontade para enviar PRs que usam seletivamente qualquer uma dessas correções (embora os testes sejam bons).

Eu fiz alguns ajustes.

Você pode puxar essas alterações (ou bundle update se você usar a linha Gemfile ) e adicionar isso à sua Guardfile para ver se ajuda:

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

Ele também registrará os erros em guard.log . (Embora isso possa desencadear a varredura de todo o diretório no OSX).

Obrigado @ e2 , infelizmente não tive muita sorte:

• O comportamento de travamento em Ctrl-C permanece o mesmo com o branch "experimental_features" quando executado sem sinalizadores adicionais.
• Fornecer -n f não faz diferença.
• Usar o parâmetro -i evita travamentos ao pressionar Ctrl-C nos testes (embora seja difícil sair!).

Frequentemente recebo uma das seguintes exceções agora ao sair com Ctrl-D, talvez uma condição de corrida:

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

E

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

As Guardfile linhas com bundle exec guard -n f parecem atrasar o erro. Pressionar Ctrl-C durante a execução de um teste ainda faz com que o Pry se desconecte com o teste continuando a gravar em STDOUT misturado com um prompt ativo. Mas acaba da mesma maneira:

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

Obrigado @Odaeus por verificar isso.

Primeiro, eu estraguei o interator não-intrometido. (Acabei de enviar um commit, para corrigir isso).

Em segundo lugar, você encontrou este bug rb-inotify: https://github.com/nex3/rb-inotify/pull/59

Para o qual criei uma correção (não mesclada ou lançada ainda).

Até então, você pode usar isso em seu Gemfile :

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

Isso resolverá o problema 2.

Para o problema 3 - provavelmente é um trabalho em andamento, mas certifique-se de ter em seu Guardfile :

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

E você pode usar tail -f guard.log na saída em outra janela.

Estou preocupado com a necessidade de redesenhar todo o manuseio da sessão do Pry para corrigir isso. Isso provavelmente levará um sábado inteiro para funcionar :(

Se eu tiver mais patches, avisarei a todos aqui o mais rápido possível.

Ok, isso deve funcionar (pelo que eu posso dizer):

Em seu 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"

São vários patches - sinta-se à vontade para revisar, comentar e enviar PRs para me ajudar a testar e liberar esses patches o mais rápido possível.

Obrigado!

@ e2 Este comportamento é muito melhor, você pode ver onde eu pressiono ctrl-c, ele volta para o prompt de comando, mas o processo está no meio da saída. Ele levanta uma exceção no final e parece estar saindo do lenhador, mas as especificações param de funcionar. Obrigado por olhar para isso. Espero que isto ajude!

^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 - obrigado por testar isso.

Não terei tempo para analisar isso tão cedo :(

Ainda bem que é mais utilizável.

Com base no seu exemplo, RSpec deve apenas parar e o Guard deve voltar ao prompt do Pry.

Acho que o problema aqui é que o Guard intercepta o sinal INT. Não deveria. Deve ser usado apenas para matar Pry, mas não deve fazer nada se Pry não estiver em execução (e não houver trabalhos).

Eu aceitaria um PR para isso se alguém quiser fazer o teste. (Basicamente, o "trabalho do Guard Pry: sem thread, interrompendo o Guard" não deveria estar acontecendo - a interrupção deveria ser simplesmente ignorada no PryWrapper).

@ e2 obrigado! Vou dar uma olhada na criação de um PR na próxima semana.

@jetheredge - Acho que é o suficiente para substituir esta linha:

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

com apenas um "retorno".

Além disso, Ctrl-C não deve sair da proteção de qualquer maneira.

@ e2 - Obrigado pela orientação, esta semana foi inesperadamente movimentada, vou criar um PR em breve.

Todos nós somos, acredite em mim;)

(Se você não acredita em mim, verifique a lista de problemas no Guard -
quase todos eles são recursos).

Na quinta-feira, 11 de agosto de 2016 às 04:10:08 -0700, Justin Etheredge escreveu:

@ e2 - Obrigado pela orientação, esta semana foi inesperadamente movimentada, vou criar um PR em breve.

Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/guard/guard/issues/842#issuecomment -239132345

Peço desculpas, ainda não me esqueci disso, está na minha lista que acabei de ser enterrado recentemente. Ainda estou planejando fazer isso, só está demorando mais do que o esperado.

Eu também estou enterrado. Espero que os patches sejam concluídos e lançados.

Não tenho certeza se relacionado, mas quando eu CTRL-C durante RSpec eu caio de volta no pry, mas o guarda nunca vai executar nada novamente. Não tentei depurar muito. O comportamento é o mesmo com e sem bundle exec. Tentei executar com os branches que você especificou acima e fez diferença onde meu guarda sairia após parar o RSpec.

Qualquer ideia? Está relacionado a isso? Fico feliz em pesquisar detalhes internos, se você não tiver uma ideia imediata sobre isso. Temos muitas especificações lentas e ser capaz de interromper uma especificação no meio do caminho economizaria muito tempo. :)

Também estou tendo esse problema no MacOs Sierra.

Quando eu cancelo um teste, as próximas alterações no arquivo não executam os testes. Ele para de assistir.

Estou tendo o mesmo problema. Alguma atualização sobre isso?

Mesmo problema aqui. Usando o macOS Catalina.