From dchelimsky at gmail.com  Wed Jul  2 23:57:23 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 22:57:23 -0500
Subject: [rspec-devel] release 1.1.5 coming soon
Message-ID: <3AFC4127-94A9-4629-A499-BF451BEC8267@gmail.com>

Hey all,

Just a heads up that I'm getting ready to release rspec-1.1.5 some  
time in the next few days - maybe sooner :)

There are some bug fixes, some new features, and Aslak was just over  
here helping me switch from about 200 lines of custom rake tasks to  
more like 10 lines of hoe-ness :)

Cheers,
David



From bryansray at gmail.com  Thu Jul  3 02:12:57 2008
From: bryansray at gmail.com (Bryan Ray)
Date: Thu, 3 Jul 2008 01:12:57 -0500
Subject: [rspec-devel] New rspec.rake require files do not exist
Message-ID: <9717A207-AA20-409C-8B1A-CD6BCD6DA6A5@gmail.com>

The latest github code will produce a file called rspec.rake and place  
it in your #{RAILS_ROOT}/lib/tasks/rspec.rake directory. My initial  
problem was that if the 'tasks' directory did not exist then the file  
would just not be created. David Chelimsky simply added in a check for  
the directory and fixed it very quickly and everything works fine now,  
but now I'm running in to another problem.

In the rspec.rake file on lines 9 and 10 you'll see:

require 'spec/rake/spectask'
require 'spec/translator'

This does not want to load for me as those files do not exist in that  
location (unless I'm doing something completely wrong?). It seemed  
like an easy enough 'fix' (for me to get my specs running) ... I  
simply change the lines to read:

require "vendor/plugins/rspec/lib/spec/rake/spectask"
require 'vendor/plugins/rspec/lib/spec/translator'

Obviously this fix doesn't 'feel' right, but I figured I would just  
create the ticket and follow the outcome.

Thanks, guys.

From dchelimsky at gmail.com  Fri Jul  4 16:45:48 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 4 Jul 2008 15:45:48 -0500
Subject: [rspec-devel] auto-generated descriptions
Message-ID: <EB33D91D-6D28-42AB-9E21-03AED32EEF64@gmail.com>

Hey all,

I'm looking for ways to optimize rspec and came upon something  
interesting. If I remove handling for auto-generated descriptions (the  
thing that allows you to say "specify { 5.should == 5 }" with no  
description string) we get an average 35% performance increase per  
expectation. 35%. That's huge.

So - how bad do you think this would suck to remove that feature? Are  
you using it yourself?

All thoughts welcome.

Thanks,
David

From pergesu at gmail.com  Fri Jul  4 18:20:21 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 4 Jul 2008 15:20:21 -0700
Subject: [rspec-devel] auto-generated descriptions
In-Reply-To: <EB33D91D-6D28-42AB-9E21-03AED32EEF64@gmail.com>
References: <EB33D91D-6D28-42AB-9E21-03AED32EEF64@gmail.com>
Message-ID: <810a540e0807041520x3691ce1ft3b114157bd47af40@mail.gmail.com>

On Fri, Jul 4, 2008 at 1:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hey all,
>
> I'm looking for ways to optimize rspec and came upon something interesting.
> If I remove handling for auto-generated descriptions (the thing that allows
> you to say "specify { 5.should == 5 }" with no description string) we get an
> average 35% performance increase per expectation. 35%. That's huge.
>
> So - how bad do you think this would suck to remove that feature? Are you
> using it yourself?
>
> All thoughts welcome.

To be clear, this is for taking a spec like:

it { 2.should == 2 }

and then when running with the specdoc formatter, getting

- should == 2

I personally don't use specdoc format very often anyway.  My intuition
is that writing specs without a description (which I frequently use)
is optimized for programmer clarity, so auto-generating a description
for it is less important.  I understand that the description would be
used in a number of other places, including error messages, but in the
case of error messages I just use line numbers.

Basically, auto-generating descriptions are valuable, but fall way
short of withholding a 35% performance improvement.

Pat

From matt-lists at reprocessed.org  Wed Jul  9 17:24:40 2008
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Wed, 9 Jul 2008 22:24:40 +0100
Subject: [rspec-devel] Trying to figure out how the it_should_behave_like
	"sandboxed rspec_options" works
Message-ID: <CB81B8F7-CE6C-4578-94A6-ACC49C5969D8@reprocessed.org>

Hey all

I've had a bit of time to develop the start I made on ticket 373 over  
at lighthouse: http://is.gd/Px9. I started to swap in an analogous  
system to the stubbable separate spec collector for options. The rough  
idea is that you'd then just stub out Spec.options and return a  
sparkly new Spec::Runner::Options object instead of the  
it_should_behave_like "sandboxed rspec_options" global variable swap.  
So far so good, but I started to see sample example groups from the  
specs (i.e. @example_group = Class.new(ExampleGroup} { describe('does  
nothing'); it("should do x") { x.should == y } }) being run and  
reported as failures by the main spec run. Clearly, something's  
leaking out...

Worse than that, the specs for a _spec.rb file got run, but the output  
said 0 specs, 0 passed. There was still plain text formmatter output,  
but my guess is that was from my stubbed Spec::Runner::Options which  
fell back to progress format and no ANSI color...

Notionally, there was a pretty simple swap - Spec.options - a function  
lifted from rspec_options in all but its use of a global variable,  
plus stubbing it where the sanboxed rspec_options trick had been used  
before was having radically different effects. Which means that my  
understanding of that part of the system is really flawed, I guess...

Would someone be willing to talk me through the way that Spec  
collection and the describe class creation stuff really works? In  
return I promise to draw pictures of it and write it up. I'll also try  
and fix some of the tedious long-lived bugs (like typos and stuff) to  
reduce the open bug count in lighthouse...

Thanks!

Matt

-- 
   Matt Patterson | Design & Code
   <matt at reprocessed org> | http://www.reprocessed.org/




From matt-lists at reprocessed.org  Wed Jul  9 17:27:55 2008
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Wed, 9 Jul 2008 22:27:55 +0100
Subject: [rspec-devel] Figuring out which open bugs to try and fix
Message-ID: <98E5B125-24BD-425D-A307-4A138D222402@reprocessed.org>

I thought I'd have a go at some of the outstanding bugs. My biggest  
problem is figuring out which of them is worth tackling. Does this  
make sense for a process?

1) Identify a bug which has been marked 'open' by someone on core team  
that looks like I could fix it
2) leave a comment offering to work on it
3) person it's assigned to leaves a comment saying that's alright
4) I work on it and submit a patch / github commit url...

