def login
debugger
LOGIN::authenticate(params)
end
When it hits the line with debugger, I type 'n' and it goes to some other file, and I can't seem to be able to get into the call to LOGIN::authenticate
Is 'n' not the right way to do this?
You'll want to use step or s for shorthand. Here is a great cheat-sheet on ruby-debug as well.
I think you should use step to step into the LOGIN::authenticate method.
n[ext] just step over to the next line.
Try help to have the list of debugger commands, and help command-name to have some help for a given command.
Related
Im trying to make a terminal but im stuck on one thing. In the doer program command do. I want docom to be the output of of the loadstring. input = io.read() its a lua terminal inside my program but nothing displays any output. Here is the code that is relevant:
docom = loadstring(input)
print(docom)
How do i make the output display? Because currently its like this:
welcome to the terminal!
loaded
do
do:
print("hello")
function: 0x809b60
do:
The third and fifth line are user inputs. how do i fix this so it shows the hello string instead of the function name. i want this to be able to manage it as i have everything else in the same lua script. please help.
You probably want print(docom()).
loadstring compile a script into a function. That's what you see function: 0x809b60.
loadstring does not run the function. Hence the call docom().
You may want to add error handling by checking whether docom is nil and by calling docom via pcall.
I am writing a small IDE with Single Steps using the Debugdemo.
Now I need an Event before and after a line is executed.
I would like to disable my Editor while the current Line is executed.
I found the OnLine Event but did not find out in what cases it is fired or how I can use it.
Any hints are welcome.
Greetings Klaus
The OnLine event is meant to alter the interpretation of code.
It is not meant for debugging purposes.
If you want to do that use the BreakPoints in TPSScriptDebugger.
Put a breakpoint on the line and after the line.
Now you will get a signal before and after the line is executed.
I am trying to work on whats wrong with my lithium current setup. I have installed the Xdebug and verified that remote host can establish the connection as requested.
http://myinstance.com/test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\test\filter\Coverage
Please note in fresh installation in local environment , "Coverage" Filter is working as expected.
I added some test code inside the "apply" function in coverage.php but it is not even called !!!! Can some have experience in debugging the above URL ?
I am not able to understand why coverage filter is not called up and executed ...Any hints are highly appreciated !
The filters in the query string are added to the options in lithium\test\Controller::__invoke() and then passed into the test Report object created by the test Dispatcher. The Report object finds the test filter class and then runs the applyFilter() method for that test filter as can be seen in lines 140 to 143 of the current code. So those lines would be another place to debug. Those should wrap the run() method of your tests with this filter code inside the apply() method that uses xdebug_get_code_coverage() and related functions. You said you added test code in the apply method and it isn't called. I'm not sure what the issue is. Are you sure you are pointing to the right server and code location? It is possible to run tests from the command line. Maybe you should try that. See code comments in lithium\console\command\Test or run li3 test --help for info on how to use the command-line test runner.
I can confirm on nginx I also have /test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\x5Ctest\x5Cfilter\x5CCoverage in my access log. The \x5C is expected url encoding of the backslash character.
This is a long standing source of frustration, but maybe there is something I'm missing. If i'm in the middle of debugging, and I want to exit the debugger and return to IRB or Rails Console, "quit" won't work as it will exit IRB. "finish" also seems to have the same effect as continue. Using "delete" to remove breakpoints and then trying "continue" or "finish" doesn't work.
Any ideas?
At least in byebug, you can do this:
eval return
Which has the net effect of evaluating a return statement from the current function. That works sometimes, depending on how the call stack looks.
Now while this doesn't remove the current breakpoint .... if you just want control back, this will do that in most cases, depending on how your code is structured.
It also is useful to do this when creating a debug entry in your code:
byebug unless $continue
So if all else fails in a debugging session, you can always run
$continue = true
c
Now this opens up a whole set of possibilities.
This SO question has a few good suggestions. It deals with specifically with debugging inside of loops. One great solution is to set the break point outside the loop, then from irb set it inside the loop and clear it manually when you want to.
Basically it comes down to putting a little bit of thought into where you set your breakpoints.
Other than that there doesn't appear to be anything else you can do.
In ruby-debug, the next command takes you to the next line of code to be executed, regardless of whether that line is in your own code, or in the rails framework, or in a gem.
Is there some way to force ruby-debug (1.9) to jump to the next line that it encounters in your code without stopping at all the other lines it must execute along the way?
Yes, there is.
You can use break linenum to manually set a breakpoint on an arbitrary line number (for instance the next one), and then type c to continue to the next breakpoint.
The documentation for ruby-debug breakpoints would probably help you a bit as well.