Recently a Carbide developer requested some additional help with the Carbide.c++ Plug-in Developer Guide in the form of examples. The specific request, bug #6751, asks for assistance with "how to do builds using [the] Carbide APIs". It seemed a reasonable request and one we are now looking at doing in the near future.

If you are building scalable (SVG) icons for your S60 application, chances are you are using makefiles without dependency tracking. I've noticed quite a few large projects that contain several icon makefiles without proper dependency tracking which can vastly degrage rebuild performance. For example, taking 15 minutes to rebuild instead of 10 seconds for a dependency check. This is typically due to header files that are always generated under \epoc32\include (e.g. MBG files) and causing subsequent CPP files to be unnecessarily re-compiled and the project re-linked.

The feedback that we are getting from users when they try to debug with TRK over Bluetooth is rather unsatisfactory. One requirement is to have a serial port service over the Bluetooth is confusing, since by default it doesn't come with many Bluetooth enabled devices and users have to go to manufacturers sites to get it. The second one is to specify "Port" number on device to connect to. This is not really a port but rather service index on the host PC.

As we begin working on the next version of Carbide we're moving up to a new version of Eclipse and CDT. Lots of new things you'll end up seeing in Carbide come from the Eclipse platform so I wanted to let our people know that they can check out the latest milestone build of Eclipse 3.4 here.

The release notes cover the new stuff added in each milestone. Some of these features are mostly of interest to Java or Eclipse plug-in developers but the platform features will be reflected in Carbide when we move up to Eclipse 3.4.

One of the more ambitious ideas I have for the next release of Carbide is to throw all of the public Carbide docs onto a website using the Eclipse Infocenter. One of the drivers to do this is to make the information available to Google searches. Most people, including myself, have developed the habit of simply doing a Google search for anything we want and simply ignoring our local resources. In many cases I believe that people sometimes actually forget that they have product documentation on their machine. And let's face it, searching the web has become both a habit and the way things are done.

In Carbide 1.3 we now display information when a panic has occurred when doing on-device debugging.

The user will now see the stack crawl display that a panic has occurred. The panic number is shown in the StackCrawl-Thread information at the top. The top frame will be the User::Panic() code. It will have source if Euser has symbolics and disassembly otherwise. The next frame will be the caller of User::Panic() only if symbolics exist for that location. Otherwise it will be in disassembly. The application will exit and the debug session will terminate when the user resumes.

A basic overview of the Carbide C/C++ and Debugger perspectives has been posted:

You can find this and other videos at:
http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos

This is pretty basic stuff; we're trying to put down a solid foundation of the fundamentals first, and then we'll start working on the more exotic stuff. We're always looking for screencast ideas, though, so speak up if you have any ideas.

So I'm sitting in a meeting today discussing how we can improve the UI for Performance Investigator (PI) in future releases. We have a lot of issues to address to improve the usability, clarity, and usefulness of the tool and are working hard to define the changes and when they can be delivered. One of the items to look at struck me by surprise. I didn't know that PI did that and I had actually documented the main feature over a year ago for Carbide 1.2 or so.

Needless to say I was a bit verklempt about the whole issue. Then I realized if I, who worked across the room from the developers didn't know of these features, it was a pretty good bet that the vast Carbide audience hadn't stumbled upon them either.

So, let's talk about them.

We used to get a lot of complaints about Carbide performance with the first releases. Slow to launch, slow to import a project, slow to launch a debug session, slow to launch the emulator, slow to build, to step, etc. We always try to improve the performance of the toolset. Here are some areas that were addressed in releases 1.3 and 1.3.1

CodeWarrior has a great feature in the debugger view to display the program under debugging in 'Source' mode, 'Disassembly' mode and "Mixed" mode. When your breakpoints are not hit or when the stepping in your program seems bogus (stepping causes program counter to jump up or down in the source file under debugging) it is invaluable to switch to debugging in 'Mixed' mode and see if the C++ sources match the ARM disassembly code. Sometimes the code is optimized and program counter will jump up and down then you can verify whether the debugger is doing the right thing by looking into the ARM code to determine the root of the problem.