[#5737] returning strings from methods/instance_methods — TRANS <transfire@...>

I was just wondering why with #methods and #instance_methods, it was

11 messages 2005/09/08

[#5796] proposed attr writer patch — Daniel Berger <Daniel.Berger@...>

Hi all,

18 messages 2005/09/16

[#5798] Makefile error in OpenSLL extension (on Windows) — noreply@...

Bugs item #2472, was opened at 2005-09-16 18:56

11 messages 2005/09/17
[#5800] Re: [ ruby-Bugs-2472 ] Makefile error in OpenSLL extension (on Windows) — nobu.nokada@... 2005/09/17

Hi,

[#5851] Re: RubyGems in Ruby HEAD — Paul van Tilburg <paul@...>

Hi all,

34 messages 2005/09/21
[#5867] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/21

Paul van Tilburg wrote:

[#5870] Re: RubyGems in Ruby HEAD — Marc Dequènes (Duck) <Duck@...> 2005/09/21

[#5920] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/22

Marc Dequ竪nes (Duck) wrote:

[#5926] Re: RubyGems in Ruby HEAD — Pascal Terjan <pterjan@...> 2005/09/23

On 9/22/05, mathew <meta@pobox.com> wrote:

[#5931] Re: RubyGems in Ruby HEAD — Austin Ziegler <halostatue@...> 2005/09/23

On 9/23/05, Pascal Terjan <pterjan@gmail.com> wrote:

[#5898] Delegate and Forwardable Documentation — James Edward Gray II <james@...>

I've tried to send these files through a couple of times now with

17 messages 2005/09/22
[#5911] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/22

On Sep 22, 2005, at 9:02 AM, James Edward Gray II wrote:

[#5924] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 22, 2005, at 11:53 AM, James Edward Gray II wrote:

[#5941] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5942] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 23, 2005, at 10:54 AM, Yukihiro Matsumoto wrote:

[#5947] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5921] Mutually dependent libs double loading. — TRANS <transfire@...>

I'm on Ruby 1.8.2.

14 messages 2005/09/23
[#5923] Re: Mutually dependent libs double loading. — Florian Gro<florgro@...> 2005/09/23

TRANS wrote:

[#5985] Finally an answer to my RubyGems question and some small suggestions — TRANS <transfire@...>

I appreciate those that attempted to offer me some info on this issue.

9 messages 2005/09/26

[#6001] Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...>

I've added namespaces to require. Works like this:

94 messages 2005/09/26
[#6002] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6003] Re: Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...> 2005/09/26

On 9/26/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6005] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6007] gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Sam Roberts <sroberts@...> 2005/09/26

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 06:02:07AM +0900:

[#6013] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6014] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 10:29:17AM +0900:

[#6015] Re: gems is a language change, not a pkging system — James Edward Gray II <james@...> 2005/09/27

On Sep 26, 2005, at 8:54 PM, Sam Roberts wrote:

[#6016] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting james@grayproductions.net, on Tue, Sep 27, 2005 at 11:06:01AM +0900:

[#6018] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6019] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 11:49:14AM +0900:

[#6024] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6025] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/27

> Right now, they're watching people who have pretty much sat on the side

[#6026] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Ralph Amissah <ralph.amissah@gmail.com> wrote:

[#6043] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/28

I'll greatly weaken my post, and give everyone the opportunity to head me

[#6044] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Ralph Amissah wrote:

[#6073] Re: gems is a language change, not a pkging system — Mauricio Fern疣dez <mfp@...> 2005/09/28

Hello,

[#6074] Re: gems is a language change, not a pkging system — Jim Weirich <jim@...> 2005/09/29

On Wednesday 28 September 2005 07:35 pm, Mauricio Fern疣dez wrote:

[#6017] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6046] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 22:41, Austin Ziegler wrote:

[#6050] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Sean E. Russell wrote:

[#6207] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/10/10

On Wednesday 28 September 2005 08:54, Hugh Sasse wrote:

[#6045] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 21:29, Austin Ziegler wrote:

[#6048] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Sean E. Russell <ser@germane-software.com> wrote:

[#6059] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

On 9/28/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6061] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Dominique Brezinski <dominique.brezinski@gmail.com> wrote:

[#6062] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

For what it is worth, I live life behind an authenticated proxy, so I

[#6099] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/30

On Wednesday 28 September 2005 08:43, Austin Ziegler wrote:

[#6009] Re: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...>

(i) correction, segfault is with official ruby 1.8.3 (2005-09-21), not

21 messages 2005/09/27
[#6010] Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...> 2005/09/27

[sorry for duplicate post]

[#6079] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "R" == Ralph Amissah <ralph.amissah@gmail.com> writes:

[#6081] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#6082] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Tanaka Akira <akr@...17n.org> 2005/09/29

In article <200509291419.j8TEJYid015419@moulon.inra.fr>,

Re: [PATCH] FW: Ruby 1.8.2 DTrace Support

From: nobuyoshi nakada <nobuyoshi.nakada@...>
Date: 2005-09-29 09:16:15 UTC
List: ruby-core #6077
Hi,

At Fri, 19 Aug 2005 04:36:36 +0900,
Paul Duncan wrote in [ruby-core:05557]:
> Richard Lowe (richlowe@richlowe.net) wrote this patch to add a DTrace
> provider into Ruby.  He's not subscribed to ruby-core, so he asked me to
> forward the patch and his description on to the list.

Tried applying to recent versions, but not sure at all.


Index: Makefile.in
===================================================================
RCS file: /cvs/ruby/src/ruby/Makefile.in,v
retrieving revision 1.75
diff -U2 -p -r1.75 Makefile.in
--- Makefile.in	6 Sep 2005 23:22:34 -0000	1.75
+++ Makefile.in	29 Sep 2005 07:43:07 -0000
@@ -40,4 +40,5 @@ EXTLIBS = 
 LIBS = @LIBS@ $(EXTLIBS)
 MISSING = @LIBOBJS@ @ALLOCA@
+MISCOBJS = @DTRACE_OBJS@
 LDSHARED = @LIBRUBY_LDSHARED@
 DLDFLAGS = @LIBRUBY_DLDFLAGS@ $(EXTLDFLAGS) @ARCH_FLAG@
@@ -167,2 +168,5 @@ distclean-local::
 ext/extinit.$(OBJEXT): ext/extinit.c $(SETUP)
 	$(CC) $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) -o$@ -c ext/extinit.c
+
+dtrace.$(OBJEXT): dtrace.d $(COREOBJS)
+	$(DTRACE) $(DTRACE_FLAGS) -o $@ -s dtrace.d $(COREOBJS)
Index: common.mk
===================================================================
RCS file: /cvs/ruby/src/ruby/common.mk,v
retrieving revision 1.20
diff -U2 -p -r1.20 common.mk
--- common.mk	3 Aug 2005 15:26:14 -0000	1.20
+++ common.mk	29 Sep 2005 07:36:28 -0000
@@ -13,5 +13,5 @@ EXTOBJS	      = 
 DLDOBJS	      = $(DMYEXT)
 
-OBJS	      = array.$(OBJEXT) \
+COREOBJS      = array.$(OBJEXT) \
 		ascii.$(OBJEXT) \
 		bignum.$(OBJEXT) \
@@ -59,4 +59,5 @@ OBJS	      = array.$(OBJEXT) \
 		version.$(OBJEXT) \
 		$(MISSING)
+OBJS	      = $(COREOBJS) $(MISCOBJS)
 
 SCRIPT_ARGS   =	--dest-dir="$(DESTDIR)" \
Index: configure.in
===================================================================
RCS file: /cvs/ruby/src/ruby/configure.in,v
retrieving revision 1.284
diff -U2 -p -r1.284 configure.in
--- configure.in	6 Sep 2005 23:22:34 -0000	1.284
+++ configure.in	29 Sep 2005 07:36:28 -0000
@@ -503,4 +503,16 @@ if test "$use_setreuid" = yes; then
     AC_DEFINE(USE_SETREGID)
 fi
+
+AC_CHECK_HEADER(sys/sdt.h)
+AC_ARG_ENABLE(dtrace,
+	[  --enable-dtrace	    enable DTrace support.],
+	[enable_dtrace=$enableval])
+if test "$enable_dtrace" = yes -a test "$ac_cv_header_sys_sdt_h" = yes; then
+    AC_DEFINE(ENABLE_DTRACE)
+    AC_SUBST(DTRACE_OBJS, ['dtrace.$(OBJEXT)'])
+    : ${DTRACE_FLAGS="-G -"`expr $ac_cv_sizeof_int \* 8`}
+    AC_SUBST(DTRACE_FLAGS)
+fi
+
 AC_STRUCT_TIMEZONE
 AC_CACHE_CHECK(for struct tm.tm_gmtoff, rb_cv_member_struct_tm_tm_gmtoff,
Index: dtrace.d
===================================================================
RCS file: dtrace.d
diff -N dtrace.d
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ dtrace.d	14 Sep 2005 08:40:45 -0000
@@ -0,0 +1,12 @@
+/* -*- Mode: C -*- */
+
+provider ruby {
+    probe function__entry(string, string, string, int);
+    probe function__return(string, string, string, int);
+};
+
+#pragma D attributes Evolving/Evolving/Common provider ruby provider
+#pragma D attributes Private/Private/Common provider ruby module
+#pragma D attributes Private/Private/Common provider ruby function
+#pragma D attributes Evolving/Evolving/Common provider ruby name
+#pragma D attributes Evolving/Evolving/Common provider ruby args
Index: eval.c
===================================================================
RCS file: /cvs/ruby/src/ruby/eval.c,v
retrieving revision 1.833
diff -U2 -p -r1.833 eval.c
--- eval.c	28 Sep 2005 15:58:01 -0000	1.833
+++ eval.c	29 Sep 2005 07:36:28 -0000
@@ -190,4 +190,11 @@ typedef jmp_buf rb_jmpbuf_t;
 #include <sys/stat.h>
 
+#ifdef ENABLE_DTRACE
+# include <sys/sdt.h>
+# define USE_DTRACE 1
+#else
+# define USE_DTRACE 0
+#endif
+
 VALUE rb_cProc;
 static VALUE rb_cBinding;
@@ -5570,5 +5577,24 @@ formal_assign(VALUE recv, NODE *node, in
 }
 
-static VALUE
+#ifdef ENABLE_DTRACE
+# define RB_DTRACE_PROBE_CALL(probe, klass, method, node) do {		\
+	if (node && node->nd_file) {					\
+	    char *classname = rb_class2name(klass);			\
+	    char *methodname = rb_id2name(method);			\
+	    if (classname && methodname) {				\
+		DTRACE_PROBE4(ruby, probe, classname, methodname,	\
+			      node->nd_file, nd_line(node));		\
+	    }								\
+	}								\
+    } while (0)
+#else
+# define RB_DTRACE_PROBE_CALL(probe, klass, method, node) ((void)0)
+#endif
+#define RB_DTRACE_PROBE_ENTRY(klass, method, node) \
+    RB_DTRACE_PROBE_CALL(function__entry, klass, method, node)
+#define RB_DTRACE_PROBE_RETURN(klass, method, node) \
+    RB_DTRACE_PROBE_CALL(function__return, klass, method, node)
+
+VALUE
 rb_call0(VALUE klass, VALUE recv, ID id, ID oid,
     int argc /* OK */, const VALUE *argv /* OK */, NODE *volatile body, int flags)
@@ -5622,9 +5648,12 @@ rb_call0(VALUE klass, VALUE recv, ID id,
 		       len, rb_class2name(klass), rb_id2name(id));
 	    }
-	    if (event_hooks) {
+	    if (USE_DTRACE || event_hooks) {
 		int state;
 
-		EXEC_EVENT_HOOK(RUBY_EVENT_C_CALL, ruby_current_node,
-				recv, id, klass);
+		if (!USE_DTRACE || event_hooks) {
+		    EXEC_EVENT_HOOK(RUBY_EVENT_C_CALL, ruby_current_node,
+				    recv, id, klass);
+		}
+		RB_DTRACE_PROBE_ENTRY(klass, id, ruby_current_node);
 		PUSH_TAG(PROT_FUNC);
 		if ((state = EXEC_TAG()) == 0) {
@@ -5633,11 +5662,16 @@ rb_call0(VALUE klass, VALUE recv, ID id,
 		POP_TAG();
 		ruby_current_node = ruby_frame->node;
-		EXEC_EVENT_HOOK(RUBY_EVENT_C_RETURN, ruby_current_node,
-				recv, id, klass);
+		RB_DTRACE_PROBE_RETURN(klass, id, ruby_current_node);
+		if (!USE_DTRACE || event_hooks) {
+		    EXEC_EVENT_HOOK(RUBY_EVENT_C_RETURN, ruby_current_node,
+				    recv, id, klass);
+		}
 		if (state) JUMP_TAG(state);
 	    }
+#if !USE_DTRACE
 	    else {
 		result = call_cfunc(body->nd_cfnc, recv, len, argc, argv);
 	    }
+#endif
 	}
 	break;
@@ -5716,4 +5750,5 @@ rb_call0(VALUE klass, VALUE recv, ID id,
 		}
 
+		RB_DTRACE_PROBE_ENTRY(klass, id, ruby_frame->prev->node);
 		if (event_hooks) {
 		    EXEC_EVENT_HOOK(RUBY_EVENT_CALL, b2, recv, id, klass);
@@ -5731,4 +5766,5 @@ rb_call0(VALUE klass, VALUE recv, ID id,
 	    ruby_cref = saved_cref;
 	    if (safe >= 0) ruby_safe_level = safe;
+	    RB_DTRACE_PROBE_RETURN(klass, id, ruby_frame->prev->node);
 	    if (event_hooks) {
 		EXEC_EVENT_HOOK(RUBY_EVENT_RETURN, body, recv, id, klass);


-- 
Nobu Nakada

In This Thread

Prev Next