Reduce dependencies

[breznak]

@dkeeney @chhenning I was reviewing your interesting work on refactoring/reducing nupic.core, and I'd like to get it merged back here to some extend.

Features that I like:

• using c++ instead of boost, where possible. Seen in @dkeeney 's base branch? Although I'm interested only in changes with c++11 (not ++17 as you target) Ok, let's go c++17. Switch to c++17 #55 Switch to c++17 and remove Boost  #106
• removing apr* , boost.filesystem is the replacement? Also in the base branch? Replace APR libraries with std:: libraries (abandoned) #74
• getting rid of zlib / capnp for compression. I think one of you sticks with either. I'd for sure remove zlib, as users can zip themselves; capnp adds lots of mess, but works quite ok, do you think vanilla plain-text backups are ok/better? Figure serialization (remove capnproto?) #48
• removing Swig, replacing with pybind11 (@chhenning ?) does it work well? which branch can I start cherry-picking and merging from? Or David has gone the pure C++ way.
  ...this bullet will be quite complex, I'll leave it for now for further discussion. Road map for migrating to PyBind11 and Python3.x support. #81
  • Do I still need/benefit from your SP/TMRegion classes? Merge Region classes from dkeeney #54

[dkeeney]

I would rather not require boost. With c++17 we get most of what boost provides as std::, including filesystem. I think most people now have compilers that can support c++17. Zlib was used only as an alternative way to feed data to one of the encoders. Not part of serialization. By removing that one minor feature we can reduce the dependencies. capnp is a real pain to follow and maintain. @chhenning and I want to replace it. Nobody else had any comment. Yes, replace Swig with pybind11 but all of that code will be in another repository. One that calls the pure C++ library. The code should be much easier to maintain as separate repositories. @chhenning was working on that but got bogged down in his real job. Without the SP/TMRegion classes it is impossible to write any NPIC implementations using the Network Framework in C++ only. The CSharp language interface will also need this because it would have a hard time calling Python to get to the SP/TMRegion modules. So it makes since to fill in the missing parts in the C++ library.

…

On Wed, Aug 1, 2018 at 3:46 PM, breznak ***@***.***> wrote: @dkeeney <https://github.com/dkeeney> @chhenning <https://github.com/chhenning> I was reviewing your interesting work on refactoring/reducing nupic.core, and I'd like to get it merged back here to some extend. Features that I like: - using c++ instead of boost, where possible. Seen in @dkeeney <https://github.com/dkeeney> 's base branch? Although I'm interested only in changes with c++11 (not ++17 as you target) - removing apr* , boost.filesystem is the replacement? Also in the base branch? - getting rid of zlib / capnp for compression. I think one of you sticks with either. I'd for sure remove apr, as user can zip themselves, capnp adds lots of mess, but works quite ok, do you think vanilla plain-text backups are ok? - removing Swig, replacing with pybind11 ***@***.*** <https://github.com/chhenning> ?) does it work well? which branch can I start cherry-picking and merging from? Or David has gone the pure C++ way. Do I still need/benefit from your SP/TMRegion classes? ...this bullet will be quite complex, I'll leave it for now for further discussion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_7HW0cqgUpZbLfTo2Nh_93NFL8Biks5uMi_TgaJpZM4VrXN-> .

[breznak]

I like to notion about zlib and capnp, I'll join that! I'll have to think about cpp17 and completely pure c++, but I agree it's the cleanest solution...so when the time comes.
Actually, is anybody else developing the repos?

[dkeeney]

There are a lot of people doing there own thing. But as far as I know, you, I and @chhenning are the only one's doing anything with nupic.cpp. I suspect that some people have looked at the current Nupic implementation as a starting point for their implementations and just decided to roll there own because it would be simpler. So one of my objectives is to make a simple implementation (within the API) that can be understood by looking at the code and ... something that uses the latest technology. By using C++17 we can avoid boost. I would rather be on the leading edge of technology that lagging behind (like requiring python2.7 and a very old compiler that matches).

…

On Tue, Aug 7, 2018 at 10:24 AM, breznak ***@***.***> wrote: I like to notion about zlib and capnp, I'll join that! I'll have to think about cpp17 and completely pure c++, but I agree it's the cleanest solution...so when the time comes. Actually, is anybody else developing the repos? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_-aJcrtk9FvWLf4P1nx4xInaInvbks5uOc1ogaJpZM4VrXN-> .

[chhenning]

Sorry for the late reply. Welcome back breznak! My pybind (replacement for swig) bindinds are working very well, I think. Have a look here:

https://github.com/chhenning/nupic/tree/master/src/cpp/nupic/python

[dkeeney]

@breznak, shall we put in pybind and isolate the python interface now or are there other smaller components you would like to put in first? I am trying to decide what part to do next.

[breznak]

Updated the description with decision based on your advices, added links to respective issues.

@dkeeney I think pybind is rather a big step, for now I'd like to align as much as possible with yours and Christian's work..so smaller pieces first, please.

1. ASAP merge Adding smart pointers and new features to ArrayBase and friends. #52 (please answer comments), and finish and merge backtracking TM  #46
2. serialization Figure serialization (remove capnproto?) #48
3. c++17 in Switch to c++17 #55
4. Region classes (should be relatively independent) Merge Region classes from dkeeney #54

[dkeeney]

I guess the next project is to remove capnproto. #48
I will take that one unless someone has already started it.

[breznak]

that'll be perfect and a big cleanup!

[breznak]

one more huge dependency dropped! Capnp removed in #62

[breznak]

With #169 we'll have most of boost includes removed,
only remaining are

• math/ArrayAlgo.hpp
• math/Math.hpp

and I'm working on those.

@dkeeney can we revisit switch to c++17 #55 and then proceed with this one?

[breznak]

Closing and moving to #106 as the only remaining part of this issue.