eventmachine-win32 0.5.2

data/COPYING

@@ -0,0 +1,281 @@
+.
+
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+ freedom to share and change it.  By contrast, the GNU General Public
+ License is intended to guarantee your freedom to share and change free
+ software--to make sure the software is free for all its users.  This
+ General Public License applies to most of the Free Software
+ Foundation's software and to any other program whose authors commit to
+ using it.  (Some other Free Software Foundation software is covered by
+ the GNU Lesser General Public License instead.)  You can apply it to
+ your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+ price.  Our General Public Licenses are designed to make sure that you
+ have the freedom to distribute copies of free software (and charge for
+ this service if you wish), that you receive source code or can get it
+ if you want it, that you can change the software or use pieces of it
+ in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+ anyone to deny you these rights or to ask you to surrender the rights.
+ These restrictions translate to certain responsibilities for you if you
+ distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+ gratis or for a fee, you must give the recipients all the rights that
+ you have.  You must make sure that they, too, receive or can get the
+ source code.  And you must show them these terms so they know their
+ rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+ (2) offer you this license which gives you legal permission to copy,
+ distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+ that everyone understands that there is no warranty for this free
+ software.  If the software is modified by someone else and passed on, we
+ want its recipients to know that what they have is not the original, so
+ that any problems introduced by others will not reflect on the original
+ authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+ patents.  We wish to avoid the danger that redistributors of a free
+ program will individually obtain patent licenses, in effect making the
+ program proprietary.  To prevent this, we have made it clear that any
+ patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+ modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+ a notice placed by the copyright holder saying it may be distributed
+ under the terms of this General Public License.  The "Program", below,
+ refers to any such program or work, and a "work based on the Program"
+ means either the Program or any derivative work under copyright law:
+ that is to say, a work containing the Program or a portion of it,
+ either verbatim or with modifications and/or translated into another
+ language.  (Hereinafter, translation is included without limitation in
+ the term "modification".)  Each licensee is addressed as "you".
+
+ Activities other than copying, distribution and modification are not
+ covered by this License; they are outside its scope.  The act of
+ running the Program is not restricted, and the output from the Program
+ is covered only if its contents constitute a work based on the
+ Program (independent of having been made by running the Program).
+ Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+ source code as you receive it, in any medium, provided that you
+ conspicuously and appropriately publish on each copy an appropriate
+ copyright notice and disclaimer of warranty; keep intact all the
+ notices that refer to this License and to the absence of any warranty;
+ and give any other recipients of the Program a copy of this License
+ along with the Program.
+
+ You may charge a fee for the physical act of transferring a copy, and
+ you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+ of it, thus forming a work based on the Program, and copy and
+ distribute such modifications or work under the terms of Section 1
+ above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+ These requirements apply to the modified work as a whole.  If
+ identifiable sections of that work are not derived from the Program,
+ and can be reasonably considered independent and separate works in
+ themselves, then this License, and its terms, do not apply to those
+ sections when you distribute them as separate works.  But when you
+ distribute the same sections as part of a whole which is a work based
+ on the Program, the distribution of the whole must be on the terms of
+ this License, whose permissions for other licensees extend to the
+ entire whole, and thus to each and every part regardless of who wrote it.
+
+ Thus, it is not the intent of this section to claim rights or contest
+ your rights to work written entirely by you; rather, the intent is to
+ exercise the right to control the distribution of derivative or
+ collective works based on the Program.
+
+ In addition, mere aggregation of another work not based on the Program
+ with the Program (or with a work based on the Program) on a volume of
+ a storage or distribution medium does not bring the other work under
+ the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+ under Section 2) in object code or executable form under the terms of
+ Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+ The source code for a work means the preferred form of the work for
+ making modifications to it.  For an executable work, complete source
+ code means all the source code for all modules it contains, plus any
+ associated interface definition files, plus the scripts used to
+ control compilation and installation of the executable.  However, as a
+ special exception, the source code distributed need not include
+ anything that is normally distributed (in either source or binary
+ form) with the major components (compiler, kernel, and so on) of the
+ operating system on which the executable runs, unless that component
+ itself accompanies the executable.
+
+ If distribution of executable or object code is made by offering
+ access to copy from a designated place, then offering equivalent
+ access to copy the source code from the same place counts as
+ distribution of the source code, even though third parties are not
+ compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+ except as expressly provided under this License.  Any attempt
+ otherwise to copy, modify, sublicense or distribute the Program is
+ void, and will automatically terminate your rights under this License.
+ However, parties who have received copies, or rights, from you under
+ this License will not have their licenses terminated so long as such
+ parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+ signed it.  However, nothing else grants you permission to modify or
+ distribute the Program or its derivative works.  These actions are
+ prohibited by law if you do not accept this License.  Therefore, by
+ modifying or distributing the Program (or any work based on the
+ Program), you indicate your acceptance of this License to do so, and
+ all its terms and conditions for copying, distributing or modifying
+ the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+ Program), the recipient automatically receives a license from the
+ original licensor to copy, distribute or modify the Program subject to
+ these terms and conditions.  You may not impose any further
+ restrictions on the recipients' exercise of the rights granted herein.
+ You are not responsible for enforcing compliance by third parties to
+ this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+ infringement or for any other reason (not limited to patent issues),
+ conditions are imposed on you (whether by court order, agreement or
+ otherwise) that contradict the conditions of this License, they do not
+ excuse you from the conditions of this License.  If you cannot
+ distribute so as to satisfy simultaneously your obligations under this
+ License and any other pertinent obligations, then as a consequence you
+ may not distribute the Program at all.  For example, if a patent
+ license would not permit royalty-free redistribution of the Program by
+ all those who receive copies directly or indirectly through you, then
+ the only way you could satisfy both it and this License would be to
+ refrain entirely from distribution of the Program.
+
+ If any portion of this section is held invalid or unenforceable under
+ any particular circumstance, the balance of the section is intended to
+ apply and the section as a whole is intended to apply in other
+ circumstances.
+
+ It is not the purpose of this section to induce you to infringe any
+ patents or other property right claims or to contest validity of any
+ such claims; this section has the sole purpose of protecting the
+ integrity of the free software distribution system, which is
+ implemented by public license practices.  Many people have made
+ generous contributions to the wide range of software distributed
+ through that system in reliance on consistent application of that
+ system; it is up to the author/donor to decide if he or she is willing
+ to distribute software through any other system and a licensee cannot
+ impose that choice.
+
+ This section is intended to make thoroughly clear what is believed to
+ be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+ certain countries either by patents or by copyrighted interfaces, the
+ original copyright holder who places the Program under this License
+ may add an explicit geographical distribution limitation excluding
+ those countries, so that distribution is permitted only in or among
+ countries not thus excluded.  In such case, this License incorporates
+ the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+ of the General Public License from time to time.  Such new versions will
+ be similar in spirit to the present version, but may differ in detail to
+ address new problems or concerns.
+
+ Each version is given a distinguishing version number.  If the Program
+ specifies a version number of this License which applies to it and "any
+ later version", you have the option of following the terms and conditions
+ either of that version or of any later version published by the Free
+ Software Foundation.  If the Program does not specify a version number of
+ this License, you may choose any version ever published by the Free Software
+ Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+ programs whose distribution conditions are different, write to the author
+ to ask for permission.  For software which is copyrighted by the Free
+ Software Foundation, write to the Free Software Foundation; we sometimes
+ make exceptions for this.  Our decision will be guided by the two goals
+ of preserving the free status of all derivatives of our free software and
+ of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+ FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+ OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+ PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+ OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+ TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+ PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+ REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+ WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+ REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+ INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+ OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+ TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+ PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGES.
+

