Creating Carbide C++

New Remote Connections View

Wed, 03 Sep 2008 07:44:07 -0600

A new feature for Carbide v2.0 is the remote connections UI framework. The framework allows Carbide users to create remote connection data objects that are stored in the workspace, can be exported and imported, and can be shared among multiple instances of use (for now, on-device launch configurations).
One of the benefits is that once a remote connection object is created and its data is specified, it can be named and reused without having to specify the data again. Another is that if the data changes, all uses of that object pick up the change. Finally, the active status of services over the connection can be seen at any time.

Terminating Multiple Processes

Fri, 29 Aug 2008 19:42:38 -0600

Debugging multiple processes at once in Carbide can be a little tricky but this is an area where we're making some improvements for 2.0. When you are using the emulator then Carbide is really debugging epoc.exe and not the individual Symbian OS processes. So if you terminate debugging one of the processes you'll take down the entire emulator. But when debugging on a real phone then you can terminate each process individually.

You can also right-click on a process in the debug view and "Terminal/Disconnect All". This will take everything down but we've discovered a couple issues with this command that we still need to fix for Carbide 2.0, so for now I recommend terminating each process individually.

Agile Tuning of the Austin Team

Fri, 29 Aug 2008 14:11:06 -0600

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.

Introduction to the workspace screencast

Thu, 28 Aug 2008 14:21:37 -0600

One thing that can confuse some users that are new to Eclipse and Carbide.c++ is the concept of the workspace and how Carbide.c++ makes use of it. Adding to this confusion can be the root directory concept along with some of its limitations, so I figured I would create a screencast for this. So without further delay, take a look at this introduction to these concepts:

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!

Adding DLLs while Debugging

Fri, 22 Aug 2008 15:53:47 -0600

I've been working with Ravi to plug a hole in our debugger use cases for Carbide 2.0: usually if you start a debug session in Carbide it will determine what executables you are interested in and let you set breakpoints there. But what if you decide you want to debug additional DLLs after a debug session has started? You can't do this in Carbide 1.3 without terminating the debug session and starting over again. In Carbide 2.0 you can now import additional DLLs (dragging them into the Executables View is easiest) in the midst of a debug session and then set breakpoints etc. This makes it easier to enlarge the scope of the debug session without having to terminate the while thing, import the new DLLs and then start debugging again.

Executables

Fri, 15 Aug 2008 22:51:47 -0600

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.

Regular Expressions Help

Mon, 11 Aug 2008 13:27:05 -0600

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.

License for v2.0 M1 downloads

Mon, 11 Aug 2008 09:57:32 -0600

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.

View Memory on Variables

Fri, 08 Aug 2008 17:26:54 -0600

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.

Build frenzy for v2.0M1 release

Thu, 07 Aug 2008 12:01:00 -0600

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.

Old School: Legacy SDKs and Carbide

Wed, 06 Aug 2008 11:49:00 -0600

I know there are people out there developing for somewhat elderly devices, and I still get regular questions from users who download Carbide.c++ v1.3 and are unpleasantly surprised when they try to write the ultimate Series 60 2nd Edition application and Carbide refuses to oblige.

To accommodate folks using older kits, we have put Carbide.c++ v1.2 back up for download. It can be found here.

Note that no active development is being done on Carbide v1.2; we simply provide it as a service to people who need it to develop for older kits.

Upgrading the Plumbing

Fri, 01 Aug 2008 11:55:55 -0600

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.

That's a little too large

Fri, 01 Aug 2008 11:51:50 -0600

One of the known problems when debugging programs on a device is simply the amount of time one spends waiting for things to happen. You have to wait for a build to complete, you have to wait for the program to be downloaded to the device, then wait for it to start, then wait for it to hit a breakpoint so you can actually begin debugging. And if the program is large, whew, does it take awhile to download.

Well, we can't solve all of these issues but if you routinely download large SIS/SISX files to devices to debug, we may have a solution for you.

New Screencast: Capability Scanner

Wed, 30 Jul 2008 15:48:05 -0600

For those of you out there working on Platform Security integration within your project, we have a tool to help: the Capability Scanner. This scanner checks the APIs used throughout your code and reports the capabilities that you must include in your MMP file. If you're looking for a simple introduction on how the capability scanner feature can be used, you've come to the right place. Take a few minutes to watch the newest screencast:

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!

More on Moving the Program Counter

Fri, 25 Jul 2008 15:48:24 -0600

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.