search

numenta / nupic-legacy

Numenta Platform for Intelligent Computing is an implementation of Hierarchical Temporal Memory (HTM), a theory of intelligence based strictly on the neuroscience of the neocortex.
http://numenta.org/
GNU Affero General Public License v3.0
6.34k stars 1.56k forks source link

Move bindings out of nupic #974

Closed david-ragazzi closed 8 years ago

david-ragazzi commented 10 years ago

This is a controversial issue, but I expose some reasons to this.

I think if we move bindings to nupic.core, this would ease the life of those that has interest only in consume the nupic.core library, but not the other things in nupic. Today if someone wants consume the NuPIC library for C# or Java environment, she should access nupic repo to extract them. It would be more produtive the nupic.core itself provide the bindings to to the code that only is provides (i.e. the CLA in C++). This said, don't make sense we have the bindings folder in a Python client project like nupic instead of nupic.core. This said, we would have in nupic.core:

nupic.core
  src
    main (the core algorithms in C++)
    bindings (the bindings of the core)
       common (files used by all bindings)
       cs (C# bindings)
       java (Java bindings)
       py (Python bindings)
    test (all tests)

The bindings shouldn't be automatically build when nupic.core is build, but it should be build by demand only when the user or client app wants.

(I know that Numenta won't give support to other languages, but this doesn't weakens the argument of move bindings to nupic.core)

rhyolight commented 10 years ago

IMO, there should be one repository for each language binding. If you want to extract the C# and Java bindings from the nupic repo, that is ok with me, but instead of putting them into nupic.core, they should live in their own repositories.

david-ragazzi commented 10 years ago

IMO, there should be one repository for each language binding. If you want to extract the C# and Java bindings from the nupic repo, that is ok with me, but instead of putting them into nupic.core, they should live in their own repositories.

This also is valid. What it is not valid, it is the bindings code remains in nupic..

Btw, why the bindings cannot be in nupic.core as they are tied only to nupic.core? They would work as front-end projects and would be separated from core algorithms in other folder.. In the end, the library is the same, but provided in a different language than C++ (.DLL, .PYC, .Java, etc)..

breznak commented 10 years ago

The thing is until nupic.core matures (it does "just" CLA) now) there can be valid requirement to bind to functionality of nupic (py) - eg there is no anomaly, swarming, even encoders in core.

utensil commented 10 years ago

+1 for moving other bindings out of nupic, -1 for moving them into nupic.core.