* Make it correctly handle lambdas
* Make it iterate over the block if block is given
The original implementation was flawed, based on lazy_set_method
instead of lazy_add_method.
Note that there is no implicit map when passing a block, the return
value of the block passed to with_index is ignored, just as it
is for Enumerator#with_index. Also like Enumerator#with_index,
when called with a block, the return value is an enumerator without
the index.
Fixes [Bug #16414]
Previously, lambdas were converted to procs because of how
rb_block_call works. Switch to rb_funcall_with_block, which
handles procs as procs and lambdas as lambdas.
Fixes [Bug #15613]
This removes the related tests, and puts the related specs behind
version guards. This affects all code in lib, including some
libraries that may want to support older versions of Ruby.
Currently, there is not a way to create a sized enumerator in C
with a different set of arguments than provided by Ruby, and
correctly handle keyword arguments. This function allows that.
The need for this is fairly uncommon, but it occurs at least in
Enumerator.produce, which takes arugments from Ruby but calls
rb_enumeratorize_with_size with a different set of arguments.
This fixes instance_exec and similar methods. It also fixes
Enumerator::Yielder#yield, rb_yield_block, and a couple of cases
with Proc#{<<,>>}.
This support requires the addition of rb_yield_values_kw, similar to
rb_yield_values2, for passing the keyword flag.
Unlike earlier attempts at this, this does not modify the rb_block_call_func
type or add a separate function type. The functions of type
rb_block_call_func are called by Ruby with a separate VM frame, and we can
get the keyword flag information from the VM frame flags, so it doesn't need
to be passed as a function argument.
These changes require the following VM functions accept a keyword flag:
* vm_yield_with_cref
* vm_yield
* vm_yield_with_block
When Object#to_enum is passed a block, the block is called to get
a size with the arguments given to to_enum. This calls the block
with the same keyword flag as to_enum is called with.
This requires adding rb_check_funcall_kw and
rb_check_funcall_default_kw to handle keyword flags.
Remove rb_add_empty_keyword, and instead of calling that every
place you need to add empty keyword hashes, run that code in
a single static function in vm_eval.c.
Add 4 defines to include/ruby/ruby.h, these are to be used as
int kw_splat values when calling the various rb_*_kw functions:
RB_NO_KEYWORDS :: Do not pass keywords
RB_PASS_KEYWORDS :: Pass final argument (which should be hash) as keywords
RB_PASS_EMPTY_KEYWORDS :: Add an empty hash to arguments and pass as keywords
RB_PASS_CALLED_KEYWORDS :: Passes same keyword type as current method was
called with (for method delegation)
rb_empty_keyword_given_p needs to stay. It is required if argument
delegation is done but delayed to a later point, which Enumerator
does.
Use RB_PASS_CALLED_KEYWORDS in rb_call_super to correctly
delegate keyword arguments to super method.
This makes objects created via #to_enum and related methods pass
keyword arguments as keywords.
To implement this, add a kw_splat member of struct enumerator and
struct iter_method_arg, and add rb_block_call_kw, which is the
same as rb_block_call_kw with a flag for whether the last argument
is keyword options.
Previously, passing to_enum/enum_for a method that was defined in
Lazy itself returned wrong results:
[1,2,3].to_enum(:map).to_a
# => [1, 2, 3]
[1,2,3].lazy.to_enum(:map).to_a
# => []
I'm not sure why methods that are designed to be lazy do not work
with to_enum/enum_for. However, one possible way to work around
this bug is to have to_enum/enum_for use the implementation found
in Enumerable/Enumerator, which is what this commit does.
While this commit works around the problem, it is a band-aid, not a
real fix. It doesn't handle aliases of Enumerable::Lazy methods,
for instance. A better fix would be appreciated.
Previously, Enumerator::Lazy#with_index was not defined, so it
picked up the default implementation from Enumerator, which was
not lazy.
Based on earlier patch from nobu.
Fixes [Bug #7877]
Previously, Enumerator::Lazy#with_index was not defined, so it
picked up the default implementation from Enumerator, which was
not lazy.
Based on earlier patch from nobu.
Fixes [Bug #7877]
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_proc_new / rb_fiber_new, and applies RB_BLOCK_CALL_FUNC_ARGLIST
wherever necessary.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_rescue / rb_rescue2, which revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. Let's start from making
rb_block_call_func_t strict, and apply RB_BLOCK_CALL_FUNC_ARGLIST liberally.
This is my mistake, I thought they were regular objects, but apparently
they are not. We don't need to pin them.
Revert "Symbols can move so only cache IDs"
This reverts commit 672ee5f6ed.
* explanation of the class concept, with examples;
* docs for all class methods (most of them just say "Like Enumerable#<methodname>, but chains operation to be lazy-evaluated.", but I believe they are useful this way because now have proper call-sequences and link to corresponding Enumerable's explanations)
* simplified example for ::new to emphasize the main concept
* Enumerable#lazy docs are slightly lightened and linked to this class for more in-depth explanations.
[Misc #15529][ruby-core:91046]
Co-authored-by: zverok <zverok.offline@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67320 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
A Yielder object can now be directly passed to another method as a
block argument.
```ruby
enum = Enumerator.new { |y|
Dir.glob("*.rb") { |file|
File.open(file) { |f| f.each_line(&y) }
}
}
```
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67211 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Reject ArithmeticSequence in rb_range_values so that methods like
Array#[] raises TypeError for ArithmeticSequence as an index.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66478 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Fix the wrong uses of rb_int_ge in arith_seq_each.
[ruby-core:90648] [Bug #15444]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66474 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
zverok
Marcus Stollsteimer
Nobuyoshi Nakada
Jeremy Evans
Lourens Naudé
Akinori MUSHA
卜部昌平
git
Aaron Patterson
Shugo Maeda
Kazuhiro NISHIYAMA
nobu
mrkn
hsbt
knu