Fix typos and update documentation

Co-Authored-By: Ngô Ngọc Đức Huy <duchuy29092000@gmail.com>
This commit is contained in:
Nguyễn Gia Phong 2020-05-02 23:01:52 +07:00
parent 2f50c5e0c2
commit 064aeb7099
14 changed files with 66 additions and 41 deletions

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@ -47,9 +47,9 @@ requested by someone who requires them.
Submitting a Patch
------------------
We except all kinds of patches, from documentation and CI/CD setup
We accept all kinds of patches, from documentation and CI/CD setup
to bug fixes, feature implementations and tests. Except for documentation
located in the ``gh-pages`` branch, others are should be filed against
located in the ``gh-pages`` branch, others should be filed against
the development branch ``master``. These are hosted on GitHub and
one may create a local repository by running::
@ -59,7 +59,7 @@ While the patch can be submitted via email, it is preferable to file
a pull request on GitHub to allow more people to review it, since we do not
have any mail list. Either way, contributors must have legal permission
to distribute the code and it must be available under `LGPLv3+`_. Furthermore,
each contributor retain the copyrights of their patch, to ensure that
each contributor retains the copyrights of their patch, to ensure that
the licence can never be revoked even if others wants to. It is advisable
that the author list per legal name under the copyright header
of each source file they modify, like so::
@ -89,6 +89,11 @@ Using GitHub
#. Add_, commit_ with `a great message`_ then push_ the result.
#. Finally, `create a pull request`_. We will then review and merge it.
It is recommended to create a new branch in your fork
(``git checkout -c what-you-are-working-on``) instead of working directly
on ``master``. This way one can still sync per fork with our ``master`` branch
and ``git pull --rebase upstream master`` to avoid integration issues.
Via Email
^^^^^^^^^
@ -142,12 +147,12 @@ reStructuredText
In order for reStructuredText to be rendered correctly, the body of
constructs beginning with a marker (lists, hyperlink targets, comments, etc.)
must be aligned relative to the marker. For this reason, it's is convenient
must be aligned relative to the marker. For this reason, it is convenient
to set your editor indentation level to 3 spaces, since most constructs
starts with two dots and a space. However, be aware of that bullet items
require 2-space alignment and other exceptions.
Limits all lines to a maximum of 79 characters. Similar to comments
Limit all lines to a maximum of 79 characters. Similar to comments
and docstrings, phrases should not be broken in the middle.
The source code of this guide itself is a good example on how line breaks
should be handled. Additionally, two spaces should also be used

View File

@ -1,6 +1,12 @@
Copying
=======
This listing is our best-faith, hard-work effort at accurate attribution,
sources, and licenses for everything in palace. If you discover
an asset/contribution that is incorrectly attributed or licensed,
please contact us immediately. We are happy to do everything we can
to fix or remove the issue.
License
-------
Palace is free software: you can redistribute it and/or modify it
@ -42,7 +48,7 @@ the developers of Alure_ and Cython_ who promptly gave detail answers
and made quick fixes to all of our problems.
The wheels are build using cibuildwheel_, which made building wheels for
extension modules much less of a pain in the ass. `Travis CI`_ and AppVoyer_
extension modules much less of a pain in the ass. `Travis CI`_ and AppVeyor_
kindly provides there services free of charge for automated CI/CD.
This documentation is generated using Sphinx_, whose maintainer responses
@ -65,4 +71,4 @@ extreamly quickly to obsolete Cython-related issues.
.. _cibuildwheel: https://cibuildwheel.readthedocs.io/en/stable/
.. _Sphinx: https://www.sphinx-doc.org/en/master/
.. _Travis CI: https://travis-ci.com/
.. _AppVoyer: https://www.appveyor.com/
.. _AppVeyor: https://www.appveyor.com/

View File

