User talk:Genuinelucifer
GSoC 2016 Symbolic Project Improvements
References
Outline
Currently, Symbolic and PyTave each have their own mechanisms to convert objects into Octave types. As first step, we would put @sym creation login into PyTave and remove all the conversion login from Symbolic. Then we will target having the same via some m-file callback to have a more generalised conversion for objects.
We'll need PyTave to build successfully on all platforms (including windows) before we can ship it as a release. In ideal case, this is the target to be achieved as mid term goal.
Once we have full support for all platforms, we could have PyTave as the only mechanism to communicate with python. Also, we will improve the functionalities of PyTave by adding support for handling python objects.
After all this is acheived and we have all tests working fine on all platforms. We will have some @sym methods recoded to use the full power of PyTave. We can then head to "blue skies" and work on some octave core stuff like correcting display of unicode on windows and maybe trying to get PyTave merged into core Octave.
If time is still left, we can work on improvements to upstream Octave:
Midterm Goals
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.
Time-line
| 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... |