null+****@clear*****
null+****@clear*****
2011年 10月 28日 (金) 22:11:54 JST
Kazuhiko 2011-10-28 13:11:54 +0000 (Fri, 28 Oct 2011)
New Revision: 3dfc61f48167f70dcf3f182bcd01a36445ed0208
Log:
[doc] typos.
Modified files:
doc/en/source/developer.rst
doc/en/source/developer/debug.rst
doc/en/source/news.rst
doc/en/source/userguide/storage.rst
doc/en/source/userguide/wrapper.rst
doc/ja/source/developer.rst
Modified: doc/en/source/developer.rst (+6 -3)
===================================================================
--- doc/en/source/developer.rst 2011-10-28 13:00:11 +0000 (240709f)
+++ doc/en/source/developer.rst 2011-10-28 13:11:54 +0000 (1a9ab2f)
@@ -50,7 +50,7 @@ Process of development
We would like to develop in the following procedure.
1. Create a new ticket and add a description
-2. Discuss in the development meating and update roadmaps
+2. Discuss in the development meeting and update roadmaps
3. Assign the ticket, and the assignee starts development
4. Implement features or fix bugs, then push to the repository if needed
5. Add and run test codes, then push to the repository
@@ -126,8 +126,11 @@ test/sql/r/
test/unit/
The directory for per-function unit tests by C/C++
+doc/en/
+ English documents in sphinx format
+
doc/ja/
- Documents in sphinx format
+ Japanese documents in sphinx format
Since we are still in the early stage of the development of groonga storage engine, we will not make the documents of the specification of SQL queries for now.
@@ -165,7 +168,7 @@ We write documents in ReStructuredText format and we convert them to HTML etc.
The source files of documents are files having .rst extension in "doc/ja/source" directory.
-When you add or modify them, please try to buid by "make html" etc. and confirm that no syntax error happens.
+When you add or modify them, please try to build by "make html" etc. and confirm that no syntax error happens.
Documents are published in http://mroonga.github.com . Since we are using github's web site feature, they will be updated each time when HTML files are pushed to http://github.com/mroonga/mroonga.github.com repository. We push to mroonga.github.com repository after confirming the consistency between documents and current released version.
Modified: doc/en/source/developer/debug.rst (+2 -2)
===================================================================
--- doc/en/source/developer/debug.rst 2011-10-28 13:00:11 +0000 (79fadf9)
+++ doc/en/source/developer/debug.rst 2011-10-28 13:11:54 +0000 (c63c3e3)
@@ -6,7 +6,7 @@ How to debug
Building for debugging
-----------------------
-Whe you build software for debugging, you can get more information like symbol resolutions in gdb.
+When you build software for debugging, you can get more information like symbol resolutions in gdb.
So we build both MySQL and groonga storage engine for debugging in development.
.. note::
@@ -44,7 +44,7 @@ The procedure from cloning repository to build is the following. ::
% ./configure CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" --with-debug --prefix=/tmp/local --with-mysql-source=$HOME/work/mysql-5.5.13 --with-mysql-config=$HOME/work/mysql-5.5.13/scripts/mysql_config
% make
-Whe you successfully build both, please invoke tests like the following.
+When you successfully build both, please invoke tests like the following.
If you get ``[pass]`` for all tests, you succeeded to build for debugging. ::
% test/run-sql-test.sh
Modified: doc/en/source/news.rst (+2 -2)
===================================================================
--- doc/en/source/news.rst 2011-10-28 13:00:11 +0000 (12ee9a2)
+++ doc/en/source/news.rst 2011-10-28 13:11:54 +0000 (0535174)
@@ -15,7 +15,7 @@ Improvements
* [storage mode][wrapper mode] support reopening a database by `flush tables`.
* [wrapper mode] support geolocation index. (Only Point type can be stored in a column. Search using index is only available for MBRContains).
-* [benchmark] add `groonga_dry_write` variable to specify not to write to groonga database, that is useful to check bottle neckes in benchmarks.
+* [benchmark] add `groonga_dry_write` variable to specify not to write to groonga database, that is useful to check bottle necks in benchmarks.
* mention MySQL version in the installation guide for CentOS 6. [proposed by @yoshi_ken]
* [geolocation] improve performance by skip needless processes.
* add `--disable-fast-mutexes` configure option to ignore fast mutexes even if mysql_config says it is enabled.
@@ -30,7 +30,7 @@ Bug fixes
* fix a bug that we have no results if we specify '+' at the beginning of the query in boolean mode. [reported by Hajime Nishiyama]
* [Fedora] fix package dependencies. [reported by Takahiro Nagai]
-* [Fedora] fix a problem that we get undefined symol error when the plugin is loaded. [reported by Takahiro Nagai]
+* [Fedora] fix a problem that we get undefined symbol error when the plugin is loaded. [reported by Takahiro Nagai]
Acknowledgements
++++++++++++++++
Modified: doc/en/source/userguide/storage.rst (+2 -2)
===================================================================
--- doc/en/source/userguide/storage.rst 2011-10-28 13:00:11 +0000 (c3f8efc)
+++ doc/en/source/userguide/storage.rst 2011-10-28 13:11:54 +0000 (a11573f)
@@ -390,7 +390,7 @@ Optimisation for ORDER BY LIMIT in full text search
Generally speaking, MySQL can process "ORDER BY" query with almost no cost if we can get records by index, and can process "LIMIT" with low cost by limiting the range of processing data even if the number of query result is very big.
-But for the query where "ORDER BY" cannot use index, like sort full text search result by the score and use LIMIT, the processing cost is propotional to the number of query results. So it might take very long time for the keyword query that matches with many records.
+But for the query where "ORDER BY" cannot use index, like sort full text search result by the score and use LIMIT, the processing cost is proportional to the number of query results. So it might take very long time for the keyword query that matches with many records.
Tritonn took no specific countermeasure for this issue, but it introduced a workaround in the latest repository so that it sorted Senna result in descending order of the score by using sen_records_sort function so that we could remove ORDER BY from the SQL query.
@@ -412,7 +412,7 @@ You can check if this optimisation works or not by the status variable. ::
Each time the optimisation for counting rows works, ``groonga_fast_order_limit`` status variable value is increased.
-Note : This optimisation is targetting queries like "select ... match against order by _score desc limit X, Y" only, and it works if all of the following conditions are right.
+Note : This optimisation is targeting queries like "select ... match against order by _score desc limit X, Y" only, and it works if all of the following conditions are right.
* WHERE phrase has "match...against" only
* no JOIN
Modified: doc/en/source/userguide/wrapper.rst (+2 -2)
===================================================================
--- doc/en/source/userguide/wrapper.rst 2011-10-28 13:00:11 +0000 (ec48fff)
+++ doc/en/source/userguide/wrapper.rst 2011-10-28 13:11:54 +0000 (4b68279)
@@ -246,7 +246,7 @@ Optimisation for ORDER BY LIMIT in full text search
Generally speaking, MySQL can process "ORDER BY" query with almost no cost if we can get records by index, and can process "LIMIT" with low cost by limiting the range of processing data even if the number of query result is very big.
-But for the query where "ORDER BY" cannot use index, like sort full text search result by the score and use LIMIT, the processing cost is propotional to the number of query results. So it might take very long time for the keyword query that matches with many records.
+But for the query where "ORDER BY" cannot use index, like sort full text search result by the score and use LIMIT, the processing cost is proportional to the number of query results. So it might take very long time for the keyword query that matches with many records.
Tritonn took no specific countermeasure for this issue, but it introduced a workaround in the latest repository so that it sorted Senna result in descending order of the score by using sen_records_sort function so that we could remove ORDER BY from the SQL query.
@@ -268,7 +268,7 @@ You can check if this optimisation works or not by the status variable. ::
Each time the optimisation for counting rows works, ``groonga_fast_order_limit`` status variable value is increased.
-Note : This optimisation is targetting queries like "select ... match against order by _score desc limit X, Y" only, and it works if all of the following conditions are right.
+Note : This optimisation is targeting queries like "select ... match against order by _score desc limit X, Y" only, and it works if all of the following conditions are right.
* WHERE phrase has "match...against" only
* no JOIN
Modified: doc/ja/source/developer.rst (+4 -1)
===================================================================
--- doc/ja/source/developer.rst 2011-10-28 13:00:11 +0000 (cab79af)
+++ doc/ja/source/developer.rst 2011-10-28 13:11:54 +0000 (52ccd70)
@@ -122,8 +122,11 @@ test/sql/r/
test/unit/
C/C++関数単体でのテストコード用ディレクトリ
+doc/en/
+ sphinx形式の日本語ドキュメント一式
+
doc/ja/
- sphinx形式のドキュメント一式
+ sphinx形式の英語ドキュメント一式
groongaストレージエンジンはまだ開発の立ち上げ段階であるため、SQL実行に関する仕様のドキュメント化は当面行いません。