@ -4,7 +4,7 @@ Installation
Prerequisites
-------------
Palace requires Python 3.6 for runtime and `pip`_ for installation.
Palace requires Python 3.6 for runtime and pip_ for installation.
Via PyPI
--------
@ -14,23 +14,20 @@ Palace can be installed from PyPI::
pip install palace
Wheel distributions are built exclusively for amd64. Currently, only GNU/Linux
is properly supported. If you want to help packaging for Windows and macOS,
see `GH-1`_ and `GH-63`_ respectively on our issues tracker on GitHub.
and macOS are properly supported. If you want to help packaging for Windows,
please see `GH-1`_ on our issues tracker on GitHub.
From source
-----------
Aside from the build dependencies listed in ``pyproject.toml``,
one will additionally need compatible Python headers, `alure`_,
one will additionally need compatible Python headers, alure_,
a C++14 compiler, CMake 2.6+ (and probably ``git`` for fetching the source).
Palace can then be compiled and installed by running:
.. code-block:: sh
Palace can then be compiled and installed by running::
git clone https://github.com/McSinyx/palace.git
pip install palace/
.. _pip: https://pip.pypa.io/en/latest/
.. _GH-1: https://github.com/McSinyx/palace/issues/1
.. _GH-63: https://github.com/McSinyx/palace/issues/63
.. _alure: https://github.com/kcat/alure

View File

