S60 Open to new features

Last week we took a slight detour in our development cycle to spend time with an Agile consultant Pete Behren of Trailridge Consulting, to help us improve our understanding and implementation of our Agile process. From my viewpoint it was amazingly successful and the chance to get an independent assessment of our progress.

When we started the Agile process a year ago we had only a single day of training and some book reading to get started. These new efforts were first seen during the Carbide 1.3 development cycle which led to more frequent beta releases, improved communication with our customers via the opening of our Bugzilla bug database, nightly builds for faster feedback on bug resolution, and a host of internal process changes that made things more efficient, more reproducible, and more accountable. Even with all the changes behind the scenes Carbide 1.3 was easily the least stressful release we had ever produced.

Needless to say, we were hooked.

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.

So, summer is here and as you may have noticed the number of entries on this blog has dropped a bit in the last few weeks as the team takes some well deserved time off to enjoy the Austin heat with their families. Unlike our corporate headquarters in Finland we don't take the entire summer off, but we do grab a week or two here and there to spend time away from the office recharging ourselves for the next project sprint.

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.

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 had a nifty feature where you could drag the program counter arrow up and down in the editor while in a debug session. This is a very powerful and very dangerous feature that people have been asking for in Carbide.

You can do something similar in Carbide by using the Resume At Line command (in the Run menu or the context menu when you click in the editor). This will move the program counter to that line and resume execution. So this works like the CodeWarrior feature except for the "resume" part. Carbide will automatically resume after moving the PC location instead of giving you the option to step etc.

I'd like to improve this feature in a future version of Carbide but for now the best work around I can think of is to set a breakpoint at the desired new PC location and then do the Resume At Line command on the line before that. Far from ideal but it will give you the option to step without auto resuming.

I have been developing tools for Symbian OS or 6 year now and think that debugging is one area of most interest to Symbian developers. Carbide C++ currently has 3 levels of debugging available:
1 - Emulation
2 - Run mode debugging with Trk
3 - Stop mode debugging with JTAG devices (currently Lauterbach and Sophia hardware emulators)

I heard another comment yesterday about perspective switching in Carbide: when you begin a debug session we automatically switch to the debug perspective but what should we do when the session ends? We've got a bug about this where people have requested we switch back to the Carbide perspective after a debug session. What do you think? Is this something you commonly do now? Would you like Carbide to do it automatically? Should that be the default behavior?

Carbide has a couple default ways of launching a debug session with the emulator: one is to simply launch the emulator (epoc.exe), the other is to launch your executable directly. Doing the second will start the emulator and open your application, saving you the trouble of navigating to it and opening it yourself.

In Carbide 1.3 people asked us to change the default behavior so that it would launch your executable directly. Since then we've found that this only seems to work on some versions of the S60 emulator. Also if you plan to rebuild your app while the emulator is running this won't work because the emulator will exit as soon as your app does.

In Carbide 1.3.1 we'll be looking into better ways to adjust the default behavior and determine when it is OK to offer this launch option. Let us know if you would like to see Carbide offer any other options when launch an emulator debug session.

We use the Eclipse platform and the Eclipse C/C++ Tools project (CDT) as the base platform for Carbide. Both of those projects have their own release schedules that are different that Carbide’s so when we have a major release of Carbide we get to move up to the newest versions of Eclipse and CDT. The next version of the Eclipse platform has just finished a development milestone (3.4M6) and you can see the new stuff here.

We hear two conflicting desires from our customers regarding the Eclipse projects: one is to use the latest release builds without modification and the other is to fix the issues they care about.

So far we have been able to find a balance: we usually don’t modify any of the Eclipse platform but we have released Carbide with a modified version of CDT. This means that we may have to live with issues in the platform longer than we would like but these are usually are not as serious for us as the things we want to fix in CDT. Each time we have found a compelling reason to make some late changes to CDT but we’re doing less of this with each Carbide release so eventually we hope to be able to ship CDT unmodified as well.