User talk:Genuinelucifer: Difference between revisions

Jump to navigation Jump to search

User talk:Genuinelucifer (edit)

Revision as of 19:41, 18 May 2016

3,629 bytes added ,  18 May 2016
→‎GSoC 2016 Symbolic Project Improvements: new section
(GSoC 2016 Symbolic Project Improvements)
 
Line 39: Line 39:


## Time-line
## 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...
== GSoC 2016 Symbolic Project Improvements ==
Here is the plan (work in progress...)- 
. 
* 2016 GSoC Plan *
** References **
http://wiki.octave.org/Python_interface
** Outline **
Currently, Symbolic and PyTave each have their own mechanisms to convert objects into Octave types. As first stepo, 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 inbuilt into core octave.
If time is still left, we can work on improvements to upstream Octave:
https://savannah.gnu.org/bugs/?31080
https://savannah.gnu.org/bugs/?43036
** 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: extend this in some way to improve the way @sym objects are returned from Python.  That is, bypass the current generating of xml strings.  This could be done in some non-optimal way initially, such as hardcoding specifics of @sym objects into PyTave.
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.
* Time-line *




Retrieved from "https://wiki.octave.org/Special:MobileDiff/9149"

Navigation menu