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 xmlstrings).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 #452Groundwork 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.

2b) Improve the BIST test set coverage of both PyTave and Symbolic for any new features added.
Added some tests to pytave with the PRs #10 and #11 on bitbucket.

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:https://bitbucket.org/macdonald/pytave

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.

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.

Something I’m curious about that we’ve never discussed: how does the new pytave communication compare for speed? I’d be curious about before and after timings of `octsympy_tests` for example… Great topic for a future blog post!