[#107008] [Ruby master Bug#18465] Make `IO#write` atomic. — "ioquatix (Samuel Williams)" <noreply@...>
Issue #18465 has been reported by ioquatix (Samuel Williams).
16 messages
2022/01/09
[#107150] [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically — "ko1 (Koichi Sasada)" <noreply@...>
Issue #18494 has been updated by ko1 (Koichi Sasada).
4 messages
2022/01/17
[#107170] Re: [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically
— Eric Wong <normalperson@...>
2022/01/17
> https://bugs.ruby-lang.org/issues/18494
[#107302] [Ruby master Bug#18553] Memory leak on compiling method call with kwargs — "ibylich (Ilya Bylich)" <noreply@...>
Issue #18553 has been reported by ibylich (Ilya Bylich).
4 messages
2022/01/27
[#107346] [Ruby master Misc#18557] DevMeeting-2022-02-17 — "mame (Yusuke Endoh)" <noreply@...>
Issue #18557 has been reported by mame (Yusuke Endoh).
18 messages
2022/01/29
[ruby-core:106961] [Ruby master Feature#18136] take_while_after
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2022-01-04 11:09:51 UTC
List:
ruby-core #106961
Issue #18136 has been updated by Eregon (Benoit Daloze).
`take_until`, from reading the method name, clearly implies to me including the element for which the condition became true, i.e., it includes that "last" element, like `1..3` includes `3`.
But if that's too confusing for others then it seems best to use another name.
As I said above, I'm fine with `take_till` and `take_upto` too.
----------------------------------------
Feature #18136: take_while_after
https://bugs.ruby-lang.org/issues/18136#change-95784
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
Sorry, I already tried that once (#16441) but I failed to produce the persuasive example.
So I am back with a couple of them, much simpler and clear than my initial.
**The proposal itself:** Have `take_while_after` which behaves like `take_while` but also includes the last element (first where the condition failed). Reason: there are a lot of cases where "the last good item" in enumeration is the distinctive one (one where enumeration should stop, but the item is still good.
**Example 1:** Take pages from paginated API, the last page will have less items than the rest (and that's how we know it is the last):
```ruby
(0..).lazy
.map { |offset| get_page(offset, limit) }
.take_while_after { |response| response.count == limit } # the last will have, say, 10 items, but should still be included!
.map { process response somehow }
```
**Example 2:** Same as above, but "we should continue pagination" is specified with a separate data key "can_continue":
```ruby
(0..).lazy
.map { |offset| get_page(offset, limit) }
.take_while_after { |response| response['can_continue'] } # the last will have can_continue=false, but still has data
.map { process response somehow }
```
**Exampe 3:** Taking a sentence from a list of tokens like this:
```ruby
tokens = [
{text: 'Ruby', type: :word},
{text: 'is', type: :word},
{text: 'cool', type: :word},
{text: '.', type: :punctuation, ends_sentence: true},
{text: 'Rust', type: :word},
# ...
]
sentence = tokens.take_while_after { !_1[:ends_sentence] }
```
(I can get more if it is necessary!)
Neither of those can be solved by "Using `take_while` with proper condition.", as @matz suggested here: https://bugs.ruby-lang.org/issues/16441#note-9
I typically solve it by `slice_after { condition }.first`, but that's a) uglier and b) greedy when we are working with lazy enumerator (so for API examples, all paginated pages would be fetched at once, and only then processed).
Another consideration in #16441 was an unfortunate naming.
I am leaving it to discussion, though I tend to like `#take_upto` from #16446.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>