Enough dumb questions from me for one night...

Thanks,

Matt


-- 
   Matt Patterson | Design & Code
   <matt at reprocessed org> | http://www.reprocessed.org/




From cgrindel at yahoo.com  Fri Jul 11 14:33:20 2008
From: cgrindel at yahoo.com (Charles Grindel)
Date: Fri, 11 Jul 2008 11:33:20 -0700 (PDT)
Subject: [rspec-devel] Getting RSpec 1.1.4+ to Work with Autotest (ZenTest
	3.10.0) on Windows (Win32)
Message-ID: <841120.80434.qm@web54110.mail.re2.yahoo.com>

Hi,

After upgrading to Rails 2.1, RSpec 1.1.4+ and ZenTest 3.10.0, autotest would no longer find any of my specs on my Windows development machine.  Some Googling directed me to a very recent update in the History.txt file for rspec-fails:

IMPORTANT: use 'script/autospec' (or just 'autospec' if you have the rspec gem
installed) instead of 'autotest'. We changed the way autotest discovers rspec
so the autotest executable won't automatically load rspec anymore. This allows
rspec to live side by side other spec frameworks without always co-opting
autotest through autotest's discovery mechanism.

My project is running RSpec and Rspec-rails as plugins, but I gave it a shot.  Unfortunately, autotest would not even start.  A quick inspection of autospec revealed that the call to autotest in this file will not work on Windows, as is.  In the Windows environment, autotest is a batch file which must be executed with the "call" command when shelling out from a Ruby script.  So, I updated my autospec file to the following:

#!/usr/bin/env ruby
ENV['RSPEC'] = 'true'
autotest_cmd = 'autotest'
autotest_cmd = "call #{autotest_cmd}" if RUBY_PLATFORM =~ /mswin/
system autotest_cmd

I have submitted a ticket requesting that autospec be updated accordingly.

http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/466-update-autospec-to-work-on-windows

Thanks,
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080711/1f05ef4f/attachment.html>

From cgrindel at yahoo.com  Sun Jul 13 17:50:55 2008
From: cgrindel at yahoo.com (Charles Grindel)
Date: Sun, 13 Jul 2008 14:50:55 -0700 (PDT)
Subject: [rspec-devel] [rspec-users] Getting RSpec 1.1.4+ to Work with
	Autotest (ZenTest 3.10.0) on Windows (Win32)
Message-ID: <506754.80820.qm@web54101.mail.re2.yahoo.com>

Hi,

Thanks for the info, Luis.  I am glad that they fixed the calling a batch file issue.  I have had to handle this myself in several different situations.

I do have one additional question.  It sounds like your setup is very similar to ours.  Is your project new or did you upgrade?  Do you run autospec or autotest from the command line?  It seems like running autotest directly should still work given the history comment, but I could not get things to fly until I started using autospec.  Just curious.

