[#12372] Release compatibility/train — Prashant Srinivasan <Prashant.Srinivasan@...>

Hello all,

28 messages 2007/10/03
[#12373] Re: Release compatibility/train — Yukihiro Matsumoto <matz@...> 2007/10/03

Hi,

[#12374] Re: Release compatibility/train — David Flanagan <david@...> 2007/10/03

Yukihiro Matsumoto wrote:

[#12376] Re: Release compatibility/train — Prashant Srinivasan <Prashant.Srinivasan@...> 2007/10/03

[#12377] Re: Release compatibility/train — Yukihiro Matsumoto <matz@...> 2007/10/03

Hi,

[#12382] Re: Release compatibility/train — Charles Oliver Nutter <charles.nutter@...> 2007/10/03

Yukihiro Matsumoto wrote:

[#12385] Re: Release compatibility/train — Yukihiro Matsumoto <matz@...> 2007/10/03

Hi,

[#12388] Re: Release compatibility/train — Charles Oliver Nutter <charles.nutter@...> 2007/10/03

Yukihiro Matsumoto wrote:

[#12389] Re: Release compatibility/train — Yukihiro Matsumoto <matz@...> 2007/10/03

Hi,

[#12406] Re: Release compatibility/train — "David A. Black" <dblack@...> 2007/10/03

Hi --

[#12383] Include Rake in Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

20 messages 2007/10/03

[#12539] Ordered Hashes in 1.9? — Michael Neumann <mneumann@...>

Hi all,

17 messages 2007/10/08
[#12542] Re: Ordered Hashes in 1.9? — Yukihiro Matsumoto <matz@...> 2007/10/08

Hi,

[#12681] Unicode: Progress? — murphy <murphy@...>

Hello!

17 messages 2007/10/15

[#12693] retry: revised 1.9 http patch — Hugh Sasse <hgs@...>

I'm reposting this because I've had little response to this version

11 messages 2007/10/15

[#12697] Range.first is incompatible with Enumerable.first — David Flanagan <david@...>

The new Enumerable.first method is a generalization of Array.first to

11 messages 2007/10/16

[#12754] Improving 'syntax error, unexpected $end, expecting kEND'? — Hugh Sasse <hgs@...>

I've had a look at this, but can't see how to do it: When I get

17 messages 2007/10/18
[#12886] Re: Improving 'syntax error, unexpected $end, expecting kEND'? — David Flanagan <david@...> 2007/10/23

The patch below changes this message to:

[#12758] Encoding::primary_encoding — David Flanagan <david@...>

Hi,

25 messages 2007/10/18
[#12763] Re: Encoding::primary_encoding — Nobuyoshi Nakada <nobu@...> 2007/10/19

Hi,

[#12802] Re: Encoding::primary_encoding — Wolfgang N疆asi-Donner <ed.odanow@...> 2007/10/21

Nobuyoshi Nakada schrieb:

[#12803] Re: Encoding::primary_encoding — Nobuyoshi Nakada <nobu@...> 2007/10/21

Hi,

[#12804] Re: Encoding::primary_encoding — Wolfgang N疆asi-Donner <ed.odanow@...> 2007/10/21

Nobuyoshi Nakada schrieb:

[#12808] Re: Encoding::primary_encoding — Nobuyoshi Nakada <nobu@...> 2007/10/22

Hi,

[#12818] Re: Encoding::primary_encoding — Wolfgang N疆asi-Donner <ed.odanow@...> 2007/10/22

Nobuyoshi Nakada schrieb:

[#12820] Re: Encoding::primary_encoding — "Michal Suchanek" <hramrach@...> 2007/10/22

T24gMjIvMTAvMjAwNywgV29sZmdhbmcgTsOhZGFzaS1Eb25uZXIgPGVkLm9kYW5vd0B3b25hZG8u

[#12823] Re: Encoding::primary_encoding — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/10/22

Michal Suchanek schrieb:

[#12824] Re: Encoding::primary_encoding — Nobuyoshi Nakada <nobu@...> 2007/10/22

Hi,

[#12767] \u escapes in string literals: proof of concept implementation — David Flanagan <david@...>

Back at the end of August, Matz wrote (see

45 messages 2007/10/19
[#12769] Re: \u escapes in string literals: proof of concept implementation — "Nobuyoshi Nakada" <nobu@...> 2007/10/19

Hi,

[#12782] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/20

Nobuyoshi Nakada wrote:

[#12831] Re: \u escapes in string literals: proof of concept implementation — Yukihiro Matsumoto <matz@...> 2007/10/22

Hi,

[#12841] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/22

Yukihiro Matsumoto wrote:

[#12862] Re: \u escapes in string literals: proof of concept implementation — Martin Duerst <duerst@...> 2007/10/23

At 04:19 07/10/23, David Flanagan wrote:

[#12864] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/23

Martin Duerst wrote:

[#12870] Re: \u escapes in string literals: proof of concept implementation — Martin Duerst <duerst@...> 2007/10/23

At 13:10 07/10/23, David Flanagan wrote:

[#12872] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/23

Martin Duerst wrote:

[#12936] Re: \u escapes in string literals: proof of concept implementation — Yukihiro Matsumoto <matz@...> 2007/10/25

Hi,

[#12980] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/26

Yukihiro Matsumoto wrote:

[#13028] Re: \u escapes in string literals: proof of concept implementation — Nobuyoshi Nakada <nobu@...> 2007/10/29

Hi,

[#13032] Re: \u escapes in string literals: proof of concept implementation — David Flanagan <david@...> 2007/10/29

Nobuyoshi Nakada wrote:

[#13034] Re: \u escapes in string literals: proof of concept implementation — Nobuyoshi Nakada <nobu@...> 2007/10/29

Hi,

[#13082] Re: \u escapes in string literals: proof of concept implementation — Martin Duerst <duerst@...> 2007/10/30

At 16:46 07/10/29, Nobuyoshi Nakada wrote:

[#13231] Re: \u escapes in string literals: proof of concept implementation — Nobuyoshi Nakada <nobu@...> 2007/11/06

Hi,

[#13234] Re: \u escapes in string literals: proof of concept implementation — Martin Duerst <duerst@...> 2007/11/06

At 11:29 07/11/06, Nobuyoshi Nakada wrote:

[#12825] clarification of ruby libraries installation paths? — Lucas Nussbaum <lucas@...>

Hi,

53 messages 2007/10/22
[#12830] Re: clarification of ruby libraries installation paths? — Ben Bleything <ben@...> 2007/10/22

On Mon, Oct 22, 2007, Lucas Nussbaum wrote:

[#12833] Re: clarification of ruby libraries installation paths? — Lucas Nussbaum <lucas@...> 2007/10/22

On 23/10/07 at 00:13 +0900, Ben Bleything wrote:

[#12835] Re: clarification of ruby libraries installation paths? — "Austin Ziegler" <halostatue@...> 2007/10/22

On 10/22/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:

[#12836] Re: clarification of ruby libraries installation paths? — Lucas Nussbaum <lucas@...> 2007/10/22

On 23/10/07 at 01:55 +0900, Austin Ziegler wrote:

[#12888] Re: clarification of ruby libraries installation paths? — Gonzalo Garramu <ggarra@...> 2007/10/23

Lucas Nussbaum wrote:

[#12894] Re: clarification of ruby libraries installation paths? — Lucas Nussbaum <lucas@...> 2007/10/24

On 24/10/07 at 05:14 +0900, Gonzalo Garramu wrote:

[#13057] Re: clarification of ruby libraries installation paths? — Gonzalo Garramu <ggarra@...> 2007/10/29

Lucas Nussbaum wrote:

[#13058] Re: clarification of ruby libraries installation paths? — Lucas Nussbaum <lucas@...> 2007/10/29

On 30/10/07 at 07:28 +0900, Gonzalo Garramu wrote:

[#12848] Re: clarification of ruby libraries installation paths? — Sam Roberts <sroberts@...> 2007/10/22

On Tue, Oct 23, 2007 at 01:55:29AM +0900, Austin Ziegler wrote:

[#12855] Re: clarification of ruby libraries installation paths? — "Austin Ziegler" <halostatue@...> 2007/10/23

On 10/22/07, Sam Roberts <sroberts@uniserve.com> wrote:

[#13016] Re: clarification of ruby libraries installation paths? — bob@... (Bob Proulx) 2007/10/28

Austin Ziegler wrote:

[#13029] Re: clarification of ruby libraries installation paths? — "Austin Ziegler" <halostatue@...> 2007/10/29

On 10/28/07, Bob Proulx <bob@proulx.com> wrote:

[#13054] Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — Lucas Nussbaum <lucas@...> 2007/10/29

Austin,

[#13055] Re: Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — "Luis Lavena" <luislavena@...> 2007/10/29

On 10/29/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:

[#13064] Re: Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — "Austin Ziegler" <halostatue@...> 2007/10/30

On 10/29/07, Luis Lavena <luislavena@gmail.com> wrote:

[#13066] Re: Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — "Luis Lavena" <luislavena@...> 2007/10/30

On 10/30/07, Austin Ziegler <halostatue@gmail.com> wrote:

[#13094] Re: Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — "Rick Bradley" <rick@...> 2007/10/30

Do we think that maybe, just maybe, things went off the rails when the

[#13095] Re: Austin Ziegler's behaviour (Was: clarification of ruby libraries installation paths?) — "Luis Lavena" <luislavena@...> 2007/10/30

On 10/30/07, Rick Bradley <rick@rickbradley.com> wrote:

[#12900] Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Wolfgang Nádasi-Donner <ed.odanow@...>

Dear Ruby 1.9 architects, developers, and testers!

31 messages 2007/10/24
[#12905] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Yukihiro Matsumoto <matz@...> 2007/10/24

Hi,

[#12907] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/10/24

Yukihiro Matsumoto schrieb:

[#12909] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Yukihiro Matsumoto <matz@...> 2007/10/24

Hi,

[#12940] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/10/25
[#12942] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/10/25

I have a (hopefully) final question before testing all

[#12948] Re: Hopefully Complete List of Possible Encoding Specifications - Existing Ones — Nobuyoshi Nakada <nobu@...> 2007/10/26

Hi,

[#12951] Fluent programming in Ruby — David Flanagan <david@...>

From the ChangeLog:

16 messages 2007/10/26

[#12996] General hash keys for colon notation — murphy <murphy@...>

Dear language designer(s) and parser wizards,

16 messages 2007/10/28

[#13027] Implementation of "guessUTF" method - final questions — Wolfgang Nádasi-Donner <ed.odanow@...>

Dear Ruby designers, developers, and testers!

22 messages 2007/10/29

[#13069] new Enumerable.butfirst method — David Flanagan <david@...>

Matz,

17 messages 2007/10/30

[PATCH] adds __file__ and __line__ methods to Methods and Procs

From: Brent Roman <brent@...>
Date: 2007-10-11 17:25:37 UTC
List: ruby-core #12598
Please consider the attached patch to
the proc.c supplied of Ruby 1.9.0

ChangeLog:

Mon Oct 11 16:45:19 2007  Brent Roman  <brent@mbari.org>

	* added __file__ and __line__ methods to Method and Proc classes
          [ruby-core:872]


This patch adds instance methods __file__ and __line__ to the
built-in classes Method and Proc.  These methods behave analogously
to the reserved words __FILE__ and __LINE__ to retrieve the Ruby source
filename and line number of the start of the receiver.

The reserved words __FILE__ and __LINE__ cannot be used
to extract the source location of a previously parsed block of
ruby code.  Please see:

[ruby-talk]:21555 <http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/21555>
[ruby-core]:872

I've written a ruby class called SourceRef as an example of what's made possible 
with this core patch.  If you've ever found yourself searching over dozens
of directories to find where a particular Ruby definition, you should
appreciate the simplicity of typing:

irb>  require 'sourceref'
irb>  require 'strange'
irb>  view StrangeClass/:wierdMethod

And having wierdMethod's source text pop up in your favorite text editor!

You can download sourceref.rb (about 10kB of Ruby) at:

 ftp://ftp.mbari.org/pub/brent/sourceref.rb


The __file__ and __line__ methods in core enable this sort of introspection
on methods and procs.  They merely allow Ruby code to access the information
that the Ruby parser and YARV already collect about every method they compile.
So, there's no additional memory overhead for this.

Note that, sometime between v1.6.8 and v1.9.0, the Proc#to_s method was enhanced
to output the file and line number where procs were defined.  However, there
still appears to be no analog for Methods.  Is this intentional?

I suppose if Method#inspect were enhanced in the same way as Proc#to_s has been,
I could get this functionality without these __line__ and __file__ methods.  Please
let me know if that would be the preferred approach.  I'd be happy to submit an
alternative patch if there was some indication that it would be accepted 
into the mainline.

- brent





Attachments (1)

ruby19-srcref.patch (4.01 KB, text/x-patch)
--- /tmp/pro_1.1.2.1_4.c	2007-10-11 09:39:49.000000000 -0700
+++ proc.c	2007-10-10 18:03:08.000000000 -0700
@@ -3,7 +3,7 @@
   proc.c - Proc, Binding, Env
 
   $Author: brent $
-  $Date: 2007/10/09 23:16:55 $
+  $Date: 2007/10/11 01:03:08 $
   created at: Wed Jan 17 12:13:14 2007
 
   Copyright (C) 2004-2007 Koichi Sasada
@@ -470,6 +470,53 @@
     return FIX2INT(proc_arity(proc));
 }
 
+
+static rb_iseq_t *
+get_proc_iseq(VALUE self)
+{
+    rb_proc_t *proc;
+    rb_iseq_t *iseq;
+    GetProcPtr(self, proc);
+    iseq = proc->block.iseq;
+    if (RUBY_VM_NORMAL_ISEQ_P(iseq))
+        return iseq;
+    rb_raise(rb_eTypeError, "(Native?) Proc has no Ruby source");
+}
+
+
+/*
+ * call-seq:
+ *    prc.__file__  => String  
+ *
+ * returns the ruby source filename containing this proc
+ * raises TypeError if this proc was not defined in ruby (i.e. native)
+ */
+ 
+static VALUE
+proc_filename(VALUE self)
+{
+    return get_proc_iseq(self)->filename;
+}
+
+
+/*
+ * call-seq:
+ *    prc.__line__  => Fixnum  
+ *
+ * returns the starting ruby source lineno of this proc or nil if none known
+ * raises TypeError if this proc was not defined in ruby (i.e. native)
+ */
+ 
+static VALUE
+proc_line_no(VALUE self)
+{
+    rb_iseq_t *iseq = get_proc_iseq(self);
+    if (!iseq->insn_info_table)
+        return Qnil;
+    return INT2FIX(iseq->insn_info_table[0].line_no);
+}
+
+
 /*
  * call-seq:
  *   prc == other_proc   =>  true or false
@@ -1256,6 +1303,57 @@
     return rb_mod_method_arity(CLASS_OF(obj), id);
 }
 
+
+
+static rb_iseq_t *
+get_method_iseq(VALUE method)
+{
+    struct METHOD *data;
+    NODE *body;
+    Data_Get_Struct(method, struct METHOD, data);
+    body=data->body;
+    if (nd_type(body) == RUBY_VM_METHOD_NODE) {
+        rb_iseq_t *iseq;
+        GetISeqPtr((VALUE)body->nd_body, iseq);
+        if (RUBY_VM_NORMAL_ISEQ_P(iseq))
+          return iseq;
+    }
+    rb_raise(rb_eTypeError, "(Native?) Method has no Ruby source");
+}
+
+/*
+ * call-seq:
+ *    meth.__file__  => String  
+ *
+ * returns the ruby source filename containing this method's definition
+ * raises TypeError if this method was not defined in ruby (i.e. native)
+ */
+ 
+static VALUE
+method_filename(VALUE method)
+{
+    return get_method_iseq(method)->filename;
+}
+
+
+/*
+ * call-seq:
+ *    meth.__line__  => Fixnum  
+ *
+ * returns the starting ruby source lineno of this method of nil if unknown
+ * raises TypeError if this method was not defined in ruby (i.e. native)
+ */
+ 
+static VALUE
+method_line_no(VALUE method)
+{
+    rb_iseq_t *iseq = get_method_iseq(method);
+    if (!iseq->insn_info_table)
+        return Qnil;  
+    return INT2FIX(iseq->insn_info_table[0].line_no);
+}
+
+
 /*
  *  call-seq:
  *   meth.to_s      =>  string
@@ -1450,6 +1548,8 @@
     rb_define_method(rb_cProc, "hash", proc_hash, 0);
     rb_define_method(rb_cProc, "to_s", proc_to_s, 0);
     rb_define_method(rb_cProc, "lambda?", proc_lambda_p, 0);
+    rb_define_method(rb_cProc, "__file__", proc_filename, 0);
+    rb_define_method(rb_cProc, "__line__", proc_line_no, 0);
 
     /* Exceptions */
     rb_eLocalJumpError = rb_define_class("LocalJumpError", rb_eStandardError);
@@ -1484,6 +1584,8 @@
     rb_define_method(rb_cMethod, "owner", method_owner, 0);
     rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
     rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
+    rb_define_method(rb_cMethod, "__file__", method_filename, 0);
+    rb_define_method(rb_cMethod, "__line__", method_line_no, 0);    
 
     /* UnboundMethod */
     rb_cUnboundMethod = rb_define_class("UnboundMethod", rb_cObject);
@@ -1499,6 +1601,8 @@
     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, "__file__", method_filename, 0);
+    rb_define_method(rb_cUnboundMethod, "__line__", method_line_no, 0);    
 
     /* Module#*_method */
     rb_define_method(rb_cModule, "instance_method", rb_mod_method, 1);

In This Thread

Prev Next