From: Robert Klemme on
On 30.06.2010 17:31, Brian Candler wrote:
> Robert Klemme wrote:
>> 2010/6/30 Brian Candler<b.candler(a)pobox.com>:
>>> or rather:
>>>
>>> Tempfile.open "prefix", "/tmp" do |io|
>>> �io.write everything
>>> �io.flush
>>
>> I'd rather io.close instead of io.flush to release resources as soon
>> as possible.
>
> But tempfile will want to close itself using the block form anyway.

Yes, but later. This can make a difference if you are low on file
descriptors. And you do not risk weird effects by the same process
opening the file twice.

> In most versions of ruby, Tempfile with a block returns nil. A change
> was committed so that it returns the (closed) object, but that hasn't
> made it into either of the versions I have lying around here.
>
>>> tf = Tempfile.open("aaa","/tmp") { puts "hello"; 123 }
> hello
> => nil

The non block form obviously returns the Tempfile instance and if you
want it to be returned from the block what stops you from explicitly
returning it?

IMHO the method with block should return whatever the implementor of the
block chooses. That is far more reusable than always returning the
Tempfile. Most of the time the Tempfile instance is of no use anyway
since it is closed then.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

From: Robert Klemme on
On 30.06.2010 17:05, James Edward Gray II wrote:
>
> That's mostly due to a pet peeve of mine. I often see code that
> slurps when foreach() would have worked fine. That's why I try to
> push that as a first choice.

I wholeheartedly agree.

> Do you think it would help if I added Wrapping an IO under the
> Shortcut Interface on this page?
>
> http://fastercsv.rubyforge.org/classes/FasterCSV.html

+1

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Brian Candler on
Robert Klemme wrote:
> The non block form obviously returns the Tempfile instance and if you
> want it to be returned from the block what stops you from explicitly
> returning it?

Only that it's a bit verbose:

tf = nil
Tempfile.open(...) do |io|
tf = io
...
end
puts tf.path

http://redmine.ruby-lang.org/issues/show/504

> IMHO the method with block should return whatever the implementor of the
> block chooses. That is far more reusable than always returning the
> Tempfile.

Maybe that's what the accepted patch does - I haven't tested it. It
would be consistent with File.open { ... } if it worked that way.

Anyway, I think we're talking about minutiae. You say that one should
close the file at the earliest opportunity to "save resources", but the
only resource we're talking about is one slot in the kernel file
descriptor table, and most apps aren't going to be constrained by that.

--
Posted via http://www.ruby-forum.com/.

From: Robert Klemme on
On 30.06.2010 20:26, Brian Candler wrote:
> Robert Klemme wrote:
>> The non block form obviously returns the Tempfile instance and if you
>> want it to be returned from the block what stops you from explicitly
>> returning it?
>
> Only that it's a bit verbose:
>
> tf = nil
> Tempfile.open(...) do |io|
> tf = io
> ...
> end
> puts tf.path

No, I was talking about the other version which returns whatever the
block returns. You would do

tf = Tempfile.open(...) do |io|
...
io
end
puts tf.path

> http://redmine.ruby-lang.org/issues/show/504

Apparently people differ in their preferences.

>> IMHO the method with block should return whatever the implementor of the
>> block chooses. That is far more reusable than always returning the
>> Tempfile.
>
> Maybe that's what the accepted patch does - I haven't tested it. It
> would be consistent with File.open { ... } if it worked that way.

Exactly that is what the patch does:

http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=19454

> Anyway, I think we're talking about minutiae. You say that one should
> close the file at the earliest opportunity to "save resources", but the
> only resource we're talking about is one slot in the kernel file
> descriptor table, and most apps aren't going to be constrained by that.

That's true. But I also have seen issues caused by files being opened
more than once by the same process. Plus, you'll notice much faster if
you try to write to the tempfile after you thought you were done when
you close the file. If the code is more complicated these bugs can be
hard to track. How much simpler is it if you see this:

irb(main):006:0> Tempfile.open "x" do |io|
irb(main):007:1* p io
irb(main):008:1> io.puts "hello"
irb(main):009:1> io.close
irb(main):010:1> io.puts "world"
irb(main):011:1> end
#<File:C:/Users/Robert/x20100630-4456-1ixsj0i-0>
IOError: closed stream
from (irb):10:in `block in irb_binding'
from /usr/local/lib/ruby19/1.9.1/tempfile.rb:199:in `open'
from (irb):6
from /usr/local/bin/irb19:12:in `<main>'

It's probably not that big a deal but I believe such discussions bring
benefit to the community by presenting alternative solutions to a
problem along with arguments. I always like this food for thought.
Thanks for sharing your thoughts!

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: James Edward Gray II on
On Jun 30, 2010, at 10:41 AM, Brian Candler wrote:

> James Edward Gray II wrote:
>> I'm open to suggestions and I do take patches.
>
> Specifically, I'd like to see how to parse CSV from stdin. You provide
> an example in the opposite direction:
>
> # FCSV($stderr) { |csv_err| csv_err << %w{my data here} } # to
> $stderr

On Jun 30, 2010, at 11:35 AM, Robert Klemme wrote:

> On 30.06.2010 17:05, James Edward Gray II wrote:
>>
>> Do you think it would help if I added Wrapping an IO under the
>> Shortcut Interface on this page?
>>
>> http://fastercsv.rubyforge.org/classes/FasterCSV.html
>
> +1

Better?

http://fastercsv.rubyforge.org/classes/FasterCSV.html

James Edward Gray II

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Trying to reach Florian Frank
Next: can't use uki