[#23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7 — John Carter <redmine@...>

Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7

17 messages 2009/05/15

[#23483] [Bug #1478] Ruby archive — Oleg Puchinin <redmine@...>

Bug #1478: Ruby archive

29 messages 2009/05/16
[#29225] [Feature #1478] Ruby archive — Luis Lavena <redmine@...> 2010/04/02

Issue #1478 has been updated by Luis Lavena.

[#30345] Re: [Feature #1478] Ruby archive — "NAKAMURA, Hiroshi" <nakahiro@...> 2010/05/21

On Fri, Apr 2, 2010 at 17:13, Luis Lavena <redmine@ruby-lang.org> wrote:

[#30346] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

> Thanks for your comment.

[#30347] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

OK Hiroshi, I read some of the comments earlier in the thread that I

[#30355] Re: [Feature #1478] Ruby archive — Caleb Clausen <vikkous@...> 2010/05/21

On 5/20/10, Jonathan Nielsen <jonathan@jmnet.us> wrote:

[#30364] Re: [Feature #1478] Ruby archive — Benoit Daloze <eregontp@...> 2010/05/22

Hi,

[#23505] [Bug #1494] tempfile#unlink may silently fail on windows — Nicholas Manning <redmine@...>

Bug #1494: tempfile#unlink may silently fail on windows

19 messages 2009/05/19

[#23572] [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork? — Hongli Lai <redmine@...>

Bug #1525: Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

27 messages 2009/05/27

[#23595] Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...>

The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The

17 messages 2009/05/28
[#23596] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23602] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/28

On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:

[#23608] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23609] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/29

On Thu, May 28, 2009 at 7:22 PM, Luis Lavena <luislavena@gmail.com> wrote:

[ruby-core:23618] Re: Defining #name= at the class level

From: Yukihiro Matsumoto <matz@...>
Date: 2009-05-29 07:12:20 UTC
List: ruby-core #23618
Hi,

In message "Re: [ruby-core:23606] Re: Defining #name= at the class level"
    on Fri, 29 May 2009 08:00:31 +0900, Gregory Brown <gregory.t.brown@gmail.com> writes:

|Well, I think the problem here is that when you use attr_accessor at
|the class level, it re-writes name to point at an ivar.   Since
|Rubinius stores the name in an ivar in the first place, this causes a
|clash (because it expects @name to be the real name of the module).
|
|Do you still think that the code I showed before should work, considering this?

I admit I misunderstood your question at the first place.  This
problem actually contains two issues in one:

  * what should happen if the specified method already defined in the
    superclass.

    attr_accessor does nothing if the method is already define in the
    target class, but what if it is in the superclass?

    In my opinion, the behavior of attr_accessor should be change to
    either a) raise exception or cause error for overriding superclass
    method b) or remain silent without overriding attr access method.

  * since core component of Rubinius is defined by Ruby itself, it
    tends to be weaker to hacks using reflection such as this.  Should
    we do something to protect internal of the core?

    Currently, I have no idea on this yet.  Maybe we need selector
    namespace or something.  Until then, I recommend Rubinius to use
    instance variable names more tolerant to outside access.

							matz.

In This Thread