FINALLY cleaned up the license text in the source code, clarifying that EM is licensed under either Ruby License or GPL. The rest of the release is just all of the little improvements we''ve been making over the last few months. I''m going to give this a few days for problems to show up in the release, and then I''ll make an announcement on Ruby-talk. Also, watch this space for announcements about the new EM web-and-community site, rubyeventmachine.com. There''s no content up there now, but it''s coming. And I''ll be looking for contributions and suggestions from everyone . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070522/002ed6a4/attachment.html
From: Francis Cianfrocca> > FINALLY cleaned up the license text in the source code, clarifying > that EM is licensed under either Ruby License or GPL. The rest of > the release is just all of the little improvements we''ve been making > over the last few months. I''m going to give this a few days for > problems to show up in the release, and then I''ll make an > announcement on Ruby-talk.Hi Francis, Thanks for the update. Would it be possible to move the WinSock startup from EventMachine_t::Run() to the EventMachine_t constructor? When I use EM without Ruby in the picture, it tries to create the LoopBreaker sockets before WinSock is initialized. I presume this manages to work when Ruby is in the mix, because ruby itself will have already initialized WinSock. Here''s the diff: Index: em.cpp ==================================================================--- em.cpp (revision 324) +++ em.cpp (working copy) @@ -44,6 +44,11 @@ LoopBreakerReader (-1), LoopBreakerWriter (-1) { + #ifdef OS_WIN32 + WSADATA w; + WSAStartup (MAKEWORD (1, 1), &w); + #endif + // Default time-slice is just smaller than one hundred mills. Quantum.tv_sec = 0; Quantum.tv_usec = 90000; @@ -219,8 +224,6 @@ void EventMachine_t::Run() { #ifdef OS_WIN32 - WSADATA w; - WSAStartup (MAKEWORD (1, 1), &w); HookControlC (true); #endif Separately, this is a kludge, but just FYI: in order to access event ID constants like TIMER_FIRED, CONNECTION_READ, etc., from a ''C'' program using EM w/out Ruby involved, I''ve copied the enum from em.h, and duplicated it in eventmachine.h: Index: eventmachine.h ==================================================================--- eventmachine.h (revision 324) +++ eventmachine.h (working copy) @@ -24,6 +24,18 @@ extern "C" { #endif + + // %%BWK -- CRIBBED FROM em.h -- EM needs to make these public for ''C'' programs: + enum { // Event names + TIMER_FIRED = 100, + CONNECTION_READ = 101, + CONNECTION_UNBOUND = 102, + CONNECTION_ACCEPTED = 103, + CONNECTION_COMPLETED = 104, + LOOPBREAK_SIGNAL = 105 + }; + + void evma_initialize_library (void(*)(const char*, int, const char*, int)); void evma_run_machine(); void evma_release_library(); Obviously the duplication is undesirable; but I just wanted to let you know that''s what I''m currently doing. If you have a suggestion for something more appropriate that would eliminate the duplication (maybe a new header file containing just those constants?) then I''d be happy to do it that way and send you a better patch. Regards, Bill
On 5/23/07, Bill Kelly <billk at cts.com> wrote:> > > Thanks for the update. Would it be possible to move the WinSock > startup from EventMachine_t::Run() to the EventMachine_t > constructor? > > When I use EM without Ruby in the picture, it tries to create the > LoopBreaker sockets before WinSock is initialized. > > I presume this manages to work when Ruby is in the mix, because > ruby itself will have already initialized WinSock.That''s obviously a bug. I just fixed it in HEAD. Please sync and try it. Separately, this is a kludge, but just FYI: in order to access> event ID constants like TIMER_FIRED, CONNECTION_READ, etc., from > a ''C'' program using EM w/out Ruby involved, I''ve copied the > enum from em.h, and duplicated it in eventmachine.h:Well, the enum is public and you have to #include em.h anyway, right? So how about you just say EventMachine_t::TIMER_FIRED and such-like in your C code? Unless I''m missing something. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070523/fc0d1bb8/attachment.html
From: Francis Cianfrocca
On 5/23/07, Bill Kelly <billk at cts.com> wrote:
Thanks for the update. Would it be possible to move the WinSock
startup from EventMachine_t::Run() to the EventMachine_t
constructor?
When I use EM without Ruby in the picture, it tries to create the
LoopBreaker sockets before WinSock is initialized.
I presume this manages to work when Ruby is in the mix, because
ruby itself will have already initialized WinSock.
That''s obviously a bug. I just fixed it in HEAD. Please sync and try
it.
Thanks!
Separately, this is a kludge, but just FYI: in order to access
event ID constants like TIMER_FIRED, CONNECTION_READ, etc., from
a ''C'' program using EM w/out Ruby involved, I''ve
copied the
enum from em.h, and duplicated it in eventmachine.h:
Well, the enum is public and you have to #include em.h anyway, right? So how
about you just say
EventMachine_t::TIMER_FIRED
and such-like in your C code? Unless I''m missing something.
I had tried to #include em.h at one point, but I recall there being some
impediments to getting the prerequisites right, to the point that I figured em.h
was probably meant to be a private include file to EM.
I don''t think I ever did get it to compile, but it seemed I needed to
#include project.h and/or do things like: using std::multimap; and using
std::vector. I think I also had a conflict with the Int64 typedef declared in
em.h.
Additionally, EventMachine_t is a C++ class, whereas I''m using the
straight ''C'' API. So currently, there is no way to use just
plain ''C'' and get access to those enums. (Admittedly my
current project is C++ ... however I can imagine wanting to use EM with a
''C'' only project.)
Regards,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070523/18abe595/attachment-0001.html
On 5/23/07, Bill Kelly <billk at cts.com> wrote:> > > had tried to #include em.h at one point, but I recall there being some > impediments to getting the prerequisites right, to the point that I figured > em.h was probably meant to be a private include file to EM. > > I don''t think I ever did get it to compile, but it seemed I needed to > #include project.h and/or do things like: using std::multimap; and using > std::vector. I think I also had a conflict with the Int64 typedef declared > in em.h. > > Additionally, EventMachine_t is a C++ class, whereas I''m using the > straight ''C'' API. So currently, there is no way to use just plain ''C'' and > get access to those enums. (Admittedly my current project is C++ ... > however I can imagine wanting to use EM with a ''C'' only project.) >Now I see where you''re going. In a C program, you should be able to do just this: #include <sys/sockets.h> #include "eventmachine.h" But you''re right, that doesn''t give you the constants. When I get a minute, I''ll refactor to make this possible. Unless you want to give it a shot and send me a patch. I''d take the enum out of em.h and put it in eventmachine.h. It probably won''t compile right off the bat. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070523/70e27d08/attachment.html
From: Francis Cianfrocca> > On 5/23/07, Bill Kelly <billk at cts.com> wrote: > > > > Additionally, EventMachine_t is a C++ class, whereas I''m using > > the straight ''C'' API. So currently, there is no way to use just > > plain ''C'' and get access to those enums. (Admittedly my current > > project is C++ ... however I can imagine wanting to use EM with > > a ''C'' only project.) > > > Now I see where you''re going. In a C program, you should be able to do just this: > > #include <sys/sockets.h> > #include "eventmachine.h " > > But you''re right, that doesn''t give you the constants. When I get a > minute, I''ll refactor to make this possible. Unless you want to give > it a shot and send me a patch. I''d take the enum out of em.h and put > it in eventmachine.h. It probably won''t compile right off the bat. :-)The patch is attached (assuming the list supports attachments.) I left the names of the constants alone. But I wonder, now that they''re in the global namespace, if there might possibly be collisions with names like TIMER_FIRED in some environments? If you think the constants should have a prefix now, like EM_TIMER_FIRED or whatever, let me know and I''ll "make it so." Regards, Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: refactor_event_names_to_eventmachine_h.diff Type: application/octet-stream Size: 3757 bytes Desc: not available Url : http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070523/9a069b91/attachment.obj
From: "Bill Kelly" <billk at cts.com>> > I left the names of the constants alone. But I wonder, now that > they''re in the global namespace, if there might possibly be > collisions with names like TIMER_FIRED in some environments? > > If you think the constants should have a prefix now, like > EM_TIMER_FIRED or whatever, let me know and I''ll "make it so."To clarify, I wasn''t suggesting the prefix be added on the ruby-side. :-) I just wondered, if, on the C/C++ side, a prefix might possibly be warranted since the patch moves the constants into the global namespace. Regards, Bill
On 5/25/07, Bill Kelly <billk at cts.com> wrote:> > > From: "Bill Kelly" <billk at cts.com> > > > I just wondered, if, on the C/C++ side, a prefix might possibly > be warranted since the patch moves the constants into the global > namespace.Definitely add a prefix to these names, if you would. (C doesn''t support namespaces like C++, does it?) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070525/b5fb841f/attachment.html
From: Francis Cianfrocca> > On 5/25/07, Bill Kelly <billk at cts.com> wrote: > > > > I just wondered, if, on the C/C++ side, a prefix might possibly > > be warranted since the patch moves the constants into the global > > namespace. > > Definitely add a prefix to these names, if you would. (C doesn''t > support namespaces like C++, does it?)Not to my knowledge. (Although admittedly I haven''t followed the very latest iterations of the ''C'' standard very closely.) I hate to pester you with trivia... but would you prefer EM_... or EVMA_... ? (Or...?) Regards, Bill
Let''s use EM_* That''s hardly trivial, since we''ll all be lookin'' at it for years to come ;-). On 5/25/07, Bill Kelly <billk at cts.com> wrote:> > > From: Francis Cianfrocca > > > > On 5/25/07, Bill Kelly <billk at cts.com> wrote: > > > > > > I just wondered, if, on the C/C++ side, a prefix might possibly > > > be warranted since the patch moves the constants into the global > > > namespace. > > > > Definitely add a prefix to these names, if you would. (C doesn''t > > support namespaces like C++, does it?) > > Not to my knowledge. (Although admittedly I haven''t followed > the very latest iterations of the ''C'' standard very closely.) > > I hate to pester you with trivia... but would you prefer > EM_... or EVMA_... ? (Or...?) > > > Regards, > > Bill > > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070525/a6d27aaf/attachment.html
From: Francis Cianfrocca> > Let''s use EM_* > > That''s hardly trivial, since we''ll all be lookin'' at it for years to come ;-).:) So let it be written, so let it be done. The new patch is attached. Regards, Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: refactor_event_names_to_eventmachine_h.diff Type: application/octet-stream Size: 4613 bytes Desc: not available Url : http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070525/d723a619/attachment.obj
On 5/26/07, Bill Kelly <billk at cts.com> wrote:> > The new patch is attached.Applied and checked in. Please sync to HEAD and test it. I changed one thing: I moved the #include of eventmachine.h into project.h. I like to put all my includes in one place. Thanks, Bill. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070526/11753f33/attachment.html