The title is true in at least two ways:
My LAPT tool is turning out to be more difficult to do than I thought, particularly because of class resolution, i.e. finding the fully-qualified class name for a class.
So I’m going to take another route and let javac do most of the work: I’m creating a temporary copy of the file that contains additional dummy methods. These dummy methods have annotated parameters for each local variable of the original method. As we all know, parameter annotations make it into the class file. So then I compile the temporary file, pull out the parameter annotations, change the name slightly, and that’s it.
Or so I thought: The JVM specs don’t specify the order of the local variables in the
LocalVariableTable, so if I want to let the annotations be indexed by the entries in that table, I need to put them in the same order. I’ve considered just creating an
AnnotatedLocalVariableTable that is a completely new format (my original intention was to reuse the
LocalVariableTable. Another benefit would be that the code can be compiled without the
-g switch for debug information. Debug information is only necessary when compiling the temporary file.
Right now I’d say I’m two thirds done with this project. It has also already taken me three halves as much time ;-)
What prevented me from potentially finishing LAPT tonight was a bug in DrJava that had popped up: [ 1561534 ] Debug Stepping Over not working with keyboard input. When the debugger was active, the program would hang when reading from
System.in. Outside of the debugger, everything was fine; in fact, the framed input box integrated into the Interactions Pane looked very nice.
Corky, my advisor, assigned the bug to me, and that confused the hell out of me. Bug assignments are rare here, in fact I don’t remember if he has ever done that before. That made me assume that fixing this problem was urgent, perhaps because the University of
Waterloo was an important user of DrJava, so working on the issue couldn’t wait until the regular Monday meeting when we would normally look at problem like this as a group
After running into a few dead ends because of files that still existed but weren’t in use anymore, I finally found the place where DrJava hung: It was a completion monitor, waiting for a
set() call. That call never came. The strange thing was — and I didn’t notice at first — that our snazzy input box never appeared on the Interactions Pane. Without that input box, the user can’t hit Enter, and the listener will never call
set(). I think additional eyes and brains at the group meeting could have helped here.
So, after spending about four hours, I realized this was not a debugger error at all. After five hours I had realized that the problem was the way the input box was inserted into the interactions document. Due to the different prompt during debugging, it was inserted in an invalid place, causing it not to show up and give the user a chance to hit enter. And after almost seven hours I’m close to checking my bug fix into the repository. And there was nothing wrong with the debugger.
To insert the component, which is represented by a plain-old string (
"[component]" in this case), our own document class was bypassed and the Swing document accessed directly, probably because creating it was inconvenient at the time to create a proper style string for the input box and let our own document class know about it.
As of revision 4010, the input box will appear and stepping/resuming will work. When the program finishes, sometimes there are two
"> >" symbols appearing now, so I suggest someone with better knowledge of the parts of the program that contained the bug should take another glance at the way the prompts are printed.
I also removed the two files
src/edu/rice/cs/util/swing/PopupConsole.java that are not in use anymore except as red herrings during my initial attempts to locate the bug.
This wasn’t exactly how I had planned to spend my evening (finishing on LAPT) and night (sleeping). I’ll give the latter a shot now, but my insomnia has been so bad lately, my eyes are dry.
PS: I am so f… antastically awesome.
I think at the time I wrote the response to the bug report, I got carried away by my lack of sleep and confusion about why I was being assigned the bug, that I inappropriately let my emotions show. I apologize for my unprofessional attitude.