[#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 <20031117210516.GA25730@student.ei.uni-stuttgart.de>,
Mauricio Fern疣dez <batsman.geo@yahoo.com> writes:
> IMHO
> the validity of the arguments _as a whole_ can easily be factored into
> a method of OpenURI::Options.
Unfortunately, options may vary depends on a kind of target:
URI::HTTP, URI::FTP and others.
Since open-uri is a delegator to open any kind of URIs and other
resources which have public `open' method, fixed set of options is not
suitable. So, validity checking cannot be factored into single class.
> Also, the foo= instance methods of OpenURI can perform the checks you'd
> have to do in open otherwise.
> If the options become more "intelligent" at some point in the future,
> it would be nice to have them in a full-blown object.
> This seems to advocate for something like
>
> options = Options.new
> options.progress_proc = proc { }
> ...
> open("http://...", ..., options)
>
> but I believe the "impedance mismatch" is too high in that case; I
> find... feel the proc{|e| e.xxx=...} idiom is "lighter".
I feel OpenURI::OptXXX => ... is more lighter than proc {|e| ... }.
I feel :xxx => ... is more lighter than OpenURI::OptXXX.
I feel :xxx => ... style matches with Kernel#open. However it tends
to have no error checking.
Maybe, implementing error checking with :xxx => ... style is a
solution. But I'm not sure that unknown option should be cause
exception.
> More importantly :-) I find one argument (even though it's a proc)
> more pleasant to the eye than several key => val pairs.
I don't feel so.
> And you can save
> some typing if you want (proc {|e| e.progress_proc = ...}) without having
> to include OpenURI.
In this point of view, :xxx => ... is best (shortest).
Further, it will be more shorter with keyword argument on Ruby2, maybe.
> class OpenURI
> class Options
> def method_missing(meth, *args)
> # any behavior you like here, including raise NameError
> end
> end
> end
>
> it won't catch all typos unless you use undef_method (but that's not
> a problem), but OpenURI::id wouldn't be caught either (this is more than
> a mere typo, though).
I meant that both are no problem. So don't advocate such trick.
Such trick tends to cause trouble.
> Summarizing: putting the options in an object gives you more power
> you might someday find useful. The proc idiom provides not too heavy a
> way to do so.
Someday? It's violates YAGNI.
--
Tanaka Akira