[#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:83502] [Backport187 Backport#2723][Rejected] $: length affects re-require time of already loaded files
From:
knu@...
Date:
2017-10-22 12:31:16 UTC
List:
ruby-core #83502
Issue #2723 has been updated by knu (Akinori MUSHA). Project changed from Ruby 1.8 to Backport187 Description updated Status changed from Assigned to Rejected Closing this, Ruby 1.8.7 had gone EOL over three years ago. ---------------------------------------- Backport #2723: $: length affects re-require time of already loaded files https://bugs.ruby-lang.org/issues/2723#change-67516 * Author: ghazel (Greg Hazel) * Status: Rejected * Priority: Normal * Assignee: knu (Akinori MUSHA) ---------------------------------------- =begin This occurs on 1.8.6, 1.8.7 and 1.9.1. The Kernel#require docs say: 'A feature will not be loaded if it‘s name already appears in $"."'. However, re-requiring the same file still scans all the load paths in $: even if the file will not be loaded. This is exceedingly problematic on Windows, where stat()ing the list of all paths becomes very slow very quickly: $:.length: 9, 0.005000 seconds $:.length: 12, 0.005690 seconds $:.length: 21, 0.010520 seconds $:.length: 48, 0.022430 seconds $:.length: 129, 0.062840 seconds $:.length: 372, 0.179510 seconds $:.length: 1101, 0.517070 seconds Since it is not possible to create a new file called "set.rb" (or even "set.so", "set.o" and "set.dll" etc) somewhere else in the load path and have "require 'set'" pickup that new file, is it really necessary to scan the paths? Specifying "require 'set.rb'" by hand works quickly. $:.length: 9, 0.000030 seconds $:.length: 12, 0.000030 seconds $:.length: 21, 0.000030 seconds $:.length: 48, 0.000030 seconds $:.length: 129, 0.000030 seconds $:.length: 372, 0.000030 seconds $:.length: 1101, 0.000030 seconds But it is very unlikely everyone will switch their require lines. There are many solutions to this problem, depending on what the intended behavior is. The current solution is a significant source of wasted time when requiring a large code base. My application takes 20 full seconds of require time which are eliminated by hacking this extra scan step out. ($:.length == 169, $".length == 993) =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>