[#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: Class variable and singleton problem

From: "Marrows, George A (PS, GENS)" <george.marrows@...>
Date: 2003-11-12 13:05:42 UTC
List: ruby-core #1673
Thanks Christoph, the tests (test_variable.rb) help a lot. I guess the main
reason for the current mechanism is to allow the singleton methods
Gods.ruler1 and Gods.ruler2 to find the Gods @@rule variable. The
'intuitive' rule wouldn't allow that.

Thanks everyone for taking the time to explain this. Promised wiki page will
appear this weekend!

-- George

> -----Original Message-----
> From: Christoph [mailto:chr_news@gmx.net]
> Sent: 11 November 2003 18:54
> To: ruby-core@ruby-lang.org
> Subject: Re: Class variable and singleton problem
> 
> 
> George marrows wrote:
> ...
> > Thanks to you and Guy, I think I now understand what it's 
> > doing - we could call it the 'surrounding class then 
> > inheritance hierarchy' rule.
> > 
> > .. but I'm afraid I'm still not clear on *why* this rule is 
> > used, in particular how it helps to 'make scope resolution as 
> > static as possible'.
> > Could you provide an example? 
> 
> You can find an example on why this probably a good idea  in 
> test.rb located in the  sample directory of Ruby's source tree - grep
> for "Titans" - (just image the morass of extra rules you 
> would need to 
> define to resolve this example if you start of with  a simple
> ``intuitive'' lookup rule).
> To throw in a little history, Ruby once had more ``intuitive'' and 
> seemingly simpler class variable scoping rules. However, because of
> their inconstancies they were dropped, and new rules were adopted
> modeled more closely around the constant scoping rules (static scope)
> - not however in contrast to the former that singleton classes are 
> not valid scopes  (see Guy's post) for class variables.
>  
> > All I see at the moment is that the rule introduces a (to me) 
> > unintuitive special case for singleton methods: in Mark's 
> > example, o is effectively a subclass of A, so it seems 
> > strange it can't directly access its class vars.
> > (See the ongoing ruby-talk discussion about objects with 
> > singleton methods still being examples of their 'original' class..)
> >
> > Thanks again for taking the time to explain. I'll write this 
> > up on the wiki when we're done.
> 
> Here is another ``weird'' example for your wiki.
> 
> ---
> class A
>   @@var = :A
> end
> 
> class B
>   @@var = :B
> end
> 
> class B
>   $a = A.new
>   def $a.var
>      @@var
>   end
> end
> 
> class A
>   $b = B.new
>   def $b.var
>     @@var
>   end
> end
> 
> p $a.var # :B
> p $b.var # :A
> ---
> 
> 
> /Christoph
> 
> 

In This Thread

Prev Next