large data set streaming (aka send

17123

true

2010-02-02T21:32:56-08:00

58615

41832

324 large-data-set-streaming-aka-send_data-redux 45

9779

invalid "sinatra streaming send_data large response" large data set streaming (aka send_data redux)

2010-02-03T07:41:30-08:00

17123

Ryan Tomayko

Jordan Ritter

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/324

1.0

Recently ran into a situation in an app where I needed to send back a lot of data (think 50,000 rows of CSV). At first I tried a few different methods joining the rows: @@@ ruby output = rows.join(",") + "\n" output = rows.inject("") { |s, r| s += r .. } @@@ etc etc. But the building of that final string of data with tens of thousands of rows took *minutes*. What I observed was that the larger the string Ruby tried to build, the slower the string append operations got. This happened to be a Rails app so I eventually discovered the render :text => proc {} method, then settled upon the slightly more succinct send_data(). Today I ran into the same problem on one of my sinatra apps. I see from ticket #143 that send_data() was deprecated and is now gone (while send_file() remains). However the solution suggested in that ticket results in the problem I ran into on the Rails app, and necessitates a streaming mechanism to be viable. I ended up creating a simple stream class wrapping my array and implementing #each(), and ending the sinatra callback with a "halt stream". I don't know the reasoning behind deprecating send_data(), but IMHO it was useful and worthwhile. Maybe there's some other streaming facility I'm not aware of that doesn't require building a huge contiguous string in memory? Otherwise it'd be great to have it back..

<div><p>Recently ran into a situation in an app where I needed to send back a lot of data (think 50,000 rows of CSV). At first I tried a few different methods joining the rows:</p> <pre> <code class="ruby">output = rows.join(",") + "\n" output = rows.inject("") { |s, r| s += r .. }</code> </pre> <p>etc etc. But the building of that final string of data with tens of thousands of rows took <em>minutes</em>. What I observed was that the larger the string Ruby tried to build, the slower the string append operations got. This happened to be a Rails app so I eventually discovered the render :text => proc {} method, then settled upon the slightly more succinct send_data().</p> <p>Today I ran into the same problem on one of my sinatra apps. I see from ticket <a href="/projects/9779/tickets/143" title= "Ticket #143">#143</a> that send_data() was deprecated and is now gone (while send_file() remains). However the solution suggested in that ticket results in the problem I ran into on the Rails app, and necessitates a streaming mechanism to be viable. I ended up creating a simple stream class wrapping my array and implementing #each(), and ending the sinatra callback with a "halt stream".<br></p> <p>I don't know the reasoning behind deprecating send_data(), but IMHO it was useful and worthwhile. Maybe there's some other streaming facility I'm not aware of that doesn't require building a huge contiguous string in memory? Otherwise it'd be great to have it back..</p></div>

17123

false

2009-08-14T06:53:48-07:00

66277

2012-12-31T00:00:00-08:00

27724

274 requests-for-same-route-different-request_method-should-return-http-405 34

9779

open http routing Requests for same route, different REQUEST_METHOD should return HTTP 405

2010-02-02T16:55:00-08:00

17123

Ryan Tomayko

Nick

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/274

Future

A sinatra app like: @@@ ruby get '/' do "Foo" end @@@ Will return a 404 response for PUT, POST, DELETE, etc requests - I believe it should return a 405 (BAD METHOD) code instead, and set the Accept: header of the response to be a comma-separated list of methods with a registered matching route. Currently I'm implementing this in a before filter, as follows: @@@ ruby before do methods_with_routes = ['GET', 'POST', 'PUT', 'HEAD', 'DELETE'].select do |m| self.class.routes[m] && self.class.routes[m].select {|r| request.path_info.match(r[0]) }.nitems > 0 end begin error_bad_method(methods_with_routes) unless methods_with_routes.include?(request.request_method) end unless methods_with_routes.empty? end helpers do def error_bad_method(good_methods = {}) response['Allow'] = good_methods.map {|m| m.to_s.upcase }.join(', ') halt 405, "Bad method" end end @@@ Really, it's a bit of sugar, but it helps for some applications. Doing it in core would be more efficient than a before-filter, I suspect, 'though I've no idea how to make the latter happen. I've only been using sinatra for the past week or so :D

<div><p>A sinatra app like:</p> <pre><code class="ruby"> get '/' do "Foo" end </code></pre> <p>Will return a 404 response for PUT, POST, DELETE, etc requests - I believe it should return a 405 (BAD METHOD) code instead, and set the Accept: header of the response to be a comma-separated list of methods with a registered matching route.</p> <p>Currently I'm implementing this in a before filter, as follows:</p> <pre><code class="ruby"> before do methods_with_routes = ['GET', 'POST', 'PUT', 'HEAD', 'DELETE'].select do |m| self.class.routes[m] && self.class.routes[m].select {|r| request.path_info.match(r[0]) }.nitems > 0 end begin error_bad_method(methods_with_routes) unless methods_with_routes.include?(request.request_method) end unless methods_with_routes.empty? end helpers do def error_bad_method(good_methods = {}) response['Allow'] = good_methods.map {|m| m.to_s.upcase }.join(', ') halt 405, "Bad method" end end </code></pre> <p>Really, it's a bit of sugar, but it helps for some applications. Doing it in core would be more efficient than a before-filter, I suspect, 'though I've no idea how to make the latter happen. I've only been using sinatra for the past week or so :D</p></div>

17123

true

2010-02-01T10:58:44-08:00

26790

2010-02-08T00:00:00-08:00

41832

322 two-requests-to-the-same-location-when-using-sinatrabase 1

9779

invalid bug "duplicate requests" "sinatra base" Two requests to the same location when using Sinatra::Base

2010-02-02T00:56:25-08:00

17123

Ryan Tomayko

Kieran P

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/322

1.0

The weirdest thing happened. I converted my single sinatra app file into a rack app (config.ru, run Application, class Application < Sinatra::Base). Anyway, it worked fine. Booted, loaded a page. But it took a while. I looked at the logs. It was making two requests to each location. Each page, each image, even each favicon, twice loaded. I reverted back to single file, and it went back to only one request. Has anyone else experienced this issue? The changes I made are here: http://github.com/KieranP/vboxweb_rb/commit/fa4c818d6eae2e8210cabe756056a70ef2914d92 Hopefully pretty standard.

<div><p>The weirdest thing happened. I converted my single sinatra app file into a rack app (config.ru, run Application, class Application < Sinatra::Base). Anyway, it worked fine. Booted, loaded a page.</p> <p>But it took a while. I looked at the logs. It was making two requests to each location. Each page, each image, even each favicon, twice loaded.</p> <p>I reverted back to single file, and it went back to only one request.</p> <p>Has anyone else experienced this issue?</p> <p>The changes I made are here: <a href= "http://github.com/KieranP/vboxweb_rb/commit/fa4c818d6eae2e8210cabe756056a70ef2914d92"> http://github.com/KieranP/vboxweb_rb/commit/fa4c818d6eae2e8210cabe7...</a></p> <p>Hopefully pretty standard.</p></div>

17123

false

2010-02-01T17:51:49-08:00

18387

2010-02-08T00:00:00-08:00

41832

323 error-block-not-being-called-in-a-sinatrabase-app 2

9779

new error error block not being called in a "sinatra/base" app

2010-02-01T18:31:14-08:00

17123

Ryan Tomayko

Alex Chaffee

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/323

1.0

The Sinatra Readme says, "The error handler is invoked any time an exception is raised from a route block or a filter." And this is true inside a "top level" Sinatra app. But it isn't working in a "base style" Sinatra app -- I get a blank page in Firefox and in Safari it says "Safari can’t open the page “http://localhost:4567/” because the server unexpectedly dropped the connection." http://gist.github.com/292270 This also happens when run with thin via a config.ru file.

<div><p>The Sinatra Readme says, "The error handler is invoked any time an exception is raised from a route block or a filter." And this is true inside a "top level" Sinatra app. But it isn't working in a "base style" Sinatra app -- I get a blank page in Firefox and in Safari it says "Safari can’t open the page “<a href= "http://localhost:4567/%E2%80%9D">http://localhost:4567/”</a> because the server unexpectedly dropped the connection."</p> <p><a href= "http://gist.github.com/292270">http://gist.github.com/292270</a></p> <p>This also happens when run with thin via a config.ru file.</p></div>

11306

false

2009-10-04T06:31:15-07:00

11306

2012-12-31T00:00:00-08:00

27724

288 fix-localjumperror-errors-on-jruby 4

9779

new jruby tilt Fix LocalJumpError errors on jRuby

2010-01-28T11:48:55-08:00

17123

Ryan Tomayko

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/288

Future

`templates_test.rb` is currently failing under jRuby

<div><p><code>templates_test.rb</code> is currently failing under jRuby</p></div>

11306

false

2009-05-18T04:16:46-07:00

11306

2012-12-31T00:00:00-08:00

27724

230 document-route-condition 3

9779

new doc Document route condition

2010-01-28T11:48:50-08:00

17123

Ryan Tomayko

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/230

Future

17123

true

2009-12-22T19:15:23-08:00

17123

2010-02-08T00:00:00-08:00

41832

312 obsolete-sinatradefault-or-not 2

9779

resolved Obsolete Sinatra::Default (or not)

2010-01-28T11:48:33-08:00

17123

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/312

1.0

This and #308 are the last major backward-compatibility issues blocking 1.0 that I'm aware of. First, see #240 (Base vs. Default vs. Application) for discussion on why these classes existed in the first place and how they're being used today in the wild. Here's a table that describes every single difference between each of the classes: <table border='1' cellpadding='5'> <tr> <td>Target for top-level routes, filters, options, and error handlers</td> <td><code>false</code></td> <td><code>false</code></td> <td><code>true</code></td> </tr> <tr> <td>Automatically register all extensions</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <th>Behavior</th> <th>Sinatra::Base</th> <th>Sinatra::Default</th> <th>Sinatra::Application</th> </tr> <tr> <td> <code>:raise_errors</code> - raises exceptions from <code>#call</code> instead of returning an <code>[500, ...]</code> error tuple. </td> <td><code>true</code></td> <td><code>false</code></td> <td><code>false</code></td> </tr> <tr> <td><code>:dump_errors</code> - write exceptions to rack.errors</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:show_exceptions</code> - don't raise exceptions, return development error page</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:logging</code> - log requests to rack.errors</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:methodoverride</code> - enable POST _method replacement</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:static</code> - check for and serve static files</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:run</code> - auto start server in at_exit hook</td> <td><code>false</code></td> <td><code>false</code></td> <td><code>true</code></td> </tr> </table> In #240, we decided to deprecate `Default` in preference to `Application` but, after discussing with sr a bit on IRC today, we're not sure obsoleting or aliasing to Application is feasible right now: * Note that aliasing Default to Application has only landed on master [7f5d4df](http://github.com/sinatra/sinatra/commit/7f5d4dfb8a2588fa888e48fbacf6d977a4cdbf3e) and hasn't went out in an official release so we have complete freedom to do whatever we want here. * No deprecation warning has been added to an 0.9.x release about `Default` going away in 1.0. * Default is used a lot in the wild. I'd estimate something like 50%-75% of class based apps subclass `Default` instead of `Base` or `Application`. * The behavior of `Default` is slightly different from that of `Application` (as can be seen in the table above). Most importantly, routes, filters, error handlers, or options set at the top-level are set on `Application` whereas this is not the case with `Default`. I don't think people subclassing `Default` would expect a route defined at the top-level to effect their class, so aliasing `Default` to `Application` (current behavior on master) seems wrong to me. Further complicating matters is that neither sr or myself use `Default` and have always opted instead to subclass `Base` and set options explicitly. This is making it hard for us to judge the utility of `Default` and come up with a solution that works for people that do use `Default`. Given all that, I think we have the following options: 1. Don't deprecate/obsolete anything. Leave `Default` and `Application` exactly as they are in the table above / 0.9.x. This is is the least incompatible change but means we're going to spend the rest of our lives trying to explain the difference between all of these classes to people. 2. Make `Default` an alias for `Application` (current master behavior). This is fairly compatible with 0.9.x and would let us tell people to use either `Base` or `Application` in the future. 3. Make `Default` an alias for `Base` and make `Base` a bit more intelligent about default options. For example, we can enable `:show_exceptions` by default in the development environment and automatically enable `:static` when the `:public` option is set. This would make `Base` act a lot more like `Default` in cases where people expect it and is also basically compatible with 0.9.x. Bottom line is we need Blake and others that care about `Default` to weigh in here with what makes the most sense to them and we need a decision for we can release 1.0.

<div><p>This and <a href="/projects/9779/tickets/308" title= "Ticket #308">#308</a> are the last major backward-compatibility issues blocking 1.0 that I'm aware of.</p> <p>First, see <a href="/projects/9779/tickets/240" title= "Ticket #240">#240</a> (Base vs. Default vs. Application) for discussion on why these classes existed in the first place and how they're being used today in the wild.</p> <p>Here's a table that describes every single difference between each of the classes:</p> <table> <tr> <td>Target for top-level routes, filters, options, and error handlers</td> <td><code>false</code></td> <td><code>false</code></td> <td><code>true</code></td> </tr> <tr> <td>Automatically register all extensions</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <th>Behavior</th> <th>Sinatra::Base</th> <th>Sinatra::Default</th> <th>Sinatra::Application</th> </tr> <tr> <td><code>:raise_errors</code> - raises exceptions from <code>#call</code> instead of returning an <code>[500, ...]</code> error tuple.</td> <td><code>true</code></td> <td><code>false</code></td> <td><code>false</code></td> </tr> <tr> <td><code>:dump_errors</code> - write exceptions to rack.errors</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:show_exceptions</code> - don't raise exceptions, return development error page</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:logging</code> - log requests to rack.errors</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:methodoverride</code> - enable POST _method replacement</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:static</code> - check for and serve static files</td> <td><code>false</code></td> <td><code>true</code></td> <td><code>true</code></td> </tr> <tr> <td><code>:run</code> - auto start server in at_exit hook</td> <td><code>false</code></td> <td><code>false</code></td> <td><code>true</code></td> </tr> </table> <p>In <a href="/projects/9779/tickets/240" title= "Ticket #240">#240</a>, we decided to deprecate <code>Default</code> in preference to <code>Application</code> but, after discussing with sr a bit on IRC today, we're not sure obsoleting or aliasing to Application is feasible right now:</p> <ul> <li>Note that aliasing Default to Application has only landed on master <a href= "http://github.com/sinatra/sinatra/commit/7f5d4dfb8a2588fa888e48fbacf6d977a4cdbf3e"> 7f5d4df</a> and hasn't went out in an official release so we have complete freedom to do whatever we want here.</li> <li>No deprecation warning has been added to an 0.9.x release about <code>Default</code> going away in 1.0.</li> <li>Default is used a lot in the wild. I'd estimate something like 50%-75% of class based apps subclass <code>Default</code> instead of <code>Base</code> or <code>Application</code>.</li> <li>The behavior of <code>Default</code> is slightly different from that of <code>Application</code> (as can be seen in the table above). Most importantly, routes, filters, error handlers, or options set at the top-level are set on <code>Application</code> whereas this is not the case with <code>Default</code>. I don't think people subclassing <code>Default</code> would expect a route defined at the top-level to effect their class, so aliasing <code>Default</code> to <code>Application</code> (current behavior on master) seems wrong to me.</li> </ul> <p>Further complicating matters is that neither sr or myself use <code>Default</code> and have always opted instead to subclass <code>Base</code> and set options explicitly. This is making it hard for us to judge the utility of <code>Default</code> and come up with a solution that works for people that do use <code>Default</code>.</p> <p>Given all that, I think we have the following options:</p> <ol> <li> <p>Don't deprecate/obsolete anything. Leave <code>Default</code> and <code>Application</code> exactly as they are in the table above / 0.9.x. This is is the least incompatible change but means we're going to spend the rest of our lives trying to explain the difference between all of these classes to people.</p> </li> <li> <p>Make <code>Default</code> an alias for <code>Application</code> (current master behavior). This is fairly compatible with 0.9.x and would let us tell people to use either <code>Base</code> or <code>Application</code> in the future.</p> </li> <li> <p>Make <code>Default</code> an alias for <code>Base</code> and make <code>Base</code> a bit more intelligent about default options. For example, we can enable <code>:show_exceptions</code> by default in the development environment and automatically enable <code>:static</code> when the <code>:public</code> option is set. This would make <code>Base</code> act a lot more like <code>Default</code> in cases where people expect it and is also basically compatible with 0.9.x.</p> </li> </ol> <p>Bottom line is we need Blake and others that care about <code>Default</code> to weigh in here with what makes the most sense to them and we need a decision for we can release 1.0.</p></div>

17123

true

2010-01-27T18:42:36-08:00

58615

2010-02-08T00:00:00-08:00

41832

321 need-a-way-to-disable-tilt-want-non-caching-behavior-when-in-development 44

9779

resolved "sinatra tilt caching reloading" need a way to disable tilt (want non-caching behavior when in development)

2010-01-28T10:09:06-08:00

58615

Jordan Ritter

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/321

1.0

I just updated to latest master (466cc74), which includes Tilt for caching my view templates. This is awesome for production. However, it looks like they're cached no matter what, regardless of RACK_ENV? This results in a different behavior than before: I can't just tweak a template and have that change show up; I have to ^C/restart the app. Kind of a bummer. (FYI, I don't use shotgun - I extend Rack::Reloader to properly handle the specifics of reloading my app files.) I looked through the code and AFAICT there doesn't appear to be a way to disable this caching/Tilt. Unless I've missed the mark on this, I'd suggest an enable/disable option for this, such that one could pop the desired setting into 'configure :development/:production' blocks like most of the other options.

<div><p>I just updated to latest master (466cc74), which includes Tilt for caching my view templates. This is awesome for production.</p> <p>However, it looks like they're cached no matter what, regardless of RACK_ENV? This results in a different behavior than before: I can't just tweak a template and have that change show up; I have to ^C/restart the app. Kind of a bummer.</p> <p>(FYI, I don't use shotgun - I extend Rack::Reloader to properly handle the specifics of reloading my app files.)</p> <p>I looked through the code and AFAICT there doesn't appear to be a way to disable this caching/Tilt. Unless I've missed the mark on this, I'd suggest an enable/disable option for this, such that one could pop the desired setting into 'configure :development/:production' blocks like most of the other options.</p></div>

17123

true

2010-01-27T17:36:22-08:00

58615

2010-02-08T00:00:00-08:00

41832

320 with-static-enabled-after-filters-always-run-while-before-filters-dont 3

9779

resolved "sinatra after before filter" with :static enabled, after filters always run while before filters don't

2010-01-28T10:07:54-08:00

58615

Jordan Ritter

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/320

1.0

When: 1. using a modular sinatra app (haven't tested classic fwiw) 2. enabling :static, setting :public 3. hitting a static file Sinatra fires the after filter, but not the before filter. Example script and output: http://gist.github.com/288331

<div><p>When:<br></p> <ol> <li>using a modular sinatra app (haven't tested classic fwiw)</li> <li>enabling :static, setting :public</li> <li>hitting a static file</li> </ol> <p>Sinatra fires the after filter, but not the before filter.</p> <p>Example script and output: <a href= "http://gist.github.com/288331">http://gist.github.com/288331</a></p></div>

false

2008-06-09T01:09:02-07:00

9991

2012-12-31T00:00:00-08:00

27724

31 nested-resources 2

9779

new "feature patch" routes routing Nested resources

2010-01-21T17:21:35-08:00

47545

Mike (at coverallcrew)

Adam Wiggins

http://sinatra.lighthouseapp.com/projects/9779/tickets/31

Future

Ok here's the more controversial feature addition. Feel free to shoot it down. :) Nested resources: @@@ resource 'posts' do get do # show all posts end post do # create new post end end resource 'posts/:id' do get do # show post params[:id] end delete do # destroy post params[:id] end get 'comments' do # show this post's comments end end @@@ The patch: http://github.com/adamwiggins/sinatra/commit/b0b67602be141dcc835e91443e3120e5b1acbc9d I was hesitant about this idea, since I do really like that typing "egrep '^(get|put|post|delete)' myapp.rb" returns all the full URLs. But for larger apps, having a bit more organization is really nice. And since it only adds ~20 lines of code and doesn't disrupt any existing syntax, it seemed like a net win overall. Curious to hear feedback.

<div><p> Ok here's the more controversial feature addition. Feel free to shoot it down. :) </p><p> Nested resources: </p> <pre><code class="">resource 'posts' do get do # show all posts end post do # create new post end end resource 'posts/:id' do get do # show post params[:id] end delete do # destroy post params[:id] end get 'comments' do # show this post's comments end end </code></pre> <p> The patch: </p><p> <a href="http://github.com/adamwiggins/sinatra/commit/b0b67602be141dcc835e91443e3120e5b1acbc9d">http://github.com/adamwiggins/si...</a> </p><p> I was hesitant about this idea, since I do really like that typing "egrep '^(get|put|post|delete)' myapp.rb" returns all the full URLs. But for larger apps, having a bit more organization is really nice. And since it only adds ~20 lines of code and doesn't disrupt any existing syntax, it seemed like a net win overall. </p><p> Curious to hear feedback. </p></div>

17123

false

2010-01-18T09:44:09-08:00

83099

2012-12-31T00:00:00-08:00

27724

319 marshaldump-chokes-on-params-hash 36

9779

new Marshal.dump chokes on params hash

2010-01-18T21:19:20-08:00

17123

Ryan Tomayko

Jeremy Stephens

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/319

Future

Marshal.dump is unable to handle the hash returned by the params method when posting. Attached is a test case. I tried this in Rack with no problems.

<div><p>Marshal.dump is unable to handle the hash returned by the params method when posting. Attached is a test case. I tried this in Rack with no problems.</p></div>

17123

false

2009-12-09T07:01:59-08:00

75124

2012-12-31T00:00:00-08:00

27724

306 added-middleware-example-to-readme 35

9779

new doc Added middleware example to README

2010-01-16T04:12:28-08:00

17123

Ryan Tomayko

Bill Gathen

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/306

Future

I added an example of using Sinatra for non-endpoint middleware, using +forward+. My fork is at billgathen/sinatra on GitHub. My first contribution, so forgive me if I'm doing this wrong. :-) - Bill

<div><p>I added an example of using Sinatra for non-endpoint middleware, using +forward+.</p> <p>My fork is at billgathen/sinatra on GitHub.</p> <p>My first contribution, so forgive me if I'm doing this wrong. :-)</p> <ul> <li>Bill</li> </ul></div>

17123

true

2009-12-11T14:50:08-08:00

17123

2010-02-08T00:00:00-08:00

41832

310 sinatra-10-faq 41

9779

resolved Sinatra 1.0 FAQ

2010-01-16T04:11:57-08:00

17123

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/310

1.0

I've started putting together a FAQ for 1.0: http://rtomayko.github.com/draft/sinatra-one-oh-faq.html I'm move this over to sinatra.github.com shortly (unlinked) so we can collab on it. For now, I'm hoping to get a list of things that should be mentioned logged here.

<div><p>I've started putting together a FAQ for 1.0:</p> <p><a href= "http://rtomayko.github.com/draft/sinatra-one-oh-faq.html">http://rtomayko.github.com/draft/sinatra-one-oh-faq.html</a></p> <p>I'm move this over to sinatra.github.com shortly (unlinked) so we can collab on it. For now, I'm hoping to get a list of things that should be mentioned logged here.</p></div>

11306

true

2009-12-29T15:43:43-08:00

43313

2010-02-08T00:00:00-08:00

41832

316 disable-logger-is-ignored-on-webrick 35

9779

invalid `disable :logging` is ignored on webrick

2010-01-15T21:16:26-08:00

43313

ujihisa

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/316

1.0

Both in Sinatra 0.9.4 and the git trunk 6c9488e22a9ca76b66c31e74ee26f737ba0e87cb, `disable :logger` is ignored when Sinatra uses Webrick. On 0.9.4: @@@ ruby require 'rubygems' require 'sinatra' set :server, 'webrick' disable :logger get '/' do '' end @@@ $ ruby -v b.rb ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9] == Sinatra/0.9.4 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 15:40:16] INFO WEBrick 1.3.1 [2009-12-29 15:40:16] INFO ruby 1.8.7 (2009-06-12) [i686-darwin9] [2009-12-29 15:40:16] INFO WEBrick::HTTPServer#start: pid=6453 port=4567 127.0.0.1 - - [29/Dec/2009 15:40:26] "GET / HTTP/1.1" 200 - 0.0004 localhost - - [29/Dec/2009:15:40:26 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:40:26] "GET / HTTP/1.1" 200 - 0.0009 localhost - - [29/Dec/2009:15:40:26 PST] "GET / HTTP/1.1" 200 0 - -> / ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 15:40:30] INFO going to shutdown ... [2009-12-29 15:40:30] INFO WEBrick::HTTPServer#start done. On Trunk: @@@ ruby def require_vendor(o) o = o.to_s $: << o $: << o + '/lib' require o end require_vendor :rack require_vendor :sinatra disable :logger get '/' do '' end @@@ $ ruby -v a.rb ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9] == Sinatra/0.10.1 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 15:42:32] INFO WEBrick 1.3.1 [2009-12-29 15:42:32] INFO ruby 1.8.7 (2009-06-12) [i686-darwin9] [2009-12-29 15:42:32] INFO WEBrick::HTTPServer#start: pid=6456 port=4567 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET / HTTP/1.1" 200 - 0.0007 localhost - - [29/Dec/2009:15:42:35 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET /favicon.ico HTTP/1.1" 404 420 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET /favicon.ico HTTP/1.1" 404 420 http://localhost:4567/ -> /favicon.ico 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET / HTTP/1.1" 200 - 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET /favicon.ico HTTP/1.1" 404 420 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET /favicon.ico HTTP/1.1" 404 420 http://localhost:4567/ -> /favicon.ico ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 15:42:39] INFO going to shutdown ... [2009-12-29 15:42:39] INFO WEBrick::HTTPServer#start done.

<div><p>Both in Sinatra 0.9.4 and the git trunk 6c9488e22a9ca76b66c31e74ee26f737ba0e87cb,<br> <code>disable :logger</code> is ignored when Sinatra uses Webrick.</p> <p>On 0.9.4:</p> <pre> <code class="ruby"> require 'rubygems' require 'sinatra' set :server, 'webrick' disable :logger get '/' do '' end</code> </pre> <pre> <code>$ ruby -v b.rb ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9] == Sinatra/0.9.4 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 15:40:16] INFO WEBrick 1.3.1 [2009-12-29 15:40:16] INFO ruby 1.8.7 (2009-06-12) [i686-darwin9] [2009-12-29 15:40:16] INFO WEBrick::HTTPServer#start: pid=6453 port=4567 127.0.0.1 - - [29/Dec/2009 15:40:26] "GET / HTTP/1.1" 200 - 0.0004 localhost - - [29/Dec/2009:15:40:26 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:40:26] "GET / HTTP/1.1" 200 - 0.0009 localhost - - [29/Dec/2009:15:40:26 PST] "GET / HTTP/1.1" 200 0 - -> / ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 15:40:30] INFO going to shutdown ... [2009-12-29 15:40:30] INFO WEBrick::HTTPServer#start done.</code> </pre> <p>On Trunk:</p> <pre> <code class="ruby"> def require_vendor(o) o = o.to_s $: << o $: << o + '/lib' require o end require_vendor :rack require_vendor :sinatra disable :logger get '/' do '' end</code> </pre> <pre> <code>$ ruby -v a.rb ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9] == Sinatra/0.10.1 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 15:42:32] INFO WEBrick 1.3.1 [2009-12-29 15:42:32] INFO ruby 1.8.7 (2009-06-12) [i686-darwin9] [2009-12-29 15:42:32] INFO WEBrick::HTTPServer#start: pid=6456 port=4567 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET / HTTP/1.1" 200 - 0.0007 localhost - - [29/Dec/2009:15:42:35 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET /favicon.ico HTTP/1.1" 404 420 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET /favicon.ico HTTP/1.1" 404 420 http://localhost:4567/ -> /favicon.ico 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET / HTTP/1.1" 200 - 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET / HTTP/1.1" 200 0 - -> / 127.0.0.1 - - [29/Dec/2009 15:42:35] "GET /favicon.ico HTTP/1.1" 404 420 0.0006 localhost - - [29/Dec/2009:15:42:35 PST] "GET /favicon.ico HTTP/1.1" 404 420 http://localhost:4567/ -> /favicon.ico ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 15:42:39] INFO going to shutdown ... [2009-12-29 15:42:39] INFO WEBrick::HTTPServer#start done.</code> </pre></div>

17123

true

2009-12-14T01:10:39-08:00

25849

2010-02-08T00:00:00-08:00

41832

311 192-and-lambda-argument-to-route_eval 4

9779

resolved 1.9.2 and lambda argument to #route_eval

2010-01-15T05:56:17-08:00

25849

Lourens Naudé

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/311

1.0

Hi, I had an issue over the weekend with Ruby 1.9.2 trunk's recent changeset that aligns instance_eval etc. with the 1.8 implementation. Reported here : http://redmine.ruby-lang.org/issues/show/2476 Suggestion being to let the block passed be a Proc, and not a lambda : # Run a route block and throw :halt with the result. def route_eval(&block) throw :halt, instance_eval(&block) end

<div><p>Hi,</p> <p>I had an issue over the weekend with Ruby 1.9.2 trunk's recent changeset that aligns instance_eval etc. with the 1.8 implementation.</p> <p>Reported here :<br> <a href= "http://redmine.ruby-lang.org/issues/show/2476">http://redmine.ruby-lang.org/issues/show/2476</a></p> <p>Suggestion being to let the block passed be a Proc, and not a lambda :<br> # Run a route block and throw :halt with the result.</p> <pre> <code>def route_eval(&block) throw :halt, instance_eval(&block) end</code> </pre></div>

17123

true

2009-12-29T16:11:14-08:00

43313

2010-02-08T00:00:00-08:00

41832

317 sinatra-doesnt-work-on-ruby-192 40

9779

dupe Sinatra Doesn't Work on Ruby 1.9.2

2010-01-15T05:16:44-08:00

17123

Ryan Tomayko

ujihisa

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/317

1.0

Both Sinatra 0.9.4 and the git trunk cannot run well on Ruby trunk. @@@ ruby require 'rubygems' require 'sinatra' set :server, 'webrick' disable :logger get '/' do '' end @@@ $ ruby192 -v b.rb ruby 1.9.2dev (2009-12-29 trunk 26197) [i386-darwin9.8.0] /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:1057: warning: previous definition of run was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run? /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:625: warning: previous definition of run? was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run= /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:626: warning: previous definition of run= was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:14: warning: shadowing outer local variable - line /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:41: warning: shadowing outer local variable - hash == Sinatra/0.9.4 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 16:04:11] INFO WEBrick 1.3.1 [2009-12-29 16:04:11] INFO ruby 1.9.2 (2009-12-29) [i386-darwin9.8.0] [2009-12-29 16:04:11] INFO WEBrick::HTTPServer#start: pid=8723 port=4567 ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:23] "GET / HTTP/1.1" 500 82483 0.2460 localhost - - [29/Dec/2009:16:04:23 PST] "GET / HTTP/1.1" 500 82483 - -> / ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:24] "GET /__sinatra__/500.png HTTP/1.1" 500 82611 0.3827 localhost - - [29/Dec/2009:16:04:23 PST] "GET /__sinatra__/500.png HTTP/1.1" 500 82611 http://localhost:4567/ -> /__sinatra__/500.png ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:24] "GET /favicon.ico HTTP/1.1" 500 82579 0.3136 localhost - - [29/Dec/2009:16:04:24 PST] "GET /favicon.ico HTTP/1.1" 500 82579 http://localhost:4567/ -> /favicon.ico ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 16:04:29] INFO going to shutdown ... [2009-12-29 16:04:29] INFO WEBrick::HTTPServer#start done. /tmp/thins

