You can set a breakpoint on the closing } of a Scala method, but it's pointless to do so because it won't be hit, apparently.
I would still like to set it there. So I thought, "how about I put in a no-op before that line, and set a breakpoint on that?"
But since evidently Eclipse is not warning me when I try to set a breakpoint that will never be hit (because there is no code there), I therefore can't rely on Eclipse telling me if a no-op has been optimised out (particularly as I'm not even using the same version of Scala to run the code as the Eclipse Scala plugin is using).
So is there a short no-operation statement or expression that I can use here which is guaranteed not to be optimised away by the Scala compiler, in all circumstances - and guaranteed not to be optimised away by a JIT in a way that prevents a breakpoint on it being hit? I guess it has to be an expression rather than a statement in my case, because this method returns a useful value, not Unit.
It's not exactly a no-op, but a logging statement (or trace expression - i.e. a logging statement which additionally returns the value it has just logged) is guaranteed not to be optimised away!
The only trouble with that is, you have to manually step over the debug statement or trace expression each time you hit the breakpoint, if you want to see what it actually outputs. Unless it's just outputting the value of a variable, in which case you can find that variable in the Variables tab in Eclipse.
And stepping over a trace expression, at least in my code, with the Eclipse Scala plugin 2.1 milestone 2, in "old-style debugging mode", is no small matter - because it's completely broken, due to this issue!
Before I realised what was going on, it took me about 20 tries of pounding the F6 and F7 keys before I finally managed to step over it! And that was just for stepping over it once!
And remember, the next line is the } - so the obvious workaround, setting another breakpoint on the next line - won't work!
Theoretically you should just be able to Inspect the value being traced, rather than trying to step over the trace. Unfortunately, that doesn't work for me either - it says class not found.
Related
I'm chasing a problem in Joomla and am debugging with Eclipse for PHP. I need to get a record of the values a specific parameter has in succeeding calls to a function.
I know how to set breakpoints and inspect variables, or how to watch the variable. The problem is that the function is called dozens of times. Too many to manually copy and paste the value of the parameter in question at each breakpoint. It's just too error prone a process.
I wonder if there is any way to automate this. I.e. when Eclipse stops because the breakpoint is reached, inspect a specific variable, copy its current value, and record that in, say, a file. I can then manually continue the execution (F8) or the automated process can do that, this doesn't matter.
Rather than opening up jdb is there a way to get similar functionality within the repl or sbt session?
The features I am seeking:
ability to define breakpoints:
:bp mySource.scala:79 // stop at line 79 mySource.scala
:bp org.mycompany.MyClass:14 // stop at line 14 of myClass (no idea if anyone supports such a thing..)
print out vars
:p myList
evaluate expressions including case statements and bonus points for closures
You can't keep a good idea down -- see the thread A non-runaway-REPL?:
Maybe it could also use a "safe" mode where it forks a JVM. While
we're at it, it's time for a debug command.
I don't know if the command should be called :forked, :borked, or simply :wtf.
I upgraded to rpy2.ipython from rmagic but it seems that every statement now prints to the console. Previously, an explicit print had to be called.
Is there an option to get back the former behaviour ?
This is fixed now in version_2.4.x on bitbucket:
https://bitbucket.org/lgautier/rpy2/commits/e22cdab51c94a504c4ea9808c6fad2772a34ef5e?at=default#Lrpy/ipython/rmagic.pyT216
Basically, I had a conceptual glitch while trying to fix up that logic - R is a Lisp, and withVisible operates on the code it gets in a way that doesn't translate via rpy2's python wrapper (which will operate in pythons function execution semantics, where the innermost is evaluated, return values passed out, etc.).
Whether or not I compile a Racket program seems to make no difference to the runtime performance.
Is it just the loading of the file initially that is improved by compilation? In other words, does running racket src.rkt do a jit compilation on the fly, which is why I see no difference in compiling vs interactive?
Even for tight loops of integer arithmetic, where I thought some difference would occur, the profile times are equivalent whether or not I previously did a raco make.
Am I missing something simple?
PS, I notice that I can run racket against the source file (.rkt) or .zo file. Does racket automatically use the .zo if one is found that corresponds to the .rkt file, or does the .zo file need to be used explicitly? Either way, it makes no difference to the performance numbers I'm seeing.
Yes, you're right.
Racket compiles code in two stages: first, the code is compiled into bytecode form, and then when it runs it gets jitted into machine code. When you compile a file, you're basically creating the bytecode which saves on re-compiling it later. Since that's usually not something that takes a lot of time for small pieces of code, you won't see any noticeable difference in runtimes. For an extreme example, you can delete all *.zo files in the collection tree and start DrRacket -- it will take a lot of time to start since there's a ton of code, but once it does start, it would run almost as usual. (It would also be slow to click "run" since that will reload and recompile some files.) Another concern for bigger pieces of code is that the compilation process can make memory consumption higher, but that's also not an issue with smaller pieces of code.
See also the Performace chapter in the guide for hints on how to improve performance.
Racket will always compile your code, regardless of whether it is run interactively at the REPL or run from the command-line. Here is the section in the guide that explains it. In interactive mode, the compiler turns every expression/definition into bytecode in memory and executes that. Otherwise, the compilers outputs the bytecode to zo files.
Note: Eli replied at the same time I did. See his response for more details.
After swaping compiler to LLVM 3.0 and libc++ to have C++11 suport (unique_ptr is a little jewel :)) I have noticed gdb is not working properly when I try to print an object information. What I have tested is the following:
1) I have a std::vector < std::unique_ptr > member variable. If I set a breakpoint inside the class containing this member var and do a "print _reusableEntities.size()" I get this:
Breakpoint 2, GameObjectMgr::createGameObject (this=0x0) at /Users/hexdump/Dropbox/Games prototypes/Re-World/src/ReWorld/Engine/EntityManagement/GameObjectMgr.mm:92
92 go=std::move(_reusableEntities.back());
The program being debugged stopped while in a function called from GDB.
When the function (GameObjectMgr::createGameObject()) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
But if I have a line of code like:
int size=_reusableEntities.size()
it reads the size ok. It really seems a gdb problem when inspecting the vector size. In the other hand I can see how the vector contains correct values in the Local vars windows.
Another thing that is really weird is why the error shows information related to createGameObject function because It has nothing to do with the gdb command call and I wasn't inside it when trying to print the values.
It is really weird and a pain in the ass when debugging.
2) I have F7 configured to step over functions. This worked until I made this changes, now, it doesn't matter if I push F6 (step into) or F7 (step over) I'm always getting inside unique_ptr code when copying, or getting raw pointer from it :/.
If anyone could guess what is happening I would be really grateful, anyway, I know it is really difficult to guess from just my explanation. If anyone needs more info, please, ask for it.