On Sun, Mar 22, 2009 at 6:28 PM, Igor Trindade Oliveira <[email protected]> wrote: > Hello, > > I am interested in work on Stackless Debugging support, can you give more > information? > What kind of external debugging solutions to support tasklets are you talking > about?
Now, this is how I tentatively see it. I may have the wrong idea about the summer of code workings, or a student may have a better idea for what they'd like to do, or how they'd do it. * Project scope This project also includes profiling support. But this is not that much extra work over and above the debugging support Python has per-thread profiling/debugging hooks, this means that any code which runs in that thread, gets profiled debugged in a standard way. However, Stackless complicates this paradigm. A thread now has tasklets running on it, but Stackless is a modified version of Python. So we need to use their debugging/profiling support, but we need to do it in a way which works for tasklets. The current way it works, is to have code in the tasklet switching logic which takes care of switching in and out per-tasklet values for the Python profiling debugging hooks. This means that all the debugging/profiling code in the standard library which operates based on the per-thread paradigm and is tasklet unaware, now does not work properly. What needs to be done within a summer of code project is to take a look at this code and to see if there is a clean way of modifying it so that it is backwards compatible, but also works naturally with Stackless tasklets, in a beneficial manner (most likely in Python). It has been proposed by one person that this per-tasklet hook switching is not the best approach and that there's a better one. It may be that we need to take a good look at what the best debugging/profiling approaches are, in order to get standard library functionality usable to profile or debug. If this is the case, then the project would also potentially involve altering the Stackless source code (in C). * Widening the scope Now, the debugging/profiling standard library work, given a reasonable level of competence on the part of the student, should not take all of the summer of code work period. I may be wrong, and if so, correct me. But I understand summer of code projects to have an expectation from google of 40 hour weeks, for just under three months. Given knowledge and moderate experience with the C programming language and no knowledge of how the debugging/profiling support in Python works, I would expect a student who learns along the way to take a month or so to do the debugging/profiling support. This would leave extra time, which I assume would need to be gainfully taken up by widening the scope of this project, for this project to be viable for Google to approve. So, a natural extension to this project would be identifying other debuggers, not included in the standard library, which would benefit from having Stackless support added. If I were doing this project, one which comes to mind would be windbg (http://winpdb.org). This has a nice interface, and for it to be extended to make visible running tasklets, the ability to debug them, and so forth, seems like a nice candidate. Research on popular and suitable other or alternative debuggers, given that this would not be enough extra work or that there are better options, would be the job of the student. Anyway, there's some more detail. Let me know if you have any more questions. Cheers, Richard. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