<div><p>Both Sinatra 0.9.4 and the git trunk cannot run well on Ruby trunk.</p> <pre> <code class="ruby"> require 'rubygems' require 'sinatra' set :server, 'webrick' disable :logger get '/' do '' end</code> </pre> <pre> <code>$ ruby192 -v b.rb ruby 1.9.2dev (2009-12-29 trunk 26197) [i386-darwin9.8.0] /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:1057: warning: previous definition of run was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run? /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:625: warning: previous definition of run? was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:948: warning: method redefined; discarding old run= /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:626: warning: previous definition of run= was here /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:14: warning: shadowing outer local variable - line /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:41: warning: shadowing outer local variable - hash == Sinatra/0.9.4 has taken the stage on 4567 for development with backup from WEBrick [2009-12-29 16:04:11] INFO WEBrick 1.3.1 [2009-12-29 16:04:11] INFO ruby 1.9.2 (2009-12-29) [i386-darwin9.8.0] [2009-12-29 16:04:11] INFO WEBrick::HTTPServer#start: pid=8723 port=4567 ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:23] "GET / HTTP/1.1" 500 82483 0.2460 localhost - - [29/Dec/2009:16:04:23 PST] "GET / HTTP/1.1" 500 82483 - -> / ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:24] "GET /__sinatra__/500.png HTTP/1.1" 500 82611 0.3827 localhost - - [29/Dec/2009:16:04:23 PST] "GET /__sinatra__/500.png HTTP/1.1" 500 82611 http://localhost:4567/ -> /__sinatra__/500.png ArgumentError - wrong number of arguments (1 for 0): /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'ArgumentError: wrong number of arguments (1 for 0) /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:474:in `route_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:463:in `block (2 levels) in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:460:in `block in route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `each' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:439:in `route!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:555:in `dispatch!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `block in call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `instance_eval' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `block in invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `catch' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:522:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/compat.rb:138:in `invoke' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:375:in `call!' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:364:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in `_call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `block in call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:943:in `synchronize' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/sinatra-0.9.4/lib/sinatra/base.rb:898:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call' /Users/ujihisa/rubies/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /Users/ujihisa/rubies/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' 127.0.0.1 - - [29/Dec/2009 16:04:24] "GET /favicon.ico HTTP/1.1" 500 82579 0.3136 localhost - - [29/Dec/2009:16:04:24 PST] "GET /favicon.ico HTTP/1.1" 500 82579 http://localhost:4567/ -> /favicon.ico ^C == Sinatra has ended his set (crowd applauds) [2009-12-29 16:04:29] INFO going to shutdown ... [2009-12-29 16:04:29] INFO WEBrick::HTTPServer#start done. /tmp/thins</code> </pre></div>