@ -77,9 +77,9 @@ requested by someone who requires them.</p>
</div>
<div class="section" id="submitting-a-patch">
<h2>Submitting a Patch<a class="headerlink" href="#submitting-a-patch" title="Permalink to this headline"></a></h2>
<p>We except all kinds of patches, from documentation and CI/CD setup
<p>We accept all kinds of patches, from documentation and CI/CD setup
to bug fixes, feature implementations and tests. Except for documentation
located in the <code class="docutils literal notranslate"><span class="pre">gh-pages</span></code> branch, others are should be filed against
located in the <code class="docutils literal notranslate"><span class="pre">gh-pages</span></code> branch, others should be filed against
the development branch <code class="docutils literal notranslate"><span class="pre">master</span></code>. These are hosted on GitHub and
one may create a local repository by running:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clone</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">McSinyx</span><span class="o">/</span><span class="n">palace</span>
@ -89,7 +89,7 @@ one may create a local repository by running:</p>
a pull request on GitHub to allow more people to review it, since we do not
have any mail list. Either way, contributors must have legal permission
to distribute the code and it must be available under <a class="reference external" href="https://www.gnu.org/licenses/lgpl-3.0.en.html">LGPLv3+</a>. Furthermore,
each contributor retain the copyrights of their patch, to ensure that
each contributor retains the copyrights of their patch, to ensure that
the licence can never be revoked even if others wants to. It is advisable
that the author list per legal name under the copyright header
of each source file they modify, like so:</p>
@ -120,6 +120,10 @@ copyright holders need to be properly documented.</p></li>
<li><p><a class="reference external" href="https://git-scm.com/docs/git-add">Add</a>, <a class="reference external" href="https://git-scm.com/docs/git-commit">commit</a> with <a class="reference external" href="https://chris.beams.io/posts/git-commit/#seven-rules">a great message</a> then <a class="reference external" href="https://git-scm.com/docs/git-push">push</a> the result.</p></li>
<li><p>Finally, <a class="reference external" href="https://help.github.com/articles/creating-a-pull-request">create a pull request</a>. We will then review and merge it.</p></li>
</ol>
<p>It is recommended to create a new branch in your fork
(<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">checkout</span> <span class="pre">-c</span> <span class="pre">what-you-are-working-on</span></code>) instead of working directly
on <code class="docutils literal notranslate"><span class="pre">master</span></code>. This way one can still sync per fork with our <code class="docutils literal notranslate"><span class="pre">master</span></code> branch
and <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">pull</span> <span class="pre">--rebase</span> <span class="pre">upstream</span> <span class="pre">master</span></code> to avoid integration issues.</p>
</div>
<div class="section" id="via-email">
<h3>Via Email<a class="headerlink" href="#via-email" title="Permalink to this headline"></a></h3>
@ -173,11 +177,11 @@ for all public names.</p></li>
<h3>reStructuredText<a class="headerlink" href="#restructuredtext" title="Permalink to this headline"></a></h3>
<p>In order for reStructuredText to be rendered correctly, the body of
constructs beginning with a marker (lists, hyperlink targets, comments, etc.)
must be aligned relative to the marker. For this reason, its is convenient
must be aligned relative to the marker. For this reason, it is convenient
to set your editor indentation level to 3 spaces, since most constructs
starts with two dots and a space. However, be aware of that bullet items
require 2-space alignment and other exceptions.</p>
<p>Limits all lines to a maximum of 79 characters. Similar to comments
<p>Limit all lines to a maximum of 79 characters. Similar to comments
and docstrings, phrases should not be broken in the middle.
The source code of this guide itself is a good example on how line breaks
should be handled. Additionally, two spaces should also be used

View File

@ -33,6 +33,11 @@
<div class="section" id="copying">
<h1>Copying<a class="headerlink" href="#copying" title="Permalink to this headline"></a></h1>
<p>This listing is our best-faith, hard-work effort at accurate attribution,
sources, and licenses for everything in palace. If you discover
an asset/contribution that is incorrectly attributed or licensed,
please contact us immediately. We are happy to do everything we can
to fix or remove the issue.</p>
<div class="section" id="license">
<h2>License<a class="headerlink" href="#license" title="Permalink to this headline"></a></h2>
<p>Palace is free software: you can redistribute it and/or modify it
@ -106,7 +111,7 @@ the build machine, which is similar to static linking:</p>
the developers of <a class="reference external" href="https://github.com/kcat/alure">Alure</a> and <a class="reference external" href="https://cython.org/">Cython</a> who promptly gave detail answers
and made quick fixes to all of our problems.</p>
<p>The wheels are build using <a class="reference external" href="https://cibuildwheel.readthedocs.io/en/stable/">cibuildwheel</a>, which made building wheels for
extension modules much less of a pain in the ass. <a class="reference external" href="https://travis-ci.com/">Travis CI</a> and <a class="reference external" href="https://www.appveyor.com/">AppVoyer</a>
extension modules much less of a pain in the ass. <a class="reference external" href="https://travis-ci.com/">Travis CI</a> and <a class="reference external" href="https://www.appveyor.com/">AppVeyor</a>
kindly provides there services free of charge for automated CI/CD.</p>
<p>This documentation is generated using <a class="reference external" href="https://www.sphinx-doc.org/en/master/">Sphinx</a>, whose maintainer responses
extreamly quickly to obsolete Cython-related issues.</p>

View File

@ -45,8 +45,8 @@
</pre></div>
</div>
<p>Wheel distributions are built exclusively for amd64. Currently, only GNU/Linux
is properly supported. If you want to help packaging for Windows and macOS,
see <a class="reference external" href="https://github.com/McSinyx/palace/issues/1">GH-1</a> and <a class="reference external" href="https://github.com/McSinyx/palace/issues/63">GH-63</a> respectively on our issues tracker on GitHub.</p>
and macOS are properly supported. If you want to help packaging for Windows,
please see <a class="reference external" href="https://github.com/McSinyx/palace/issues/1">GH-1</a> on our issues tracker on GitHub.</p>
</div>
<div class="section" id="from-source">
<h2>From source<a class="headerlink" href="#from-source" title="Permalink to this headline"></a></h2>
@ -54,8 +54,8 @@ see <a class="reference external" href="https://github.com/McSinyx/palace/issues
one will additionally need compatible Python headers, <a class="reference external" href="https://github.com/kcat/alure">alure</a>,
a C++14 compiler, CMake 2.6+ (and probably <code class="docutils literal notranslate"><span class="pre">git</span></code> for fetching the source).
Palace can then be compiled and installed by running:</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>git clone https://github.com/McSinyx/palace.git
pip install palace/
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clone</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">McSinyx</span><span class="o">/</span><span class="n">palace</span><span class="o">.</span><span class="n">git</span>
<span class="n">pip</span> <span class="n">install</span> <span class="n">palace</span><span class="o">/</span>
</pre></div>
</div>
</div>

File diff suppressed because one or more lines are too long

View File

@ -47,9 +47,9 @@ requested by someone who requires them.
Submitting a Patch
------------------
We except all kinds of patches, from documentation and CI/CD setup
We accept all kinds of patches, from documentation and CI/CD setup
to bug fixes, feature implementations and tests. Except for documentation
located in the ``gh-pages`` branch, others are should be filed against
located in the ``gh-pages`` branch, others should be filed against
the development branch ``master``. These are hosted on GitHub and
one may create a local repository by running::
@ -59,7 +59,7 @@ While the patch can be submitted via email, it is preferable to file
a pull request on GitHub to allow more people to review it, since we do not
have any mail list. Either way, contributors must have legal permission
to distribute the code and it must be available under `LGPLv3+`_. Furthermore,
each contributor retain the copyrights of their patch, to ensure that
each contributor retains the copyrights of their patch, to ensure that
the licence can never be revoked even if others wants to. It is advisable
that the author list per legal name under the copyright header
of each source file they modify, like so::
@ -89,6 +89,11 @@ Using GitHub
#. Add_, commit_ with `a great message`_ then push_ the result.
#. Finally, `create a pull request`_. We will then review and merge it.
It is recommended to create a new branch in your fork
(``git checkout -c what-you-are-working-on``) instead of working directly
on ``master``. This way one can still sync per fork with our ``master`` branch
and ``git pull --rebase upstream master`` to avoid integration issues.
Via Email
^^^^^^^^^
@ -142,12 +147,12 @@ reStructuredText
In order for reStructuredText to be rendered correctly, the body of
constructs beginning with a marker (lists, hyperlink targets, comments, etc.)
must be aligned relative to the marker. For this reason, it's is convenient
must be aligned relative to the marker. For this reason, it is convenient
to set your editor indentation level to 3 spaces, since most constructs
starts with two dots and a space. However, be aware of that bullet items
require 2-space alignment and other exceptions.
Limits all lines to a maximum of 79 characters. Similar to comments
Limit all lines to a maximum of 79 characters. Similar to comments
and docstrings, phrases should not be broken in the middle.
The source code of this guide itself is a good example on how line breaks
should be handled. Additionally, two spaces should also be used

View File

@ -1,6 +1,12 @@
Copying
=======
This listing is our best-faith, hard-work effort at accurate attribution,
sources, and licenses for everything in palace. If you discover
an asset/contribution that is incorrectly attributed or licensed,
please contact us immediately. We are happy to do everything we can
to fix or remove the issue.
License
-------
Palace is free software: you can redistribute it and/or modify it
@ -42,7 +48,7 @@ the developers of Alure_ and Cython_ who promptly gave detail answers
and made quick fixes to all of our problems.
The wheels are build using cibuildwheel_, which made building wheels for
extension modules much less of a pain in the ass. `Travis CI`_ and AppVoyer_
extension modules much less of a pain in the ass. `Travis CI`_ and AppVeyor_
kindly provides there services free of charge for automated CI/CD.
This documentation is generated using Sphinx_, whose maintainer responses
@ -65,4 +71,4 @@ extreamly quickly to obsolete Cython-related issues.
.. _cibuildwheel: https://cibuildwheel.readthedocs.io/en/stable/
.. _Sphinx: https://www.sphinx-doc.org/en/master/
.. _Travis CI: https://travis-ci.com/
.. _AppVoyer: https://www.appveyor.com/
.. _AppVeyor: https://www.appveyor.com/

View File

@ -4,7 +4,7 @@ Installation
Prerequisites
-------------
Palace requires Python 3.6 for runtime and `pip`_ for installation.
Palace requires Python 3.6 for runtime and pip_ for installation.
Via PyPI
--------
@ -14,23 +14,20 @@ Palace can be installed from PyPI::
pip install palace
Wheel distributions are built exclusively for amd64. Currently, only GNU/Linux
is properly supported. If you want to help packaging for Windows and macOS,
see `GH-1`_ and `GH-63`_ respectively on our issues tracker on GitHub.
and macOS are properly supported. If you want to help packaging for Windows,
please see `GH-1`_ on our issues tracker on GitHub.
From source
-----------
Aside from the build dependencies listed in ``pyproject.toml``,
one will additionally need compatible Python headers, `alure`_,
one will additionally need compatible Python headers, alure_,
a C++14 compiler, CMake 2.6+ (and probably ``git`` for fetching the source).
Palace can then be compiled and installed by running:
.. code-block:: sh
Palace can then be compiled and installed by running::
git clone https://github.com/McSinyx/palace.git
pip install palace/
.. _pip: https://pip.pypa.io/en/latest/
.. _GH-1: https://github.com/McSinyx/palace/issues/1
.. _GH-63: https://github.com/McSinyx/palace/issues/63
.. _alure: https://github.com/kcat/alure