Merging latest from develop

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,93 @@
+# Code of Conduct
+
+> A code of conduct is a set of rules outlining the social norms and rules and responsibilities of, or proper practices for, an individual, party or organization
+
+## Summary
+
+Shapelets is dedicated to providing a harassment-free working environment for all, regardless of gender, sexual orientation, disability, physical appearance, body size, race, or religion. We do not tolerate harassment of any form. All communication should be appropriate for a professional audience including people of many different backgrounds. 
+
+Sexual language and imagery is not appropriate for any communication and/or talks. Be kind and do not insult or put down others. Behave professionally. Remember that harassment and sexist, racist, or exclusionary jokes are not appropriate for Shapelets. Staff violating these rules should be reported to an appropriate line manager.
+
+These are the values to which people in the Shapelets community should aspire:
+
+- Be friendly and welcoming
+- Be patient
+  - Remember that people have varying communication styles and that not everyone is using their native language. (Meaning and tone can be lost in translation.) 
+- Be thoughtful
+  - Productive communication requires effort. Think about how your words will be interpreted.
+  - Remember that sometimes it is best to refrain entirely from commenting. 
+- Be respectful
+  - In particular, respect differences of opinion. 
+- Be charitable
+  - Interpret the arguments of others in good faith, do not seek to disagree.
+  - When we do disagree, try to understand why. 
+- Avoid destructive behavior:
+  - Derailing: stay on topic; if you want to talk about something else, start a new conversation.
+  - Unconstructive criticism: don't merely decry the current state of affairs; offer—or at least solicit—suggestions as to how things may be improved.
+  - Snarking (pithy, unproductive, sniping comments)
+  - Discussing potentially offensive or sensitive issues; this all too often leads to unnecessary conflict.
+  - Microaggressions: brief and commonplace verbal, behavioral and environmental indignities that communicate hostile, derogatory or negative slights and insults to a person or group. 
+
+People are complicated. You should expect to be misunderstood and to misunderstand others; when this inevitably occurs, resist the urge to be defensive or assign blame. Try not to take offense where no offense was intended. Give people the benefit of the doubt. Even if the intent was to provoke, do not rise to it. It is the responsibility of all parties to de-escalate conflict when it arises. 
+
+## Reporting an incident
+
+Incidents that violate the Code of Conduct are extremely damaging to Shapelets, and they will not be tolerated. The silver lining is that, in many cases, these incidents present a chance for the offenders, and the teams at large, to grow, learn, and become better. 
+
+> The following should be handled by a line manager who has been informed of the incident
+
+Try to get as much of the incident in written form. The important information to gather include the following:
+
+- Name and team of the participant doing the harassing
+- The location in which the incident occurred
+- The behavior that was in violation
+- The approximate time of the behavior
+- The circumstances surrounding the incident
+- Other people involved in the incident
+
+Depending on the severity/details of the incident, please follow these guidelines:
+
+- If there is any general threat to staff or any other doubts, summon security or police
+- Offer the victim a private place to sit
+- Ask "is there a friend or trusted person who you would like to be with you?" (if so, arrange for someone to fetch this person)
+- Ask them "how can I help?"
+- Provide them with your list of emergency contacts if they need help later
+- If everyone is presently physically safe, involve the police or security only at a victim's request
+
+There are also some guidelines as to what not to do as an initial response:
+
+- Do not overtly invite them to withdraw the complaint or mention that withdrawal is OK. This suggests that you want them to do so, and is therefore coercive. "If you're OK with pursuing the complaint" suggests that you are by default pursuing it and is not coercive.
+- Do not ask for their advice on how to deal with the complaint. This is a staff responsibility.
+- Do not offer them input into penalties. This is the staff's responsibility.
+
+The line manager who is handling the reported offence should find out the following:
+
+- What happened?
+- Are we doing anything about it?
+- Who is doing those things?
+- When are they doing them?
+
+After the above has been identified and discussed, have an appropriate line manager communicate with the alleged harasser. Make sure to inform them of what has been reported about them.
+
+Allow the alleged harasser to give their side of the story. After this point, if the report stands, let the alleged harasser know what actions will be taken against them.
+
+Some things for the staff to consider when dealing with Code of Conduct offenders:
+
+- Warning the harasser to cease their behaviour and that any further reports will result in sanctions
+- Requiring that the harasser avoid any interaction with, and physical proximity to, their victim until a resolution or course of action has been decided upon
+- Requiring that the harasser not volunteer for future events your organisation runs (either indefinitely or for a certain time period)
+- Depending on the severity/details of the incident, requiring that the harasser immediately be sent home
+- Depending on the severity/details of the incident, removing a harasser from membership of relevant Shapelets organisations
+- Depending on the severity/details of the incident, publishing an account of the harassment and calling for the resignation of the harasser from their responsibilities (usually pursued by people without formal authority: may be called for if the harasser is a team leader, or refuses to stand aside from the conflict of interest)
+
+Give accused staff members a place to appeal to if there is one, but in the meantime the report stands. Keep in mind that it is not a good idea to encourage an apology from the harasser.
+
+It is very important how we deal with the incident publicly. Our policy is to make sure that everyone aware of the initial incident is also made aware that it is not according to policy and that official action has been taken - while still respecting the privacy of individual staff members. When speaking to individuals (those who are aware of the incident, but were not involved with the incident) about the incident it is a good idea to keep the details out.
+
+Depending on the incident, the head of responsible department, or designate, may decide to make one or more public announcements. If necessary, this will be done with a short announcement either during the plenary and/or through other channels. No one other than the head of responsible department or someone delegated authority from them should make any announcements. No personal information about either party will be disclosed as part of this process.
+
+If some members of staff were angered by the incident, it is best to apologise to them that the incident occurred to begin with. If there are residual hard feelings, suggest to them to write an email to the responsible head of department. It will be dealt with accordingly.
+
+## Attribution
+
+This Code of Conduct was adapted from both [Golang](https://golang.org/conduct) an the [Golang UK Conference](http://golanguk.com/conduct/).

.github/CONTRIBUTING.md

@@ -0,0 +1,84 @@
+# Contributing
+
+Contributions are welcome and are greatly appreciated! Every
+little bit helps, and credit will always be given.
+
+
+# Table of Contents
+  * [Formatting Style](#formatting-style)
+  * [Branching model](#branching-model)
+  * [Contribution process](#contribution-process)
+  * [Types of Contributions](#types-of-contributions)
+      - [Report Bugs](#report-bugs)
+      - [Fix Bugs](#fix-bugs)
+      - [Implement Features](#implement-features)
+      - [Improve Documentation](#improve-documentation)
+      - [Submit Feedback](#submit-feedback)
+  * [Documentation](#documentation)
+  * [Development and Testing](#development-and-testing)
+      - [Set up a development env using Docker](#set-up-a-development-env-using-docker)
+
+## Formatting Style
+
+In order to have a standarised code base, we only accept code that is formatted according to the Google rules for C++ with a column width of 120 characters and an identation of 4 whitespaces. For this purpose, we use `clang-format`, which can be installed in MacOs by executing the next command: `brew install clang-format`.
+We use the `clang-format` plugin for the VS Code editor to format our codes. This plugin uses the `clang-format` program and the aforementioned rules under the hood.
+
+## Branching model
+
+Our branching model has two permanent branches, **develop** and **master**. We aim at using `develop` as the main branch, where all features are merged. In this sense, we use the master branch to push the release versions of the Khiva library.
+
+## Contribution process
+
+In order to contribute to the code base, we follow the next process :
+1. The main branch is develop, every developer should pull the current status of the branch before stating to develop any new feature.
+`git pull`
+1. Create a new branch with the following pattern "feature/[name_of_the_feature]"
+`git checkout -b feature/example_feature`
+3. Develop the new feature on the the new branch. It includes testing and documentation.
+`git commit -a -m "Bla, Bla, Bla";  git push`
+4. Open a Pull Request to merge the feature branch in to develop. Currently, a pull request has to be reviewed at least by one person.
+5. Finally, delete the feature branch.
+6. Move back to develop branch.
+`git checkout develop`
+7. Pull the latest changes.
+`git pull`
+
+## Types of Contributions
+
+### Report Bugs
+
+Report bugs through [GitHub issues](https://github.com/shapelets/khiva/issues)
+
+Please follow the project issue template to exhibit the problem.
+
+### Fix Bugs
+
+Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it.
+
+### Implement Features
+
+Look through the [GitHub issues](https://github.com/shapelets/khiva/issues) for feature requests. Any unassigned "Improvement" issue is open to whoever wants to implement it.
+
+We have included an initial set of algorithms, but feel free to add any new one(s).
+
+### Improve Documentation
+
+Khiva could always use better documentation, whether as part of the official Khiva docs,
+`doc/sphinx/source/*.rst` or even description of the methods in the different namespaces.
+
+### Submit Feedback
+
+The best way to send feedback is to open an issue on [GitHub issues](https://github.com/shapelets/khiva/issues)
+
+If you are proposing a feature, please follow the feature request template.
+
+## Development and Testing
+
+### Set up a development env using Docker
+
+Start a new docker container.
+
+```
+# Start docker
+docker run -ti shapelets/khiva 
+```

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,25 @@
+---
+name: Bug report
+about: Create a report to help us improve
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior, at minimum a code snippet containing the steps which produced the error, and preferably a project with :
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Environment information:**
+ - OS: [e.g. Mac OS]
+ - Version [e.g. 10.13]
+ - Khiva dependencies versions [e.g. ArrayFire 3.5.1, Boost 1.66.0]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,31 @@
+Make sure you have checked _all_ steps below.
+
+
+### Description
+- [ ] Here are some details about my PR, including screenshots of any UI changes:
+
+
+### Tests
+- [ ] My PR adds the following unit tests __OR__ does not need testing for this extremely good reason:
+
+
+### Benchmarks
+- [ ] My PR adds the following micro benchmarks __OR__ does not need benchmarks for this extremely good reason:
+
+
+### Commits
+- [ ] My commits have been squashed if they address the same issue. In addition, my commits follow the guidelines from "[How to write a good git commit message](http://chris.beams.io/posts/git-commit/)":
+    1. Subject is separated from body by a blank line
+    2. Subject is limited to 50 characters
+    3. Subject does not end with a period
+    4. Subject uses the imperative mood ("add", not "adding")
+    5. Body wraps at 72 characters
+    6. Body explains "what" and "why", not "how"
+
+
+## License
+- [ ] Add a [Mozilla Public License 2.0 license header](http://mozilla.org/MPL/2.0/) to all the new files.
+
+
+### Documentation
+- [ ] In case of new functionality, my PR adds documentation that describes how to use it.

.gitignore

@@ -1,9 +1,6 @@
 bin
 build
 .DS_Store
-conanbuildinfo.cmake
-conanbuildinfo.txt
-conaninfo.txt
 *.cmake
 *CMakeFiles*
 *Makefile

CMakeLists.txt

@@ -12,14 +12,10 @@ SET_PROPERTY(GLOBAL PROPERTY USE_FOLDERS ON)
 # Using C++ 11
 SET(CMAKE_CXX_STANDARD 11)
 
-# Bring conan generated dependencies
-INCLUDE(conanbuildinfo.cmake)
-CONAN_BASIC_SETUP()
-
 # Load from environment variables
-SET(CMAKE_MODULE_PATH $ENV{CMAKE_MODULE_PATH})
-SET(CMAKE_PREFIX_PATH $ENV{CMAKE_PREFIX_PATH})
-SET(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
+LIST(APPEND CMAKE_MODULE_PATH $ENV{CMAKE_MODULE_PATH})
+LIST(APPEND CMAKE_PREFIX_PATH $ENV{CMAKE_PREFIX_PATH})
+LIST(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
 
 # Set the build type
 IF(NOT CMAKE_BUILD_TYPE)
@@ -28,6 +24,31 @@ IF(NOT CMAKE_BUILD_TYPE)
       FORCE)
 ENDIF()
 
+# Compile-time options
+OPTION(KHIVA_BUILD_TESTS "Build tests of the Khiva library" ON)
+OPTION(KHIVA_BUILD_BENCHMARKS "Build benchmarks of the Khiva library" ON)
+OPTION(KHIVA_BUILD_EXAMPLES "Build examples of the Khiva library" ON)
+OPTION(KHIVA_BUILD_DOCUMENTATION "Create and install the HTML based API documentation (requires Doxygen, GraphViz and Sphinx)" ON)
+OPTION(KHIVA_USE_CONAN "Use the conan package manager to download the dependencies of the Khiva library" ON)
+
+IF(KHIVA_USE_CONAN)
+    INCLUDE(conan)
+
+    IF("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
+        SET(CONAN_CPPSTD 14)
+    ELSE()
+        SET(CONAN_CPPSTD 11)
+    ENDIF()
+    conan_cmake_run(CONANFILE conanfile.txt
+                    BASIC_SETUP CMAKE_TARGETS
+                    BUILD missing
+                    SETTINGS cppstd=${CONAN_CPPSTD})
+
+    # Bring conan generated dependencies
+    INCLUDE(${CMAKE_CURRENT_BINARY_DIR}/conanbuildinfo.cmake)
+    CONAN_BASIC_SETUP()
+ENDIF()
+
 # Set the base directory to parent so src and include become equaly visible
 SET(KHIVALIB_BASE_DIR ${PROJECT_SOURCE_DIR})
 # Define source directory
@@ -38,7 +59,7 @@ SET(KHIVALIB_INC "${KHIVALIB_BASE_DIR}/include/")
 SET(KHIVALIB "khiva")
 
 # Bring KHIVA version and installation directories
-INCLUDE(Version)
+INCLUDE(KhivaVersion)
 INCLUDE(KhivaInstallDirs)
 
 SET(PROJECT_VERSION ${VERSION_SHORT})
@@ -73,25 +94,28 @@ ENDIF()
 ADD_SUBDIRECTORY(src)
 
 # build examples
-ADD_SUBDIRECTORY(examples)
+IF(KHIVA_BUILD_EXAMPLES)
+    ADD_SUBDIRECTORY(examples)
+ENDIF()
 
-# test and benchmarks
-ENABLE_TESTING()
-ADD_SUBDIRECTORY(test)
-ADD_SUBDIRECTORY(benchmarks)
+# build tests
+IF(KHIVA_BUILD_TESTS)
+    ENABLE_TESTING()
+    ADD_SUBDIRECTORY(test)
+ENDIF()
+
+# build benchmarks
+IF(KHIVA_BUILD_BENCHMARKS)
+    ADD_SUBDIRECTORY(benchmarks)
+ENDIF()
 
 # build bindings for c and jni
 ADD_SUBDIRECTORY(bindings)
 
 # build items in subdirectories
-ADD_SUBDIRECTORY(doc)
-
-INSTALL(DIRECTORY examples/
-    DESTINATION ${KHIVA_INSTALL_EXAMPLE_DIR}
-    COMPONENT examples
-    FILES_MATCHING
-    PATTERN "*.cpp"
-    PATTERN "*.h")
+IF(KHIVA_BUILD_DOCUMENTATION)
+    ADD_SUBDIRECTORY(doc)
+ENDIF()
 
 INSTALL(DIRECTORY licenses/
     DESTINATION ${KHIVA_INSTALL_LICENSES_DIR}