From noreply at rubyforge.org Sun Jul 1 20:49:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 20:49:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702004929.73AF05240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 20:56:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 20:56:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702005617.20671A970002@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-02 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 00:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:21:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:21:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] " should_yield" or " .should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702012140.1DB565240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:25:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:25:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] " should_yield" or " .should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702012530.7695F5240B92@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-02 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 01:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-02 01:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 00:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:27:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:27:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & quot; should_yield& quot; or & quot; .should raise_error(MySpecificError)& quot; equivalent for yields Message-ID: <20070702012719.3AE205240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: &quot;should_yield&quot; or &quot;.should raise_error(MySpecificError)&quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Mon Jul 2 05:03:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 05:03:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11891 ] script/generate rspec_controller fails to create appropriate views (from templates) on edge rails Message-ID: <20070702090323.429ED5240A90@rubyforge.org> Bugs item #11891, was opened at 2007-06-27 19:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11891&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: George Anderson (caton) Assigned to: David Chelimsky (dchelimsky) Summary: script/generate rspec_controller fails to create appropriate views (from templates) on edge rails Initial Comment: Mac OSX 10.4.9 edge rails: r7126 rspec (plugin): r2082 rspec_on_rails: r2081 Views couldn't be generated by script/generate rspec_controller ... $ script/generate rspec_controller patient_base index face_sheet patient_messages rx chart_timeline archive chart_note flow_sheet hist ory hospital lab_results radiology x_ray exists app/controllers/ exists app/helpers/ create app/views/patient_base exists spec/controllers/ exists spec/helpers/ create spec/views/patient_base create spec/controllers/patient_base_controller_spec.rb create spec/helpers/patient_base_helper_spec.rb create app/controllers/patient_base_controller.rb create app/helpers/patient_base_helper.rb create spec/views/patient_base/index_view_spec.rb create app/views/patient_base/index.rhtml No such file or directory - /Users/george/work/one_box/vendor/rails/railties/lib/rails_generator/generators/components/controller/templates/view.rhtml railties/lib/rails_generator/generators/components/controller/templates/view.html changed to view.html.erb as of r6690 (roughly 2 months ago). See: http://dev.rubyonrails.org/browser/trunk/railties/lib/rails_generator/generators/components/controller/templates Rails 1.2 STABLE should use view.rhtml (See: http://dev.rubyonrails.org/browser/branches/1-2-stable/railties/lib/rails_generator/generators/components/controller/templates) So perhaps this ticket is premature. Consider, however, the *.html.erb style will eventually be in the STABLE release. At that time, RSpec may have to deal with the *old* and *new* style templates. For those of you reading this far, and not feeling you have suffient RSpec-fu to create a patch for this (myself included among you), consider this workaround: $ script/generate rspec_controller patient_base index this will throw the error herein described, but just lop off the "rspec_" bit and run: $ script/generate controller patient_base index Most of the files will be identical, but the *.html.erb-style templates will generate as expected. For bonus points, clean up the test::unit cruft thusly: $ rm test/functional/patient_base_controller_test.rb Thx. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 09:03 Message: Fixed in r2152. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-06-28 16:48 Message: No need to justify this - it's missing functionality that we'll add. The rspec_resource generator already does the right thing based on the rails environment and we can get the rspec_controller generator to do the same. ---------------------------------------------------------------------- Comment By: George Anderson (caton) Date: 2007-06-28 16:45 Message: .rhtml won't be fully deprecated until Rails 3.0 See: http://dev.rubyonrails.org/changeset/6178 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11891&group_id=797 From noreply at rubyforge.org Mon Jul 2 05:52:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 05:52:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11628 ] error mocking partial page variable only after partial has already been rendered Message-ID: <20070702095217.9DBE95240A90@rubyforge.org> Bugs item #11628, was opened at 2007-06-17 10:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11628&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: error mocking partial page variable only after partial has already been rendered Initial Comment: Steps to reproduce: Apply the attached patch (which adds an example file w/ 2 examples) cd example_rails_app rake rspec:install_plugin script/spec spec/views/person/_person.rhtml_spec.rb You should see an error. If, however, you apply --reverse, you should not: script/spec spec/views/person/_person.rhtml_spec.rb --reverse ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 09:52 Message: The solution to this is to NOT do this. Instead, we've added template.expects_render for view examples and controller.expects_render for controller examples. Docs have been appropriately updated as of r2153. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11628&group_id=797 From noreply at rubyforge.org Mon Jul 2 16:06:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 16:06:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070702200647.2583FA970002@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Tue Jul 3 03:13:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Jul 2007 03:13:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070703071329.209D0A970002@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 03:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:32:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:32:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705083230.ADC6D52409AA@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:47:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:47:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705084728.032545240A2E@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:48:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:48:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705084824.0DCD75240A44@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 05:59:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 05:59:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705095946.C23025240945@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 09:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 06:02:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 06:02:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705100255.5B2005240951@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 10:02 Message: Will attach alternative patch as commented previously. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 09:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Fri Jul 6 14:09:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Jul 2007 14:09:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070706180916.ADBD65240A95@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Nobody (None) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Fri Jul 6 14:09:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Jul 2007 14:09:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070706180934.30D335240B60@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Nobody (None) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Sat Jul 7 00:21:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 00:21:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12066 ] Docfix for mocks/mocks.page Message-ID: <20070707042152.A62565240D53@rubyforge.org> Patches item #12066, was opened at 2007-07-07 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kyle Hargraves (philodespotos) Assigned to: Nobody (None) Summary: Docfix for mocks/mocks.page Initial Comment: The mocks page was still using the magic underscore syntax in one little place. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 From noreply at rubyforge.org Sat Jul 7 00:25:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 00:25:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12066 ] Docfix for mocks/mocks.page Message-ID: <20070707042513.E6A845240D54@rubyforge.org> Patches item #12066, was opened at 2007-07-07 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Kyle Hargraves (philodespotos) >Assigned to: David Chelimsky (dchelimsky) Summary: Docfix for mocks/mocks.page Initial Comment: The mocks page was still using the magic underscore syntax in one little place. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-07 04:25 Message: Applied to r2154. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 From noreply at rubyforge.org Sat Jul 7 14:46:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 14:46:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070707184653.DD77CA970016@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sat Jul 7 14:51:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 14:51:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070707185106.B1A64A970012@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sat Jul 7 17:26:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 17:26:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12079 ] auto-generated example name incomplete: should have 1 error on .... Message-ID: <20070707212641.DFC625240BC2@rubyforge.org> Bugs item #12079, was opened at 2007-07-07 21:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: auto-generated example name incomplete: should have 1 error on .... Initial Comment: Per the "RSpec Basics" peepcode: If you do this in a model: describe SomeModel ... specify do model.should have(1).error_on(:some_attribute) end end The feedback you get says: SomeModel - should have 1 error on But it doesn't tell you on what. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 From noreply at rubyforge.org Sat Jul 7 17:34:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 17:34:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12079 ] auto-generated example name incomplete: should have 1 error on .... Message-ID: <20070707213436.029265240AB4@rubyforge.org> Bugs item #12079, was opened at 2007-07-07 21:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: auto-generated example name incomplete: should have 1 error on .... Initial Comment: Per the "RSpec Basics" peepcode: If you do this in a model: describe SomeModel ... specify do model.should have(1).error_on(:some_attribute) end end The feedback you get says: SomeModel - should have 1 error on But it doesn't tell you on what. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-07 21:34 Message: Fixed in r2159. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:14:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:14:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708101413.CB2EB5240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:27:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:27:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708102752.E21D65240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:48:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:48:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708104813.77ACF5240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:48 Message: Posted a follow-up TextMate ticket here: http://macromates.com/ticket/show?ticket_id=0F597093 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Mon Jul 9 02:46:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 02:46:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12121 ] uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Message-ID: <20070709064610.835995240D67@rubyforge.org> Bugs item #12121, was opened at 2007-07-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Initial Comment: rspec_on_rails/lib/spec/rails/extensions/action_controller/rescue.rb:6 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 From noreply at rubyforge.org Mon Jul 9 04:11:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 04:11:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12121 ] uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Message-ID: <20070709081111.742ABA970002@rubyforge.org> Bugs item #12121, was opened at 2007-07-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Initial Comment: rspec_on_rails/lib/spec/rails/extensions/action_controller/rescue.rb:6 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-09 01:11 Message: Fixed in Head ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:10:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:10:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709221044.939EF5240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:18:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:18:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & quot; should_yield& quot; or & quot; .should raise_error(MySpecificError)& quot; equivalent for yields Message-ID: <20070709221818.BC8145240B0A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: &quot;should_yield&quot; or &quot;.should raise_error(MySpecificError)&quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 18:18 Message: In your example (both here and in your blog entry) - what does &spec_block(1) refer to? Is this some sort of block that would be implicitly available when yield_with (or similar) is used? Could you use something more straightforward like this? class Funky def self.bacon(&proc) yield '_how' if proc.arity == 1 end end describe Funky do it "should yield when arity is 1" do lambda do Funky.bacon do |s| s.should == '_how' throw :done end end.should throw_symbol(:done) # proves the bacon yielded end it "should not yield when arity is 2" do lambda do Funky.bacon do throw :done end end.should_not throw_symbol(:done) end end ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 21:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 21:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 21:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:26:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:26:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709222617.3609A5240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 22:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 22:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:29:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:29:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709222908.8AAC75240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 18:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 18:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 18:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:59:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:59:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & amp; quot; should_yield& amp; quot; or & amp; quot; .should raise_error(MySpecificError)& amp; quot; equivalent for yields Message-ID: <20070709225914.329905240B5F@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: &amp;quot;should_yield&amp;quot; or &amp;quot;.should raise_error(MySpecificError)&amp;quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-09 17:59 Message: Aslak, that is very similar (with less validation) to what I already do (as explained in the blog entry above), but doesn't add too much value if we are following a DSL approach in my opinion. My thoughts on what spec_block would do is generate a block with whatever arity is given for it. For example, if I call spec_block(3) that block will produce a block that has 3 arguments that cannot be ignored. I am open to suggestions on the naming of this helper method, but I would prefer that the specs I write for my application don't require so much setup to specify such a simple thing. Those are just my thoughts and will leave this open until there is a bit more clarity to what the RSpec developer consensus is. I will work on a patch based on the vision after that point. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 17:18 Message: In your example (both here and in your blog entry) - what does &spec_block(1) refer to? Is this some sort of block that would be implicitly available when yield_with (or similar) is used? Could you use something more straightforward like this? class Funky def self.bacon(&proc) yield '_how' if proc.arity == 1 end end describe Funky do it "should yield when arity is 1" do lambda do Funky.bacon do |s| s.should == '_how' throw :done end end.should throw_symbol(:done) # proves the bacon yielded end it "should not yield when arity is 2" do lambda do Funky.bacon do throw :done end end.should_not throw_symbol(:done) end end ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:15:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:15:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710121505.48C205240A31@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Akhil Bansal (bansalakhil) Assigned to: Nobody (None) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:19:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:19:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710121937.A38405240A41@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Akhil Bansal (bansalakhil) >Assigned to: David Chelimsky (dchelimsky) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-10 12:19 Message: RSpec wants the file to be called user_spec.rb. If you don't want to call it that, you can do this: describe User, :behaviour_type => :model do ... end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:25:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:25:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710122540.142D15240A41@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 08:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Akhil Bansal (bansalakhil) Assigned to: David Chelimsky (dchelimsky) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 08:25 Message: You may also have been bitten by this bug: http://rubyforge.org/tracker/index.php?func=detail&aid=10534&group_id=797&atid=3149 The bug exists in RSpec 1.0.5 and should be gone with the next release. It's fixed on trunk, so you may want to try with that to see if your problem goes away. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-10 08:19 Message: RSpec wants the file to be called user_spec.rb. If you don't want to call it that, you can do this: describe User, :behaviour_type => :model do ... end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:29:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:29:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070710122942.5EB505240A42@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: John Andrews (jandrews) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:54 Message: Method visibility is as follows: Object method > Kernel method > method_missing (RSpec describe) ORA driver (DelegateClass) What we need to do here is to make sure the OCI8AutoRecover object intercepts the method before it falls back to Kernel. That's easily done by monkey patching it: class OCI8AutoRecover def describe(name) @connection.describe(name) end end All this does is to define the describe method directly and delegate explicitly. It should work just like before, but I don't have an ORA here to verify it. If someone can confirm that this works I'll roll this into Spec::Rails and enable it automagically so you don't have anything special to do. Aaait? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:06 Message: I'm looking into a fix for this... ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-28 12:12 Message: We have a patch for this: Save the following to your /lib directory in a file called e.g. oracle_adapter.rb --------------- # Rspec's dsl uses #describe as a method name at the core of its functionality # The oracle_adapter also uses #describe and the two clash. # Because rspec mixes-in the #describe method via the Kernel module all # Object instances (i.e. all objects) have a #describe method. # The oracle adpater uses a delegation model for some functionality via the # #method_missing mechanism. The #describe method is one of the methods which # _was_ missing when rspec was not around. However the mixin via Kernel changes # that thus _things_ do not function as intended (on the oracle side). # This patch hacks in the #describe method to where it was missing and then # delegates to the implementation. # #see # http://rubyforge.org/tracker/index.php?func=detail&aid=10577&group_id=797&atid=3149 module OracleAdapterPatch # rspec method name collision patch def describe(obj) # puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) ---------------------------- Edit as required. In your environment.rb for example add the following require 'oracle_adapter' which can be made conditional (or could this be a rspec rake task?) Cheers! sinclair rspec now functions ---------------------------------------------------------------------- Comment By: Venkatasubramaniyan K (venkat) Date: 2007-06-28 11:57 Message: Dear rspec team: I am also running into the same problem. I figured out the issue after a long debug session. I don't have any good solution for it. But I would appreciate a solution for this soon (even if it is a temp patch to begin with), so that we don't waste time debugging this. Yes, there could be other software affected by this but the specific Oracle issue at least needs to be resolved. Thanks, Venkat. ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-01 14:25 Message: Hi, I just ran into this problem in rspec_for_rails 1.0.0. The solution I think we will settle for in the short term is a monkey patch to the OCI8AutoRecover class. The patch implements the #describe method in the OCI8AutoRecover class (via a module include). The patch file is in our rails_app/lib directory and is #required in the environment.rb. This is the implementation: module OracleAdapterPatch # rspec method name collision patch def describe(obj) puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) As is stated below this is (still) a band-aid approach. Cheers! sinclair ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-05 19:56 Message: I'm uncomfortable with this solution. It's a band-aid for this particular example, but someone else might come along and do something similar - using method_missing to delegate to another object WITH a block expected in that object's #describe method. Does anyone have any other suggestions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From noreply at rubyforge.org Tue Jul 10 09:36:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 09:36:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710133617.DB2945240A20@rubyforge.org> Patches item #12156, was opened at 2007-07-10 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ienaga Eiji (ienaga) Assigned to: Nobody (None) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 09:46:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 09:46:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710134616.282565240A41@rubyforge.org> Patches item #12156, was opened at 2007-07-10 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Ienaga Eiji (ienaga) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:11:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:11:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070710151113.5CA225240A9F@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: John Andrews (jandrews) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:11 Message: Fixed in r2162. In my previous comment I completely overlooked that my suggestion was in essence what Sinclair had suggested below :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:54 Message: Method visibility is as follows: Object method > Kernel method > method_missing (RSpec describe) ORA driver (DelegateClass) What we need to do here is to make sure the OCI8AutoRecover object intercepts the method before it falls back to Kernel. That's easily done by monkey patching it: class OCI8AutoRecover def describe(name) @connection.describe(name) end end All this does is to define the describe method directly and delegate explicitly. It should work just like before, but I don't have an ORA here to verify it. If someone can confirm that this works I'll roll this into Spec::Rails and enable it automagically so you don't have anything special to do. Aaait? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:06 Message: I'm looking into a fix for this... ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-28 12:12 Message: We have a patch for this: Save the following to your /lib directory in a file called e.g. oracle_adapter.rb --------------- # Rspec's dsl uses #describe as a method name at the core of its functionality # The oracle_adapter also uses #describe and the two clash. # Because rspec mixes-in the #describe method via the Kernel module all # Object instances (i.e. all objects) have a #describe method. # The oracle adpater uses a delegation model for some functionality via the # #method_missing mechanism. The #describe method is one of the methods which # _was_ missing when rspec was not around. However the mixin via Kernel changes # that thus _things_ do not function as intended (on the oracle side). # This patch hacks in the #describe method to where it was missing and then # delegates to the implementation. # #see # http://rubyforge.org/tracker/index.php?func=detail&aid=10577&group_id=797&atid=3149 module OracleAdapterPatch # rspec method name collision patch def describe(obj) # puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) ---------------------------- Edit as required. In your environment.rb for example add the following require 'oracle_adapter' which can be made conditional (or could this be a rspec rake task?) Cheers! sinclair rspec now functions ---------------------------------------------------------------------- Comment By: Venkatasubramaniyan K (venkat) Date: 2007-06-28 11:57 Message: Dear rspec team: I am also running into the same problem. I figured out the issue after a long debug session. I don't have any good solution for it. But I would appreciate a solution for this soon (even if it is a temp patch to begin with), so that we don't waste time debugging this. Yes, there could be other software affected by this but the specific Oracle issue at least needs to be resolved. Thanks, Venkat. ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-01 14:25 Message: Hi, I just ran into this problem in rspec_for_rails 1.0.0. The solution I think we will settle for in the short term is a monkey patch to the OCI8AutoRecover class. The patch implements the #describe method in the OCI8AutoRecover class (via a module include). The patch file is in our rails_app/lib directory and is #required in the environment.rb. This is the implementation: module OracleAdapterPatch # rspec method name collision patch def describe(obj) puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) As is stated below this is (still) a band-aid approach. Cheers! sinclair ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-05 19:56 Message: I'm uncomfortable with this solution. It's a band-aid for this particular example, but someone else might come along and do something similar - using method_missing to delegate to another object WITH a block expected in that object's #describe method. Does anyone have any other suggestions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:23:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:23:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710152323.AC0815240A67@rubyforge.org> Patches item #12156, was opened at 2007-07-10 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Ienaga Eiji (ienaga) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:23 Message: Thanks. Applied in r2163. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:34:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:34:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070710153418.6060C5240A31@rubyforge.org> Patches item #12010, was opened at 2007-07-05 04:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:34 Message: Great patch! Applied in r2164. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 06:02 Message: Will attach alternative patch as commented previously. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 05:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 04:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 04:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:42:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:42:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11888 ] rspec_on_rails spews out warnings when assert_select is used with an XML response Message-ID: <20070710154245.ABC125240A89@rubyforge.org> Patches item #11888, was opened at 2007-06-27 13:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11888&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Leitch (idl) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rspec_on_rails spews out warnings when assert_select is used with an XML response Initial Comment: The warning: ignoring attempt to close channel with link opened at byte 61, line 3 closed at byte 141, line 5 attributes at open: {} text around open: "ss version=\2.0\>\n \n \n Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:42 Message: Thanks! Applied in r2165 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11888&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:54:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:54:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Message-ID: <20070710155415.AFB065240AF5@rubyforge.org> Bugs item #12162, was opened at 2007-07-10 11:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Initial Comment: Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following: NameError in 'PurchaseController should use PurchaseController' undefined local variable or method `raise_controller_errors' for [RSpec example]:# ./spec/models/../spec_helper.rb:12: ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:55:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:55:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070710155554.8A7885240AE6@rubyforge.org> Patches item #12054, was opened at 2007-07-06 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:55 Message: Great idea. The logic you have to detect twins between lib and spec files is also implemented in RSpec's autotest plugin and in RSpec.tmbundle. I'd like to consolidate this to one place before I apply this, and just rely on one such mechanism from anywhere. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Tue Jul 10 12:17:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 12:17:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11917 ] Cleaner Spec::Ui error for failed Selenium connection Message-ID: <20070710161711.718FE5240BAF@rubyforge.org> Patches item #11917, was opened at 2007-06-29 02:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11917&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Dees (undees) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Cleaner Spec::Ui error for failed Selenium connection Initial Comment: If Spec::Ui fails for some reason to connect to the Selenium remote (e.g., if it's not running, or the port settings are wrong), the result is a rather lengthy backtrace leading off with a "You must call Spec::Ui::ScreenshotFormatter.screenshot..." message---even if the requisite call to screenshot() is in the right place. Spec::Ui::ScreenshotFormatter::extra_error_content() seems to expect @relative_png_path to be set, which is reasonable for spec failures, but in the case of a "before" clause raising an error, this attribute won't have been set yet. The simplest solution is to skip the call to img_div()---which calls relative_png_path()---if failure.expectation_not_met() is false. This would seem to have the side effect of skipping the screen capture for a "describe" clause that raises any error other than ExpectationNotMet. From a test writer's perspective, I can say the lack of a screenshot in that (rare?) case wouldn't bug me. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 12:17 Message: Nice. Applied in r2166 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11917&group_id=797 From noreply at rubyforge.org Tue Jul 10 12:48:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 12:48:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12163 ] spec:ui:selenium:start and spec:ui:selenium:stop Message-ID: <20070710164822.5CEE95240A4A@rubyforge.org> Feature Requests item #12163, was opened at 2007-07-10 16:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: spec:ui:selenium:start and spec:ui:selenium:stop Initial Comment: It would be nice to have these rake tasks to stop and start selenium-server just as we start and top spec_server. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797 From noreply at rubyforge.org Tue Jul 10 14:44:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 14:44:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10823 ] separate errors and failures in output Message-ID: <20070710184404.3680B5240BA4@rubyforge.org> Feature Requests item #10823, was opened at 2007-05-14 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assi