Hey so, People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the point of 1.9 for library developers to have time to get ready for 2.0? It''s not like 1.9 is a production release. Evan -- Evan Weaver Cloudburst, LLC
On Dec 11, 2007 2:57 PM, Evan Weaver <evan at cloudbur.st> wrote:> Hey so, > > People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the > point of 1.9 for library developers to have time to get ready for 2.0? > It''s not like 1.9 is a production release. >Exactly. 1.9 (odd numebering) is a development release, not a stable one. Getting reading for 1.9 is a on-going process, mostly due changes Matz and others are implementing (also the new UTF and encoding functionality). Guess lot of projects will require partial rewrite to avoid the deprecations of 1.9. So, for users asking: is mongrel 1.9?... will be, that takes time. We have 1 year ahead to make it compatible. Stop bugging us! :D -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 11, 2007 11:02 AM, Luis Lavena <luislavena at gmail.com> wrote:> So, for users asking: is mongrel 1.9?... will be, that takes time. We > have 1 year ahead to make it compatible. > > Stop bugging us! :DYeah. 1.9 is a moving target. It _may_ not take a lot to make mongrel work with it, but it may take quite a bit more labor to make Mongrel work with it in an optimal way. The switch to native threads means that the thread-per-request approach gets more complex, for instance. Left as is, performance will probaby suffer substantially, as native threads are a lot more expensive to create than Ruby green threads. We should probably start thinking about and talking about these issues so that we don''t get too far behind the curve, but having a 1.9-compatible/2.0 read Mongrel is going to take time. Kirk
> On Dec 11, 2007 2:57 PM, Evan Weaver <evan at cloudbur.st> wrote: > People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the > point of 1.9 for library developers to have time to get ready for 2.0? > It''s not like 1.9 is a production release.1.9.1 is a production release. I think the point is to bridge 1.8 and 2.0 for all users, not just library developers. On 12/11/07, Luis Lavena <luislavena at gmail.com> wrote:> Exactly. 1.9 (odd numebering) is a development release, not a stable one.This is no longer true since last RubyKaigi 2006: Matz announced 1.9.1 is the next stable release, aiming for Christmas 2007. However, this October he said Ruby 1.8 will remain the stable Ruby for the first half of 2008.> Getting reading for 1.9 is a on-going process, mostly due changes Matz > and others are implementing (also the new UTF and encoding > functionality). > > Guess lot of projects will require partial rewrite to avoid the > deprecations of 1.9. > > So, for users asking: is mongrel 1.9?... will be, that takes time. We > have 1 year ahead to make it compatible. > > Stop bugging us! :DIt will take time to update for 1.9, but the sooner the better. Best, jeremy
So there will be two different stable Rubys, and everyone has to be compatible with both of them? Ugh. Evan On Dec 11, 2007 1:20 PM, Jeremy Kemper <jeremy at bitsweat.net> wrote:> > On Dec 11, 2007 2:57 PM, Evan Weaver <evan at cloudbur.st> wrote: > > People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the > > point of 1.9 for library developers to have time to get ready for 2.0? > > It''s not like 1.9 is a production release. > > 1.9.1 is a production release. I think the point is to bridge 1.8 and > 2.0 for all users, not just library developers. > > On 12/11/07, Luis Lavena <luislavena at gmail.com> wrote: > > Exactly. 1.9 (odd numebering) is a development release, not a stable one. > > This is no longer true since last RubyKaigi 2006: Matz announced 1.9.1 > is the next stable release, aiming for Christmas 2007. However, this > October he said Ruby 1.8 will remain the stable Ruby for the first > half of 2008. > > > Getting reading for 1.9 is a on-going process, mostly due changes Matz > > and others are implementing (also the new UTF and encoding > > functionality). > > > > Guess lot of projects will require partial rewrite to avoid the > > deprecations of 1.9. > > > > So, for users asking: is mongrel 1.9?... will be, that takes time. We > > have 1 year ahead to make it compatible. > > > > Stop bugging us! :D > > It will take time to update for 1.9, but the sooner the better. > > Best, > jeremy > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Tue, 11 Dec 2007, Evan Weaver wrote:> So there will be two different stable Rubys, and everyone has to be > compatible with both of them? Ugh.Yeap, kind of. Did anyone here try to run mongrel with ruby 1.9? I already played with ruby1.9 for a while migrating debian packages, so I would be interested in help with this ''port''.>> >> It will take time to update for 1.9, but the sooner the better. >>Yeah.... u are right. Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru }
Mongrel will probably run with minor changes on 1.9. It will definitely not run well, because (like Kirk says) having a process-level thread queue will destroy your performance under load in short order. It would be nice to move to something simple and eventy, like just select() polling maybe. No dependencies. Evan On Dec 11, 2007 1:39 PM, Filipe <filipe at icewall.org> wrote:> On Tue, 11 Dec 2007, Evan Weaver wrote: > > > So there will be two different stable Rubys, and everyone has to be > > compatible with both of them? Ugh. > > Yeap, kind of. Did anyone here try to run mongrel with ruby 1.9? I > already played with ruby1.9 for a while migrating debian packages, so I > would be interested in help with this ''port''. > > >> > >> It will take time to update for 1.9, but the sooner the better. > >> > > Yeah.... u are right. > > Cheers, > > filipe { > @ icewall.org > GPG 1024D/A6BA423E > Jabber lautert at jabber.ru > > } > > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Ruby-core:> As I said before we try our best to stabilize features before > Christmas. 1.9.1 on Christmas will not be as stable as you (or we) > expected. > > matz.On Dec 11, 2007 1:43 PM, Evan Weaver <evan at cloudbur.st> wrote:> Mongrel will probably run with minor changes on 1.9. It will > definitely not run well, because (like Kirk says) having a > process-level thread queue will destroy your performance under load in > short order. > > It would be nice to move to something simple and eventy, like just > select() polling maybe. No dependencies. > > Evan > > > On Dec 11, 2007 1:39 PM, Filipe <filipe at icewall.org> wrote: > > On Tue, 11 Dec 2007, Evan Weaver wrote: > > > > > So there will be two different stable Rubys, and everyone has to be > > > compatible with both of them? Ugh. > > > > Yeap, kind of. Did anyone here try to run mongrel with ruby 1.9? I > > already played with ruby1.9 for a while migrating debian packages, so I > > would be interested in help with this ''port''. > > > > >> > > >> It will take time to update for 1.9, but the sooner the better. > > >> > > > > Yeah.... u are right. > > > > Cheers, > > > > filipe { > > @ icewall.org > > GPG 1024D/A6BA423E > > Jabber lautert at jabber.ru > > > > } > > > > > > _______________________________________________ > > Mongrel-development mailing list > > Mongrel-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-development > > > > > > -- > Evan Weaver > Cloudburst, LLC >-- Evan Weaver Cloudburst, LLC
I believe someone committed some changes to the http parser from me that make it work on Ruby 1.9. (Very minor things like str->ptr to RSTRING_PTR(str).) So last time I checked (2 or 3 months ago), the C part of mongrel was passing tests in 1.9. ry
On Dec 11, 2007 4:39 PM, ry dahl <ry at tinyclouds.org> wrote:> I believe someone committed some changes to the http parser from me > that make it work on Ruby 1.9. (Very minor things like str->ptr to > RSTRING_PTR(str).) So last time I checked (2 or 3 months ago), the C > part of mongrel was passing tests in 1.9. >yes, we discussed that on #mongrel-dev channel. The thing is that 1.9.1 will be a base for the upcoming 2.0 (were community will decide which feature will made into 2.0 or should be dropped). Even I like the performance boost of 1.9, and even I like the bleeding edge stuff, I don''t see me running a production quality server/application on 1.9.1 this january. As example, lot of things Rails do will be broken in 1.9, and they need to fix that before we jump into the interpreter/VM switch. Also, the green vs. native thread is a huge change, and that will require a lot of time to get a working, stable and optimized solution to it. I think Fibers will suit best our requirements? [1] [2] anyway, need a deep analysis prior jumping into the Wow 1.9 YARV bandwagon. [1] http://www.infoq.com/news/2007/08/ruby-1-9-fibers [2] http://www.davidflanagan.com/blog/2007_08.html#000139 -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 11 Dec 2007, ry dahl wrote:> I believe someone committed some changes to the http parser from me > that make it work on Ruby 1.9. (Very minor things like str->ptr to > RSTRING_PTR(str).) So last time I checked (2 or 3 months ago), the C > part of mongrel was passing tests in 1.9. >Now i commited this :D Also, two changes for 2 classes that had problems with ruby 1.9. Now it builds for ruby 1.8 and 1.9 . Next step is make is pass all the tests. Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFHXyOomKFbPqa6Qj4RAir4AJYmm4MNNl36QoSs58poVKzbwwRNAKCIGIC6 6Ty/aqUpm2OHKVKRUr5tQg==34br -----END PGP SIGNATURE-----
Fibers don''t do any scheduling for you. We''d have to reimplement half of green threads in them. Evan On Dec 11, 2007 6:51 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Dec 11, 2007 4:39 PM, ry dahl <ry at tinyclouds.org> wrote: > > I believe someone committed some changes to the http parser from me > > that make it work on Ruby 1.9. (Very minor things like str->ptr to > > RSTRING_PTR(str).) So last time I checked (2 or 3 months ago), the C > > part of mongrel was passing tests in 1.9. > > > > yes, we discussed that on #mongrel-dev channel. > > The thing is that 1.9.1 will be a base for the upcoming 2.0 (were > community will decide which feature will made into 2.0 or should be > dropped). > > Even I like the performance boost of 1.9, and even I like the bleeding > edge stuff, I don''t see me running a production quality > server/application on 1.9.1 this january. > > As example, lot of things Rails do will be broken in 1.9, and they > need to fix that before we jump into the interpreter/VM switch. > > Also, the green vs. native thread is a huge change, and that will > require a lot of time to get a working, stable and optimized solution > to it. > > I think Fibers will suit best our requirements? [1] [2] anyway, need a > deep analysis prior jumping into the Wow 1.9 YARV bandwagon. > > [1] http://www.infoq.com/news/2007/08/ruby-1-9-fibers > [2] http://www.davidflanagan.com/blog/2007_08.html#000139 > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
Should we just target 1.2 for YARV compat? And forget about point releases for 1.1? Evan On Dec 11, 2007 6:56 PM, Filipe <filipe at icewall.org> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 11 Dec 2007, ry dahl wrote: > > > I believe someone committed some changes to the http parser from me > > that make it work on Ruby 1.9. (Very minor things like str->ptr to > > RSTRING_PTR(str).) So last time I checked (2 or 3 months ago), the C > > part of mongrel was passing tests in 1.9. > > > > Now i commited this :D > > Also, two changes for 2 classes that had problems with ruby 1.9. Now it > builds for ruby 1.8 and 1.9 . Next step is make is pass all the tests. > > Cheers, > > filipe { > @ icewall.org > GPG 1024D/A6BA423E > Jabber lautert at jabber.ru > } > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD4DBQFHXyOomKFbPqa6Qj4RAir4AJYmm4MNNl36QoSs58poVKzbwwRNAKCIGIC6 > 6Ty/aqUpm2OHKVKRUr5tQg=> =34br > -----END PGP SIGNATURE----- > > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Dec 11, 2007 8:59 PM, Evan Weaver <evan at cloudbur.st> wrote:> Should we just target 1.2 for YARV compat? And forget about point > releases for 1.1? >Hold on a bit... :D We should be doing the 1.2 or YARV compatibility under a branch, and not trunk. Leave trunk for bugfixes to current stable or released code and backport them to the branch. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Tue, 11 Dec 2007 13:34:30 -0500 "Evan Weaver" <evan at cloudbur.st> wrote:> So there will be two different stable Rubys, and everyone has to be > compatible with both of them? Ugh.Yay! I love Ruby! -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Tue, 11 Dec 2007 13:43:20 -0500 "Evan Weaver" <evan at cloudbur.st> wrote:> Mongrel will probably run with minor changes on 1.9. It will > definitely not run well, because (like Kirk says) having a > process-level thread queue will destroy your performance under load in > short order. > > It would be nice to move to something simple and eventy, like just > select() polling maybe. No dependencies.A fellow contacted me earlier today about the possiblity of resurrecting my Ruby/Event module (a nice ruby wrapper around libevent) under 1.9. Apparently 1.9 will have an idle real thread that you can put stuff like libevent callbacks and running inside. Sure as hell no have no idea about the actual thread locking requirements of such a hack, but if it is doable then I might give it a try. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Dec 11, 2007 9:36 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Tue, 11 Dec 2007 18:59:35 -0500 > "Evan Weaver" <evan at cloudbur.st> wrote: > > > Should we just target 1.2 for YARV compat? And forget about point > > releases for 1.1? > > Hell, while you''re at it, why not try a pure ruby http parser that is > generated from Ragel and see if it gets decent perf on 1.9. Might be a > good time to give that a try. >Great Idea, removing the c dependency will ease the path to rubinius too (even they got substend part of mongrel working already). -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Tue, 11 Dec 2007 18:59:35 -0500 "Evan Weaver" <evan at cloudbur.st> wrote:> Should we just target 1.2 for YARV compat? And forget about point > releases for 1.1?Hell, while you''re at it, why not try a pure ruby http parser that is generated from Ragel and see if it gets decent perf on 1.9. Might be a good time to give that a try. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Tue, 11 Dec 2007, Luis Lavena wrote:> On Dec 11, 2007 9:36 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote: >> On Tue, 11 Dec 2007 18:59:35 -0500 >> "Evan Weaver" <evan at cloudbur.st> wrote: >> >>> Should we just target 1.2 for YARV compat? And forget about point >>> releases for 1.1? >> >> Hell, while you''re at it, why not try a pure ruby http parser that is >> generated from Ragel and see if it gets decent perf on 1.9. Might be a >> good time to give that a try. >> > > Great Idea, removing the c dependency will ease the path to rubinius > too (even they got substend part of mongrel working already).Yeah, this would be cool. Anyway, small changes to support ruby 1.9 will not hurt anyone. for instance, just a simple diff with less than 10 lines makes mongrel compile on ruby 1.8/ruby1.9 . But if we could be a ruby only project this would be superb! cheers, filipe
actually i''ve done that - although it''s not operational yet when i realized it was noticeably slower running the unit tests i gave up i can commit the code if anyone wants to check it out ry On Dec 11, 2007 4:36 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Tue, 11 Dec 2007 18:59:35 -0500 > "Evan Weaver" <evan at cloudbur.st> wrote: > > > Should we just target 1.2 for YARV compat? And forget about point > > releases for 1.1? > > Hell, while you''re at it, why not try a pure ruby http parser that is > generated from Ragel and see if it gets decent perf on 1.9. Might be a > good time to give that a try. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >
On Dec 11, 2007 11:44 PM, ry dahl <ry at tinyclouds.org> wrote:> actually i''ve done that - although it''s not operational yet > when i realized it was noticeably slower running the unit tests i gave up > i can commit the code if anyone wants to check it out >If you do try to branch it to avoid problems with trunk (which is almost "stable") or put inside a place where is not called at all and we can look at it (like lib/experimental or something). -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
p.s.: it doesn''t conform exactly to the C''s API - i was just trying to get it to pass all the tests first (it shouldn''t be hard to change things to be that way). i think if someone can get it to pass that dumbfuck_headers test, it would be functional. On Dec 11, 2007 7:08 PM, ry dahl <ry at tinyclouds.org> wrote:> er, here i''ll just tar it up. when i run the tests i get this: > > ..E.. > Finished in 0.488298 seconds. > > 1) Error: > test_parse_dumbfuck_headers(HttpParserTest): > HttpParser::ParseError: HttpParser::ParseError > ./http11.rb:466:in `execute'' > ./test.rb:57:in `test_parse_dumbfuck_headers'' > > 5 tests, 15 assertions, 0 failures, 1 errors > > > > > > > On Dec 11, 2007 6:48 PM, Luis Lavena <luislavena at gmail.com> wrote: > > On Dec 11, 2007 11:44 PM, ry dahl <ry at tinyclouds.org> wrote: > > > actually i''ve done that - although it''s not operational yet > > > when i realized it was noticeably slower running the unit tests i gave up > > > i can commit the code if anyone wants to check it out > > > > > > > If you do try to branch it to avoid problems with trunk (which is > > almost "stable") or put inside a place where is not called at all and > > we can look at it (like lib/experimental or something). > > > > -- > > Luis Lavena > > Multimedia systems > > - > > A common mistake that people make when trying to design > > something completely foolproof is to underestimate > > the ingenuity of complete fools. > > Douglas Adams > > _______________________________________________ > > > > Mongrel-development mailing list > > Mongrel-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-development > > >
Oh, it seems the list doesn''t allow me to post attachments. sorry. here it is. http://s3.amazonaws.com/four.livejournal/20071211/http11_ruby.tar.gz On Dec 11, 2007 7:12 PM, ry dahl <ry at tinyclouds.org> wrote:> p.s.: it doesn''t conform exactly to the C''s API - i was just trying to > get it to pass all the tests first (it shouldn''t be hard to change > things to be that way). > i think if someone can get it to pass that dumbfuck_headers test, it > would be functional. > > > > > On Dec 11, 2007 7:08 PM, ry dahl <ry at tinyclouds.org> wrote: > > er, here i''ll just tar it up. when i run the tests i get this: > > > > ..E.. > > Finished in 0.488298 seconds. > > > > 1) Error: > > test_parse_dumbfuck_headers(HttpParserTest): > > HttpParser::ParseError: HttpParser::ParseError > > ./http11.rb:466:in `execute'' > > ./test.rb:57:in `test_parse_dumbfuck_headers'' > > > > 5 tests, 15 assertions, 0 failures, 1 errors > > > > > > > > > > > > > > On Dec 11, 2007 6:48 PM, Luis Lavena <luislavena at gmail.com> wrote: > > > On Dec 11, 2007 11:44 PM, ry dahl <ry at tinyclouds.org> wrote: > > > > actually i''ve done that - although it''s not operational yet > > > > when i realized it was noticeably slower running the unit tests i gave up > > > > i can commit the code if anyone wants to check it out > > > > > > > > > > If you do try to branch it to avoid problems with trunk (which is > > > almost "stable") or put inside a place where is not called at all and > > > we can look at it (like lib/experimental or something). > > > > > > -- > > > Luis Lavena > > > Multimedia systems > > > - > > > A common mistake that people make when trying to design > > > something completely foolproof is to underestimate > > > the ingenuity of complete fools. > > > Douglas Adams > > > _______________________________________________ > > > > > > Mongrel-development mailing list > > > Mongrel-development at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-development > > > > > >
On Dec 11, 2007 7:35 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> A fellow contacted me earlier today about the possiblity of > resurrecting my Ruby/Event module (a nice ruby wrapper around libevent) > under 1.9. Apparently 1.9 will have an idle real thread that you can > put stuff like libevent callbacks and running inside. Sure as hell no > have no idea about the actual thread locking requirements of such a > hack, but if it is doable then I might give it a try. >This idea actually sounds quite promising. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071212/e05bf200/attachment.html
Let''s take things one step at a time then, and just get things working incremetally. Even if they run _slowly_ as is, we could first focus on getting things running and then speeding things up by addressing our model. What do you think? Also, does anyone know if Ruby 1.9 needs fastthread? ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071212/ca54f9d1/attachment.html
On Dec 12, 2007 3:21 PM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:> Let''s take things one step at a time then, and just get things working > incremetally. > Even if they run _slowly_ as is, we could first focus on getting things > running and then speeding things up by addressing our model. What do you > think? >I agree with Wayne on this. Get it running first, then see why it behave slow and then start looking for alternatives to the design.> Also, does anyone know if Ruby 1.9 needs fastthread? >Threading was fixed in latest 1.8.6, and since 1.9 uses native threads instead of green threads queueing methods, is not needed. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 12, 2007 1:29 PM, Luis Lavena <luislavena at gmail.com> wrote:> Threading was fixed in latest 1.8.6, and since 1.9 uses native threads > instead of green threads queueing methods, is not needed. >Ok, I just installed ruby-1.9 and ran gem-1.9 install mongrel. So it appears that our first thing to remove is fastthread dependency for 1.9. Let''s do that then find the next issue. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071212/f5779ae5/attachment.html
On Dec 12, 2007 3:32 PM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:> On Dec 12, 2007 1:29 PM, Luis Lavena <luislavena at gmail.com> wrote: > > > Threading was fixed in latest 1.8.6, and since 1.9 uses native threads > > instead of green threads queueing methods, is not needed. > > > > Ok, I just installed ruby-1.9 and ran gem-1.9 install mongrel. > So it appears that our first thing to remove is fastthread dependency for > 1.9. > Let''s do that then find the next issue. >That will not be easy: you state which version of rubygems you depend on, and which version of ruby depend on. There is no way to tell rubygems that (on Ruby < 1.8.6, we should depend on fastthread, on >1.9 we shouldn''t). We can do the check on code and leave the following dependencies as warning: fastthread multipart_cgi_eof_fix (or something like that, is quite looong the name of that gem) :-P -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
I think we need a roadmap. This is getting complicated. Evan On Dec 12, 2007 1:36 PM, Luis Lavena <luislavena at gmail.com> wrote:> > On Dec 12, 2007 3:32 PM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote: > > On Dec 12, 2007 1:29 PM, Luis Lavena <luislavena at gmail.com> wrote: > > > > > Threading was fixed in latest 1.8.6, and since 1.9 uses native threads > > > instead of green threads queueing methods, is not needed. > > > > > > > Ok, I just installed ruby-1.9 and ran gem-1.9 install mongrel. > > So it appears that our first thing to remove is fastthread dependency for > > 1.9. > > Let''s do that then find the next issue. > > > > That will not be easy: you state which version of rubygems you depend > on, and which version of ruby depend on. There is no way to tell > rubygems that (on Ruby < 1.8.6, we should depend on fastthread, on >> 1.9 we shouldn''t). > > We can do the check on code and leave the following dependencies as warning: > > fastthread > multipart_cgi_eof_fix (or something like that, is quite looong the > name of that gem) :-P > > > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Dec 12, 2007 3:42 PM, Evan Weaver <evan at cloudbur.st> wrote:> I think we need a roadmap. This is getting complicated. >Yeah, I like when things get complicated :-D So: 1) Remove external dependencies (fastthread and multi_part_eof_fix) to code warnings instead, like the changes done with the compiled extension in mongrel_experimental. Rescue from them and warn the user about it. 2) Replace the ragel .c part with a ragel-ruby generated one and make all the tests pass on 1.8 3) Move to 1.9 and see if everything will work out of the box (the new generated ragel, the tests, the classes and the modules mongrel implements). 4) Do some benchmark of: Mongrel/MRI18 Mongrel/YARV19 Mongrel/JRUBY102 Mongrel/JRUBY110 Mongrel/Rubinius I put the bench on step 4 to be as fair as possible, compare the same code base across interpreters. 5) Start optimizing the deadlocks/threads and strategies about handling concurrent connections. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? Also, you need 6) Merge mongrel_rails and mongrel::cluster into a less fussy mongrel runner, possibly removing gem_plugin in the process. Evan On Dec 12, 2007 1:50 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Dec 12, 2007 3:42 PM, Evan Weaver <evan at cloudbur.st> wrote: > > I think we need a roadmap. This is getting complicated. > > > > Yeah, I like when things get complicated :-D > > So: > > 1) Remove external dependencies (fastthread and multi_part_eof_fix) to > code warnings instead, like the changes done with the compiled > extension in mongrel_experimental. > > Rescue from them and warn the user about it. > > 2) Replace the ragel .c part with a ragel-ruby generated one and make > all the tests pass on 1.8 > > 3) Move to 1.9 and see if everything will work out of the box (the new > generated ragel, the tests, the classes and the modules mongrel > implements). > > 4) Do some benchmark of: > > Mongrel/MRI18 > Mongrel/YARV19 > Mongrel/JRUBY102 > Mongrel/JRUBY110 > Mongrel/Rubinius > > I put the bench on step 4 to be as fair as possible, compare the same > code base across interpreters. > > 5) Start optimizing the deadlocks/threads and strategies about > handling concurrent connections. > > -- > > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
And I don''t think we really came to a decision about that proxy error response issue thing. Evan On Dec 12, 2007 1:55 PM, Evan Weaver <evan at cloudbur.st> wrote:> I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? > > Also, you need > > 6) Merge mongrel_rails and mongrel::cluster into a less fussy mongrel > runner, possibly removing gem_plugin in the process. > > Evan > > > > On Dec 12, 2007 1:50 PM, Luis Lavena <luislavena at gmail.com> wrote: > > On Dec 12, 2007 3:42 PM, Evan Weaver <evan at cloudbur.st> wrote: > > > I think we need a roadmap. This is getting complicated. > > > > > > > Yeah, I like when things get complicated :-D > > > > So: > > > > 1) Remove external dependencies (fastthread and multi_part_eof_fix) to > > code warnings instead, like the changes done with the compiled > > extension in mongrel_experimental. > > > > Rescue from them and warn the user about it. > > > > 2) Replace the ragel .c part with a ragel-ruby generated one and make > > all the tests pass on 1.8 > > > > 3) Move to 1.9 and see if everything will work out of the box (the new > > generated ragel, the tests, the classes and the modules mongrel > > implements). > > > > 4) Do some benchmark of: > > > > Mongrel/MRI18 > > Mongrel/YARV19 > > Mongrel/JRUBY102 > > Mongrel/JRUBY110 > > Mongrel/Rubinius > > > > I put the bench on step 4 to be as fair as possible, compare the same > > code base across interpreters. > > > > 5) Start optimizing the deadlocks/threads and strategies about > > handling concurrent connections. > > > > -- > > > > Luis Lavena > > Multimedia systems > > - > > A common mistake that people make when trying to design > > something completely foolproof is to underestimate > > the ingenuity of complete fools. > > Douglas Adams > > _______________________________________________ > > Mongrel-development mailing list > > Mongrel-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-development > > > > > > -- > Evan Weaver > Cloudburst, LLC >-- Evan Weaver Cloudburst, LLC
On Dec 12, 2007 3:56 PM, Evan Weaver <evan at cloudbur.st> wrote:> And I don''t think we really came to a decision about that proxy error > response issue thing. >We need some test on another load balancer.... help? I mean, if it is just nginx how behaves badly, why don''t fix it instead of putting the fix on mongrel? -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 12, 2007 3:55 PM, Evan Weaver <evan at cloudbur.st> wrote:> I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? >How performance penalty was compared to 1.9? If we are going to bring some changes to 1.9, we should start checking for big issues: - native extensions need compilers. - production servers don''t have compilers, so some users do the compile locally and generated a new platform-specific gem for their servers. - latest rubygems is broken is broken on windows (and I''m waiting eric releases 0.9.5.1 to fix the damn thing).> Also, you need > > 6) Merge mongrel_rails and mongrel::cluster into a less fussy mongrel > runner, possibly removing gem_plugin in the process.That could be splitted in several steps, you''re trying to chum a lot in just one bite. mongrel_rails is another beast, and is the only one that uses gem_plugins in its current form, so: remove all the gem processing from mongrel, isn''t our call to workaround Kernel.require or depend on rubygems presence to work. There are some users don''t like rubygems, mostly due their memory load. gem_plugin is great, but it have some issues since it "skip" some of the rubygems functionality and try to do it manually. Get a simpler configuration and plugabble mongrel_rails could be addressed later. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
> gem_plugin is greatDisagree. Evan On Dec 12, 2007 2:11 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Dec 12, 2007 3:55 PM, Evan Weaver <evan at cloudbur.st> wrote: > > I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? > > > > How performance penalty was compared to 1.9? If we are going to bring > some changes to 1.9, we should start checking for big issues: > > - native extensions need compilers. > - production servers don''t have compilers, so some users do the > compile locally and generated a new platform-specific gem for their > servers. > - latest rubygems is broken is broken on windows (and I''m waiting eric > releases 0.9.5.1 to fix the damn thing). > > > Also, you need > > > > 6) Merge mongrel_rails and mongrel::cluster into a less fussy mongrel > > runner, possibly removing gem_plugin in the process. > > That could be splitted in several steps, you''re trying to chum a lot > in just one bite. > > mongrel_rails is another beast, and is the only one that uses > gem_plugins in its current form, so: > > remove all the gem processing from mongrel, isn''t our call to > workaround Kernel.require or depend on rubygems presence to work. > > There are some users don''t like rubygems, mostly due their memory load. > > gem_plugin is great, but it have some issues since it "skip" some of > the rubygems functionality and try to do it manually. > > Get a simpler configuration and plugabble mongrel_rails could be > addressed later. > > -- > > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Dec 12, 2007 4:19 PM, Evan Weaver <evan at cloudbur.st> wrote:> > gem_plugin is great > > Disagree. >I mean: great in general speaking, not in the topic we are talking about. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
Still disagree :). Evan On Dec 12, 2007 2:31 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Dec 12, 2007 4:19 PM, Evan Weaver <evan at cloudbur.st> wrote: > > > gem_plugin is great > > > > Disagree. > > > > I mean: great in general speaking, not in the topic we are talking about. > > -- > > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Dec 12, 2007 11:56 AM, Evan Weaver <evan at cloudbur.st> wrote:> And I don''t think we really came to a decision about that proxy error > response issue thing.The RFC is terribly vague on this issue. Maybe a few of us can each take a different proxy other than nginx and investigate how they handle having the connection closed versus receiving a 400 response. Kirk
On Dec 12, 2007 11:55 AM, Evan Weaver <evan at cloudbur.st> wrote:> I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered?Performance is going to suffer. HTTP parsing is expensive, and unless we goto a parser like ServerSide''s (heavily regexp based), I don''t think we''re going to come close to the speed of a C based parser. I think the question is whether the performance loss is enough to be debilitating on 1.9.x or on rubinius (or jruby?). I would think that we wouldn''t get rid of the C extensions, though. Just render them an additional, optional component.> 6) Merge mongrel_rails and mongrel::cluster into a less fussy mongrel > runner, possibly removing gem_plugin in the process.Hallelujah! Kirk
> > I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? > How performance penalty was compared to 1.9?I don''t have any benchmarks but it was signifigantly slower running test. For something at the very heart of the server, I doubt anyone would want to take that performance hit. Mongrel should stick with the C parser for now.> mongrel_rails is another beast, and is the only one that uses > gem_plugins in its current form, so:My 2 cents: gem_plugins is not being used and doesn''t provide any features to the core server except making handlers slightly easier to install. I think it should be removed for the sake of simplicity. ry
> Just render them an additional, optional component.I am totally opposed to additional options to set. We have enough trouble as it is responding to people''s environment and configuration problems. I don''t think there are significant problems with the current C Ragel and Java Ragel. They share have the same .rl file even. And Kevin Clark managed to make it run on Rubinius with relatively few changes. Evan On Dec 12, 2007 3:34 PM, ry dahl <ry at tinyclouds.org> wrote:> > > I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? > > How performance penalty was compared to 1.9? > > I don''t have any benchmarks but it was signifigantly slower running > test. For something at the very heart of the server, I doubt anyone > would want to take that performance hit. Mongrel should stick with the > C parser for now. > > > mongrel_rails is another beast, and is the only one that uses > > gem_plugins in its current form, so: > > My 2 cents: gem_plugins is not being used and doesn''t provide any > features to the core server except making handlers slightly easier to > install. I think it should be removed for the sake of simplicity. > > > ry > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Dec 12, 2007 3:14 PM, Evan Weaver <evan at cloudbur.st> wrote:> > Just render them an additional, optional component. > > I am totally opposed to additional options to set. We have enough > trouble as it is responding to people''s environment and configuration > problems. > > I don''t think there are significant problems with the current C Ragel > and Java Ragel. They share have the same .rl file even. And Kevin > Clark managed to make it run on Rubinius with relatively few changes.I don''t, either, but it seems that a lot of people think there needs to be a pure ruby option. Kirk Haines
On Dec 12, 2007 7:19 PM, Kirk Haines <wyhaines at gmail.com> wrote:> > > > I don''t think there are significant problems with the current C Ragel > > and Java Ragel. They share have the same .rl file even. And Kevin > > Clark managed to make it run on Rubinius with relatively few changes. > > I don''t, either, but it seems that a lot of people think there needs > to be a pure ruby option. >Ok, my bad on following Zed proposal :P For the record, rubinius is going to replace the bison parser (like MRI currently have) to a plain ruby one using Racc. [1] Did the Rubinius team introduced changes in the ragel part or just the extension? So we have a java-ragel for JRuby, a C ragel for MRI and YARV and the same C for rbx. Following ruby-core talk there seems 1.9 will not be "re-entrant" to support something libevent, but I could be wrong (lot of traffic on so many lists to follow everything). So, what''s next on the list? [1] http://blog.zenspider.com/archives/2007/12/no_longer_secret.html -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Wed, 12 Dec 2007 12:34:48 -0800 "ry dahl" <ry at tinyclouds.org> wrote:> > > I think 2) remove C Ragel is debatable. Didn''t ry say that performance suffered? > > How performance penalty was compared to 1.9? > > I don''t have any benchmarks but it was signifigantly slower running > test. For something at the very heart of the server, I doubt anyone > would want to take that performance hit. Mongrel should stick with the > C parser for now.Ry, did you try: 1) Ruby parser. 2) Ruby 1.9 absolute latest. 3) Benchmarked tests to see what''s slow. 4) Ruled out stupidity or possible easy fixes. ? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Wed, 12 Dec 2007 14:53:08 -0500 "Evan Weaver" <evan at cloudbur.st> wrote:> Still disagree :).Sigh, ok, why? It''s not fair to just yell disagree without stating your reasons so they can be debated. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
It adds a lot of complexity. It discourages encapsulation of your dependencies per-app. For using inside custom handlers, you have to explicitly specify which plugin you want (:handler => plugin()) etc., so why not just use ''require''. Some plugins just use regular Class#new anyway. It''s mostly widely used (outside of mongrel_rails itself) for mongrel_cluster, which is our own project, and which basically duplicates all of mongrel_rails, because there''s no way to extend one plugin from another besides reopening classes. This is really awful. For mongrel_rails, it doesn''t provide any interfaces. All it does is load stuff. For our purposes it''s much simpler to make a runner that takes the name of a handler and an optional list of dependencies to try to load. That runner can deal with the pid files and mount whatever you please on ''/'' for whatever size cluster you want. The dep list can include rubygems if you want it, or just libraries on the loadpath, or whatever. I understand the glorious vision of thousands of handlers and plugins blooming and breeding, but that''s not really how it''s worked out. Evan On Dec 12, 2007 9:58 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Wed, 12 Dec 2007 14:53:08 -0500 > "Evan Weaver" <evan at cloudbur.st> wrote: > > > Still disagree :). > > Sigh, ok, why? It''s not fair to just yell disagree without stating > your reasons so they can be debated. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
First, I''m all for replacing it if you can simplify things, and I''m just giving out advice. You guys are in charge so do as you wish, but Evan, you''re kind of being a jerk about this one. Read my comments below, take your ideas, implement a small prototype for them, and then hit ALL the other projects using mongrel to get their feedback. Not just Rails. If they all like the idea then go for it, but from what I see, you''re very narrow minded about Rails, Rails, Rails, and that''s bad. Frankly, my insistence on keeping Mongrel relatively agnostic and not sucking rails-core cocks is why everyone uses Mongrel. I saw how the rails-core guys treated the people making them famous and realized I needed to keep things open for anyone in order to level the playing field. Too much power held by one group is a very bad thing. As the new guys in charge of Mongrel, you have to keep this in mind. Fucking things up for even one of the small players can ruin people''s trust in you and destroy something that''s a key piece of infrastructure for many people. So, I''m not being mean in the below comments at all, because you rock for challenging what exists, I''m just challenging your ideas back because I think your reasoning and proposed alternatives blow. They need more whiteboard time and probably some code. Now with my comments... On Thu, 13 Dec 2007 00:21:01 -0500 "Evan Weaver" <evan at cloudbur.st> wrote:> It adds a lot of complexity.Add the complexity where, and what is your proposed alternative? The last alternative you did was to replace my rake help library (which required no dependencies on build) with your own "simpler" rubygem (which means that now mongrel builds need rubygems). So, let''s get crystal clear about what you think is complex, where it''s complex, and how it would be simpler under your proposed plan.> It discourages encapsulation of your dependencies per-app.Which "app"? Mongrel? Rails? Mongrel based frameworks? And, how does a gem that''s required and loaded on the fly discourage people from putting their stuff in the gems and encapsulate them? My definition of "encapsulation" is that things are like, you know, encapsulated. Shielded. Protected. Kept from other stuff. Can you clarify? And, what would be your proposed alternative that doesn''t use gems and yet encourages encapsulation?> For using inside custom handlers, you have to explicitly specify which > plugin you want (:handler => plugin()) etc., so why not just use > ''require''. Some plugins just use regular Class#new anyway.It''s intended to be used as something that is configured to start just the handler. Inside your handler or any other ruby code nothing prevents you from just using require. Can you give sample code that shows the situation you''re talking about where you MUST use the gemplugin system to load a dependent plain gem?> It''s mostly widely used (outside of mongrel_rails itself) for > mongrel_cluster, which is our own project, and which basically > duplicates all of mongrel_rails, because there''s no way to extend one > plugin from another besides reopening classes. This is really awful.Ok, but again, you don''t need to use gemplugins. In each place where I used it, you can also not use it. That''s how it always has been. Commands for mongrel_rails are a small exception (not handlers) because the mongrel_rails script needs some way to load new commands that were added to the system without accessing any list a user controls, and without requiring much more configuration than a gem install. I think you might be missing this feature if you''re expecting someone to install a gem AND edit a config file somewhere in order to enable a new command for mongrel_rails for the whole system. I also put forward this observation: You are thinking of gemplugins as subclassable reusable bits of code, but I think of them as standalone components that are loaded (similar to nearly every other plugin system including Rails''). Reusable-subclassable is not how they were designed, they were designed so people who wanted to contribute a handler or command for mongrel could package it independently of the mongrel project and distribute it without requiring us to give them: 1) svn access 2) permission 3) source 4) licensing 5) command line tool changes 6) configuration after install If your proposed alternative doesn''t allow that, or requires other external dependencies besides gems, then it''s not going to work as an alternative.> For mongrel_rails, it doesn''t provide any interfaces. All it does is > load stuff. For our purposes it''s much simpler to make a runner that > takes the name of a handler and an optional list of dependencies to > try to load. That runner can deal with the pid files and mount > whatever you please on ''/'' for whatever size cluster you want. The dep > list can include rubygems if you want it, or just libraries on the > loadpath, or whatever.Uh, it does provide an interface using the -S option to provide a configuration script, and that''s even documented. Do you mean for commands or for handlers? But at this point, I realize you probably just have a general distaste/distrust of gemplugins and yet no viable tested and agreed on alternative worked on yet. I think if you went and worked on the alternative you''d have a more convincing argument, especially if it was simply, "Look bitch! My code simpla!"> I understand the glorious vision of thousands of handlers and plugins > blooming and breeding, but that''s not really how it''s worked out.Well, the glorious vision was that I got to write a web server that everyone uses, which is pretty much what I did so that''s cool. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
> Ry, did you try: > > 1) Ruby parser. > 2) Ruby 1.9 absolute latest. > 3) Benchmarked tests to see what''s slow. > 4) Ruled out stupidity or possible easy fixes.No, I haven''t - I''m pretty busy these days - if anyone wants to give it a try see my code above. Kirk, didn''t you say on IRC that you had written a simple ruby-regex based http parser that was pretty fast and simple? (Or was that someone else?) Also: I gave a brief presentation of Ruby and Ragel at the European Ruby conference last month. It was basically to advise people to read http11 because it''s very nice. If anyone is interested in looking at the slides: http://s3.amazonaws.com/four.livejournal/20071116/ragel_talk.pdf ry
On Dec 13, 2007 11:57 AM, ry dahl <ry at tinyclouds.org> wrote:> Kirk, didn''t you say on IRC that you had written a simple ruby-regex > based http parser that was pretty fast and simple? (Or was that > someone else?)No. ServerSide''s parser is regexp based. That''s probably what you are thinking of. Kirk Haines
On Dec 13, 2007 4:49 PM, Kirk Haines <wyhaines at gmail.com> wrote:> On Dec 13, 2007 11:57 AM, ry dahl <ry at tinyclouds.org> wrote: > > > Kirk, didn''t you say on IRC that you had written a simple ruby-regex > > based http parser that was pretty fast and simple? (Or was that > > someone else?) > > No. ServerSide''s parser is regexp based. That''s probably what you > are thinking of. >Quoting Zed''s own answer back in september 2006 [1], talking about ServerSide: It''s still pretty impressive for a first run. I''d be curious to see if some kind of mongrel+severside alliance could be had, but I suspect the author has his eye on the "fastest web server" prize. Also, recent noob comparison of serverside/mongrel performance [2] shows it still is good at performance. Since Mongrel proved being a viable server implementation for Rails, Merb and other frameworks, maybe is just time we can have some collaborative work with SS guys? Just a thought, anyway, we are stuck if we keep discussing without a plan :-P [1] http://rubyforge.org/pipermail/mongrel-users/2006-September/001460.html [2] http://rubyforge.org/pipermail/mongrel-users/2007-November/004461.html -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 13, 2007 3:09 PM, Luis Lavena <luislavena at gmail.com> wrote:> Quoting Zed''s own answer back in september 2006 [1], talking about > ServerSide: > > It''s still pretty impressive for a first run. I''d be curious to see if > some kind of mongrel+severside alliance could be had, but I suspect the > author has his eye on the "fastest web server" prize. > > Also, recent noob comparison of serverside/mongrel performance [2] > shows it still is good at performance. > > Since Mongrel proved being a viable server implementation for Rails, > Merb and other frameworks, maybe is just time we can have some > collaborative work with SS guys? > > Just a thought, anyway, we are stuck if we keep discussing without a plan > :-P > > [1] > http://rubyforge.org/pipermail/mongrel-users/2006-September/001460.html > [2] http://rubyforge.org/pipermail/mongrel-users/2007-November/004461.html >I''m one of the ServerSide devs, so if we need to discuss things with the author it is very easy to facilitate. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071213/819ec1f6/attachment.html
> Evan, you''re kind of being a jerk about this one. Read my commentsSorry; fair enough.> very narrow minded about Rails, Rails, Rails, and that''s bad.Rails and Camping, yeah, because those are what I use. Pushback here is good. When people worried about removing the Trie I was happy to give them the option to keep using it. I explained my idea to Wayne and Kirk though and they seemed to mainly agree. If you guys can respond here that would be great.> required no dependencies on build) with your own "simpler" rubygemPoint taken, but setup.rb still works, and rakehelp is no longer duplicated in every subproject, and the tarballs now ship dependency-free gemspecs, and the tests run without Rake. Plus I removed the C Trie.> > It discourages encapsulation of your dependencies per-app.I mean, to bundle your entire app and its dependencies in a repository or tarball or something. gem_plugin requires things to be installed in system-wide Rubygems.> encapsulated. Shielded. Protected. Kept from other stuff. Can youShielded from other apps.> And, what would be your proposed alternative that doesn''t use gems and > yet encourages encapsulation?Just the $LOAD_PATH and require().> Can you give sample code that shows the situation you''re talking about > where you MUST use the gemplugin system to load a dependent plain gem?No, but why do we need yet another alternative load mechanism? I hate Rail''s override of require() just as much.> > mongrel_cluster, which is our own project, and which basically> Ok, but again, you don''t need to use gemplugins. In each place where I > used it, you can also not use it. That''s how it always has been.Maybe then it''s misapplied in this situation.> the mongrel_rails script needs some way to load new commands that were > added to the system without accessing any list a user controls, and > without requiring much more configuration than a gem install. I think > you might be missing this feature if you''re expecting someone toI disagree. The user is running the command from somewhere, and they could specify requirements to load just like you can with Ruby itself. Instead of: gem install mongrel_thingy ./mongrel_rails mongrel::thingy arg gem install mongrel_thingy ./mongrel #{handler_name} arg -rmongrel_thingy (Autoload of Rubygems implied if mongrel_thingy isn''t in $LOAD_PATH). The reqs would get loaded first so they can include your handler class, which is just camelcased from ARGV[0] and mounted on ''/''. This breaks us out of a Rails specific runner which I think is undeniably a good thing.> I think of them as standalone > components that are loadedLike plain gems and libraries.> they were designed so people who wanted to contribute a handler or > command for mongrel could package it independently of the mongrelThat is the goal. Right now the runner only runs Rails, I want to move it to run any handler. The Rails team would like to work on their own handler internally anyway instead of having it shipped with Mongrel.> Uh, it does provide an interface using the -S option to provide a > configuration script, and that''s even documented. Do you mean for > commands or for handlers?I mean for automatically adding commands without having to duplicate everything that is already there regarding process and cluster management. Maybe I don''t understand.> no viable tested and agreed on alternative worked on yet.That''s why we''re talking about it.> > I think if you went and worked on the alternative you''d have a more > convincing argument, especially if it was simply, "Look bitch! My code > simpla!"True but I want feedback before doing something ridiculous. I mention most of this stuff in #mongrel-dev, Wayne and Luis and Kirk have seen it before.> Well, the glorious vision was that I got to write a web server that > everyone uses, which is pretty much what I did so that''s cool.Yes. Evan -- Evan Weaver Cloudburst, LLC
And just a final, social point; I can be a loose cannon (Wayne has called me as much ;) ), but if you fuss at me I will be reasonable. I haven''t been offended by any criticism here. Evan PS. On an unrelated note, what are all the different frameworks we need to keep in mind? Ramaze IOWA Camping Rails Sinatra Nitro (?) ... There must be at 5-10 others. On Dec 14, 2007 7:37 PM, Evan Weaver <evan at cloudbur.st> wrote:> > Evan, you''re kind of being a jerk about this one. Read my comments > > Sorry; fair enough. > > > very narrow minded about Rails, Rails, Rails, and that''s bad. > > Rails and Camping, yeah, because those are what I use. Pushback here > is good. When people worried about removing the Trie I was happy to > give them the option to keep using it. > > I explained my idea to Wayne and Kirk though and they seemed to mainly > agree. If you guys can respond here that would be great. > > > required no dependencies on build) with your own "simpler" rubygem > > Point taken, but setup.rb still works, and rakehelp is no longer > duplicated in every subproject, and the tarballs now ship > dependency-free gemspecs, and the tests run without Rake. > > Plus I removed the C Trie. > > > > It discourages encapsulation of your dependencies per-app. > > I mean, to bundle your entire app and its dependencies in a repository > or tarball or something. gem_plugin requires things to be installed in > system-wide Rubygems. > > > encapsulated. Shielded. Protected. Kept from other stuff. Can you > > Shielded from other apps. > > > And, what would be your proposed alternative that doesn''t use gems and > > yet encourages encapsulation? > > Just the $LOAD_PATH and require(). > > > Can you give sample code that shows the situation you''re talking about > > where you MUST use the gemplugin system to load a dependent plain gem? > > No, but why do we need yet another alternative load mechanism? I hate > Rail''s override of require() just as much. > > > > mongrel_cluster, which is our own project, and which basically > > > Ok, but again, you don''t need to use gemplugins. In each place where I > > used it, you can also not use it. That''s how it always has been. > > Maybe then it''s misapplied in this situation. > > > the mongrel_rails script needs some way to load new commands that were > > added to the system without accessing any list a user controls, and > > without requiring much more configuration than a gem install. I think > > you might be missing this feature if you''re expecting someone to > > I disagree. The user is running the command from somewhere, and they > could specify requirements to load just like you can with Ruby itself. > > Instead of: > > gem install mongrel_thingy > ./mongrel_rails mongrel::thingy arg > > gem install mongrel_thingy > ./mongrel #{handler_name} arg -rmongrel_thingy > > (Autoload of Rubygems implied if mongrel_thingy isn''t in $LOAD_PATH). > The reqs would get loaded first so they can include your handler > class, which is just camelcased from ARGV[0] and mounted on ''/''. > > This breaks us out of a Rails specific runner which I think is > undeniably a good thing. > > > I think of them as standalone > > components that are loaded > > Like plain gems and libraries. > > > they were designed so people who wanted to contribute a handler or > > command for mongrel could package it independently of the mongrel > > That is the goal. Right now the runner only runs Rails, I want to move > it to run any handler. The Rails team would like to work on their own > handler internally anyway instead of having it shipped with Mongrel. > > > Uh, it does provide an interface using the -S option to provide a > > configuration script, and that''s even documented. Do you mean for > > commands or for handlers? > > I mean for automatically adding commands without having to duplicate > everything that is already there regarding process and cluster > management. Maybe I don''t understand. > > > no viable tested and agreed on alternative worked on yet. > > That''s why we''re talking about it. > > > > > I think if you went and worked on the alternative you''d have a more > > convincing argument, especially if it was simply, "Look bitch! My code > > simpla!" > > True but I want feedback before doing something ridiculous. I mention > most of this stuff in #mongrel-dev, Wayne and Luis and Kirk have seen > it before. > > > Well, the glorious vision was that I got to write a web server that > > everyone uses, which is pretty much what I did so that''s cool. > > Yes. > > > Evan > > -- > Evan Weaver > Cloudburst, LLC >-- Evan Weaver Cloudburst, LLC
On Dec 14, 2007 9:10 PM, Evan Weaver <evan at cloudbur.st> wrote:> And just a final, social point; I can be a loose cannon (Wayne has > called me as much ;) ), but if you fuss at me I will be reasonable. I > haven''t been offended by any criticism here. > > EvanI meant it with respect :-p -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071215/ffd17db7/attachment.html
On Dec 14, 2007 7:10 PM, Evan Weaver <evan at cloudbur.st> wrote:> And just a final, social point; I can be a loose cannon (Wayne has > called me as much ;) ), but if you fuss at me I will be reasonable. I > haven''t been offended by any criticism here.> Ramaze > IOWA > Camping > Rails > Sinatra > Nitro (?)Yes, Nitro. They deploy primarily using Mongrel. Add Merb to that list. And include Rack. That set covers the vast majority of mongrel using frameworks that are in production usage, AFAIK. Kirk