[#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-23 19:12:44 UTC
List: ruby-core #1738
On Sunday 23 November 2003 07:12 pm, Mathieu Bouchard wrote:

> I'm puzzled by how this new behaviour would make anything actually easier
> for anyone, while demanding significant workarounds for code that relies
> on having separate locals for multiple activations of a closure.

Actually I agree. I don't know why Matz thinks this is the "most regrettable 
behavior in Ruby". To me it makes perfect sense --a varaible is visible in 
the scope it was defined and all inner "sub"-scopes. How can you get any more  
POLS then that? I'd even take it further and make "instance varaibles" work 
likewise (but that's another story). Sure, you have to define a dummy 
variable on the outside of block to get it to come out the other end, but 
that's exactly becuase that's the scope level you want it to exist in --sort 
of self documenting.

> Unless I'm really missing something big (please tell me!), it seems to be
> about on the same level as my proposed merging of Module and Class, except
> that my proposal didn't have such an obvious compatibility impact.

Well I don't think so, but I'm crazy so.... I think there's just some 
irrational distaste for i = nil at the root of this (no one likes to have 
nothing ;)

So what's this merging of Module and Class all about?

> > p.s. if you don't mind me asking, what do you think of Structural
> > Reflection?
>
> never heard about it, though the words do sound familiar. what is it?

Refelection is when code can look at itself (inspection) and also manipulate 
itself. So Ruby has reflection at the OO level. It's one of the greatest 
things about Ruby. Structural reflection is a step or two lower, where a 
language can actually manipulate its own statements, yet is still a rung or 
two above on-the-fly syntax manipulation. Here's a pseudo example:

  def m
    print "A"
    print "B"
  end

  m; puts >> "AB"

  puts m:[0].to_s  # => print "A"
  puts m:[1].to_s  # => print "B"
  m: << lambda { print "C" }

  m; puts >> "ABC"

The colon notation used here to refer to the method "structure" of m is 
completely made up, but you get the idea. With structural reflection, I can 
manipulate the code on-the-fly as if it were an array of statements, for 
example.

Actually, Ruby does have some *limited structural reflection* through the use 
of eval.

-t0


In This Thread