[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>

Tanaka Akira:

22 messages 2003/11/19
[#1737] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1739] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1740] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:

[#1741] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>

22 messages 2003/11/21
[#1722] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/22

In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,

[#1724] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/22

On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:

[#1726] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311221024.05642.transami@runbox.com>,

[#1731] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:

[#1732] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311230325.21687.transami@runbox.com>,

[#1733] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:

[#1750] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/24

In article <200311230648.41003.transami@runbox.com>,

[#1759] Re: open-uri patch, added progress_proc hook — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 03:19, Tanaka Akira wrote:

[#1762] Re: open-uri patch, added progress_proc hook — "Nathaniel Talbott" <nathaniel@...> 2003/11/24

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).

16 messages 2003/11/24
[#1754] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1757] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

Yes, there are several (Ruby) threads working during this gc_sweep.

[#1758] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1763] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

of course this effects 300 machines ;-)

[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>

On Mon, 2003-11-24 at 02:04, T. Onoma wrote:

26 messages 2003/11/24
[#1756] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:

[#1760] Re: Controlled block variables — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 11:51, T. Onoma wrote:

[#1761] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:

Re: open-uri patch, added progress_proc hook

From: Tanaka Akira <akr@...17n.org>
Date: 2003-11-19 07:13:32 UTC
List: ruby-core #1709
In article <AD4480A509455343AEFACCC231BA850F17C3CA@ukexchange>,
  Elliott Hughes <ehughes@bluearc.com> writes:

> that would let you use the 'natural' Ruby block syntax, but also let you
> have an arbitrary number of blocks. i think Matz made a good decision in
> 'limiting' us to one block parameter per method, because anything more would
> be terribly confusing (and suggest that the method in question doesn't Do
> One Thing).

I feel no problem with lambda.

Note that I tried to make matz support multiple blocks.  I don't give
up yet.

> the major change would be that OpenURI's work would move into UriOpener, and
> OpenURI.open_uri would now create a UriOpener instance, and invoke the
> open_uri on that instance.

I think resource locators should know "how to open it".  So open-uri
provides URI::HTTP#open and URI::FTP#open and make Kernel#open to
parse URI string and call its open method.  So I'm not sure that
introducing additional UriOpener object is suitable.

>> open("http://...", OpenURI::OptProgressProc => lambda {|s| ... })
>> 
>> OpenURI::OptProgressProc is a some constant of a symbol.
>
> that would be better than the kind of hash used in Ruby's telnet, for
> example. if there's one thing worse than an error that isn't detected until
> run-time, it's an error that isn't even detected at run-time!

Another error checking idea:

Even if the style open("http://...", :progress_proc => lambda { ... })
is used, it is possible to implement some checking method
OpenURI.check_options(hash) using a set of options such as:

OpenURI::Options = {
  :proxy => true,
  :progress_proc => true,
  :content_length_proc => true,
  ...
}

It makes possible to use simple symbol keys with error checking with
inserting a single line call to OpenURI.check_options.  Also new
options can be added by another resource locator implementation with
only one line as: OpenURI::Options[:new_option] = true
-- 
Tanaka Akira

In This Thread

Prev Next