Call for 1.1.0 release

Call for 1.1.0 release

[Joshua Peek]

I'd to cut a 1.1 release before the new year. I'm going to put in the
work for the release notes and actual gem push. Now that we are on
Gemcutter, the entire rack core team has push access.

Heres an overview of the major changes:

* Relaxes SPEC to allow subclasses.
  - This is the major change I want to get out there. Right now Rails
2.x needs to monkey patch Lint to work around this.
* Refactored rackup into Rack::Server
* Removed Auth::OpenID
* Nested parameter and multipart generation improvements to Mock
* Pull in some useful contrib middleware: Config, ETag, Runtime,
Sendfile
* rack.logger extension specification
* Various bug fixes and optimizations

Please test rack/master and make sure your libraries are ready.

I'd like to get a +1 from all the rack core members before anything is
released.

Re: Call for 1.1.0 release

[Christian Neukirchen]

On Tue, Dec 22, 2009 at 4:11 AM, Joshua Peek <josh@joshpeek.com> wrote:
> I'd to cut a 1.1 release before the new year. I'm going to put in the
> work for the release notes and actual gem push. Now that we are on
> Gemcutter, the entire rack core team has push access.
>
> Heres an overview of the major changes:
>
> * Relaxes SPEC to allow subclasses.
>  - This is the major change I want to get out there. Right now Rails
> 2.x needs to monkey patch Lint to work around this.
> * Refactored rackup into Rack::Server
> * Removed Auth::OpenID
> * Nested parameter and multipart generation improvements to Mock
> * Pull in some useful contrib middleware: Config, ETag, Runtime,
> Sendfile
> * rack.logger extension specification
> * Various bug fixes and optimizations
>
> Please test rack/master and make sure your libraries are ready.
>
> I'd like to get a +1 from all the rack core members before anything is
> released.

+1, but please let me have a look over it before you release.
I can update the site and rubyforge then.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Call for 1.1.0 release

[Ryan Tomayko]

On Mon, Dec 21, 2009 at 7:11 PM, Joshua Peek <josh@joshpeek.com> wrote:
> I'd to cut a 1.1 release before the new year. I'm going to put in the
> work for the release notes and actual gem push. Now that we are on
> Gemcutter, the entire rack core team has push access.
>
> Heres an overview of the major changes:
>
> * Relaxes SPEC to allow subclasses.
>  - This is the major change I want to get out there. Right now Rails
> 2.x needs to monkey patch Lint to work around this.
> * Refactored rackup into Rack::Server
> * Removed Auth::OpenID
> * Nested parameter and multipart generation improvements to Mock
> * Pull in some useful contrib middleware: Config, ETag, Runtime,
> Sendfile
> * rack.logger extension specification
> * Various bug fixes and optimizations
>
> Please test rack/master and make sure your libraries are ready.
>
> I'd like to get a +1 from all the rack core members before anything is
> released.

Tentative +1. I'm looking at a diff of 202afb4...master -- is that right?

Rack, Sinatra, and Rack::Cache test suites all pass under MRI
1.8.6/1.8.7 and REE 1.8.7. I can't get test-spec to run under 1.9 for
some reason so I haven't been able to test there.

Also, I have a few minor bugs I'd like to get in if possible. They
should be straightforward. I'll try to get patches to the list today.

Thanks,
Ryan
--
# tomayko.com/about

Re: Call for 1.1.0 release

[Eric Wong]

Joshua Peek <josh@joshpeek.com> wrote:
> I'd to cut a 1.1 release before the new year. I'm going to put in the

Hi, I've started adding specs for (optional) "rack.io" and Mongrel
support as well.  It's pretty lightweight in that it just requires
an IO.select-able IO object or StringIO (for testing)..

Perhaps it can go into 1.1 with some review/comments.

It's useful for at least two purposes.

* It can be used to implement Web Sockets or other alternative
  sub-protocols with the HTTP connection.

* It can be used to detect client disconnects to avoid needlessly
  performing expensive operations:

  mid: <8b5b448c-d311-4472-81c3-38fd8814cd66@r5g2000prh.googlegroups.com>
  http://groups.google.com/group/rack-devel/browse_thread/thread/5e5b52892f5e9353


I'm also thinking of a way to integrate it with EM-based servers like
Thin so it can be used with existing Thin deployments.


The code is in the "rack.io" branch of my git repo:
  * git://git.bogomips.org/rack
  * http://git.bogomips.org/cgit/rack.git/log/?h=rack.io

