[#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:83083] [Ruby trunk Bug#13965] Surprising behavior when using Tempfile.open
From:
therealdave.myron@...
Date:
2017-10-03 00:17:35 UTC
List:
ruby-core #83083
Issue #13965 has been updated by davemyron (Dave Myron).
To workaround the unexpected behavior, either use `IO#sync = true` or `IO#flush` after writing to the file.
----------------------------------------
Bug #13965: Surprising behavior when using Tempfile.open
https://bugs.ruby-lang.org/issues/13965#change-67032
* Author: davemyron (Dave Myron)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: 2.4.1p111
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
I was trying to write the contents of an array to a Tempfile using the #open() + block syntax: Tempfile.open { |f| my_array.each { |item| f.puts item }}
However, I was finding that only *most* of the items were being written to the file which, in my case, was Very Bad.
Witness (with Ruby 2.4.1p111; same behavior in 2.4.3):
```
>> Tempfile.open() { |f| (1..10000).each { |i| f.puts i }; `tail -n1 #{f.path}` }
=> "8416"
>> Tempfile.open() { |f| (1..100000).each { |i| f.puts i }; `tail -n1 #{f.path}` }
=> "98835"
>> Tempfile.open() { |f| f.puts "Test\n"; `tail -n1 #{f.path}` }
=> ""
```
All very surprising results! When using block syntax, I expect to be able to interact with the Tempfile inside the block and then forget about it.
Storing the path of the Tempfile and accessing it after the block is closed produces the expected results:
```
>> path = ""; Tempfile.open() { |f| path = f.path; f.puts "Test\n" }; `tail -n1 #{path}`
=> "Test\n"
>> path = ""; Tempfile.open() { |f| path = f.path; (1..10000).each { |i| f.puts i }}; `tail -n1 #{path}`
=> "10000\n"
```
I suspect that it's due to some buffering. Nonetheless, it's unexpected to have to store the path to the Tempfile when using the block syntax and to interact with after closing the block.
--
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>