[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
[email protected] wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <[email protected]> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <[email protected]> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <[email protected]> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
[email protected] wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
[email protected] wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <[email protected]> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:87112] [Ruby trunk Bug#14575] Switch Range#=== to use cover? instead of include?
From:
ko1@...
Date:
2018-05-17 07:26:13 UTC
List:
ruby-core #87112
Issue #14575 has been updated by ko1 (Koichi Sasada).
Assignee set to nobu (Nobuyoshi Nakada)
Target version set to 2.6
----------------------------------------
Bug #14575: Switch Range#=== to use cover? instead of include?
https://bugs.ruby-lang.org/issues/14575#change-72091
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
* Target version: 2.6
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
_This is **a conscious duplicate** of the bug I've created [more than a year ago](https://bugs.ruby-lang.org/issues/12612). I believe that the previous one was rejected too easy, mostly due to the fact I haven't provided enough evidence to support my proposal. I also believe that writing the new, better-grounded proposal would be more visible than adding more comments to the rejected ticket._
**The problem**: `Range#===` (used in `case` and `grep`) uses `include?` to check the value against the range, which could be:
a) really ineffective or b) simply unavailable.
Here are real-life and real-life-alike examples of types that suffer from the problem:
* [ipaddress](https://github.com/ipaddress-gem/ipaddress) `IPAddress("172.16.10.1")..IPAddress("172.16.11.255")`: it is really readable to describe in some server config "for this range allow this, for that range allow that", yet it could be fascinatingly slow, calculating thousands of IPs inside range just to check with `include?`;
* [Measurement units](https://github.com/joshwlewis/unitwise): `(Unitwise(1, 'm')...Unitwise(10, 'm')) === Unitwise(5, 'm')` throws "can't iterate from Unitwise::Measurement", which is reasonable: there is no `.succ` for numeric types; Ruby itself has an ugly workaround of "if this is a numeric type, behave like `cover?`"
* Dates and times: `(Date.today..Date.today + 1) === DateTime.now` is `false`; it is hard to imagine code where it is a desired behavior.
Matz's objections to the previous ticket were:
> I see no real-world use-case for `Range#===` with strings. (Because I have provided only string ranges example initially -- VS)
That is addressed, hopefully, with the new set of examples.
> Besides that, using `cover?` behavior for \[string\] ranges would introduce incompatibility.
I don't know how to estimate amount of incompatibilities introduced by this behavior change.
Yet it is really hard (for me) to invent some reasonable real-life use case which could be broken by it.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
