The following screenshot shows the loop variable highlighted because it has changed since the last step.
The variable status is reset on user-pause or breakpoint.
So, I am getting towards some sort of state where I might have to think what to do with this software. I think what I’ll try to do is develop a Mojo Palm Pre application using it. I am expecting Palm are working on there own version. They certainly mentioned that developer tools were a high priority on their blog. When they release their own this will become completely redundant but we’ll wait and see. For the heck of it I am going to keep working on it now and then.
It’s looking good. After a mammoth effort to get my head round the Eclipse debug support and User Interface messaging I think I have a fairly stable version of a debugger now.
This has breakpoint, step and simple local variable support. The feature set is kind of at the mercy of the WebOS debugger really as it is the one driving the back-end.
The screenshot shows the application sitting at a breakpoint. If you look at the variable output you will see from the variables that I have been stepping around inside the for loop.
I think I’ll have a break from trying to debug the Palm Pre Debugger plugin as it is doing my head in trying to track all the threads of execution. I need to roll back to a simpler version so I can make sure that is working properly first before trying to get the variable dump working.
Android 1.6 is out and I have been very neglectful recently with my applications on the app store. Would you believe the most popular application is the first one I wrote ‘Simple Weather’? The others have been trounced well and truly in the download stakes.
The app store is looking for screen shots. I sat down tonight and booted up the Android emulator only to realise I hadn’t a clue what I was doing. So, I think I should spend a few days getting back into the toolset.
Local variables support added.
More complex objects are going to be a bit of a challenge.
I am going to go back through the code at this point and re-factor out some of the more ropey looking parts.
Step support has been added.
You can set breakpoints, break, step over, into and out of your code and resume.
Next is processing the variables.
This is version 1.4.4 of the plugin showing a breakpoint in the preferences view of the newsReader sample application. Note, the stack dump but no local variables yet. Also note the application is called ‘Mojo App #1’ in the debug window. This is so I can keep track of the strings I am using. I will go back through this and fix all that stuff at some point.
So this is quite a major milestone. When I started this I visualised that this was what I wanted to see. A breakpoint in the editor with the stack dump. The only bit that’s missing is the variables, that’s another issue in itself. I always thought I could get this working but I also had my moments when I doubted myself. If it wasn’t so late I would pour myself a McCallan but I think I’ll savour this soberly and look at it again tomorrow.
An hour here an hour there does not make for great progress. I am not an expert in regex so I have resorted to writing unit tests to try and sort out the parsing issues I’ve been getting with the debugger output. Here is a diagram with the state machine for startup, run and pause on breakpoint. This works sort of.
Hopefully this weekend I will get a better run and factoring out some of the problems. The good news is that you can set a breakpoint and when it hits the debugger picks this up, gets the stack trace, gets the local variables (or it would do but this state is empty for the moment) before waiting for you to resume. I haven’t put in the step functionality yet although it should be straightforward (in theory anyway).
I am still waiting for Palm to announce their own Eclipse debugger support any day now so I can stop this programming death march (only joking, I think). I guess I’ll just keep going until I get to the point where I get totally stuck.
Here’s a rough outline of my Mojo debugger Eclipse Plugin. This is a work in progress.
The packages in yellow are where I am hooking into the Palm jars from the SDK. Note the states defined in bottom right. The controller issues commands to the connected emulator and the current state processes the response.
I haven’t filled in all the methods or classes quite yet as the design is in a state of flux.
My next task is to add a kindof blocking queue which the debug target will attach to when the UI requests debug info. This will block (with timeout) for data such as the stack trace and the local variables. The current state will populate a central debug resource, as it is reads back data from the terminal stream, and signal to the queue when data is available. That’s my current idea for the moment anyway.
I have the pause working with displaying the stack frame. It’s a bit fragile. The acid test is can I get the breakpoint support working? No screen shots as I don’t want to build anyones hopes up. Unbelievably this was the easy bit and it’s only taken me a few weeks (sarcasm) to get to.
I assume Palm are working on this as well and since they can alter the debugger as they see fit I suppose this is a bit of a non-runner (at least for now). I should say that this is just a ‘lunchtime’ project and I am only spending about an hour a day on it. We’ll see how it goes. I am confused about the debugger being GDB compatible. If that’s the case then maybe I am wasting my time. It’s fun anyway as a learning process.
My internet connection is back up!
I have started to rewrite the state machine as it was too unwieldy. The states now encapsulate the outgoing request and the response rather than put that burden on the controller. Having re-factored it the whole thing makes better sense now and flows better. Not finished yet though, still a ways to go.
There is an update to the IFrame. RAB and KAM (many thanks) have posted there update here. This will make it’s way into the main source update really soon I promise. It’s remiss of me to update this stuff but life has intervened.
As mentioned in the previous post I had a look at the WebOS SDK and was mightily dissapointed that Palm hadn’t bothered to hook the debugger into the Eclipse plugin. Well I though it might be an interesting project to try and write a debugger front-end.
I started off looking at the ports from the emulator and trying to capture the commands that go between the two using WireShark. No luck, not sure why but it seems that it can’t capture stuff between the virtual network link and the host PC. Fair enough. I then looked into their jar files that compose the Palm plugin and realised that I could call their API to do the same thing. So, I recreated their plugin. This wasn’t easy..
Writing an Eclipse plugin is a bit of a dark art. It’s one of those thing that most programmers don’t have to do. So far I have the following working:
- Launching an application.
- Terminating an application.
- Launching the debugger.
- Talking to the debugger to start and stop the application.
- State machine for processing debugger output.
- Capture break condition to extract method, line and column numbers.
- UI reflecting pause status correctly.
- Eclipse shutdown pulling down any application launched from Eclipse plugin.
Talking to the emulator requires the use of methods from the Palm JARs bundled with the SDK. The API lets me open a TTY terminal connection to the emulator. I am querying if there is an existing debug process and if not it will start one up. At that point we can control the debugger and get output back from it.
The response is processed depending on the current ‘state’. The state is set by the operations from the user (break, run etc) and a state machine transitions around to capture the output and process it accordingly.