[#64703] Add `Hash#fetch_at` (issue #10017) — Wojtek Mach <wojtek@...>
Hey guys
1 message
2014/09/01
[#64711] [ruby-trunk - Bug #10193] [Closed] TestIO#test_readpartial_locktmp fails randomly — nobu@...
Issue #10193 has been updated by Nobuyoshi Nakada.
3 messages
2014/09/02
[#64744] [ruby-trunk - Bug #10202] [Open] TestBenchmark#test_realtime_output breaks on ARM — v.ondruch@...
Issue #10202 has been reported by Vit Ondruch.
3 messages
2014/09/03
[#64823] documenting constants — Xavier Noria <fxn@...>
I am writing a Rails guide about constant autoloading in Ruby on
5 messages
2014/09/07
[#64838] [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus — ko1@...
Issue #10212 has been reported by Koichi Sasada.
6 messages
2014/09/08
[#64858] Re: [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus
— Eric Wong <normalperson@...>
2014/09/08
rb_env_t may use a flexible array, helps a little even on my busy system:
[#64871] Re: [ruby-trunk - Bug #10212] [Open] MRI is not for lambda calculus
— SASADA Koichi <ko1@...>
2014/09/08
(2014/09/08 19:48), Eric Wong wrote:
[#64972] [ruby-trunk - Bug #10231] [Open] Process.detach(pid) defines new singleton classes every call — headius@...
Issue #10231 has been reported by Charles Nutter.
3 messages
2014/09/11
[#64980] [ruby-trunk - Bug #10212] MRI is not for lambda calculus — ko1@...
Issue #10212 has been updated by Koichi Sasada.
4 messages
2014/09/12
[#65142] [ruby-trunk - Feature #10267] [Open] Number of processors — akr@...
Issue #10267 has been reported by Akira Tanaka.
4 messages
2014/09/20
[#65144] Re: [ruby-trunk - Feature #10267] [Open] Number of processors
— Eric Wong <normalperson@...>
2014/09/20
akr@fsij.org wrote:
[#65210] [ruby-trunk - misc #10278] [Assigned] [RFC] st.c: use ccan linked list — nobu@...
Issue #10278 has been updated by Nobuyoshi Nakada.
3 messages
2014/09/22
[ruby-core:64995] Re: [ruby-trunk - Bug #10212] MRI is not for lambda calculus
From:
Eric Wong <normalperson@...>
Date:
2014-09-12 10:22:04 UTC
List:
ruby-core #64995
SASADA Koichi <ko1@atdot.net> wrote:
> (2014/09/12 19:03), Eric Wong wrote:
> > Yes, I think the following API is OK. rb_proc_t is big.
> > The new inline rb_proc_alloc() takes 7(!) parameters.
> > Maybe we can drop klass since that is always rb_cProc.
>
> Nice.
>
> Additionally, I recommend to move the definition from vm_core.h to vm.c
OK, I think I'll move the inline to vm.c
> (and expose it) because proc_dup() in proc.c is minor function.
But exposing it seems worse, even. In other words: the new rb_proc_alloc
is the wrong interface for rb_proc_dup. I like the following much
more (still using rb_proc_wrap):
--- a/proc.c
+++ b/proc.c
@@ -106,12 +106,13 @@ rb_obj_is_proc(VALUE proc)
static VALUE
proc_dup(VALUE self)
{
- rb_proc_t *src;
+ rb_proc_t *src, *dst;
GetProcPtr(self, src);
- return rb_proc_alloc(rb_cProc, &src->block, src->envval, src->blockprocval,
- src->safe_level, src->is_from_method, src->is_lambda);
+ dst = ALLOC(rb_proc_t);
+ *dst = *src;
+ return rb_proc_wrap(rb_cProc, dst);
}
/* :nodoc: */