[#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:23593] Defining #name= at the class level

From: Gregory Brown <gregory.t.brown@...>
Date: 2009-05-28 17:50:24 UTC
List: ruby-core #23593
Hi folks,

I'd like to just confirm from Matz or one of the core Ruby folks that
defining #name at the class level should be an undefined behavior.

Almost every implementation I've tried allows the following code to
work (MRI, YARV, JRuby, MacRuby):

>> @class = Class.new
=> #<Class:0x267690>
>> @class.instance_eval { class << self; attr_accessor :name; end }
=> nil
>> @class.name = "My Special Class"
=> "My Special Class"
>> @class.name
=> "My Special Class

However, Rubinius fails, like this:

>> @class = Class.new
=> #<Class:0x13c>
>> @class.instance_eval { class << self; attr_accessor :name; end }
=> nil
>> @class.name = "Foo"
TypeError:   Tried to use object of type String (48) as type Symbol (49)
   from Object# (__eval__) at (irb):3

Although this may seem esoteric, I ran into the issue because the
test/spec library uses this to assign human names to anonymous classes
created in unit tests.    I am curious whether this behavior should be
considered:

1) Defined to work as MRI and YARV, in which case Rubinius would not
be compatible for this feature
2) Undefined, in which case, test/spec should be patched to not use
#name=, as it cannot reliably work across implementations
3) Forbidden.  In this case, it'd be nice to see the other
implementations fail as Rubinius does.

I am guessing this is undefined behavior, no different from changing
the way any other existing Ruby code works via monkeypatching.   If
that's the case, I'll just patch test/spec and go away happy.
However, if it's one of the other options, I'd like to know.

-greg

-- 
BOOK:  http://rubybestpractices.com
TECH: http://blog.majesticseacreature.com
NON-TECH: http://metametta.blogspot.com

In This Thread

Prev Next