The mid term evaluations of GSoC 2016 are close. This blog post is to summarize the complete work done under the ‘Symbolic Project’ under the organization ‘Octave’.
I will mention each of the goals that were set for the mid term and then give an overview about what was done for that:
1a) Octave, Symbolic, and PyTave dev versions installed.
I built Octave from source successfully on ubuntu 16.04 then used symbolic with it. Also built pytave from source using the dev version of Octave.
My Symbolic fork on github can be found at:
My main Pytave fork can be found at:
I also forked pytave from Colin’s fork (to work on experimental features) which can be found at:
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).
PR #452 added the functionality to convert python types into Octave types including @sym objects using pytave. Then PR #460 fixed the communication when lists/tuples were passed from python to Octave.
Then we also added proper conversion of tuples and booleans from python to Octave types in pytave repo in the PRs #9 and #11 respectively.
1c) Most of Symbolic’s tests and doctests continue passing, although some failures ok at this point.
Tested on Ubuntu 16.04. Most of the tests pass on Linux. There are still many tests which are failing (with the new IPC) but we will work on them once we have a stable pytave IPC mechanism.
With use of pytave, the errors have now been converted to python exceptions which seems to be the main reason of many tests failing. Also, sometimes it seems that the way we chose to return the outputs is conflicting with how the existing IPC mechanisms were doing it. But, these are minor failures and can be taken care of later as the new IPC matures.
1d) The above works on at least one OS (probably GNU/Linux).
It works good on Linux (our local machines).
We are currently trying to integrate use of pytave on the build-bot. The work can be tracked on the PRs #477 & #478 on github.
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.
Instead of editing pytave to convert @sym objects before returning, we incorporated a different mechanism in Symbolic only which converts the objects it gets into @sym objects if necessary using py* functions. The major work was on the PR #452
Groundwork has been laid for storing objects persistently on python side using @pyobject from pytave. We will also work on improving @pyobject to allow for calling all the attributes of a python object from Octave.
2c) Improve doctest coverage of PyTave.
Not many doctests were needed so this part is low priority for now. Might still do it this week.
We also had some ‘Stretch Goals’ which were planned in case we get time and following is the progress for them:
3) Improve on 2a) with some TBD mechanism: perhaps a pure m-file callback feature in the PyTave export code.
Since the workaround for @sym conversion was already used in symbolic so this was not required. Moreover, we are working on adding @pyobject support to pytave on Colin’s fork:
4) The above works on both GNU/Linux and MS Windows.
Pytave needs to be built on Windows which might take a while. On Linux, we have it working. For building on windows, we are having an extensive and comprehensive discussion and are getting closer to the goal everyday.
First ‘cygwin’ was tried to build pytave on windows but many tools were not found on cygwin, moreover Octave already has a MSYS environment so we shifted to using something like that. Currently we were trying MSYS2 environment for building pytave, all the libraries were available but we got stuck at a point when trying to link with octave libraries. Octave was build with GCC 4 while MSYS2 has GCC 5 and due to some ABI incompatibility of GCC between the two versions, it was not possible to continue the build.
So, now we will try to build it from within octave, using the the MSYS bash shell. But, now we need to (probably) build libboost-dev and python-dev using that shell and then move to building pytave with it.
5) Objects passed from Symbolic back to Python should use PyTave mechanisms.
The work can be seen in the PR #465 which tries to call py* functions to store the variables into python. We have written a function which stores the required variables to a python list. Currently, it is not very stable and causes octave to crash in some tests but we are working on improving it. It now supports passing lists and 2-D matrices. But, it needs to be extended to support other types like cell-arrays and n-D matrices.
In the start of the project we had some minor enhancements to Symbolic. In the mid way we also had some enhancements on the pytave side which were needed to move ahead with the aforementioned goals.
All of my contributions to the repos can be tracked at following links:
My contributions to octsympy‘s main repo on github
My contributions to pytave‘s main repo on bitbucket
My Contribution to Colin’s pytave fork
This was the summary as per the goals set. Now, a quick summary as per the timeline we decided just to showcase how closely we are following the path we decided at the start of the project:
30th May — Work on adding the sym conversion to PyTave and cleaning up the conversion mechanism in Symbolic.
Till 30th May we had already added the mechanism to convert sym objects that come from pytave. We still have to work on it for some cases, as we have many failing tests. But, we have a basic structure that doesn’t rely on any XML stuff for object conversion.
15th June — Improve tests and doctests. Work on building PyTave and testing on Windows. No more crufty XML!
Till 15th June we had improved BISTs of pytave. The building of pytave has been underway and we have got rid of the XML stuff in pytave IPC.
27th June — Try to get working PyTave with Symbolic on Windows (if needed, use cygwin)
We have been following the timeline from the start. We also have other smaller goals in progress aside to this (including build pytave on travis and using pytave to pass variables to python). We have used MSYS2 to build pytave on windows. But that led to some conflict in gcc versions of MSYS2 and the ones present in Octave. Finally it seems that boost and python-dev have to be build using the MSYS environment of Octave and then only pytave can be built using those tools.
All of the aforementioned goals and timeline can be found at my wiki page:
For any feedback/comment, feel free to post a comment here…