Thanks,
Chuck


----- Original Message ----
From: Luis Lavena <luislavena at gmail.com>
To: rspec-users <rspec-users at rubyforge.org>
Cc: RSpec Developers Mailing List <rspec-devel at rubyforge.org>
Sent: Friday, July 11, 2008 3:29:04 PM
Subject: Re: [rspec-users] Getting RSpec 1.1.4+ to Work with Autotest (ZenTest 3.10.0) on Windows (Win32)

On Fri, Jul 11, 2008 at 8:33 PM, Charles Grindel <cgrindel at yahoo.com> wrote:
> Hi,
>
> After upgrading to Rails 2.1, RSpec 1.1.4+ and ZenTest 3.10.0, autotest
> would no longer find any of my specs on my Windows development machine.
> Some Googling directed me to a very recent update in the History.txt file
> for rspec-fails:
>
> IMPORTANT: use 'script/autospec' (or just 'autospec' if you have the rspec
> gem
> installed) instead of 'autotest'. We changed the way autotest discovers
> rspec
> so the autotest executable won't automatically load rspec anymore. This
> allows
> rspec to live side by side other spec frameworks without always co-opting
> autotest through autotest's discovery mechanism.
>

Dunno if this funny, but I'm running right now with the exact same
combination of components and autotest picks my updated spec and files
(even the ones in lib).

> My project is running RSpec and Rspec-rails as plugins, but I gave it a
> shot.  Unfortunately, autotest would not even start.  A quick inspection of
> autospec revealed that the call to autotest in this file will not work on
> Windows, as is.  In the Windows environment, autotest is a batch file which
> must be executed with the "call" command when shelling out from a Ruby
> script.  So, I updated my autospec file to the following:
>
> #!/usr/bin/env ruby
> ENV['RSPEC'] = 'true'
> autotest_cmd = 'autotest'
> autotest_cmd = "call #{autotest_cmd}" if RUBY_PLATFORM =~ /mswin/
> system autotest_cmd
>
> I have submitted a ticket requesting that autospec be updated accordingly.
>
> http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/466-update-autospec-to-work-on-windows
>

The upcoming version of Ruby (1.8.6 after patchlevel 114) will include
a fix for this issue, which I described in this post (less quirks for
us section):

http://blog.mmediasys.com/2008/04/24/contributions-speedup-and-less-quirks-for-us/

So there is no need to prepend 'call' or ".bat" on Windows anymore
(also, you should consider mswin AND mingw as valid platforms ;-)

Regards,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams
_______________________________________________
rspec-users mailing list
rspec-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080713/52bf0ef9/attachment-0001.html>

From dchelimsky at gmail.com  Sun Jul 13 18:11:53 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 13 Jul 2008 17:11:53 -0500
Subject: [rspec-devel] [rspec-users] Getting RSpec 1.1.4+ to Work with
	Autotest (ZenTest 3.10.0) on Windows (Win32)
In-Reply-To: <506754.80820.qm@web54101.mail.re2.yahoo.com>
References: <506754.80820.qm@web54101.mail.re2.yahoo.com>
Message-ID: <57c63afe0807131511w41e36b30oa396fb6626c71098@mail.gmail.com>

On Sun, Jul 13, 2008 at 4:50 PM, Charles Grindel <cgrindel at yahoo.com> wrote:
> Hi,
>
> Thanks for the info, Luis.  I am glad that they fixed the calling a batch
> file issue.  I have had to handle this myself in several different
> situations.
>
> I do have one additional question.  It sounds like your setup is very
> similar to ours.  Is your project new or did you upgrade?  Do you run
> autospec or autotest from the command line?  It seems like running autotest
> directly should still work given the history comment, but I could not get
> things to fly until I started using autospec.  Just curious.

When we introduced autospec, we also changed the way rspec identifies
itself to autotest such that an ENV var must be present (which is set
by autospec) - so no, the autotest command won't work.

