| Areas | interpreter back-end, command dispatch, nre, debugging |
| Good if student knows | C (essential) and gdb |
| Priority | high |
| Difficulty | Medium |
| Benefits to the student | Learn Tcl and C internals, language design and implementation, experience with scripting debuggers, eternal recognition |
| Benefits to Tcl | Easier debugging of the Tcl core |
| Mentor | Miguel Sofer |
The Tcl core has become a lot harder to debug since NRE's adoption. The problem is intrinsic to the nature and goals of the NRE: C keeps a who called me stack, NRE does its best to replace it with a who do we call next stack. But
Tcl is a lispy language built onto C - a 100% procedural substrate. The NRE is a mechanism that enables features like coroutines and proper tailcalls.
All's well when all's well, but when things go boom in the night the tools designed for C get lost too. Today the only way to understand what is happening is a tedious manual inspection of the NRE stack, which allows to deduce the execution history if there were no intervening tailcalls. It is hard work that requires a lot of concentration and knowledge of the internals.
The student will have to gain a good understanding of the flow of control in Tcl's internals. Armed with this, s/he will research different possibilities for assisting the developer to debug Tcl's core, including a simpler inspection of core dumps, and implement one of them. One idea might be to devise a tracing mode, enabled with special compile flags, that would maintain a who called me stack (in memory? on file?).
A second step would then be to arrange for the tracing output to be inspected from gdb (MS: I cannot estimate the difficulty of this step, as I have no knowledge of gdb except as unsophisticated user)