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

[Seemanta Dutta <seemanta gmail com>]

Dodji,
Thanks a *lot* for replying to my email so promptly! I seriously think we should have more project leads like you! You make working on Nemiver (and open source in general) such a pleasure :) 

Please see inline for my comments.

On Fri, Apr 8, 2011 at 5:40 AM, Dodji Seketeli <dodji seketeli org> wrote:

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.

  
   Do you want me to edit my proposal and mention this thing about the IDebugger within the submitted proposal ?

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.

    Absolutely! I did not mention about this plain vanilla command line in my proposal because I wanted to limit the scope of my project to just the python console for now. I think if we design our python console well enough, later on providing bindings to pure gdb'ish commands would be simple. What do you think ?

>    - *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.

   Thanks !

> 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.

   Of course! Thing might change depending on how they work out in real life. I mentioned the schedule just so that we have some framework to follow and also the format for the proposal asks for a brief schedule from all applicants.

>      *-- 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.

   So are you saying that we don't aim specifically for any high level design but rather get it done 'along-the-way', so to speak ? If so, yes, I agree. But then do you want me to edit my proposal within google-melange.com for this ?
  

>      *-- 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 :-)

  
   Agreed :) To quote Linus Torvalds, "Talk is cheap. Show me the code" :)

[...]

>      *-- 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 ;-).

    Oh yeah. What I meant was maybe create end-user documentation, at the end. Inline comments are of course are a must during development :)
 

>    - *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".
 

    One iteration, seems good. But given that midterm would be half way between the final date, I would prefer a couple of iterations, subject to the timing constraints, of course. I mean I want the things to be proportionate between the midterm and the final evaluations. But as you said, we can monitor the pace of the project along the way and throttle ourselves as we see fit.

 

Would this way of working make sense to you?

    Absolutely! I am really grateful for your valuable comments. So now, should I go ahead and edit my proposal within google-melange.com based on the above comments or do you think leaving it as is would be sufficient ?

 

--
               Dodji
_______________________________________________
nemiver-list mailing list
nemiver-list gnome org
http://mail.gnome.org/mailman/listinfo/nemiver-list