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

pry-stack_explorer compatibility #4

Open
banister opened this issue Jan 25, 2012 · 9 comments
Open

pry-stack_explorer compatibility #4

banister opened this issue Jan 25, 2012 · 9 comments

Comments

@banister
Copy link
Collaborator

Hi,

as of tonight (25 jan) pry 0.9.8 has been released. I haven't tested thoroughly but it appears pry-nav still seems to work ok.

I have also officially released pry-stack_explorer and, pry-nav appears to work fine with it out of the box on ruby 1.9.2. In fact, they work together in almost exactly the way i would expect, with no changes to either one necessary.

However on Ruby 1.9.3 i encounter a segfault when issue a show-stack command after moving forward one line with next -- i am as yet unsure about the cause of this segfault but i will investigate (and hopefully fix) as soon as i get the chance.

If it's not too much to ask, i wonder if you could also investigate the compatibility between these two plugins, so that we can put a notice for users to indicate any problems.

Thanks in advance!

John

@nixme
Copy link
Owner

nixme commented Jan 26, 2012

Awesome. I'll test it out and see if I can come up with a workaround for the segfault.

@MSch
Copy link

MSch commented Jan 28, 2012

I encountered an error when simply stepping through a method via n. Not sure if it's related. The crash went away when I didn't load pry-stack_explorer.

https://gist.github.com/c15ae6ed49e612ab4e1c

@banister
Copy link
Collaborator Author

@MSch thanks, I noticed something similar too, thanks for the bug report. As a result, for the meantime, i do not think it's safe to use pry-nav at the same time as pry-stack_explorer. Have to choose one or the other currently i think ;)

We'll work on getting them working together soon though.

@nixme
Copy link
Owner

nixme commented Jan 31, 2012

@banister, are there any open issues on binding_of_caller that might be causing the segfaults? set_trace_func is pretty finicky in the ruby interpreter though, but I just don't want to rule out weird interaction between the C extension and the tracer.

@banister
Copy link
Collaborator Author

@nixme None that i know of. The segfault relates to GC (when i looked at it in gdb), and there's been substantial changes in the way GC works in 1.9.3, so i think the issue lies in there. I will look into it soon as i get a chance.

How's the behaviour on 1.9.2 btw?

@banister
Copy link
Collaborator Author

banister commented Feb 1, 2012

@nixme segfault should be fixed in most recent version of binding_of_caller (v0.6.2). I think all that's left for compatibility is to remove the pry-nav internal frames from the navigable call-stack, then we should be good to go!

I'll release an update to stack_explorer that does this soon :) thanks again

@nixme
Copy link
Owner

nixme commented Feb 2, 2012

Great, I'll add stack_explorer to my jazz_hands package (https://github.com/nixme/jazz_hands) once you do.

@banister
Copy link
Collaborator Author

banister commented Feb 4, 2012

@nixme hey i released a version of stack_explorer (0.3.3) that should work seamlessly with pry-nav, give it a spin, and let me know how you get on!

Try with the following example, remember to mix and match step / next with up and down and tell me if you get what you 'expect' behaviour to be:

require 'pry-nav'

def alpha
  x = "hello"
  binding.pry
  beta("good evening")
end

def beta(val)
  puts val
  y = "a secret message"
  gamma
  v = "strange days ahead"
end

def gamma
  message = "end of the line"
  puts message
  puts "bye!"
end

alpha

@banister
Copy link
Collaborator Author

@nixme I don't mean to bug you :) but have you had a go with this yet? I can never find anyone else to try it, so im still unsure if this issue should be closed

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

No branches or pull requests

3 participants