Using "up" is returning strange results

[jperry]

Hi,

When trying to go up the stack I am getting this:

    16:     # Wrap a Pry REPL to catch navigational commands and act on them.
    17:     def run(initial = true, &block)
    18:       return_value = nil
    19:
    20:       command = catch(:breakout_nav) do  # Throws from PryByebug::Commands
 => 21:         return_value = yield
    22:         {}    # Nothing thrown == no navigational command
    23:       end
    24:
    25:       times = (command[:times] || 1).to_i   # Command argument
    26:       times = 1 if times <= 0

[razum2um]

experiencing the same issue while using pry-byebug with this gem

[CyborgMaster]

I'm getting the same issue here

[banister]

Thanks guys, i hope to visit some of these issues soon, expect something in the next couple of weeks! :)

[banister]

This should be fixed now with latest release, let me know if you're still encountering problems!

[CyborgMaster]

It works for me. Thanks!

[banister]

@CyborgMaster do you find the first frame is repeated? i.e going up brings you the same frame (for the first frame) ? I noticed this, seems like a residual bug i need to fix. But maybe it's just me..

[CyborgMaster]

As I checked it out today I did notice exactly that. I had to run up twice to get to the next frame. I thought it must have been an interaction between the way minitest builds test functions from blocks because my stack looked like this,

   #0  test_0004_forgot password <practice#test_0004_forgot password()>
   #1 [block]   block (2 levels) in <class:WebAccountManagmentTest> <practice#test_0004_forgot password()>
...

and frame 0 and 1 brought me to the same line of source code. So if you are seeing the same behavior inside of minitest, maybe its not pry-stack_explorer's fault. I really have no idea though, just guessing.

[banister]

@CyborgMaster thanks for checking it. I think it's probably an easy fix i'll try to get out tomorrow

[CyborgMaster]

Anytime, this is a great gem. I'm happy to help where I can.