11306

true

2010-01-11T10:04:32-08:00

36235

2010-02-08T00:00:00-08:00

41832

318 rackup-e-production-does-not-call-config-blocks 37

9779

invalid rackup -E production does not call config blocks

2010-01-14T10:21:06-08:00

17123

Ryan Tomayko

TJ Holowaychuk

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/318

1.0

@@@ ruby configure do p 'configure' end configure :production do p 'configure production' end @@@ with `$ rackup -E production` etc does not call the second block, maybe I misunderstood how this is supposed to be used

<div><pre> <code class="ruby">configure do p 'configure' end configure :production do p 'configure production' end</code> </pre> <p>with <code>$ rackup -E production</code> etc does not call the second block, maybe I misunderstood how<br> this is supposed to be used</p></div>

17123

true

2009-12-27T08:40:33-08:00

12893

2010-02-08T00:00:00-08:00

41832

315 before-filters 4

9779

wontfix filters Before Filters

2009-12-28T12:12:27-08:00

12893

DAddYE

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/315

1.0

Hi, It's possible in next release eval filters in route_eval or some where so we can get the route params? Take this example @@@ ruby before do I18n.locale = params[:locale] if params[:locale] end get "/:locale/posts" do; end get "/:locale/posts/:id" do; end put "/:locale/posts/:id" do; end ... @@@ Now is not possible do that (with this simple way) or Im wrong? Why do some like this: @@@ ruby def route_eval(&block) before_filter! throw :halt, instance_eval(&block) after_filter! end @@@ Thanks!

