From jos at catnook.com Tue Nov 4 15:41:59 2008 From: jos at catnook.com (Jos Backus) Date: Tue, 4 Nov 2008 12:41:59 -0800 Subject: [Mongrel-development] Mongrel doesn't set close-on-exec on its listen socket In-Reply-To: <20080820082737.GA2403@yp-box.dyndns.org> References: <20080722163104.GA82787@lizzy.catnook.local> <20080818215844.GA1441@yp-box.dyndns.org> <20080819030844.GA53303@lizzy.catnook.local> <20080820082737.GA2403@yp-box.dyndns.org> Message-ID: <20081104204159.GA48584@lizzy.catnook.local> On Wed, Aug 20, 2008 at 01:27:37AM -0700, Eric Wong wrote: > Jos Backus wrote: > > On Mon, Aug 18, 2008 at 02:59:21PM -0700, Eric Wong wrote: > > > This probably works: > > > > > > diff --git a/lib/mongrel.rb b/lib/mongrel.rb > > > index 8b5dfe2..027bfdb 100644 > > > --- a/lib/mongrel.rb > > > +++ b/lib/mongrel.rb > > > @@ -91,6 +91,9 @@ module Mongrel > > > > > > tries = 0 > > > @socket = TCPServer.new(host, port) > > > + if defined?(Fcntl::FD_CLOEXEC) > > > + @socket.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) > > > + end > > > > > > @classifier = URIClassifier.new > > > @host = host > > > > Looks reasonable to me. Thanks, Eric. Can somebody commit, please? > > I've just committed it, r1036 to trunk. Thanks for the report! Thanks Eric. The patch is probably incomplete, as I just noticed a problem: /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:94:in `initialize': uninitialized constant Mongrel::HttpServer::Fcntl (NameError) That code doesn't have the defined? test. But even if it did, it wouldn't work as `fcntl' hadn't been require'd so the Fcntl::FD_CLOEXEC constant couldn't be available until it was (if it was available). So the right thing to do is to also apply this patch which explicitly require's `fcntl': --- mongrel.rb- 2008-11-04 15:39:01.000000000 -0500 +++ mongrel.rb 2008-11-04 15:26:38.000000000 -0500 @@ -7,6 +7,7 @@ require 'etc' require 'uri' require 'stringio' +require 'fcntl' # Compiled Mongrel extension require 'http11' -- Jos Backus jos at catnook.com From normalperson at yhbt.net Fri Nov 7 21:15:35 2008 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 7 Nov 2008 18:15:35 -0800 Subject: [Mongrel-development] Mongrel doesn't set close-on-exec on its listen socket In-Reply-To: <20081104204159.GA48584@lizzy.catnook.local> References: <20080722163104.GA82787@lizzy.catnook.local> <20080818215844.GA1441@yp-box.dyndns.org> <20080819030844.GA53303@lizzy.catnook.local> <20080820082737.GA2403@yp-box.dyndns.org> <20081104204159.GA48584@lizzy.catnook.local> Message-ID: <20081108021534.GA27211@yp-box.dyndns.org> Jos Backus wrote: > On Wed, Aug 20, 2008 at 01:27:37AM -0700, Eric Wong wrote: > > Jos Backus wrote: > > > On Mon, Aug 18, 2008 at 02:59:21PM -0700, Eric Wong wrote: > > > > This probably works: > > > > > > Looks reasonable to me. Thanks, Eric. Can somebody commit, please? > > > > I've just committed it, r1036 to trunk. Thanks for the report! > > Thanks Eric. The patch is probably incomplete, as I just noticed a problem: > > /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:94:in > `initialize': uninitialized constant Mongrel::HttpServer::Fcntl (NameError) > > That code doesn't have the defined? test. But even if it did, it wouldn't work > as `fcntl' hadn't been require'd so the Fcntl::FD_CLOEXEC constant couldn't be > available until it was (if it was available). > > So the right thing to do is to also apply this patch which explicitly > require's `fcntl': Applied, thanks! -- Eric Wong From evan at cloudbur.st Mon Nov 17 15:32:33 2008 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 17 Nov 2008 15:32:33 -0500 Subject: [Mongrel-development] Mongrel 2.0 Message-ID: Hi Mongrels, I'm working on trunk and would like to change the following things and release it as a 2.0rc. - Timestamped logging - 1.9.1rc compatibility - Early PID drop - Error code instead of connection-close, as discussed earlier - Option to fork and run from a shared socket on Linux instead of queueing - Move to a Rack handler interface, and include backwards-compatible versions of the current ones - Eliminate gem_plugins - Other random bugfixes from off the trac and github I'm unsure of what to do about mongrel_cluster. Do people still use that? Only for the --clean option? It would be nice if it could go away. At a later date, I would like to include optional ESI parsing to help people's dev environments. Please fuss at me if these are bad. Evan -- Evan Weaver From evan at cloudbur.st Mon Nov 17 15:33:12 2008 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 17 Nov 2008 15:33:12 -0500 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: Message-ID: Also, I will document the release process. Evan On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver wrote: > Hi Mongrels, > > I'm working on trunk and would like to change the following things and > release it as a 2.0rc. > > - Timestamped logging > - 1.9.1rc compatibility > - Early PID drop > - Error code instead of connection-close, as discussed earlier > - Option to fork and run from a shared socket on Linux instead of queueing > - Move to a Rack handler interface, and include backwards-compatible > versions of the current ones > - Eliminate gem_plugins > - Other random bugfixes from off the trac and github > > I'm unsure of what to do about mongrel_cluster. Do people still use > that? Only for the --clean option? It would be nice if it could go > away. > > At a later date, I would like to include optional ESI parsing to help > people's dev environments. > > Please fuss at me if these are bad. > > Evan > > -- > Evan Weaver > -- Evan Weaver From ezmobius at gmail.com Mon Nov 17 15:47:12 2008 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Mon, 17 Nov 2008 12:47:12 -0800 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: Message-ID: These all look good to me. If you move the --clean option into mongrel proper then we no longer need mongrel_cluster afaik. Cheers- -Ezra On Nov 17, 2008, at 12:33 PM, Evan Weaver wrote: > Also, I will document the release process. > > Evan > > On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver wrote: >> Hi Mongrels, >> >> I'm working on trunk and would like to change the following things >> and >> release it as a 2.0rc. >> >> - Timestamped logging >> - 1.9.1rc compatibility >> - Early PID drop >> - Error code instead of connection-close, as discussed earlier >> - Option to fork and run from a shared socket on Linux instead of >> queueing >> - Move to a Rack handler interface, and include backwards-compatible >> versions of the current ones >> - Eliminate gem_plugins >> - Other random bugfixes from off the trac and github >> >> I'm unsure of what to do about mongrel_cluster. Do people still use >> that? Only for the --clean option? It would be nice if it could go >> away. >> >> At a later date, I would like to include optional ESI parsing to help >> people's dev environments. >> >> Please fuss at me if these are bad. >> >> Evan >> >> -- >> Evan Weaver >> > > > > -- > Evan Weaver > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development Ezra Zygmuntowicz ez at engineyard.com From filipe at icewall.org Mon Nov 17 17:55:22 2008 From: filipe at icewall.org (Filipe Lautert) Date: Mon, 17 Nov 2008 20:55:22 -0200 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References:

