>If Stewart reads this, how would you evaluate difficulty of the >"flow-based" NuPIC?
Interesting question, not so easy to answer. In order not to reimplement the whole messaging wheel, it'll be best to just use zeromq. This makes it easier, but the hard constraint on dependency free core puts that to the test in a big way. Thus the probable outcome is to use zeromq then maybe once proof of concept is sound rewrite the messaging. This is probably an insane thing to do. Might be best to just compromise with one dependency. So depending on the messaging rewrite / dependency hardline - this impacts difficulty. It shouldn't be done as one massive code drop on main. It reworks the entire structure of each component. Thus each component supports asynchronous io. If it is done in one huge code drop, 90% it'll be wrong, integration will be slow. It'll be fubar. It would be an extremely rocky ride for Grok, but at this stage API needs to break so as far as I'm concerned nobody should come along for the ride but should just wait for the next bus. Network ( component graph) manager related stuff needs to be stripped out. Lots of python related stuff in there. Link class removal etc - difficulty - "soso" Then that very clean asynchronous API needs to be distilled. difficulty - "hard" - as it requires lots of intelligent and stupid people to bash that API into shape. This should really be done by core team. But there is too much office politics, ass covering, and ego for them to effectively make decisions independently, the community has to cause them to reflect, but even then the 'don't do this on our mailing list' card will be pulled, so expect blood to flow, and members banned. One needs to remind them, the community are not employees that need to be managed. There are a subset that behave like employees, these folk _maybe_ seeking employement. It doesnt mean we all seek this path, and therefore should model it. On the whole we come to free software to escape office politics. There is nothing more annoying than ego trumping good sociotechnical decisions. It'll probably be best done by an enthusiastic bright student, but one shielded to best effect by C4. Then again just using C4 is too much drama, so I'm giving up being the tip of the spear point effecting change. Need some nupic R&R before I come back, in the mean time I'm passively watching. btw now I will no longer hold back my opinions (both technical and sociotechnical) regarding nupic's path forward even if it includes swear words and gets me banned! I don't have the ability to see a clear path through this, that's why I need C4. C4 effectively maps a path through the problem space. Its at this point i need my mind to engage with crowd wisdom. Now, there are too many variables and possible outcomes. So when people come to me saying are you sure this is going to work, or I've been backing you, (now I'm scared to back you) all I can say is: you need to use C4 to effectively map this problem space. At this time, it means maintainers who implement C4 _properly_. David being made a maintainer is an _excellent_ step forward. But I fear it is an appeasement only. The real proof is when David liberally (guided by C4) clicks the green button, now we're talking. Unless core devs bite the bullet, by putting Grok on the side and getting things done quickly then reattaching Grok. Without using C4 and the ability to pivot with crowd wisdom, It'll be nearly impossible, or will be a long series unmerged, closed pull requests. The brush I have used is broad, it does not touch all. Hence my overall answer based on my current naivety level : Impossible at the moment. Kind regards Stewart -- Please excuse my typos and brevity _______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