<div><p>Hi,</p> <p>It's possible in next release eval filters in route_eval or some where so we can get the route params?</p> <p>Take this example</p> <pre> <code class="ruby">before do I18n.locale = params[:locale] if params[:locale] end get "/:locale/posts" do; end get "/:locale/posts/:id" do; end put "/:locale/posts/:id" do; end ...</code> </pre> <p>Now is not possible do that (with this simple way) or Im wrong?</p> <p>Why do some like this:</p> <pre> <code class="ruby"> def route_eval(&block) before_filter! throw :halt, instance_eval(&block) after_filter! end</code> </pre> <p>Thanks!</p></div>

11306

true

2009-12-22T23:07:41-08:00

42236

2010-02-08T00:00:00-08:00

41832

314 racksession-variable-is-missing-env-under-test-environment 35

9779

resolved rack.session variable is missing env under test environment

2009-12-25T19:14:18-08:00

11306

Simon Rozet

sankar

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/314

1.0

hi i just try to set session in rack middleware under development and production the code works fine. but in test mode the env['rack.session'] is missing. below is sample code hello_rack.rb class HelloRack def initialize(app) @app = app end def call(env) session = env['rack.session'] puts env.inspect unless session[:user] session[:user] = "matz" end status,headers,response = @app.call(env) [status,headers, response] end end hello_world.rb require 'rubygems' require 'sinatra' require File.dirname(__FILE__)+'/hello_rack' use HelloRack enable :sessions get '/' do user = session[:user] || "sankar" "Hello World! #{user}" end sinatra_test.rb require File.dirname(__FILE__)+'/hello_world' # <-- your sinatra app require 'test/spec' require 'rack/test' set :environment, :test describe 'The HelloWorld App' do include Rack::Test::Methods def app Sinatra::Application end it "says hello" do get '/' last_response.should.be.ok last_response.body.should.equal 'Hello World' end end i got the following error {"rack.test"=>true, "SERVER_NAME"=>"example.org", "CONTENT_LENGTH"=>"0", "rack.url_scheme"=>"http", "rack.errors"=>#<StringIO:0xb7a328cc>, "REMOTE_ADDR"=>"127.0.0.1", "PATH_INFO"=>"/", "rack.version"=>[0, 1], "rack.run_once"=>false, "rack.request"=>#<Rack::Request:0xb7a325e8 @env={...}>, "SCRIPT_NAME"=>"", "HTTP_COOKIE"=>"", "rack.multithread"=>true, "rack.multiprocess"=>true, "SERVER_PORT"=>"80", "REQUEST_METHOD"=>"GET", "QUERY_STRING"=>"", "rack.input"=>#<StringIO:0xb7a3287c>} E Finished in 0.06553 seconds. 1) Error: test_spec {The HelloWorld App} 001 [says hello](The HelloWorld App): NoMethodError: undefined method `[]' for nil:NilClass ./hello_rack.rb:10:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/methodoverride.rb:24:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:898:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:943:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:898:in `call' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/mock_session.rb:30:in `request' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/test.rb:207:in `process_request' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/test.rb:57:in `get' sinatra_test.rb:15:in `test_spec {The HelloWorld App} 001 [says hello]' 1 tests, 0 assertions, 0 failures, 1 errors shell returned 1