data/README

@@ -0,0 +1,68 @@
+$Id: README 2484 2006-05-12 16:55:59Z francis $
+
+= RUBY/EventMachine
+
+Homepage::  http://rubyeventmachine.com
+Copyright:: (C) 2006 by Francis Cianfrocca. All Rights Reserved.
+Email:: gmail address: garbagecat10
+
+This program is made available under the terms of the Lesser-GPL version 2.
+See EventMachine and EventMachine::Connection for documentation and
+usage examples.
+
+EventMachine implements a fast, single-threaded engine for arbitrary network
+communications. It's extremely easy to use in Ruby. EventMachine wraps all
+interactions with IP sockets, allowing programs to concentrate on the
+implementation of network protocols. It can be used to create both network
+servers and clients. To create a server or client, a Ruby program only needs
+to specify the IP address and port, and provide a Module that implements the
+communications protocol. Implementations of several standard network protocols
+are provided with the package, primarily to serve as examples. The real goal
+of EventMachine is to enable programs to easily interface with other programs
+using TCP/IP, especially if custom protocols are required.
+
+A Ruby program uses EventMachine by registering the addresses and ports of
+network servers and clients, and then entering an event-handling loop.
+EventMachine contains glue code in Ruby which will execute callbacks to
+user-supplied code for all significant events occurring in the clients
+and servers. These events include connection acceptance, startup, data-receipt,
+shutdown, and timer events. Arbitrary processing can be performed by user code
+during event callbacks, including sending data to one or more remote network
+peers, startup and shutdown of network connections, and installation of new
+event handlers.
+
+The EventMachine implements a very familiar model for network programming.
+It emphasizes: 1) the maximum possible isolation of user code from network
+objects like sockets; 2) maximum performance and scalability; and 3) extreme
+ease-of-use for user code. It attempts to provide a higher-level interface
+than similar projects which expose a variety of low-level event-handling
+and networking objects to Ruby programs.
+
+The design and implementation of EventMachine grows out of nearly ten years
+of experience writing high-performance, high-scaling network server applications.
+We have taken particular account of the challenges and lessons described as
+the "C10K problem" by Dan Kegel and others.
+
+EventMachine consists of an extension library written in C++ (which can be
+accessed from languages other than Ruby), and a Ruby module which can be dropped
+into user programs. The current implementation uses the <tt>select(2)</tt> system call
+and may be used on a range of Unix-like systems. A future version of EventMachine
+for Linux will use <tt>epoll(4)</tt> and will thus require a Linux 2.6 kernel.
+Here's a fully-functional echo server written with EventMachine:
+
+      require 'rubygems'
+      require 'eventmachine'
+
+      module EchoServer
+        def receive_data data
+          send_data ">>>you sent: #{data}"
+          close_connection if data =~ /quit/i
+        end
+      end
+
+      EventMachine::run {
+        EventMachine::start_server "192.168.0.100", 8081, EchoServer
+      }
+
+
+# vim: sts=2 sw=2 ts=4 et ai tw=77

data/RELEASE_NOTES

