S60 Open to new features

My work this week on Carbide 2.0 was focused on cleaning up problems dealing with executable files. Several people had reported cases where their executables remained locked after a debug session. I was able to reproduce at least one of them and put a fix into the next nightly build.

I also cleaned up an assortment of minor issues with the Executables View and added a "Remove" button to let you easily remove executable files you import for debugging. You can only remove the ones you import since the others reflect the files generated by the projects in your workspace.

Eclipse contains a host of features and sometimes finding what you want is pretty obscure and simply searching the help may not be, ahem, helpful. As an example, bug #7457 describes a lack of regular expression help in the Find/Replace dialog. It's actually there but not if you look in the Keys preference panel or search the Eclipse documentation.

Here's what to look for and how it works.

With some customers already taking a look at the Milestone 1 release for v2.0, we are getting some questions about licensing errors. The Carbide.c++ Licenses folder is currently blank when you download the tool and this is what will cause the problem.

For now, the current tool will accept v1.3 licenses. We have also posted a temp license on the main page of the Google Group. Here is a link:

http://groups.google.com/group/carbide_cpp-v2-beta/web/license-PRO-Sept.lic

To install the license:

Open up the IDE,
Click Help -> Carbide Licenses -> Install License
Then paste the contents of the license file.

In Carbide 1.3 we picked up a new feature from CDT that had been missed by CodeWarrior users when moving to Carbide: the ability to right-click on a variable and view memory. This week I revisited an issue that also came up with CodeWarrior: what happens when you "View Memory" on a variable that's stored in a register?

Ordinarily we assume you want to look at the chunk of memory were the variable's value is stored. We find out where it is located and open a memory monitor on that address. This does the what you would want in most cases except when the compiler has used a register to store the variable's value. In Carbide 1.3 you get an obscure error message if you attempt to view memory on a variable in a register. For Carbide 2.0 I could have just cleaned up the error message but recalled that when we had this issue when CodeWarrior we fixed it to use the value in the register as the memory location. This isn't completely consistent with how we treat other variables but at least does something more useful than display an error.

We are closing in on the release of Carbide.c++ v2.0M1 to begin public testing. As those of you in software development know this is an exciting, exhausting, and terrifying time as everyone involved works to make sure that the first public revealing of a new product release goes smoothly.

We have several exciting improvements for you to delve into, not the least of which is our update of Carbide to use the latest Eclipse 3.4 and CDT 5.0 Ganymede releases for Carbide.c++ 2.0. Lots of basic platform and C/C++ improvements should make for an exciting release.

While working at home this week I got to watch a work crew digging up our street so they could put in a new sewer line. It reminded me that while most of the work going on for Carbide 2.0 will result in visible new features we are also upgrading some of the existing ones. I just finished reworking how the Executables view gets the list of source files it displays for an executable. To get the list we have to read and parse the symbol information for the executable. We had been using the light weight symbol readers built into CDT for this but saw problems in Carbide 1.3.1 with really large symbol files. So now we ask our debugger engine back-end to get the list of source files. This works faster, is more reliable, and resolves the issues we saw in 1.3.1. The only trade-off has been a brief delay when we start up the debugger engine if it isn't running already, but I think this will be OK given the other improvements we get.

Here's a followup to my previous post about moving the PC while debugging: This week I've been working on integrating a new CDT contribution that will add a "Move To Line" command to compliment the existing "Run to Line" and "Resume at Line." "Move To Line" will let you move the PC to a new location without resuming execution. Look for it in a Carbide 2.0 nightly build next week.

One of the things we have heard about the last couple Carbide releases is how much better the code navigation features have become. Most of those rely on the C++ code indexer built into CDT so the better the indexer gets the better all the code navigation features perform.

While our team tests these features and has fixed a few bugs most of the recent improvement is due to work by other committers on the CDT project. Markus Schorn at Wind River has lead the great improvement in the CDT indexer over the past couple releases and Andrew Ferguson at Symbian has addressed a lot of issues that effect Carbide.c++ users in particular.

The CDT C++ indexer code isn’t easy to just pick up and play around with so there aren’t a lot of people with the skills and experience to work on improvements. So we’re very happy Andrew’s work on CDT has continued: he’s fixed over a dozen bugs in CDT 5.0.x that we’ll be using in the upcoming Carbide 2.0 release. You can see the details by searching the Eclipse bugzilla. Thanks Andrew.

This week I looked at a couple issues with contextual launching: that's what happens when you hit the Debug button and Carbide determines what to launch in the debugger. Carbide 2.0 is based on the new Eclipse 3.4 release and this includes some new APIs for contextual launching. I added support for those and now when you hover over the Debug button it will show you the exact name of the launch configuration you’ll get, not just the project name. I then looked at bug 3904 which asked that the selection in the Symbian Project Navigator View be used to determine which executable would be used by default. So now if you hit "Debug" while an mmp is selected in the SPN view it will launch the executable built by that mmp by default.