<div><p>hi<br> i just try to set session in rack middleware under development and production the code works fine. but in test mode the env['rack.session'] is missing.</p> <p>below is sample code<br> hello_rack.rb<br> class HelloRack<br> def initialize(app)</p> <pre> <code>@app = app</code> </pre> <p>end def call(env)<br></p> <pre> <code> session = env['rack.session'] puts env.inspect unless session[:user] session[:user] = "matz" end status,headers,response = @app.call(env) [status,headers, response]</code> </pre> <p>end end</p> <p>hello_world.rb<br> require 'rubygems'<br> require 'sinatra'<br> require File.dirname(<strong>FILE</strong>)+'/hello_rack'<br> use HelloRack<br> enable :sessions</p> <p>get '/' do<br> user = session[:user] || "sankar" "Hello World! #{user}" end</p> <p>sinatra_test.rb<br> require File.dirname(<strong>FILE</strong>)+'/hello_world' # <-- your sinatra app<br> require 'test/spec'<br> require 'rack/test'</p> <p>set :environment, :test</p> <p>describe 'The HelloWorld App' do<br> include Rack::Test::Methods</p> <p>def app</p> <pre> <code>Sinatra::Application</code> </pre> <p>end</p> <p>it "says hello" do</p> <pre> <code>get '/' last_response.should.be.ok last_response.body.should.equal 'Hello World'</code> </pre> <p>end end</p> <p>i got the following error</p> <p>{"rack.test"=>true, "SERVER_NAME"=>"example.org", "CONTENT_LENGTH"=>"0", "rack.url_scheme"=>"http", "rack.errors"=>#<StringIO:0xb7a328cc>, "REMOTE_ADDR"=>"127.0.0.1", "PATH_INFO"=>"/", "rack.version"=>[0, 1], "rack.run_once"=>false, "rack.request"=>#<Rack::Request:0xb7a325e8 @env={...}>, "SCRIPT_NAME"=>"", "HTTP_COOKIE"=>"", "rack.multithread"=>true, "rack.multiprocess"=>true, "SERVER_PORT"=>"80", "REQUEST_METHOD"=>"GET", "QUERY_STRING"=>"", "rack.input"=>#<StringIO:0xb7a3287c>} E<br> Finished in 0.06553 seconds.</p> <p>1) Error: test_spec {The HelloWorld App} 001 [says hello](The HelloWorld App):<br> NoMethodError: undefined method <code>[]' for nil:NilClass<br/></code></p> <pre> <code>./hello_rack.rb:10:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/methodoverride.rb:24:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:898:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:943:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sinatra-0.9.2/lib/sinatra/base.rb:898:in `call' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/mock_session.rb:30:in `request' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/test.rb:207:in `process_request' /home/abs1/.gem/ruby/1.8/gems/rack-test-0.5.0/lib/rack/test.rb:57:in `get' sinatra_test.rb:15:in `test_spec {The HelloWorld App} 001 [says hello]'</code> </pre> <p>1 tests, 0 assertions, 0 failures, 1 errors</p> <p>shell returned 1</p></div>

