[#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
On Mon, Nov 17, 2003 at 11:44:44AM +0900, Tanaka Akira wrote:
> In article <20031116142119.GA18339@student.ei.uni-stuttgart.de>,
> Mauricio Fern疣dez <batsman.geo@yahoo.com> writes:
>
> > What about
> >
> > open("http://...", ... current options ...,
> > proc { |extconf|
> > extconf.progress_proc = proc { }
> > extconf.foo = ...
> > }
> > )
> >
> > ?
> >
> > extconf would be an object of type OpenURI::Options or so.
> >
> > This scheme is AFAIK backwards compatible, extensible (just add accessors
> > to OpenURI::Options), can detect wrong parameters and ensures open won't
> > be given non-existent arguments. You don't have to remember the order of
> > arguments nor to put nil for those not needed. Moreover, the validity
> > of the arguments _as a whole_ can easily be factored into a method of
> > OpenURI::Options.
>
> What's an advantage over mine?
IMHO
the validity of the arguments _as a whole_ can easily be factored into
a method of OpenURI::Options.
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".
More importantly :-) I find one argument (even though it's a proc)
more pleasant to the eye than several key => val pairs. And you can save
some typing if you want (proc {|e| e.progress_proc = ...}) without having
to include OpenURI.
> Both detects typos on option names. However exception class is different:
> extconf.typo raises NoMethodError and OpenURI::OptTypo raises NameError.
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).
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.
--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
C is quirky, flawed, and an enormous success
-- Dennis M. Ritchie