[#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
ko1@atdot.net 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 <ko1@atdot.net> 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 <ko1@atdot.net> 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 <ko1@atdot.net> 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
sam.saffron@gmail.com 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
ko1@atdot.net 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 <normalperson@yhbt.net> 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:87314] [Ruby trunk Feature#14799] Startless range
From:
shyouhei@...
Date:
2018-05-31 08:10:28 UTC
List:
ruby-core #87314
Issue #14799 has been updated by shyouhei (Shyouhei Urabe).
No strong opinion on this. However let me leave one question: how should Range#each work for this kind of ranges?
----------------------------------------
Feature #14799: Startless range
https://bugs.ruby-lang.org/issues/14799#change-72307
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
On introduction of endless range at #12912, "startless range" was discussed this way:
> @sowieso: Not having the opposite (`..5` and `..-2`) feels like this is rather a hack than a thoroughly planned feature.
> @duerst: I don't understand the need for a `..5` Range. The feature is called "endless range". Although mathematically, it's possible to think about startless ranges, they don't work in a program. Maybe some programming languages have `..5` as a shortcut for `0..5`, but that's in any way a usual, bounded, range with a start and an end. It's conceptually totally different from `5..`, which is a range with a start but no end, an unbound range.
In the context of that ticket (ranges used mostly for slicing arrays) having `..5` was indeed hard to justify, but there are other cases when `..5` being `-Infinity..5` is absolutely reasonable:
```ruby
case release_date
when ..1.year.ago
puts "ancient"
when 1.year.ago..3.months.ago
puts "old"
when 3.months.ago..Date.today
puts "recent"
when Date.today..
puts "upcoming"
end
log.map(&:logged_at).grep(..Date.new(1980)) # => outliers due to bad log parsing...
```
E.g., whenever case equality operator is acting, having startless range to express "below this value" is the most concise and readable way. Also, for expressing constants (mostly decorative, but very readable):
```ruby
# Celsius degrees
WORK_RANGES = {
..-10 => :turn_off,
-10..0 => :energy_saving,
0..20 => :main,
20..35 => :cooling,
35.. => :turn_off
}
```
In addition, my related proposal #14784 suggests that this kind of ranges could be utilized by more powerful clamp too:
```ruby
updated_at.clamp(..Date.today)
```
**Uncertainty points:**
* Would it be hard to add to parser? I am not sure, I am not very good at it :(
* Should `..` be a thing? I guess not, unless there would be convincing real-life examples, which for me it is hard to think of.
--
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>