17123

true

2009-12-22T19:45:54-08:00

11306

2010-02-08T00:00:00-08:00

41832

313 misc-readme-fix-and-additions 42

9779

resolved Misc README fix and additions

2009-12-25T19:10:38-08:00

11306

Simon Rozet

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/313

1.0

Please review http://github.com/sr/sinatra/tree/readme I'll squash before pushing. Thanks

<div><p>Please review <a href= "http://github.com/sr/sinatra/tree/readme">http://github.com/sr/sinatra/tree/readme</a> I'll squash before pushing. Thanks</p></div>

11306

true

2009-12-11T14:40:42-08:00

17123

2010-02-08T00:00:00-08:00

41832

308 deprecate-use_in_file_templates-choose-better-name 1

9779

resolved Deprecate "use_in_file_templates!", choose better name

2009-12-22T19:43:28-08:00

11306

Simon Rozet

Ryan Tomayko

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/308

1.0

We've wanted to change this method name for a long time. Need to do it now if we're going to do it. Here's some ideas: * `import_templates` * `load_file_templates` * Umm. I can't think of anything, really. Note that this method doesn't even need to be called anymore for top-level apps - it happens automatically in `sinatra/main.rb`.

<div><p>We've wanted to change this method name for a long time. Need to do it now if we're going to do it. Here's some ideas:</p> <ul> <li><code>import_templates</code></li> <li><code>load_file_templates</code></li> <li>Umm. I can't think of anything, really.</li> </ul> <p>Note that this method doesn't even need to be called anymore for top-level apps - it happens automatically in <code>sinatra/main.rb</code>.</p></div>

