New directions with refactored code

[MichaelCurrie]

[Copied from @JimHokanson 's comments, so this remains an open issue.]

Some thoughts on going forward:

1. The new code needs documentation.
2. Might populate WormFeatures with NormalizedWorm values as non-user-requested features and then make requests for these features like we do other dependencies.
3. Need to build in support for missing dependencies. This code has been started but needs some work. It would be good to knock out the contour and then make sure things can fail gracefully.
4. Event signing and filtering could be done in a separate feature manipulation. It was sort of a hack to do this in the feature expansion code.
5. I'm not sure the statistics are being calculated correctly, this needs to be looked at.
6. Histograms need to always be created instead of sometimes returning None
7. There are lots of TODOs in the code that should be made into issues

[cheelee]

I'm in the process of trying to get all the dependencies together on my Mac OS X machine (which is slightly different from the Linux instructions given) under virtualenvwrapper (with the exception of opencv.) Maybe I can take a shot at getting automatic python dependency set up? I can also try other scripting approaches (Makefile or CMAKE) to pull in other non-python dependencies.

[MichaelCurrie]

Hi @cheelee, sounds good. One idea is to first see if you can get it to build on Mac OS and then maybe add Mac instructions to the INSTALL.md. That would be a great start.

[cheelee]

Will do. I'll take the opportunity to ask questions about the workflow and use-cases for the code base outside of the tests and examples as I try this. Thanks!

[cheelee]

Ok, I've got all the steps in INSTALL.md adapted to OS X and I'm just waiting on some clarification on the sudo steps used for configuring opencv before I try out the .mat examples I've downloaded via the INSTALL.md instructions. I have a more-or-less complete INSTALL-OSX.md file documenting the process that I can check in once I successfully test the examples. After that happens, I'll look into automatically handling the python dependencies, which theoretically should just check for an exit code from conda.

Meanwhile is the group comfortable working directly with the master branch? Or should we create a dev branch for contributors to make pull requests into, which then gets eventually merged into master whenever we are ready to make official OWAT releases?

I'm personally working on my own fork, with the group's repository set as upstream.

[MichaelCurrie]

Best practice is to do work in a throwaway branch, then create a pull request. Try to merge back to or pull from master often to avoid extra work merging later, if you're working on a part that others are also working on. In other words, sounds like you're already doing the right thing!