Forum: RSpec Missing method implementation_backtrace

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4e46fab0a7e907763b19ca11c3b8e854?d=identicon&s=25 Ben Fyvie (Guest)
on 2008-11-20 19:52
(Received via mailing list)
We just upgraded from rspec version 1.1.4 to rspec version 1.1.11 and
found
that this no longer exists:






# File lib/spec/example/example_methods.rb, line 84
      def implementation_backtrace
        eval("caller", @_implementation)
      end



I don't really know what this method is for and don't really care that
it is
gone; however, Netbeans 6.5 does care that it is gone and is not able to
run
tests without it.  As a temporary band-aid I have added the method back
locally.  I was wondering if someone could enlighten me as to why the
method
was removed?



Thanks!





Ben Fyvie
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-20 20:35
(Received via mailing list)
On Thu, Nov 20, 2008 at 12:44 PM, Ben Fyvie
<ben.fyvie@champsoftware.com> wrote:
>
>       end
>
>
>
> I don't really know what this method is for and don't really care that it is
> gone; however, Netbeans 6.5 does care that it is gone and is not able to run
> tests without it.  As a temporary band-aid I have added the method back
> locally.  I was wondering if someone could enlighten me as to why the method
> was removed?

Unfortunately we don't yet have a formal API for tool vendors to use,
so NetBeans apparently used a method that we view as internal and it
got moved or renamed during a refactoring.

This is something we plan to address over the coming months:
formalizing an API for extension and tool use.

FWIW,
David
944f769c99deff7aa8bc3b5b93830b7a?d=identicon&s=25 Scott Taylor (Guest)
on 2008-11-20 20:37
(Received via mailing list)
On Nov 20, 2008, at 2:35 PM, David Chelimsky wrote:

>>      def implementation_backtrace
>> able to run
> This is something we plan to address over the coming months:
> formalizing an API for extension and tool use.
>

Also, check out this:

http://metaclass.org/2008/6/7/calling-in-the-dark

Scott
44cbd795ae9185fc634ab8bc7939b3e3?d=identicon&s=25 rubyphunk (Guest)
on 2008-11-21 00:48
(Received via mailing list)
Hi,

same problem here. I always used "example.implementation_backtrace" in
a custom formatter to find out to which spec file a passing example
belongs to.
Is there another way to get the file path?


lg // andreas
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-21 19:00
(Received via mailing list)
On Thu, Nov 20, 2008 at 5:47 PM, rubyphunk <rubyphunk@googlemail.com>
wrote:
> Hi,
>
> same problem here. I always used "example.implementation_backtrace" in
> a custom formatter to find out to which spec file a passing example
> belongs to.
> Is there another way to get the file path?

Looking through the code I see the name was changed to
example_backtrace, and I can see why it was changed to that. In fact,
looking closer I really think it should just be backtrace.

I'm going to change it to #backtrace, rdoc it up to formalize its
place in the world as an API method, and, in the interest of playing
nice w/ NetBeans, reinstate a deprecated implementation_backtrace that
delegates to backtrace.

Rubyphunk, what you can do in the short run is alias
implementation_backtrace, example_backtrace, but you'll have to change
that for the next release. Sorry about the churn, but this was really
not a formally public method to begin with. Now we will make it so.

Cheers,
David
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-21 21:25
(Received via mailing list)
On Thu, Nov 20, 2008 at 9:20 PM, David Chelimsky <dchelimsky@gmail.com>
wrote:
> looking closer I really think it should just be backtrace.
>
> I'm going to change it to #backtrace, rdoc it up to formalize its
> place in the world as an API method, and, in the interest of playing
> nice w/ NetBeans, reinstate a deprecated implementation_backtrace that
> delegates to backtrace.
>
> Rubyphunk, what you can do in the short run is alias
> implementation_backtrace, example_backtrace, but you'll have to change
> that for the next release. Sorry about the churn, but this was really
> not a formally public method to begin with. Now we will make it so.

Actually - I see that this change from implementation_backtrace to
example_backtrace was after the 1.1.11 release (the OP said this was
upgrading to 1.1.11, but it must have been upgrading to the current
code in git).

I'm still going to go ahead w/ this plan (rename to backtrace and
reinstate a deprecated implementation_backtrace before the next
release), but I just want to alleviate concern of anybody who might be
concerned that the current release doesn't play nice w/ NetBeans (at
least for this reason)