@@ -0,0 +1,59 @@
+$Id: RELEASE_NOTES 2477 2006-05-11 13:22:39Z francis $
+
+RUBY/EventMachine RELEASE NOTES
+
+--------------------------------------------------
+Version: 0.5.2, released 05May06
+Made several nonvisible improvements to the Windows
+implementation.
+Added an exception-handling patch contributed by Jeff Rose, jeff@rosejn.net.
+Added a dir-config patch contributed anonymously.
+Supported builds on Solaris.
+
+--------------------------------------------------
+Version: 0.5.1, released 05May06
+Made it possible to pass a Class rather than a Module
+to a protocol handler.
+Added Windows port.
+
+--------------------------------------------------
+Version: 0.5.0, released 30Apr06
+Added a preliminary SSL/TLS extension. This will probably
+change over the next few releases.
+
+--------------------------------------------------
+Version: 0.4.5, released 29Apr06
+Changed ext files so the ruby.h is installed after unistd.h
+otherwise it doesn't compile on gcc 4.1
+
+--------------------------------------------------
+Version: 0.4.2, released 19Apr06
+Changed the Ruby-glue so the extension will play nicer
+in the sandbox with Ruby threads.
+Added an EventMachine::run_without_threads API to
+switch off the thread-awareness for better performance
+in programs that do not spin any Ruby threads.
+
+--------------------------------------------------
+Version: 0.4.1, released 15Apr06
+Reworked the shared-object interface to make it easier to
+use EventMachine from languages other than Ruby.
+
+--------------------------------------------------
+Version: 0.3.2, released 12Apr06
+Added support for a user-supplied block in EventMachine#connect.
+
+--------------------------------------------------
+Version: 0.3.1, released 11Apr06
+Fixed bug that prevented EventMachine from being run multiple
+times in a single process.
+
+--------------------------------------------------
+Version: 0.3.0, released 10Apr06
+Added method EventHandler::Connection::post_init
+
+--------------------------------------------------
+Version: 0.2.0, released 10Apr06
+Added method EventHandler::stop
+
+

data/lib/eventmachine.rb

