[ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze

[ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

Would it be possible to have a few patches applied before freeze [if
possible]-I know I would use them [for being able to run racc against
the original method definitions, etc.] :)

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598

and/or

http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a

I'd be happy to submit a more formal patch for them, as well, if desired.

Thanks!
-=R

[ruby-core:18455] Re: [ANN] Ruby 1.9.1 feature freeze

[hemant]

On Thu, Sep 4, 2008 at 9:43 PM, Roger Pack <rogerpack2005@gmail.com> wrote:
> Would it be possible to have a few patches applied before freeze [if
> possible]-I know I would use them [for being able to run racc against
> the original method definitions, etc.] :)
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
>
> and/or
>
> http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
>
> I'd be happy to submit a more formal patch for them, as well, if desired.

This was a very wrong subject line to choose. :)

[ruby-core:18469] Re: [ANN] Ruby 1.9.1 feature freeze

[Charles Oliver Nutter]

hemant wrote:
> On Thu, Sep 4, 2008 at 9:43 PM, Roger Pack <rogerpack2005@gmail.com> wrote:
>> Would it be possible to have a few patches applied before freeze [if
>> possible]-I know I would use them [for being able to run racc against
>> the original method definitions, etc.] :)
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
>>
>> and/or
>>
>> http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
>>
>> I'd be happy to submit a more formal patch for them, as well, if desired.
> 
> This was a very wrong subject line to choose. :)

Definitely confused me!

[ruby-core:18471] Re: [ANN] Ruby 1.9.1 feature freeze

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze"
    on Fri, 5 Sep 2008 01:13:56 +0900, "Roger Pack" <rogerpack2005@gmail.com> writes:

|Would it be possible to have a few patches applied before freeze [if
|possible]-I know I would use them [for being able to run racc against
|the original method definitions, etc.] :)
|
|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598

This is a proposal to add __file__ and __line__ methods to Method and
Proc objects.  Issues are:

  * the method names.  I don't think proposed names that are
    surrounded by underscores are appropriate.
  * non-Ruby defined methods/procs.  the patch raises TypeError, but
    is it really appropriate?  Should they return nil for such cases?
  * use-case.  the proposal comes with use-case sourceref.rb, but any
    other use case?

							matz.

[ruby-core:18474] Re: [ANN] Ruby 1.9.1 feature freeze

[Wilson Bilkovich]

On 9/6/08, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
>  In message "Re: [ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze"
>
>     on Fri, 5 Sep 2008 01:13:56 +0900, "Roger Pack" <rogerpack2005@gmail.com> writes:
>
>  |Would it be possible to have a few patches applied before freeze [if
>  |possible]-I know I would use them [for being able to run racc against
>  |the original method definitions, etc.] :)
>  |
>  |http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
>
>
> This is a proposal to add __file__ and __line__ methods to Method and
>  Proc objects.  Issues are:
>
>   * the method names.  I don't think proposed names that are
>     surrounded by underscores are appropriate.
>   * non-Ruby defined methods/procs.  the patch raises TypeError, but
>     is it really appropriate?  Should they return nil for such cases?
>   * use-case.  the proposal comes with use-case sourceref.rb, but any
>     other use case?
>


RSpec currently uses eval("caller(0)", @a_proc_instance) to simulate
this behavior.
I had not seen this proposal before, but I like it.
I looked into this while working on RSpec for Rubinius, and this seems
to be the only way to determine where a particular block_pass or proc
was created.

RSpec cares about this because (as one example) it allows users to
specify 'examples' to run by regexp against their description.

These 'examples' could be in any spec file, so it uses what I have
taken to calling the 'declaration trace' .. in other words, what you
get when you eval Kernel#caller with a proc as binding.

Using eval for this is slow and ugly; it would be nice to have a clean
feature to implement.
I considered proposing Proc#caller when I first encountered this, but
__file__ and __line__ are nice.

While I am on the subject, here is the bug ticket I filed related to this:
http://redmine.ruby-lang.org/issues/show/146

[ruby-core:18487] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

Sorry for the original subject line being wrong--my attempt to post on
the right thread went very awry :)

