Timeline and Goals for the project

We (me and both mentors) decided upon the following timeline to be followed during the course of this project:

30th May — Work on adding the sym conversion to PyTave and cleaning up the conversion mechanism in Symbolic.
15th June — Improve tests and doctests. Work on building PyTave and testing on Windows. No more crufty XML!
27th June — Try to get working PyTave with Symbolic on Windows (if needed, use cygwin) [Mid Term Evaluations]

5th July — Get a successfully working Symbolic with PyTave (all the tests and features working). Continue work on Goal 3.
20th July — Finalize implementation for Goal 3.
31st July — Work on improvements to PyTave such as adding support for Python objects from within Octave (printing, calling methods, saving etc…).
10th August — Recode @sym methods as required to take benefit of PyTave. Also, add some other methods into Symbolic from #215
15th August — “Blue-skies” stuff. Try to fix the unicode utf8 rendering on Windows. Explore possibility of incorporating PyTave into Octave. [gsoc final code submission begins]
23rd August — Finish all the code, test on buildbots and Windows. Submit to Google. [Final deadline for code submission]
Afterwards — Complete any goals which are left. Continue contributing to Octave…

———————————————————————-

Following goals were set for the mid term evaluations :

1a) Octave, Symbolic, and PyTave dev versions installed.

1b) Some basic communication working between PyTave and Symbolic. This might use some existing implementations in a non-optimal way (e.g., its ok if Symbolic returns objects as xml strings).

1c) Most of Symbolic’s tests and doctests continue passing, although some failures ok at this point.

1d) The above works on at least one OS (probably GNU/Linux).

2a) PyTave converts various Python objects into appropriate Octave objects. PyTave needs to be extended to return proper @pyobj when it cannot convert the object. Also, symbolic must be able to convert such objects to @sym objects by calling proper python functions via PyTave (if they are indeed @sym). That is, bypass the current generating of xml strings.

2b) Improve the BIST test set coverage of both PyTave and Symbolic for any new features added.

2c) Improve doctest coverage of PyTave.

Stretch Goals: 

3) Improve on 2a) with some TBD mechanism: perhaps a pure m-file callback feature in the PyTave export code.

4) The above works on both GNU/Linux and MS Windows.

5) Objects passed from Symbolic back to Python should use PyTave mechanisms.

Advertisements

Author: genuinelucifer

I love coding, working on open source projects specially. Even making my own games, softwares... Learning new technologies has always been my cup of tea. :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s