typo cleanup

Ref0_meta.txt

@@ -35,7 +35,7 @@ Libevent is divided into the following components:
 
 evutil::
  Generic functionality to abstract out the differences between
- different platforms' networkign implementations.
+ different platforms' networking implementations.
 
 event and event_base::
  This is the heart of Libevent. It provides an abstract API to
@@ -72,11 +72,11 @@ evrpc::
 The Libraries
 ~~~~~~~~~~~~~
 
-When Libevent is built, by default it it installs the following
+When Libevent is built, by default it installs the following
 libraries:
 
 libevent_core::
- All core event and buffer functionality functionality. This
+ All core event and buffer functionality. This
  library contains all the event_base, evbuffer, bufferevent,
  and utility functions.
 
@@ -102,7 +102,7 @@ libevent_pthreads::
 The Headers
 ~~~~~~~~~~~
 
-All current public Libevent headers are instaleld under the 'event2'
+All current public Libevent headers are installed under the 'event2'
 directory. Headers fall into three broad classes:
 
 API headers::

Ref1_libsetup.txt

@@ -159,12 +159,12 @@ void start_counting_bytes(void)
 
 .NOTES
 - Replacing the memory management functions affects all future calls to
- allocate, resize, or free memory from in Libevent. Therefore, you
+ allocate, resize, or free memory from Libevent. Therefore, you
  need to make sure that you replace the functions _before_ you call any
  other Libevent functions. Otherwise, Libevent will use your version
  of free to deallocate memory returned from the C library's version of
  malloc.
-- Your malloc and realloc functions needs to return memory chunks with
+- Your malloc and realloc functions need to return memory chunks with
  the same alignment as the C library.
 - Your realloc function needs to handle realloc(NULL, sz) correctly
  (that is, by treating it as malloc(sz)).
@@ -176,7 +176,7 @@ void start_counting_bytes(void)
  are using Libevent from more than one thread.
 
 The event_set_mem_functions() function is declared in <event2/event.h>.
-They first appeared in Libevent 2.0.1-alpha.
+It first appeared in Libevent 2.0.1-alpha.
 
 Libevent can be built with event_set_mem_functions() disabled. If it
 is, then programs using event_set_mem_functions will not compile or link.
@@ -191,7 +191,7 @@ time.
 Libevent structures can generally work three ways with multithreading.
 
 - Some structures are inherently single-threaded: it is never safe to use
- them from more then one thread at the same time.
+ them from more than one thread at the same time.
 - Some structures are optionally locked: you can tell Libevent for each
  object whether you need to use it from multiple threads at once.
 - Some structures are always locked: if Libevent is running with lock
@@ -312,7 +312,7 @@ may be different.
 You can get a Libevent version in two formats: as a string suitable for
 displaying to users, or as a 4-byte integer suitable for numerical
 comparison. The integer format uses the high byte for the major version,
-the second byte for the minor version, the byte for the patch version, and
+the second byte for the minor version, the third byte for the patch version, and
 the low byte to indicate release status (0 for release, nonzero for a
 development series after a given release).
 

Ref2_eventbase.txt

@@ -122,7 +122,7 @@ The recognized option values for event_config_set_flag() are:
 The above functions that manipulate an event_config all return 0 on success,
 -1 on failure.
 
-NOTE: it is easy to set up an event_config that requires a backend that your
+NOTE: It is easy to set up an event_config that requires a backend that your
 OS does not provide. For example, as of Libevent 2.0.1-alpha, there is no
 O(1) backend for Windows, and no backend on Linux that provides both
 EV_FEATURE_FDS and EV_FEATURE_O1. If you have made a configuration that
@@ -344,7 +344,7 @@ struct event_base *event_init(void);
 --------
 
 This function worked like event_base_new(), and set the current base
-to the allocated base. There was no way other way to change the
+to the allocated base. There was no other way to change the
 curent base.
 
 

Ref4_event.txt

@@ -18,7 +18,7 @@ represents a set of conditions, including:
 Events have similar lifecycles. Once you call a Libevent function to
 set up an event and associate it with an event base, it becomes
 *initialized*. At this point, you can 'add', which makes it
-*pending*.  in the base. When the event is pending, if the conditions
+*pending* in the base. When the event is pending, if the conditions
 that would trigger an event occur (e.g., its file descriptor changes
 state or its timeout expires), the event becomes *active*, and its
 (user-provided) callback function is run. If the event is configured
@@ -64,8 +64,8 @@ All new events are initialized and non-pending. To make an event
 pending, call event_add() (documented below).
 
 To deallocate an event, call event_free(). It is safe to call
-event_free() on an event that is pending or active: doing do makes the
-event non-pending and in-active befrore deallocating it.
+event_free() on an event that is pending or active: doing so makes the
+event non-pending and in-active before deallocating it.
 
 .Example
 [code]
