Stewart, I think this is an interesting direction to think about. In theory this should be relatively straightforward but someone with more knowledge of the build system might be able to speak to this.
I could see a few different ways to go. One possibility is to split along languages: have a core repo that is pure C++ and then language specific ones which contains bindings, etc. for that specific language. So there would be a nupic-core repo plus nupic-py repo's, nupic-java, etc. Or, nupic-core could contain the C++ core, C++ algorithm implementations, and the main language specific bindings within it (but cleanly separated out) and other repos have clients such as the OPF, vision, etc. This might be much more practical as nupic-core by itself would be fully usable. I'm also worried about repo-explosion. Matt - what's the best way to carry on the discussion? We can keep going on email, but would this also be a good office hour topic? --Subutai On Sat, Nov 16, 2013 at 6:27 PM, stewart mackenzie <[email protected]>wrote: > So this is great info. > > Might I suggest we simply strip out Algorithms and Network API out > into a separate repository? > > This can easily be joined together at build time with a cmake script. > > This way we can create an eco-system ontop of Network API (+ Algos) > without affecting Grok dependencies such OPF and support. > > Kind regards > Stewart > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
