[#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
Tanaka Akira wrote:
> I may also want to use proc for:
> * process content fragments instead of byte count.
> * handle request/response header for *each* request by redirection.
> (for authentication, cookie, etc.)
> * etc.
>
> In future, open may have many proc arguments as:
>
> open(name, progress_proc, content_progress_proc,
> extra_request_header_proc, handle_response_header_proc, ...)
>
> I don't like that.
> I don't want to remember the order.
> I don't want to specify number of nil for arguments I don't care.
>
> So, although it has no backward compatibility, it has extensibility
> problem.
[the trouble with YAGNI is that -- if you're writing a library -- YAreGNI,
at least where 'it' is room to maneuver ;-)]
the extensibility problem is part of the reason i suggested a new class. i
imagined something along these lines:
class UriOpener
def monitorProgress(&block)
@progress_monitor = block
end
def handleResponseHeader(&block)
@response_header_handler = block
end
...
def open_uri(name)
...
end
end
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).
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.
unless, of course, i'm missing something. i don't really understand why
conversation switched to Procs.
> If the benefit of that is parameter checking, how about this style:
>
> 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!
i still prefer factoring the behavior out into a new class that gives access
to all the fancier functionality, though.
--elliott
*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin@bluearc.com
*********************************************************************