[#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:23448] Fwd: Bug report involving class variables

From: Ryan Davis <ryand-ruby@...>
Date: 2009-05-14 05:36:13 UTC
List: ruby-core #23448
Can we get the redmine issues fixed?

Begin forwarded message:

> From: Ken Ballou <ballou@crab.mv.com>
> Date: May 13, 2009 4:24:41 PM PDT
> To: ruby-talk@ruby-lang.org (ruby-talk ML)
> Subject: Bug report involving class variables
> Reply-To: ruby-talk@ruby-lang.org
> X-Spam-Status: No, score=-2.6 required=5.0  
> tests=BAYES_00,RCVD_IN_DNSWL_LOW, ZSS_RUBY autolearn=ham  
> version=3.2.5-zss_spam_1_1_1
>
> (Slight rant:  I tried to submit this bug report through the tracker
> system at redmine.ruby-lang.org.  After trying twice to get a username
> and password [since the first attempt would not recognize the username
> and password even after I clicked the "confirm" link], I was finally
> able to log in.  When I tried to submit a new issue report, the form
> complained that the "mailing-list" field could not be blank, even  
> though
> there were no choices in the drop-down box and I could not type in the
> text area.  I gave up.)
>
> OK, on to the bug report.  Since I didn't really understand the  
> example
> of class variables on pages 337-8 of "Programming Ruby 1.9", I decided
> to try the code.  I found that the output was different for Ruby 1.9.0
> and Ruby 1.9.1p129, and neither agreed with the book.  This seems like
> it may be a defect in Ruby 1.9.
>
> Version information:
>
> 1.9.0:  ruby -v reports "ruby 1.9.0 (2006-06-08) [x86_64-linux]"
> 1.9.1:  ruby -v reports "ruby 1.9.1p129 (2009-05-12 revision 23412)
> [i686-linux]"
>
> Here is the code I used for this test:
>
> ##### begin classvars.rb
> class Holder
>    @@var = 99
>    def Holder.var=(val)
>        @@var = val
>    end
>    def Holder.read_var
>        @@var
>    end
>    def var
>        @@var
>    end
> end
>
> @@var = "top level variable"
>
> a = Holder.new
> puts "a.var: #{a.var}"
> Holder.var = 123
> puts "a.var: #{a.var}"
>
> def a.get_var
>    @@var
> end
>
> puts "a.get_var: #{a.get_var}"
> puts "@@var: #{@@var}"
> puts "Holder.read_var: #{Holder.read_var}"
> ##### end classvars.rb
>
> Here is the output:
>
> Ruby 1.9.0:
>
> a.var: 99
> a.var: 123
> a.get_var: top level variable
> @@var: top level variable
> Holder.read_var: 123
>
> Ruby 1.9.1p129:
>
> a.var: top level variable
> a.var: 123
> a.get_var: 123
> @@var: 123
> Holder.read_var: 123
>
> (I'm not entirely sure I understand why the first call to a.var should
> return the string "top level variable" but the second should return  
> the
> Fixnum 123 as the book claims, but that's not part of the bug report.)
>
> Perhaps someone who has more luck than I do with the issue tracker
> system can enter this report?
>
> Thank you, and I vaguely apologize for the rant.  I'm just feeling
> beaten up by the issue tracker system.
>
> 					- Ken
>


In This Thread

Prev Next