[#1651] A min/max bug? — "Christoph" <chr_news@...>
Hi,
[#1690] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In effect. I mean that if a method's interface is getting too complicated,
In article <AD4480A509455343AEFACCC231BA850F17C358@ukexchange>,
On Sun, Nov 16, 2003 at 07:51:42PM +0900, Tanaka Akira wrote:
[#1699] FileUtils bug and fix — Chad Fowler <chad@...>
As posted in ruby-talk:85349, I believe there is a bug in FileUtils.cp's
[#1706] gc_sweep in Ruby 1.8 — Richard Kilmer <rich@...>
I posted about this before but Matz wanted me to post more detail.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
On Sunday 23 November 2003 07:12 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 09:32 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 11:13 pm, Mathieu Bouchard wrote:
On Mon, Nov 24, 2003 at 05:32:09AM +0900, Mathieu Bouchard wrote:
[#1716] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,
On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:
In article <200311221024.05642.transami@runbox.com>,
On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:
In article <200311230325.21687.transami@runbox.com>,
On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:
In article <200311230648.41003.transami@runbox.com>,
On Monday 24 November 2003 03:19, Tanaka Akira wrote:
Sean E Russell [mailto:ser@germane-software.com] wrote:
[#1753] gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...>
We still encountered a gc_sweep in our use of Ruby 1.8 on Linux (v8).
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
Yes, there are several (Ruby) threads working during this gc_sweep.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
of course this effects 300 machines ;-)
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
The saga continues:
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
There is a discussion (found by chad fowler) on ruby-dev (22000)
[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>
On Mon, 2003-11-24 at 02:04, T. Onoma wrote:
On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:
On Monday 24 November 2003 11:51, T. Onoma wrote:
On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
On Tue, 25 Nov 2003, T. Onoma wrote:
On Monday 24 November 2003 14:02, T. Onoma wrote:
On Monday 24 November 2003 09:15 pm, Sean E Russell wrote:
[#1799] Syck install on Debian Standard (Ruby 1.6.7) — "T. Onoma" <transami@...>
Hi, I'm having some trouble installing Syck on Debain (woody). I'm not
On Friday 28 November 2003 09:17 am, T. Onoma wrote:
On Fri, Nov 28, 2003 at 05:22:48PM +0900, T. Onoma wrote:
[#1819] Re: configure.in: do not override CCDLDFLAGS, LDFLAGS, XLDFLAGS — Eric Sunshine <sunshine@...>
Hello,
Re: open-uri patch, added progress_proc hook
In article <E1AKwJf-0003Jv-NX@odie.runbox.com>,
"T. Onoma" <transami@runbox.com> writes:
>> * It is not called if content is empty.
>
> hmm...there may be noting to do about it. just have to live with it.
It's user's choice. I don't want to deny progress bar for empty file.
>> * It may inform users that total may change.
>
> but it is changing. only happens on redirect right? not much data 200 bytes? i doubt would be even notice it would go by so fast.
I meant that passing total size multiple times informs programmers it
will change:
% ruby -rlib/open-uri -e 'open("http://www.ruby-lang.org/en/",:progress_proc => lambda {|pos, total| p [pos, total]})'
[720, 15324]
[1144, 15324]
...
[15200, 15324]
[15324, 15324]
In this case, I feel "Hmm... total may change because the interface is
designed as it can be changed".
But it doesn't change (if redirection is ignored by open-uri).
I prefer an interface which doesn't inform such invalid feel.
Regardless of that, do you want to show progress bar 3 times for
http://www.ruby-lang.org/ ?
1. redirection for http://www.ruby-lang.org/ to
http://www.ruby-lang.org/en/index.html
2. redirection for http://www.ruby-lang.org/en/index.html to
http://www.ruby-lang.org/en/
3. content retrieving for http://www.ruby-lang.org/en/
>> When an user know total by some applilcation specific way, total is useless.
>> Although calculating total is no problem in HTTP, it require another
>> network traffic in FTP.
>
> yuk. but only need to do if total is requested perhaps?
But the two-argument :progress_bar proc interface cannot request
progress without total.
>> > perhaps just convert nil to 0 instead and it will be a little better?
>>
>> It unify "total size is unknown" and "total size is 0".
>> I think it should be distinguishable.
>
> how can total length ever be 0?
Try:
% cd ~/public_html
% touch empty.txt
> if 0 it must be unknown. having a nil means having to take exception for nil type in proc.
I agree that nil may cause trouble because nil is different type than
integer. But it's essential.
There is a case that total size cannot be known by open-uri.
For example, CGI output which has no Content-Length.
In this case, progress bar cannot show percentage of transfer by
information open-uri provides.
So disabling progress_proc for such case may be a solution.
But it disables progress bar even if a client know total size by some
application specific way.
> i think maybe just leave out total for now. perhaps better idea will turn up later. maybe :progress_with_total_proc, if problems can be resolved.
>
> have you thought of better idea?
Maybe, another hook named content_length_proc or total_size_proc.
% ruby -rlib/open-uri -e '
open(ARGV[0],
:total_size_proc => lambda {|t| p [:total, t] },
:progress_proc => lambda {|s| p [:progress, s] }
)' http://www.ruby-lang.org
[:total, 15326]
[:progress, 720]
[:progress, 1144]
...
[:progress, 14352]
[:progress, 15326]
Is there a better name?
--
Tanaka Akira