@@ -0,0 +1,806 @@
+# $Id: eventmachine.rb 2469 2006-05-10 18:11:10Z francis $
+#
+# Author:: blackhedd (gmail address: garbagecat20).
+# Date:: 8 Apr 2006
+# 
+# Copyright (C) 2006 by Francis Cianfrocca. All Rights Reserved.
+#
+# This program is made available under the terms of the GPL version 2.
+#
+# See EventMachine and EventMachine::Connection for documentation and
+# usage examples.
+#
+#----------------------------------------------------------------------------
+#
+# Copyright (C) 2006 by Francis Cianfrocca. All Rights Reserved.
+#
+# Gmail: garbagecat10
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---------------------------------------------------------------------------
+#
+# 
+
+require 'rubyeventmachine'
+
+# == Introduction
+# EventMachine provides a fast, lightweight framework for implementing
+# Ruby programs that can use the network to communicate with other
+# processes. Using EventMachine, Ruby programmers can easily connect
+# to remote servers and act as servers themselves. EventMachine does not
+# supplant the Ruby IP libraries. It does provide an alternate technique
+# for those applications requiring better performance, scalability,
+# and discipline over the behavior of network sockets, than is easily
+# obtainable using the built-in libraries, especially in applications
+# which are structurally well-suited for the event-driven programming model.
+#
+# EventMachine provides a perpetual event-loop which your programs can
+# start and stop. Within the event loop, TCP network connections are
+# initiated and accepted, based on EventMachine methods called by your
+# program. You also define callback methods which are called by EventMachine
+# when events of interest occur within the event-loop.
+#
+# User programs will be called back when the following events occur:
+# * When the event loop accepts network connections from remote peers
+# * When data is received from network connections
+# * When connections are closed, either by the local or the remote side
+# * When user-defined timers expire
+#
+# == Usage example
+#
+# Here's a fully-functional echo server implemented in EventMachine:
+# 
+#       require 'rubygems'
+#       require 'eventmachine'
+# 
+#       module EchoServer
+#         def receive_data data
+#           send_data ">>>you sent: #{data}"
+#           close_connection if data =~ /quit/i
+#         end
+#       end
+# 
+#       EventMachine::run {
+#         EventMachine::start_server "192.168.0.100", 8081, EchoServer
+#       }
+# 
+# What's going on here? Well, we have defined the module EchoServer to
+# implement the semantics of the echo protocol (more about that shortly).
+# The last three lines invoke the event-machine itself, which runs forever
+# unless one of your callbacks terminates it. The block that you supply
+# to EventMachine::run contains code that runs immediately after the event
+# machine is initialized and before it starts looping. This is the place
+# to open up a TCP server by specifying the address and port it will listen
+# on, together with the module that will process the data.
+# 
+# Our EchoServer is extremely simple as the echo protocol doesn't require
+# much work. Basically you want to send back to the remote peer whatever
+# data it sends you. We'll dress it up with a little extra text to make it
+# interesting. Also, we'll close the connection in case the received data
+# contains the word "quit."
+# 
+# So what about this module EchoServer? Well, whenever a network connection
+# (either a client or a server) starts up, EventMachine instantiates an anonymous
+# class, that your module has been mixed into. Exactly one of these class
+# instances is created for each connection. Whenever an event occurs on a
+# given connection, its corresponding object automatically calls specific
+# instance methods which your module may redefine. The code in your module
+# always runs in the context of a class instance, so you can create instance
+# variables as you wish and they will be carried over to other callbacks
+# made on that same connection.
+# 
+# Looking back up at EchoServer, you can see that we've defined the method
+# receive_data which (big surprise) is called whenever data has been received
+# from the remote end of the connection. Very simple. We get the data
+# (a String object) and can do whatever we wish with it. In this case,
+# we use the method send_data to return the received data to the caller,
+# with some extra text added in. And if the user sends the word "quit,"
+# we'll close the connection with (naturally) close_connection.
+# (Notice that closing the connection doesn't terminate the processing loop,
+# or change the fact that your echo server is still accepting connections!) 
+#
+#
+# == Questions and Futures
+# Encryption: EventMachine needs the capability to run SSL/TLS on any
+# of its clients and servers. Coming soon.
+#
+# <tt>epoll(4):</tt> EventMachine currently is based on the <tt>select(2)</tt>
+# system call in order to be compatible with the widest variety of platforms,
+# but it would be interesting to re-base it on <tt>epoll(4).</tt>
+# While requiring a Linux 2.6 kernel, this might possibly give much better
+# performance and scalability. EventMachine's C++ antecedents already work
+# with <tt>kqueue</tt> from the BSD world, but it's not yet clear that this
+# is worth doing. Depends on how many people ask for it.
+#
+# Would it be useful for EventMachine to incorporate the Observer pattern
+# and make use of the corresponding Ruby <tt>observer</tt> package?
+# Interesting thought.
+#
+# 
+module EventMachine
+
+
+  # EventMachine::run initializes and runs an event loop.
+  # This method only returns if user-callback code calls stop_event_loop.
+  # Use the supplied block to define your clients and servers.
+  # The block is called by EventMachine::run immediately after initializing
+  # its internal event loop but <i>before</i> running the loop.
+  # Therefore this block is the right place to call start_server if you
+  # want to accept connections from remote clients.
+  #
+  # For programs that are structured as servers, it's usually appropriate
+  # to start an event loop by calling EventMachine::run, and let it
+  # run forever. It's also possible to use EventMachine::run to make a single
+  # client-connection to a remote server, process the data flow from that
+  # single connection, and then call stop_event_loop to force EventMachine::run
+  # to return. Your program will then continue from the point immediately
+  # following the call to EventMachine::run.
+  #
+  # You can of course do both client and servers simultaneously in the same program.
+  # One of the strengths of the event-driven programming model is that the
+  # handling of network events on many different connections will be interleaved,
+  # and scheduled according to the actual events themselves. This maximizes
+  # efficiency.
+  #
+  # === Server usage example
+  #
+  # See the text at the top of this file for an example of an echo server.
+  #
+  # === Client usage example
+  #
+  # See the description of stop_event_loop for an extremely simple client example.
+  #
+  #--
+  # Obsoleted the use_threads mechanism.
+  #
+  def EventMachine::run &block
+  #def EventMachine::run use_threads = true, &block
+    @conns = {}
+    @acceptors = {}
+    @timers = {}
+    initialize_event_machine
+    block and add_timer 0, block
+    #use_threads ? run_machine : run_machine_without_threads
+    run_machine
+    release_machine
+  end
+
+  # +deprecated+
+  #--
+  # EventMachine#run_without_threads is semantically identical
+  # to EventMachine#run, but it runs somewhat faster.
+  # However, it must not be used in applications that spin
+  # Ruby threads.
+  def EventMachine::run_without_threads &block
+    #EventMachine::run false, &block
+    EventMachine::run &block
+  end
+
+  # EventMachine#add_timer adds a one-shot timer to the event loop.
+  # Call it with one or two parameters. The first parameters is a delay-time
+  # expressed in <i>seconds</i> (not milliseconds). The second parameter, if
+  # present, must be a proc object. If a proc object is not given, then you
+  # can also simply pass a block to the method call.
+  #
+  # EventMachine#add_timer may be called from the block passed to EventMachine#run
+  # or from any callback method. It schedules execution of the proc or block
+  # passed to add_timer, after the passage of an interval of time equal to
+  # <i>at least</i> the number of seconds specified in the first parameter to
+  # the call.
+  #
+  # EventMachine#add_timer is a <i>non-blocking</i> call. Callbacks can and will
+  # be called during the interval of time that the timer is in effect.
+  # There is no built-in limit to the number of timers that can be outstanding at
+  # any given time.
+  #
+  # === Usage example
+  #
+  # This example shows how easy timers are to use. Observe that two timers are
+  # initiated simultaneously. Also, notice that the event loop will continue
+  # to run even after the second timer event is processed, since there was
+  # no call to EventMachine#stop_event_loop. There will be no activity, of
+  # course, since no network clients or servers are defined. Stop the program
+  # with Ctrl-C.
+  #
+  #  require 'rubygems'
+  #  require 'eventmachine'
+  #
+  #  EventMachine::run {
+  #    puts "Starting the run now: #{Time.now}"
+  #    EventMachine::add_timer 5, proc { puts "Executing timer event: #{Time.now}" }
+  #    EventMachine::add_timer( 10 ) { puts "Executing timer event: #{Time.now}" }
+  #  }
+  #
+  #
+  def EventMachine::add_timer *args, &block
+    interval = args.shift
+    code = args.shift || block
+    if code
+      # check too many timers!
+      s = add_oneshot_timer interval
+      @timers[s] = code
+    end
+  end
+
+  # EventMachine#add_periodic_timer adds a periodic timer to the event loop.
+  # It takes the same parameters as the one-shot timer method, EventMachine#add_timer.
+  # This method schedules execution of the given block repeatedly, at intervals
+  # of time <i>at least</i> as great as the number of seconds given in the first
+  # parameter to the call.
+  # 
+  # === Usage example
+  #
+  # The following sample program will write a dollar-sign to stderr every five seconds.
+  # (Of course if the program defined network clients and/or servers, they would
+  # be doing their work while the periodic timer is counting off.)
+  #
+  #  EventMachine::run {
+  #    EventMachine::add_periodic_timer( 5 ) { $stderr.write "$" }
+  #  }
+  #
+  def EventMachine::add_periodic_timer *args, &block
+    interval = args.shift
+    code = args.shift || block
+    if code
+      block_1 = proc {
+        code.call
+        EventMachine::add_periodic_timer interval, code
+      }
+      add_timer interval, block_1
+    end
+  end
+
+
+  # stop_event_loop may called from within a callback method
+  # while EventMachine's processing loop is running.
+  # It causes the processing loop to stop executing, which
+  # will cause all open connections and accepting servers
+  # to be run down and closed. <i>Callbacks for connection-termination
+  # will be called</i> as part of the processing of stop_event_loop.
+  # (There currently is no option to panic-stop the loop without
+  # closing connections.) When all of this processing is complete,
+  # the call to EventMachine::run which started the processing loop
+  # will return and program flow will resume from the statement
+  # following EventMachine::run call.
+  #
+  # === Usage example
+  #
+  #  require 'rubygems'
+  #  require 'eventmachine'
+  #
+  #  module Redmond
+  #  
+  #    def post_init
+  #      puts "We're sending a dumb HTTP request to the remote peer."
+  #      send_data "GET / HTTP/1.1\r\nHost: www.microsoft.com\r\n\r\n"
+  #    end
+  #  
+  #    def receive_data data
+  #      puts "We received #{data.length} bytes from the remote peer."
+  #      puts "We're going to stop the event loop now."
+  #      EventMachine::stop_event_loop
+  #    end
+  #  
+  #    def unbind
+  #      puts "A connection has terminated."
+  #    end
+  #  
+  #  end
+  #  
+  #  puts "We're starting the event loop now."
+  #  EventMachine::run {
+  #    EventMachine::connect "www.microsoft.com", 80, Redmond
+  #  }
+  #  puts "The event loop has stopped."
+  #  
+  # This program will produce approximately the following output:
+  #
+  #  We're starting the event loop now.
+  #  We're sending a dumb HTTP request to the remote peer.
+  #  We received 1440 bytes from the remote peer.
+  #  We're going to stop the event loop now.
+  #  A connection has terminated.
+  #  The event loop has stopped.
+  #
+  #
+  def EventMachine::stop_event_loop
+    EventMachine::stop
+  end
+
+  # EventMachine::start_server initiates a TCP server (socket
+  # acceptor) on the specified IP address and port.
+  # The IP address must be valid on the machine where the program
+  # runs, and the process must be privileged enough to listen
+  # on the specified port (on Unix-like systems, superuser privileges
+  # are usually required to listen on any port lower than 1024).
+  # Only one listener may be running on any given address/port
+  # combination. start_server will fail if the given address and port
+  # are already listening on the machine, either because of a prior call
+  # to start_server or some unrelated process running on the machine.
+  # If start_server succeeds, the new network listener becomes active
+  # immediately and starts accepting connections from remote peers,
+  # and these connections generate callback events that are processed
+  # by the code specified in the handler parameter to start_server.
+  #
+  # The optional handler which is passed to start_server is the key
+  # to EventMachine's ability to handle particular network protocols.
+  # The handler parameter passed to start_server must be a Ruby Module
+  # that you must define. When the network server that is started by
+  # start_server accepts a new connection, it instantiates a new
+  # object of an anonymous class that is inherited from EventMachine::Connection,
+  # <i>into which the methods from your handler have been mixed.</i>
+  # Your handler module may redefine any of the methods in EventMachine::Connection
+  # in order to implement the specific behavior of the network protocol.
+  #
+  # Callbacks invoked in response to network events <i>always</i> take place
+  # within the execution context of the object derived from EventMachine::Connection
+  # extended by your handler module. There is one object per connection, and
+  # all of the callbacks invoked for a particular connection take the form
+  # of instance methods called against the corresponding EventMachine::Connection
+  # object. Therefore, you are free to define whatever instance variables you
+  # wish, in order to contain the per-connection state required by the network protocol you are
+  # implementing.
+  #
+  # start_server is often called inside the block passed to EventMachine::run,
+  # but it can be called from any EventMachine callback. start_server will fail
+  # unless the EventMachine event loop is currently running (which is why
+  # it's often called in the block suppled to EventMachine::run).
+  #
+  # You may call start_server any number of times to start up network
+  # listeners on different address/port combinations. The servers will
+  # all run simultaneously. More interestingly, each individual call to start_server
+  # can specify a different handler module and thus implement a different
+  # network protocol from all the others.
+  #
+  # === Usage example
+  # Here is an example of a server that counts lines of input from the remote
+  # peer and sends back the total number of lines received, after each line.
+  # Try the example with more than one client connection opened via telnet,
+  # and you will see that the line count increments independently on each
+  # of the client connections. Also very important to note, is that the
+  # handler for the receive_data function, which our handler redefines, may
+  # not assume that the data it receives observes any kind of message boundaries.
+  # Also, to use this example, be sure to change the server and port parameters
+  # to the start_server call to values appropriate for your environment.
+  #
+  #  require 'rubygems'
+  #  require 'eventmachine'
+  #
+  #  module LineCounter
+  #  
+  #    MaxLinesPerConnection = 10
+  #  
+  #    def post_init
+  #      puts "Received a new connection"
+  #      @data_received = ""
+  #      @line_count = 0
+  #    end
+  #  
+  #    def receive_data data
+  #      @data_received << data
+  #      while @data_received.slice!( /^[^\n]*[\n]/m )
+  #        @line_count += 1
+  #        send_data "received #{@line_count} lines so far\r\n"
+  #        @line_count == MaxLinesPerConnection and close_connection_after_writing
+  #      end
+  #    end
+  #  
+  #  end # module LineCounter
+  #  
+  #  EventMachine::run {
+  #    host,port = "192.168.0.100", 8090
+  #    EventMachine::start_server host, port, LineCounter
+  #    puts "Now accepting connections on address #{host}, port #{port}..."
+  #    EventMachine::add_periodic_timer( 10 ) { $stderr.write "*" }
+  #  }
+  #  
+  #
+  def EventMachine::start_server server, port, handler=nil
+    klass = if (handler and handler.is_a?(Class))
+      handler
+    else
+      Class.new( Connection ) {handler and include handler}
+    end
+
+    s = start_tcp_server server, port
+    @acceptors[s] = klass
+  end
+
+  # EventMachine#connect initiates a TCP connection to a remote
+  # server and sets up event-handling for the connection.
+  # You can call EventMachine#connect in the block supplied
+  # to EventMachine#run or in any callback method.
+  #
+  # EventMachine#connect takes the IP address (or hostname) and
+  # port of the remote server you want to connect to.
+  # It also takes an optional handler Module which you must define, that
+  # contains the callbacks that will be invoked by the event loop
+  # on behalf of the connection.
+  #
+  # See the description of EventMachine#start_server for a discussion
+  # of the handler Module. All of the details given in that description
+  # apply for connections created with EventMachine#connect.
+  #
+  # === Usage Example
+  #
+  # Here's a program which connects to a web server, sends a naive
+  # request, parses the HTTP header of the response, and then
+  # (antisocially) ends the event loop, which automatically drops the connection
+  # (and incidentally calls the connection's unbind method).
+  # 
+  #  require 'rubygems'
+  #  require 'eventmachine'
+  #  
+  #  module DumbHttpClient
+  #  
+  #    def post_init
+  #      send_data "GET / HTTP/1.1\r\nHost: _\r\n\r\n"
+  #      @data = ""
+  #    end
+  #  
+  #    def receive_data data
+  #      @data << data
+  #      if  @data =~ /[\n][\r]*[\n]/m
+  #        puts "RECEIVED HTTP HEADER:"
+  #        $`.each {|line| puts ">>> #{line}" }
+  #  
+  #        puts "Now we'll terminate the loop, which will also close the connection"
+  #        EventMachine::stop_event_loop
+  #      end
+  #    end
+  #  
+  #    def unbind
+  #      puts "A connection has terminated"
+  #    end
+  #  
+  #  end # DumbHttpClient
+  #  
+  #  
+  #  EventMachine::run {
+  #    EventMachine::connect "www.bayshorenetworks.com", 80, DumbHttpClient
+  #  }
+  #  puts "The event loop has ended"
+  #  
+  #
+  # There are times when it's more convenient to define a protocol handler
+  # as a Class rather than a Module. Here's how to do this:
+  #
+  #  class MyProtocolHandler < EventMachine::Connection
+  #    def initialize *args
+  #      super
+  #      # whatever else you want to do here
+  #    end
+  #    
+  #    #.......your other class code
+  #  end # class MyProtocolHandler
+  #
+  # If you do this, then an instance of your class will be instantiated to handle
+  # every network connection created by your code or accepted by servers that you
+  # create. If you redefine #post_init in your protocol-handler class, your
+  # #post_init method will be called _inside_ the call to #super that you will
+  # make in your #initialize method (if you provide one).
+  #
+  #--
+  # EventMachine::connect initiates a TCP connection to a remote
+  # server and sets up event-handling for the connection.
+  # It internally creates an object that should not be handled
+  # by the caller. HOWEVER, it's often convenient to get the
+  # object to set up interfacing to other objects in the system.
+  # We return the newly-created anonymous-class object to the caller.
+  # It's expected that a considerable amount of code will depend
+  # on this behavior, so don't change it.
+  #
+  # Ok, added support for a user-defined block, 13Apr06.
+  # This leads us to an interesting choice because of the
+  # presence of the post_init call, which happens in the
+  # initialize method of the new object. We call the user's
+  # block and pass the new object to it. This is a great
+  # way to do protocol-specific initiation. It happens
+  # AFTER post_init has been called on the object, which I
+  # certainly hope is the right choice.
+  # Don't change this lightly, because accepted connections
+  # are different from connected ones and we don't want
+  # to have them behave differently with respect to post_init
+  # if at all possible.
+  #
+  def EventMachine::connect server, port, handler=nil
+
+    klass = if (handler and handler.is_a?(Class))
+      handler
+    else
+      Class.new( Connection ) {handler and include handler}
+    end
+
+    s = connect_server server, port
+    c = klass.new s
+    @conns[s] = c
+    block_given? and yield c
+    c
+  end
+
+
+  # EventMachine#open_datagram_socket is for support of UDP-based
+  # protocols. Its usage is similar to that of EventMachine#start_server.
+  # It takes three parameters: an IP address (which must be valid
+  # on the machine which executes the method), a port number,
+  # and an optional Module name which will handle the data.
+  # This method will create a new UDP (datagram) socket and
+  # bind it to the address and port that you specify.
+  # The normal callbacks (see EventMachine#start_server) will
+  # be called as events of interest occur on the newly-created
+  # socket, but there are some differences in how they behave.
+  #
+  # Connection#receive_data will be called when a datagram packet
+  # is received on the socket, but unlike TCP sockets, the message
+  # boundaries of the received data will be respected. In other words,
+  # if the remote peer sent you a datagram of a particular size,
+  # you may rely on Connection#receive_data to give you the
+  # exact data in the packet, with the original data length.
+  # Also observe that Connection#receive_data may be called with a
+  # <i>zero-length</i> data payload, since empty datagrams are permitted
+  # in UDP.
+  #
+  # Connection#send_data is available with UDP packets as with TCP,
+  # but there is an important difference. Because UDP communications
+  # are <i>connectionless,</i> there is no implicit recipient for the packets you
+  # send. Ordinarily you must specify the recipient for each packet you send.
+  # However, EventMachine
+  # provides for the typical pattern of receiving a UDP datagram
+  # from a remote peer, performing some operation, and then sending
+  # one or more packets in response to the same remote peer.
+  # To support this model easily, just use Connection#send_data
+  # in the code that you supply for Connection:receive_data.
+  # EventMachine will
+  # provide an implicit return address for any messages sent to
+  # Connection#send_data within the context of a Connection#receive_data callback,
+  # and your response will automatically go to the correct remote peer.
+  # (TODO: Example-code needed!)
+  #
+  # Observe that the port number that you supply to EventMachine#open_datagram_socket
+  # may be zero. In this case, EventMachine will create a UDP socket
+  # that is bound to an <i>ephemeral</i> (not well-known) port.
+  # This is not appropriate for servers that must publish a well-known
+  # port to which remote peers may send datagrams. But it can be useful
+  # for clients that send datagrams to other servers.
+  # If you do this, you will receive any responses from the remote
+  # servers through the normal Connection#receive_data callback.
+  # Observe that you will probably have issues with firewalls blocking
+  # the ephemeral port numbers, so this technique is most appropriate for LANs.
+  # (TODO: Need an example!)
+  #
+  # If you wish to send datagrams to arbitrary remote peers (not
+  # necessarily ones that have sent data to which you are responding),
+  # then see Connection#send_datagram.
+  #
+  def self::open_datagram_socket address, port, handler=nil
+    s = open_udp_socket address, port
+    klass = Class.new( Connection ) {
+      handler and include handler
+    }
+    c = klass.new s
+    @conns[s] = c
+    block_given? and yield c
+    c
+  end
+
+
+  private
+  def EventMachine::event_callback conn_binding, opcode, data
+    case opcode
+    when ConnectionData
+      c = @conns[conn_binding] or raise ConnectionNotBound
+      c.receive_data data
+    when ConnectionUnbound
+      if c = @conns.delete( conn_binding )
+        c.unbind
+      elsif c = @acceptors.delete( conn_binding )
+        # no-op
+      else
+        raise ConnectionNotBound
+      end
+    when ConnectionAccepted
+      accep = @acceptors[conn_binding] or raise NoHandlerForAcceptedConnection
+      c = accep.new data
+      @conns[data] = c
+    when TimerFired
+      t = @timers.delete( data ) or raise UnknownTimerFired
+      t.call
+    end
+  end
+
+
+
+# EventMachine::Connection is a class that is instantiated
+# by EventMachine's processing loop whenever a new connection
+# is created. (New connections can be either initiated locally
+# to a remote server or accepted locally from a remote client.)
+# When a Connection object is instantiated, it <i>mixes in</i>
+# the functionality contained in the user-defined module
+# specified in calls to EventMachine#connect or EventMachine#start_server.
+# User-defined handler modules may redefine any or all of the standard
+# methods defined here, as well as add arbitrary additional code
+# that will also be mixed in.
+#
+# EventMachine manages one object inherited from EventMachine::Connection
+# (and containing the mixed-in user code) for every network connection
+# that is active at any given time.
+# The event loop will automatically call methods on EventMachine::Connection
+# objects whenever specific events occur on the corresponding connections,
+# as described below.
+#
+# This class is never instantiated by user code, and does not publish an
+# initialize method. The instance methods of EventMachine::Connection
+# which may be called by the event loop are: post_init, receive_data,
+# and unbind. All of the other instance methods defined here are called
+# only by user code.
+#
+class Connection
+
+  def initialize sig #:nodoc:
+    @signature = sig
+    post_init
+  end
+
+  # EventMachine::Connection#post_init is called by the event loop
+  # immediately after the network connection has been established,
+  # and before resumption of the network loop.
+  # This method is generally not called by user code, but is called automatically
+  # by the event loop. The base-class implementation is a no-op.
+  # This is a very good place to initialize instance variables that will
+  # be used throughout the lifetime of the network connection.
+  #
+  def post_init
+  end
+
+  # EventMachine::Connection#receive_data is called by the event loop
+  # whenever data has been received by the network connection.
+  # It is never called by user code.
+  # receive_data is called with a single parameter, a String containing
+  # the network protocol data, which may of course be binary. You will
+  # generally redefine this method to perform your own processing of the incoming data.
+  #
+  # Here's a key point which is essential to understanding the event-driven
+  # programming model: <i>EventMachine knows absolutely nothing about the protocol
+  # which your code implements.</i> You must not make any assumptions about
+  # the size of the incoming data packets, or about their alignment on any
+  # particular intra-message or PDU boundaries (such as line breaks).
+  # receive_data can and will send you arbitrary chunks of data, with the
+  # only guarantee being that the data is presented to your code in the order
+  # it was collected from the network. Don't even assume that the chunks of
+  # data will correspond to network packets, as EventMachine can and will coalesce
+  # several incoming packets into one, to improve performance. The implication for your
+  # code is that you generally will need to implement some kind of a state machine
+  # in your redefined implementation of receive_data. For a better understanding
+  # of this, read through the examples of specific protocol handlers given
+  # elsewhere in this package. (STUB, WE MUST ADD THESE!)
+  #
+  # The base-class implementation of receive_data (which will be invoked if
+  # you don't redefine it) simply prints the size of each incoming data packet
+  # to stdout.
+  #
+  def receive_data data
+    puts "............>>>#{data.length}"
+  end
+
+  # EventMachine::Connection#unbind is called by the framework whenever a connection
+  # (either a server or client connection) is closed. The close can occur because
+  # your code intentionally closes it (see close_connection and close_connection_after_writing),
+  # because the remote peer closed the connection, or because of a network error.
+  # You may not assume that the network connection is still open and able to send or
+  # receive data when the callback to unbind is made. This is intended only to give
+  # you a chance to clean up associations your code may have made to the connection
+  # object while it was open.
+  #
+  def unbind
+  end
+
+  # EventMachine::Connection#close_connection is called only by user code, and never
+  # by the event loop. You may call this method against a connection object in any
+  # callback handler, whether or not the callback was made against the connection
+  # you want to close. close_connection <i>schedules</i> the connection to be closed
+  # at the next available opportunity within the event loop. You may not assume that
+  # the connection is closed when close_connection returns. In particular, the framework
+  # will callback the unbind method for the particular connection at a point shortly
+  # after you call close_connection. You may assume that the unbind callback will
+  # take place sometime after your call to close_connection completes. In other words,
+  # the unbind callback will not re-enter your code "inside" of your call to close_connection.
+  # However, it's not guaranteed that a future version of EventMachine will not change
+  # this behavior.
+  #
+  # close_connection will <i>silently discard</i> any outbound data which you have
+  # sent to the connection using EventMachine::Connection#send_data but which has not
+  # yet been sent across the network. If you want to avoid this behavior, use
+  # EventMachine::Connection#close_connection_after_writing.
+  #
+  def close_connection after_writing = false
+    EventMachine::close_connection @signature, after_writing
+  end
+
+  # EventMachine::Connection#close_connection_after_writing is a variant of close_connection.
+  # All of the descriptive comments given for close_connection also apply to
+  # close_connection_after_writing, <i>with one exception:</i> If the connection has
+  # outbound data sent using send_dat but which has not yet been sent across the network,
+  # close_connection_after_writing will schedule the connection to be closed <i>after</i>
+  # all of the outbound data has been safely written to the remote peer.
+  #
+  # Depending on the amount of outgoing data and the speed of the network,
+  # considerable time may elapse between your call to close_connection_after_writing
+  # and the actual closing of the socket (at which time the unbind callback will be called
+  # by the event loop). During this time, you <i>may not</i> call send_data to transmit
+  # additional data (that is, the connection is closed for further writes). In very
+  # rare cases, you may experience a receive_data callback after your call to close_connection_after_writing,
+  # depending on whether incoming data was in the process of being received on the connection
+  # at the moment when you called close_connection_after_writing. Your protocol handler must
+  # be prepared to properly deal with such data (probably by ignoring it).
+  #
+  def close_connection_after_writing
+    close_connection true
+  end
+
+  # EventMachine::Connection#send_data is only called by user code, never by
+  # the event loop. You call this method to send data to the remote end of the
+  # network connection. send_data is called with a single String argument, which
+  # may of course contain binary data. You can call send_data any number of times.
+  # send_data is an instance method of an object derived from EventMachine::Connection
+  # and containing your mixed-in handler code), so if you call it without qualification
+  # within a callback function, the data will be sent to the same network connection
+  # that generated the callback. Calling self.send_data is exactly equivalent.
+  #
+  # You can also call send_data to write to a connection <i>other than the one
+  # whose callback you are calling send_data from.</i> This is done by recording
+  # the value of the connection in any callback function (the value self), in any
+  # variable visible to other callback invocations on the same or different
+  # connection objects. (Need an example to make that clear.)
+  #
+  def send_data data
+    EventMachine::send_data @signature, data, data.length
+  end
+
+
+  def start_tls
+    EventMachine::start_tls @signature
+  end
+
+
+  # send_datagram is for sending UDP messages.
+  # This method may be called from any Connection object that refers
+  # to an open datagram socket (see EventMachine#open_datagram_socket).
+  # The method sends a UDP (datagram) packet containing the data you specify,
+  # to a remote peer specified by the IP address and port that you give
+  # as parameters to the method.
+  # Observe that you may send a zero-length packet (empty string).
+  # However, you may not send an arbitrarily-large data packet because
+  # your operating system will enforce a platform-specific limit on
+  # the size of the outbound packet. (Your kernel
+  # will respond in a platform-specific way if you send an overlarge
+  # packet: some will send a truncated packet, some will complain, and
+  # some will silently drop your request).
+  # On LANs, it's usually OK to send datagrams up to about 4000 bytes in length,
+  # but to be really safe, send messages smaller than the Ethernet-packet
+  # size (typically about 1400 bytes). Some very restrictive WANs
+  # will either drop or truncate packets larger than about 500 bytes.
+  #
+  def send_datagram data, recipient_address, recipient_port
+    data = data.to_s
+    EventMachine::send_datagram @signature, data, data.length, recipient_address, recipient_port
+  end
+
+
+end
+
+
+end # module EventMachine
+