Shortlog:

Eric Wong (2):
      Rack::Lint understands "rack.io" env
      add "rack.io" to Mongrel request

-- 
Eric Wong

Re: Call for 1.1.0 release

[Joshua Peek]

Hey Eric,

Raw io access has been on my wish list for a while. I'm totally +1 but
do you think we can hold off? I'd like to put together the release
sometime next week before the new year.

Though there was a long year gap between 1.0 and 1.1, it doesn't mean
1.2 needs to be that far off. I'd like to speed up the release
schedule for these new ideas.

On Thu, Dec 24, 2009 at 4:49 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Joshua Peek <josh@joshpeek.com> wrote:
>> I'd to cut a 1.1 release before the new year. I'm going to put in the
>
> Hi, I've started adding specs for (optional) "rack.io" and Mongrel
> support as well.  It's pretty lightweight in that it just requires
> an IO.select-able IO object or StringIO (for testing)..
>
> Perhaps it can go into 1.1 with some review/comments.
>
> It's useful for at least two purposes.
>
> * It can be used to implement Web Sockets or other alternative
>  sub-protocols with the HTTP connection.
>
> * It can be used to detect client disconnects to avoid needlessly
>  performing expensive operations:
>
>  mid: <8b5b448c-d311-4472-81c3-38fd8814cd66@r5g2000prh.googlegroups.com>
>  http://groups.google.com/group/rack-devel/browse_thread/thread/5e5b52892f5e9353
>
>
> I'm also thinking of a way to integrate it with EM-based servers like
> Thin so it can be used with existing Thin deployments.
>
>
> The code is in the "rack.io" branch of my git repo:
>  * git://git.bogomips.org/rack
>  * http://git.bogomips.org/cgit/rack.git/log/?h=rack.io
>
> Shortlog:
>
> Eric Wong (2):
>      Rack::Lint understands "rack.io" env
>      add "rack.io" to Mongrel request
>
> --
> Eric Wong
>



-- 
Joshua Peek

Re: Call for 1.1.0 release

[Scytrin dai Kinthra]

 +1 for a New Years release.

On Thu, Dec 24, 2009 at 15:40, Joshua Peek <josh@joshpeek.com> wrote:
> Hey Eric,
>
> Raw io access has been on my wish list for a while. I'm totally +1 but
> do you think we can hold off? I'd like to put together the release
> sometime next week before the new year.
>
> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
> 1.2 needs to be that far off. I'd like to speed up the release
> schedule for these new ideas.
>
> On Thu, Dec 24, 2009 at 4:49 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> Joshua Peek <josh@joshpeek.com> wrote:
>>> I'd to cut a 1.1 release before the new year. I'm going to put in the
>>
>> Hi, I've started adding specs for (optional) "rack.io" and Mongrel
>> support as well.  It's pretty lightweight in that it just requires
>> an IO.select-able IO object or StringIO (for testing)..
>>
>> Perhaps it can go into 1.1 with some review/comments.
>>
>> It's useful for at least two purposes.
>>
>> * It can be used to implement Web Sockets or other alternative
>>  sub-protocols with the HTTP connection.
>>
>> * It can be used to detect client disconnects to avoid needlessly
>>  performing expensive operations:
>>
>>  mid: <8b5b448c-d311-4472-81c3-38fd8814cd66@r5g2000prh.googlegroups.com>
>>  http://groups.google.com/group/rack-devel/browse_thread/thread/5e5b52892f5e9353
>>
>>
>> I'm also thinking of a way to integrate it with EM-based servers like
>> Thin so it can be used with existing Thin deployments.
>>
>>
>> The code is in the "rack.io" branch of my git repo:
>>  * git://git.bogomips.org/rack
>>  * http://git.bogomips.org/cgit/rack.git/log/?h=rack.io
>>
>> Shortlog:
>>
>> Eric Wong (2):
>>      Rack::Lint understands "rack.io" env
>>      add "rack.io" to Mongrel request
>>
>> --
>> Eric Wong
>>
>
>
>
> --
> Joshua Peek
>



-- 
stadik.net

Re: Call for 1.1.0 release

[Eric Wong]

Joshua Peek <josh@joshpeek.com> wrote:
> Hey Eric,
> 
> Raw io access has been on my wish list for a while. I'm totally +1 but
> do you think we can hold off? I'd like to put together the release
> sometime next week before the new year.

Sure thing on holding off.