Cheers,
David
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 aslak hellesoy (Guest)
on 2008-11-23 00:23
(Received via mailing list)
On Fri, Nov 21, 2008 at 4:20 AM, David Chelimsky
<dchelimsky@gmail.com>wrote:

> example_backtrace, and I can see why it was changed to that. In fact,
> not a formally public method to begin with. Now we will make it so.
>

How will people know that a method is part of an API? Can we simply say
that
if it has RDoc it's part of the API and stable, and if it doesn't it's
not?
(We can still RDoc non-API code, just put :nodoc: on it so it doesn't
get
part of the API docs).

WDYT?

Aslak
D069ac0170dc6c93bad77734258fadae?d=identicon&s=25 Peter Jaros (Guest)
on 2008-11-24 10:51
(Received via mailing list)
On Fri, Nov 21, 2008 at 8:28 AM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:
>
> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).

I think that would clarify the API *and* make the RDoc easier to read.
:)

Peter
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-24 13:01
(Received via mailing list)
On Fri, Nov 21, 2008 at 7:28 AM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:
>> > a custom formatter to find out to which spec file a passing example
>> delegates to backtrace.
>
> WDYT?

I think that's where we want to land. It's going to take a bit of a
going through to get there though. I think that should be part of a
1.2 release (not necessarily the very next release) - that we put a
line in the sand as far as that is concerned.

Another thing to consider is what the Merb team has done, where public
methods are marked with ":api: public" in the RDoc. In fact, they've
done a good job of RDoco in general, with Parameters, Returns and
Notes consistently separated.

WDYTAT?
7b5c142a67af70ddc5cf696d952b2a81?d=identicon&s=25 Andreas Wolff (Guest)
on 2008-11-24 16:56
(Received via mailing list)
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:

> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).
>
> WDYT?
>
> Aslak

Wouldn't it be better to have a kind of standalone api. An interface
where the internal implementation can be changed but the public one
stays (mostly) consistent over different releases? IMO going this way,
the rspec-development would be more aware of changes to that API.

lg // andreas
44cbd795ae9185fc634ab8bc7939b3e3?d=identicon&s=25 Andreas Wolff (Guest)
on 2008-11-24 16:59
(Received via mailing list)
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:

> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).
>
> WDYT?

Wouldn't it be better to have a kind of standalone api. An interface
where the internal implementation can be changed but the public one
stays (mostly) consistent over different releases? IMO going this way,
the rspec-development would be more aware of changes to that API.

lg // andreas
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-24 17:00
(Received via mailing list)
On Sun, Nov 23, 2008 at 5:16 AM, David Chelimsky <dchelimsky@gmail.com>
wrote:
>>> >
>>> place in the world as an API method, and, in the interest of playing
>> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> methods are marked with ":api: public" in the RDoc. In fact, they've
> done a good job of RDoco in general, with Parameters, Returns and
> Notes consistently separated.
>
> WDYTAT?

PS - I did add rdoc for the #backtrace methods in both
ExampleGroupMethods and ExampleMethods, as well as their deprecated
counterparts.
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-24 17:05
(Received via mailing list)
On Fri, Nov 21, 2008 at 4:50 PM, Andreas Wolff <treas@dynamicdudes.com>
wrote:
>> Aslak
>
> Wouldn't it be better to have a kind of standalone api. An interface
> where the internal implementation can be changed but the public one
> stays (mostly) consistent over different releases? IMO going this way,
> the rspec-development would be more aware of changes to that API.
>
> lg // andreas

Can you elaborate? What would make an api "standalone" in this context?
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 aslak hellesoy (Guest)
on 2008-11-24 17:25
(Received via mailing list)
On Sun, Nov 23, 2008 at 12:16 PM, David Chelimsky
<dchelimsky@gmail.com>wrote:

> >> >
> >> place in the world as an API method, and, in the interest of playing
> > if it has RDoc it's part of the API and stable, and if it doesn't it's
>
> Another thing to consider is what the Merb team has done, where public
> methods are marked with ":api: public" in the RDoc. In fact, they've
> done a good job of RDoco in general, with Parameters, Returns and
> Notes consistently separated.
>
> WDYTAT?
>

I like that
This topic is locked and can not be replied to.