Comments (37)
Using the latest version 2.0.0
of pry-byebug
from Github this is what happens when I try to connect with pry-remote
:
12:52:50 web.1 | [pry-remote] Waiting for client on druby://127.0.0.1:9876
12:52:56 web.1 | [pry-remote] Client received, starting remote session
12:52:56 web.1 | [pry-remote] Remote session terminated
12:52:56 web.1 | [pry-remote] Ensure stop service
12:52:56 web.1 |
12:52:56 web.1 | Frame number: 0/140
12:52:56 web.1 |
12:52:56 web.1 | From: /home/vagrant/.gem/ruby/2.1.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 321 Object#remote_pry:
12:52:56 web.1 |
12:52:56 web.1 | 319: def remote_pry(host = PryRemote::DefaultHost, port = PryRemote::DefaultPort, options = {})
12:52:56 web.1 | 320: PryRemote::Server.new(self, host, port, options).run
12:52:56 web.1 | => 321: end
from pry-byebug.
This issue is four years old and the problem described by @brauliomartinezlm, @jeffutter and others is still present.
from pry-byebug.
I just ran into this issue with pry-byebug 8.2.4 and pry-remote 0.1.8.
from pry-byebug.
Thanks for all your investigations! I'll try to find some time to look at this! 👍
from pry-byebug.
Anybody have traction on this issue? I'm using pry-remote standalone, but would really like to navigate!
from pry-byebug.
pry-byebug version 1.3.3 works great with pry-remote, so I'm pinned there for now.
from pry-byebug.
Workaround
Use Byebug.start_server
and byebug -R
.
You don't need pry-remote
, pry
, pry-nav
, or pry-remote
. You don't need any pry-stuff. All you need is byebug
.
It's not well documented, but it works. See Nicholas Gronow's instructions on SO: https://stackoverflow.com/a/25823241/567762
from pry-byebug.
Same. So far the only solution is use pry-nav
instead of pry-byebug
from pry-byebug.
@atd I applied your suggestions and pushed to my fork (https://github.com/sloneorzeszki/pry-byebug/commit/33d4ba2536a68221ac8c08797b06af5bec5fcaab). Unfortunately I wasn't able to fix the wrong terminal problem even though I spent a few hours on it. Hopefully someone else will be able to go on with that. Thanks again for help.
from pry-byebug.
I experience the same issue, if pry-remote even works at all. Sometimes I get the behaviour described in this ticket: Mon-Ouie/pry-remote#58
In that case pry-remote does not work at all, showing the context of the PryRemote::Server#run method in the rails server log rather than dropping in the pry-remote command.
from pry-byebug.
@chrisarcand Thanks for investigating. Unfortunately I can't seem to find time & will to have a look at this... 😞 Sorry.
The commit you point to is also the cause of other issues users of this gem usually find, specially pry users. I suggest you have a look at #75. Maybe if you rebase that and get it working against latest master, issues will be fixed, since that PR basically makes the behavior introduced by the offending commit optional.
from pry-byebug.
Part of the problem stems from pry-byebug alias-method-chaining Pry.start
, eating the passed arguments, but not conveying those arguments to the original Pry.start
call.
The alias-method-chain (lib/pry-byebug/pry_ext.rb:10
):
def start_with_pry_byebug(target = TOPLEVEL_BINDING, options = {})
Byebug::PryProcessor.start unless ENV['DISABLE_PRY']
# ^ options not conveyed here
The call to the original Pry.start
lib/byebug/processors/pry_processor.rb:117
:
def resume_pry
run do
@pry = Pry.start_without_pry_byebug(new_binding)
# ^ options not conveyed here
@JoshCheek posted a hacky fix in #45 (here) as a proof of concept. But I think the idiomatic thing would be to write a companion class to PryProcessor
named PryInterface
, similar to byebug's other *Processor/*Interface
class pairs. It tracks invocation information.
diff --git a/lib/byebug/interfaces/pry_interface.rb b/lib/byebug/interfaces/pry_interface.rb
new file mode 100644
index 0000000..74e410d
--- /dev/null
+++ b/lib/byebug/interfaces/pry_interface.rb
@@ -0,0 +1,14 @@
+# frozen_string_literal: true
+
+require "byebug/core"
+
+module Byebug
+ class PryInterface < LocalInterface
+ attr_accessor :options
+
+ def initialize(options)
+ super()
+ @options = options
+ end
+ end
+end
diff --git a/lib/byebug/processors/pry_processor.rb b/lib/byebug/processors/pry_processor.rb
index 5f29cfd..eb75bfd 100644
--- a/lib/byebug/processors/pry_processor.rb
+++ b/lib/byebug/processors/pry_processor.rb
@@ -1,6 +1,7 @@
# frozen_string_literal: true
require "byebug/core"
+require "byebug/interfaces/pry_interface"
module Byebug
#
@@ -13,10 +14,11 @@ module Byebug
def_delegators :@pry, :output
def_delegators Pry::Helpers::Text, :bold
- def self.start
+ def self.start(options = {})
Byebug.start
Setting[:autolist] = false
Context.processor = self
+ Context.interface = PryInterface.new(options)
Byebug.current_context.step_out(4, true)
end
@@ -114,7 +116,7 @@ module Byebug
if defined?(@pry) && @pry
@pry.repl(new_binding)
else
- @pry = Pry.start_without_pry_byebug(new_binding)
+ @pry = Pry.start_without_pry_byebug(new_binding, interface.options)
end
end
end
diff --git a/lib/pry-byebug/pry_ext.rb b/lib/pry-byebug/pry_ext.rb
index 03c3400..1882e88 100644
--- a/lib/pry-byebug/pry_ext.rb
+++ b/lib/pry-byebug/pry_ext.rb
@@ -7,7 +7,7 @@ class << Pry
def start_with_pry_byebug(target = TOPLEVEL_BINDING, options = {})
if target.is_a?(Binding) && PryByebug.file_context?(target)
- Byebug::PryProcessor.start unless ENV["DISABLE_PRY"]
+ Byebug::PryProcessor.start(options) unless ENV["DISABLE_PRY"]
else
# No need for the tracer unless we have a file context to step through
start_without_pry_byebug(target, options)
Having a decoupled class to maintain upstream Pry
state/preferences would be great. For example, if this were in place, PryInterface
could be also used to configure binding behavior preferences (byebug vs. vanilla pry), closing #45.
from pry-byebug.
Hi @brauliomartinezlm !
As I commented here, it's in my TODO list to review compatibility with pry-remote
. I'm not sure whether it will work or not, but feedback like yours seems to indicate that it doesn't. In any case, I'll review this as soon as I can.
Cheers!
from pry-byebug.
@deivid-rodriguez thanks a lot! I try to help if I have some spare time.
from pry-byebug.
Great!!
from pry-byebug.
👍 this is pretty huge for me. I love pry-byebug a lot but I can't use it locally since I have to test with Unicorn.
from pry-byebug.
👍 Same issue for me (using a Vagrant image locally for development)
Is there some way I/we (everyone with this issue) could help with getting this compatibility added?
from pry-byebug.
Clone/fork both repos and start researching. If you need help let me know. 👍
from pry-byebug.
This helped us get running again. Thank you @nessur.
from pry-byebug.
👍
from pry-byebug.
👍 I'm still seeing this issue with pry-byebug. I'd love to see an update that lets them work together.
from pry-byebug.
Any traction on this issue? I am not getting any love from pry-byebug v.1.3.3, v.3.1, v.3.3 with POW and pry-remote v.0.1.8
from pry-byebug.
Nope.
from pry-byebug.
Ok, unless it is really necessary to use pry-remote--e.g. you are doing some pair programming with someone in another city, there is a work around in regard to getting pry-byebug working with POW.
By using the proxy feature of POW, you can create the following in ~/.pow instead of a symlink:
echo 3000 > ~/.pow/
basename $PWD``
...doing above from your app directory.
I am doing this with
zeus server
and it is working great. And now I am back to having functionality of pry from pry-byebug,
or using byebug if I wish. Fantastic!
And the pair programming option with POW and byebug is still available with this configuration that Starr Horne came up with:
# config/initializers/byebug.rb
require 'byebug/core'
if Rails.env.development?
Byebug.start_server 'localhost', ENV.fetch("BYEBUG_SERVER_PORT", 1048).to_i
end
...then:
bundle exec byebug -R localhost:1048
from command line and you're right as rain.
You would just use the normal symlink in ~/.pow in the second example.
Cheers!
jet
from pry-byebug.
@nessur's fix (using version 1.3.3) works for me:
rails (5.0.0.1)
pry-remote (0.1.8)
from pry-byebug.
@deivid-rodriguez have you got any news about compatibility pry-byebug with pry-remote? It's running very well with pry-byebug(version 1.3.3) but I wanna update the gems later.
from pry-byebug.
Any thoughts here? We're seeing the same issue with pry-byebug 1.3.3, byebug 2.7.0 and pry-remote 0.1.8.
For what it's worth here is the exact output we're seeing:
[2] pry(#<Frontend>)> next
From: /usr/local/bundle/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 211 PryRemote::Server#run:
206: def run
207: setup
208:
209: Pry.start(@object, @options.merge(:input => client.input_proxy, :output => client.output))
210: ensure
=> 211: teardown
212: end
It's like it is next
ing in the pry process, not in the application.
Unfortunately pry-remote is the best (only?) solution for using pry in a docker-compose setup with multiple ruby applications in the stack. It would be great if it worked well.
from pry-byebug.
@deivid-rodriguez 👋 I took a look at this and bisected the issue down to 49de00c. That's the first bad commit where pry-remote no longer works. I guess that probably doesn't help a lot because unfortunately lots of changes have happened since then so I'm not really sure where to go from here to help track this issue down.
from pry-byebug.
I have the same problem with pry-byebug 3.6.0 and pry-remote 0.1.8.
One thing I found out is that changing the value in Byebug.current_context.step_out(4, true)
( pry_processor.rb
) from 4
to 5
fixes the issue, but only for binding.remote_pry
. Once I use binding.pry
in the same place it all breaks. It seems that using binding.remote_pry
adds one more layer to step out from. This is the stack I got with binding.pry
:
step_out 1: /home/sloneorzeszki/lab/pry-byebug/lib/byebug/processors/pry_processor.rb @ line 19 Byebug::PryProcessor.start
step_out 2: /home/sloneorzeszki/lab/pry-byebug/lib/pry-byebug/pry_ext.rb @ line 14 Pry.start_with_pry_byebug
step_out 3: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-0.12.2/lib/pry/core_extensions.rb @ line 47 Object#pry:
step_out 4: place where I put binding.pry (target location)
but with binding.remote_pry
it is:
step_out 1: /home/sloneorzeszki/lab/pry-byebug/lib/byebug/processors/pry_processor.rb @ line 19 Byebug::PryProcessor.start
step_out 2: /home/sloneorzeszki/lab/pry-byebug/lib/pry-byebug/pry_ext.rb @ line 14 Pry.start_with_pry_byebug
step_out 3: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 211 PryRemote::Server#run:
step_out 4: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 321 Object#remote_pry
step_out 5: place where I put binding.remote_pry
Note: step_out 4 is the same line reported in the discussion above.
There is one more thing, although it might be just my setup (I guess it may influence the order the gems are loaded). When debugging I wasn't really able to bind into pry_remote_ext.rb
file. No matter what I did within it, I didn't see any change in a way the gem worked. To me it seems like this file isn't loaded at all. I tried to load it via cli.rb
, which generated an error suggesting that the class PryRemote::Server isn't loaded yet (so it can't be overridden). Again, this might be just my setup.
I don't really know enough about pry or byebug to go further with it. This is the first time I'm contributing on GH so I hope I'm not making any blatant mistakes. Thanks for doing this, @deivid-rodriguez
from pry-byebug.
Thank you so much @sloneorzeszki. I find your comment quite insightful and useful. Congrats for your first contribution!
Changing 4
to 5
also works for me. But I cannot find a clear way to submit a fix. How do you calculate the frames you need to step out? It depends on the pry plugins or hacks you have included in your setup 🤔
from pry-byebug.
Thanks, @atd :) If enough people confirm that changing the number to 5 fixes the problem I guess we can assume that's the way to go. It maybe sounds like a bad idea (since we would have to set a different number for every gem having similar problem), but with pry-remote we already have the pry_remote_ext.rb
file where we can place most of the code.
I too have a problem thinking about any good-looking solution but I made a fix that works for me - hopefully someone will be able to make something better of it. It's available on my fork -
https://github.com/sloneorzeszki/pry-byebug/commit/81c258f9cce84acd2329d24383f0f3270fd1203e.
Few remarks:
- I had to replace
attr_accessor :current_remote_server
with setter/getter methods - I don't fully understand consequences of using attr_accessor in modules but the test suite wouldn't even start without that change - I used
prepend
instead ofalias_method
solution - this may possibly cause problems with backward compatibility - I added a require statement for
pry_remote_ext
incli.rb
, as mentioned before - in my environment the file wasn't loaded at all, is this intentional? - number of steps out is set by default to 4 but the number can be passed as a block (not the prettiest solution, I know)
- I didn't add any tests since that would require some more time which I don't have at the moment (never tested anything like this before)
I didn't make a pull request out of it due to above caveats. I will be happy to make it if needed :)
from pry-byebug.
Thank you for sharing your branch @sloneorzeszki
I have tested it, but I still get the input inside the wrong terminal (the one with the rails s
) and outputs does go to the pry-remote
terminal
Regarding your comments, you should be able to enclose the attr_accessor :current_remote_server
inside class << self; end
so you enable PryByebug.current_remote_server
(the other way, the instances of a class that includes PryByebug
would have the attr_accesor
)
About using prepend
, I would say it is ok since byebug
only works with ruby 2
Finally, you can pass the step_out
options within a new options
argument to Byebug::PryProcessor.start
from pry-byebug.
I have tested it, but I still get the input inside the wrong terminal (the one with the rails s) and outputs does go to the pry-remote terminal
It was the first time I used this gem, I honestly didn't realize this was the problem (although I did find it pretty odd 😶), I was focused on the step_out thing only. Thank you for your feedback, will look into it in the coming days :)
from pry-byebug.
I've found a way to make it work and opened an MR here #339.
from pry-byebug.
For anyone who's interested, @meinac's fix has been released as a forked version of this gem: https://rubygems.org/gems/gitlab-pry-byebug/versions/3.9.0
from pry-byebug.
For anyone who's interested, @meinac's fix has been released as a forked version of this gem: https://rubygems.org/gems/gitlab-pry-byebug/versions/3.9.0
Thanks @thiago-gitlab that's awesome. Is this fork receiving updates? I see it's pinned to the 0.13.0 version of Pry, which has moved up to 0.14.0
from pry-byebug.
@kylesnowschwartz, it's not because we were hoping that upstream would be eventually fixed. The MR has been open for a few months without any comments, so that hasn't happened yet.
Our fork is here: https://gitlab.com/gitlab-org/gitlab-pry-byebug/-/tree/release_new_version
If anyone feels like contributing an update, I'm sure @meinac would be happy to review it.
from pry-byebug.
Related Issues (20)
- It's possible to start a REPL session passing a command? HOT 1
- Loading pry-byebug on Archlinux fails with "cannot load such file -- irb" HOT 1
- Newest version of Pry breaks pry-byebug HOT 15
- Pry Byebug specifies an older version of Pry HOT 1
- Deprecation warnings in Ruby 2.7 HOT 2
- Pry "next" alias does not work
- Any plans for a new release? HOT 4
- less: unrecognized option: X HOT 1
- PR proposition : Deprecated - Pry.config.control_d_handler HOT 6
- Repeated newlines in multi-line strings are ignored
- NameError: undefined local variable or method `text' for #<PryByebug::BreakCommand HOT 2
- New release? HOT 2
- Deprecation warnings Pry v 0.14.1 on Ruby v 3.1.1 HOT 1
- Relax restriction for byebug version HOT 5
- The version 3.10.0 breaks rails console HOT 8
- Build failure with ruby-pry-byebug version 3.9.0-1
- Run error using Ruby 3.2 HOT 1
- Deprecation on Ruby 3.2.2
- Compatibility Inquiry: pry-byebug 3.10.1 with Ruby 3.3.0
- Question: Is there a recommended way of requiring the gem for test but not CI?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pry-byebug.