[#3907] Obtaining mode information on an IO object — Jos Backus <jos@...>

The attached patch implements IO#mode. This method returns the mode the IO

17 messages 2004/12/06
[#3909] Re: [patch] Obtaining mode information on an IO object — nobu.nokada@... 2004/12/07

Hi,

[#3910] Re: [patch] Obtaining mode information on an IO object — Jos Backus <jos@...> 2004/12/07

On Tue, Dec 07, 2004 at 09:25:13AM +0900, nobu.nokada@softhome.net wrote:

[#3925] Re: [patch] Obtaining mode information on an IO object — James Britt <ruby@...> 2004/12/09

Jos Backus wrote:

[#4009] cgi.rb -- more GET/POST stuff — mde@...26.com

First of all, I think it would be great, as Eustaquio suggests, to

17 messages 2004/12/23
[#4016] Re: [PATCH] cgi.rb -- more GET/POST stuff — Francis Hwang <sera@...> 2004/12/24

GETs and POSTs are defined to be fairly different actions. I'd read

[#4027] Allowing custom number literal suffixes? — Florian Gro<florgro@...>

Moin!

35 messages 2004/12/27
[#4070] Re: Allowing custom number literal suffixes? — nobu.nokada@... 2005/01/02

Hi,

[#4072] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/02

[#4079] Re: Allowing custom number literal suffixes? — Florian Gro<florgro@...> 2005/01/03

Mathieu Bouchard wrote:

[#4081] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/03

[#4082] Re: Allowing custom number literal suffixes? — Florian Gro<florgro@...> 2005/01/03

Mathieu Bouchard wrote:

[#4084] Re: Allowing custom number literal suffixes? — Brent Roman <brent@...> 2005/01/04

I'm not sure I would advocate making Ruby's grammar even more

[#4086] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/04

[#4033] Garbage collection trouble — Christian Neukirchen <chneukirchen@...>

Hello,

13 messages 2004/12/27

Re: [1.9, 1.8] super

From: Shugo Maeda <shugo@...>
Date: 2004-12-03 18:55:39 UTC
List: ruby-core #3882
Hi,

ts wrote:
> S> Program received signal SIGSEGV, Segmentation fault.
> S> 0xb7f3ead7 in proc_invoke (proc=3084300296, args=3, self=6, klass=0)
> S>      at eval.c:8166
> S> 8166        _block.frame.argc = RARRAY(args)->len;
> 
>  This is why, in the patch to 1.9, it use `tmp' rather than `args'

Thank you.
The following patch worked.

Index: eval.c
===================================================================
RCS file: /var/cvs/src/ruby/eval.c,v
retrieving revision 1.616.2.74
diff -u -r1.616.2.74 eval.c
--- eval.c	3 Dec 2004 09:30:32 -0000	1.616.2.74
+++ eval.c	3 Dec 2004 18:54:13 -0000
@@ -8139,6 +8139,7 @@
     volatile int safe = ruby_safe_level;
     volatile VALUE old_wrapper = ruby_wrapper;
     volatile int pcall, avalue = Qtrue;
+    volatile VALUE tmp = args;

     if (rb_block_given_p() && ruby_frame->last_func) {
 	if (klass != ruby_frame->last_class)
@@ -8163,9 +8164,9 @@
     _block = *data;
     if (self != Qundef) _block.frame.self = self;
     if (klass) _block.frame.last_class = klass;
-    _block.frame.argc = RARRAY(args)->len;
-    _block.frame.argv = ALLOCA_N(VALUE, RARRAY(args)->len);
-    MEMCPY(_block.frame.argv, RARRAY(args)->ptr, VALUE, RARRAY(args)->len);
+    _block.frame.argc = RARRAY(tmp)->len;
+    _block.frame.argv = ALLOCA_N(VALUE, RARRAY(tmp)->len);
+    MEMCPY(_block.frame.argv, RARRAY(tmp)->ptr, VALUE, RARRAY(tmp)->len);
     _block.frame.flags = FRAME_ALLOCA;
     ruby_block = &_block;

In This Thread

Prev Next