|
» Subscribe » Favorite Links » What is S60? » Freeware & Trials » S60 devices » Hints and tips » About this blog |
» Blognotes (15) » Bugs and Workarounds (4) » Build tools (5) » Carbide.c++ 1.1 (4) » Carbide.c++ 1.2 (8) » Carbide.c++ 1.3.x (10) » Carbide.c++ 2.0.x (13) » Carbide Plug-Ins (4) » CodeWarrior (2) » FAQ (6) » Future directions (25) » General (48) » Off-topic (5) » On-device debugging (13) » Performance Investigator (2) » Product features (18) » Product releases (16) » Screencast (14) » Support (37) » Tool setup (6) » UI Designer (8) » Usability (19) » Work in Progress (14) » Write-build-debug (4) |
|
» New Remote Connections View » Launch configurations and other revisionism's » C++ Refactoring in CDT » Seeking input on Carbide API examples » Simplifying debugging with TRK over the Bluetooth |
|
Subscribe to RSS feed For email notification, please click here » |
A new feature for Carbide v2.0 is the remote connections UI framework. The framework allows Carbide users to create remote connections 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).
Some of the benefits are 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. Also, if the data changes, all uses pick up the change.
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.
Continue reading "Launch configurations and other revisionism's" »You may have noticed the Refactoring menu option in the context menus while using Carbide.c++. Under Carbide 1.3.x all it does is basic renaming of objects and variables. However, there is a project underway (from HSR) that adds a lot of new C++ refactoring functionality to the eclipse C/C++ tool set. You can even give it a test drive by visiting the CDT Refactoring Project website and downloading the update site and installing the plug-ins into Carbide!
Continue reading "C++ Refactoring in CDT" »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.
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.
Continue reading "Simplifying debugging with TRK over the Bluetooth" »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.
Continue reading "Online Carbide documentation push" »The development team here is always looking for ways to make using Carbide.c++ easier and faster, and this has brought another new feature to the tool. With the 1.3.1 release, there will be a way for customers to submit support issues directly from Carbide.
This is one of the features on which I get the least amount of support questions. It is either working great and nobody has any problem using it, or people don't use it often or somebody else in the company handles all the support questions and don't like to share it with the rest of the team:) Honestly, we'd like to get some more feedback on this feature and I'll try to explain here things that we are planning or considering for the next update.
Right now, Performance Investigator generates a trace sampling output file on target device and users have to somehow transfer this file from the target to their PC and then import it into Carbide C++ part of Performance Investigator to see process/thread/function/etc. execution info and graphs.
We would like to make this process more user-friendly where target agent of PI would communicate directly to Carbide side of PI and possibly use the same communication channel that TRK is using for communication with the PC side Carbide debugger. This way user could see run-time profiling info. Ideally this could happen at the same time user has a debugging session going, despite the fact that stopping at a breakpoint will cause an interruption in user program execution.
Some other interesting ideas are related to general profiling:
- Enable PI to detect deadlock/starvation situation in a user program (my favorite)
- Enable PI to detect memory leaks
If you have a great idea to improve PI or simply would like to use it in your development with Carbide, please tell us what you think.
Wikipedia’s Software Testing Controversies [as of publication of this blog entry] summarizes the questions facing testers, developers and managers today. Should testing be Agile or traditional, exploratory or scripted, manual or automated? Our organization has had to answer all the issues, and oh, the difficulty! Continue reading "Automation is a Key Carbide.c++ Development Goal" »