[#106939] [Ruby master Bug#18455] `IO#close` has poor performance and difficult to understand semantics. — "ioquatix (Samuel Williams)" <noreply@...>

Issue #18455 has been reported by ioquatix (Samuel Williams).

10 messages 2022/01/01

[#106977] [Ruby master Feature#18461] closures are capturing unused variables — "bughit (bug hit)" <noreply@...>

Issue #18461 has been reported by bughit (bug hit).

12 messages 2022/01/05

[#106994] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support — "katei (Yuta Saito)" <noreply@...>

Issue #18462 has been reported by katei (Yuta Saito).

8 messages 2022/01/07

[#106996] [Ruby master Feature#18463] Random number generation with xoshiro — "bbrklm (Benson Muite)" <noreply@...>

Issue #18463 has been reported by bbrklm (Benson Muite).

8 messages 2022/01/07

[#107005] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors — "kjtsanaktsidis (KJ Tsanaktsidis)" <noreply@...>

Issue #18464 has been reported by kjtsanaktsidis (KJ Tsanaktsidis).

14 messages 2022/01/08

[#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

[#107073] [Ruby master Feature#18481] Porting YJIT to Rust (request for feedback) — "maximecb (Maxime Chevalier-Boisvert)" <noreply@...>

Issue #18481 has been reported by maximecb (Maxime Chevalier-Boisvert).

26 messages 2022/01/12

[#107106] [Ruby master Bug#18487] Kernel#binding behaves differently depending on implementation language of items on the stack — "alanwu (Alan Wu)" <noreply@...>

Issue #18487 has been reported by alanwu (Alan Wu).

11 messages 2022/01/13

[#107190] [Ruby master Feature#18498] Introduce a public WeakKeysMap that compares by equality — "byroot (Jean Boussier)" <noreply@...>

Issue #18498 has been reported by byroot (Jean Boussier).

17 messages 2022/01/19

[#107203] [Ruby master Bug#18501] [BUG] try to mark T_NONE object in RubyVM::InstructionSequence. load_from_binary — "byroot (Jean Boussier)" <noreply@...>

Issue #18501 has been reported by byroot (Jean Boussier).

8 messages 2022/01/20

[#107204] [Ruby master Bug#18502] Make ruby-2.7.5 on Solaris 10 ld.so.1: gcc: fatal: libintl.so.8: open failed: No such file or directory — "dklein (Dmitri Klein)" <noreply@...>

Issue #18502 has been reported by dklein (Dmitri Klein).

8 messages 2022/01/20

[#107275] [Ruby master Bug#18512] MacOS 12.1 Monterey Bug — "oucl5976@... (Paul Liu)" <noreply@...>

Issue #18512 has been reported by oucl5976@gmail.com (Paul Liu).

9 messages 2022/01/25

[#107291] [Ruby master Bug#18518] NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18518 has been reported by Eregon (Benoit Daloze).

12 messages 2022/01/26

[#107310] [Ruby master Bug#18555] Running "bundle exec middleman server" on M1 Mac gives [BUG] Bus Error at 0x0000000104b04000 — "anthonyaykut (Anthony Aykut)" <noreply@...>

Issue #18555 has been reported by anthonyaykut (Anthony Aykut).

13 messages 2022/01/28

[#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

[#107392] [Ruby master Bug#18560] "Compaction isn't available on this platform" error running PG test suite on ppc64le — "vo.x (Vit Ondruch)" <noreply@...>

Issue #18560 has been reported by vo.x (Vit Ondruch).

7 messages 2022/01/31

[ruby-core:107315] [Ruby master Feature#18136] take_while_after

From: "knu (Akinori MUSHA)" <noreply@...>
Date: 2022-01-28 06:23:30 UTC
List: ruby-core #107315
Issue #18136 has been updated by knu (Akinori MUSHA).


In today's developer meeting, Matz said the only acceptable name so far was "drop_after" (if he had to choose).  He's still not quite convinced of the need for this feature.

----------------------------------------
Feature #18136: take_while_after
https://bugs.ruby-lang.org/issues/18136#change-96213

* 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>

In This Thread