I’d like to see Nupic in C#. I can get a fork going, but I could use some assistance. I’m not an expert on… pretty much anything required to setup these bindings. C++, CMake, Cap’n Proto… all new.
I’m on Windows 10 64-bit, and I’d like to use Visual Studio 2017. I’m following the Windows setup instructions.
ISSUES
Is python and pycapnp even necessary for getting C# or languages other than python? Currently, CMake fails with:
CMake Error at CMakeLists.txt:251 (create_capnpc_command): Unknown CMake command "create_capnpc_command".
Now, this is likely because pycapnp fails to install… and I’m not really sure why. Windows support? User error? I installed the latest setup tools.
*WARNING* no libcapnp detected or rebuild forced. Will download and build it from source now. If you have C++ Cap'n Proto installed, it may be out of date or is not being detected. Downloading and building libcapnp may take a while. fetching https://capnproto.org/capnproto-c++-0.6.0.tar.gz into c:\users\matt\appdata\local\temp\pip-build-m63xk4\pycapnp\bundled error: [Error 2] The system cannot find the file specified
PROPOSAL
Bindings would go in nupic.core/bindings/cs/. Thought ‘cs’ is better than ‘csharp’ - it matches the C# file extension.
Would this require an update to the CMake file - a variable for the Swig language parameter?
Before I add a Github issue - as long as there’s interest - I’d just like to get an idea of what would need to be done, so we can track everything.
@heilerm I have been able to successfully create a Visual Studio 2017 solution fork to compile nupic.core and run the unit tests. I think it’s a little out of shape because I’m trying to add python 3 binding without swig.
If you are interested I can help you out get going on your machine.
I found your fork the other day. Getting anything into VS 2017 would be a step forward. Definitely interested.
I tried using the CMake VS 2015 generator, since that seems to have been working and I’m getting the same issue - getting Cap’n Proto setup in Windows. Were you able to install pycapnp using pip?
Since python is the only language bound at the moment, I’m having difficult pinpointing how another language would be supported in core. So, to start, I guess I’d like to figure out how the python binding is working. Trouble is getting it built at the moment.
I also tried to build nupic.core under VS 2017 and was unsuccessful. All I wanted was the ability to call into nupic core from C++ under Windows. For my project I did not need Python. From what I gather it is possible to build under Windows but only if I build under a very old version of VS and that is not an option in my case.
The algorithm modules in nupic.core such as TemporalMemory.hpp contain things like #include <nupic/proto/TemporalMemoryProto.capnp.h>
I think this is generated by pycapnp. Since I cannot run or build pycapnp I was stopped.
This program is a wrapper around Cap’n Proto’s functions but I don’t know what it is intended to add. (http://jparyani.github.io/pycapnp/)
Cap’n Proto and all of the other third party modules have newer versions that do support Python 3 but pycapnp does not. Looking into pycapnp it appears that it is no longer being maintained. The last change was 7/2015.
So we would either have to update pycapnp ourselves (probably not likely) or change the nupic.core build to not use pycapnp. I have not investigated what it would take to do that. I suspect that if we were to get rid of pycapnp it would remove the restriction to using VS 2017 and also allow Python 3 because we could then link with the right libraries. Once nupic.core builds under VS 2017 we could then setup an interface for C# and any other languages people might want.
Building under VS 2017 will prevent Python2 from running with these newer libraries so we would have to upgrade everything to Python 3. A cursory check of all of the third party imports like Numpy I found they have Python 3 versions so that would not be a problem but more than likely we would break some existing Python code in Nupic in the process. There would be a lot of testing required to identify what was broken and fix them but it would be doable.
Tasks:
Setup Community Fork
Come up with a strategy for removing pycapnp
Make changes to Nupic.core modules as needed.
Make changes to build
Run tests on all Nupic.core to confirm nothing is broken in the C++ code.
Run tests on all existing Python code and fix any problems.
The new build must work for both Linux and Windows (under VS) and must also be able to be built with the old compiler such that it can still support Python 2 for those people that don’t’ want to upgrade quite yet.
I am a retired Software Engineer. I have some time and I would be willing to help in this task but I do not want to take on the project myself. Is anyone willing to help me?
It seems the desire to move to python 3 is overwhelming. I’m working on getting @chhenning branch to build so that I have something to look at. He’s upgrading to Python 3. I’m not an expert with C++, Python, CMake, VCPKG… any of this, really. That said, I’m very much willing to help… and learn. I’m not really sure why pycapnp is there. Looks like there’s some interop? C++ calling some numpy code? I’m on day 2 of absorbing all this.
If you’re going to do this in a community fork, why worry about Python 2 at all? Those not wanting to upgrade can simply continue using NuPIC stable releases.
@rhyolight mentioned seeing about getting official language bindings into master. Major changes would probably make that less likely. It is in maintenance mode… I’ll hope for a little and expect not a lot.
If noninvasive changes could be made in order to add the C# bindings, that could possibly go into master and then we could have community branches for the larger and riskier alterations like VS 2017 updates. Other binding could be added as well. I’m just not really sure how that would work. I can’t find a tutorial on how to do that, as outlined in the extraction plan. Any hope for that, @rhyolight? My thought was that once I got it to build using CMake, bindings would be added to ~\nupic\bindings\cs using swig and that’d be used to generate a C# project repository.
My immediate issue is installing pycapnp on Windows. I get the error described in my initial post. I suspected setuptools, but updating them didn’t work. Once I get that installed, I’m hoping that puts me past the CMake error I’m getting that’s related to it.
@heilerm Now that we have a new version of pycapnp it should make our work much simpler.
However, I still question why we are using pycapnp at all. I discovered that the data portions of the following classes are not defined in C++. They are declared in the nupic Python code. pycapnp builds the corresponding .h files so the C++ modules will compile.
This means that there is a compile time dependency on the Python nupic modules even if you are trying to build a C# or even a C++ implementation. I suspect this is so that these objects can be passed by value or the object’s public fields can be directly accessed by the Python modules. This requires serialization and deserialization of the object on each access. Not a very good design for a core library but this is probably not the time to be re-designing the library.
Lets get a new CMakelist.txt working for nupic.core using the new cycapnp and then we can decide what to do.
A tutorial on creating a language binding in swig? No we don’t have one. But I’m sure swig has docs. You are pioneering new territory here folks. As you make progress, please track it here on #nupic:developers. This forum is also a wiki and a great search tool. It would be great to have a wiki page on creating language bindings.
Hmm. I think I need a visual of what’s going on. A map. Working on a diagram. At work, so I might not have anything until later.
@David_Keeney Do you think a test/prototype project would be a good idea? C+±only. Copy/paste a couple classes from nupic.core. Pick two languages for binding. Keep the same/similar project structure. Test it without having to support legacy, on Windows, Linux, and OS X? No python anything. The core extraction plan describes it’s goal to be C++ only, so I too was surprised to find a dependency on python. That plan describes:
nupic.core - C++
nupic-<flavor> - language binding
nupic-<flavor>-client - language client
Then we can have that to discuss and maybe see if we can do anything for master?
@rhyolight Maybe a new topic, once we get things ironed out? See what we need to do. Not sure this could be merged into master, due to its current state and the impact of this work.
I could be way off, but this is what I’m thinking, as I understand it:
SETUP -> BUILD -> PUBLISH
SETUP
This is kind of a black box right now, so correct me if I’m wrong.
With the source code (*.hpp, *.cpp), generate swig interfaces (*.i), then generate whatever wrapper(s) (*.cs, *.py, etc.) you want? Can’t this be scripted?
Using the wrappers and CMake, generate a build system?
BUILD
System-specific. Whatever is available in CMake generator tool?
PUBLISH
System-specific. Package DLLs and PY and whatnot.
PROTOTYPE
To start, I’d propose…
nupic.core (prototype)
/env
// cmake generator output?
/gen
// generated swig input/bindings (*.i)
/obj
// generated swig output/wrappers (*.cs, *.py., etc.)
/src
// flatten this out a little bit from src/nupic? put test and examples in other projects?
/algorithms
/bindings
// can't this be generated from headers using swig? whats the history behind this? am i misunderstanding swig?
/encoders
/engine
/math
/ntypes
/os
/proto
/py_support
// is this why nupic.core depends on python? move that to a different repo and pull it in - isolate it?
// would that simplify the build process? are things just fine?
// python is still required to run C++? is numenta really cool with that? to run... java, you would need C++, java, and python runtimes, no?
/regions
/types
/utils
// setup can go in the root
// setup script does:
// 1. generate swig interfaces from headers into gen
// 2. generate wrappers from swig interfaces into obj
CMAKE (Generate a build system with ~/src)
CMake the build system for your environment.
\*.cppproj
\*.sln
...
BUILD
Use that build system.
nupic.core.lib
nupic.core.dll
...
GENERATED (e.g., C#, Python)
WRAP
Use Swig? Can those interfaces be generated from the headers, then used to wrap the source code?
Script this? (e.g., wrap.py -python, wrap.py -csharp).
generate swig interfaces from headers into ~/obj.
generate code from swig interfaces into ~/gen.
CMAKE (Generate a build system with ~/gen)
CMake the build system for your environment.
Build the source and generated code.
Package it and ship it.
NPM? Nuget? Other(s)? All-the-above? Up the community to provide support?
// C++
// pass-through?
nupic.core.lib // C++
// C#
nupic.core.dll // C++
nupic.core.cs.dll // C#
// PYTHON
nupic.core.lib // C++
nupic.core.py.py // Python
PROTOTYPE
To start, I’d propose…
nupic.core (prototype)
/gen
// generated swig output\wrappers (*.cs, *.py., etc.)
// gitignored
/obj
// generated swig input\bindings (*.i) generated from source (*.hpp, *.cpp)
// gitignored
/src
/algorithms
/bindings
// can't this be generated from headers using swig? whats the history behind this? am i misunderstanding swig?
/encoders
/engine
/math
/ntypes
/os
/proto
/py_support
// we can talk about removing this at a later point
// since this is exposed, i wouldnt touch it - thats high-impact
// ignore this until the end of the prototype?
/regions
/types
/utils
// project.cmake - setup build system for source code (C++)
// project-cs.cmake - setup build system for generated code (C#)
// project-py.cmake - setup build system for generated code (Python)
// publish.py - publish script
// publish-cs.py - publish script wrapper (C#)
// publish-py.py - publish script wrapper (Python)
// wrap.py - python script? have to pick something for both linux and windows...
// wrap-cs.py - ease-of-use?
// wrap-py.py - ease-of-use?
@heilerm That looks like the right idea. We probably should have a /build folder. This thing needs a ton of third party stuff and we need a place to put all of it.
nupic.core is distributed with patches for those third parties, too. Got a little bit farther with the Windows build and currently have an issue getting those to patch, but… there they are.