>
> Thanks,
> Chuck
>
> ----- Original Message ----
> From: Luis Lavena <luislavena at gmail.com>
> To: rspec-users <rspec-users at rubyforge.org>
> Cc: RSpec Developers Mailing List <rspec-devel at rubyforge.org>
> Sent: Friday, July 11, 2008 3:29:04 PM
> Subject: Re: [rspec-users] Getting RSpec 1.1.4+ to Work with Autotest
> (ZenTest 3.10.0) on Windows (Win32)
>
> On Fri, Jul 11, 2008 at 8:33 PM, Charles Grindel <cgrindel at yahoo.com> wrote:
>> Hi,
>>
>> After upgrading to Rails 2.1, RSpec 1.1.4+ and ZenTest 3.10.0, autotest
>> would no longer find any of my specs on my Windows development machine.
>> Some Googling directed me to a very recent update in the History.txt file
>> for rspec-fails:
>>
>> IMPORTANT: use 'script/autospec' (or just 'autospec' if you have the rspec
>> gem
>> installed) instead of 'autotest'. We changed the way autotest discovers
>> rspec
>> so the autotest executable won't automatically load rspec anymore. This
>> allows
>> rspec to live side by side other spec frameworks without always co-opting
>> autotest through autotest's discovery mechanism.
>>
>
> Dunno if this funny, but I'm running right now with the exact same
> combination of components and autotest picks my updated spec and files
> (even the ones in lib).
>
>> My project is running RSpec and Rspec-rails as plugins, but I gave it a
>> shot.  Unfortunately, autotest would not even start.  A quick inspection
>> of
>> autospec revealed that the call to autotest in this file will not work on
>> Windows, as is.  In the Windows environment, autotest is a batch file
>> which
>> must be executed with the "call" command when shelling out from a Ruby
>> script.  So, I updated my autospec file to the following:
>>
>> #!/usr/bin/env ruby
>> ENV['RSPEC'] = 'true'
>> autotest_cmd = 'autotest'
>> autotest_cmd = "call #{autotest_cmd}" if RUBY_PLATFORM =~ /mswin/
>> system autotest_cmd
>>
>> I have submitted a ticket requesting that autospec be updated accordingly.
>>
>>
>> http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/466-update-autospec-to-work-on-windows
>>
>
> The upcoming version of Ruby (1.8.6 after patchlevel 114) will include
> a fix for this issue, which I described in this post (less quirks for
> us section):
>
> http://blog.mmediasys.com/2008/04/24/contributions-speedup-and-less-quirks-for-us/
>
> So there is no need to prepend 'call' or ".bat" on Windows anymore
> (also, you should consider mswin AND mingw as valid platforms ;-)
>
> Regards,
> --
> Luis Lavena
> AREA 17
> -
> Human beings, who are almost unique in having the ability to learn from
> the experience of others, are also remarkable for their apparent
> disinclination to do so.
> Douglas Adams
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Tue Jul 15 08:03:51 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 15 Jul 2008 07:03:51 -0500
Subject: [rspec-devel] [rspec-users] Getting RSpec 1.1.4+ to Work with
	Autotest (ZenTest 3.10.0) on Windows (Win32)
In-Reply-To: <71166b3b0807150116j287458fydc221ba6850946c3@mail.gmail.com>
References: <506754.80820.qm@web54101.mail.re2.yahoo.com>
	<57c63afe0807131511w41e36b30oa396fb6626c71098@mail.gmail.com>
	<71166b3b0807150116j287458fydc221ba6850946c3@mail.gmail.com>
Message-ID: <57c63afe0807150503n3e4a5328kc2bb80e258d4bb77@mail.gmail.com>

On Tue, Jul 15, 2008 at 3:16 AM, Luis Lavena <luislavena at gmail.com> wrote:
> On Mon, Jul 14, 2008 at 12:11 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Sun, Jul 13, 2008 at 4:50 PM, Charles Grindel <cgrindel at yahoo.com> wrote:
>>> Hi,
>>>
>>> Thanks for the info, Luis.  I am glad that they fixed the calling a batch
>>> file issue.  I have had to handle this myself in several different
>>> situations.
>>>
>>> I do have one additional question.  It sounds like your setup is very
>>> similar to ours.  Is your project new or did you upgrade?  Do you run
>>> autospec or autotest from the command line?  It seems like running autotest
>>> directly should still work given the history comment, but I could not get
>>> things to fly until I started using autospec.  Just curious.
>>
>> When we introduced autospec, we also changed the way rspec identifies
>> itself to autotest such that an ENV var must be present (which is set
>> by autospec) - so no, the autotest command won't work.
>>
>
> Hmn, really?
>
> rspec, commit 5bb989c6a54e325198e180ef3d4e59b5bf6eb21c
> rspec-rails: commit 9a1e10e7b71f7e8e4fb910a9695ee69abec63816
>
> http://pastie.org/private/gwgvkbhpbvhvtquslwe6g

Hmm. Well, it's not supposed to work :) We added autospec specifically
so that it wouldn't. Check out
http://rspec.lighthouseapp.com/projects/5645/tickets/394 and
http://github.com/dchelimsky/rspec/commit/c12b4e0cdcae1309725eeee75ce85110b905f432.
Any reason that shouldn't work on windows?

> But in any case, if you say that I should use script/autospec, then I should :-)
>
> --
> Luis Lavena
> AREA 17
> -
> Human beings, who are almost unique in having the ability to learn from
> the experience of others, are also remarkable for their apparent
> disinclination to do so.
> Douglas Adams
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>