data/tests/testem.rb

@@ -0,0 +1,5 @@
+# $Id: testem.rb 2229 2006-04-09 19:03:34Z francis $
+#
+# STUB
+#
+

metadata

@@ -0,0 +1,56 @@
+--- !ruby/object:Gem::Specification 
+rubygems_version: 0.8.11
+specification_version: 1
+name: eventmachine-win32
+version: !ruby/object:Gem::Version 
+  version: 0.5.2
+date: 2006-05-13 00:00:00 -04:00
+summary: Ruby/EventMachine socket engine library- binary gem for Win32
+require_paths: 
+- lib
+email: garbagecat10@gmail.com
+homepage: http://rubyeventmachine.com
+rubyforge_project: eventmachine
+description: ""
+autorequire: 
+default_executable: 
+bindir: bin
+has_rdoc: true
+required_ruby_version: !ruby/object:Gem::Version::Requirement 
+  requirements: 
+  - - ">"
+    - !ruby/object:Gem::Version 
+      version: 0.0.0
+  version: 
+platform: ruby
+signing_key: 
+cert_chain: 
+authors: 
+- Francis Cianfrocca
+files: 
+- tests/testem.rb
+- lib/eventmachine.rb
+- lib/rubyeventmachine.so
+- README
+- RELEASE_NOTES
+- COPYING
+test_files: 
+- tests/testem.rb
+rdoc_options: 
+- --title
+- EventMachine
+- --main
+- README
+- --line-numbers
+extra_rdoc_files: 
+- README
+- RELEASE_NOTES
+- COPYING
+executables: []
+
+extensions: []
+
+requirements: []
+
+dependencies: []
+