[#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: "T. Onoma" <transami@...>
Date: 2003-11-24 05:13:42 UTC
List: ruby-core #1749
On Sunday 23 November 2003 11:13 pm, Mathieu Bouchard wrote:
> On Mon, 24 Nov 2003, T. Onoma wrote:
> > > I expect this code to produce n distinct counters that will each
> > > produce their own independent sequence 1,2,3,4,5,... when called
> > > repeatedly. If it becomes impossible to do this anymore, then I won't
> > > be able to honestly say that Ruby really supports closures.
> >
> > Hmm...there would have to be an exception made for lambdas. Another
> > minus.
>
> what's the difference between a lambda/proc and a block?

That was the very first thing that I did not understood about Ruby, and still 
do not. Why are blocks and lambdas (and maybe methods for that matter) 
treated so distinctly? (In fact, you can still see the chicken scratch on 
page 10 of my Pickaxe.)

Take the def statement for example, why the odd sugar?: def blocky(x,y,&z). 
why not def blocky(x,y){z}? But then & isn't exactly just sugar. Is it? And I 
still get confused: when do I need the & in my method? And so on. No, unless 
there's some subtle aspect to this I do not understand, it would be much more 
intuitive if blocks were just treated as Proc/Lambda arguments that happened 
to have a special outside of ( ) notation.

I've also wished that Proc/Lambdas had there own unique delimiteres and not 
shared them with hashes. (Couldn't hashes have shared delimiters with array 
instead? The => gives them away, after all.) It would have simplified the 
symbol sematics.

> BTW it's impossible for a method that receive a blocks to pass it to
> another method without turning it into a proc/lambda (using the &
> prefixes), so it makes distinctions between lambda/proc and block rather
> undesirable, as there are some techniques that rely on passing blocks
> around, and can't work if it involves a difference of behaviour between
> "real block" and "block that was converted from a proc that was converted
> from a block".
>
> So I'm not sure how that exception would work at all, if an exception were
> to be applied...

Now we know the solution: local {"I knew it would come to this..."}

-t0



In This Thread