I'm very glad to know there's interest for this idea.  I'll try
to cook up some examples of ways to use it with async servers, too...

> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
> 1.2 needs to be that far off. I'd like to speed up the release
> schedule for these new ideas.

Yeah, the gap between releases got me a bit worried.

-- 
Eric Wong

Re: Call for 1.1.0 release

[James Tucker]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]


On 24 Dec 2009, at 23:40, Joshua Peek wrote:

> Hey Eric,
> 
> Raw io access has been on my wish list for a while. I'm totally +1 but
> do you think we can hold off? I'd like to put together the release
> sometime next week before the new year.
> 
> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
> 1.2 needs to be that far off. I'd like to speed up the release
> schedule for these new ideas.

+1 we need to hold off, there's more to discuss in this area.

> 
> On Thu, Dec 24, 2009 at 4:49 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> Joshua Peek <josh@joshpeek.com> wrote:
>>> I'd to cut a 1.1 release before the new year. I'm going to put in the
>> 
>> Hi, I've started adding specs for (optional) "rack.io" and Mongrel
>> support as well.  It's pretty lightweight in that it just requires
>> an IO.select-able IO object or StringIO (for testing)..
>> 
>> Perhaps it can go into 1.1 with some review/comments.
>> 
>> It's useful for at least two purposes.
>> 
>> * It can be used to implement Web Sockets or other alternative
>>  sub-protocols with the HTTP connection.
>> 
>> * It can be used to detect client disconnects to avoid needlessly
>>  performing expensive operations:
>> 
>>  mid: <8b5b448c-d311-4472-81c3-38fd8814cd66@r5g2000prh.googlegroups.com>
>>  http://groups.google.com/group/rack-devel/browse_thread/thread/5e5b52892f5e9353
>> 
>> 
>> I'm also thinking of a way to integrate it with EM-based servers like
>> Thin so it can be used with existing Thin deployments.
>> 
>> 
>> The code is in the "rack.io" branch of my git repo:
>>  * git://git.bogomips.org/rack
>>  * http://git.bogomips.org/cgit/rack.git/log/?h=rack.io
>> 
>> Shortlog:
>> 
>> Eric Wong (2):
>>      Rack::Lint understands "rack.io" env
>>      add "rack.io" to Mongrel request
>> 
>> --
>> Eric Wong
>> 
> 
> 
> 
> -- 
> Joshua Peek


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]

Re: Call for 1.1.0 release

[James Tucker]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]


On 25 Dec 2009, at 00:24, Eric Wong wrote:

> Joshua Peek <josh@joshpeek.com> wrote:
>> Hey Eric,
>> 
>> Raw io access has been on my wish list for a while. I'm totally +1 but
>> do you think we can hold off? I'd like to put together the release
>> sometime next week before the new year.
> 
> Sure thing on holding off.
> 
> I'm very glad to know there's interest for this idea.  I'll try
> to cook up some examples of ways to use it with async servers, too...

Eric - I had a report from one of the async_sinatra users who tried out rainbows with EM, and found that the API didn't actually line up with what Thin was doing. I really want to devote some more time with this but I've been very busy. Sadly due to this I don't want to say stop, but, well, I want to say please check existing apps against it. I guess could you check async_*.ru from github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from what was reported, they're not working with the rainbows implementation of the deferrablebody hacks.

> 
>> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
>> 1.2 needs to be that far off. I'd like to speed up the release
>> schedule for these new ideas.
> 
> Yeah, the gap between releases got me a bit worried.
> 
> -- 
> Eric Wong


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]

deferrable bodies in Rainbows!

[Eric Wong]

Moving to rainbows list

James Tucker <jftucker@gmail.com> wrote:
> Eric - I had a report from one of the async_sinatra users who tried
> out rainbows with EM, and found that the API didn't actually line up
> with what Thin was doing. I really want to devote some more time with
> this but I've been very busy. Sadly due to this I don't want to say
> stop, but, well, I want to say please check existing apps against it.
> I guess could you check async_*.ru from
> github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
> what was reported, they're not working with the rainbows
> implementation of the deferrablebody hacks.

Hi James, thhanks for the heads up.

Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
the first time around), so it can't do everything Thin does with EM, yet.
It's already in the TODO, I'll make a mental note to work on it sooner.

-- 
Eric Wong

Re: deferrable bodies in Rainbows!

[Eric Wong]

