Apologies Matt, Just read your Meeting Notes (should have done that first), so a small amendment. Insert at top of my list
nupic repo remains with entire current contents nupic.core etc... Regards, Fergal Byrne On Fri, Jan 24, 2014 at 9:01 AM, Fergal Byrne <[email protected]>wrote: > Thanks Matt, > > That'll be a huge step forward, well done for getting it out the door as a > priority. I think your point (made during the Office Hour) about > incrementally including regression tests as a way to control the migration > is vital, and I think you should proceed as you suggested by putting > "trivial" or basic regression tests in and then driving enthusiasts (Marek > springs to mind) to add to and improve them. > > I agree with Chetan about using dots in the repo names (it's become a > convention in most OSS projects as well as in namespaces). In addition, > this will allow us to extend the hierarchy at a later date rather than > build new repos. This also answers the python question by using the github > naming convention (project.repo.component.subcomponent..). Here's a > candidate: > > nupic.core is the repo for a pure C++ stack, including: > nupic.core.lib - project packaging the nupic-core API as a GLIBC library > (and Windows equivalents) > nupic.core.app - command line app (single download, easy to build > binaries) which reads a single config file: "nupic -c > hotgym/nupic-config.json" > > nupic.py is the python project repo, including > nupic.py.bindings > nupic.py.lib - python library version of NuPIC, eventually packageable as > a python package > nupic.py.clients - approved clients including OPF, various runners, > visualisers, Cerebro etc. These would each be in nupic.python.clients.opf > for example. > > nupic.ruby repo includes > nupic.ruby.lib makes a nupic gem > nupic.ruby.clients > > nupic.your-lang-here > > I recommend setting up most of these language repos with just a README.md > calling for people to fork and build the initial version, then pull them in > yourself when appropriate, at which point you could appoint the forker as > lead maintainer for that repo (or continue to point people to the fork and > manage the merges yourselves). > > Regards, > > Fergal Byrne > > > > > > On Thu, Jan 23, 2014 at 6:20 PM, Matt Keith <[email protected]> wrote: > >> I think it all depends on how you define 'client'. If the OPF is >> considered a client, then I think that it should be separate from the >> python bindings. However, I think that the python encoders should be >> included in the python bindings repo. So maybe something like this: >> nupic.core <- nupic.python (includes encoders and simple example) <- >> additional clients or projects using nupic >> >> On Jan 23, 2014, at 11:06 AM, Chetan Surpur <[email protected]> wrote: >> >> Trivial suggestion: how about naming the repo 'nupic.core'? The dot >> notation to demonstrate project hierarchy seems cleaner to me (and is >> common on GitHub). >> >> Other repo names might look like 'nupic.python' and >> 'nupic.python.client'. >> On Jan 23, 2014 8:30 AM, "Matthew Taylor" <[email protected]> wrote: >> >>> You guys want a C++ core extracted from NuPIC, so we're going to plan >>> it. Starting next sprint[1], we're going to work on pulling all the C++ out >>> of NuPIC into a repo called 'nupic-core'. >>> >>> We had a meeting Monday[2] where we discussed many of the details of >>> this plan, and I created some diagrams to describe the plan[3]. Please take >>> a moment to review these and provide feedback for this plan. The end goal >>> is this: >>> >>> >>> https://github.com/numenta/nupic/wiki/images/nupic-core-extraction-goal.jpg >>> >>> We still have some open questions that we'll work out as we go along, >>> for example: >>> >>> 1. Should there be different repos for language bindings AND clients? Or >>> should they be combined in one repository? >>> 2. How will our build automation need to change to accommodate these >>> changes? >>> 3. Do we include general encoders in nupic-core? (they are all currently >>> within python) >>> >>> I'd like to hear opinions on this whole plan. We want nupic-core to be >>> generic enough to provide what everyone wants, so if this plan seems to >>> restrict your particular use-case, let's discuss it. >>> >>> [1] https://github.com/numenta/nupic/issues?milestone=9 >>> [2] >>> https://github.com/numenta/nupic/wiki/2014-January-Core-API-Meeting-Notes >>> [3] https://github.com/numenta/nupic/wiki/NuPIC-Core-Extraction-Plan >>> >>> --------- >>> Matt Taylor >>> OS Community Flag-Bearer >>> Numenta >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> nupic mailing list >> [email protected] >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> > > > -- > > Fergal Byrne, Brenter IT > > <http://www.examsupport.ie>http://inbits.com - Better Living through > Thoughtful Technology > > e:[email protected] t:+353 83 4214179 > Formerly of Adnet [email protected] http://www.adnet.ie > -- Fergal Byrne, Brenter IT <http://www.examsupport.ie>http://inbits.com - Better Living through Thoughtful Technology e:[email protected] t:+353 83 4214179 Formerly of Adnet [email protected] http://www.adnet.ie
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