17123

true

2009-09-04T01:46:01-07:00

68723

2010-02-08T00:00:00-08:00

41832

280 please-create-a-command-line-option-i-which-makes-sinatra-bind-to-a-specific-ip 22

9779

resolved options Please create a command line option (-i) which makes sinatra bind to a specific IP

2009-12-13T12:36:34-08:00

17123

Ryan Tomayko

lastcoolnameleft

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/280

1.0

A few days ago I completed my first sinatra app, it was fun and really easy. While installing it on our server, the admin told me to run it on 127.0.0.1 rather that 0.0.0.0. It turned out that there is no command line switch for it, so I had to edit the default IP in sinatra-0.9.4/lib/sinatra/base.rb al a workaround. Please add a command line option for that purpose. Peter

<div><p>A few days ago I completed my first sinatra app, it was fun and really easy.</p> <p>While installing it on our server, the admin told me to run it on 127.0.0.1 rather that 0.0.0.0. It turned out that there is no command line switch for it, so I had to edit the default IP in sinatra-0.9.4/lib/sinatra/base.rb al a workaround.</p> <p>Please add a command line option for that purpose.</p> <p>Peter</p></div>

17123

true

2009-12-11T14:47:51-08:00

17123

2010-02-08T00:00:00-08:00

41832

309 extensions-cant-add-routes 40

9779

resolved Extensions can't add routes

2009-12-13T11:43:12-08:00

17123

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/309

1.0

I vaguely remember a problem with extensions trying to add routes and things failing when people subclassed either `Sinatra::Default`, `Sinatra::Base`, or both. I can't remember the details but I'd like to know what's going on there and whether its been fixed before 1.0.

<div><p>I vaguely remember a problem with extensions trying to add routes and things failing when people subclassed either <code>Sinatra::Default</code>, <code>Sinatra::Base</code>, or both. I can't remember the details but I'd like to know what's going on there and whether its been fixed before 1.0.</p></div>

11306

true

2009-12-12T17:07:04-08:00

74434

2010-02-08T00:00:00-08:00

41832

305 html_escape-gets-set-to-true-when-you-add-a-haml-option-from-the-route-block 34

9779

