- Adding object and array view, hover watches
- Support for evaluating properties from the debugger and modify the value of expressions
- Improving the debugger robustness
- LLDB Backend
-
Adding object and array view, hover watches
Overview: The integrated debugger would benefit from easier ways to evaluate the values of expresions. One such way would be to support popups on hovering the mouse over an identifier in the code editor.
Another important improvement would be to include expand/collapse controls for an expression of a class/struct type being watched (both in the watch windows, and in these new popups). Upon expanding, the values of members would be evaluated and display, and would have further expand/collapse buttons if they are also of a class/struct type.
Additionnally, inspecting arrays or pointers should feature similar expand/collapse controls for an array view where the elements of the array could be expanded. Some consideration should be given for pointer not having a fixed size, or very large arrays so as to avoid jamming the IDE for too long.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with GDB
- Familiarity with IDE debugging environments
Being able to expand objects and arrays being evaluated in the integrated debugger
Difficulty: Easy
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Support for evaluating properties from the debugger and modify the value of expressions
Overview: We would like to see support for evaluating properties from the integrated debugger, as well as the ability to edit the values of modifiable expressions (e.g. variables) from the watches panel.
GDB will let you use print (or call) to invoke a function with parameters and output its result. This could probably be used for most properties evaluation (and possibly also setting properties).
Support for editing regular values would likely be based on existing evaluation code, with support for assigning values. Some translation will have to be done to convert eC constructs to their C equivalents.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with GDB
- A good understanding of pointers and memory
Difficulty: Medium
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Improving the debugger robustness
Overview: As GDB does not know about eC, all requests to GDB are done at the C level. A failure of the Ecere IDE to parse the code can result in broken symbols evaluation, which often occurs especially if preprocessor directives are involved (as only some of those are processed by the integrated code editor / debugger). Looking at ways to minimize this breakage would be very valuable (one potential solutions is better parser recovery, which the new recursive descent parser mentioned in idea below would facilitate).
This task would consist in identifying situations where the debugger is not capable of evaluating expressions properly, categorizing these according to the various causes (parsing failure or otherwise) and finding ways to resolve these issues. For cases where it really is not possible to proceed with the evaluation, evaluation error messages should be improved.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with parsing
- Familiarity with GDB
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
LLDB Backend
Overview: Since LLVM and Clang has gained a lot of momentum (and we already support using Clang for the final stage of compiling eC source to object files), we would like support for its native debugger, LLDB. LLDB is now the default debugger installed with OS X development tools, while GDB now requires manual installation.
Another good reason to support with LLDB is that it features a library with a BSD-style license, which would be much easier to interface with than GDB which we have interfaced with through pipes in the IDE, using an interpreter mode which we have found to be either lacking, buggy or incomplete. We are hoping for a smoother experience integrating the LLDB debugger.
One thing we see as a drawback however is LLDB library being in C++ rather than C, which would require settings up C bindings to interace with from eC. It would also mean an extra dependency on the C++ standard library for the Ecere IDE.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with C++
- Familiarity with LLVM/LLDB
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com>