Eric Wong <normalperson@yhbt.net> wrote:
> Moving to rainbows list
> 
> James Tucker <jftucker@gmail.com> wrote:
> > Eric - I had a report from one of the async_sinatra users who tried
> > out rainbows with EM, and found that the API didn't actually line up
> > with what Thin was doing. I really want to devote some more time with
> > this but I've been very busy. Sadly due to this I don't want to say
> > stop, but, well, I want to say please check existing apps against it.
> > I guess could you check async_*.ru from
> > github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
> > what was reported, they're not working with the rainbows
> > implementation of the deferrablebody hacks.
> 
> Hi James, thhanks for the heads up.
> 
> Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
> the first time around), so it can't do everything Thin does with EM, yet.
> It's already in the TODO, I'll make a mental note to work on it sooner.

Rainbows! 0.90.1 should support deferrable bodies needed for async apps
on EM.

I stole the async_app.ru and async_tailer.ru examples from Thin and made
them a part of the integration tests (in t/t04??-*.sh).


The app.deferred?(env) isn't supported, yet.  It's in the TODO and I
don't think many people use it... (correct me if I'm wrong).

-- 
Eric Wong

Re: Call for 1.1.0 release

[Eric Wong]

Ryan Tomayko <r@tomayko.com> wrote:
> Rack, Sinatra, and Rack::Cache test suites all pass under MRI
> 1.8.6/1.8.7 and REE 1.8.7. I can't get test-spec to run under 1.9 for
> some reason so I haven't been able to test there.

I sent the patches ad the end of this message to Christian which should
get test-spec mostly working under 1.9 (though I can't get test-spec to
pass its own tests).

Under all versions of Ruby I tested, the basic test suite fails
spec_rack_logger.rb:

  <"Program started\nNothing to do!\n"> expected to be =~
  </INFO\ \-\-\ :\ Program\ started/>.

  It looks like the Logger formatter gets clobbered somewhere,
  running that test standalone seems to work fine, though.

Running Ruby 1.9.2dev trunk r26127, everything else passes except the
following because of a Marshal format change:

  test_spec {Rack::Session::Cookie} 005 [creates a new cookie with integrity hash](Rack::Session::Cookie) [/home/ew/rack/test/spec_rack_session_cookie.rb:55]:
  <"rack.session=BAh7BkkiDGNvdW50ZXIGOgZFRmkG%0A--2548b2a97e67656c3457b9a5cb43b65a83715cbc; path=/"> expected to be =~
  </rack\.session=BAh7BkkiDGNvdW50ZXIGOg1lbmNvZGluZyINVVMtQVNDSUlpBg%3D%3D%0A\-\-d7a6637b94d2728194a96c18484e1f7ed9074a83/>.


test-spec patches below:
--------------------------------- 8< ---------------------------------

Wed Dec 30 23:22:17 UTC 2009  normalperson@yhbt.net
  * add "spec" pattern for automatic tests
  
  test-unit 2.0.5 (required for Ruby 1.9) doesn't automatically
  glob patterns beginning with "spec".
Wed Dec 30 22:24:51 UTC 2009  normalperson@yhbt.net
  * Rakefile: String#each -> String#each_line for 1.9
  
  String#each no longer exists in Ruby 1.9
diff -rN -u old-testspec/bin/specrb new-testspec/bin/specrb
--- old-testspec/bin/specrb	2009-12-31 01:00:08.000000000 +0000
+++ new-testspec/bin/specrb	2009-12-31 01:00:08.000000000 +0000
@@ -104,4 +104,10 @@
 runner = Test::Unit::AutoRunner.new true
 runner.process_args(argv) ||
   abort("internal error calling Test::Unit, please report a bug")
+
+# needed for test-unit 2.0.5 under Ruby 1.9
+if automatic && RUBY_VERSION.to_f >= 1.9
+  runner.pattern << %r{\Aspec[_\-].+\.rb\z}m
+end
+
 exit runner.run
diff -rN -u old-testspec/Rakefile new-testspec/Rakefile
--- old-testspec/Rakefile	2009-12-31 01:00:08.000000000 +0000
+++ new-testspec/Rakefile	2009-12-31 01:00:08.000000000 +0000
@@ -27,7 +27,7 @@
   count = 0
   tag = "0.0"
   
-  changes.each("\n\n") { |change|
+  changes.each_line("\n\n") { |change|
     head, title, desc = change.split("\n", 3)
     
     if title =~ /^  \*/

-- 
Eric Wong