|
» 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 (9) » Carbide.c++ 2.0.x (12) » 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 (36) » Tool setup (6) » UI Designer (8) » Usability (18) » Work in Progress (14) » Write-build-debug (4) |
|
» New Remote Connections View » Terminating Multiple Processes » Agile Tuning of the Austin Team » Introduction to the workspace screencast » Adding DLLs while Debugging |
|
Subscribe to RSS feed For email notification, please click here ยป |
« That's a little too large | Main | Old School: Legacy SDKs and Carbide »
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.