Message-ID: <4921F65A.4030202@icewall.org> Someone is doing dev work? whow Nice mate, go ahead! I can help after the first rc to find bugs/close them. Cheers filipe Ezra Zygmuntowicz wrote: > > These all look good to me. If you move the --clean option into > mongrel proper then we no longer need mongrel_cluster afaik. > > Cheers- > -Ezra > > > On Nov 17, 2008, at 12:33 PM, Evan Weaver wrote: > >> Also, I will document the release process. >> >> Evan >> >> On Mon, Nov 17, 2008 at 3:32 PM, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> I'm working on trunk and would like to change the following things and >>> release it as a 2.0rc. >>> >>> - Timestamped logging >>> - 1.9.1rc compatibility >>> - Early PID drop >>> - Error code instead of connection-close, as discussed earlier >>> - Option to fork and run from a shared socket on Linux instead of >>> queueing >>> - Move to a Rack handler interface, and include backwards-compatible >>> versions of the current ones >>> - Eliminate gem_plugins >>> - Other random bugfixes from off the trac and github >>> >>> I'm unsure of what to do about mongrel_cluster. Do people still use >>> that? Only for the --clean option? It would be nice if it could go >>> away. >>> >>> At a later date, I would like to include optional ESI parsing to help >>> people's dev environments. >>> >>> Please fuss at me if these are bad. >>> >>> Evan >>> >>> -- >>> Evan Weaver >>> >> >> >> >> -- >> Evan Weaver >> _______________________________________________ >> Mongrel-development mailing list >> Mongrel-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-development > > Ezra Zygmuntowicz > ez at engineyard.com > > > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development From zedshaw at zedshaw.com Tue Nov 18 00:36:29 2008 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Mon, 17 Nov 2008 21:36:29 -0800 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: Message-ID: <20081118053629.GK1405@zedshaw> Very cool, nice work. One small comment... On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: > Hi Mongrels, > > - Error code instead of connection-close, as discussed earlier With this do you mean returning one of the many error codes in an HTTP response when the server is overloaded? I would recommend against that if that's the case. In theory it's nice to return an error code to clients that could be waiting. In practice, your queue is already overloaded, so taking more time to send a response to clients only adds to the problem. In a modern system this isn't such a big deal, but in Ruby it becomes a mess because of the file id limits in the select loop. I'd say, if you add that, make it optional to turn it off and be prepared with a FAQ about it in case people have problems. Have fun. -- Zed A. Shaw http://freehackersunion.org/ From evan at cloudbur.st Tue Nov 18 00:49:14 2008 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 18 Nov 2008 00:49:14 -0500 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: <20081118053629.GK1405@zedshaw> References: <20081118053629.GK1405@zedshaw> Message-ID: Optional is a good compromise. Evan On Tue, Nov 18, 2008 at 12:36 AM, Zed A. Shaw wrote: > Very cool, nice work. One small comment... > > On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >> Hi Mongrels, >> >> - Error code instead of connection-close, as discussed earlier > > With this do you mean returning one of the many error codes in an HTTP > response when the server is overloaded? > > I would recommend against that if that's the case. In theory it's nice > to return an error code to clients that could be waiting. In practice, > your queue is already overloaded, so taking more time to send a response > to clients only adds to the problem. In a modern system this isn't such > a big deal, but in Ruby it becomes a mess because of the file id limits > in the select loop. > > I'd say, if you add that, make it optional to turn it off and be > prepared with a FAQ about it in case people have problems. > > Have fun. > > -- > Zed A. Shaw > http://freehackersunion.org/ > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver From wyhaines at gmail.com Tue Nov 18 09:59:51 2008 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 18 Nov 2008 07:59:51 -0700 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: <20081118053629.GK1405@zedshaw> References: <20081118053629.GK1405@zedshaw> Message-ID: On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw wrote: > Very cool, nice work. One small comment... > > On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >> Hi Mongrels, >> >> - Error code instead of connection-close, as discussed earlier > > With this do you mean returning one of the many error codes in an HTTP > response when the server is overloaded? > > I would recommend against that if that's the case. In theory it's nice > to return an error code to clients that could be waiting. In practice, > your queue is already overloaded, so taking more time to send a response > to clients only adds to the problem. In a modern system this isn't such > a big deal, but in Ruby it becomes a mess because of the file id limits > in the select loop. In an overload situation, I think that just dropping the connection is an acceptable thing to do, though. The mongrel is overloaded, so it is a correct and beneficial response on the part of the proxy to assume something is wrong with it, and to stop sending traffic to it for a while. The use case for sending a response instead of just dropping the connection is when the HTTP parser throws an exception because of malformed HTTP. Currently that results in an immediate closed connection. The problem there is that upstream proxies can assume that getting the connection cut unexpectedly means that the mongrel itself has a problem. If that proxy responds to this by removing that mongrel from the proxy rotation for a period of time, one misbehaving client, whether intentionally or unintentionally, can DOS a whole cluster. The fix is to just return a canned 400 response before closing. Kirk Haines From evan at cloudbur.st Tue Nov 18 11:22:44 2008 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 18 Nov 2008 11:22:44 -0500 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: <20081118053629.GK1405@zedshaw> Message-ID: Whether the mongrel is overloaded such that responding further degrades service depends on whether you are blocked on local CPU or on a shared resource. In my experience, shared resource problems are more common. Evan On 11/18/08, Kirk Haines wrote: > On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw wrote: >> Very cool, nice work. One small comment... >> >> On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> - Error code instead of connection-close, as discussed earlier >> >> With this do you mean returning one of the many error codes in an HTTP >> response when the server is overloaded? >> >> I would recommend against that if that's the case. In theory it's nice >> to return an error code to clients that could be waiting. In practice, >> your queue is already overloaded, so taking more time to send a response >> to clients only adds to the problem. In a modern system this isn't such >> a big deal, but in Ruby it becomes a mess because of the file id limits >> in the select loop. > > In an overload situation, I think that just dropping the connection is > an acceptable thing to do, though. The mongrel is overloaded, so it > is a correct and beneficial response on the part of the proxy to > assume something is wrong with it, and to stop sending traffic to it > for a while. > > The use case for sending a response instead of just dropping the > connection is when the HTTP parser throws an exception because of > malformed HTTP. > > Currently that results in an immediate closed connection. The problem > there is that upstream proxies can assume that getting the connection > cut unexpectedly means that the mongrel itself has a problem. If that > proxy responds to this by removing that mongrel from the proxy > rotation for a period of time, one misbehaving client, whether > intentionally or unintentionally, can DOS a whole cluster. > > The fix is to just return a canned 400 response before closing. > > > Kirk Haines > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver From wayneeseguin at gmail.com Wed Nov 19 21:31:49 2008 From: wayneeseguin at gmail.com (Wayne Seguin) Date: Wed, 19 Nov 2008 21:31:49 -0500 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: <20081118053629.GK1405@zedshaw> Message-ID: <4FF8586B-5B06-4F63-8A10-531AAC942EB3@gmail.com> Evan, I believe that optional with default being to drop the connection would be best in this case. It will serve the 98% case just fine and for those who are more demanding they can opt in. The rest look like a good set for a 2.0 release to me. ~Wayne On Nov 18, 2008, at 00:49 , Evan Weaver wrote: > Optional is a good compromise. > > Evan > > On Tue, Nov 18, 2008 at 12:36 AM, Zed A. Shaw > wrote: >> Very cool, nice work. One small comment... >> >> On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> - Error code instead of connection-close, as discussed earlier >> >> With this do you mean returning one of the many error codes in an >> HTTP >> response when the server is overloaded? >> >> I would recommend against that if that's the case. In theory it's >> nice >> to return an error code to clients that could be waiting. In >> practice, >> your queue is already overloaded, so taking more time to send a >> response >> to clients only adds to the problem. In a modern system this isn't >> such >> a big deal, but in Ruby it becomes a mess because of the file id >> limits >> in the select loop. >> >> I'd say, if you add that, make it optional to turn it off and be >> prepared with a FAQ about it in case people have problems. >> >> Have fun. >> >> -- >> Zed A. Shaw >> http://freehackersunion.org/ >> _______________________________________________ >> Mongrel-development mailing list >> Mongrel-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-development >> > > > > -- > Evan Weaver > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development From luislavena at gmail.com Wed Nov 19 22:09:13 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 20 Nov 2008 01:09:13 -0200 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: Message-ID: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283@mail.gmail.com> On Mon, Nov 17, 2008 at 6:32 PM, Evan Weaver wrote: > Hi Mongrels, > > I'm working on trunk and would like to change the following things and > release it as a 2.0rc. > > - Timestamped logging > - 1.9.1rc compatibility > - Early PID drop > - Error code instead of connection-close, as discussed earlier > - Option to fork and run from a shared socket on Linux instead of queueing Can you give more details on this? > - Move to a Rack handler interface, and include backwards-compatible > versions of the current ones How this will overlap / affect / interfere Rack and it's own handler for mongrel? > - Eliminate gem_plugins > - Other random bugfixes from off the trac and github > I'll really liek to have mongrel repository moved to git prior the release, I lost track of all the branches and what is current the past months... > I'm unsure of what to do about mongrel_cluster. Do people still use > that? Only for the --clean option? It would be nice if it could go > away. > > At a later date, I would like to include optional ESI parsing to help > people's dev environments. > > Please fuss at me if these are bad. > Most of thos looks good, but hearing more the details of some points details will help me a bit. For the record, I'm working on some rake helpers to ease the building of all the gems and also cross compilation, with the goal that noone needs me or Windows to be able to release gems for the platform. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From wyhaines at gmail.com Wed Nov 19 23:39:33 2008 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 19 Nov 2008 21:39:33 -0700 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283@mail.gmail.com> References: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283@mail.gmail.com> Message-ID: >> - Option to fork and run from a shared socket on Linux instead of queueing > > Can you give more details on this? On Linux (and some other *nixes), there's a funky little thing that happens when a process that is bound to a socket is forked. All of the forked processes are also bound to the socket, and the kernel will distribute connections between them. It's a low cost way to load balance between workers on a machine that is running an OS which will support it. Kirk Haines From tony at medioh.com Thu Nov 20 00:54:38 2008 From: tony at medioh.com (Tony Arcieri) Date: Wed, 19 Nov 2008 22:54:38 -0700 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283@mail.gmail.com> Message-ID: On Wed, Nov 19, 2008 at 9:39 PM, Kirk Haines wrote: > On Linux (and some other *nixes), there's a funky little thing that > happens when a process that is bound to a socket is forked. > > All of the forked processes are also bound to the socket, and the > kernel will distribute connections between them. It's a low cost way > to load balance between workers on a machine that is running an OS > which will support it. > Prefork servers should be fairly portable. Any reason why you aren't trying this on other platforms? -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan at cloudbur.st Fri Nov 21 13:03:12 2008 From: evan at cloudbur.st (Evan Weaver) Date: Fri, 21 Nov 2008 10:03:12 -0800 Subject: [Mongrel-development] Mongrel 2.0 In-Reply-To: References: <71166b3b0811191909n6ad79b3cse89be4b9c50b8283@mail.gmail.com> Message-ID: I was under the impression that it wasn't portable. If it is, that would be great. Evan On Wed, Nov 19, 2008 at 9:54 PM, Tony Arcieri wrote: > On Wed, Nov 19, 2008 at 9:39 PM, Kirk Haines wrote: >> >> On Linux (and some other *nixes), there's a funky little thing that >> happens when a process that is bound to a socket is forked. >> >> All of the forked processes are also bound to the socket, and the >> kernel will distribute connections between them. It's a low cost way >> to load balance between workers on a machine that is running an OS >> which will support it. > > Prefork servers should be fairly portable. Any reason why you aren't trying > this on other platforms? > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development > > -- Evan Weaver From luislavena at gmail.com Sun Nov 30 10:37:49 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 30 Nov 2008 10:37:49 -0500 Subject: [Mongrel-development] ANN: rake-compiler 0.2.1 Message-ID: <71166b3b0811300737vfbce944k1421b5798fc7c909@mail.gmail.com> Hello Rubysts: I'll like to introduce you rake-compiler gem version 0.2.1 rake-compiler aims to help Gem developers while dealing with Ruby C extensions, simplifying the code and reducing the duplication. It follows *convention over configuration* and set an standardized structure to build and package C extensions in your gems. This is the result of experiences dealing with several Gems that required native extensions across platforms and different user configurations where details like portability and clarity of code were lacking. http://github.com/luislavena/rake-compiler/tree/master == Current functionality: * One-liner to be able to compile extensions using Rake * One-liner to be able to package native extensions into Gems. * 3 Lines of code to be able to cross compile extensions for Windows from Linux or OSX * Same 3 lines of code to be able to package those extensions into Gems for Windows. I know 3 lines sounds a lot... but compared to current alternatives (ala: none), 3 lines is cheap. == How to get it Right now it's only available at github: gem install luislavena-rake-compiler --source http://gems.github.com Soon at rubyforge, both will be keep on sync. == Integration You can use any gem packaging and releasing tool with rake-compiler (Hoe, Echoe, MrBones, etc). It doesn't interfere as long you can provide a Gem::Specification to hook into the native gems generation. == Target audience rake-compiler is not only to generate gems for Windows. Under certain circumstances users request binary gems for Linux since their production servers lack the build tools available under development environments. This solution ease the path on all these fields. == Feedback While there is no project page for it (yet), I encourage users send their feedback to Ruby Installer development mailing list. rake-compiler is a side project of One-Click Installer and attempts reduce the gap between users across platforms. == Thanks Several users contributed to make this project a reality, which includes: * Aaron Patterson from nokogiri for the simplified cross compile ruby tasks that inspired the ones implemented in this project * Dan Kubb from DataMapper and DataObjects for care about support of Windows users. * Jonathan Stott from DataMapper and DataObjects for hacking in cross compilation into DO and playing with the workflow Thanks to everyone for their support and feedback during the development of this project! -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams