From dchelimsky at gmail.com Fri Mar 6 05:59:15 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Mar 2009 04:59:15 -0600 Subject: [rspec-devel] Help make rspec-1.2 a smooth upgrade Message-ID: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> Hi all, I'm planning to release rspec-1.2 and rspec-rails-1.2 shortly after rails-2.3 goes final (rails-2.3.1 was just released as RC2). There are a couple of loose ends right now, and I need your help in two important areas. I've curtailed releasing github gems, so please clone, build and install the latest [1] if you wish to help out. == Testing the release As rails' internals have changed and rspec-rails has kept up with those changes, I've also been taking the opportunity to clean up much of rspec-rails' internals (along with those of rspec core). While the public API has remain *mostly* unchanged [2], the changes to the internals present some risk for any extension libraries or any of your own customizations that monkey patch internals. To this end, it would be very helpful if you would run your rails apps with the latest rspec/rspec-rails code, and let me know (via reports to http://rspec.lighthouseapp.com) if you run into any problems. == Ruby 1.9 RSpec core's specs are all running against ruby 1.9 now. Not so much with rspec-rails. With rails-2.3.1 (RC2), rspec/rspec-rails-1.1.99.12 [1] and ruby-1.9.1, there is zero feedback. No failures. No errors. Just nothing. It would be most appreciated by many if the bold among you could help to resolve this issue and get rspec-rails working with ruby-1.9.1. Thanks in advance for your assistance. Cheers, David [1] rspec and rspec-rails > 1.1.99.9 require that you clone the github repo and build/install locally. Instructions: http://wiki.github.com/dchelimsky/rspec/releases-and-gems [2] There is some rspec-rails code that needlessly duplicates functionality already available in rails' testing framework. To reduce the maintenance burden, as changes to rails cause problems with rspec-rails, I've been looking for opportunities to access rails via public APIs rather than internals. In some cases, this resulted in changes to rspec-rails. I've documented what I know in Upgrade.markdown in the root of the rspec-rails source. From lasitha.ranatunga at gmail.com Mon Mar 9 11:37:49 2009 From: lasitha.ranatunga at gmail.com (lasitha) Date: Mon, 9 Mar 2009 21:07:49 +0530 Subject: [rspec-devel] getting rspec-rails specs to run on ruby 1.9 Message-ID: <268f428a0903090837v7e013c2dsdcd1b86540672cee@mail.gmail.com> Hello all, i'm looking into getting the rspec-rails specs running on ruby 1.9. The specs not being run at all seems to be related to 1.9 loading rubygems on startup. Specifically, if i pop the test-unit gem off the $LOAD_PATH at the top of rails_suite.rb as follows: $:.delete '/usr/local/ruby1.9/lib/ruby/gems/1.9.1/gems/test-unit-2.0.2/lib' ... then the specs will run (they're all failing, but one thing at a time :). Another way to demonstrate the ruby 1.9 difference is to run it with the --disable-gems flag. This will also cause the specs to run. I will keep digging but wanted to put that out there in case it helps in the meantime. I should also say this is my first foray into rspec[-rails] code, so i may be way off. Pointers appreciated. Solidarity, lasitha From lasitha.ranatunga at gmail.com Mon Mar 9 11:53:24 2009 From: lasitha.ranatunga at gmail.com (lasitha) Date: Mon, 9 Mar 2009 21:23:24 +0530 Subject: [rspec-devel] getting rspec-rails specs to run on ruby 1.9 In-Reply-To: <268f428a0903090837v7e013c2dsdcd1b86540672cee@mail.gmail.com> References: <268f428a0903090837v7e013c2dsdcd1b86540672cee@mail.gmail.com> Message-ID: <268f428a0903090853j332b5ba4v906ef9a4f17eed32@mail.gmail.com> On Mon, Mar 9, 2009 at 9:07 PM, lasitha wrote: > > Specifically, if i pop the test-unit gem off the $LOAD_PATH at the top > of rails_suite.rb as follows: > $:.delete '/usr/local/ruby1.9/lib/ruby/gems/1.9.1/gems/test-unit-2.0.2/lib' > > ... then the specs will run (they're all failing, but one thing at a time :). A quick follow up: I noticed i had two versions of test-unit installed: 2.0.2 - the latest release i got by default 1.2.3 - after realizing rspec asks for this specific version. Uninstalling 2.0.2 gets the specs running (no need for the $:.delete mentioned above). Ruby 1.9 was obviously loading the latest on startup and then rspec was loading 1.2.3 explicitly and that can't be good. I'm now wondering if i'm barking up the wrong tree... Is it likely that many of us have multiple versions of test-unit installed? Perhaps... Back to digging... lasitha. From mhennemeyer at gmail.com Tue Mar 10 06:38:59 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Tue, 10 Mar 2009 03:38:59 -0700 (PDT) Subject: [rspec-devel] Help make rspec-1.2 a smooth upgrade In-Reply-To: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> References: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> Message-ID: <22431644.post@talk.nabble.com> Hi, i have the rspec-rails suite running on my system. I'm running the examples with: $ ruby spec/rails_suite.rb from rspec-dev/example_rails_app/vendor/plugins/rspec-rails. here is the output: http://pastie.org/412600 The no-output issue occurs when i try to run the examples with 'rake spec'. I'm still investigating, but i actually know that (when running the rspec-rails examples with 'rake spec') the TestCase class' inherited callback is never executed and so there are no example_groups when it comes to run the examples. Inside the Spec::Runner::Options#run_examples method there is a conditional that would only let the examples run when example_groups.empty? returns false, but it returns true. Maybe there is a lib loaded after rspec that overrides the TestCases inherited callback? Matthias System info: $ ruby -v #=> ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-darwin9] $ uname -a #=> Darwin mac 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 -- View this message in context: http://www.nabble.com/Help-make-rspec-1.2-a-smooth-upgrade-tp22370822p22431644.html Sent from the rspec-devel mailing list archive at Nabble.com. From mhennemeyer at gmail.com Tue Mar 10 09:13:09 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Tue, 10 Mar 2009 06:13:09 -0700 (PDT) Subject: [rspec-devel] Help make rspec-1.2 a smooth upgrade In-Reply-To: <22431644.post@talk.nabble.com> References: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> <22431644.post@talk.nabble.com> Message-ID: <22433916.post@talk.nabble.com> mhennemeyer wrote: > > Maybe there is a lib loaded after rspec that overrides the > TestCases inherited callback? > It is the test-unit 2.0.2 library. It overrides the inherited callback defined in ExampleGroupMethods. Quick solution is to uninstall the test-unit 2.0.2 gem. Matthias -- View this message in context: http://www.nabble.com/Help-make-rspec-1.2-a-smooth-upgrade-tp22370822p22433916.html Sent from the rspec-devel mailing list archive at Nabble.com. From mhennemeyer at gmail.com Tue Mar 10 09:26:28 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Tue, 10 Mar 2009 06:26:28 -0700 (PDT) Subject: [rspec-devel] Help make rspec-1.2 a smooth upgrade In-Reply-To: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> References: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> Message-ID: <22434132.post@talk.nabble.com> A better solution than uninstalling test-unit-2.0.2 (quick solution) is probably to require test-unit version 1.2.3. I've created a patch: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/727-rspec-rails-require-test-unit-123-if-ruby19 Matthias -- View this message in context: http://www.nabble.com/Help-make-rspec-1.2-a-smooth-upgrade-tp22370822p22434132.html Sent from the rspec-devel mailing list archive at Nabble.com. From dchelimsky at gmail.com Sun Mar 15 15:25:39 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Mar 2009 14:25:39 -0500 Subject: [rspec-devel] [ANN] rspec 1.2.0 Released Message-ID: <57c63afe0903151225v5047d9f8nf306db41a8169ad3@mail.gmail.com> rspec version 1.2.0 has been released! Behaviour Driven Development for Ruby. Changes: ### Version 1.2.0 WARNINGS: * If you use the ruby command to run specs instead of the spec command, you'll need to require 'spec/autorun' or they won't run. This won't affect you if you use the spec command or the Spec::Rake::SpecTask that ships with RSpec. * require 'spec/test/unit' to invoke test/unit interop if you're using RSpec's core (this is handled implicitly with spec-rails) * setup and teardown are gone - use before and after instead * you can still use setup and teardown if you're using Test::Unit::TestCase as the base ExampleGroup class (which is implicit in rspec-rails) * The matcher protocol has been improved. The old protocol is still supported, so as long as you're not monkey patching rspec's built-in matchers, or using extension libraries that do, this should not affect you. If you run into trouble, you'll just need to change: * failure_message => failure_message_for_should * negative_failure_message => failure_message_for_should_not * All references to rubygems have been removed from within rspec's code. * See http://gist.github.com/54177 for rationale and suggestions on alternative approaches to loading rubygems * deprecations * BaseTextFormatter#colourize - use colorize_failure instead. * BaseTextFormatter#magenta - use red instead. * enhancements * cleaner integration with with heckle-1.4.2 * allow registering example groups with a path-like key (Pat Maddox) * start DRb service at "druby://localhost:0" (Hongli Lai) - See http://redmine.ruby-lang.org/issues/show/496 * consistent reporting of errors as failures * added spec/test/unit as more intuitive path to loading test/unit interop lib * added explicit autorun feature for running specs with ruby command * added handling for does_not_match? for matchers that want to know the context in which they were called * lots of ruby 1.9.1 compatibility fixes from Chad Humprhies * improved feedback from be_kind_of/be_a_kind_of/be_instance_of/be_an_instance_of (Jakub ????astn??) * added --format silent (l) option, which is now the default when running --heckle (Bob Aman) * sexy new custom matcher creation (Corey Haines & David Chelimsky - initial concept by Yehuda Katz) * improved matcher protocol - old one is still supported, but new one is cleaner and prefered * bug fixes * support delegating operator matchers to subject with should_not * all arguments are included if --drb is specified in spec.opts (Neil Buckley). Closes #671. * added --autospec option hack (used internally) to get --color to work when using --drb and autospec. * Fixed mock framework failure message bug in which similar calls were excluded from the output * cryptic error message on change.rb when the from value is wrong (Michael Murray). Closes #706. From dchelimsky at gmail.com Sun Mar 15 15:25:44 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Mar 2009 14:25:44 -0500 Subject: [rspec-devel] [ANN] rspec-rails 1.2.0 Released Message-ID: <57c63afe0903151225x577636b1mc7dce1d7af939e8@mail.gmail.com> rspec-rails version 1.2.0 has been released! * * * * Behaviour Driven Development for Ruby on Rails. Changes: ### Version 1.2.0 IMPORTANT INFORMATION: Due to changes in Rails-2.3, there are some changes in rspec-rails-1.2.0 that might break some specs in your existing apps. Be sure to see http://wiki.github.com/dchelimsky/rspec/rails and http://wiki.github.com/dchelimsky/rspec/upgrades for information about upgrading. IMPORTANT: This release includes the following backwards-compatibility-breaking changes. * rspec-rails supports rails 2.0.5, 2.1.2 and 2.2.2, and 2.3.1 * We are no longer supporting 1.x versions of rails. * expect_render and stub_render have been removed. * Both of these methods were deprecated in rspec-rails-1.1.5, released in Sept, 2008. * { route_for(args).should == "/path" } now delegates to assert_generates (in rails) * see Upgrade.markdown for more information * deprecations * controller.use_rails_error_handling! is deprecated * use rescue_action_in_public! (from rails) instead * enhancements * Adding status codes to redirect_to matcher (Damian Janowski). Closes #570. * Initialize current URL before executing any examples in a ViewExampleGroup (Wilson Bilkovich). Closes #654. * Support query strings in params_from (Wilson Bilkovich). Closes #652. * delegate route_for to assert_recognizes (less brittle) * it { should be_valid } (Kakutani). Closes #665. * controller is implicit subject in controller specs (Joe Ferris). #686. * template is implicit subject in view specs (Joe Ferris). #686. * redirect_to and render_template matchers can accept controller or response (Joe Ferris). Closes #686. * generated specs use declarative docstrings * rspec_scaffold generator generates layout and stylesheet (per Rails-2.3) * add bypass_rescue for controller specs * infer template path from the first arg passed to describe in view specs * separate routing specs (in spec/routing) * bug fixes * you no longer *have* to load ActionMailer to get specs to run. Closes #650. * query_params are now parsed by Rack::Utils.parse_query in redirect_to matcher. Closes #684. * cleaned up spec_server (there was a bunch of pre-rails 2.0 material). Closes #685. * rspec's rake tasks are not loaded when running "rake gems" or any of its subtasks * only warn when rspec is not installed when trying to invoke an rspec rake task * support 2 arg version of ActionController::Base#render (reported by Nathan Wilmes) * rake spec:server:start doesn't choke if there is no tmp directory * force cache_classes = false when running with spec_server. Closes #287. * keep spec_server working against edge rails (Jonathan Tron). Closes #685. * create lib/tasks if not present when running script/generate rspec. Closes #687. * fixed regression (and added spec so it won't regress again) where render => :inline didn't render unless integrate_views was set * fixed nil.with_output_buffer bug in helper specs. Closes #719. From roman.chernyatchik at jetbrains.com Wed Mar 18 12:08:23 2009 From: roman.chernyatchik at jetbrains.com (Roman.Chernyatchik) Date: Wed, 18 Mar 2009 19:08:23 +0300 Subject: [rspec-devel] Changed Spec::Example::ExampleMethods.execute() behavior in rspec 1.2.0 In-Reply-To: <57c63afe0903151225x577636b1mc7dce1d7af939e8@mail.gmail.com> References: <57c63afe0903151225x577636b1mc7dce1d7af939e8@mail.gmail.com> Message-ID: <3BD38D6C-799F-4446-886C-59E96689D43A@jetbrains.com> Hi rspec guys, I've just noticed that in rspec 1.2.0 Spec::Example::ExampleMethods.execute() method sends formatter empty string instead of example object (as it was in RSpec 1.1.12) Just compare old and new behaviors: ---- rspec-1.2.0/lib/spec/example/example_methods.rb, lines 28-32 ---- ------------------------------------------------------------------------------------------ def execute(run_options, instance_variables) # :nodoc: #FIIXME - there is no reason to have example_started pass a name # - in fact, it would introduce bugs in cases where no docstring # is passed to it() run_options.reporter.example_started("") ------------------------------------------------------------------------------------------ with ---- rspec-1.1.12/lib/spec/example/example_methods.rb, lines 44-45 ---- ------------------------------------------------------------------------------------------ def execute(options, instance_variables) options.reporter.example_started(self) ------------------------------------------------------------------------------------------ Unfortunately this change affects our custom formatter (for RubyMine IDE) because in our test runner GUI we use "example_started" event to show that corresponding example starts. It is possible to restore old behavior? May I create issue in bug tracker? ---- Best regards, Roman Chernyatchik, RubyMine Developer, JetBrains, Inc. http://www.jetbrains.com/ "Develop with Pleasure!" From dchelimsky at gmail.com Wed Mar 18 12:25:53 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Mar 2009 11:25:53 -0500 Subject: [rspec-devel] Changed Spec::Example::ExampleMethods.execute() behavior in rspec 1.2.0 In-Reply-To: <3BD38D6C-799F-4446-886C-59E96689D43A@jetbrains.com> References: <57c63afe0903151225x577636b1mc7dce1d7af939e8@mail.gmail.com> <3BD38D6C-799F-4446-886C-59E96689D43A@jetbrains.com> Message-ID: <57c63afe0903180925x6ae098a8kace58e8f1a5e416@mail.gmail.com> On Wed, Mar 18, 2009 at 11:08 AM, Roman.Chernyatchik wrote: > Hi rspec guys, > > I've just noticed that in rspec 1.2.0 > Spec::Example::ExampleMethods.execute() method sends formatter empty string > instead of example object (as it was in RSpec 1.1.12) > Just compare old and new behaviors: > > ---- rspec-1.2.0/lib/spec/example/example_methods.rb, lines 28-32 ---- > ------------------------------------------------------------------------------------------ > def execute(run_options, instance_variables) # :nodoc: > ?#FIIXME - there is no reason to have example_started pass a name > ?# - in fact, it would introduce bugs in cases where no docstring > ?# is passed to it() > ?run_options.reporter.example_started("") > ------------------------------------------------------------------------------------------ > > with > > ---- rspec-1.1.12/lib/spec/example/example_methods.rb, lines 44-45 ?---- > ------------------------------------------------------------------------------------------ > def execute(options, instance_variables) > ?options.reporter.example_started(self) > ------------------------------------------------------------------------------------------ > > Unfortunately this change affects our custom formatter (for RubyMine IDE) > because in our test runner GUI we use "example_started" event to show that > corresponding example starts. > It is possible to restore old behavior? May I create issue in bug tracker? You can always create an issue in the bug tracker :) http://rspec.lighthouseapp.com I have some thoughts about this but I'd like to capture the conversation in the tracker. Thanks, David > > ---- > Best regards, > > Roman Chernyatchik, > RubyMine Developer, > JetBrains, Inc. > http://www.jetbrains.com/ > "Develop with Pleasure!" > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From roman.chernyatchik at jetbrains.com Wed Mar 18 13:03:04 2009 From: roman.chernyatchik at jetbrains.com (Roman.Chernyatchik) Date: Wed, 18 Mar 2009 20:03:04 +0300 Subject: [rspec-devel] Changed Spec::Example::ExampleMethods.execute() behavior in rspec 1.2.0 In-Reply-To: <57c63afe0903180925x6ae098a8kace58e8f1a5e416@mail.gmail.com> References: <57c63afe0903151225x577636b1mc7dce1d7af939e8@mail.gmail.com> <3BD38D6C-799F-4446-886C-59E96689D43A@jetbrains.com> <57c63afe0903180925x6ae098a8kace58e8f1a5e416@mail.gmail.com> Message-ID: <7BA76FC3-B1CB-41DA-9793-F5205DDB9DFD@jetbrains.com> David, Thanks for a quick reply, I've created an issue http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/738 --- Best regards, Roman Chernyatchik, RubyMine Developer, JetBrains, Inc. http://www.jetbrains.com/ "Develop with Pleasure!" On 18.03.2009, at 19:25, David Chelimsky wrote: > > You can always create an issue in the bug tracker :) > > http://rspec.lighthouseapp.com > > I have some thoughts about this but I'd like to capture the > conversation in the tracker. > > Thanks, > David > >> >> ---- >> Best regards, >> >> Roman Chernyatchik, >> RubyMine Developer, >> JetBrains, Inc. >> http://www.jetbrains.com/ >> "Develop with Pleasure!" >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt-lists at reprocessed.org Wed Mar 18 15:40:56 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 18 Mar 2009 19:40:56 +0000 Subject: [rspec-devel] The new spec/routing convention isn't recognised by Autotest Message-ID: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> Hey guys, I've just upgraded a Rails app to rspec-rails 1.2, and moved my routing specs over to spec/routing after noticing that bit of the upgrade file. However, autotest doesn't recognise that location, so no specs run... I've opened a ticket and commited a patch to my fork... ticket's at http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/739 Best, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From dchelimsky at gmail.com Wed Mar 18 16:11:58 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Mar 2009 15:11:58 -0500 Subject: [rspec-devel] The new spec/routing convention isn't recognised by Autotest In-Reply-To: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> References: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> Message-ID: <57c63afe0903181311o41287f38yb4c31c13a70ee867@mail.gmail.com> Thanks Matt - I get notified when tickets are entered, so you don't need to post here as well just to say there is a ticket :) Thanks for the ticket, and the patch, and the follow through. I won't be able to address until tonight, but I'll get it applied. Thanks, David On Wed, Mar 18, 2009 at 2:40 PM, Matt Patterson wrote: > Hey guys, > > I've just upgraded a Rails app to rspec-rails 1.2, and moved my routing > specs over to spec/routing after noticing that bit of the upgrade file. > > However, autotest doesn't recognise that location, so no specs run... > > I've opened a ticket and commited a patch to my fork... > > ticket's at http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/739 > > Best, > > Matt > > > -- > ?Matt Patterson | Design & Code > ? | http://www.reprocessed.org/ > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From scott at railsnewbie.com Wed Mar 18 16:40:58 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Wed, 18 Mar 2009 16:40:58 -0400 Subject: [rspec-devel] The new spec/routing convention isn't recognised by Autotest In-Reply-To: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> References: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> Message-ID: <658F7227-BFF3-4BAB-929A-9D3671F63085@railsnewbie.com> On Mar 18, 2009, at 3:40 PM, Matt Patterson wrote: > Hey guys, > > I've just upgraded a Rails app to rspec-rails 1.2, and moved my > routing specs over to spec/routing after noticing that bit of the > upgrade file. > > However, autotest doesn't recognise that location, so no specs run... > > I've opened a ticket and commited a patch to my fork... > > ticket's at http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/739 You should add specs for it. Scott > > > Best, > > Matt > > > -- > Matt Patterson | Design & Code > | http://www.reprocessed.org/ > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From matt-lists at reprocessed.org Wed Mar 18 19:25:27 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 18 Mar 2009 23:25:27 +0000 Subject: [rspec-devel] The new spec/routing convention isn't recognised by Autotest In-Reply-To: <658F7227-BFF3-4BAB-929A-9D3671F63085@railsnewbie.com> References: <336668B6-DF99-4132-B7AC-85F6C8314C4C@reprocessed.org> <658F7227-BFF3-4BAB-929A-9D3671F63085@railsnewbie.com> Message-ID: On 18 Mar 2009, at 20:40, Scott Taylor wrote: > On Mar 18, 2009, at 3:40 PM, Matt Patterson wrote: > >> ticket's at http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/739 > > You should add specs for it. You're quite right. For some reason I looked at it and thought that the mappings were unspecced. One of those days. I'll post a link to the second commit on the lighthouse ticket Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From aslak.hellesoy at gmail.com Sat Mar 21 15:38:09 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 21 Mar 2009 15:38:09 -0400 Subject: [rspec-devel] [Cucumber] new usage formatter Message-ID: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> http://github.com/aslakhellesoy/cucumber/commit/60bcff6ceb1efb0a5439d2bbcfd30d1d8e7a910b This should be of interest to anyone writing editor code completion and navigation support for Cucumber (notably Cucumber.tmbubdle) Try this in cucumber's root dir: bin/cucumber examples/self_test/features -f usage --dry-run This gives the following output (truncated): /^passing without a table$/ # examples/self_test/features/step_definitions/sample_steps.rb:12 Given passing without a table # examples/self_test/features/background/failing_background_after_success.feature:4 Given without a table # examples/self_test/features/outline_sample.feature:6 Given without a table # examples/self_test/features/outline_sample.feature:7 /^failing without a table$/ # examples/self_test/features/step_definitions/sample_steps.rb:15 Given failing without a table # examples/self_test/features/background/failing_background.feature:4 Given failing without a table # examples/self_test/features/background/scenario_outline_failing_background.feature:4 I'm hoping the Following TODOs from Cucumber.tmbundle can use this: - Goto step definition from feature file. - From a step definition be able to pull up a list of features using that step and to jump to them. Aslak -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Sat Mar 21 19:59:57 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 21 Mar 2009 19:59:57 -0400 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> Message-ID: <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> On Sat, Mar 21, 2009 at 7:12 PM, Dr Nic Williams wrote: > > I'm hoping the Following TODOs from Cucumber.tmbundle can use this: > > > > Goto step definition from feature file. > > Currently works with Shift+Alt+Cmd+Down > Yes, but that is based on code in the bundle right? Isn't it better to use "official" Cucumber code for this? Aslak > > From a step definition be able to pull up a list of features using that > step > > and to jump to them. > > Yeah I want this too. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at benmabey.com Sat Mar 21 23:25:12 2009 From: ben at benmabey.com (Ben Mabey) Date: Sat, 21 Mar 2009 21:25:12 -0600 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> Message-ID: <49C5AF98.2010008@benmabey.com> aslak hellesoy wrote: > > > On Sat, Mar 21, 2009 at 7:12 PM, Dr Nic Williams > > wrote: > > > I'm hoping the Following TODOs from Cucumber.tmbundle can use this: > > > > Goto step definition from feature file. > > Currently works with Shift+Alt+Cmd+Down > > > Yes, but that is based on code in the bundle right? Isn't it better to > use "official" Cucumber code for this? > > Aslak +1. I think we should keep as much functionality in Cucumber so other editors can leverage the functionality. > > > > From a step definition be able to pull up a list of features > using that step > > and to jump to them. > > Yeah I want this too. > > I'm going to take a stab at this now with the new usage formatter- very nice! I think the biggest drawback to this will be speed. For example, doing a dry-run on cucumber's own features takes ~2 seconds. For a rails project loading up the entire environment I think this would be too slow to wait for everytime. Any ideas on a caching strategy? Storing a cached version of the output is easy enough, but knowing when to expire the cache is somewhat tricky... -Ben From aslak.hellesoy at gmail.com Sun Mar 22 00:45:34 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 22 Mar 2009 00:45:34 -0400 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <49C5AF98.2010008@benmabey.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> <49C5AF98.2010008@benmabey.com> Message-ID: <8d961d900903212145y16f88b80k1b8c0b65b555caee@mail.gmail.com> On Sat, Mar 21, 2009 at 11:25 PM, Ben Mabey wrote: > aslak hellesoy wrote: > >> >> >> On Sat, Mar 21, 2009 at 7:12 PM, Dr Nic Williams > drnicwilliams at gmail.com>> wrote: >> >> > I'm hoping the Following TODOs from Cucumber.tmbundle can use this: >> > >> > Goto step definition from feature file. >> >> Currently works with Shift+Alt+Cmd+Down >> >> >> Yes, but that is based on code in the bundle right? Isn't it better to use >> "official" Cucumber code for this? >> >> Aslak >> > > +1. I think we should keep as much functionality in Cucumber so other > editors can leverage the functionality. > >> >> >> > From a step definition be able to pull up a list of features >> using that step >> > and to jump to them. >> >> Yeah I want this too. >> >> >> I'm going to take a stab at this now with the new usage formatter- very > nice! I think the biggest drawback to this will be speed. For example, > doing a dry-run on cucumber's own features takes ~2 seconds. For a rails > project loading up the entire environment I think this would be too slow to > wait for everytime. Any ideas on a caching strategy? Storing a cached > version of the output is easy enough, but knowing when to expire the cache > is somewhat tricky... > Or maybe we could optimise. The support files don't have to be loaded, nor do we need to instantiate a full AST (mulitline args can be skipped). I'll try out a few things. I'm sure we can make it perform reasonably well. Aslak > > -Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Mon Mar 23 01:07:38 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Mar 2009 00:07:38 -0500 Subject: [rspec-devel] [ANN] rspec 1.2.1 Released Message-ID: <57c63afe0903222207k1a5bb22g8714327a553017f8@mail.gmail.com> rspec version 1.2.1 has been released! * * * * Behaviour Driven Development for Ruby. Changes: ### Version 1.2.1 / 2009-03-22 This is a bug-fix release, recommended for anybody who has already upgraded to rspec-1.2.0. See Upgrade.rdoc for information about upgrading to rspec-1.2.1 * enhancments * matchers, including the new DSL, easily added to your test/unit tests * added support for 0 to n args in matcher DSL * restored loading rubygems when necessary * if you really don't want to use rubygems, you can set an NO_RUBYGEMS environment variable, and RSpec won't force it on you. * added -u/--debugger option (Rick DeNatale) #262. * just add "debugger" anywhere in your code and run spec path/to/code --debugger * rename ExampleDescription to ExampleProxy * pass ExampleProxy to example_started(). Closes #738, #743 * thanks to Tobias Grimm (Eclipse) fort the patch and Roman Chernyatchik (JetBrains, RubyMine) for the assist * bug fixes * subject (implicit or explicit) is now properly inherited by nested groups. Closes #744. * * * * From dchelimsky at gmail.com Mon Mar 23 01:08:02 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Mar 2009 00:08:02 -0500 Subject: [rspec-devel] [ANN] rspec-rails 1.2.1 Released Message-ID: <57c63afe0903222208y6384ee37qb77c5dfa21b9b62f@mail.gmail.com> rspec-rails version 1.2.1 has been released! * * * * * Behaviour Driven Development for Ruby on Rails. Changes: ### Version 1.2.1 / 2009-03-22 This is a bug-fix release, recommended for anybody who has already upgraded to rspec-rails-1.2.0 or is upgrading to rails-2.3.2 See Upgrade.rdoc for information about upgrading to rspec-rails-1.2.1 * enhancements * more cleanup of internals (reducing dependency on rspec-core) * don't require config/environments more than once * autotest includes spec/routing directory (Matt Peterson). Closes #739. * display helpful messages when installing rspec-rails running script/generate rspec * thanks for Dr Nic for the pointers * restored require 'rubygems' where needed * export NO_RUBYGEMS=true if you don't use rubygems * bug fixes * fix scoping issues in rspec-rails' own suite for ruby 1.9.1 (Matthias Hennemeyer). Closes #717. * rake stats no longer hides test directories. Closes #748. * fixed regression that was introduced in 1.2 in which controller_name failed to override the controller class passed to describe() (patches from Aaron Gibralter and Zach Dennis). Closes #732. * * * * * From dchelimsky at gmail.com Mon Mar 23 02:49:21 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Mar 2009 01:49:21 -0500 Subject: [rspec-devel] [ANN] rspec 1.2.2 Released Message-ID: <57c63afe0903222349m583bb6c2qa2268af3ccb5a2a4@mail.gmail.com> rspec version 1.2.2 has been released! * * * * Behaviour Driven Development for Ruby. Changes: ### Version 1.2.2 / 2009-03-22 Bug-fix release (fixes regression introduced in 1.2.1) * bug fixes * fixed bug in which spec_parser raised an error for custom example group base classes * * * * From dchelimsky at gmail.com Mon Mar 23 02:49:27 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Mar 2009 01:49:27 -0500 Subject: [rspec-devel] [ANN] rspec-rails 1.2.2 Released Message-ID: <57c63afe0903222349p13b26d4dq3126ff2cb2c67b0a@mail.gmail.com> rspec-rails version 1.2.2 has been released! * * * * * Behaviour Driven Development for Ruby on Rails. Changes: ### Version 1.2.2 / 2009-03-22 No changes in this release, but aligns with the rspec-1.2.2 release. * * * * * From matt-lists at reprocessed.org Tue Mar 24 17:46:10 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Tue, 24 Mar 2009 21:46:10 +0000 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action Message-ID: Evening. I've got a question about the redefinition of ActionController::Base#rescue_action. Mainly, why? From the comment in the source it looks there was a pain point that this solved, but I can't figure out what that might be. My problem is this: I make heavy use of rescue_from to trap exceptional cases so I can 404, 401 or 500 as appropriate. I've got a Scenario which looks like this ('deleted' blog posts in this app aren't erased from the DB, they're marked deleted for auditing): Scenario: Attempting to visit a deleted blog post Given there is a blog post entitled "Look Ma no hands" And the blog post "Look Ma no hands" has been marked as deleted When I attempt to visit the Blog post page for "Look Ma no hands" Then the response should be a 404 error That looks like a perfectly reasonable scenario to me, except that it blows up at "When I attempt to visit". The source for that step is: When /^I attempt to visit the Blog post page for "(.+)"$/ do |title| visit entry_path(Entry.find_by_url_slug! (Digest::MD5.hexdigest(title))) end [Excuse the MD5 - it's just a way of maintaining readability in the scenarios without resorting to fixtures (I'm undecided about it as an approach, btw)] visit is exploding when my controller raises a FourOhFour error because a non-staff non-logged-in user shouldn't be able to see the page. I use rescue_from to render a special 404 template, but that's never reached because of the redefinition of rescue_action. This seems really counterintuitive to me: I expect that the integration tests will use the full stack, and even in my isolated controller specs I have to explicitly request that the normal rescue_action is bypassed. If there's a genuine pain point here that re-raising and not handling the exception solves then I'm sure I can find a different idiom for these kinds of scenarios, but I've spent 4 hours today trying to figure out what was broken: first in my app code then breaking out rdebug to find out what was really happening, which suggests to me that it's a non-obvious and confusing intervention. Anyway, sorry to sound so whingey. Like I said: if there's a genuine problem this approach solves, I'll find a new idiom and shut up. Otherwise, can this be changed? Thanks, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From aslak.hellesoy at gmail.com Tue Mar 24 18:45:49 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 24 Mar 2009 23:45:49 +0100 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: References: Message-ID: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson wrote: > Evening. > > I've got a question about the redefinition of > ActionController::Base#rescue_action. Mainly, why? From the comment in the > source it looks there was a pain point that this solved, but I can't figure > out what that might be. > > My problem is this: I make heavy use of rescue_from to trap exceptional > cases so I can 404, 401 or 500 as appropriate. I've got a Scenario which > looks like this ('deleted' blog posts in this app aren't erased from the DB, > they're marked deleted for auditing): > > Scenario: Attempting to visit a deleted blog post > Given there is a blog post entitled "Look Ma no hands" > And the blog post "Look Ma no hands" has been marked as deleted > When I attempt to visit the Blog post page for "Look Ma no hands" > Then the response should be a 404 error > > That looks like a perfectly reasonable scenario to me, except that it blows > up at "When I attempt to visit". The source for that step is: > > When /^I attempt to visit the Blog post page for "(.+)"$/ do |title| > visit entry_path(Entry.find_by_url_slug!(Digest::MD5.hexdigest(title))) > end > > [Excuse the MD5 - it's just a way of maintaining readability in the > scenarios without resorting to fixtures (I'm undecided about it as an > approach, btw)] > > visit is exploding when my controller raises a FourOhFour error because a > non-staff non-logged-in user shouldn't be able to see the page. I use > rescue_from to render a special 404 template, but that's never reached > because of the redefinition of rescue_action. > > This seems really counterintuitive to me: I expect that the integration > tests will use the full stack, and even in my isolated controller specs I > have to explicitly request that the normal rescue_action is bypassed. If > there's a genuine pain point here that re-raising and not handling the > exception solves then I'm sure I can find a different idiom for these kinds > of scenarios, but I've spent 4 hours today trying to figure out what was > broken: first in my app code then breaking out rdebug to find out what was > really happening, which suggests to me that it's a non-obvious and confusing > intervention. > > Anyway, sorry to sound so whingey. Like I said: if there's a genuine > problem this approach solves, I'll find a new idiom and shut up. Otherwise, > can this be changed? > I understand your situation - it's perfectly valid. Still, I think you are the first person to bring this up. The vast majority of Cucumber users/Rails developers don't rely on this kind of error handling, so raising errors seems to be a sensible default. There is currently no way to turn off that default. Can you provide a patch (or a suggestion) that will let users optionally turn off the current behaviour? Aslak > > Thanks, > > Matt > > -- > Matt Patterson | Design & Code > | http://www.reprocessed.org/ > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach.dennis at gmail.com Tue Mar 24 19:04:39 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 24 Mar 2009 19:04:39 -0400 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> Message-ID: <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> 2009/3/24 aslak hellesoy : > > > On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson > wrote: >> >> Evening. >> >> I've got a question about the redefinition of >> ActionController::Base#rescue_action. Mainly, why? From the comment in the >> source it looks there was a pain point that this solved, but I can't figure >> out what that might be. >> >> My problem is this: I make heavy use of rescue_from to trap exceptional >> cases so I can 404, 401 or 500 as appropriate. I've got a Scenario which >> looks like this ('deleted' blog posts in this app aren't erased from the DB, >> they're marked deleted for auditing): >> >> ?Scenario: Attempting to visit a deleted blog post >> ? ?Given there is a blog post entitled "Look Ma no hands" >> ? ?And the blog post "Look Ma no hands" has been marked as deleted >> ? ?When I attempt to visit the Blog post page for "Look Ma no hands" >> ? ?Then the response should be a 404 error >> >> That looks like a perfectly reasonable scenario to me, except that it >> blows up at "When I attempt to visit". The source for that step is: >> >> When /^I attempt to visit the Blog post page for "(.+)"$/ do |title| >> ?visit entry_path(Entry.find_by_url_slug!(Digest::MD5.hexdigest(title))) >> end >> >> [Excuse the MD5 - it's just a way of maintaining readability in the >> scenarios without resorting to fixtures (I'm undecided about it as an >> approach, btw)] >> >> visit is exploding when my controller raises a FourOhFour error because a >> non-staff non-logged-in user shouldn't be able to see the page. I use >> rescue_from to render a special 404 template, but that's never reached >> because of the redefinition of rescue_action. >> >> This seems really counterintuitive to me: I expect that the integration >> tests will use the full stack, and even in my isolated controller specs I >> have to explicitly request that the normal rescue_action is bypassed. If >> there's a genuine pain point here that re-raising and not handling the >> exception solves then I'm sure I can find a different idiom for these kinds >> of scenarios, but I've spent 4 hours today trying to figure out what was >> broken: first in my app code then breaking out rdebug to find out what was >> really happening, which suggests to me that it's a non-obvious and confusing >> intervention. >> >> Anyway, sorry to sound so whingey. Like I said: if there's a genuine >> problem this approach solves, I'll find a new idiom and shut up. Otherwise, >> can this be changed? I usually comment those things out in rails/world.rb in cucumber. > > I understand your situation - it's perfectly valid. Still, I think you are > the first person to bring this up. Nope, he's not: http://www.ruby-forum.com/topic/177887 > The vast majority of Cucumber users/Rails > developers don't rely on this kind of error handling, so raising errors > seems to be a sensible default. I'm not the vast, but I rely on, and I know several other Rails devs who rely on it to. Although, we may still be the minority. > > There is currently no way to turn off that default. Can you provide a patch > (or a suggestion) that will let users optionally turn off the current > behaviour? A discussion was originally brought up here: http://rspec.lighthouseapp.com/projects/16211/tickets/49-cucumber-and-rails-controller-error-handling I apologize for not being proactive on my end, so far taking out the offending lines on rails/world.rb has worked fine. > > Aslak > >> >> Thanks, >> >> Matt >> >> -- >> ?Matt Patterson | Design & Code >> ? | http://www.reprocessed.org/ >> >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From matt-lists at reprocessed.org Tue Mar 24 20:11:32 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 25 Mar 2009 00:11:32 +0000 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> Message-ID: <96F8CB33-AFCF-4465-A10A-4DE28BD12D2B@reprocessed.org> On 24 Mar 2009, at 23:04, Zach Dennis wrote: > 2009/3/24 aslak hellesoy : >> >> On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson >> wrote: >>> >>> Anyway, sorry to sound so whingey. Like I said: if there's a genuine >>> problem this approach solves, I'll find a new idiom and shut up. >>> Otherwise, >>> can this be changed? > > I usually comment those things out in rails/world.rb in cucumber. That's what I wound up doing >> There is currently no way to turn off that default. Can you provide >> a patch >> (or a suggestion) that will let users optionally turn off the current >> behaviour? > > A discussion was originally brought up here: > > http://rspec.lighthouseapp.com/projects/16211/tickets/49-cucumber-and-rails-controller-error-handling > > I apologize for not being proactive on my end, so far taking out the > offending lines on rails/world.rb has worked fine. Interesting - I think it should definitely be configurable from Cucumber, rather than reuse the RSpec config - I want rescue_action bypassed in RSpec and honoured in Cucumber... I've had a bit of a poke around and think I can do something along the lines of Cucumber::Rails.use_transactional_fixtures I'll submit a patch to that Lighthouse ticket in the morning. Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From aslak.hellesoy at gmail.com Tue Mar 24 20:14:49 2009 From: aslak.hellesoy at gmail.com (=?utf-8?Q?Aslak_Helles=C3=B8y?=) Date: Wed, 25 Mar 2009 01:14:49 +0100 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> Message-ID: Den 25. mars. 2009 kl. 00.04 skrev Zach Dennis : > 2009/3/24 aslak hellesoy : >> >> >> On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson >> wrote: >>> >>> Evening. >>> >>> I've got a question about the redefinition of >>> ActionController::Base#rescue_action. Mainly, why? From the >>> comment in the >>> source it looks there was a pain point that this solved, but I >>> can't figure >>> out what that might be. >>> >>> My problem is this: I make heavy use of rescue_from to trap >>> exceptional >>> cases so I can 404, 401 or 500 as appropriate. I've got a Scenario >>> which >>> looks like this ('deleted' blog posts in this app aren't erased >>> from the DB, >>> they're marked deleted for auditing): >>> >>> Scenario: Attempting to visit a deleted blog post >>> Given there is a blog post entitled "Look Ma no hands" >>> And the blog post "Look Ma no hands" has been marked as deleted >>> When I attempt to visit the Blog post page for "Look Ma no hands" >>> Then the response should be a 404 error >>> >>> That looks like a perfectly reasonable scenario to me, except that >>> it >>> blows up at "When I attempt to visit". The source for that step is: >>> >>> When /^I attempt to visit the Blog post page for "(.+)"$/ do |title| >>> visit entry_path(Entry.find_by_url_slug! >>> (Digest::MD5.hexdigest(title))) >>> end >>> >>> [Excuse the MD5 - it's just a way of maintaining readability in the >>> scenarios without resorting to fixtures (I'm undecided about it as >>> an >>> approach, btw)] >>> >>> visit is exploding when my controller raises a FourOhFour error >>> because a >>> non-staff non-logged-in user shouldn't be able to see the page. I >>> use >>> rescue_from to render a special 404 template, but that's never >>> reached >>> because of the redefinition of rescue_action. >>> >>> This seems really counterintuitive to me: I expect that the >>> integration >>> tests will use the full stack, and even in my isolated controller >>> specs I >>> have to explicitly request that the normal rescue_action is >>> bypassed. If >>> there's a genuine pain point here that re-raising and not handling >>> the >>> exception solves then I'm sure I can find a different idiom for >>> these kinds >>> of scenarios, but I've spent 4 hours today trying to figure out >>> what was >>> broken: first in my app code then breaking out rdebug to find out >>> what was >>> really happening, which suggests to me that it's a non-obvious and >>> confusing >>> intervention. >>> >>> Anyway, sorry to sound so whingey. Like I said: if there's a genuine >>> problem this approach solves, I'll find a new idiom and shut up. >>> Otherwise, >>> can this be changed? > > I usually comment those things out in rails/world.rb in cucumber. > >> >> I understand your situation - it's perfectly valid. Still, I think >> you are >> the first person to bring this up. > > Nope, he's not: > > http://www.ruby-forum.com/topic/177887 Doh. Forgot. > > >> The vast majority of Cucumber users/Rails >> developers don't rely on this kind of error handling, so raising >> errors >> seems to be a sensible default. > > I'm not the vast, but I rely on, and I know several other Rails devs > who rely on it to. Although, we may still be the minority. > >> >> There is currently no way to turn off that default. Can you provide >> a patch >> (or a suggestion) that will let users optionally turn off the current >> behaviour? > > A discussion was originally brought up here: > > http://rspec.lighthouseapp.com/projects/16211/tickets/49-cucumber-and-rails-controller-error-handling > > I apologize for not being proactive on my end, so far taking out the > offending lines on rails/world.rb has worked fine. > >> >> Aslak >> >>> >>> Thanks, >>> >>> Matt >>> >>> -- >>> Matt Patterson | Design & Code >>> | http://www.reprocessed.org/ >>> >>> >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From zach.dennis at gmail.com Tue Mar 24 21:03:28 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 24 Mar 2009 21:03:28 -0400 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <96F8CB33-AFCF-4465-A10A-4DE28BD12D2B@reprocessed.org> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> <96F8CB33-AFCF-4465-A10A-4DE28BD12D2B@reprocessed.org> Message-ID: <85d99afe0903241803q2f6e9898ve47761b6ff08ab17@mail.gmail.com> On Tue, Mar 24, 2009 at 8:11 PM, Matt Patterson wrote: > On 24 Mar 2009, at 23:04, Zach Dennis wrote: > >> 2009/3/24 aslak hellesoy : >>> >>> On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson >>> wrote: >>>> >>>> Anyway, sorry to sound so whingey. Like I said: if there's a genuine >>>> problem this approach solves, I'll find a new idiom and shut up. >>>> Otherwise, >>>> can this be changed? >> >> I usually comment those things out in rails/world.rb in cucumber. > > That's what I wound up doing > >>> There is currently no way to turn off that default. Can you provide a >>> patch >>> (or a suggestion) that will let users optionally turn off the current >>> behaviour? >> >> A discussion was originally brought up here: >> >> >> http://rspec.lighthouseapp.com/projects/16211/tickets/49-cucumber-and-rails-controller-error-handling >> >> I apologize for not being proactive on my end, so far taking out the >> offending lines on rails/world.rb has worked fine. > > > Interesting - I think it should definitely be configurable from Cucumber, > rather than reuse the RSpec config - I want rescue_action bypassed in RSpec > and honoured in Cucumber... > > I've had a bit of a poke around and think I can do something along the lines > of Cucumber::Rails.use_transactional_fixtures > > I'll submit a patch to that Lighthouse ticket in the morning. > I don't know if you have already, but be sure to read through the related RSpec ticket: http://rspec.lighthouseapp.com/projects/5645/tickets/85-11818-have-mode-for-rails-error-handling The discussion on that ticket evolved over time and has some good thoughts that ultimately ended up in RSpec. I think some of those same considerations would do a Cucumber patch good. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From matt-lists at reprocessed.org Wed Mar 25 04:04:37 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 25 Mar 2009 08:04:37 +0000 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <85d99afe0903241803q2f6e9898ve47761b6ff08ab17@mail.gmail.com> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> <96F8CB33-AFCF-4465-A10A-4DE28BD12D2B@reprocessed.org> <85d99afe0903241803q2f6e9898ve47761b6ff08ab17@mail.gmail.com> Message-ID: <4853F0AA-BEF8-4FCC-9868-D86DF88B2697@reprocessed.org> On 25 Mar 2009, at 01:03, Zach Dennis wrote: >> >> I've had a bit of a poke around and think I can do something along >> the lines >> of Cucumber::Rails.use_transactional_fixtures >> >> I'll submit a patch to that Lighthouse ticket in the morning. > > I don't know if you have already, but be sure to read through the > related RSpec ticket: > > http://rspec.lighthouseapp.com/projects/5645/tickets/85-11818-have-mode-for-rails-error-handling > > The discussion on that ticket evolved over time and has some good > thoughts that ultimately ended up in RSpec. I think some of those same > considerations would do a Cucumber patch good. I hadn't seen the ticket, but I had looked at bypass_rescue in the source. I've looked over the ticket now and I think that what I'm proposing is broadly in line with it. Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From matt-lists at reprocessed.org Wed Mar 25 06:13:59 2009 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 25 Mar 2009 10:13:59 +0000 Subject: [rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action In-Reply-To: <4853F0AA-BEF8-4FCC-9868-D86DF88B2697@reprocessed.org> References: <8d961d900903241545w64fb6dc4ia645116d9f0b8001@mail.gmail.com> <85d99afe0903241604v617c1135gd13d542d114af48b@mail.gmail.com> <96F8CB33-AFCF-4465-A10A-4DE28BD12D2B@reprocessed.org> <85d99afe0903241803q2f6e9898ve47761b6ff08ab17@mail.gmail.com> <4853F0AA-BEF8-4FCC-9868-D86DF88B2697@reprocessed.org> Message-ID: On 25 Mar 2009, at 08:04, Matt Patterson wrote: > I hadn't seen the ticket, but I had looked at bypass_rescue in the > source. I've looked over the ticket now and I think that what I'm > proposing is broadly in line with it. I've got a patched Cucumber fork which moves the rescue-related redefinitions to a method (Cucumber::Rails.bypass_rescue), and updated the ticket here: http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/49-cucumber-and-rails-controller-error-handling Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From dchelimsky at gmail.com Wed Mar 25 21:31:06 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Mar 2009 20:31:06 -0500 Subject: [rspec-devel] require 'rubygems' Message-ID: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Hey all, I'd like your feedback on something before I merge it into master. Before the 1.2 release I read http://gist.github.com/54177, in which Ryan Tomayko explains why "require 'rubygems'" should not appear in your library code. This made some sense to me. So much so, that I yanked it from rspec for the 1.2 release. Then the bug reports started coming in and some conversation led me to believe that this had been a mistake because it caused pain for the lion's share of rspec users because most libraries go ahead and require 'rubygems', so that has become the defacto standard situation, for better or worse. The solution that I added to 1.2.1 was to reinstate "require 'rubygems'" but with a catch: require 'rubygems' unless ENV['NO_RUBYGEMS'] This seemed like a fair tradeoff, since it allowed those who didn't want to have to think about it to just use rspec as/is, and those who do care and don't use rubygems in any given environment had an out. I've just received another report about that decision, with a patch, that offers what I think is a better solution: https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more I've pushed Tobias' patch to a require-rubygems branch for the moment. I'm inclined to merge it into master, but this would the third release in a row that makes changes to how rspec handles rubygems, and I want it to be the last. So please let me know your thoughts, for or against. Thanks, David From peter.fitzgibbons at gmail.com Wed Mar 25 22:02:58 2009 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Wed, 25 Mar 2009 21:02:58 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: <670a00380903251902q2f3ae995ud572cd37069656a6@mail.gmail.com> -1 on the push to master. I agree with Tobias' synopsis. I think though that there could be something better than letting anyone's library fail without proper libraries. As troublesome as rubygems might be for some, it is clear when I get a rubygems-load error that I'm missing an install detail. When I get a load error from require... WTH? Maybe without rubygems I'd expect any load error to be something "I" missed. David, you may have stumbled upon a wakeup call to many rspec users who have not been paying attention to their library loading mechanism. To any of those in pain... ever used PERL? Shove THAT in your load library! Ruby is sane in comparison. So, rant and vote all in one. A two in one deal! Happy Trails Peter Fitzgibbons (847) 687-7646 Email: peter.fitzgibbons at gmail.com IM GTalk: peter.fitzgibbons IM Yahoo: pjfitzgibbons IM MSN: pjfitzgibbons at hotmail.com IM AOL: peter.fitzgibbons at gmail.com On Wed, Mar 25, 2009 at 8:31 PM, David Chelimsky wrote: > Hey all, > > I'd like your feedback on something before I merge it into master. > > Before the 1.2 release I read http://gist.github.com/54177, in which > Ryan Tomayko explains why "require 'rubygems'" should not appear in > your library code. This made some sense to me. So much so, that I > yanked it from rspec for the 1.2 release. > > Then the bug reports started coming in and some conversation led me to > believe that this had been a mistake because it caused pain for the > lion's share of rspec users because most libraries go ahead and > require 'rubygems', so that has become the defacto standard situation, > for better or worse. > > The solution that I added to 1.2.1 was to reinstate "require > 'rubygems'" but with a catch: > > require 'rubygems' unless ENV['NO_RUBYGEMS'] > > This seemed like a fair tradeoff, since it allowed those who didn't > want to have to think about it to just use rspec as/is, and those who > do care and don't use rubygems in any given environment had an out. > > I've just received another report about that decision, with a patch, > that offers what I think is a better solution: > > https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more > > I've pushed Tobias' patch to a require-rubygems branch for the moment. > I'm inclined to merge it into master, but this would the third release > in a row that makes changes to how rspec handles rubygems, and I want > it to be the last. So please let me know your thoughts, for or > against. > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.weirich at gmail.com Wed Mar 25 22:50:47 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 26 Mar 2009 02:50:47 +0000 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote: > require 'rubygems' unless ENV['NO_RUBYGEMS'] This is what I use in Rake: begin require 'rake' rescue LoadError require 'rubygems' require 'rake' end Try without rubygems, then if it fails, try again with rubygems. -- -- Jim Weirich -- jim.weirich at gmail.com From scott at railsnewbie.com Wed Mar 25 22:56:03 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Wed, 25 Mar 2009 22:56:03 -0400 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: <49CAEEC3.5010308@railsnewbie.com> David Chelimsky wrote: > Hey all, > > I'd like your feedback on something before I merge it into master. > > Before the 1.2 release I read http://gist.github.com/54177, in which > Ryan Tomayko explains why "require 'rubygems'" should not appear in > your library code. This made some sense to me. So much so, that I > yanked it from rspec for the 1.2 release. > > Then the bug reports started coming in and some conversation led me to > believe that this had been a mistake because it caused pain for the > lion's share of rspec users because most libraries go ahead and > require 'rubygems', so that has become the defacto standard situation, > for better or worse. > > The solution that I added to 1.2.1 was to reinstate "require > 'rubygems'" but with a catch: > > require 'rubygems' unless ENV['NO_RUBYGEMS'] > How are others normally loading libraries without rubygems? Are most writing wrapper scripts or setting the RUBYOPT environment variable as Ryan points out in his post? Scott > This seemed like a fair tradeoff, since it allowed those who didn't > want to have to think about it to just use rspec as/is, and those who > do care and don't use rubygems in any given environment had an out. > > I've just received another report about that decision, with a patch, > that offers what I think is a better solution: > https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more > > I've pushed Tobias' patch to a require-rubygems branch for the moment. > I'm inclined to merge it into master, but this would the third release > in a row that makes changes to how rspec handles rubygems, and I want > it to be the last. So please let me know your thoughts, for or > against. > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Mar 25 23:04:42 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Mar 2009 22:04:42 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> On Wed, Mar 25, 2009 at 9:50 PM, Jim Weirich wrote: > > On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote: > >> ?require 'rubygems' unless ENV['NO_RUBYGEMS'] > > This is what I use in Rake: > > begin > ?require 'rake' > rescue LoadError > ?require 'rubygems' > ?require 'rake' > end > > Try without rubygems, then if it fails, try again with rubygems. That's essentially what's happening in this branch, though it's wrapped in a method to reduce duplication. One question I have about this approach is the impact it has on someone who doesn't have the gem installed. Unlikely with rake, but with something like diff-lcs, which rspec uses *if* you ask it to present results with diffs, it is more likely. So: begin require 'diff-lcs' rescue LoadError require 'rubygems' require 'diff-lcs' end If I don't have diff-lcs installed, now rubygems will be loaded. Is that a situation that would screw up those among us who use an alternative gem management system? Or does that matter, since they're trying to use something they don't have installed either way. Sorry if this all seems pedantic. I just want to get this right. Cheers, David > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Mar 25 23:07:20 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Mar 2009 22:07:20 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <49CAEEC3.5010308@railsnewbie.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <49CAEEC3.5010308@railsnewbie.com> Message-ID: <57c63afe0903252007l321e1350i98f9e90ca2b3b425@mail.gmail.com> On Wed, Mar 25, 2009 at 9:56 PM, Scott Taylor wrote: > David Chelimsky wrote: >> >> Hey all, >> >> I'd like your feedback on something before I merge it into master. >> >> Before the 1.2 release I read http://gist.github.com/54177, in which >> Ryan Tomayko explains why "require 'rubygems'" should not appear in >> your library code. This made some sense to me. So much so, that I >> yanked it from rspec for the 1.2 release. >> >> Then the bug reports started coming in and some conversation led me to >> believe that this had been a mistake because it caused pain for the >> lion's share of rspec users because most libraries go ahead and >> require 'rubygems', so that has become the defacto standard situation, >> for better or worse. >> >> The solution that I added to 1.2.1 was to reinstate "require >> 'rubygems'" but with a catch: >> >> ?require 'rubygems' unless ENV['NO_RUBYGEMS'] >> > > How are others normally loading libraries without rubygems? ?Are most > writing wrapper scripts or setting the RUBYOPT environment variable as Ryan > points out in his post? The problem w/ RUBYOPT is that it means that rubygems is always loaded even if you don't need it. At least that's the problem that's been expressed to me. I don't have a problem with that myself because pretty much everything I do depends on other gems. FWIW, David > > Scott > > >> This seemed like a fair tradeoff, since it allowed those who didn't >> want to have to think about it to just use rspec as/is, and those who >> do care and don't use rubygems in any given environment had an out. >> >> I've just received another report about that decision, with a patch, >> that offers what I think is a better solution: >> >> https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more >> >> I've pushed Tobias' patch to a require-rubygems branch for the moment. >> I'm inclined to merge it into master, but this would the third release >> in a row that makes changes to how rspec handles rubygems, and I want >> it to be the last. So please let me know your thoughts, for or >> against. >> >> Thanks, >> David >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mike at vincent.ws Wed Mar 25 23:31:19 2009 From: mike at vincent.ws (Mike Vincent) Date: Wed, 25 Mar 2009 22:31:19 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: <2386bfa00903252031i79108954xcccee91f32c70fb7@mail.gmail.com> On Wed, Mar 25, 2009 at 9:50 PM, Jim Weirich wrote: > > On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote: > >> ?require 'rubygems' unless ENV['NO_RUBYGEMS'] > > This is what I use in Rake: > > begin > ?require 'rake' > rescue LoadError > ?require 'rubygems' > ?require 'rake' > end > > Try without rubygems, then if it fails, try again with rubygems. I always liked a similar idiom using retry since the require will return true the first time it's successful begin require 'rake' rescue LoadError retry if require 'rubygems' end From mark at mwilden.com Thu Mar 26 00:09:33 2009 From: mark at mwilden.com (Mark Wilden) Date: Wed, 25 Mar 2009 21:09:33 -0700 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> Message-ID: <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> I think this whole thing is a tempest in a teapot. What are the actual, real-world disadvantages of "require 'rubygems'"? Here's what Ryan says: Why You Shouldn't Force Rubygems On People ------------------------------------------ When I use your library, deploy your app, or run your tests I may not want to use rubygems. When you "require 'rubygems'" in your code, you remove my ability to make that decision. I cannot unrequire rubygems, but you can not require it in the first place. This sounds like more of a libertarian/philosophical rationale than something that I should spend any time worrying about. So require rubygems or don't require it - it doesn't matter to me (or anyone I know) because I have rubygems installed. So do 99% of Rails users, I'm willing to bet. As for frequent releases, I don't think there's anything wrong with that. That's the agile way - you release something, see what the reaction is, change it, lather, maybe get soap in your eyes, rinse, and repeat. No one's going to remember version 1.2.326 in six months, anyway. ///ark (Anyone figure out why there are so many Ryans on Rails?) From dchelimsky at gmail.com Thu Mar 26 00:33:25 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Mar 2009 23:33:25 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> Message-ID: <57c63afe0903252133v3ac94b3cj47409f9458d1809c@mail.gmail.com> On Wed, Mar 25, 2009 at 11:09 PM, Mark Wilden wrote: > I think this whole thing is a tempest in a teapot. > > What are the actual, real-world disadvantages of "require 'rubygems'"? > Here's what Ryan says: > > ?Why You Shouldn't Force Rubygems On People > ?------------------------------------------ > ?When I use your library, deploy your app, or run your tests I may not want > ?to use rubygems. When you "require 'rubygems'" in your code, you remove my > ?ability to make that decision. I cannot unrequire rubygems, but you can > ?not require it in the first place. > > This sounds like more of a libertarian/philosophical rationale than > something that I should spend any time worrying about. > > So require rubygems or don't require it - it doesn't matter to me (or > anyone I know) because I have rubygems installed. So do 99% of Rails > users, I'm willing to bet. FWIW, I actually think he's got a legitimate point. It's one thing to make things easier for the majority, but it's another to tie the hands of the minority in the process. We should find a way to do it that keeps options open for alternatives. > As for frequent releases, I don't think there's anything wrong with > that. That's the agile way - you release something, see what the > reaction is, change it, lather, maybe get soap in your eyes, rinse, > and repeat. No one's going to remember version 1.2.326 in six months, > anyway. You haven't been using rspec that long, have you :) History proves that I have NO problem with frequent releases. What I do have a problem with is saying "A, no, now B, now back to A, oops - let's try "C" - all around one issue that has an impact on users. > > ///ark > > (Anyone figure out why there are so many Ryans on Rails?) How about all the ///arks? Cheers, David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mark at mwilden.com Thu Mar 26 02:26:11 2009 From: mark at mwilden.com (Mark Wilden) Date: Wed, 25 Mar 2009 23:26:11 -0700 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903252133v3ac94b3cj47409f9458d1809c@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> <57c63afe0903252133v3ac94b3cj47409f9458d1809c@mail.gmail.com> Message-ID: <3c30da400903252326u7c1b697ew4c246325eba6f689@mail.gmail.com> On Wed, Mar 25, 2009 at 9:33 PM, David Chelimsky wrote: > > FWIW, I actually think he's got a legitimate point. It's one thing to > make things easier for the majority, but it's another to tie the hands > of the minority in the process. We should find a way to do it that > keeps options open for alternatives. I don't disagree with that. If there's a solid idiom for accomodating these users, you might as well add the three or four lines of code it takes to make them happy. I was really just commenting on the vehemence of the viewpoint, that it seemed to me was unsubstantiated by any pragmatic (as opposed to political) concern. However, there's not going to be any hands-tieing either way. Forking a library, or even simply editing it in situ, is not the end of the world. But I'd be interested to know just how many users there are out there who haven't installed ruby-gems (including Ryan). > What I do have a problem with is saying "A, no, now B, now back to A, > oops - let's try "C" - all around one issue that has an impact on > users. Hey, I do that all the time with my users. :) RSpec admittedly does have a somewhat larger installed base. ///ark From jim.weirich at gmail.com Thu Mar 26 04:08:03 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 26 Mar 2009 08:08:03 +0000 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> Message-ID: <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote: > That's essentially what's happening in this branch, though it's > wrapped in a method to reduce duplication. Duplication? How many places need to do this? Seems to me that any libraries don't need this. By the time the libraries are loading, rubygems should already be loaded (otherwise the libraries wouldn't have been found). I only put this in the top level application code. One place. At least this is true for rake. Is rspec different? -- -- Jim Weirich -- jim.weirich at gmail.com From peter.fitzgibbons at gmail.com Thu Mar 26 06:49:36 2009 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Thu, 26 Mar 2009 05:49:36 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> Message-ID: <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> On Thu, Mar 26, 2009 at 3:08 AM, Jim Weirich wrote: > > On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote: > > That's essentially what's happening in this branch, though it's >> wrapped in a method to reduce duplication. >> > > Duplication? How many places need to do this? > > Seems to me that any libraries don't need this. By the time the libraries > are loading, rubygems should already be loaded (otherwise the libraries > wouldn't have been found). > > I only put this in the top level application code. One place. > > At least this is true for rake. Is rspec different? I'm with you. Also this seems to also be taken care of through RUBYOPT, no? Peter Fitzgibbons Email: peter.fitzgibbons at gmail.com > > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Thu Mar 26 07:04:04 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Mar 2009 07:04:04 -0400 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> Message-ID: <57c63afe0903260404r37587e71vef4815ad85771745@mail.gmail.com> On Thu, Mar 26, 2009 at 4:08 AM, Jim Weirich wrote: > > On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote: > >> That's essentially what's happening in this branch, though it's >> wrapped in a method to reduce duplication. > > Duplication? ?How many places need to do this? > > Seems to me that any libraries don't need this. ?By the time the libraries > are loading, rubygems should already be loaded (otherwise the libraries > wouldn't have been found). > > I only put this in the top level application code. ?One place. > > At least this is true for rake. ?Is rspec different? There are several cases of libraries that rspec only needs to load with certain command line options. These libraries get loaded by rspec's options before any of *your* files are loaded, so even if you require 'rubygems' from a spec_helper it won't happen until after we need those files. We could, of course, change that strategy to reduce this duplication, but that would require a fair bit more re-thinking than needs happen before this issue is decided. > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Thu Mar 26 07:12:22 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Mar 2009 07:12:22 -0400 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> Message-ID: <57c63afe0903260412j3f9439f0v92fd07af0bb42b84@mail.gmail.com> 2009/3/26 Peter Fitzgibbons : > > On Thu, Mar 26, 2009 at 3:08 AM, Jim Weirich wrote: >> >> On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote: >> >>> That's essentially what's happening in this branch, though it's >>> wrapped in a method to reduce duplication. >> >> Duplication? ?How many places need to do this? >> >> Seems to me that any libraries don't need this. ?By the time the libraries >> are loading, rubygems should already be loaded (otherwise the libraries >> wouldn't have been found). >> >> I only put this in the top level application code. ?One place. >> >> At least this is true for rake. ?Is rspec different? > > I'm with you.? Also this seems to also be taken care of through RUBYOPT, no? Setting RUBYOPT means that all of your programs always load the rubygems machinery even if you're not using rubygems. While I realize that most of us use gems in nearly all (if not 100%) of our projects, I think there is a case for saying "don't make me load rubygems unless I need it" that is equally as strong as "don't force me to use rubygems as my gem-loading strategy." David > > > Peter Fitzgibbons > Email: peter.fitzgibbons at gmail.com > > >> >> -- >> -- Jim Weirich >> -- jim.weirich at gmail.com >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From peter.fitzgibbons at gmail.com Thu Mar 26 07:24:27 2009 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Thu, 26 Mar 2009 06:24:27 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <57c63afe0903260412j3f9439f0v92fd07af0bb42b84@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> <57c63afe0903260412j3f9439f0v92fd07af0bb42b84@mail.gmail.com> Message-ID: <670a00380903260424y4da96fdeu7ed169c1d843441b@mail.gmail.com> On Thu, Mar 26, 2009 at 6:12 AM, David Chelimsky wrote: > 2009/3/26 Peter Fitzgibbons : > > > >> > >> Seems to me that any libraries don't need this. By the time the > libraries > >> are loading, rubygems should already be loaded (otherwise the libraries > >> wouldn't have been found). > >> > >> I only put this in the top level application code. One place. > >> > >> At least this is true for rake. Is rspec different? > > > > I'm with you. Also this seems to also be taken care of through RUBYOPT, > no? > > Setting RUBYOPT means that all of your programs always load the > rubygems machinery even if you're not using rubygems. While I realize > that most of us use gems in nearly all (if not 100%) of our projects, > I think there is a case for saying "don't make me load rubygems unless > I need it" that is equally as strong as "don't force me to use > rubygems as my gem-loading strategy." Yes, I agree. My arrow missed the target. I was trying to say, those who need rubygems, as Ryan points out, should be using RUBYOPT or calling require 'rubygems' somewhere above "any" library. I'm with Ryan that as a maintainer, you should be "above" the use of rubygems (as a rails user, I also understand the pain that entails). Peter Fitzgibbons Email: peter.fitzgibbons at gmail.com > > David > > > > > > > Peter Fitzgibbons > > Email: peter.fitzgibbons at gmail.com > > > > > >> > >> -- > >> -- Jim Weirich > >> -- jim.weirich at gmail.com > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From listaccount at e-tobi.net Thu Mar 26 07:28:16 2009 From: listaccount at e-tobi.net (Tobias Grimm) Date: Thu, 26 Mar 2009 04:28:16 -0700 (PDT) Subject: [rspec-devel] re quire 'rubygems' In-Reply-To: <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> Message-ID: <22720122.post@talk.nabble.com> Mark Wilden wrote: > > So require rubygems or don't require it - it doesn't matter to me (or > anyone I know) because I have rubygems installed. So do 99% of Rails > users, I'm willing to bet. > You're right. But there are scenarios, where rubygems just is not needed. >From a Debian Developers point of view, there is no reason for most packaged Ruby applications or libs to depend on rubygems, because any dependencies must be available as a Debian package anyway. It's not a problem to just strip the "require 'rubygems'" in the Debian package, but I prefer to push such changes upstream. My patch that David put into the require-rubygems branch, is just a compromise - load a library if available, if no try it with rubygems. (But I prefer Mike's proposal with the "retry" statement - haven't thought of this one...) In general and from a software developers point of view, I don't think RSpec should require rubygems anywhere in it's libraries (!) at all! RSpec needs heckle and diff-lcs, not rubygems. RSpec shouldn't be aware from where and how external libraries it doesn't ship need to be loaded. This is an end-user issue and should be dealed with at the end-user level. This means RUBYOPTS or the bin/spec executable. Just my two cent.... Tobias -- View this message in context: http://www.nabble.com/require-%27rubygems%27-tp22714532p22720122.html Sent from the rspec-devel mailing list archive at Nabble.com. From joahking at gmail.com Thu Mar 26 07:47:42 2009 From: joahking at gmail.com (Joaquin Rivera Padron) Date: Thu, 26 Mar 2009 12:47:42 +0100 Subject: [rspec-devel] re quire 'rubygems' In-Reply-To: <22720122.post@talk.nabble.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <3c30da400903252109s2ced2c2cu2615d6fbd9361619@mail.gmail.com> <22720122.post@talk.nabble.com> Message-ID: <8277b7f40903260447tb708c1cm1a720c424355ebd9@mail.gmail.com> I might be wrong, but ain't that in Ruby 1.9 the require rubygems will be done by ruby itself? also, are RSpec gems ready to use other options than rubygems (minigems I guess is a faster choice around there)? cheers, joaquin -------------- next part -------------- An HTML attachment was scrubbed... URL: From luislavena at gmail.com Thu Mar 26 09:07:50 2009 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 26 Mar 2009 10:07:50 -0300 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <670a00380903260424y4da96fdeu7ed169c1d843441b@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> <57c63afe0903260412j3f9439f0v92fd07af0bb42b84@mail.gmail.com> <670a00380903260424y4da96fdeu7ed169c1d843441b@mail.gmail.com> Message-ID: <71166b3b0903260607h656e2e79x38ca0a8c57c7c6ac@mail.gmail.com> 2009/3/26 Peter Fitzgibbons : > > On Thu, Mar 26, 2009 at 6:12 AM, David Chelimsky > wrote: >> >> 2009/3/26 Peter Fitzgibbons : >> > >> >> >> >> Seems to me that any libraries don't need this. ?By the time the >> >> libraries >> >> are loading, rubygems should already be loaded (otherwise the libraries >> >> wouldn't have been found). >> >> >> >> I only put this in the top level application code. ?One place. >> >> >> >> At least this is true for rake. ?Is rspec different? >> > >> > I'm with you.? Also this seems to also be taken care of through RUBYOPT, >> > no? >> >> Setting RUBYOPT means that all of your programs always load the >> rubygems machinery even if you're not using rubygems. While I realize >> that most of us use gems in nearly all (if not 100%) of our projects, >> I think there is a case for saying "don't make me load rubygems unless >> I need it" that is equally as strong as "don't force me to use >> rubygems as my gem-loading strategy." > > Yes, I agree.? My arrow missed the target.? I was trying to say, those who > need rubygems, as Ryan points out, should be using RUBYOPT or calling > require 'rubygems' somewhere above "any" library.? I'm with Ryan that as a > maintainer, you should be "above" the use of rubygems (as a rails user, I > also understand the pain that entails). > RUBYOPT is not the solution. I've faced and replied to lot (more than 20) emails and support requests about RUBYOPT being set or not in One-Click Installer. Also, the change of no rubygems all across rspec broke color output when called form autospec, that is because it calls directly to ruby with the direct binary script, not using RubyGems load machinery. So, while I can agree with Ryan point on having rubygems in your library or specs is wrong, sometimes is needed. Extreme purism is not a solution. If someone is complaining on something I'm doing wrong, please provide me a patch that doesn't break my normal usage (or other hundred users). Is hard to split between rspec and the libraries it depends on, even harder for the user to trace what happened between the version of your library that supposed to be working on previous releases. Sorry for being so stubborn. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From peter.fitzgibbons at gmail.com Fri Mar 27 13:52:01 2009 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Fri, 27 Mar 2009 12:52:01 -0500 Subject: [rspec-devel] require 'rubygems' In-Reply-To: <71166b3b0903260607h656e2e79x38ca0a8c57c7c6ac@mail.gmail.com> References: <57c63afe0903251831n76caa509w9c57b1e3d304c290@mail.gmail.com> <57c63afe0903252004x1624b772y5babd139bbd993b0@mail.gmail.com> <49DE9C3C-1085-44EC-B8D5-B01E3D1F04D3@gmail.com> <670a00380903260349h7e5cdacdm224b077c9bf53bb5@mail.gmail.com> <57c63afe0903260412j3f9439f0v92fd07af0bb42b84@mail.gmail.com> <670a00380903260424y4da96fdeu7ed169c1d843441b@mail.gmail.com> <71166b3b0903260607h656e2e79x38ca0a8c57c7c6ac@mail.gmail.com> Message-ID: <670a00380903271052x394fcb8kb0ce2677d79a4a4f@mail.gmail.com> David, Just want to point out, if you didn't think of it already (I'm expecting you did) activesupport-2.3.2/lib/active_support/core_ext/kernel.rb#require_library_or_gem looks like a nice complete example. I am not suggesting dependency on activesupport... more stealing a well-honed example. Regards, Peter Fitzgibbons (847) 687-7646 Email: peter.fitzgibbons at gmail.com IM GTalk: peter.fitzgibbons IM Yahoo: pjfitzgibbons IM MSN: pjfitzgibbons at hotmail.com IM AOL: peter.fitzgibbons at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Sun Mar 29 13:16:13 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Mar 2009 13:16:13 -0400 Subject: [rspec-devel] matcher dsl Message-ID: <57c63afe0903291016i5b1b209esdf9977c1fab363c2@mail.gmail.com> Hey all, rspec-1.2.0 introduced a new matcher DSL, which lets you define a matcher like this: Spec::Matchers.create :be_a_multiple_of do |expected| match do |actual| actual % expected == 0 end end This defines a matcher that you can use in an example like this: 25.should be_a_multiple_of(5) It occurs to me that "Spec::Matchers.create" is not the most intuitive entry point. We're not defining Matchers (plural), nor are we really creating anything at the point of declaration. So I'm thinking of changing it (still supporting the original for now) to "Spec.matcher" or "Spec.define_matcher", or something similar. Anybody have any suggestions? My only restriction for the moment is that it should not be top level (i.e. define_matcher with no scoping). Thanks, David From scott at railsnewbie.com Sun Mar 29 15:02:03 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Sun, 29 Mar 2009 15:02:03 -0400 Subject: [rspec-devel] matcher dsl In-Reply-To: <57c63afe0903291016i5b1b209esdf9977c1fab363c2@mail.gmail.com> References: <57c63afe0903291016i5b1b209esdf9977c1fab363c2@mail.gmail.com> Message-ID: <49CFC5AB.6010001@railsnewbie.com> David Chelimsky wrote: > Hey all, > > rspec-1.2.0 introduced a new matcher DSL, which lets you define a > matcher like this: > > Spec::Matchers.create :be_a_multiple_of do |expected| > match do |actual| > actual % expected == 0 > end > end > Spec::Matcher.define or Spec::Matcher.create is fine with me. It would only take "aliasing" the constant: module Spec module Matchers ... end Matcher = Matchers end Scott > This defines a matcher that you can use in an example like this: > > 25.should be_a_multiple_of(5) > > It occurs to me that "Spec::Matchers.create" is not the most intuitive > entry point. We're not defining Matchers (plural), nor are we really > creating anything at the point of declaration. > > So I'm thinking of changing it (still supporting the original for now) > to "Spec.matcher" or "Spec.define_matcher", or something similar. > Anybody have any suggestions? My only restriction for the moment is > that it should not be top level (i.e. define_matcher with no scoping). > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From zach.dennis at gmail.com Mon Mar 30 10:19:49 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Mon, 30 Mar 2009 10:19:49 -0400 Subject: [rspec-devel] matcher dsl In-Reply-To: <57c63afe0903291016i5b1b209esdf9977c1fab363c2@mail.gmail.com> References: <57c63afe0903291016i5b1b209esdf9977c1fab363c2@mail.gmail.com> Message-ID: <85d99afe0903300719h2ef923d0ua026df83f954f8e6@mail.gmail.com> On Sun, Mar 29, 2009 at 1:16 PM, David Chelimsky wrote: > Hey all, > > rspec-1.2.0 introduced a new matcher DSL, which lets you define a > matcher like this: > > ? ? ?Spec::Matchers.create :be_a_multiple_of do |expected| > ? ? ? ?match do |actual| > ? ? ? ? ?actual % expected == 0 > ? ? ? ?end > ? ? ?end > > This defines a matcher that you can use in an example like this: > > ?25.should be_a_multiple_of(5) > > It occurs to me that "Spec::Matchers.create" is not the most intuitive > entry point. We're not defining Matchers (plural), nor are we really > creating anything at the point of declaration. > > So I'm thinking of changing it (still supporting the original for now) > to "Spec.matcher" or "Spec.define_matcher", or something similar. > Anybody have any suggestions? My only restriction for the moment is > that it should not be top level (i.e. define_matcher with no scoping). I don't like the idea of top-level either. Personally I prefer Spec::Matcher.define over Spec.define_matcher, but Spec.define_matcher is better than Spec.matcher or Spec::Matchers.create. It would be nice if you could do multiple matchers in one-swipe, only having to rely on the namespace once. For example, I have a matchers.rb file which houses the misc simple matchers for a project. It'd be nice to say something like: Spec::Matchers.define do define :be_a_multiple_of do # .. end define :be_something_else do # ... end #... end I don't know how other folks organize their simple matchers though, > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From drnicwilliams at gmail.com Sat Mar 21 19:12:06 2009 From: drnicwilliams at gmail.com (Dr Nic Williams) Date: Sun, 22 Mar 2009 07:12:06 +0800 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> Message-ID: <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> > I'm hoping the Following TODOs from Cucumber.tmbundle can use this: > > Goto step definition from feature file. Currently works with Shift+Alt+Cmd+Down > From a step definition be able to pull up a list of features using that step > and to jump to them. Yeah I want this too. From drnicwilliams at gmail.com Sat Mar 21 19:39:22 2009 From: drnicwilliams at gmail.com (Dr Nic Williams) Date: Sun, 22 Mar 2009 07:39:22 +0800 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> Message-ID: <44b555bb0903211639l70bea7b3pe59a4490600b5689@mail.gmail.com> Sorry, it is Shift+Ctrl+Alt+Down On Sun, Mar 22, 2009 at 7:12 AM, Dr Nic Williams wrote: >> I'm hoping the Following TODOs from Cucumber.tmbundle can use this: >> >> Goto step definition from feature file. > > Currently works with Shift+Alt+Cmd+Down > >> From a step definition be able to pull up a list of features using that step >> and to jump to them. > > Yeah I want this too. > -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ * From drnicwilliams at gmail.com Sat Mar 21 21:04:25 2009 From: drnicwilliams at gmail.com (Dr Nic Williams) Date: Sun, 22 Mar 2009 09:04:25 +0800 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> Message-ID: <44b555bb0903211804l190610f9k65d649481d9fcc05@mail.gmail.com> There is an internal data structure generated by eval'ing the step files; we'll switch out the eval => cucumber --step-definitions call, but the data structures will stay so it will 90% be the same code. On Sun, Mar 22, 2009 at 7:59 AM, aslak hellesoy wrote: > > > On Sat, Mar 21, 2009 at 7:12 PM, Dr Nic Williams > wrote: >> >> > I'm hoping the Following TODOs from Cucumber.tmbundle can use this: >> > >> > Goto step definition from feature file. >> >> Currently works with Shift+Alt+Cmd+Down > > Yes, but that is based on code in the bundle right? Isn't it better to use > "official" Cucumber code for this? > > Aslak > >> >> > From a step definition be able to pull up a list of features using that >> > step >> > and to jump to them. >> >> Yeah I want this too. > > -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ * From drnicwilliams at gmail.com Sun Mar 22 01:34:33 2009 From: drnicwilliams at gmail.com (Dr Nic Williams) Date: Sun, 22 Mar 2009 13:34:33 +0800 Subject: [rspec-devel] [Cucumber] new usage formatter In-Reply-To: <8d961d900903212145y16f88b80k1b8c0b65b555caee@mail.gmail.com> References: <8d961d900903211238k2fbd84c2ic110d369309e46d2@mail.gmail.com> <44b555bb0903211612r546819e2g454ca0917ba0b064@mail.gmail.com> <8d961d900903211659u152a0e08rbe6360bd142d4520@mail.gmail.com> <49C5AF98.2010008@benmabey.com> <8d961d900903212145y16f88b80k1b8c0b65b555caee@mail.gmail.com> Message-ID: <44b555bb0903212234xb8c5483m9759e410ab0411c9@mail.gmail.com> Try using the code we have in the bundle for fake loading + evaling :) On Sun, Mar 22, 2009 at 12:45 PM, aslak hellesoy wrote: > > > On Sat, Mar 21, 2009 at 11:25 PM, Ben Mabey wrote: >> >> aslak hellesoy wrote: >>> >>> >>> On Sat, Mar 21, 2009 at 7:12 PM, Dr Nic Williams >> > wrote: >>> >>> ? ?> I'm hoping the Following TODOs from Cucumber.tmbundle can use this: >>> ? ?> >>> ? ?> Goto step definition from feature file. >>> >>> ? ?Currently works with Shift+Alt+Cmd+Down >>> >>> >>> Yes, but that is based on code in the bundle right? Isn't it better to >>> use "official" Cucumber code for this? >>> >>> Aslak >> >> +1. ?I think we should keep as much functionality in Cucumber so other >> editors can leverage the functionality. >>> >>> >>> ? ?> From a step definition be able to pull up a list of features >>> ? ?using that step >>> ? ?> and to jump to them. >>> >>> ? ?Yeah I want this too. >>> >>> >> I'm going to take a stab at this now with the new usage formatter- very >> nice! ?I think the biggest drawback to this will be speed. ?For example, >> doing a dry-run on cucumber's own features takes ~2 seconds. ?For a rails >> project loading up the entire environment I think this would be too slow to >> wait for everytime. ?Any ideas on a caching strategy? ?Storing a cached >> version of the output is easy enough, but knowing when to expire the cache >> is somewhat tricky... > > Or maybe we could optimise. The support files don't have to be loaded, nor > do we need to instantiate a full AST (mulitline args can be skipped). > > I'll try out a few things. I'm sure we can make it perform reasonably well. > > Aslak > >> >> -Ben > > -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ *