Pry-Remote with Pow on Rails 4

[DelawareConsulting]

Problem:

When added binding.remote_pry to my code it breaks the code but when I can't get into the debugger by typing pry-remote. This used to work when running Rails 3 and Ruby 1.9.3.

Side note: When running Rails s instead of Pow and binding.pry instead binding.remote_pry , it falls into the debugger.

What I'm running: Pow 0.5.0 ruby 2.1.5p273 Rails 4.2.0 OSX 10.9.5

Gemfile gem 'pry' gem 'pry-remote' gem 'pry-stack_explorer' gem 'pry-rails' gem 'byebug' gem 'pry-byebug'

Gemfile.lock pry (0.10.1) coderay (~> 1.1.0) method_source (~> 0.8.1) slop (~> 3.4) pry-byebug (3.0.1) byebug (~> 3.4) pry (~> 0.10) pry-rails (0.3.3) pry (>= 0.9.10) pry-remote (0.1.8) pry (~> 0.9) slop (~> 3.0) pry-stack_explorer (0.4.9.2) binding_of_caller (>= 0.7) pry (>= 0.9.11)

[indirect]

I'm seeing this same problem with Rails 4.2 on Ruby 2.2.0.

[DelawareConsulting]

@indirect please show your Full Gemfile and Gemfile.lock

[indirect]

@YOUConsulting https://gist.github.com/indirect/6ef6ac8aa640d7f56b69

# server side
$ bin/rails s
=> Booting Puma
=> Rails 4.2.0 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Puma 2.11.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:3000

Started GET "/join" for ::1 at 2015-02-23 13:58:25 -0800
  ActiveRecord::SchemaMigration Load (6.1ms)  SELECT "schema_migrations".* FROM "schema_migrations"
Processing by HomeController#join as */*
[pry-remote] Waiting for client on druby://127.0.0.1:9876
[pry-remote] Client received, starting remote session
[pry-remote] Remote session terminated
[pry-remote] Ensure stop service

From: /Users/andre/src/rubytogether/rubytogether.org/.bundle/ruby/2.2.0/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 321 Object#remote_pry:

    319: def remote_pry(host = PryRemote::DefaultHost, port = PryRemote::DefaultPort, options = {})
    320:   PryRemote::Server.new(self, host, port, options).run
 => 321: end

[1] pry(#<Binding>)> 

# client side
$ bundle exec pry-remote
$

[barrkel-m20]

I'm seeing this too. Calling binding.pry_remote causes the server process to block as expected. Running pry-remote on the command line to attach then causes the message as quoted above by @indirect - looks a bit like normal interactive pry. Unfortunately that terminal is shared across multiple forked processes.

Running rails 3.2.13, pry 0.10.1, pry-byebug 3.0.1, pry-remote 0.1.8, and pry-stack_explorer 0.4.9.1.

[sungwoncho]

I am seeing this issue as well, using Rails 4.2.1, pry-byebug 3.1.0, pry-remote 0.1.8 on OSX Yosemite.

[gerrywastaken]

Reverting back to version 1.3.3 of pry-byebug fixes the issue: https://github.com/deivid-rodriguez/pry-byebug/issues/33

The author of pry-byebug doesn't use the gem any more, so is understandably unmotivated to fix issues: https://github.com/deivid-rodriguez/pry-byebug/issues/45#issuecomment-68314470

[squaresurf]

I also had to revert back to version 1.3.3 and things started working for me. I'm using Rails 4.2 with Foreman.