I think cereal Docs - Main would be a great, lightweight choice for c++ codebase.
My question is, if instead of solving serialization for each binding, we could make a separate “nupic.serializer” project? Which would take a py/c++/c#/java object and de/serialize it?
Alternatively, the serialization would be only provided by the one low-level binding (c++ nupic.core) and other bindings just call its load/store methods.
@chhenning Yes, I think that is a valid description of serialization. The existing approach to serialization should be retained… starting with a call to serialization on the Network class, it calls serialization on all registered Region classes. They in turn call serialization on those classes below them. The de-serialization is just the same in reverse.
Progress report.
I have about 1/4 of the C# binding code rough written, about 1/2 of that compiles. One of the biggest challenges was getting CMake to build the C# interface code (C++/CLI) within the native C++ project that builds nupic core. I still don’t have it building the C# unit test code. Another challenge is determining how to implement the plug-in facility so that it works somewhat like it does for Python. C# is a strongly typed language and some of the data structures used in the nupic.core do not lend themselves to passing data between the native C++ core and the C# plug-ins without copying. But I think it can be done.
I currently have wrappers for:
Engine - about 75% rough coded.
nTypes and types - 80% coded and compiled.
utils - 25% coded
encoders - 0% coded
algorithms - 0% coded
math - 0% coded
regions - 0%
tests - 0%
os - will not be needed.
proto - will not be needed (using Yaml serialization.
py_support - will not be used
bindings - will not be needed (not using SWIG)
Additional work that needs to be done:
Write unit tests comparable to the Python test suite.
Documentation of the C# interface
Sample code written in C#
port other Python code to C#
getting it to work with non-Microsoft C# compiler on linux
I am taking next week off … Headed for Hawaii in the morning for a destination wedding.
I pushed what I have up to my repository in case anyone wants to take a look. https://github.com/dkeeney/nupic.core/tree/master/src/nupic/csharp/wrappers
Do not expect anything to work or anything to be complete. Its a bit of a mess actually…
@chhenning I am back working on the C# interface again and I wanted to get the latest version of Nupic.cpp. But I see this still has the capnproto code in it. Didn’t you remove the capnproto serialization? … or am I looking in the wrong place. I really did not want to do Capn proto serialization in C# unless I had to.
@chhenning I am in the process of sticking the C# modules into a clone of your repository but I get this error when I try to compile one of my modules:
f:\ai\chhenning\include\pybind11\detail/common.h(111): fatal error C1083: Cannot open include file: ‘Python.h’: No such file or directory
I assume this means that you want Python to be installed in some specific place? How do I fix this?
It would be nice if there is a way to do a C# & nupic.core only build without also having Python installed but we can worry about that later.
Sorry for the late reply. You should be able to use both python versions, 2.7.x and 3.x . I think the path might be hardcoded to c:\python36\include. Will fix that eventually.
Can you please tell me in simpler way to setup this nupic in c#. As I have looked at this but I didn’t understand many things. So please make any video tutorial on this or provide some steps to do it. Also what is the advantage of this nupic?
We are still a long ways off from having a C# interface working.
The first steps are to get the nupic.core library extracted so it can be compiled with the latest compilers C++ compilers. Then re-constructing the Python extension to work with this library using Python3 and pybind11. And with support for MSVC, Linux, and OSx platforms. This is almost working but not quite ready for prime time. https://github.com/htm-community/nupic.cpp
The next step is to fill out the C++ library with missing components that are currently implemented in Python (SPRegion, TMRegion), such that Python is not required to implement a full application in C++ using the Network API.
Once all of that is working, we can write wrappers for C#. Much of that has been roughed out but a lot of work remains.