[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, normal@ruby-lang.org wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <albertoalmagro@gmail.com> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83411] [Ruby trunk Feature#8948] Frozen regex
From:
shyouhei@...
Date:
2017-10-20 01:40:28 UTC
List:
ruby-core #83411
Issue #8948 has been updated by shyouhei (Shyouhei Urabe).
We had a discussion around this issue at yesterday's developer meeting.
Seems everyone there agreed that in long term future, regex shall be frozen. However the status quo is that there are wild applications that do override regex methods, particularly for testing purposes. So there needs to be some transition paths.
Freezing regex literals sounded a good starting point. We already optimize the return value of them:
```ruby
3.times {
p(/foo/.object_id)
}
```
The merit of freezing regex literals are:
- Seems very safe to do. If it hurts someone, that means that person has already been bothered by the literal being shared among evaluations.
The disadvantage of freezing regex literals are:
- It benefits no one while it does confuse people. Regexp class has no built-in destructive methods so freezing them does almost nothing; just prohibits method redefinitions. Is it worth doing by deafult?
----------------------------------------
Feature #8948: Frozen regex
https://bugs.ruby-lang.org/issues/8948#change-67376
* Author: sawa (Tsuyoshi Sawada)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version:
----------------------------------------
=begin
I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like:
class Foo
RE1 = /pattern1/
RE2 = /pattern1/
RE3 = /pattern1/
def classify
case self
when RE1 then 1
when RE2 then 2
when RE3 then 3
else 4
end
end
end
but suppose we have a frozen `Regexp` literal `//f`. Then we can write like:
class Foo
def classify
case self
when /pattern1/f then 1
when /pattern1/f then 2
when /pattern1/f then 3
else 4
end
end
end
=end
--
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>