[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66165] [ruby-trunk - Feature #10195] [Open] Alternative to rb_proc_new that provides access to self, super and passed block
From:
nobu@...
Date:
2014-11-10 04:55:10 UTC
List:
ruby-core #66165
Issue #10195 has been updated by Nobuyoshi Nakada.
Description updated
Status changed from Closed to Open
Passed block is passed as the fifth argument, as the test in r48350.
----------------------------------------
Feature #10195: Alternative to rb_proc_new that provides access to self, super and passed block
https://bugs.ruby-lang.org/issues/10195#change-49864
* Author: Charles Strahan
* Status: Open
* Priority: Normal
* Assignee:
* Category:
* Target version:
----------------------------------------
I'm developing a Haskell binding to the Ruby C API. Unfortunately, `rb_proc_new`
does not provide any means of accessing super, self and/or any passed block. A
better alternative to `rb_proc_new` would make it possible to create procs from
C/Haskell/etc that can access `self`/`super`/&`block`.
I'm currently hacking around this lacking in the C API by creating a closure
from the Ruby side that closes over self et al - a trampoline of sorts:
~~~
rupee_proc_constructor_with_super = rb_eval_string_protect(
"Proc.new {|callable|\n"
" su = if defined?(super)\n"
" Proc.new {|*args,&blk| super(*args,&blk) }\n"
" else\n"
" nil\n"
" end\n"
" Proc.new {|*args,&blk|\n"
" callable.call(self, su, *args, &blk)\n"
" }\n"
"}",
&status);
~~~
From the Haskell side, I then pass in the `callable' object, where `callable#call`
is implemented in Haskell. This is pretty clunky/slow, and also creates
unintuitive behavior from the Haskell side. It would be ideal for the C API to
support this natively.
--
https://bugs.ruby-lang.org/