From bfd9a4f396d144199cb57376e6928701cf0dc931 Mon Sep 17 00:00:00 2001 From: Matthias Lang Date: Mon, 15 Mar 2010 07:46:50 +0100 Subject: Change all incorrect occurrences of it's to its The documentation (*.xml) in the otp tree has a common grammatical problem, "it's" and "its" are often interchanged. That is annoying for some readers. This commit consists entirely of "it's" -> "its" changes. I went through every .xml file in the tree. If there are any remaining bugs of this type, it's because I missed them, not because I didn't look. --- lib/stdlib/doc/src/io_protocol.xml | 4 ++-- lib/stdlib/doc/src/ms_transform.xml | 2 +- lib/stdlib/doc/src/unicode_usage.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) (limited to 'lib/stdlib') diff --git a/lib/stdlib/doc/src/io_protocol.xml b/lib/stdlib/doc/src/io_protocol.xml index 201787f7b5..b52e862a5c 100644 --- a/lib/stdlib/doc/src/io_protocol.xml +++ b/lib/stdlib/doc/src/io_protocol.xml @@ -195,7 +195,7 @@ latin1, Module, Function, Args} respectively.

below).

The function will be called with the data the io_server finds on - it's device, returning {done, Result, RestChars} when enough data is + its device, returning {done, Result, RestChars} when enough data is read (in which case Result is sent to the client and RestChars are kept in the io_server as a buffer for subsequent input) or {more, Continuation}, indicating that more characters are needed to @@ -741,7 +741,7 @@ optimize anything however. It is important though that the returned data is of the right type depending on the options set, so we convert the lists to binaries in the correct encoding if possible before returning. The function supplied in the get_until request may, -as it's final result return anything, so only functions actually +as its final result return anything, so only functions actually returning lists can get them converted to binaries. If the request contained the encoding tag unicode, the lists can contain all unicode codepoints and the binaries should be in UTF-8, if the encoding tag diff --git a/lib/stdlib/doc/src/ms_transform.xml b/lib/stdlib/doc/src/ms_transform.xml index 9f178b426c..6c484c5119 100644 --- a/lib/stdlib/doc/src/ms_transform.xml +++ b/lib/stdlib/doc/src/ms_transform.xml @@ -245,7 +245,7 @@ ets:select(emp_tab, ets:fun2ms( fun(#emp{empno = [$0 | Rest] }) -> {[$0|Rest],[$1|Rest]} end)). -

As a matter of fact, this query hit's the feature of partially bound +

As a matter of fact, this query hits the feature of partially bound keys in the table type ordered_set, so that not the whole table need be searched, only the part of the table containing keys beginning with 0 is in fact looked into.

diff --git a/lib/stdlib/doc/src/unicode_usage.xml b/lib/stdlib/doc/src/unicode_usage.xml index c5bf10b63d..f1b0659ea2 100644 --- a/lib/stdlib/doc/src/unicode_usage.xml +++ b/lib/stdlib/doc/src/unicode_usage.xml @@ -143,7 +143,7 @@ en_US.UTF-8 
 $ echo $LC_CTYPE
 en_US.UTF-8
-

The LANG or LC_CTYPE setting should be consistent with what the terminal is capable of, there is no portable way for Erlang to ask the actual terminal about it's UTF-8 capacity, we have to rely on the language and character type settings.

+

The LANG or LC_CTYPE setting should be consistent with what the terminal is capable of, there is no portable way for Erlang to ask the actual terminal about its UTF-8 capacity, we have to rely on the language and character type settings.

To investigate what Erlang thinks about the terminal, the io:getopts() call can be used when the shell is started:

 $ LC_CTYPE=en_US.ISO-8859-1 erl
@@ -185,7 +185,7 @@ Eshell V5.7  (abort with ^G)
 file, group and user
 
 
I/O-servers throughout the system are able both to handle Unicode data and has options for converting data upon actual output or input to/from the device. As shown earlier, the shell has support for Unicode terminals and the  file module allows for translation to and from various Unicode formats on disk.

-
The actual reading and writing of files with Unicode data is however not best done with the file module as it's interface is byte oriented. A file opened with a Unicode encoding (like UTF-8), is then best read or written using the io module.

+
The actual reading and writing of files with Unicode data is however not best done with the file module as its interface is byte oriented. A file opened with a Unicode encoding (like UTF-8), is then best read or written using the io module.

 
 re
 
-- 
cgit v1.2.3