[#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
> No. I already implemented. (not committed yet.)
>
> In my version, progress_proc takes two arguments instead of one.
> It takes expected total size by Content-Length as second argument if available.
could you show example? hmm...wouldn't the expected length be in the proc already if it were needed? that's what i did with my progressbar.
> > i had it that way before and i can just put it back. the thing about the proc arguements though, each proc in the hash could take different arguments. hmmm....is is possible for the hash key itself to determine which args to pass in to the proc rather then making up names for them? for instance:
> >
> > open( url, { pos: proc { |b| ...} } ) # would pass #pos
> >
> > or something like that. just a thought.
>
> m(x => y) is same as m({x => y}).
ugh, my typo. what i meant was:
open(url, {:pos => proc {|b| ...}})
so that if, method_key = :pos and progress_prco = proc {|b| ...}
would end up something like
...
http.get(uri.to_s, header) { |str|
buf << str
progress_proc.call(buf.io.method(method_key).call) if progress_proc
}
}
...
but maybe that's too odd?
> > funny you ask, because i keep reading and reading about them, but for some reason i never quite understand them. most tech writers just assume you know, i guess. i sort of know how to use them on command line to pipe output from one command into another. can you more easily explain?
>
> pipe can be used to asynchronous process.
>
> Try:
>
> pipe = IO.popen("while :; do echo a; sleep 1; done")
> pipe.each_line {|line| p line }
>
> pipe = IO.popen("wget -q -O- http://raa.ruby-lang.org/all.html")
> pipe.each_line {|line| p line }
>
> IO.popen doesn't wait finishing a command.
>
> So, if URI::HTTP#open works like that, you can use it for progress
> bar. But it has subtle differences.
i see, thank you! that makes more sense. i think i was just confusing myself by making it more complicated.
-t0