Re: Proposal for GSoC 2011 - Python based scripting front end for Nemiver

[Dodji Seketeli <dodji seketeli org>]

Hello Seemanta,

Thank you for pulling this together.

Seemanta Dutta <seemanta gmail com> a écrit:

> *Project Idea:*  *Python based scripting front-end for Nemiver - the Gnome
> debugger.*
>
> *Short description:* The aim of this project is to create a scripting
> front-end for Nemiver, based on the python language. Using this front-end,
> the user shall be able to create his or her own python debug scripts to help
> debug programs more efficiently. The idea is to leverage the popularity of
> the Python language to impart the user an ability to create powerful
> debugging scripts that can greatly improve the efficiency of debugging
> sessions.

Interesting!

As some might know, I am not a python fan.  But hey.  This looks like a
fun project :-)

>    - *What components/modules will it touch/change or create?*
>
> The project involves creating a Python console that can be invoked from the
> main user interface of Nemiver. The console will make available certain
> functionalities of the debugger as python objects which can then be simply
> 'import'ed to access their services. For example, to set a breakpoint, the
> user can perform the following steps:
>
> *import execObj # execution Object for manipulating execution.*
> *execObj.setBreakPoint(file, line)  # Sets breakpoint in file 'file' at line
> 'line'.*
> *execObj.setBreakPoint(function)  # Sets breakpoint in the function
> 'function'.*

I guess ultimately this means exposing key Nemiver interfaces like
IDebugger to the [Python] interpreter's environment.

This is very interesting as over time it can lead to interesting
projects.  I am thinking about things like writing a GCC plugin to aid
in emitting introspection information to avoid wrapping Nemiver's
interfaces by hand.  That kind of things.  But maybe we could think
about smarting small first ;-)

> Over time, a frequently used library of python code can be gradually
> developed that will contain often used commands or tricks.

Indeed.  Many people have expressed the need of having a command line
console in Nemiver.  Maybe that command line console could be written in
an interpreted language [like Python] that is exposed to Nemiver's
interfaces, like what you are proposing.

>    - *How do you plan to achieve completion of your project?*
>
> I plan to have weekly/bi-weekly milestones for my projects. Every week, I
> propose to hold a checkpoint meeting on IRC (or through emails on the
> mailing list if meeting in real time is not possible) to check the progress
> of reaching that goal, with the project leads. These checkpoints are to
> assess the progress and status of the project made thus far. My keeping
> short, realizable goals for each milestone, the overall goal can be achieved
> in steps. This approach, I believe will work very well for my project.

Yeah, I'd be inclined to communicating via the mailing-list as you
suggested, and secondarily on IRC, during our timezone overlapping
times.

As for milestones, I agree about the need for small-ish targets :-).
This topic seems quite broad, so that could help.

> Here is a brief tentative schedule of milestones which I think can be used
> as a plan for this project:

Okay.  I take it as the whole timeline is subject to re-arrangement
depending on how things turn out to be in practise.

>      *-- Milestone 0 (April 25 - May 23)* :  Do a round of requirements
> gathering and document the requirements so that we know exactly what we are
> aiming for. This can happen in parallel during the community bonding period,
> as mentioned in the GSoC timeline.

OK.

>
>      *-- Milestone 1* *(May 23-30)*:  Do a high level design of the project
> based on the requirements above and submit it for review to the leads.


OK.

>      *-- Milestone 2* *(May 31 - June 7 )*:  Incorporate the review comments
> and start on doing a detailed design for the approved high level
> design.

I would just skip the detailed design part ;-) Once we agree on what we
are aiming for (as in, a set of little incremental deliverables) and the
rough high level design of the changes to make to reach those points,
I'd go straight to coding :-) If you hit road blocks, we'll amend
requirements, design and code, if need be.  If we communicate well, I
hope we can just keep the mess inside some walls.

>      *-- Milestone 4* *(June 8 - June 22)*:  Complete detailed design and
> get it reviewed by the leads.

Same here.  I am sure you are doing enough paperwork in your life like
that.  Let's focus more on code, in an iterative way :-)

[...]

>      *-- Milestone 7* *(July 25 - Aug 22 - Final version ready)*: Finish
> development, start documenting the project and also do any final round of
> tests. This can be further broken down into sub-milestones during the entire
> period from July 25 till Aug 22.

I'd hope that documentation as well as code would happen in an
incremental way.  At least, documentation in the form of code comments
 -- that would already be an improvement compared to the current state of
Nemiver's code anyway ;-).

>    - *What will showable at mid-term [1]?*
>
> For midterm I, my plan is to develop an initial prototype with a few of the
> important python bindings. This will be more like a proof-of-concept of the
> final thing. The initial prototype will have very basic Nemiver
> functionalities exposed via python objects and will not include the full
> functionality.

Sure.  I guess at mid-term we'd be able to show the result of "just one
of the iterations".

Would this way of working make sense to you?

-- 
		Dodji