Initial public release of neon

.gitchangelog.rc

@@ -0,0 +1,162 @@
+##
+## Format
+##
+##   ACTION: [AUDIENCE:] COMMIT_MSG [@TAG ...]
+##
+## Description
+##
+##   ACTION is one of 'chg', 'fix', 'new'
+##
+##       Is WHAT the change is about.
+##
+##       'chg' is for refactor, small improvement, cosmetic changes...
+##       'fix' is for bug fixes
+##       'new' is for new features, big improvement
+##
+##   SUBJECT is optional and one of 'dev', 'usr', 'pkg', 'test', 'doc'
+##
+##       Is WHO is concerned by the change.
+##
+##       'dev'  is for developpers (API changes, refactors...)
+##       'usr'  is for final users (UI changes)
+##       'pkg'  is for packagers   (packaging changes)
+##       'test' is for testers     (test only related changes)
+##       'doc'  is for doc guys    (doc only changes)
+##
+##   COMMIT_MSG is ... well ... the commit message itself.
+##
+##   TAGs are additionnal adjective as 'refactor' 'minor' 'cosmetic'
+##
+##       'refactor' is obviously for refactoring code only
+##       'minor' is for a very meaningless change (a typo, adding a comment)
+##       'cosmetic' is for cosmetic driven change (re-indentation, 80-col...)
+##       'wip' is for partial functionality but complete subfunctionality.
+##
+## Example:
+##
+##   new: usr: support of bazaar implemented
+##   chg: re-indentend some lines @cosmetic
+##   new: dev: updated code to be compatible with last version of killer lib.
+##   fix: pkg: updated year of licence coverage.
+##   new: test: added a bunch of test around user usability of feature X.
+##   fix: typo in spelling my name in comment. @minor
+##
+##   Please note that multi-line commit message are supported, and only the
+##   first line will be considered as the "summary" of the commit message. So
+##   tags, and other rules only applies to the summary.  The body of the commit
+##   message will be displayed in the changelog with minor reformating.
+
+
+##
+## ``ignore_regexps`` is a line of regexps
+##
+## Any commit having its full commit message matching any regexp listed here
+## will be ignored and won't be reported in the changelog.
+##
+ignore_regexps = [
+        r'@minor', r'!minor',
+        r'@cosmetic', r'!cosmetic',
+        r'@refactor', r'!refactor',
+        r'@wip', r'!wip',
+        r'^([cC]hg|[fF]ix|[nN]ew)\s*:\s*[p|P]kg:',
+        r'^([cC]hg|[fF]ix|[nN]ew)\s*:\s*[d|D]ev:',
+        r'^(.{3,3}\s*:)?\s*[fF]irst commit.?\s*$',
+  ]
+
+
+##
+## ``replace_regexps`` is a dict associating a regexp pattern and its replacement
+##
+## It will be applied to get the summary line from the full commit message.
+##
+## Note that you can provide multiple replacement patterns, they will be all
+## tried. If None matches, the summary line will be the full commit message.
+##
+replace_regexps = {
+    ## current format (ie: 'chg: dev: my commit msg @tag1 @tag2')
+
+    r'^([cC]hg|[fF]ix|[nN]ew)\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n@]*)(@[a-z]+\s+)*$':
+  r'\4',
+}
+
+
+## ``section_regexps`` is a list of 2-tuples associating a string label and a
+## list of regexp
+##
+## Commit messages will be classified in sections thanks to this. Section
+## titles are the label, and a commit is classified under this section if any
+## of the regexps associated is matching.
+##
+section_regexps = [
+    ('New', [
+  r'^[nN]ew\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',
+     ]),
+    ('Changes', [
+        r'^[cC]hg\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',
+     ]),
+    ('Fix', [
+        r'^[fF]ix\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',
+     ]),
+
+    ('Modifications', None ## Match all lines
+     ),
+
+]
+
+
+## ``body_split_regexp`` is a regexp
+##
+## Commit message body (not the summary) if existing will be split
+## (new line) on this regexp
+##
+body_split_regexp = r'\n(?=\w+\s*:)'
+
+
+## ``tag_filter_regexp`` is a regexp
+##
+## Tags that will be used for the changelog must match this regexp.
+##
+#tag_filter_regexp = r'^[0-9]+\.[0-9]+(\.[0-9]+)?$'
+tag_filter_regexp = r'v[0-9]+\.[0-9]+(\.[0-9]+)?'
+
+
+## ``unreleased_version_label`` is a string
+##
+## This label will be used as the changelog Title of the last set of changes
+## between last valid tag and HEAD if any.
+#unreleased_version_label = "%%version%% (unreleased)"
+unreleased_version_label = "(unreleased)"
+
+
+## ``output_engine`` is a callable
+##
+## This will change the output format of the generated changelog file
+##
+## Available choices are:
+##
+##   - rest_py
+##
+##        Legacy pure python engine, outputs ReSTructured text.
+##        This is the default.
+##
+##   - mustache(<template_name>)
+##
+##        Template name could be any of the available templates in
+##        ``templates/mustache/*.tpl``.
+##        Requires python package ``pystache``.
+##        Examples:
+##           - mustache("markdown")
+##           - mustache("restructuredtext")
+##
+##   - makotemplate(<template_name>)
+##
+##        Template name could be any of the available templates in
+##        ``templates/mako/*.tpl``.
+##        Requires python package ``mako``.
+##        Examples:
+##           - makotemplate("restructuredtext")
+##
+#output_engine = rest_py
+#output_engine = mustache("restructuredtext")
+output_engine = mustache("markdown")
+#output_engine = makotemplate("restructuredtext")

