Merge pull request #14 from cupy/rename-chainer

Fix document

README.md

@@ -74,11 +74,11 @@ And then, reinstall CuPy.
 ## Run with Docker
 
 We provide the official Docker image.
-Use [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) command to run Chainer image with GPU.
+Use [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) command to run CuPy image with GPU.
 You can login to the environment with bash, and run the Python interpreter.
 
 ```
-$ nvidia-docker run -it chainer/chainer /bin/bash
+$ nvidia-docker run -it cupy/cupy /bin/bash
 ```
 
 
@@ -96,8 +96,8 @@ The Twenty-ninth Annual Conference on Neural Information Processing Systems (NIP
 - Official site: (to be appeared)
 - Official document: http://docs.cupy.chainer.org/
 - github: https://github.com/cupy/cupy
-- Forum: https://groups.google.com/forum/#!forum/chainer
-- Forum (Japanese): https://groups.google.com/forum/#!forum/chainer-jp
+- Forum: https://groups.google.com/forum/#!forum/cupy
+- Forum (Japanese): https://groups.google.com/forum/#!forum/cupy-ja
 - Twitter: https://twitter.com/ChainerOfficial
 - Twitter (Japanese): https://twitter.com/chainerjp
 - Research projects using Chainer: https://github.com/pfnet/chainer/wiki/Research-projects-using-Chainer

docs/source/compatibility.rst

@@ -1,26 +1,19 @@
 API Compatibility Policy
 ========================
 
-This document expresses the design policy on compatibilities of Chainer APIs.
+This document expresses the design policy on compatibilities of CuPy APIs.
 Development team should obey this policy on deciding to add, extend, and change APIs and their behaviors.
 
 This document is written for both users and developers.
-Users can decide the level of dependencies on Chainer’s implementations in their codes based on this document.
+Users can decide the level of dependencies on CuPy’s implementations in their codes based on this document.
 Developers should read through this document before creating pull requests that contain changes on the interface.
 Note that this document may contain ambiguities on the level of supported compatibilities.
 
 
-Targeted Versions
------------------
-
-This policy is applied to Chainer of versions v1.5.1 and higher.
-Note that this policy is not applied to Chainer of lower versions.
-
-
 Versioning and Backward Compatibilities
 ---------------------------------------
 
-The updates of Chainer are classified into three levels: major, minor, and revision.
+The updates of CuPy are classified into three levels: major, minor, and revision.
 These types have distinct levels of backward compatibilities.
 
 - **Major update** contains disruptive changes that break the backward compatibility.
@@ -68,40 +61,6 @@ The actual change should be done in the following steps:
 - At the major update announced in the above update, change the API.
 
 
-.. module:: chainer.utils
-
-Experimental APIs
------------------
-
-Thanks to many contributors, we have introduced many new features to Chainer.
-
-However, we have sometimes released new features only to later notice that their APIs are not appropriate.
-The objective of experimental APIs is to avoid such issues by allowing the developer to mark any newly added API as experimental.
-
-Any newly added API can be marked as *experimental*.
-Any API that is not experimental is called *stable* in this document.
-
-.. note::
-    Undocumented behaviors are not considered as APIs. So they are not experimental nor stable.
-    The treatment of undocumented behaviors are descibed in :ref:`undocumented_behavior` section.
-
-Chainer can change the interfaces and documents of experimental APIs at **any** version up.
-This change is not considered as a break of backward compatibility.
-Chainer can promote an experimental API to become stable at any **minor** or **major** version up.
-Once experimental APIs become stable, they cannot revert to experimental again.
-
-When users use experimental APIs for the first time, warnings are raised once for each experimental API,
-unless users explicitly disable the emission of the warnings in advance.
-
-See the document of :meth:`chainer.utils.experimental` how developers mark APIs as experimental
-and how users enable or disable the warnings practically.
-
-.. note::
-   It is up to developers if APIs should be annotated as experimental or not.
-   We recommend to make the APIs experimental if they implement large modules or
-   make a decision from several design choices.
-
-
 Supported Backward Compatibility
 --------------------------------
 
@@ -110,7 +69,7 @@ This section defines backward compatibilities that minor updates must maintain.
 Documented Interface
 ~~~~~~~~~~~~~~~~~~~~
 
-Chainer has the official API documentation.
+CuPy has the official API documentation.
 Many applications can be written based on the documented features.
 We support backward compatibilities of documented features.
 In other words, codes only based on the documented features run correctly with minor/revision-updated versions.
@@ -123,7 +82,7 @@ For example, attributes outside of the documented APIs should have one or more u
 Undocumented behaviors
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Behaviors of Chainer implementation not stated in the documentation are undefined.
+Behaviors of CuPy implementation not stated in the documentation are undefined.
 Undocumented behaviors are not guaranteed to be stable between different minor/revision versions.
 
 Minor update may contain changes to undocumented behaviors.
@@ -170,16 +129,6 @@ No exception is raised in the future versions with correct usages that the docum
 On the other hand, warnings may be added at any minor updates for any APIs.
 It means minor updates do not keep backward compatibility of warnings.
 
-Model Format Compatibility
---------------------------
-
-Objects serialized by official serializers that Chainer provides are correctly loaded with the higher (future) versions.
-They might not be correctly loaded with Chainer of the lower versions.
-
-.. note::
-   Current serialization APIs do not support versioning (at least in v1.6.1).
-   It prevents us from introducing changes in the layout of objects that support serialization.
-   We are discussing about introducing versioning in serialization APIs.
 
 Installation Compatibility
 --------------------------
@@ -196,6 +145,6 @@ We support environmental compatibilities in the following ways.
 - Supporting optional packages/libraries may be done in minor updates (e.g. supporting h5py in optional features).
 
 .. note::
-   The installation compatibility does not guarantee that all the features of Chainer correctly run on supported environments.
+   The installation compatibility does not guarantee that all the features of CuPy correctly run on supported environments.
    It may contain bugs that only occurs in certain environments.
    Such bugs should be fixed in some updates.

docs/source/contribution.rst

@@ -12,7 +12,7 @@ There are several ways to contribute to CuPy community:
 
 1. Registering an issue
 2. Sending a pull request (PR)
-3. Sending a question to `Chainer User Group <https://groups.google.com/forum/#!forum/chainer>`_
+3. Sending a question to `CuPy User Group <https://groups.google.com/forum/#!forum/cupy>`_
 4. Writing a post about CuPy
 
 This document mainly focuses on 1 and 2, though other contributions are also appreciated.
@@ -64,9 +64,9 @@ You can contain your thoughts on **how** to realize it into the feature requests
 
 .. warning::
 
-   If you have a question on usages of CuPy, it is highly recommended to send a post to `Chainer User Group <https://groups.google.com/forum/#!forum/chainer>`_ instead of the issue tracker.
+   If you have a question on usages of CuPy, it is highly recommended to send a post to `CuPy User Group <https://groups.google.com/forum/#!forum/cupy>`_ instead of the issue tracker.
    The issue tracker is not a place to share knowledge on practices.
-   We may redirect question issues to Chainer User Group.
+   We may redirect question issues to CuPy User Group.
 
 If you can write code to fix an issue, send a PR to the master branch.
 Before writing your code for PRs, read through the :ref:`coding-guide`.
@@ -170,11 +170,6 @@ For example, if you have only one GPU, launch ``nosetests`` by the following com
 
   $ nosetests path/to/gpu/test.py --eval-attr='gpu<2'
 
-Some tests spend too much time.
-If you want to skip such tests, pass ``--attr='!slow'`` option to the ``nosetests`` command::
-
-  $ nosetests path/to/your/test.py --attr='!slow'
-
 Tests are put into the ``tests/cupy_tests`` and ``tests/install_tests`` directories.
 These have the same structure as that of ``cupy`` and ``install`` directories, respectively.
 In order to enable test runner to find test scripts correctly, we are using special naming convention for the test subdirectories and the test scripts.
@@ -235,24 +230,7 @@ In order to write tests for multiple GPUs, use ``cupy.testing.attr.multi_gpu()``
       def test_my_two_gpu_func(self):
           ...
 
-If your test requires too much time, add ``chainer.testing.attr.slow`` decorator.
-The test functions decorated by ``slow`` are skipped if ``--attr='!slow'`` is given::
-
-  import unittest
-  from chainer.testing import attr
-
-  class TestMyFunc(unittest.TestCase):
-      ...
-
-      @attr.slow
-      def test_my_slow_func(self):
-          ...
-
-.. note::
-   If you want to specify more than two attributes, separate them with a comma such as ``--attr='!gpu,!slow'``.
-   See detail in `the document of nose <https://nose.readthedocs.io/en/latest/plugins/attrib.html#simple-syntax>`_.
-
-Once you send a pull request, your code is automatically tested by `Travis-CI <https://travis-ci.org/pfnet/cupy/>`_ **with --attr='!gpu,!slow' option**.
+Once you send a pull request, your code is automatically tested by `Travis-CI <https://travis-ci.org/cupy/cupy/>`_ **with --attr='!gpu,!slow' option**.
 Since Travis-CI does not support CUDA, we cannot check your CUDA-related code automatically.
 The reviewing process starts after the test passes.
 Note that reviewers will test your code without the option to check CUDA-related code.

docs/source/cupy-reference/environment.rst

@@ -1,7 +1,7 @@
 Environment variables
 =====================
 
-Here are the environment variables Chainer uses.
+Here are the environment variables CuPy uses.
 
 
 +--------------------+----------------------------------------------------+

docs/source/cupy-reference/overview.rst

@@ -8,7 +8,7 @@ CuPy Overview
 CuPy is an implementation of NumPy-compatible multi-dimensional array on CUDA.
 CuPy consists of the core multi-dimensional array class, :class:`cupy.ndarray`,
 and many functions on it. It supports a subset of :class:`numpy.ndarray`
-interface that is enough for Chainer.
+interface that is enough for `Chainer <http://chainer.org/>`_.
 
 The following is a brief overview of supported subset of NumPy interface:
 
@@ -390,7 +390,7 @@ Statistics
 :func:`bincount`
 
 Padding
-~~~~~~~~~~
+~~~~~~~
 
 :func:`pad`
 

docs/source/install.rst

@@ -182,7 +182,7 @@ Run CuPy with Docker
 -----------------------
 
 We provide the official Docker image.
-Use `nvidia-docker <https://github.com/NVIDIA/nvidia-docker>`_ command to run Chainer image with GPU.
+Use `nvidia-docker <https://github.com/NVIDIA/nvidia-docker>`_ command to run CuPy image with GPU.
 You can login to the environment with bash, and run the Python interpreter::
 
   $ nvidia-docker run -it cupy/cupy /bin/bash