Some comments in-line:

> This is a proposal to add __file__ and __line__ methods to Method and
> Proc objects.  Issues are:
>
>  * the method names.  I don't think proposed names that are
>    surrounded by underscores are appropriate.

Perhaps #definition_file/ #definition_line or
#declaration_file/#declaration_line?

>  * non-Ruby defined methods/procs.  the patch raises TypeError, but
>    is it really appropriate?  Should they return nil for such cases?

Nil is probably better, since it already returns nil in some cases.

>  * use-case.  the proposal comes with use-case sourceref.rb, but any
>    other use case?

For me I'll use it to lookup where methods are defined so that I can
<gulp> hate to admit it--re-parse the methods [using racc or what
not], see if they can be optimized, combine them with sub methods, add
pseudo named parameter wrappers, that type of thing.

On second thought I'm wondering if the following would be more useful:
Method#iseq
Proc#iseq

and then add the file/line methods to iseq itself:
RubyVM::InstructionSequence#declaration_file
RubyVM::InstructionSequence#declaration_line

So looking up a method's declaration line would be like
klass.instance_method(:name).iseq.declaration_file

Then that would give us access to the iseq as well as to the file/line
positions.  That would be even better for me [since I would then have
access to the iseq for proc's as well as method's--there seems to
currently be no way to disassemble procs, that I know of, so this
would also conveniently overcome this difficulty as well].
I'd be happy to submit a modified patch.
Thanks!
-=R

[ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze

[Nobuyoshi Nakada]

Hi,

At Sun, 7 Sep 2008 04:53:43 +0900,
Yukihiro Matsumoto wrote in [ruby-core:18471]:
> This is a proposal to add __file__ and __line__ methods to Method and
> Proc objects.  Issues are:
> 
>   * the method names.  I don't think proposed names that are
>     surrounded by underscores are appropriate.
>   * non-Ruby defined methods/procs.  the patch raises TypeError, but
>     is it really appropriate?  Should they return nil for such cases?
>   * use-case.  the proposal comes with use-case sourceref.rb, but any
>     other use case?

I propose a new method, #location than those two new methods.

\f
Index: proc.c
===================================================================
--- proc.c	(revision 19215)
+++ proc.c	(working copy)
@@ -510,9 +510,9 @@ proc_call(int argc, VALUE *argv, VALUE p
     rb_proc_t *proc;
     rb_block_t *blockptr = 0;
+    rb_iseq_t *iseq;
     GetProcPtr(procval, proc);
 
-    if (BUILTIN_TYPE(proc->block.iseq) == T_NODE ||
-	proc->block.iseq->arg_block != -1) {
-
+    iseq = proc->block.iseq;
+    if (BUILTIN_TYPE(iseq) == T_NODE || iseq->arg_block != -1) {
 	if (rb_block_given_p()) {
 	    rb_proc_t *proc;
@@ -621,8 +621,7 @@ get_proc_iseq(VALUE self)
 }
 
-VALUE
-rb_proc_location(VALUE self)
+static VALUE
+iseq_location(rb_iseq_t *iseq)
 {
-    rb_iseq_t *iseq = get_proc_iseq(self);
     VALUE loc[2];
 
@@ -640,4 +639,18 @@ rb_proc_location(VALUE self)
 /*
  * call-seq:
+ *    prc.location  => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this proc
+ * or nil if this proc was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_proc_location(VALUE self)
+{
+    return iseq_location(get_proc_iseq(self));
+}
+
+/*
+ * call-seq:
  *   prc == other_proc   =>  true or false
  *
@@ -1438,4 +1451,37 @@ rb_obj_method_arity(VALUE obj, ID id)
 }
 
+static rb_iseq_t *
+get_method_iseq(VALUE method)
+{
+    struct METHOD *data;
+    NODE *body;
+    rb_iseq_t *iseq;
+
+    Data_Get_Struct(method, struct METHOD, data);
+    body = data->body;
+    switch (nd_type(body)) {
+      case RUBY_VM_METHOD_NODE:
+	GetISeqPtr((VALUE)body->nd_body, iseq);
+	if (RUBY_VM_NORMAL_ISEQ_P(iseq)) break;
+      default:
+	return 0;
+    }
+    return iseq;
+}
+
+/*
+ * call-seq:
+ *    meth.location  => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this method
+ * or nil if this method was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_method_location(VALUE method)
+{
+    return iseq_location(get_method_iseq(method));
+}
+
 /*
  *  call-seq:
@@ -1769,4 +1815,5 @@ Init_Proc(void)
     rb_define_method(rb_cProc, "binding", proc_binding, 0);
     rb_define_method(rb_cProc, "curry", proc_curry, -1);
+    rb_define_method(rb_cProc, "location", rb_proc_location, 0);
 
     /* Exceptions */
@@ -1803,4 +1850,5 @@ Init_Proc(void)
     rb_define_method(rb_cMethod, "owner", method_owner, 0);
     rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
+    rb_define_method(rb_cMethod, "location", rb_method_location, 0);
     rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
     rb_define_method(rb_mKernel, "public_method", rb_obj_public_method, 1);
@@ -1820,4 +1868,5 @@ Init_Proc(void)
     rb_define_method(rb_cUnboundMethod, "owner", method_owner, 0);
     rb_define_method(rb_cUnboundMethod, "bind", umethod_bind, 1);
+    rb_define_method(rb_cUnboundMethod, "location", rb_method_location, 0);
 
     /* Module#*_method */
\f

-- 
Nobu Nakada

[ruby-core:18491] Re: [ANN] Ruby 1.9.1 feature freeze

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
    on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <nobu@ruby-lang.org> writes:

|At Sun, 7 Sep 2008 04:53:43 +0900,
|Yukihiro Matsumoto wrote in [ruby-core:18471]:
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.

|I propose a new method, #location than those two new methods.

I like the idea.  How others think?

							matz.

[ruby-core:18493] Re: [ANN] Ruby 1.9.1 feature freeze

[Trans]

On Sep 8, 5:36 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
>     on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <n...@ruby-lang.org> writes:
>
> |At Sun, 7 Sep 2008 04:53:43 +0900,
> |Yukihiro Matsumoto wrote in [ruby-core:18471]:
> |> This is a proposal to add __file__ and __line__ methods to Method and
> |> Proc objects.
>
> |I propose a new method, #location than those two new methods.
>
> I like the idea.  How others think?

Seems reasonable if __FILE__ and __LINE__ can't do the job.

But, will it lead to wanting a general #location method to use in
place of __FILE__ and __LINE__? If so, a more specialized name, eg.
#source_location, would be better.

Also, should the method be defined for Binding too?

T.


P.S. A bit aside, but could we also have a method for

  binding.eval{ self }

too (eg. Binding#context)?

[ruby-core:18519] Re: [ANN] Ruby 1.9.1 feature freeze

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:18493] Re: [ANN] Ruby 1.9.1 feature freeze"
    on Mon, 8 Sep 2008 20:22:58 +0900, Trans <transfire@gmail.com> writes:

|But, will it lead to wanting a general #location method to use in
|place of __FILE__ and __LINE__? If so, a more specialized name, eg.
|#source_location, would be better.

I like #source_location best.

|Also, should the method be defined for Binding too?

Probably a good idea.

|P.S. A bit aside, but could we also have a method for
|
|  binding.eval{ self }
|
|too (eg. Binding#context)?

Is self really a context?

							matz.

[ruby-core:18528] Re: [ANN] Ruby 1.9.1 feature freeze

[Trans]

On Sep 9, 4:30 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> |P.S. A bit aside, but could we also have a method for
> |
> |  binding.eval{ self }
> |
> |too (eg. Binding#context)?
>
> Is self really a context?

For lack of a better word.

T.

[ruby-core:18496] Re: [ANN] Ruby 1.9.1 feature freeze

[Wilson Bilkovich]

On 9/8/08, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
>  In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
>
>     on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <nobu@ruby-lang.org> writes:
>
>  |At Sun, 7 Sep 2008 04:53:43 +0900,
>  |Yukihiro Matsumoto wrote in [ruby-core:18471]:
>  |> This is a proposal to add __file__ and __line__ methods to Method and
>  |> Proc objects.
>
>
> |I propose a new method, #location than those two new methods.
>
>
> I like the idea.  How others think?
>

This is a specialized feature. Having a specialized name appeals to
me; 'location' is good.

[ruby-core:18497] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

I think Trans' #source_location is nice.

I would prefer to rewrite this patch to become

RubyVM::InstructionSequence#source_location # or whatever name we use

And then also provide
Method#iseq
and
Proc#iseq
methods

To also provide the added capability of accessing Proc's iseq's [and
disassembling it, etc.--currently unavailable]

except I am having trouble creating Proc#iseq [Method#iseq is here[1]].

Any pointers on how to accomplish this? :)
Thanks for your help.
-=R
[1] http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a


On Mon, Sep 8, 2008 at 3:36 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
>    on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <nobu@ruby-lang.org> writes:
>
> |At Sun, 7 Sep 2008 04:53:43 +0900,
> |Yukihiro Matsumoto wrote in [ruby-core:18471]:
> |> This is a proposal to add __file__ and __line__ methods to Method and
> |> Proc objects.
>
> |I propose a new method, #location than those two new methods.
>
> I like the idea.  How others think?
>
>                                                        matz.
>
>



--
Thanks!
-=R



-- 
Thanks!
-=R

[ruby-core:18501] Re: [ANN] Ruby 1.9.1 feature freeze

[Wilson Bilkovich]

On 9/8/08, Roger Pack <rogerpack2005@gmail.com> wrote:
> I think Trans' #source_location is nice.
>
>  I would prefer to rewrite this patch to become
>
>  RubyVM::InstructionSequence#source_location # or whatever name we use
>
>  And then also provide
>  Method#iseq
>  and
>  Proc#iseq
>  methods
>
>  To also provide the added capability of accessing Proc's iseq's [and
>  disassembling it, etc.--currently unavailable]
>
>  except I am having trouble creating Proc#iseq [Method#iseq is here[1]].
>

I much prefer 'location', because it is something that every Ruby
implementation can provide. iseq is super super low-level, and we
should think hard about the API before calling it public.

[ruby-core:18509] Re: [ANN] Ruby 1.9.1 feature freeze

[Charles Oliver Nutter]

Wilson Bilkovich wrote:
> I much prefer 'location', because it is something that every Ruby
> implementation can provide. iseq is super super low-level, and we
> should think hard about the API before calling it public.

I would also hope any "location" methods added will refer only to static 
information, like the place the Proc was created, rather than adding yet 
another method with "special" knowledge of the caller's context 
(requiring the ability to look across invocation frames).

- Charlie

[ruby-core:18521] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

> I much prefer 'location', because it is something that every Ruby
> implementation can provide. iseq is super super low-level, and we
> should think hard about the API before calling it public.

True.  I suppose my suggestion was a little bit MRI-centric after all :)

Could I then also make a request for a few MRI specific functions, either

>> p = proc { |n| n + 2 }
=> #<Proc:...>
>> RubyVM::InstructionSequence.disassemble p # this doesn't currently work

or the before mentioned
Proc#iseq
(Unbound)Method#iseq [see [1]]

These would yield some very welcome functionality for projects like
[2,3,4]  since it would allow users to potentially parse blocks [and
rewrite them] before executing them, which has some strong potential.
This is available in 1.8.x because the AST is made available to c
functions, but not (yet) for 1.9.

Thanks for your help.
-=R

[1] http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
[2] http://rewrite.rubyforge.org/
[3] http://parsetree.rubyforge.org/
[4] http://code.google.com/p/ruby-roger-useful-functions/wiki/NamedParameters

[ruby-core:18546] Re: [ANN] Ruby 1.9.1 feature freeze

[Paul Brannan]

On Wed, Sep 10, 2008 at 03:21:20AM +0900, Roger Pack wrote:
> > I much prefer 'location', because it is something that every Ruby
> > implementation can provide. iseq is super super low-level, and we
> > should think hard about the API before calling it public.
> 
> True.  I suppose my suggestion was a little bit MRI-centric after all :)
> 
> Could I then also make a request for a few MRI specific functions, either
> 
> >> p = proc { |n| n + 2 }
> => #<Proc:...>
> >> RubyVM::InstructionSequence.disassemble p # this doesn't currently work

With ruby-internal (http://github.com/cout/ruby-internal) you can do this:

irb(main):001:0> require 'internal/proc'
=> true
irb(main):002:0> p = proc { |n| n + 2 }
=> #<Proc:0x40275ed0@(irb):2>
irb(main):003:0> puts p.body.disasm
== disasm: <ISeq:block (3 levels) in irb_binding@(irb)>=================
== catch table
| catch type: redo   st: 0000 ed: 0006 sp: 0000 cont: 0000
| catch type: next   st: 0000 ed: 0006 sp: 0000 cont: 0006
|------------------------------------------------------------------------
local table (size: 1, argc: 1 [opts: 0, rest: -1, post: 0, block: -1] s3)
[ 1] n<Arg>
0000 getdynamic       n, 0                                            (   2)
0003 putobject        2
0005 opt_plus
0006 leave
=> nil

> 
> or the before mentioned
> Proc#iseq
> (Unbound)Method#iseq [see [1]]
> 
> These would yield some very welcome functionality for projects like
> [2,3,4]  since it would allow users to potentially parse blocks [and
> rewrite them] before executing them, which has some strong potential.
> This is available in 1.8.x because the AST is made available to c
> functions, but not (yet) for 1.9.

AFAICT the AST is discarded once the method is compiled to bytecode.

Paul

[ruby-core:18636] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

> To also provide the added capability of accessing Proc's iseq's [and
> disassembling it, etc.--currently unavailable]
>
> except I am having trouble creating Proc#iseq [Method#iseq is here[1]].
>
> Any pointers on how to accomplish this? :)

Thanks to Paul Brannan for his pointers.
I have included here a patch with a prototype
VM::InstructionSequence.disassemble_proc
method with the functionality that I was hoping could be added.
I was unsure how to rewrite
VM::InstructionSequence.disassemble

to handle both methods and procs, so just wrote a separate method.

Thoughts?
-=R
Index: iseq.c
===================================================================
--- iseq.c      (revision 19392)
+++ iseq.c      (working copy)
@@ -928,6 +928,21 @@
    return ret;
 }

+static VALUE
+iseq_s_disasm_proc(VALUE klass, VALUE proc)
+{
+  VALUE ret = Qnil;
+  rb_proc_t *proc_pointer;
+  GetProcPtr(proc, proc_pointer);
+  VALUE iseqval = (VALUE) proc_pointer->block.iseq->self;
+  if (RUBY_VM_NORMAL_ISEQ_P(iseqval))
+       ret = ruby_iseq_disasm(iseqval);
+
+  return ret;
+}
+
+
+
 const char *
 ruby_node_name(int node)
 {
@@ -1339,5 +1354,6 @@
    rb_define_singleton_method(rb_cISeq, "compile_option=",
iseq_s_compile_option_set, 1);
    rb_define_singleton_method(rb_cISeq, "disasm", iseq_s_disasm, 1);
    rb_define_singleton_method(rb_cISeq, "disassemble", iseq_s_disasm, 1);
+    rb_define_singleton_method(rb_cISeq, "disassemble_proc",
iseq_s_disasm_proc, 1);
 }

[ruby-core:18498] Re: [ANN] Ruby 1.9.1 feature freeze

[Robert Klemme]

2008/9/8 Yukihiro Matsumoto <matz@ruby-lang.org>:
> Hi,
>
> In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
>    on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <nobu@ruby-lang.org> writes:
>
> |At Sun, 7 Sep 2008 04:53:43 +0900,
> |Yukihiro Matsumoto wrote in [ruby-core:18471]:
> |> This is a proposal to add __file__ and __line__ methods to Method and
> |> Proc objects.
>
> |I propose a new method, #location than those two new methods.
>
> I like the idea.  How others think?

Good! I'd like to suggest a name alternative though

#defined_at

IMHO #location is very general and #defined_at better expresses what's
being returned (at least from what I gathered should be the semantics
of this method).  Usage would be

def foo(&b)
  file, line = b.defined_at
  $stderr.printf "calling block which was defined at %s:%d\n", file, line
  b.call
end

Kind regards

robert

-- 
use.inject do |as, often| as.you_can - without end

[ruby-core:18502] Re: [ANN] Ruby 1.9.1 feature freeze

[Joel VanderWerf]

Robert Klemme wrote:
> #defined_at
> 
> IMHO #location is very general and #defined_at better expresses what's
> being returned (at least from what I gathered should be the semantics
> of this method).  Usage would be

Agree. It is convenient to use subclasses of Procs. Having such a 
general method name taken away is sob-optimal.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

[ruby-core:18763] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

> I propose a new method, #location than those two new methods.
...
> --
> Nobu Nakada

Interestingly, there already was an rb_proc_location method in 1.9
[just no Proc#location nor Method#location nor Binding#location].

Anyway, here's Nobu Nakada's patch with the method name changed to
source_location [should work against SVN head].

Note also the recent creation of
Feature #578: add method to disassemble Proc objects

Thanks for your help.  I know I'm annoying with this :)
-=R

Index: proc.c
===================================================================
--- proc.c	(revision 19438)
+++ proc.c	(working copy)
@@ -509,11 +509,11 @@
 {
     rb_proc_t *proc;
     rb_block_t *blockptr = 0;
+    rb_iseq_t *iseq;
     GetProcPtr(procval, proc);
+    iseq = proc->block.iseq;
+    if (BUILTIN_TYPE(iseq) == T_NODE || iseq->arg_block != -1) {

-    if (BUILTIN_TYPE(proc->block.iseq) == T_NODE ||
-	proc->block.iseq->arg_block != -1) {
-
 	if (rb_block_given_p()) {
 	    rb_proc_t *proc;
 	    VALUE procval;
@@ -620,10 +620,9 @@
     return iseq;
 }

-VALUE
-rb_proc_location(VALUE self)
+static VALUE
+iseq_location(rb_iseq_t *iseq)
 {
-    rb_iseq_t *iseq = get_proc_iseq(self);
     VALUE loc[2];

     if (!iseq) return Qnil;
@@ -639,6 +638,20 @@

 /*
  * call-seq:
+ *    prc.source_location  => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this proc
+ * or nil if this proc was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_proc_source_location(VALUE self)
+{
+    return iseq_location(get_proc_iseq(self));
+}
+
+/*
+ * call-seq:
  *   prc == other_proc   =>  true or false
  *
  * Return <code>true</code> if <i>prc</i> is the same object as
@@ -1437,7 +1450,40 @@
     return rb_mod_method_arity(CLASS_OF(obj), id);
 }

+static rb_iseq_t *
+get_method_iseq(VALUE method)
+{
+    struct METHOD *data;
+    NODE *body;
+    rb_iseq_t *iseq;
+
+    Data_Get_Struct(method, struct METHOD, data);
+    body = data->body;
+    switch (nd_type(body)) {
+      case RUBY_VM_METHOD_NODE:
+       GetISeqPtr((VALUE)body->nd_body, iseq);
+       if (RUBY_VM_NORMAL_ISEQ_P(iseq)) break;
+      default:
+       return 0;
+    }
+    return iseq;
+}
+
 /*
+ * call-seq:
+ *    meth.source_location  => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this method
+ * or nil if this method was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_method_source_location(VALUE method)
+{
+    return iseq_location(get_method_iseq(method));
+}
+
+/*
  *  call-seq:
  *   meth.to_s      =>  string
  *   meth.inspect   =>  string
@@ -1768,6 +1814,7 @@
     rb_define_method(rb_cProc, "lambda?", proc_lambda_p, 0);
     rb_define_method(rb_cProc, "binding", proc_binding, 0);
     rb_define_method(rb_cProc, "curry", proc_curry, -1);
+    rb_define_method(rb_cProc, "source_location", rb_proc_source_location, 0);

     /* Exceptions */
     rb_eLocalJumpError = rb_define_class("LocalJumpError", rb_eStandardError);
@@ -1802,6 +1849,7 @@
     rb_define_method(rb_cMethod, "name", method_name, 0);
     rb_define_method(rb_cMethod, "owner", method_owner, 0);
     rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
+    rb_define_method(rb_cMethod, "source_location",
rb_method_source_location, 0);
     rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
     rb_define_method(rb_mKernel, "public_method", rb_obj_public_method, 1);

@@ -1819,6 +1867,7 @@
     rb_define_method(rb_cUnboundMethod, "name", method_name, 0);
     rb_define_method(rb_cUnboundMethod, "owner", method_owner, 0);
     rb_define_method(rb_cUnboundMethod, "bind", umethod_bind, 1);
+    rb_define_method(rb_cUnboundMethod, "source_location",
rb_method_source_location, 0);

     /* Module#*_method */
     rb_define_method(rb_cModule, "instance_method", rb_mod_instance_method, 1);
Index: thread.c
===================================================================
--- thread.c	(revision 19438)
+++ thread.c	(working copy)
@@ -528,10 +528,10 @@
     }
     GetThreadPtr(thread, th);
     if (th->first_args) {
-	VALUE rb_proc_location(VALUE self);
+	VALUE rb_proc_source_location(VALUE self);
 	VALUE proc = th->first_proc, line, loc;
 	const char *file;
-        if (!proc || !RTEST(loc = rb_proc_location(proc))) {
+        if (!proc || !RTEST(loc = rb_proc_source_location(proc))) {
             rb_raise(rb_eThreadError, "already initialized thread");
         }
 	file = RSTRING_PTR(RARRAY_PTR(loc)[0]);

[ruby-core:18875] Re: [ANN] Ruby 1.9.1 feature freeze

[Nobuyoshi Nakada]

Hi,

At Sun, 21 Sep 2008 03:49:50 +0900,
Roger Pack wrote in [ruby-core:18763]:
> Anyway, here's Nobu Nakada's patch with the method name changed to
> source_location [should work against SVN head].

Are you proposing the change of C functions names together?

-- 
Nobu Nakada

[ruby-core:18970] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

>> Interestingly, there already was an rb_proc_location method in 1.9
>> [just no Proc#location nor Method#location nor Binding#location].
>>
>> Anyway, here's Nobu Nakada's patch with the method name changed to
>> source_location [should work against SVN head].

> Nobuyoshi Nakada wrote:
> Are you proposing the change of C functions names together?

Yeah I was thinking it would be less confusing to only have one
function name [source_location] and have it apply to both proc and
method.

Also note that it was mentioned that Binding#source_location would be
nice--I just have no idea how to add it so the current patch doesn't
include it.

Note also Feature #578: add method to disassemble Proc objects
Any feedback on having that added as well?

-=R

[ruby-core:18978] Re: [ANN] Ruby 1.9.1 feature freeze

[Nobuyoshi Nakada]

Hi,

At Fri, 26 Sep 2008 13:17:25 +0900,
Roger Pack wrote in [ruby-core:18970]:
> > Nobuyoshi Nakada wrote:
> > Are you proposing the change of C functions names together?
> 
> Yeah I was thinking it would be less confusing to only have one
> function name [source_location] and have it apply to both proc and
> method.

Meanwhile, I added the methods without changing the function
names.  The names are another story.

# I've thought I'd committed it already, but forgotten.

> Also note that it was mentioned that Binding#source_location would be
> nice--I just have no idea how to add it so the current patch doesn't
> include it.

What is the line number of Binding?

-- 
Nobu Nakada

[ruby-core:18981] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

>> Yeah I was thinking it would be less confusing to only have one
>> function name [source_location] and have it apply to both proc and
>> method.
>
> Meanwhile, I added the methods without changing the function
> names.  The names are another story.
>
> # I've thought I'd committed it already, but forgotten.

Thanks for adding those.  I see them in SVN now.
I prefer #source_location but #location is livable :)

>> Also note that it was mentioned that Binding#source_location would be
>> nice--I just have no idea how to add it so the current patch doesn't
>> include it.
>
> What is the line number of Binding?

There isn't one in that patch.  I'm unsure how to create Binding#source_location
Thanks!
-=R

[ruby-core:18984] Re: [ANN] Ruby 1.9.1 feature freeze

[Nobuyoshi Nakada]

Hi,

At Sat, 27 Sep 2008 01:19:37 +0900,
Roger Pack wrote in [ruby-core:18981]:
> >> Yeah I was thinking it would be less confusing to only have one
> >> function name [source_location] and have it apply to both proc and
> >> method.
> >
> > Meanwhile, I added the methods without changing the function
> > names.  The names are another story.
> >
> > # I've thought I'd committed it already, but forgotten.
> 
> Thanks for adding those.  I see them in SVN now.
> I prefer #source_location but #location is livable :)

Methods are #source_location, C functions are still
*_location().

> >> Also note that it was mentioned that Binding#source_location would be
> >> nice--I just have no idea how to add it so the current patch doesn't
> >> include it.
> >
> > What is the line number of Binding?
> 
> There isn't one in that patch.  I'm unsure how to create Binding#source_location

It's easy to implement, if it is OK to return the beginning of
the code block where the binding was made.

\f
Index: proc.c
===================================================================
--- proc.c	(revision 19593)
+++ proc.c	(working copy)
@@ -29,4 +29,5 @@ static VALUE bmcall(VALUE, VALUE);
 static int method_arity(VALUE);
 static VALUE rb_obj_is_method(VALUE m);
+static VALUE iseq_location(rb_iseq_t *iseq);
 
 /* Proc */
@@ -339,4 +340,22 @@ bind_eval(int argc, VALUE *argv, VALUE b
 }
 
+/*
+ * call-seq:
+ *    binding.source_location  => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this binding
+ * or nil if this binding was not defined in ruby (i.e. native)
+ */
+VALUE
+rb_bind_location(VALUE self)
+{
+    rb_binding_t *bind;
+    rb_env_t *env;
+
+    GetBindingPtr(self, bind);
+    GetEnvPtr(bind->env, env);
+    return iseq_location(env->block.iseq);
+}
+
 static VALUE
 proc_new(VALUE klass, int is_lambda)
@@ -1923,4 +1942,5 @@ Init_Binding(void)
     rb_define_method(rb_cBinding, "dup", binding_dup, 0);
     rb_define_method(rb_cBinding, "eval", bind_eval, -1);
+    rb_define_method(rb_cBinding, "source_location", rb_bind_location, 0);
     rb_define_global_function("binding", rb_f_binding, 0);
 }
Index: ruby.c
===================================================================
--- ruby.c	(revision 19593)
+++ ruby.c	(working copy)
@@ -1478,4 +1478,5 @@ ruby_prog_init(void)
 
     rb_define_global_const("ARGV", rb_argv);
+    rb_define_global_const("TOPLEVEL_BINDING", rb_binding_new());
 
 #ifdef MSDOS
Index: vm.c
===================================================================
--- vm.c	(revision 19594)
+++ vm.c	(working copy)
@@ -1241,7 +1241,4 @@ rb_iseq_eval(VALUE iseqval)
     vm_set_top_stack(th, iseqval);
 
-    if (!rb_const_defined(rb_cObject, rb_intern("TOPLEVEL_BINDING"))) {
-	rb_define_global_const("TOPLEVEL_BINDING", rb_binding_new());
-    }
     val = vm_exec(th);
     tmp = iseqval; /* prohibit tail call optimization */
\f

-- 
Nobu Nakada

[ruby-core:20708] Re: [ANN] Ruby 1.9.1 feature freeze

[Roger Pack]

> +/*
> + * call-seq:
> + *    meth.location  => [String, Fixnum]
> + *
> + * returns the ruby source filename and line number containing this method
> + * or nil if this method was not defined in ruby (i.e. native)
> + */

Quite useful would also be
meth.source_location => [String, Fixnum, Fixnum] # to designate which
character it started at, to make it easier to go in and extract the
original code.

Or even meth.source_location => [[begin char], [end char]] that would
be nice [though not necessary, I suppose, since once you have the
beginning, you can scan for the end].
This would enable meth.to_s more readily.
Thanks!
-=R