.gitignore

@@ -0,0 +1,19 @@
+neon.sublime-project
+neon.sublime-workspace
+*.pyc
+*.pkl
+*.so
+*.swp
+.DS_Store
+.tox
+neon.egg-info
+src
+build
+neon/version.py
+MANIFEST
+dist
+doc/source/generated
+*@eaDir
+.pkgs/
+hosts
+neon/hyperopt/expt

CONTRIBUTING.rst

@@ -0,0 +1,125 @@
+.. ---------------------------------------------------------------------------
+.. Copyright 2014 Nervana Systems Inc.
+.. Licensed under the Apache License, Version 2.0 (the "License");
+.. you may not use this file except in compliance with the License.
+.. You may obtain a copy of the License at
+..
+..      http://www.apache.org/licenses/LICENSE-2.0
+..
+.. Unless required by applicable law or agreed to in writing, software
+.. distributed under the License is distributed on an "AS IS" BASIS,
+.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+.. See the License for the specific language governing permissions and
+.. limitations under the License.
+.. ---------------------------------------------------------------------------
+
+neon Contribution Process
+-------------------------
+
+1. File an issue:
+
+   * Create an issue on github:
+     https://github.com/NervanaSystems/neon/issues
+
+2. Clone and/or update your checked out copy of neon to ensure you have the
+   most recent commits from the master branch:
+
+.. code-block:: bash
+
+    git clone https://github.com/NervanaSystems/neon.git
+    cd neon
+    git fetch origin
+    git checkout master
+    git pull
+
+3. Create a new feature branch for your work and switch to it.  Give it a
+   meaningful name related to the task(s) at hand:
+
+.. code-block:: bash
+
+    # to do both steps at once:
+    git checkout -b my_new_feature_branch
+    # or separately:
+    git branch my_new_feature_branch
+    git checkout my_new_feature_branch
+
+4. Locally build neon, with your build type configured (eg. with GPU):
+
+.. code-block:: bash
+
+    # to setup your build type defaults for all future commands, edit setup.cfg
+    vi setup.cfg
+    make develop
+    # or
+    make build
+    # or override for a specific command
+    make -e DEV=1 DIST=1 GPU=cudanet develop
+
+5. Ideally you'd start by creating one or more unit tests with the
+   functionality you expect your new feature to perform.  These should reside
+   under the appropriate tests subdirectory of whatever you are changing.
+   Then hack away at the code until you feel your feature is complete.  Once
+   satisfied, run the code through the tests and various style checking:
+
+.. code-block:: bash
+
+    make test   # ensure all are OK for each of your build types
+    make sanity # again ensure all pass OK
+    make style  # ensure there are no style related issues
+    make speed  # ensure there are no performance regressions
+    make grad   # ensure sample gradient checks all pass OK
+    make lint   # (optional).  We still have a fair bit to clean up currently!
+
+6. If necessary you may want to update and/or rebuild the documentation.
+   This all exists under doc/source and is in 
+   `Sphinx Restructed Text format <http://sphinx-doc.org/rest.html>`_:
+
+.. code-block:: bash
+
+    make doc         # builds documentation locally
+
+7. Commit your changes and push your feature branch to ypur github fork.  Be
+   sure to add a descriptive message and reference the github issue associated
+   with your task (ex. #1).  You can create a sequence of separate commits in
+   this manner if your task is better broken down into separate components:
+
+.. code-block:: bash
+
+    git add my_updated_file.txt
+    git commit -m "Added new awesome functionality.  Closes issue #1"
+    git push origin my_new_feature_branch
+
+8. Create a new pull request to get your feature branch merged into master for
+   others to use.  You'll first need to ensure your feature branch contains the
+   latest changes from master.  Furthermore, internal devs will need to assign
+   the request to someone else for a code review.  You should also ensure all
+   your tests pass when run through the items defined in step 5.
+
+.. code-block:: bash
+
+    # (external contribs): make a new pull request:
+    https://github.com/NervanaSystems/neon/pulls
+
+    # merge latest master changes into your feature branch
+    git fetch origin
+    git checkout master
+    git pull origin master
+    git checkout my_new_feature_branch
+    git merge master  # you may need to manually resolve any merge conflicts
+
+9. If there are issues you can continue to push commits to your feature branch
+   by following step 7.  They will automatically be added to this same merge
+   request.
+
+8. Once your change has been successfully merged, you can remove the source
+   branch and ensure your local copy is up to date:
+
+.. code-block:: bash
+
+    git fetch origin
+    git checkout master
+    git pull
+    git branch -d my_new_feature_branch
+    git branch -d -r origin/my_new_feature_branch
+
+9. Give yourself a high five for a job well done!

ChangeLog

@@ -0,0 +1,10 @@
+# Changelog
+
+## (unreleased)
+
+
+## v0.8.1 (2015-05-03)
+
+### Modifications
+
+* Initial public release of neon [Scott Leishman]