Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work when inside group #157

Open
alkuzad opened this issue Jan 14, 2016 · 6 comments
Open

Does not work when inside group #157

alkuzad opened this issue Jan 14, 2016 · 6 comments

Comments

@alkuzad
Copy link

alkuzad commented Jan 14, 2016

When I run guard-livereload when guard is in default group - it works. When I move it to group "live" it does nothinhg after switching to that group and exception is raised:

[1] Live guard(main)> livereload
13:02:26 - DEBUG - Interactor was stopped or killed
13:02:26 - INFO - Run LiveReload
13:02:26 - DEBUG - Start interactor
13:06:13 - DEBUG - Interactor was stopped or killed
13:06:13 - DEBUG - Hook :run_on_modifications_begin executed for Guard::LiveReload
13:06:13 - ERROR - Guard::LiveReload failed to achieve its <run_on_modifications>, exception was:
> [#] NoMethodError: undefined method `reload_browser' for nil:NilClass
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/bundler/gems/guard-livereload-ac68bc1ae226/lib/guard/livereload.rb:51:in `run_on_modifications'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:82:in `block in _supervise'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:79:in `catch'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:79:in `_supervise'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:61:in `block (3 levels) in run_on_changes'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:56:in `each'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:56:in `block (2 levels) in run_on_changes'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:119:in `block (2 levels) in _run_group_plugins'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:117:in `each'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:117:in `block in _run_group_plugins'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:116:in `catch'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:116:in `_run_group_plugins'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:54:in `block in run_on_changes'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:53:in `each'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/runner.rb:53:in `run_on_changes'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/internals/queue.rb:23:in `process'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/commander.rb:43:in `start'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/cli/environments/valid.rb:16:in `start_guard'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/cli.rb:122:in `start'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/aruba_adapter.rb:32:in `execute'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/lib/guard/aruba_adapter.rb:19:in `execute!'
> [#] /usr/local/rvm/gems/ruby-2.2.3@wft/gems/guard-2.13.0/bin/_guard-core:11:in `<main>'
@e2
Copy link
Contributor

e2 commented Jan 14, 2016

It's a bug in Guard - no one ever reported it yet.

The problem:

It's likely that Guard doesn't stop/restart plugins when switching groups. This is fine for most plugins that don't do anything on startup.

(I'll report and handle this issues, so don't worry about it).

I have 2 questions to be sure:

  1. What's your Guardfile like?
  2. How you are switching between groups?

@e2
Copy link
Contributor

e2 commented Jan 14, 2016

In short, Guard should be fixed to allow switching without problems (here, a new instance of guard-livereload is created, but guard doesn't start it up).

@alkuzad
Copy link
Author

alkuzad commented Jan 14, 2016

@e2 thanks for fast response :)

My Guardfile looks like this:

scope group: :standard

group :standard do  
  guard :rspec, cmd: 'bin/rspec' do
      #rspec watchers here
  end

  guard 'spinach', all_on_start: false, binstubs: true do
    #spinach watchers here
  end
end

group :live do 
  guard :livereload, port:'9999' do 
     #standard livereload watchers here
  end
end

I start the guard via bundle exec guard and then switch group via 'o live'. Then guard-livereload crashes. I've started using env variable to control the startup of livereload, not so fast like groups but works ...

@e2
Copy link
Contributor

e2 commented Jan 15, 2016

Thanks for the Guardfile.

Just a guess for a workaround, but what if you:

  1. started using the live group: guard -g live
  2. you switch to standard with o standard
  3. and when you need to, you can switch to live with o live

Because I think that if you start in live mode, you should then be able to switch back and forth without crashing. This is because if you start with live, the plugin will be properly started.

@alkuzad
Copy link
Author

alkuzad commented Jan 15, 2016

@e2 thanks for that tip, this works in that way every switch to another group will start crashing the livereload but switching back to live group will "repair" the guard. So it works but still some exceptions are raised.

@e2
Copy link
Contributor

e2 commented Jan 15, 2016

Sadly, it's not trivial to fix: guard/guard#812

When you're switching back from :live to :standard, you expect livereload to be stopped, right? (And whenever you switch to :livereload, you expect it to be started, right?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants