Jump to: navigation, search

Difference between revisions of "CDT/Better Debugging (GSoC project)"

< CDT
(Schedule of Code and Deliverables)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
This page contains detailed description of "Better Debugging Environment" project for Google Summer of Code.
+
This page contains detailed description of "Better Debugging Environment for CDT" project for Google Summer of Code.
 
+
 
+
TODO: add screenshots.
+
 
+
TODO: re-read.
+
  
 
== Summary ==
 
== Summary ==
Line 10: Line 5:
 
* More powerful "Watch expressions" window, which will have default formatters for STL containers (map, vector, queue, priority_queue, ...) and custom user types.
 
* More powerful "Watch expressions" window, which will have default formatters for STL containers (map, vector, queue, priority_queue, ...) and custom user types.
 
* Support for custom user formatters.
 
* Support for custom user formatters.
* Ability to inspect variables by simply hovering mouse over them in the code editor. This feature will be ported from old CDI-GDB to new DFS-GDF preserving same functionality.
+
* Ability to inspect variables by simply hovering mouse over them in the code editor. This feature will be ported from old CDI-GDB to new DSF-GDB preserving same functionality.
  
 
== Detailed Project Description ==
 
== Detailed Project Description ==
Line 106: Line 101:
 
# Make a screencast for implemented features
 
# Make a screencast for implemented features
  
I am currently unaware which things might take more time than expected :(.
+
Totally all project would take 113-176 hours = 15-22 work days = 3-4.5 work weeks. Considering that those estimates might be extremely over-optimistic, whole project can last for 6-9 work weeks.
 +
 
 +
Even though codding phase officially starts May 23-rd, I hope to deliver "hovered inspection" by 10th of May. I also hope that whole project (completed second part: "default & custom formatters") will be done by July 1-st. Those dates are far ahead of GSoC suggested schedule, but that buffer is left in case something will go terribly wrong. If I will manager to complete whole project before the deadline I will start incorporating other usability enhancements.
 +
 
 +
Unfortunately I am currently unaware which things might take more time than expected :(.

Latest revision as of 14:41, 30 March 2009

This page contains detailed description of "Better Debugging Environment for CDT" project for Google Summer of Code.

Summary

The goal of this project is to create more user-friendly C/C++ debugging environment. By finishing this project there will be:

  • More powerful "Watch expressions" window, which will have default formatters for STL containers (map, vector, queue, priority_queue, ...) and custom user types.
  • Support for custom user formatters.
  • Ability to inspect variables by simply hovering mouse over them in the code editor. This feature will be ported from old CDI-GDB to new DSF-GDB preserving same functionality.

Detailed Project Description

This projects is intended to make debugging with CDT at least as comfortable as with Microsoft Visual Studio.

Custom and Default formatters

One of main parts of this project is to provide users with more readable representation of their data. Formatter is a function that accepts object and returns its human-readable description.

For example, when user watches on a vector<int> variable he/she expects to see its content, not details of internal implementation:

vector<int> v;
for (int i = 0; i < 5; i++)
    v.push_back(i);

should display value of v as {0, 1, 2, 3, 4}.

Successful completion of this project will implement at least following default formatters for standard STL containers:

  • vector, set, multiset and list will display all items formatted in following way: {item1, item2, ... , itemN}.
  • stack will display all items formatted in following way: (item1, item2, ... , itemN], where item1 is stack top and itemN is stack bottom.
  • queue and deque will display all items formatted in following way: (item1, item2, ... , itemN), where item1 is front of the queue and itemN is back of the queue.
  • priority_queue will display all items formatted in following way: (top:item1 other: {item2, ... , itemN}), where item1 is top of the queue and items 2..N are remaining queued items.
  • map, multimap as {key1->value1, key2->value2, ... , keyN->valueN}.
  • bitset 's like (0111 1110 10)

Of course, all formatters will be applied recursively, thus:

vector<int> row1, row2;
row1.push_back(1);
row1.push_back(2);
row2.push_back(3);
row2.push_back(4);
 
vector< vector<int> > matrix;
matrix.push_back(row1);
matrix.push_back(row2);

will display matrix as {{1, 2}, {3, 4}}.

Secondly, all standard C/C++ constructions will also have default formatters:

T* obj;

can displayed as "ptr_to: <value of *obj>", or as "null_ptr" if obj is null.

void* obj;

can be displayed as: ptr_to: <addr>

Displaying array of objects should also be intuitive. If arr is defined as int* it should be able to view it's contents giving watch expression "(int[N]) arr".

struct Point {
  double x, y, z;
};

Will be formatted as "(x=<value of x>, y=<value of y>, z=<value of z>)".

Each structure, array and container will be expandable as a tree with access to all it's fields/items.

As per CDT/planning/6.0 there exists bugzilla entry 237960 which can be done by this project.

Inspecting variables on the fly

When user debugs code he/she must be able to hover mouse over any variable in the code editor and inspect it's value.

This feature was already present in CDI-GDB, but is not present in DSF-GDB and was requested (as per 255026 bug entry). Implementation will similarly as it did previously for CDI-GDB [1].

Schedule of Code and Deliverables

I've tried to build this schedule as Joel suggests. Unfortunately this is very rough estimate

  1. Familiarize with all available development documentation -- 8 hours
  2. Set up developing environment -- 4 hours
  3. Implement inspection by hovering over variable
    1. Study how hovering was implemented in CDI-GDB -- 4-16 hours
    2. Implement feature -- 20-40 hours
    3. Commit patch / Get feedback / Fix mistakes -- 4-8 hours for each cycle
  4. Implement formatter support for viewing expressions
    1. Master GDB command line interface -- 4-12 hours
    2. Become able to manually view contents of vector from the CLI -- 4 hours
    3. Study DSF-GDB -- 4-8 hours
    4. Design how formatters would fit in current structure -- 8 hours
      1. Current proposal: formatters are functions take an object and return it's string description. GDB will be asked to invoke function on that object and result should be displayed to user.
      2. Implement basic vector formatter -- 1 hours
      3. Be able to use that formatter manually from the CLI -- 4 hours
    5. Add additional formatter layer between GDB and text that is being outputed -- 20-40 hours
      • Add a button that allows users to select formatters (+ window to do that) -- 4-12 hours
    6. Test that additional formatter doesn't break anything -- 8 hours
    7. Commit patch / Get feedback / Fix mistakes -- 4-8 hours for each cycle
    8. Write default formatters for all types promised by this project -- 4 hours
    9. Test that formatters look nicely -- 4 hours
    10. Commit patch / Get feedback / Fix mistakes -- 4-8 hours for each cycle
  5. Write user documentation for implemented features
  6. Make a screencast for implemented features

Totally all project would take 113-176 hours = 15-22 work days = 3-4.5 work weeks. Considering that those estimates might be extremely over-optimistic, whole project can last for 6-9 work weeks.

Even though codding phase officially starts May 23-rd, I hope to deliver "hovered inspection" by 10th of May. I also hope that whole project (completed second part: "default & custom formatters") will be done by July 1-st. Those dates are far ahead of GSoC suggested schedule, but that buffer is left in case something will go terribly wrong. If I will manager to complete whole project before the deadline I will start incorporating other usability enhancements.

Unfortunately I am currently unaware which things might take more time than expected :(.