From mag at kite.se Wed Mar 7 15:43:53 2007 From: mag at kite.se (Magnus Naeslund) Date: Wed, 07 Mar 2007 21:43:53 +0100 Subject: Is there a thread safe ActiveRecord replacement? Message-ID: <45EF2409.5060002@kite.se> I'm using merb as an application server backend for a client application, the goal is to be able to handle thousands of parallell sessions (not parallell requests). It will use sendfile to send files. The controller uses an singleton that saves sessions in a hash that is memory resident cross requests, but isn't persistent otherwise. I'm using ActiveRecord since there is an Rails site used to administer the whole thing, and I thought it would be nice to share the models. Since ActiveRecord is mutexed this not only scales bad (or atleast the scaling point is not where I'd like it), but if something murphy-like is happening on the database server (or in between), the whole server is hung which is "not ideal". So: is there a (lightweight) ActiveRecord replacement that I can use instead? I'm not sure yet if I really need the belongs_to style relational mappings yet, but I would consider that a big plus. It doesn't need to be compatible with ActiveRecord, but I can't rename the tables or modify the table definitions since the Rails app will break. Any ideas? Regards, Magnus P.S.: I love merb so far, I only wish it existed when the original Rails site was created :) From mag at kite.se Thu Mar 8 12:51:58 2007 From: mag at kite.se (Magnus Naeslund) Date: Thu, 08 Mar 2007 18:51:58 +0100 Subject: Transfer-encoding: gzip Message-ID: <45F04D3E.3030104@kite.se> Hello! What is the simplest way to make merb respond to the client sending Accept-Encoding: gzip? Just checking if it exists, otherwise I'll implement it myself. Regards, Magnus From ez at engineyard.com Thu Mar 8 14:12:58 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Thu, 8 Mar 2007 11:12:58 -0800 Subject: Transfer-encoding: gzip In-Reply-To: <45F04D3E.3030104@kite.se> References: <45F04D3E.3030104@kite.se> Message-ID: <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> On Mar 8, 2007, at 9:51 AM, Magnus Naeslund wrote: > Hello! > What is the simplest way to make merb respond to the client sending > Accept-Encoding: gzip? > Just checking if it exists, otherwise I'll implement it myself. > > Regards, > Magnus Hey Magnus- The easiest way would be to use the mongrel deflate handler. You would want to add a config option for it and then at the bottom of merb_server.rb where I mount the mongrel handlers you woudl mount the deflate handler. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From mag at kite.se Thu Mar 8 17:55:57 2007 From: mag at kite.se (Magnus Naeslund) Date: Thu, 08 Mar 2007 23:55:57 +0100 Subject: Transfer-encoding: gzip In-Reply-To: <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> References: <45F04D3E.3030104@kite.se> <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> Message-ID: <45F0947D.3070703@kite.se> Ezra Zygmuntowicz wrote: > > Hey Magnus- > > The easiest way would be to use the mongrel deflate handler. You > would want to add a config option for it and then at the bottom of > merb_server.rb where I mount the mongrel handlers you woudl mount the > deflate handler. > Excellent! Magnus From luke at slantwisedesign.com Fri Mar 9 14:40:48 2007 From: luke at slantwisedesign.com (Luke Francl) Date: Fri, 9 Mar 2007 13:40:48 -0600 Subject: Merb + attachment_fu Message-ID: Merbists, I saw a note in the attachment_fu source code regarding supporting Merb[1] as well as a post on the Caboose forum[2]. Has anyone gotten Merb working with Rick Olson's attachment_fu to handle uploads for a Rails app? I've hacked together something, but it's not pretty. Besides fixing the TODO mentioned in the attachment_fu source code to support Merb tempfiles, the main thing I've done is change is attachment_fu's init.rb to manually load the files in its lib directory (and, trivially, define the RAILS_ROOT constant in merb_init.rb). I think this is due to the way that merb loads plugins (Dir[DIST_ROOT+"/plugins/*/init.rb"].each { |m| require m }) versus how Rails loads plugins (see Rails::Initializer#load_plugin). Any thoughts on making Merb able to load a typical Rails ActiveRecord plugin more easily? Regards, Luke Francl [1] http://svn.techno-weenie.net/projects/plugins/attachment_fu/lib/technoweenie/attachment_fu.rb [2] http://beast.caboo.se/forums/2/topics/833 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070309/b480c1a6/attachment.html From ez at engineyard.com Fri Mar 9 16:13:39 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Fri, 9 Mar 2007 13:13:39 -0800 Subject: Is there a thread safe ActiveRecord replacement? In-Reply-To: <45EF2409.5060002@kite.se> References: <45EF2409.5060002@kite.se> Message-ID: On Mar 7, 2007, at 12:43 PM, Magnus Naeslund wrote: > I'm using merb as an application server backend for a client > application, the goal is to be able to handle thousands of > parallell sessions (not parallell requests). It will use sendfile > to send files. > The controller uses an singleton that saves sessions in a hash that > is memory resident cross requests, but isn't persistent otherwise. > > I'm using ActiveRecord since there is an Rails site used to > administer the whole thing, and I thought it would be nice to share > the models. > Since ActiveRecord is mutexed this not only scales bad (or atleast > the scaling point is not where I'd like it), but if something > murphy-like is happening on the database server (or in between), > the whole server is hung which is "not ideal". > > So: is there a (lightweight) ActiveRecord replacement that I can > use instead? > I'm not sure yet if I really need the belongs_to style relational > mappings yet, but I would consider that a big plus. > It doesn't need to be compatible with ActiveRecord, but I can't > rename the tables or modify the table definitions since the Rails > app will break. > > Any ideas? > > Regards, > Magnus > > P.S.: I love merb so far, I only wish it existed when the original > Rails site was created :) > There aren't any lightweight ORM's that i know of that would work better here. I have been using the Mysql library directly with a small wrapper and it works much better then AR when you need high concurrency. As far as using send_file thats good but realize that mongrel is serving those files still. You would be better off with nginx up front and using nginx's X-Accell_redirect feture . With this way all you woudl do in your merb action is use nginx_send_file. This just sets the header to the path to the file to be server and nginx serves the file fast instead of mongrel doing it. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From mag at kite.se Fri Mar 9 20:01:32 2007 From: mag at kite.se (Magnus Naeslund) Date: Sat, 10 Mar 2007 02:01:32 +0100 Subject: Is there a thread safe ActiveRecord replacement? In-Reply-To: References: <45EF2409.5060002@kite.se> Message-ID: <45F2036C.6030203@kite.se> Ezra Zygmuntowicz wrote: > > There aren't any lightweight ORM's that i know of that would work > better here. I have been using the Mysql library directly with a > small wrapper and it works much better then AR when you need high > concurrency. > Yes I'm thinking this is the way to go unless there pops up a framework that I can use before I get around to it. In the meantime, how about turning off locking around AR? I've seen you say that this won't get me any performance gain, but I don't care about that in this context, I'm just worried that one request going bad will lock up the whole app. > As far as using send_file thats good but realize that mongrel is > serving those files still. You would be better off with nginx up > front and using nginx's X-Accell_redirect feture . With this way all > you woudl do in your merb action is use nginx_send_file. This just > sets the header to the path to the file to be server and nginx serves > the file fast instead of mongrel doing it. > I thought that you just passed it on to mongrel, and it immediately issued a sendfile() system call. But you're saying it's just a verb and mongrel will do something not-so-fast? Small thing: why don't I get replies on my mails through the list, is there some setting for this? It's no biggie, but I'm used to getting both the direct mail and also via the mailinglist... Regards, Magnus From ez at engineyard.com Fri Mar 9 20:41:34 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Fri, 9 Mar 2007 17:41:34 -0800 Subject: Is there a thread safe ActiveRecord replacement? In-Reply-To: <45F2036C.6030203@kite.se> References: <45EF2409.5060002@kite.se> <45F2036C.6030203@kite.se> Message-ID: On Mar 9, 2007, at 5:01 PM, Magnus Naeslund wrote: > Ezra Zygmuntowicz wrote: >> >> There aren't any lightweight ORM's that i know of that would work >> better here. I have been using the Mysql library directly with a >> small wrapper and it works much better then AR when you need high >> concurrency. >> > > Yes I'm thinking this is the way to go unless there pops up a > framework that I can use before I get around to it. > In the meantime, how about turning off locking around AR? > I've seen you say that this won't get me any performance gain, but > I don't care about that in this context, I'm just worried that one > request going bad will lock up the whole app. > >> As far as using send_file thats good but realize that mongrel is >> serving those files still. You would be better off with nginx up >> front and using nginx's X-Accell_redirect feture . With this way all >> you woudl do in your merb action is use nginx_send_file. This just >> sets the header to the path to the file to be server and nginx serves >> the file fast instead of mongrel doing it. >> > > I thought that you just passed it on to mongrel, and it immediately > issued a sendfile() system call. > But you're saying it's just a verb and mongrel will do something > not-so-fast? > > Small thing: why don't I get replies on my mails through the list, > is there some setting for this? > It's no biggie, but I'm used to getting both the direct mail and > also via the mailinglist... > > Regards, > Magnus Magnus- Ok so I just made the mutex lock a configration option so you can turn it on or off as needed. http://merb.devjavu.com/projects/merb/changeset/198 The mutex will lock by default for the shortest amount of time possible where you could make ActiveRecord calls. If you aren't using AR then you can turn it off by doing this in your merb.yml: :use_mutex: false or you can do it with the merb command line tool $ merb --mutex off $ merb --mutex on Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From hutch at recursive.ca Mon Mar 12 00:10:37 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Mon, 12 Mar 2007 00:10:37 -0400 Subject: Clarification of how controllers and views work together... Message-ID: Hi, So I've started mucking about with Merb. I'm doing some experimenting with some product ideas. Things are working out quite well, Merb is a pleasure to use. It seems very fast too. A couple of rough spots but that might be me, if they are still chaffing after a few more days I'll mention them. One thing... I wrote a controller and a view with several partials. Works fine. Now lets say that I have to generate a bunch of static files that are exactly like that page generated by that controller. So I generated an array of hashes, where each hash provides the information needed by the views and partials. In a loop, I set an instance variable, say @data, to each hash in the array then render the view. It works the first time, subsequent times produce pages identical to the first. I put a few puts in the view so I know it is executing and isn't caching its results. When I look at object_ids I'm starting to see what might be going on. The object_id of the @data object is never the same as in the controller, and it never changes during that request. Next request it is different but doesn't change. Sounds like some kind of cache. Now, I'm thinking I'm either out of luck, or there is a trivial thing I have to do to loosen the view's grip on that copy of @data that it has. Any help is appreciated. Cheers, Bob ---- Bob Hutchison -- blogs at Recursive Design Inc. -- xampl for Ruby -- From ez at engineyard.com Mon Mar 12 03:01:24 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Mon, 12 Mar 2007 00:01:24 -0700 Subject: Clarification of how controllers and views work together... In-Reply-To: References: Message-ID: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> Hey Bob- Let me explain what is happening. WHen you call render in your controller action a new ViewContext instance is created. The ViewContext takes the controller as an argument and copies all of its instance variables into the VIewContext, then the same view context is cached for the life of one request so subsequent renders don't suffer the perf hit of making a new VIewContext. That being said, I will take a look and come up with a flag to create a new viewcontext by passing in a flag. Ok I took a look. Here is a patch for you to try before I commit it to the repo. The default behavior remains the same and the viewcontext is cached for subsequest renders. But if you pass in :clean_context => true along with your render method you will get a fresh context with your current ivars as you expect. Index: lib/merb/mixins/render_mixin.rb =================================================================== --- lib/merb/mixins/render_mixin.rb (revision 195) +++ lib/merb/mixins/render_mixin.rb (working copy) @@ -78,7 +78,7 @@ engine = engine_for(template) options = { :file => template, - :view_context => _view_context, + :view_context => (opts[:clean_context] ? clean_view_context : _view_context), :opts => opts } content = engine.transform(options) @@ -96,6 +96,10 @@ @_view_context_cache ||= ViewContext.new(self) end + def clean_view_context + ViewContext.new(self) + end + # does a render with no layout. Also sets the # content type header to text/javascript. Use # this when you want to render a template with Cheers- -Ezra On Mar 11, 2007, at 9:10 PM, Bob Hutchison wrote: > Hi, > > So I've started mucking about with Merb. I'm doing some experimenting > with some product ideas. Things are working out quite well, Merb is a > pleasure to use. It seems very fast too. A couple of rough spots but > that might be me, if they are still chaffing after a few more days > I'll mention them. > > One thing... > > I wrote a controller and a view with several partials. Works fine. > Now lets say that I have to generate a bunch of static files that are > exactly like that page generated by that controller. > > So I generated an array of hashes, where each hash provides the > information needed by the views and partials. In a loop, I set an > instance variable, say @data, to each hash in the array then render > the view. It works the first time, subsequent times produce pages > identical to the first. I put a few puts in the view so I know it is > executing and isn't caching its results. When I look at object_ids > I'm starting to see what might be going on. The object_id of the > @data object is never the same as in the controller, and it never > changes during that request. Next request it is different but doesn't > change. > > Sounds like some kind of cache. > > Now, I'm thinking I'm either out of luck, or there is a trivial thing > I have to do to loosen the view's grip on that copy of @data that it > has. > > Any help is appreciated. > > Cheers, > Bob > > ---- > Bob Hutchison -- blogs at hutch/> > Recursive Design Inc. -- > xampl for Ruby -- xampl/> > > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From luke at slantwisedesign.com Tue Mar 13 13:56:07 2007 From: luke at slantwisedesign.com (Luke Francl) Date: Tue, 13 Mar 2007 12:56:07 -0500 Subject: running merb locally Message-ID: Stupid question, but is there a way to run merb locally, without installing it as a gem? I don't mean freezing it into a merb app, but checking out merb and being able to run it without installing the gem first. The reason I ask is that I'm working on some debugging stuff and it'd be helpful to be able to modify the source code, run it, modify, run, and so on. (And yes, I am writing tests. ;-) Thanks, Luke Francl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070313/3d865999/attachment.html From ez at engineyard.com Tue Mar 13 14:37:36 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Tue, 13 Mar 2007 11:37:36 -0700 Subject: running merb locally In-Reply-To: References: Message-ID: <6365681A-817C-4D4E-B11D-AC46C6AD48B4@engineyard.com> On Mar 13, 2007, at 10:56 AM, Luke Francl wrote: > Stupid question, but is there a way to run merb locally, without > installing it as a gem? I don't mean freezing it into a merb app, > but checking out merb and being able to run it without installing > the gem first. > > The reason I ask is that I'm working on some debugging stuff and > it'd be helpful to be able to modify the source code, run it, > modify, run, and so on. (And yes, I am writing tests. ;-) > > Thanks, > Luke Francl Hey Luke- There is not really a way to do that without installing the gem first. You have to build the gem and then freeze the framework into your app. Then you can modify it easily. This is how I work with it. $ rake install #builds the gem and installs # from your merb_root, not dist_root $ rake freeze:merb Then you need to use $ script/merb Then you can uninstall the gem. This will create a dist/framework directory with the entire merb framework in it and you can modify it and use it without needing to rebuild gems all the time. ALso if you do this to yoru app once, it creates the script/merb stub for you and makes the framework dir. You could then delete the framework dir and do a frsh svn co of trunk into your dist/fraemwork dir. That way if you make changes and want to send a patch its easy. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From rogelio.samour at gmail.com Tue Mar 13 15:07:25 2007 From: rogelio.samour at gmail.com (Rogelio J. Samour) Date: Tue, 13 Mar 2007 13:07:25 -0600 Subject: running merb locally In-Reply-To: <6365681A-817C-4D4E-B11D-AC46C6AD48B4@engineyard.com> References: <6365681A-817C-4D4E-B11D-AC46C6AD48B4@engineyard.com> Message-ID: or the way that I do it is... svn checkout to /usr/local/src/merb make the changes to the source as needed and then gem uninstall and rake install again... extra steps but it works. :) HTH, rogelio On 3/13/07, Ezra Zygmuntowicz wrote: > > > On Mar 13, 2007, at 10:56 AM, Luke Francl wrote: > > > Stupid question, but is there a way to run merb locally, without > > installing it as a gem? I don't mean freezing it into a merb app, > > but checking out merb and being able to run it without installing > > the gem first. > > > > The reason I ask is that I'm working on some debugging stuff and > > it'd be helpful to be able to modify the source code, run it, > > modify, run, and so on. (And yes, I am writing tests. ;-) > > > > Thanks, > > Luke Francl > > > Hey Luke- > > There is not really a way to do that without installing the gem > first. You have to build the gem and then freeze the framework into > your app. Then you can modify it easily. This is how I work with it. > > $ rake install #builds the gem and installs > > # from your merb_root, not dist_root > $ rake freeze:merb > > Then you need to use > > $ script/merb > > Then you can uninstall the gem. This will create a dist/framework > directory with the entire merb framework in it and you can modify it > and use it without needing to rebuild gems all the time. ALso if you > do this to yoru app once, it creates the script/merb stub for you and > makes the framework dir. You could then delete the framework dir and > do a frsh svn co of trunk into your dist/fraemwork dir. That way if > you make changes and want to send a patch its easy. > > Cheers- > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070313/37e66c3a/attachment.html From luke at slantwisedesign.com Tue Mar 13 15:13:17 2007 From: luke at slantwisedesign.com (Luke Francl) Date: Tue, 13 Mar 2007 14:13:17 -0500 Subject: Specs for Ticket 21 Message-ID: I've submitted some specs for the problem I found with parsing multipart forms. http://merb.devjavu.com/projects/merb/ticket/21 It looks like the problem is broader than I thought before. The multipart form parsing only takes the last field in the form, the others get thrown away. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070313/e72ba07f/attachment-0001.html From hutch at recursive.ca Wed Mar 14 08:19:54 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Wed, 14 Mar 2007 08:19:54 -0400 Subject: Clarification of how controllers and views work together... In-Reply-To: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> References: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> Message-ID: Thanks Ezra, I'll give it a shot this afternoon. Sorry for the delayed response, it has been crazy here. Cheers, Bob On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote: > Hey Bob- > > Let me explain what is happening. WHen you call render in your > controller action a new ViewContext instance is created. The > ViewContext takes the controller as an argument and copies all of > its instance variables into the VIewContext, then the same view > context is cached for the life of one request so subsequent renders > don't suffer the perf hit of making a new VIewContext. > > That being said, I will take a look and come up with a flag to > create a new viewcontext by passing in a flag. > > Ok I took a look. Here is a patch for you to try before I commit > it to the repo. The default behavior remains the same and the > viewcontext is cached for subsequest renders. But if you pass > in :clean_context => true along with your render method you will > get a fresh context with your current ivars as you expect. > > > Index: lib/merb/mixins/render_mixin.rb > =================================================================== > --- lib/merb/mixins/render_mixin.rb (revision 195) > +++ lib/merb/mixins/render_mixin.rb (working copy) > @@ -78,7 +78,7 @@ > engine = engine_for(template) > options = { > :file => template, > - :view_context => _view_context, > + :view_context => (opts[:clean_context] ? > clean_view_context : _view_context), > :opts => opts > } > content = engine.transform(options) > @@ -96,6 +96,10 @@ > @_view_context_cache ||= ViewContext.new(self) > end > > + def clean_view_context > + ViewContext.new(self) > + end > + > # does a render with no layout. Also sets the > # content type header to text/javascript. Use > # this when you want to render a template with > > > > Cheers- > -Ezra > > > On Mar 11, 2007, at 9:10 PM, Bob Hutchison wrote: > >> Hi, >> >> So I've started mucking about with Merb. I'm doing some experimenting >> with some product ideas. Things are working out quite well, Merb is a >> pleasure to use. It seems very fast too. A couple of rough spots but >> that might be me, if they are still chaffing after a few more days >> I'll mention them. >> >> One thing... >> >> I wrote a controller and a view with several partials. Works fine. >> Now lets say that I have to generate a bunch of static files that are >> exactly like that page generated by that controller. >> >> So I generated an array of hashes, where each hash provides the >> information needed by the views and partials. In a loop, I set an >> instance variable, say @data, to each hash in the array then render >> the view. It works the first time, subsequent times produce pages >> identical to the first. I put a few puts in the view so I know it is >> executing and isn't caching its results. When I look at object_ids >> I'm starting to see what might be going on. The object_id of the >> @data object is never the same as in the controller, and it never >> changes during that request. Next request it is different but doesn't >> change. >> >> Sounds like some kind of cache. >> >> Now, I'm thinking I'm either out of luck, or there is a trivial thing >> I have to do to loosen the view's grip on that copy of @data that it >> has. >> >> Any help is appreciated. >> >> Cheers, >> Bob >> >> ---- >> Bob Hutchison -- blogs at > hutch/> >> Recursive Design Inc. -- >> xampl for Ruby -- > xampl/> >> >> >> >> _______________________________________________ >> Merb-devel mailing list >> Merb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/merb-devel > > -- Ezra Zygmuntowicz-- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > ---- Bob Hutchison -- blogs at Recursive Design Inc. -- xampl for Ruby -- From mag at kite.se Sat Mar 17 07:47:27 2007 From: mag at kite.se (Magnus Naeslund) Date: Sat, 17 Mar 2007 12:47:27 +0100 Subject: Transfer-encoding: gzip In-Reply-To: <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> References: <45F04D3E.3030104@kite.se> <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> Message-ID: <45FBD54F.1040703@kite.se> Ezra Zygmuntowicz wrote: > Hey Magnus- > > The easiest way would be to use the mongrel deflate handler. You > would want to add a config option for it and then at the bottom of > merb_server.rb where I mount the mongrel handlers you woudl mount the > deflate handler. > I patched merb so that I can add additional handlers in merb_init.rb, see patch below. In merb_init.rb i do: Merb::Server.add_handler(:uri => '/', :handler => GzipFilter.new, :in_front => true) If I don't have the :in_front thing nothing happens... The problem is that when i test it, it doesn't compress the output, it only sets the header: # echo -en "GET /xxx HTTP/1.0\r\nAccept-Encoding: gzip,deflate\r\n\r\n" | nc -v localhost 4000 | strings localhost [127.0.0.1] 4000 (?) open HTTP/1.1 200 OK Connection: close Date: Sat, 17 Mar 2007 11:45:10 GMT Content-Encoding: gzip Content-Type: text/html Content-Length: 5 hello That's a bit strange, right? Is there any special way I should prepare the body more than returning a string from the controllers action? Magnus From hutch at recursive.ca Sat Mar 17 10:42:18 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Sat, 17 Mar 2007 10:42:18 -0400 Subject: Clarification of how controllers and views work together... In-Reply-To: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> References: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> Message-ID: <7DF5E276-2FEE-44D2-A02B-37BCDF35644F@recursive.ca> Hi Ezra, On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote: > Ok I took a look. Here is a patch for you to try before I commit > it to the repo. The default behavior remains the same and the > viewcontext is cached for subsequest renders. But if you pass > in :clean_context => true along with your render method you will > get a fresh context with your current ivars as you expect. > That worked perfectly. Thanks! Just wondering... what do you gain by caching the ViewContext? Well, more precisely, when would the output of the render be different when using the cached ViewContext? Doesn't the ViewContext pretty much control the input to the rendering? ... I suppose some of the view's input could be computed by calls (that changed the state of something, otherwise the result of the call would always be the same) made by the view but is that a good idea? Cheers, Bob ---- Bob Hutchison -- tumblelog at Recursive Design Inc. -- xampl for Ruby -- From ez at engineyard.com Sat Mar 17 14:10:52 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Sat, 17 Mar 2007 11:10:52 -0700 Subject: Clarification of how controllers and views work together... In-Reply-To: <7DF5E276-2FEE-44D2-A02B-37BCDF35644F@recursive.ca> References: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> <7DF5E276-2FEE-44D2-A02B-37BCDF35644F@recursive.ca> Message-ID: <9A543056-91FD-48D2-A2A5-08C3CE624164@engineyard.com> On Mar 17, 2007, at 7:42 AM, Bob Hutchison wrote: > Hi Ezra, > > On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote: > >> Ok I took a look. Here is a patch for you to try before I commit >> it to the repo. The default behavior remains the same and the >> viewcontext is cached for subsequest renders. But if you pass >> in :clean_context => true along with your render method you will >> get a fresh context with your current ivars as you expect. >> > > That worked perfectly. Thanks! > > Just wondering... what do you gain by caching the ViewContext? > Well, more precisely, when would the output of the render be > different when using the cached ViewContext? Doesn't the > ViewContext pretty much control the input to the rendering? ... I > suppose some of the view's input could be computed by calls (that > changed the state of something, otherwise the result of the call > would always be the same) made by the view but is that a good idea? > > Cheers, > Bob Hey Bob- If we don't cache the view context then layouts will not work properly. The views that have layouts are rendered in a 2 step process. First the inner template is rendered and an instance var is set on the cached view context so when the layout gets rendered that ivar is expanded to the layout content. If the view context is not cached the layout will be empty, and its a performance hit to copy ivars over twice. You will notice rails does something similar by only allowing you to render once. I don't limit you to rendering once and merb renders just return strings and merb actions send whatever their return value is to the browser. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From hutch at recursive.ca Sat Mar 17 15:16:05 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Sat, 17 Mar 2007 15:16:05 -0400 Subject: Clarification of how controllers and views work together... In-Reply-To: <9A543056-91FD-48D2-A2A5-08C3CE624164@engineyard.com> References: <989DE533-9ED8-4059-AAF7-565E590DD761@engineyard.com> <7DF5E276-2FEE-44D2-A02B-37BCDF35644F@recursive.ca> <9A543056-91FD-48D2-A2A5-08C3CE624164@engineyard.com> Message-ID: <0A7E81BE-A098-4EDB-B94E-95417489E9EE@recursive.ca> On 17-Mar-07, at 2:10 PM, Ezra Zygmuntowicz wrote: > > On Mar 17, 2007, at 7:42 AM, Bob Hutchison wrote: > >> Hi Ezra, >> >> On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote: >> >>> Ok I took a look. Here is a patch for you to try before I commit >>> it to the repo. The default behavior remains the same and the >>> viewcontext is cached for subsequest renders. But if you pass >>> in :clean_context => true along with your render method you >>> will get a fresh context with your current ivars as you expect. >>> >> >> That worked perfectly. Thanks! >> >> Just wondering... what do you gain by caching the ViewContext? >> Well, more precisely, when would the output of the render be >> different when using the cached ViewContext? Doesn't the >> ViewContext pretty much control the input to the rendering? ... I >> suppose some of the view's input could be computed by calls (that >> changed the state of something, otherwise the result of the call >> would always be the same) made by the view but is that a good idea? >> >> Cheers, >> Bob > > > Hey Bob- > > If we don't cache the view context then layouts will not work > properly. The views that have layouts are rendered in a 2 step > process. First the inner template is rendered and an instance var > is set on the cached view context so when the layout gets rendered > that ivar is expanded to the layout content. If the view context is > not cached the layout will be empty, and its a performance hit to > copy ivars over twice. Coincidentally I'm not using layouts, so I didn't seen any problems :-) And you can't accomplish the same by caching the result in the case of layouts? Not via the view context, but an option maybe? > > You will notice rails does something similar by only allowing you > to render once. I don't limit you to rendering once and merb > renders just return strings and merb actions send whatever their > return value is to the browser. I certainly did notice and I think what you've done is a very good idea. Very handy. I'm doing stuff in Merb that I can't do in Rails so I'm happy. I think this is a pretty nice feature that you should draw a bit of attention to. Cheers, Bob > > Cheers- > -- Ezra Zygmuntowicz-- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > ---- Bob Hutchison -- tumblelog at Recursive Design Inc. -- xampl for Ruby -- From mag at kite.se Sun Mar 18 16:08:43 2007 From: mag at kite.se (Magnus Naeslund) Date: Sun, 18 Mar 2007 21:08:43 +0100 Subject: Transfer-encoding: gzip In-Reply-To: <45FBD54F.1040703@kite.se> References: <45F04D3E.3030104@kite.se> <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> <45FBD54F.1040703@kite.se> Message-ID: <45FD9C4B.40009@kite.se> Magnus Naeslund wrote: [snip] > I patched merb so that I can add additional handlers in merb_init.rb, see patch below. [snip] Maybe I should attach the patch aswell :) Magnus Index: lib/merb/merb_server.rb =================================================================== --- lib/merb/merb_server.rb (revision 198) +++ lib/merb/merb_server.rb (working copy) @@ -284,6 +284,11 @@ uri( "/", :handler => MerbUploadHandler.new(yconfig), :in_front => true) if @@merb_opts[:config] uri "/", :handler => MerbHandler.new(@@merb_opts[:dist_root]+'/public') uri "/favicon.ico", :handler => Mongrel::Error404Handler.new("") + if @@additional_handlers + @@additional_handlers.each do |h| + uri(h[:uri], :handler => h[:handler], :in_front => (h[:in_front] || false)) + end + end end trap("INT") { stop } @@ -295,7 +300,12 @@ def config @@merb_opts end - + + def add_handler(h) + @@additional_handlers ||= [] + @@additional_handlers << h + end + end end # Server From mag at kite.se Sun Mar 18 18:31:09 2007 From: mag at kite.se (Magnus Naeslund) Date: Sun, 18 Mar 2007 23:31:09 +0100 Subject: Transfer-encoding: gzip In-Reply-To: <45FD9C4B.40009@kite.se> References: <45F04D3E.3030104@kite.se> <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> <45FBD54F.1040703@kite.se> <45FD9C4B.40009@kite.se> Message-ID: <45FDBDAD.3030709@kite.se> I gave up the idea to use the mongrel handlers for compression, and am using this kind of construct instead: The action returns stuff like this: return compress_if_possible(result) And the utility method defined as: def compress_if_possible(str) enc = request.env[HTTP_ACCEPT_ENCODING] return str if enc.nil? or enc.include?('deflate') == false headers['Content-Encoding'] = 'deflate' # Shamelessly stolen from mongrels deflate filter deflater = Zlib::Deflate.new( Zlib::DEFAULT_COMPRESSION, # drop the zlib header which causes both Safari and IE to choke -(Zlib::MAX_WBITS), Zlib::DEF_MEM_LEVEL, Zlib::DEFAULT_STRATEGY) return deflater.deflate(str, Zlib::FINISH) end I'm ok with that ugliness :) Anyways someone else might want to use additional handlers so here's my respun patch, feel free to include it if you like, Ezra. Index: lib/merb/merb_server.rb =================================================================== --- lib/merb/merb_server.rb (revision 198) +++ lib/merb/merb_server.rb (working copy) @@ -140,6 +140,7 @@ end def run + @@additional_handlers = [] @@merb_raw_opts = ARGV merb_config @@ -284,6 +285,9 @@ uri( "/", :handler => MerbUploadHandler.new(yconfig), :in_front => true) if @@merb_opts[:config] uri "/", :handler => MerbHandler.new(@@merb_opts[:dist_root]+'/public') uri "/favicon.ico", :handler => Mongrel::Error404Handler.new("") + @@additional_handlers.each do |h| + uri(h[:uri], :handler => h[:handler], :in_front => (h[:in_front] || false)) + end end trap("INT") { stop } @@ -295,7 +299,11 @@ def config @@merb_opts end - + + def add_handler(h) + @@additional_handlers << h + end + end end # Server From mag at kite.se Sun Mar 18 18:43:53 2007 From: mag at kite.se (Magnus Naeslund) Date: Sun, 18 Mar 2007 23:43:53 +0100 Subject: Transfer-encoding: gzip In-Reply-To: <45FDBDAD.3030709@kite.se> References: <45F04D3E.3030104@kite.se> <719D39D1-F276-41AD-82F8-CE9B981FF6DB@engineyard.com> <45FBD54F.1040703@kite.se> <45FD9C4B.40009@kite.se> <45FDBDAD.3030709@kite.se> Message-ID: <45FDC0A9.4050907@kite.se> Magnus Naeslund wrote: > > def compress_if_possible(str) > enc = request.env[HTTP_ACCEPT_ENCODING] > return str if enc.nil? or enc.include?('deflate') == false > headers['Content-Encoding'] = 'deflate' > > # Shamelessly stolen from mongrels deflate filter > deflater = Zlib::Deflate.new( > Zlib::DEFAULT_COMPRESSION, > # drop the zlib header which causes both Safari and IE to choke > -(Zlib::MAX_WBITS), > Zlib::DEF_MEM_LEVEL, > Zlib::DEFAULT_STRATEGY) > > return deflater.deflate(str, Zlib::FINISH) > end > Remember to user deflater.close before returning, if someone copies this code :) Regards, Magnus - butterfingers From olle at olleolleolle.dk Wed Mar 28 05:13:54 2007 From: olle at olleolleolle.dk (Olle Jonsson) Date: Wed, 28 Mar 2007 11:13:54 +0200 Subject: [recipe] How to get on Merb Edge Message-ID: Hello, My name is Olle, and I am new here. I'd like to add some detail to Ez's explanation in a previous email [1]. These are the steps I took to get Merb running Merb Edge (is that what you call it?). Start in the merb-root not in the dist-root. # Create dist/framework, plus script/merb stub rake merb:freeze cd dist rm -rf framework # Replace dist/framework with trunk version svn co http://svn.devjavu.com/merb/trunk/lib framework # Get rid of installed gem, you now run Merb Edge sudo gem uninstall merb Now, you're off gems, and when you help the Merb effort by finding a bug, you can send in a "svn diff" in a simple way. best regards, Olle Jonsson Copenhagen http://ollehost.dk/blog/ [1]: Ezra gives smart recipe http://rubyforge.org/pipermail/merb-devel/2007-March/000060.html From azifali at gmail.com Thu Mar 29 06:37:19 2007 From: azifali at gmail.com (Asif Ali) Date: Thu, 29 Mar 2007 16:07:19 +0530 Subject: error while installing merb Message-ID: <52d8feb90703290337h32e98571q274d65a41278d20c@mail.gmail.com> I got an error while installing merb ------------- ERROR: Error installing gem json-1.0.1.gem[.gem]: ERROR: Failed to build gem native extension. Gem files will remain installed in C:/InstantRails/ruby/lib/ruby/gems/1.8/gems/j son-1.0.1 for inspection. ---------- Can someone tell me what the error is and how to fix it ? Dude -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070329/0979144f/attachment.html