S60 Open to new features

I'm back at my desk now trying to stay awake after a coma inducing lunch of Stubb's BBQ following the Austin DemoCamp. A bunch of Nokia people from our office joined Chris Aniszczyk and people from IBM, Freescale, and others to look at a few demos and talk about Ganymede, the just released new version of the Eclipse platform.

We're starting to build Carbide.c++ 2.0 with the new platform and so I got to talk to some Eclipse people outside the mobile community about our experiences and contributions.

The session was also something of a reunion of former Metrowerks people: the team that developed the CodeWarrior tools was bought by Motorola years ago which then spun them out along with Freescale. The CodeWarrior for Symbian team then moved to Nokia and now develops Carbide.c++ at our office here next to the coma inducing BBQ. So a lot of people who created the CodeWarrior tools back then are working with Eclipse now. It was great to have a chance to visit with some old friends and make some new ones. I'm hoping we can continue to get the Eclipse people in Austin together now and again.

In Carbide 1.3.1 we revamped the wording and internal code for the generation of console output. Mainly this was done to unify the option's wording and make it easy identify which console program and error output was sent to. Remember, the Console view has several default pages associated with it.

However, an additional step was overlooked in the Carbide manual, the editing of the epoc.ini file, which must be made for a couple of these options to work. Here's how to correct that.

We have yet another screencast to bring to you. This one is a quick overview of some helpful shortcuts for working within Carbide.c++. Hopefully a few of these tips will make Carbide.c++ even easier to use:

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

Got ideas for screencasts you'd like to see? Leave us some feedback here and we'll get on it!

A new screencast has been posted -- it walks you through debugging a simple project with DLLs and talks a bit about the Executables view. Shouldn't be anything special to many of you, but maybe a few could use the review...

So I've talked about the improvements we made in our build system in earlier articles. These include

1. Allowing the compiler to do the dependency tracking
2. Tracking changes to the mmp (and bld.inf).
3. Allow multiple jobs to be spawned by setting the Make environment variable to "make -j N" to allow the make rules to run concurrently in multiiple jobs and thus the compilation time will be faster.
4. Allow the user to turn on the Eclipse incremental builder to determine if anything has changed in the workspace.

But how much faster? We did some example benchmarking to give us an idea.

In the third part of this series of articles I want to tallk about a problem customers ran into during the beta cycle when using the dependency tracking of the Carbide 1.3 build system and how we tackled that problem. It resulted in the next major improvement in the build system.

.

Some people make heavy use of real-time console debug messages via the RDebug::Print interface, only to discover that their messages have fallen off the end of the console buffer before they could read them. We limited the size of the debug console buffer for a very good reason: letting it grow without bounds until it consumed all available memory caused all kinds of problems. And while we strongly discourage people from removing the buffer size limitations for that reason, it's simple enough to increase the buffer size via Window > Preferences:

So set it to the value of your choice (within reason) and use RDebug with confidence!

I've just spent the last week revising the entire launch configuration section of the Carbide manual to make it easier to understand, remove redundancies, and show its advantages when writing and debugging projects. The whole concept of a launch configuration was a bit strange to me when we first began developing Carbide but its gradually become a critical component to understanding how to link the code you write with one or more ways of running or debugging it to ensure its correctness. Therefore it seemed an obvious choice for a good edit and update. So that's what I've done.

The Carbide team worked closely with the N-gage SDK team on Carbide 1.3 to try to meet the demands of getting a workable development environment for a unique set of developers. But, I admit, we fell a bit short in a couple of key areas that we plan to look at fixing so we'll have a more complete solution. So I'ld like to talk about these shortcomings and some ideas on what we might do in our next release, Carbide 2.0 since some of these improvements will benefit all developers who do on-device debugging with Application TRK.