I have a question about eclipse debugging. I would like to have, in an output file, all the calls of methods for a debugging session. I would like to track the methods called, all of theme, just like the in debug view but not only for a break point but for all the debug session.
Using breakpoints does not allow to know which methods were called before. Knowing that could help placing break points efficiently.
The Eclipse Java debugger has no tracing capabilities. You need to look at other tools like the Yourkit profiler (which I used often for traces and benchmarking) or JProfiler.
Related
What are the best practices for developing with the Eclipse Pydev interactive console once code migrates inside a function?
I heavily use the interactive console as my projects are typically experimental, open-ended, and not spec-driven. The interactive console works well for code in the main loop, but as soon as I migrate that code to a function, I only know to use breakpoints with the debug view. However, that seems unwieldy, and I don't need the entire stack, nor error-catching mechanisms.
Is there a way to have the vanilla pydev environment interactive console inside a function, for example on the first breakpoint, or raised error?
Without this, I typically have to copy the function back into the main loop. Then, I end up using the same variable names, which leads to occasional global variable name accidents when I copy back to a function.
Thanks in advance.
I am adding a homemade programming language to VS Code, and can't get the interpreter to run my files. The goal is for the extension to run "myinterpreter.exe ${file}" or equivalent, when the user hits Debug (or Run, I have no debugging features implemented, so I am going to just ignore any debug information.) I have very little in the way of ideas on how to do this, but I think it should be mostly possible with just package.json. How would I do this?
I think these docs cover what you need. What happens when the user hits "Run" or "Debug" is defined in client/.vscode/launch.json. "runtimeExecutable" is what you can populate with "myinterpreter.exe ${file}"
While trying to use GWT Super Dev Mode, I followed those guidelines :
GWT-2.5-Super-Dev-Mode
Introducing Super Dev Mode
How does GWT's Super Dev Mode work?
However, I am stuck at the step trying to turn on Super Dev Mode :
Once I fully compiled my project, I run the code server and the dev mode, go at http://127.0.0.1:8888/myapp.html (without the ?gwt.codesvr=127.0.0.1:9997) and then click on the bookmark Dev Mode On. It detects my module, asks me to recompile, a glass screen appears with a message Compiling MyApp ... and then nothing ... No error, no stack trace either in Chrome or Eclipse. Just nothing happens.
Debugging the js code from dev_mode_on.js file, the script is interrupted at line 324 :
...
function getBindingParameters(module_name, get_prop_map) {
var session_key = '__gwtDevModeSession:' + module_name;
--> var prop_map = get_prop_map(); <--
...
Once the function get_prop_map is called, a few more obfuscated functions run and the debugger returns.
I know it is still experimental, but do you have any idea of what I could have done wrong ?
PS: I am using GWT 2.5, GWT-maven-plugin 2.5 and Chrome 23.0.1271.64 m
We have found a similar issue and tracked down the cause, looks like a boundary case not handled in GWT.
More info can be found here: http://code.google.com/p/google-web-toolkit/issues/detail?id=7894
I don't have an answer, but I can give some general debugging tips for this sort of problem.
Super Dev Mode currently (as of 2.5) doesn't report any progress to the web browser while it's compiling. It won't update the dialog until the compile finishes. So it's possible that it's just very slow for your program for some reason, or the compile stopped and somehow didn't report an error like it normally does.
However, there are other ways you can monitor its progress. The compiler log is available as a web page by following links from the code server's front page; you will have to refresh the page to see updates. Or you could look at the log on disk in the code server's work directory. (You can set the work directory with the -workDir argument when you start it.)
Another way is to start the code server from the command line. Any stack traces from the code server will be printed there. You should also be able to look at the output in Eclipse or IntelliJ if you're running it from there.
From this you should be able to tell whether the compiler is slow, but still working (it's still printing output) or has actually stopped with a stack trace.
I followed this tutorial and got Eclipse to recognize the program I'm debugging.
However, after setting a break point, and steering the application to the break point, the application just seems to ignore it.
The code continues merrily as if nothing happened, and I don't get to see the variables I'm trying to look at.
Unfortunately I don't know what info to include here, so if you need more information, just let me know in the comments.
You have to be careful with what you are doing. There are some pitfalls when debugging node applications in eclipse. Here are some tips that might help you.
Start your application with node --debug-brk your-script.js
Start the debugger in eclipse
Step over (F6) the first few require statements, that import the code you want to debug.
Set your breakpoints. (Be sure you don't set breakpoints in the source files you are currently editing. When debugging, there is a "Project" in your workspace that contains all the scripts that are loaded by node. Set your breakpoints in some of these files. Otherwise the breakpoints will be ignored. Most often you want to set breakpoints at the beginning of a callback.)
Then resume (F8) the script and it will pause at the first breakpoint it passes.
Start with that until debugging works for the first time. After that you can try more unconventional cases.
I have a perl script, if i run it normally, it doesn't work right.
But if i run it with the debugger and set a breakpoint at a very specific line, then the script operates correctly.
What side effects can the, breakpoints of the ptkdb module, have?
Loading of any perl debugger has quite significant impact on all environment -- for an idea look into perldebguts. While the debuggers try hardly to minimize its effects, there are additional packages loaded, some special variable has different contents, timing of runtime changes, etc. Without more detail it is hard to say what difference is affecting you.
I would recommend to debug using logger (I found easy mode of Log::Log4perl very handy for this). Also many useful hints on debugging art is in perldebtut.