Time for an update on the state of Carbide, the Eclipse Debugger for C/C++ (EDC), Symbian, and Nokia. As usual all comments and analysis are my own.
We finally shipped Carbide 3.2 to the public! This is the first publicly available 3.x version of Carbide and the first new version seen outside of Nokia in over a year. It includes support for a new build system, a brand new on-device debugger built on top of EDC, and lots of usability improvements. The delay was a result of one of the many iterations of Nokia's strategy over the past few years: for much of 2010 and until February 11th of 2011 we were telling developers that our mobile platform was the Qt app framework, not Symbian. The Qt folks were busy building their own IDE (Qt Creator) and so it was thought that developers would be confused if they had Carbide available as well. So Carbide was designated a "platform tool" only for use by Nokia's thousands of internal developers.
Then on February 11th our new CEO announced that Nokia would be using Microsoft's Windows Phone 7 software in the future and Symbian would be phased out over the next couple years. So our team has ended up in a strange position: we need to keep Carbide up to a high standard to support Nokia's continuing Symbian efforts but we know the plug will be pulled at some point, probably within the next year. Nokia has built in some flexibility for it's Symbian roadmap and arranged a soft landing by working out a deal to transfer 3000 people to Accenture at the end of this year. Accenture will then contract us back to Nokia to do the remaining Symbian work.
Our team's chief contribution to the Eclipse community over the past 24 months has been the Eclipse Debugger for C/C++ (EDC), part of the CDT project. Faced with the need for a new C/C++ debugger for Carbide and unhappy with any of the available options we designed and built one from the ground up. But the ground was already pretty rich: we leveraged all the work done in CDT's Debug Services Framework (DSF), used the CDT language parser for expression support, and relied on the Target Communications Framework (TCF) for low level debug services.
The first version of EDC shipped with Helios but it was pretty raw as we hadn't yet shipped a Carbide product using it. Indigo EDC is a big improvement in stability, performance, and feature set and we got to fix a number of things we didn't get right on the first attempt. The two reference debuggers provided with EDC (Windows & Linux) still aren't near production quality but are great for introduction and testing and provide a good example of how to build a debugger around EDC.
As we developed EDC we found other tools people interested in the idea and it reflects valuable contributions from the CDT community. As Carbide winds down I hope it continues to offer some value to anyone moving beyond their legacy debugger. I'd like to continue improving it and the rest of CDT but that awaits a volatile future.
Monday, May 16, 2011
Thursday, March 17, 2011
Copying Memory
I've been starting to clear some usability issues out of our backlog and ran into one that seemed simple enough but eventually required a little more thought and attention.
When debugging native code it's common to want to inspect memory so the Eclipse debug platform offers a standard Memory view. The view can host a number of memory renderings, each offering a different way of viewing a chunk of memory.
The "traditional" memory rendering is popular with C/C++ developers because it works much like the memory views in other debuggers and shows a range of memory in both binary and text formats.
Our developer (I'll call him Tom because that's his real name) wanted to do something that seemed pretty simple: select a hex value, copy it to the clipboard, and then paste it into a variable in the Variables view. But the global "Copy" command wasn't hooked up to the memory rendering so it did nothing. Tom then discovered "Copy to Clipboard" in the context menu.
But the "Copy to Clipboard" command copied all of the selected data from the rendering: addresses, binary, and text to the clipboard so it looked like this:
0x7FFF5FBFED20 74736574 00676E69 996E019D 3CBE8497 5FBFED40 testing...n...¾<@í¿_
Tom had to paste this into a text editor, then select just the binary/hex part, and finally had something to paste to set the value of his variable. This sort of thing delights some people because they find a work-around and then have another story to inflict on their colleagues, but Tom had real work to do, expected better, and logged a bug. Our team worked on other stuff that seemed more important until last week when I went back to take another look.
First I looked to see if the rendering's support for "Copy" could just do the right thing by grabbing the address, the binary data, or the text based on which part had been clicked in last. While that would work in the narrow case it wouldn't leave any indication of what it might do if you have forgotten which area you clicked in last, and the ability to copy all three (addresses, binary, text) would have been lost.
There needed to be a more explicit way to say which portion of the data you wanted to copy. So I changed the context menu to provide all four options.
This would make life better for Tom but still wouldn't fix the "select the hex data and hit control/command - c" scenario. So it also keeps track of one choice as the default option that is used when fired by the global "Copy" command, which is now hooked up to the rendering. Tom will have to select "Binary" once and then Copy will work the way he expected.
When debugging native code it's common to want to inspect memory so the Eclipse debug platform offers a standard Memory view. The view can host a number of memory renderings, each offering a different way of viewing a chunk of memory.
The "traditional" memory rendering is popular with C/C++ developers because it works much like the memory views in other debuggers and shows a range of memory in both binary and text formats.
 |
| "Traditional" memory rendering from CDT |
 |
| Memory View in Xcode 4 |
 |
| Memory view from Visual Studio 2008 |
 |
| Memory window from CodeWarrior in 2001 |
Our developer (I'll call him Tom because that's his real name) wanted to do something that seemed pretty simple: select a hex value, copy it to the clipboard, and then paste it into a variable in the Variables view. But the global "Copy" command wasn't hooked up to the memory rendering so it did nothing. Tom then discovered "Copy to Clipboard" in the context menu.
0x7FFF5FBFED20 74736574 00676E69 996E019D 3CBE8497 5FBFED40 testing...n...¾<@í¿_
Tom had to paste this into a text editor, then select just the binary/hex part, and finally had something to paste to set the value of his variable. This sort of thing delights some people because they find a work-around and then have another story to inflict on their colleagues, but Tom had real work to do, expected better, and logged a bug. Our team worked on other stuff that seemed more important until last week when I went back to take another look.
First I looked to see if the rendering's support for "Copy" could just do the right thing by grabbing the address, the binary data, or the text based on which part had been clicked in last. While that would work in the narrow case it wouldn't leave any indication of what it might do if you have forgotten which area you clicked in last, and the ability to copy all three (addresses, binary, text) would have been lost.
There needed to be a more explicit way to say which portion of the data you wanted to copy. So I changed the context menu to provide all four options.
This would make life better for Tom but still wouldn't fix the "select the hex data and hit control/command - c" scenario. So it also keeps track of one choice as the default option that is used when fired by the global "Copy" command, which is now hooked up to the rendering. Tom will have to select "Binary" once and then Copy will work the way he expected.
Subscribe to:
Posts (Atom)