worksforme haml haml_options :html_escape gets set to true when you add a haml option from the route block

2009-12-13T10:29:05-08:00

11306

Simon Rozet

picardo

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/305

1.0

Hey guys, I am seeing a weird issue. :haml_options is getting set to true whenever I specify an option from the route block. So with this route... get "/" do haml :home, :layout => :'layouts/application' end haml escapes all HTML...This is what you see in your browser: <h2>Hello world</h2> It doesn't matter in the init.rb I have this: set :haml, { :format => :html5, :escape_html=>false } If i remove the :layout => :'layouts/application', then it looks ok. If I add :escape_html=>false after :layout, then it looks ok as well. But I think this should not be reset everytime I use a haml option, right?

<div><p>Hey guys,</p> <p>I am seeing a weird issue. :haml_options is getting set to true whenever I specify an option from the route block.</p> <p>So with this route...</p> <p>get "/" do</p> <pre> <code>haml :home, :layout => :'layouts/application'</code> </pre> <p>end</p> <p>haml escapes all HTML...This is what you see in your browser:</p> <h2>Hello world</h2> <p>It doesn't matter in the init.rb I have this:</p> <p>set :haml, { :format => :html5, :escape_html=>false }</p> <p>If i remove the :layout => :'layouts/application', then it looks ok. If I add :escape_html=>false after :layout, then it looks ok as well. But I think this should not be reset everytime I use a haml option, right?</p></div>

15214

true

2008-04-30T11:15:18-07:00

7654

2012-12-31T00:00:00-08:00

27724

16 patch-http-authentication 26

9779

resolved auth http patch Offical HTTP Authentication Extensions

2009-12-12T16:30:14-08:00

17123

Ryan Tomayko

Bjørn Arild Mæland

Blake Mizerany

http://sinatra.lighthouseapp.com/projects/9779/tickets/16

Future

I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) Code: http://github.com/Chrononaut/sinatra/commits/master

<div><p> I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) </p><p> Code: <a href="http://github.com/Chrononaut/sinatra/commits/master">http://github.com/Chrononaut/sin...</a> </p></div>

17123

true

2009-01-30T04:02:02-08:00

278

2010-02-08T00:00:00-08:00

41832

142 gravatar-for-githubcomsinatra 5

9779

resolved gravatar for github.com/sinatra

2009-12-12T15:32:25-08:00

17123

Ryan Tomayko

ronin-278 (at lighthouseapp)

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/142

1.0

Can we register a gravatar with the hat for the email used for github.com/sinatra? kthxbai

<div><p>Can we register a gravatar with the hat for the email used for github.com/sinatra? kthxbai</p></div>

11306

true

2009-05-12T05:25:22-07:00

47921

2010-02-08T00:00:00-08:00

41832

224 github-djanowski-sent-you-a-message 1

9779

resolved Don't disable sessions in test environment

2009-12-12T15:31:55-08:00

17123

Ryan Tomayko

GitHub

Simon Rozet

http://sinatra.lighthouseapp.com/projects/9779/tickets/224

1.0

djanowski wants you to pull from djanowski/sinatra at enable_sessions_if_i_really_want_to Body: Please disregard the pull request from master. View repository: http://github.com/djanowski/sinatra/tree/enable_sessions_if_i_really_want_to

<div><p>djanowski wants you to pull from djanowski/sinatra at enable_sessions_if_i_really_want_to</p> <p>Body: Please disregard the pull request from master.</p> <p>View repository: <a href="http://github.com/djanowski/sinatra/tree/enable_sessions_if_i_really_want_to"> http://github.com/djanowski/sina...</a></p></div>

17123

true

2009-01-09T02:34:40-08:00

17123

2010-02-08T00:00:00-08:00

41832

62 cachedcompiled-templates 6

9779

resolved performance templates Cached/Compiled Templates

2009-12-12T15:29:36-08:00

17123

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/62

1.0

Pratik (lifo) was working on support for compiled templates at one point and was far enough along to show a significant perf win. IIRC, the big issues he ran into were 1.) dealing with locals, and 2.) recompiling when a template changes on disk.

<div><p>Pratik (lifo) was working on support for compiled templates at one point and was far enough along to show a significant perf win. IIRC, the big issues he ran into were 1.) dealing with locals, and 2.) recompiling when a template changes on disk.</p></div>

17123

true

2009-07-01T16:55:03-07:00

6253

2010-02-08T00:00:00-08:00

41832

256 some-percent-encoded-uri-route-matches-fail 12

9779

wontfix some percent-encoded uri route matches fail

2009-12-12T15:19:53-08:00

17123

Ryan Tomayko

Darrin Eden

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/256

1.0

it seems that certain routes containing percent-encoded uri fail to match. here's a failing test: uri_encode_test.rb http://gist.github.com/139160 thanks!

<div><p>it seems that certain routes containing percent-encoded uri fail to match.</p> <p>here's a failing test:</p> <pre> <code>uri_encode_test.rb <a href="http://gist.github.com/139160">http://gist.github.com/139160</a> </code> </pre> <p>thanks!</p></div>

17123

true

2009-11-11T14:58:37-08:00

36235

2010-02-08T00:00:00-08:00

41832

302 session-testing-documentation-helpers-if-needed 37

9779

resolved documentation sessions Session testing documentation / helpers if needed

2009-12-12T10:42:20-08:00

36235

TJ Holowaychuk

Ryan Tomayko

http://sinatra.lighthouseapp.com/projects/9779/tickets/302

1.0

I found a few other issues on here talking about session testing but nothing seems to be working. @@@ ruby it "should allow testing of sessions" do mock_app do get '/foo' do session[:foo] = 'bar' 'test' end get '/bar' do session[:foo] end end get '/foo' get '/bar' last_response.body.should == 'bar' end @@@ my #mock_app helper: @@@ ruby def mock_app options = {}, &block subclass = Class.new Sinatra::Application subclass.enable :sessions subclass.set :environment, :not_test subclass.instance_eval &block @app = subclass.new end @@@ any advice would be great, id gladly write up some docs for the site for others to use

<div><p>I found a few other issues on here talking about session testing but nothing seems to be working.</p> <pre> <code class="ruby"> it "should allow testing of sessions" do mock_app do get '/foo' do session[:foo] = 'bar' 'test' end get '/bar' do session[:foo] end end get '/foo' get '/bar' last_response.body.should == 'bar' end</code> </pre> <p>my #mock_app helper:</p> <pre> <code class="ruby"> def mock_app options = {}, &block subclass = Class.new Sinatra::Application subclass.enable :sessions subclass.set :environment, :not_test subclass.instance_eval &block @app = subclass.new end</code> </pre> <p>any advice would be great, id gladly write up some docs for the site for others to use</p></div>