Re: Proposal for GSoC 2011 - Python based scripting front end for Nemiver
- From: Dodji Seketeli <dodji seketeli org>
- To: The mailing list of the Nemiver project <nemiver-list gnome org>
- Subject: Re: Proposal for GSoC 2011 - Python based scripting front end for Nemiver
- Date: Fri, 08 Apr 2011 14:40:59 +0200
Thank you for pulling this together.
Seemanta Dutta <seemanta gmail com> a écrit:
> *Project Idea:* *Python based scripting front-end for Nemiver - the Gnome
> *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
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
> *execObj.setBreakPoint(function) # Sets breakpoint in the 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
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.
> *-- 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.
> *-- Milestone 2* *(May 31 - June 7 )*: Incorporate the review comments
> and start on doing a detailed design for the approved high level
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 ?*
> 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
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?
] [Thread Prev