From: Rocky Bernstein <rocky.bernstein@...>
Date: 2007-12-22T22:45:11+09:00
Subject: Re: Semantics of caller (was Re: Some Ruby 1.9 loose ends to tie up)

------=_Part_2686_4165501.1198331116873
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I hope this isn't too tedious but a couple of more thoughts here.  The
situation in JRuby and that in Ruby 1.9 are kind of different. From what I
understand JRuby does a frame elimination *only* when it determines the call
can't be recursive whereas Ruby 1.9 (if it performs tail recursion removal),
removes frames on (some) recursive calls.

In the non-recursive case, providing information requested by caller() or a
printed in an exception trace which amounts to the same thing doesn't strike
me as that hard. When the method is expanded in-line the caller information
can be saved somewhere - that's static information.  That said, I don't
believe the combination gdb and gcc do or show this when calls are inlined.

And as to leaving a bread crumb, one place this information would be used is
in showing an exception or stack trace, especially when that static call
information is not available.

On Dec 22, 2007 7:43 AM, Rocky Bernstein <rocky.bernstein@gmail.com> wrote:

> Thanks for the detailed explanation.  A suggestion  to those who omit call
> frames is to leave a breadcrumb somewhere to indicate that this has
> happened; I have a hard time imagining this would impact performance to any
> noticeable degree . (And for all I know it may be already be the case that
> this currently done).
>
> My answer to your question is in line.
>
> On Dec 22, 2007 7:08 AM, Charles Oliver Nutter <charles.nutter@sun.com>
> wrote:
>
> > .
> >
> > > Personally, I don't see anything wrong clarifying the explanation of
> > > caller() to mean that it gives reports the frames it sees is currently
> > > there if that's in fact what's going on in the YARV and JRuby
> > > implementations. The other alternative of course is to have these
> > > implementations try to support caller as though no frames were
> > removed.
> >
> > Is it useful if the result could vary depending on how you write your
> > code and how long the code has run?
>
>
> It is useful to have a precise understanding of the semantics of caller.
> And having a caller()  method --- and for that matter access to the existing
> stack frames -- is more useful than not having access which is what it
> seemed you were implying initially.
>
>

------=_Part_2686_4165501.1198331116873
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I hope this isn&#39;t too tedious but a couple of more thoughts here.&nbsp; The situation in JRuby and that in Ruby 1.9 are kind of different. From what I understand JRuby does a frame elimination <i>only</i> when it determines the call can&#39;t be recursive whereas Ruby 
1.9 (if it performs tail recursion removal), removes frames on (some) recursive calls. <br><br>In the non-recursive case, providing information requested by caller() or a printed in an exception trace which amounts to the same thing doesn&#39;t strike me as that hard. When the method is expanded in-line the caller information can be saved somewhere - that&#39;s static information.&nbsp; That said, I don&#39;t believe the combination gdb and gcc do or show this when calls are inlined. 
<br><br>And as to leaving a bread crumb, one place this information would be used is in showing an exception or stack trace, especially when that static call information is not available. <br><br><div class="gmail_quote">
On Dec 22, 2007 7:43 AM, Rocky Bernstein &lt;<a href="mailto:rocky.bernstein@gmail.com">rocky.bernstein@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Thanks for the detailed explanation.&nbsp; A suggestion&nbsp; to those who omit call frames is to leave a breadcrumb somewhere to indicate that this has happened; I have a hard time imagining this would impact performance to any noticeable degree . (And for all I know it may be already be the case that this currently done). 
<br><br>My answer to your question is in line.<br><br></div><div class="gmail_quote"><div class="Ih2E3d">On Dec 22, 2007 7:08 AM, Charles Oliver Nutter &lt;<a href="mailto:charles.nutter@sun.com" target="_blank">charles.nutter@sun.com
</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
.<br><div><br>&gt; Personally, I don&#39;t see anything wrong clarifying the explanation of<br>&gt; caller() to mean that it gives reports the frames it sees is currently<br>&gt; there if that&#39;s in fact what&#39;s going on in the YARV and JRuby
<br>&gt; implementations. The other alternative of course is to have these<br>&gt; implementations try to support caller as though no frames were removed.<br><br></div>Is it useful if the result could vary depending on how you write your
<br>code and how long the code has run?</blockquote></div><div class="Ih2E3d"><div><br>It is useful to have a precise understanding of the semantics of caller. And having a caller()&nbsp; method --- and for that matter access to the existing stack frames -- is more useful than not having access which is what it seemed you were implying initially.
<br></div></div></div><br>
</blockquote></div><br>

------=_Part_2686_4165501.1198331116873--