@@ -234,7 +234,7 @@ structure.
 These are _very_ small costs, and do not matter for most applications.
 You should just stick to using event_new() unless you *know* that
 you're incurring a significant performance penalty for heap-allocating
-your events. Using this function can cause hard-do-diagnose errors
+your events. Not using this function can cause hard-do-diagnose errors
 with future versions of Libevent if they use a larger event structure
 than the one you're building with.
 
@@ -320,7 +320,7 @@ non-active. If the event was not pending or active, there is no
 effect. The return value is 0 on success, -1 on failure.
 
 NOTE: If you delete an event after it becomes active but before
-its callback has a chance to executes, the callback will not be
+its callback has a chance to execute, the callback will not be
 executed.
 
 These functions are defined in <event2/event.h>; they have existed

Ref6_bufferevent.txt

@@ -17,9 +17,9 @@ write data, for example, the usual pattern runs something like:
  wait for the connection to become writeable again.
 
 This buffered IO pattern is common enough that Libevent provides a
-generic mechanism for it. A "bufferevent" is consists of an
+generic mechanism for it. A "bufferevent" consists of an
 underlying transport (like a socket), a read buffer, and a write
-buffer. Instead of regular events, which givecallbacks when the
+buffer. Instead of regular events, which give callbacks when the
 underlying transport is ready to be read or written, a bufferevent
 invokes its user-supplied callbacks when it has read or written enough
 data.
@@ -74,7 +74,7 @@ and a write callback. By default, the read callback is called
 whenever any data is read from the underlying transport, and the write
 callback is called whenever enough data is written to the output
 buffer is emptied. You can override the behavior of these functions
-by adjusting the the read and write "watermarks" of the bufferevent.
+by adjusting the read and write "watermarks" of the bufferevent.
 
 Every bufferevent has four watermarks:
 
@@ -85,7 +85,7 @@ Read low-water mark::
  being invoked.
 
 Read high-water mark::
- If the bufferevent's input buffer ever gets to than this level, the
+ If the bufferevent's input buffer ever gets to this level, the
  bufferevent stops reading until enough data is drained from the
  input buffer to take us below it again. Defaults to unlimited, so
  that we never stop reading because of the size of the input buffer.
@@ -96,7 +96,7 @@ Write low-water mark::
  is not invoked unless the output buffer is emptied.
 
 Write high-water mark::
- Not used by a bufferevent diretly, this watermark can have special
+ Not used by a bufferevent directly, this watermark can have special
  meaning when a bufferevent is used as the underlying transport of
  another bufferevent. See notes on filtering bufferevents below.
 
@@ -356,7 +356,7 @@ reading, and restarts again when there is space to read.
 By default, a newly created bufferevent has writing enabled, but not
 reading.
 
-These function was introduced before Libevent 1.0.
+These functions were introduced before Libevent 1.0.
 
 .Interface
 [code]
@@ -426,7 +426,7 @@ info1 = malloc(sizeof(struct info));
 info1->name = "buffer 1";
 info1->total_drained = 0;
 
-/* ... Here we should set up the bufferevent and makes sure it gets
+/* ... Here we should set up the bufferevent and make sure it gets
  connected... */
 
 /* Trigger the read callback only whenever there is at least 128 bytes

Ref7_evbuffer.txt

@@ -1,4 +1,4 @@
-binclude::license.txt[]
+include::license.txt[]
 
 :language: C
 
@@ -186,7 +186,7 @@ Rearranging the internal layout of an evbuffer
 
 Sometimes you want to peek at the the first N bytes of data in the
 front of an evbuffer, and see it as a contiguous array of bytes. To
-do this, you must first ensure that the fron of the buffer really _is_
+do this, you must first ensure that the front of the buffer really _is_
 contiguous.
 
 .Interface
@@ -360,7 +360,7 @@ struct evbuffer_ptr evbuffer_search(struct evbuffer *buffer,
  const char *what, size_t len, const struct evbuffer_ptr *start);
 --------
 
-This function scands the buffer for an occurrence of the
+This function scans the buffer for an occurrence of the
 'len'-character string 'what'. It returns an evbuffer_ptr containing
 the position of the string, or -1 if the string was not found. If the
 'start' argument is provided, it's the position at which the search
@@ -689,7 +689,7 @@ attempts to flush as much of the buffer as it can.
 On Unix, these functions should work on any file descriptor that
 supports read and write. On Windows, only sockets are supported.
 
-Not that when you are using bufferevents, you do not need to call
+Note that when you are using bufferevents, you do not need to call
 these IO functions; the buferevents code does it for you.
 
 The evbuffer_write_atmost() function was introduced in Libevent 2.0.1-alpha.

Ref8_listener.txt

@@ -1,4 +1,4 @@
-binclude::license.txt[]
+include::license.txt[]
 
 :language: C