[#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] Valgrind support

From: Tilman Sauerbeck <tilman@...>
Date: 2005-09-08 16:26:08 UTC
List: ruby-core #5740
On Thu, 8 Sep 2005 06:58:29 +0900 nobu.nokada@softhome.net wrote:

> At Thu, 8 Sep 2005 04:13:29 +0900,
> Tilman Sauerbeck wrote in [ruby-core:05729]:
> > This seems to work very well, maybe too well - it might hide
> > real bugs. It's way less painful than suppression files, but
> > requires you to recompile Ruby.
> 
> How better than suppression files?

Once you have a *perfect* suppression file there might not be any difference at all.
But producing this perfect suppression file for Ruby is a PITA ;)

> > Please comment. If you think it's useful, maybe it can be
> > merged? Of course ./configure should check whether Valgrind
> > is available + some #ifdef magic for the macros etc.
> > 
> > Patch made against 1.8.3-preview1.
> 
> Patch with a configuration flag and those checks against trunc
> HEAD.  To enable Valgrind support, you need to add -I option
> for appropriate path to CPPFLAGS.  This can be applied also to
> 1.8 branch.

I attached another patch, with the autoconf stuff done properly :o
No need to set CPPFLAGS manually. If Valgrind support is requested explicitly (by adding --enable-valgrind on the command line), configure will abort if Valgrind cannot be found. Otherwise, it's just the usual autodetect mode.

Regards,
Tilman

-- 
learn to quote: http://www.netmeister.org/news/learn2quote.html

Attachments (1)

ruby-valgrind2.diff (2.27 KB, text/x-diff)
diff -aur ruby-1.8.3.orig/Makefile.in ruby-1.8.3/Makefile.in
--- ruby-1.8.3.orig/Makefile.in	2005-04-20 16:25:31.000000000 +0200
+++ ruby-1.8.3/Makefile.in	2005-09-08 08:15:59.000000000 +0200
@@ -31,9 +31,9 @@
 RIDATADIR = $(DESTDIR)$(datadir)/ri/$(MAJOR).$(MINOR)/system
 
 OUTFLAG = -o 
-CFLAGS = @CFLAGS@ @XCFLAGS@ @ARCH_FLAG@
+CFLAGS = @CFLAGS@ @XCFLAGS@ @ARCH_FLAG@ @VALGRIND_CFLAGS@
 CPPFLAGS = -I. -I$(srcdir) @CPPFLAGS@
-LDFLAGS = @STATIC@ $(CFLAGS) @LDFLAGS@
+LDFLAGS = @STATIC@ $(CFLAGS) @LDFLAGS@ @VALGRIND_LIBS@
 EXTLDFLAGS = 
 XLDFLAGS = @XLDFLAGS@ $(EXTLDFLAGS)
 EXTLIBS = 
diff -aur ruby-1.8.3.orig/configure.in ruby-1.8.3/configure.in
--- ruby-1.8.3.orig/configure.in	2005-04-16 08:27:43.000000000 +0200
+++ ruby-1.8.3/configure.in	2005-09-08 08:54:21.000000000 +0200
@@ -754,6 +754,20 @@
     fi
 fi
 
+AC_ARG_ENABLE(valgrind,
+       [  --enable-valgrind       use valgrind support.],
+       [want_valgrind=$enableval], [want_valgrind=auto])
+
+if test x"$want_valgrind" != xno; then
+	PKG_CHECK_MODULES(VALGRIND, valgrind, have_valgrind=yes, have_valgrind=no)
+
+	if test x"$have_valgrind" = xyes; then
+		AC_DEFINE(HAVE_VALGRIND)
+	elif test x"$want_valgrind" = xyes -a x"$have_valgrind" = xno; then
+		AC_MSG_ERROR(valgrind support requested but valgrind not found)
+	fi
+fi
+
 dnl default value for $KANJI
 DEFAULT_KCODE="KCODE_NONE"
 
diff -aur ruby-1.8.3.orig/gc.c ruby-1.8.3/gc.c
--- ruby-1.8.3.orig/gc.c	2005-01-20 10:34:36.000000000 +0100
+++ ruby-1.8.3/gc.c	2005-09-08 08:17:48.000000000 +0200
@@ -30,6 +30,12 @@
 #include <sys/resource.h>
 #endif
 
+#ifdef HAVE_VALGRIND
+#include <memcheck.h>
+#else
+#define VALGRIND_MAKE_READABLE(p, n) /* empty */
+#endif
+
 #ifdef __ia64__
 #include <ucontext.h>
 #if defined(__FreeBSD__)
@@ -620,6 +626,9 @@
     register long n;
 {
     VALUE v;
+
+    VALGRIND_MAKE_READABLE(x, sizeof(*x) * n);
+
     while (n--) {
         v = *x;
 	if (is_pointer_to_heap((void *)v)) {
@@ -710,7 +719,10 @@
 {
     register RVALUE *obj;
 
+    VALGRIND_MAKE_READABLE(&ptr, sizeof(ptr));
     obj = RANY(ptr);
+    VALGRIND_MAKE_READABLE(obj, sizeof(*obj));
+
     if (rb_special_const_p(ptr)) return; /* special const not marked */
     if (obj->as.basic.flags == 0) return;       /* free cell */
     if (obj->as.basic.flags & FL_MARK) return;  /* already marked */ 

In This Thread

Prev Next