[#26488] Add Standard Deviation Function to Math Module — Daniel Cohen <danielc2017@...>

This patch adds a Standard Deviation function to the Math Module. It takes

25 messages 2009/11/02
[#26489] Re: Add Standard Deviation Function to Math Module — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26490] Re: Add Standard Deviation Function to Math Module — Daniel Cohen <danielc2017@...> 2009/11/03

OK,

[#26493] Re: Add Standard Deviation Function to Math Module — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26511] Re: Add Standard Deviation Function to Math Module — Yusuke ENDOH <mame@...> 2009/11/03

Hi,

[#26492] HashWithIndifferentAccess to core — Urabe Shyouhei <shyouhei@...>

Hello,

35 messages 2009/11/03
[#26496] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26507] Re: HashWithIndifferentAccess to core — Jeremy Kemper <jeremy@...> 2009/11/03

On Tue, Nov 3, 2009 at 6:48 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wro=

[#26514] Re: HashWithIndifferentAccess to core — "Martin J. Dst" <duerst@...> 2009/11/04

Just a thought: What about implementing this with an option on Hash:new,

[#26522] Re: HashWithIndifferentAccess to core — Yusuke ENDOH <mame@...> 2009/11/04

Hi,

[#26555] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/05

Hi,

[#26584] Re: HashWithIndifferentAccess to core — Yugui <yugui@...> 2009/11/07

2009/11/6 Yukihiro Matsumoto <matz@ruby-lang.org>:

[#26589] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/07

Hi,

[#26593] Re: HashWithIndifferentAccess to core — Lourens Naud<lourens@...> 2009/11/07

Hi,

[#26523] [Bug #2330] Non systematic segmentation fault with autoload rubyspec — Marc-Andre Lafortune <redmine@...>

Bug #2330: Non systematic segmentation fault with autoload rubyspec

12 messages 2009/11/04

[#26560] [Feature #2340] Removing YAML/Syck — Yui NARUSE <redmine@...>

Feature #2340: Removing YAML/Syck

38 messages 2009/11/06
[#26562] [Feature #2340] Removing YAML/Syck — Yui NARUSE <redmine@...> 2009/11/06

Issue #2340 has been updated by Yui NARUSE.

[#26567] Re: [Feature #2340] Removing YAML/Syck — James Edward Gray II <james@...> 2009/11/06

On Nov 6, 2009, at 4:02 AM, Yui NARUSE wrote:

[#26568] Re: [Feature #2340] Removing YAML/Syck — Jon <jon.forums@...> 2009/11/06

> > Issue #2340 has been updated by Yui NARUSE.

[#26571] Re: [Feature #2340] Removing YAML/Syck — "NARUSE, Yui" <naruse@...> 2009/11/06

Jon wrote:

[#26574] Re: [Feature #2340] Removing YAML/Syck — Aaron Patterson <aaron@...> 2009/11/06

On Sat, Nov 07, 2009 at 12:59:25AM +0900, NARUSE, Yui wrote:

[#26635] [Feature #2348] RBTree Should be Added to the Standard Library — James Gray <redmine@...>

Feature #2348: RBTree Should be Added to the Standard Library

20 messages 2009/11/08
[#28842] [Feature #2348] RBTree Should be Added to the Standard Library — James Gray <redmine@...> 2010/03/21

Issue #2348 has been updated by James Gray.

[#26650] [Feature #2350] Unicode specific functionality on String in 1.9 — Manfred Stienstra <redmine@...>

Feature #2350: Unicode specific functionality on String in 1.9

12 messages 2009/11/09
[#28985] [Feature #2350](Rejected) Unicode specific functionality on String in 1.9 — Yusuke Endoh <redmine@...> 2010/03/25

Issue #2350 has been updated by Yusuke Endoh.

[#28993] Re: [Feature #2350](Rejected) Unicode specific functionality on String in 1.9 — Nikolai Weibull <now@...> 2010/03/25

On Thu, Mar 25, 2010 at 14:45, Yusuke Endoh <redmine@ruby-lang.org> wrote:

[#26704] Maintainer confirmation process done. — "Yugui (Yuki Sonoda)" <yugui@...>

I'm sorry for my closing the maintainer confirmation process so late.

13 messages 2009/11/12

[#26736] [Bug #2365] Matrix: poor handling of coercion errors [patch] — Marc-Andre Lafortune <redmine@...>

Bug #2365: Matrix: poor handling of coercion errors [patch]

12 messages 2009/11/14

[#26772] [Bug #2378] Regression in ParseDate.parsedate('nn-nn') — Vladimir Sizikov <redmine@...>

Bug #2378: Regression in ParseDate.parsedate('nn-nn')

10 messages 2009/11/16

[#26774] Ruby constant lookup — Yehuda Katz <wycats@...>

Over the past six months or so, I have been working with the new Ruby 1.9

22 messages 2009/11/16
[#26775] Re: Ruby constant lookup — Shugo Maeda <shugo@...> 2009/11/17

Hi,

[#26777] Re: Ruby constant lookup — Yehuda Katz <wycats@...> 2009/11/17

Shugo,

[#26778] Re: Ruby constant lookup — Shugo Maeda <shugo@...> 2009/11/17

Hi,

[#26869] Caching #to_s for immutables (and a possible future for constant-folding) — Kurt Stephens <ks@...>

I have a proof-of-concept patch to MRI that caches #to_s values for

16 messages 2009/11/23
[#26936] Re: Caching #to_s for immutables (and a possible future for constant-folding) — Roger Pack <rogerdpack@...> 2009/11/29

> =A0It reduces the number of #to_s Strings created during the MRI test sui=

[#26958] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Kurt Stephens <ks@...> 2009/11/30

The attached patch add caching of #to_s results to the main immutable

[#26960] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Roger Pack <rogerdpack@...> 2009/11/30

> Yes. =A0The MRI test suite runs at 45 sec with these changes and at 53 se=

[#26963] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Kurt Stephens <ks@...> 2009/11/30

I just ran rubyspec against it; ~ 5% time improvement.

[ruby-core:26775] Re: Ruby constant lookup

From: Shugo Maeda <shugo@...>
Date: 2009-11-17 02:41:47 UTC
List: ruby-core #26775
Hi,

At Tue, 17 Nov 2009 06:48:42 +0900,
Yehuda Katz <wycats@gmail.com> wrote:
> For instance, you can do the following in Rails:
> 
> module ActionController::MimeResponds
>   extend ActiveSupport::Concern
> 
>     included do
>       inheritable_accessor :responder, :mimes_for_respond_to,
> :instance_writer => false
>       self.responder = ActionController::Responder
>       clear_respond_to
>     end
> end

Do you mean that `self.responder = ActionController::Responder' can be replaced
by `self.responder = Responder' on Ruby 1.8?

Then, does it really work on Ruby 1.8?
I guess MimeResponds should be nested in ActionController as follows:

module ActionController
  module MimeResponds
    ...
  end
end

> > This is a wrapper around the very common:
> 
> def self.included(klass)
>   klass.class_eval do
>     # code here
>   end
> end
 
For Matz and Koichi (and other people who aren't familiar with Rails),
included and append_features are overridden in ActiveSupport::Concern
as follows:

    def included(base = nil, &block)
      if base.nil?
        @_included_block = block
      else
        super
      end
    end

    def append_features(base)
      if super
        ...
        base.class_eval(&@_included_block) if instance_variable_defined?("@_incl
uded_block")
      end
    end

> Because I understand the utility in the Ruby 1.9 approach, I would like to
> suggest that users be allowed to choose which scoping they want. I suggest
> that module_eval, by default, revert to Ruby 1.8 behavior. I also suggest
> that we add a new method (or flag to module_eval) to enable the new
> behavior.

I basically prefer the behavior of Ruby 1.9.  I think class variables
should especially be lookuped like Ruby 1.9 because they can't be
accessed outside of a class or its instance.  Then, I guess your
problem may be able to fixed differently.

The problem is not that Ruby 1.9 prepends the receiver of class_eval to
the constant lookup path, but that a wrapper of class_eval can't be
implemented on Ruby 1.9.

The following program works on both Ruby 1.8 and 1.9:

class Foo
end

module ActionController
  Responder = "This is a Responder"
  module MimeResponds
    Foo.class_eval do
      p Responder
    end
  end
end

However, the following program doesn't work on Ruby 1.9:

def my_class_eval(klass, &block)
  klass.class_eval(&block)
end

class Foo
end

module ActionController
  Responder = "This is a Responder"
  module MimeResponds
    my_class_eval(Foo) do
      p Responder
    end
  end
end

It's because class_eval prepends the reciver to the constant lookup
path at the time of invocation of class_eval.  I think it should
prepends the receiver to the constant lookup path which the given block
holds.

I have attached a patch to fix it.  If it's acceptable, I'll write a
test and commit them.

-- 
Shugo Maeda <shugo@ruby-lang.org>

Attachments (1)

class_eval.diff (2.86 KB, text/x-diff)
Index: insns.def
===================================================================
--- insns.def	(revision 25805)
+++ insns.def	(working copy)
@@ -944,7 +944,7 @@ defineclass
 	rb_bug("unknown defineclass type: %d", (int)define_type);
     }
 
-    COPY_CREF(class_iseq->cref_stack, vm_cref_push(th, klass, NOEX_PUBLIC));
+    COPY_CREF(class_iseq->cref_stack, vm_cref_push(th, klass, NOEX_PUBLIC, NULL));
 
     /* enter scope */
     vm_push_frame(th, class_iseq,
Index: vm_eval.c
===================================================================
--- vm_eval.c	(revision 25805)
+++ vm_eval.c	(working copy)
@@ -17,7 +17,7 @@ static inline VALUE vm_yield_with_cref(rb_thread_t
 static inline VALUE vm_yield(rb_thread_t *th, int argc, const VALUE *argv);
 static inline VALUE vm_backtrace(rb_thread_t *th, int lev);
 static int vm_backtrace_each(rb_thread_t *th, int lev, rb_backtrace_iter_func *iter, void *arg);
-static NODE *vm_cref_push(rb_thread_t *th, VALUE klass, int noex);
+static NODE *vm_cref_push(rb_thread_t *th, VALUE klass, int noex, rb_block_t *blockptr);
 static VALUE vm_exec(rb_thread_t *th);
 static void vm_set_eval_stack(rb_thread_t * th, VALUE iseqval, const NODE *cref);
 static int vm_collect_local_variables_in_heap(rb_thread_t *th, VALUE *dfp, VALUE ary);
@@ -1100,13 +1100,14 @@ yield_under(VALUE under, VALUE self, VALUE values)
 {
     rb_thread_t *th = GET_THREAD();
     rb_block_t block, *blockptr;
-    NODE *cref = vm_cref_push(th, under, NOEX_PUBLIC);
+    NODE *cref;
 
     if ((blockptr = GC_GUARDED_PTR_REF(th->cfp->lfp[0])) != 0) {
 	block = *blockptr;
 	block.self = self;
 	th->cfp->lfp[0] = GC_GUARDED_PTR(&block);
     }
+    cref = vm_cref_push(th, under, NOEX_PUBLIC, &block);
 
     if (values == Qundef) {
 	return vm_yield_with_cref(th, 0, 0, cref);
@@ -1120,7 +1121,7 @@ yield_under(VALUE under, VALUE self, VALUE values)
 static VALUE
 eval_under(VALUE under, VALUE self, VALUE src, const char *file, int line)
 {
-    NODE *cref = vm_cref_push(GET_THREAD(), under, NOEX_PUBLIC);
+    NODE *cref = vm_cref_push(GET_THREAD(), under, NOEX_PUBLIC, NULL);
 
     if (rb_safe_level() >= 4) {
 	StringValue(src);
Index: vm_insnhelper.c
===================================================================
--- vm_insnhelper.c	(revision 25805)
+++ vm_insnhelper.c	(working copy)
@@ -1066,14 +1066,17 @@ vm_get_cref(const rb_iseq_t *iseq, const VALUE *lf
 }
 
 static NODE *
-vm_cref_push(rb_thread_t *th, VALUE klass, int noex)
+vm_cref_push(rb_thread_t *th, VALUE klass, int noex, rb_block_t *blockptr)
 {
     rb_control_frame_t *cfp = vm_get_ruby_level_caller_cfp(th, th->cfp);
     NODE *cref = NEW_BLOCK(klass);
     cref->nd_file = 0;
     cref->nd_visi = noex;
 
-    if (cfp) {
+    if (blockptr) {
+	cref->nd_next = vm_get_cref(blockptr->iseq, blockptr->lfp, blockptr->dfp);
+    }
+    else if (cfp) {
 	cref->nd_next = vm_get_cref(cfp->iseq, cfp->lfp, cfp->dfp);
     }
 

In This Thread