# patch from gam3@gam3.net
Only in POE-1.284.spelling/: bingos-followtail
Only in POE-1.284.spelling/: blib
diff -ru POE-1.284/lib/POE/Component/Client/TCP.pm POE-1.284.spelling/lib/POE/Component/Client/TCP.pm
--- POE-1.284/lib/POE/Component/Client/TCP.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Component/Client/TCP.pm	2010-01-16 17:00:04.000000000 -0500
@@ -701,7 +701,7 @@
 
 =head4 ServerInput
 
-C<ServerInput> is a requried callback.  It is called for each fully
+C<ServerInput> is a required callback.  It is called for each fully
 parsed input record received by POE::Wheel::ReadWrite.  $_[ARG0]
 contains the input record, the format of which is determined by the
 C<Filter> constructor parameter.
@@ -750,7 +750,7 @@
 bookkeeping.  The following members are used and should be used as
 directed, or with care.
 
-This sampe input handler is an example of most reserved heap members:
+This sample input handler is an example of most reserved heap members:
 
   sub handle_input {
     # Pending input from when we were connected.
diff -ru POE-1.284/lib/POE/Component/Server/TCP.pm POE-1.284.spelling/lib/POE/Component/Server/TCP.pm
--- POE-1.284/lib/POE/Component/Server/TCP.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Component/Server/TCP.pm	2010-01-16 16:58:26.000000000 -0500
@@ -1048,7 +1048,7 @@
 often sent to the remote client from this callback.
 
 The @_[ARG0..$#_] parameters to C<ClientConnected> are a copy of the
-values in the C<ClientArgs> constructor parameter's array referece.
+values in the C<ClientArgs> constructor parameter's array reference.
 The other @_ members are standard for a POE::Session _start handler.
 
 C<ClientConnected> is called once per session startup.  It will never
@@ -1332,7 +1332,7 @@
 
 =head3 remote_ip
 
-$_[HEAP]{remote_ip} contains the remote client's nuermic address in
+$_[HEAP]{remote_ip} contains the remote client's numeric address in
 human-readable form.
 
 =head3 remote_port
@@ -1343,7 +1343,7 @@
 =head3 remote_addr
 
 $_[HEAP]{remote_addr} contains the remote client's packed socket
-address in computer-readabe form.
+address in computer-readable form.
 
 =head3 shutdown
 
diff -ru POE-1.284/lib/POE/Component.pm POE-1.284.spelling/lib/POE/Component.pm
--- POE-1.284/lib/POE/Component.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Component.pm	2010-01-16 17:51:33.000000000 -0500
@@ -100,7 +100,7 @@
 L<POE::Stage> is a nascent project to formalize POE components, make
 POE::Kernel more object-oriented, and provide syntactic and semantic
 sugar for many common aspects of POE::Component development.  It's
-also easier to type.  Please investigate the project.  Ideas and tuits
+also easier to type.  Please investigate the project.  Ideas and I<tuits>
 are badly needed to help get the project off the ground.
 
 =head1 TO DO
diff -ru POE-1.284/lib/POE/Driver/SysRW.pm POE-1.284.spelling/lib/POE/Driver/SysRW.pm
--- POE-1.284/lib/POE/Driver/SysRW.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Driver/SysRW.pm	2010-01-16 17:02:33.000000000 -0500
@@ -192,7 +192,7 @@
 
 new() creates a new buffered I/O driver that uses sysread() to read
 data from a handle and syswrite() to flush data to that handle.  The
-constructer accepts one optional named parameter, C<BlockSize>, which
+constructor accepts one optional named parameter, C<BlockSize>, which
 indicates the maximum number of OCTETS that will be read at one time.
 
 C<BlockSize> is 64 kilobytes (65536 octets) by default.  Higher values
diff -ru POE-1.284/lib/POE/Driver.pm POE-1.284.spelling/lib/POE/Driver.pm
--- POE-1.284/lib/POE/Driver.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Driver.pm	2010-01-16 17:34:38.000000000 -0500
@@ -100,7 +100,7 @@
 =item put ARRAYREF
 
 put() accepts an ARRAYREF of raw octet chunks.  These octets are added
-to the dirver's internal output queue or buffer.  put() returns the
+to the driver's internal output queue or buffer.  put() returns the
 number of octets pending output after the new octets are buffered.
 
 Some drivers may flush data immediately from their put() methods.
@@ -108,7 +108,7 @@
 =item flush FILEHANDLE
 
 flush() attempts to write a driver's buffered data to a given
-FIELHANDLE.  The driver should flush as much data as possible in a
+FILEHANDLE.  The driver should flush as much data as possible in a
 single flush() call.
 
 flush() returns the number of octets remaining in the driver's output
diff -ru POE-1.284/lib/POE/Filter/Map.pm POE-1.284.spelling/lib/POE/Filter/Map.pm
--- POE-1.284/lib/POE/Filter/Map.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Filter/Map.pm	2010-01-16 17:22:03.000000000 -0500
@@ -174,7 +174,7 @@
 called with a single Code parameter, or both a Put and a Get
 parameter.  The values for Code, Put and Get are code references that,
 when invoked, return transformed versions of their sole parameters.  A
-Code function will be used for both input and ouput, while Get and Put
+Code function will be used for both input and output, while Get and Put
 functions allow input and output to be filtered in different ways.
 
   # Decrypt rot13.
diff -ru POE-1.284/lib/POE/Filter/RecordBlock.pm POE-1.284.spelling/lib/POE/Filter/RecordBlock.pm
--- POE-1.284/lib/POE/Filter/RecordBlock.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Filter/RecordBlock.pm	2010-01-16 17:20:03.000000000 -0500
@@ -137,9 +137,9 @@
 =head1 SYNOPSIS
 
 Hello, dear reader.  This SYNOPSIS does not contain a fully
-functioning sample program because your humble documentor cannot come
+functioning sample program because your humble documenter cannot come
 up with a short, reasonable use case for this module.  Please contact
-the maintaner if this module is useful to you.  Otherwise you may wake
+the maintainer if this module is useful to you.  Otherwise you may wake
 up one morning to discover that it has been deprecated.
 
   $filter = new POE::Filter::RecordBlock( BlockSize => 4 );
@@ -159,7 +159,7 @@
 On output, this module flattens array references.
 
 This module may be deprecated in the future.  Please contact the
-maintaner if this module is useful to you.
+maintainer if this module is useful to you.
 
 =head1 PUBLIC FILTER METHODS
 
diff -ru POE-1.284/lib/POE/Filter/Reference.pm POE-1.284.spelling/lib/POE/Filter/Reference.pm
--- POE-1.284/lib/POE/Filter/Reference.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Filter/Reference.pm	2010-01-16 17:21:41.000000000 -0500
@@ -381,7 +381,7 @@
 connection.  Even different versions of the same serializer can break
 data in transit.
 
-Most (if not all) serializers will rebless data at the destination,
+Most (if not all) serializers will re-bless data at the destination,
 but many of them will not load the necessary classes to make their
 blessings work.
 
diff -ru POE-1.284/lib/POE/Filter.pm POE-1.284.spelling/lib/POE/Filter.pm
--- POE-1.284/lib/POE/Filter.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Filter.pm	2010-01-16 17:48:16.000000000 -0500
@@ -216,7 +216,7 @@
 get() should not be used with wheels that support filter switching.
 Its greedy nature means that it often parses streams well in advance
 of a wheel's events.  By the time an application changes the wheel's
-filter, it's too late: The old fiter has already parsed the rest of
+filter, it's too late: The old filter has already parsed the rest of
 the received data.
 
 Consider a stream of letters, numbers, and periods.  The periods
diff -ru POE-1.284/lib/POE/Kernel.pm POE-1.284.spelling/lib/POE/Kernel.pm
--- POE-1.284/lib/POE/Kernel.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Kernel.pm	2010-01-16 17:45:39.000000000 -0500
@@ -2687,7 +2687,7 @@
 task scheduler, doling out timeslices to each session by invoking
 callbacks within them.
 
-Callbacks are not pre-emptive.  As long as one is running, no others
+Callbacks are not preemptive.  As long as one is running, no others
 will be dispatched.  This is known as I<cooperative> multitasking.
 Each session must cooperate by returning to the central dispatching
 kernel.
@@ -2760,7 +2760,7 @@
 remain active for it to be dispatched.  The sender remains alive in
 case the receiver would like to send back a response.
 
-Posted events cannot be pre-emptively canceled.  They tend to be
+Posted events cannot be preemptively canceled.  They tend to be
 short-lived in practice, so this generally isn't an issue.
 
 =item Timers.
@@ -2781,7 +2781,7 @@
 aliases, POE::Kernel will send them a terminal L</IDLE> signal.  In
 most cases this will terminate the remaining sessions and allow the
 program to exit.  If the sessions remain in memory without waking up
-on the C<IDLE> signal, POE::Kernel sends them a nonmaskable L</ZOMBIE>
+on the C<IDLE> signal, POE::Kernel sends them a non-maskable L</ZOMBIE>
 signal.  They are then forcibly removed, and the program will finally
 exit.
 
@@ -2837,7 +2837,7 @@
 Sessions may be stopped even if they have active resources.  For
 example, a session may fail to handle a terminal signal.  In this
 case, POE::Kernel forces the session to stop, and all resources
-associated with the session are pre-emptively released.
+associated with the session are preemptively released.
 
 =head2 Events
 
@@ -3020,7 +3020,7 @@
 
 =head3 POE::XS::Loop::EPoll (separate distribution)
 
-L<POE::Loop::EPoll> allows POE components to trnasparently use the
+L<POE::Loop::EPoll> allows POE components to transparently use the
 EPoll event library on operating systems that support it.
 
 =head3 POE::XS::Loop::Poll (separate distribution)
@@ -3049,7 +3049,7 @@
   % perl -wl -MPOE -e 'print $poe_kernel->ID'
   poerbook.local-46c89ad800000e21
 
-While the IDs are made globaly unique by including hostname, time and
+While the IDs are made globally unique by including hostname, time and
 PID, they should be considered an opaque but printable string.  That
 is, your code should not depend on the current format.
 
@@ -3253,7 +3253,7 @@
 prevent data from going stale between the time an event is enqueued
 and the time it's delivered.
 
-Synchronous event handlers pre-empt POE's event queue, so they should
+Synchronous event handlers preempt POE's event queue, so they should
 perform simple tasks of limited duration.  Synchronous events that
 need to do more than just service a resource should pass the
 resource's information to an asynchronous handler.  Otherwise
@@ -3329,7 +3329,7 @@
 
 =head3 Using Time::HiRes
 
-POE::Kernel timers support subsecond accuracy, but don't expect too
+POE::Kernel timers support sub-second accuracy, but don't expect too
 much here.  Perl is not the right language for realtime programming.
 
 Subsecond accuracy is supported through the use of select() timeouts
@@ -4368,7 +4368,7 @@
 been handled so that default behaviors are not necessary.
 
 Signals are I<action at a distance> by nature, and their implementation
-requires widespread synchronization between sessions (and re-entrancy
+requires widespread synchronization between sessions (and reentrancy
 in the dispatcher, but that's an implementation detail).  Perfecting
 the semantics has proven difficult, but POE tries to do the Right
 Thing whenever possible.
@@ -4418,17 +4418,17 @@
 =head4 Nonmaskable signals
 
 Nonmaskable signals are terminal regardless whether sig_handled() is
-called.  The term comes from "NMI", the nonmaskable CPU interrupt
+called.  The term comes from "NMI", the non-maskable CPU interrupt
 usually generated by an unrecoverable hardware exception.
 
-Sessions that receive a nonmaskable signal will unavoidably stop.  POE
-implements two nonmaskable signals:
+Sessions that receive a non-maskable signal will unavoidably stop.  POE
+implements two non-maskable signals:
 
 =over
 
 =item ZOMBIE
 
-This nonmaskable signal is fired if a program has received an C<IDLE> signal
+This non-maskable signal is fired if a program has received an C<IDLE> signal
 but neither restarted nor exited.  The program has become a zombie (that is,
 it's neither dead nor alive, and only exists to consume braaaains ...er...
 memory).  The C<ZOMBIE> signal acts like a cricket bat to the head,
@@ -4436,7 +4436,7 @@
 
 =item UIDESTROY
 
-This nonmaskable signal indicates that a program's user
+This non-maskable signal indicates that a program's user
 interface has been closed, and the program should take the user's hint
 and buzz off as well.  It's usually generated when a particular GUI
 widget is closed.
@@ -4780,7 +4780,7 @@
 
 Because all sessions are a child of POE::Kernel, sending a signal to
 the kernel will propagate the signal to all sessions.  This is a cheap
-form of I<mutlicast>.
+form of I<multicast>.
 
   $_[KERNEL]->signal( $_[KERNEL], 'shutdown' );
 
@@ -4789,7 +4789,7 @@
 signal_ui_destroy() associates the destruction of a particular
 WIDGET_OBJECT with the complete destruction of the program's user
 interface.  When the WIDGET_OBJECT destructs, POE::Kernel issues the
-nonmaskable UIDESTROY signal, which quickly triggers mass destruction
+non-maskable UIDESTROY signal, which quickly triggers mass destruction
 of all active sessions.  POE::Kernel->run() returns shortly
 thereafter.
 
@@ -5387,7 +5387,7 @@
 with Windows and is not used on that platform.
 
 If you wish to revert to the previous unsafe signal behaviour, you
-must set C<USE_SIGNAL_PIPE> to 0, or the environment vairable
+must set C<USE_SIGNAL_PIPE> to 0, or the environment variable
 C<POE_USE_SIGNAL_PIPE>.
 
 =head2 CATCH_EXCEPTIONS
diff -ru POE-1.284/lib/POE/Loop.pm POE-1.284.spelling/lib/POE/Loop.pm
--- POE-1.284/lib/POE/Loop.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Loop.pm	2010-01-16 17:47:47.000000000 -0500
@@ -46,7 +46,7 @@
 POE::Kernel loads the most appropriate POE::Loop subclass for the
 event loop it finds.  The subclass slots its methods into POE::Kernel,
 completing the class at load time.  POE and POE::Kernel provide ways
-to state the desired event loop in case the autodetection makes a
+to state the desired event loop in case the auto-detection makes a
 mistake or the developer prefers to be explicit.  See
 L<POE::Kernel/"Using POE with Other Event Loops"> for instructions on
 how to actually use POE with other event loops, event loop naming
@@ -256,7 +256,7 @@
 "SIG" removed.
 
 POE::Loop::PerlSignals' implementation adds callbacks to %SIG except
-for CHLD/CLD, which begins a waitpid() pollng loop instead.
+for CHLD/CLD, which begins a waitpid() polling loop instead.
 
 As of this writing, all of the POE::Loop subclasses register their
 signal handlers through POE::Loop::PerlSignals.
@@ -337,8 +337,8 @@
 
 The time management methods may accept NEXT_EVENT_TIME.  This is the
 time the next event will become due, in UNIX epoch time.
-NEXT_EVENT_TIME is a real number and may have subsecond accuracy.  It
-is the bridge's responsibility to convert this value intos something
+NEXT_EVENT_TIME is a real number and may have sub-second accuracy.  It
+is the bridge's responsibility to convert this value into something
 the underlying event loop requires.
 
 =head3 loop_resume_time_watcher NEXT_EVENT_TIME
@@ -346,7 +346,7 @@
 Resume an already active time watcher.  It is used with
 loop_pause_time_watcher() to provide less expensive timer toggling for
 frequent use cases.  As mentioned above, NEXT_EVENT_TIME is in UNIX
-epoch time and may have subsecond accuracy.
+epoch time and may have sub-second accuracy.
 
 loop_resume_time_watcher() is used by bridges that set them watchers
 in the underlying event loop.  For example, POE::Loop::Gtk implements
diff -ru POE-1.284/lib/POE/Queue.pm POE-1.284.spelling/lib/POE/Queue.pm
--- POE-1.284/lib/POE/Queue.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Queue.pm	2010-01-16 17:49:18.000000000 -0500
@@ -121,7 +121,7 @@
 =head2 dequeue_next
 
 Removes the next item from the queue, returning it as three fields:
-priority, ID and payloade.
+priority, ID and payload.
 
 The "next" item is the one with the lowest priority number.  If
 multiple items exist with the same priority, dequeue_next() will
@@ -257,7 +257,7 @@
 
 Returns undef if the item's priority could not be adjusted, and sets
 $! to explain why: ESRCH means that the ITEM_ID could not be found,
-and EPERM means that the FILTER_FUNCTION was not satsified.
+and EPERM means that the FILTER_FUNCTION was not satisfied.
 
 =head2 set_priority ITEM_ID, FILTER_FUNCTION, ABSOLUTE_PRIORITY
 
@@ -268,7 +268,7 @@
 
 Returns undef if the item's priority could not be set, and sets $! to
 explain why: ESRCH means that the ITEM_ID could not be found, and
-EPERM means that the FILTER_FUNCTION was not satsified.
+EPERM means that the FILTER_FUNCTION was not satisfied.
 
   my $new_priority = $queue->set_priority(
     $item_id, \&one_of_mine, time() + 60
diff -ru POE-1.284/lib/POE/Resource/FileHandles.pm POE-1.284.spelling/lib/POE/Resource/FileHandles.pm
--- POE-1.284/lib/POE/Resource/FileHandles.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Resource/FileHandles.pm	2010-01-16 17:03:08.000000000 -0500
@@ -752,7 +752,7 @@
 POE watches I/O based on filehandles rather than file descriptors,
 which means there can be clashes between its API and an underlying
 descriptor-based event loop.  This is usually not a problem, but it
-may require work-arounds in certain edge cases.
+may require a work-around in certain edge cases.
 
 =head1 AUTHORS & COPYRIGHTS
 
diff -ru POE-1.284/lib/POE/Wheel/FollowTail.pm POE-1.284.spelling/lib/POE/Wheel/FollowTail.pm
--- POE-1.284/lib/POE/Wheel/FollowTail.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/FollowTail.pm	2010-01-16 17:16:11.000000000 -0500
@@ -690,10 +690,10 @@
 =head1 DESCRIPTION
 
 POE::Wheel::FollowTail objects watch for new data at the end of a file
-and generate new events when things happen to the file.  Its C<Filter>
-parameter defines how to parse data from the file.  Each new item is
-sent to the creator's session as an C<InputEvent> event.  Log rotatin
-will trigger a C<ResetEvent>.
+and generate new events when things happen to the file. Its C<Filter>
+parameter defines how to parse data from the file. Each new item is sent
+to the creator's session as an C<InputEvent> event. Log rotation will
+trigger a C<ResetEvent>.
 
 POE::Wheel::FollowTail only reads from a file, so it doesn't implement
 a put() method.
@@ -783,7 +783,7 @@
 
 POE::Wheel::FollowTail may follow a previously opened file C<Handle>.
 Unfortunately it cannot follow log resets this way, as it won't be
-albe to reopen the file once it has been reset.  Applications that
+able to reopen the file once it has been reset.  Applications that
 must follow resets should use C<Filename> instead.
 
 C<Handle> is still useful for files that will never be reset, or for
diff -ru POE-1.284/lib/POE/Wheel/ListenAccept.pm POE-1.284.spelling/lib/POE/Wheel/ListenAccept.pm
--- POE-1.284/lib/POE/Wheel/ListenAccept.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/ListenAccept.pm	2010-01-16 17:33:32.000000000 -0500
@@ -276,7 +276,7 @@
 C<AcceptEvent> names the event that will be emitted for each newly
 accepted client socket.  It is accompanied by three parameters:
 
-C<$_[ARG0]> contains the newly accpeted client socket handle.  It's up
+C<$_[ARG0]> contains the newly accepted client socket handle.  It's up
 to the application to do something with this socket.  Most use cases
 involve passing the socket to a L<POE::Wheel::ReadWrite> constructor.
 
diff -ru POE-1.284/lib/POE/Wheel/ReadLine.pm POE-1.284.spelling/lib/POE/Wheel/ReadLine.pm
--- POE-1.284/lib/POE/Wheel/ReadLine.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/ReadLine.pm	2010-01-16 17:06:27.000000000 -0500
@@ -3138,7 +3138,7 @@
 POE::Wheel::ReadLine handles almost all common input editing keys.  It
 provides an input history list.  It has both vi and emacs modes.  It
 supports incremental input search.  It's fully customizable, and it's
-compatible with standard readline(3) implementions such as
+compatible with standard readline(3) implementations such as
 Term::ReadLine::Gnu.
 
 POE::Wheel::ReadLine is configured by placing commands in an "inputrc"
@@ -3292,7 +3292,7 @@
 =head3 add_defun NAME FN
 
 add_defun(NAME, FUNCTION) defines a new global FUNCTION, giving it a
-specific NAME.  The function may then be bound to kestrokes by that
+specific NAME.  The function may then be bound to keystrokes by that
 NAME.
 
 =head2 Console I/O Methods
diff -ru POE-1.284/lib/POE/Wheel/ReadWrite.pm POE-1.284.spelling/lib/POE/Wheel/ReadWrite.pm
--- POE-1.284/lib/POE/Wheel/ReadWrite.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/ReadWrite.pm	2010-01-16 17:12:59.000000000 -0500
@@ -795,7 +795,7 @@
 =head4 OutputFilter
 
 InputFilter and OutputFilter may be used to specify different filters
-for input and output.  Please see L</InputFilter> for more informatin
+for input and output. Please see L</InputFilter> for more information
 and an example.
 
 =head4 InputEvent
@@ -1023,7 +1023,7 @@
 Sets the high water mark---the number of octets that designates a
 "full enough" output buffer.  A POE::Wheel::ReadWrite object will emit
 a HighEvent when its output buffer expands to reach this point.  All
-put() calls will reutrn true when the output buffer is equal or
+put() calls will return true when the output buffer is equal or
 greater than HIGH_MARK_OCTETS.
 
 Both HighEvent and put() indicate that it's unsafe to continue writing
@@ -1097,7 +1097,7 @@
 filehandle.  This only works for sockets; nothing will happen for
 other types of filehandle.
 
-tionally, the POE::Wheel::ReadWrite object will stop monitoring
+Occasionally, the POE::Wheel::ReadWrite object will stop monitoring
 its input filehandle for new data.  This occurs regardless of the
 filehandle type.
 
@@ -1109,8 +1109,8 @@
 filehandle.  This only works for sockets; nothing will happen for
 other types of filehandle.
 
-tionally, the POE::Wheel::ReadWrite object will stop monitoring its
-output filehandle for new data.  This occurs regardless of the
+Occasionally, the POE::Wheel::ReadWrite object will stop monitoring its
+output filehandle for new data. This occurs regardless of the
 filehandle type.
 
 TODO - Example.
@@ -1126,7 +1126,7 @@
 =head2 get_driver_out_messages
 
 L<POE::Driver> objects' output buffers may be message based.  Every put()
-call may be buffered individualy.  get_driver_out_messages() will
+call may be buffered individually.  get_driver_out_messages() will
 return the number of pending put() messages that remain to be sent.
 
 Stream-based drivers will simply return 1 if any data remains to be
diff -ru POE-1.284/lib/POE/Wheel/Run.pm POE-1.284.spelling/lib/POE/Wheel/Run.pm
--- POE-1.284/lib/POE/Wheel/Run.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/Run.pm	2010-01-16 17:15:18.000000000 -0500
@@ -1364,7 +1364,7 @@
 
 Because process leaks are so severe, POE::Kernel will check for this
 condition on exit and display a notice if it finds that processes are
-leaking.  Develpers should heed these warnings.
+leaking.  Developers should heed these warnings.
 
 POE::Wheel::Run communicates with the child process in a line-based
 fashion by default.  Programs may override this by specifying some
@@ -1427,7 +1427,7 @@
 
 Winsize sets the child process' terminal size.  Its value should be an
 arrayref with two or four elements.  The first two elements must be
-the number of lines and columsn for the child's terminal window,
+the number of lines and columns for the child's terminal window,
 respectively.  The optional pair of elements describe the terminal's X
 and Y dimensions in pixels:
 
@@ -1552,7 +1552,7 @@
     warn "Wheel $wheel_id generated $operation error $errnum: $errstr\n";
   }
 
-Note that unless you deactivate the signal pipe, you might allso see C<EIO>
+Note that unless you deactivate the signal pipe, you might also see C<EIO>
 (5) error during read operations.
 
 =head4 StdinEvent
diff -ru POE-1.284/lib/POE/Wheel/SocketFactory.pm POE-1.284.spelling/lib/POE/Wheel/SocketFactory.pm
--- POE-1.284/lib/POE/Wheel/SocketFactory.pm	2010-01-14 02:07:06.000000000 -0500
+++ POE-1.284.spelling/lib/POE/Wheel/SocketFactory.pm	2010-01-16 17:32:53.000000000 -0500
@@ -1222,7 +1222,7 @@
 
 =head2 new
 
-new() creats a new POE::Wheel::SocketFactory object.  For sockets
+new() creates a new POE::Wheel::SocketFactory object.  For sockets
 which listen() for and accept() connections, the wheel will generate
 new sockets for each accepted client.  Socket factories for one-shot
 sockets, such as UDP peers or clients established by connect() only
@@ -1350,7 +1350,7 @@
 
 =head3 Connecting the Socket to a Remote Endpoint
 
-A socket may either listen for connections to arrive, intitate
+A socket may either listen for connections to arrive, initiate
 connections to a remote endpoint, or be connectionless (such as in the
 case of UDP sockets).
 
@@ -1435,14 +1435,14 @@
 =head4 FailureEvent
 
 C<FailureEvent> names the event POE::Wheel::SocketFactory will emit
-whenever something goes wrong.  It ususally represents some kind of
+whenever something goes wrong.  It usually represents some kind of
 built-in function call error.  See L</PUBLIC EVENTS> for details, as
 some errors are handled internally by this wheel.
 
 =head2 event
 
 event() allows a session to change the events emitted by a wheel
-without destrying and re-creating the wheel.  It accepts one or more
+without destroying and re-creating the wheel.  It accepts one or more
 of the events listed in L</PUBLIC EVENTS>.  Undefined event names
 disable those events.
 
Only in POE-1.284.spelling/: Makefile
Only in POE-1.284.spelling/: pm_to_blib
Only in POE-1.284.spelling/: run_network_tests
Only in POE-1.284.spelling/t/20_resources: 10_perl
Only in POE-1.284.spelling/t: 30_loops
Only in POE-1.284.spelling/t: spell.t
--- POE-1.284/t/spell.t	1969-12-31 19:00:00.000000000 -0500
+++ POE-1.284.spelling/t/spell.t	2010-01-16 17:51:53.000000000 -0500
@@ -0,0 +1,285 @@
+
+use Test::More;
+
+eval 'use Test::Spelling 0.10'; plan( skip_all => 'Test::Spelling 0.10 required for this test' ) if $@;
+
+add_stopwords(<DATA>);
+all_pod_files_spelling_ok();
+__DATA__
+AcceptEvent
+Addi
+AIX
+aka
+alarm's
+API
+APIs
+Applicatin
+arg
+ARG
+Arnar
+ARRAYREFs
+ARRAYREFsCGI
+Artur
+attribs
+autodetect
+Barcomb
+behaviour
+benchmarked
+BindAddress
+BindPort
+blead
+blocksize
+BlockSize
+bots
+'bots
+Boumans
+braaaains
+callback
+callbacks
+callback's
+call's
+Caputo
+Cashner
+CGI
+checkput
+CheckPut
+CHLD
+CLD
+ClientFlushed
+ClientInput
+CloseEvent
+CloseOnCall
+co
+com
+ConnectError
+connectionless
+Connectionless
+cpan
+CPAN
+cpoe
+Ctrl
+defun
+deniability
+DESTINATION's
+DESTROYed
+destructors
+EAGAIN
+echoer
+EEXIST
+EINVAL
+empt
+empts
+eot
+EPERM
+EPoll
+er
+erm
+ErrorEvent
+ESRCH
+ETIMEDOUT
+EV
+extref
+Extrefs
+FailureEvent
+fallback
+FAQ
+featureful
+FILTERs
+finalizer
+Finalizers
+FlushedEvent
+FlushEvent
+FN
+FreeBSD
+Gtk
+Gtk's
+GUI
+hashrefs
+HEAPs
+HEAPth
+HighEvent
+HighMark
+holde
+hostname
+Hrafnkelsson
+HTTP
+HUP
+IDs
+IKC
+IMHO
+inet
+inline
+InlineStates
+InputEvent
+InputFilter
+InputHandle
+inputrc
+interoperability
+interoperate
+introspected
+IPC
+IPv
+irc
+IRC
+irssi
+isearch
+iThreads
+Jos
+KERNELth
+keymap
+keymaps
+kqueue
+LengthCodec
+LF
+libcurses
+libpoll
+LowEvent
+LowMark
+MainWindow
+mehtod
+mixins
+MSWin
+multicast
+namespace
+namespaces
+ncurses
+nfreeze
+NMI
+non-maskable
+Nonmaskable
+no-op
+NoSetPgrp
+NoSetSid
+NUL
+ObjectStates
+Olde
+Ondoej
+OO
+OOB
+org
+OutputFilter
+OutputHandle
+PackageStates
+passphraseless
+Pearcey
+PG
+pipelike
+pm
+poe
+POE
+POE's
+POEx
+PollInterval
+PONIE
+postback
+postbacks
+postback's
+Postbacks
+pre
+preprocess
+Prima
+Prima's
+ProgramArgs
+pty
+ptys
+QNX
+ReadLine's
+ReadWrite
+ReadWrite's
+rebless
+reconnections
+RecordBlock
+RECORDs
+reentrancy
+REFERENCEd
+RemoteAddress
+RemoteHost
+reponds
+repopulating
+    requester's
+reserialized
+ResetEvent
+RFC
+roadmap
+rollover
+runstate
+RUNSTATE
+Runstates
+scarily
+scrollback
+SeekBack
+Seifer
+serializer
+serializers
+ServerError
+SessionParams
+SESSION's
+Sesson
+SIDs
+sig
+SIG
+SIGALRM
+SIGCHLD
+SIGCLD
+SIGINT
+SIGMONKEY
+SIGPIPE
+SIGTERM
+SIGTSTP
+SIGWINCH
+SocketFactory
+socketpair
+Soderberg
+Solaris
+SPARC
+ssh
+SSL
+stairstep
+standalone
+Standalone
+STATEth
+STDERR
+StderrEvent
+StderrFilter
+STDIN
+StdinEvent
+StdinFilter
+StdinFilter's
+StdioDriver
+StdioFilter
+STDOUT
+StdoutEvent
+StdoutFilter
+StdoutFilter's
+Storable
+stringifying
+Subsecond
+SuccessEvent
+TCL
+tcp
+timeslices
+TODO
+TODOs
+TODOS
+tokenizing
+tuits
+UDP
+Uhlarik
+UIDESTROY
+unfixably
+unhandled
+UNIXy
+unshifts
+WIDGET's
+wiki
+Winsize
+WinSock
+www
+Wx
+Wx's
+WxWindows
+Xantus
+xchat
+XP
+XS
+YAML
