I added a few comments to critical_tags.txt like this:
fails(need to track which thread owns critical lock):Thread.critical defers
exit
This will help the next person who tries to fix the bug, and also as just
documentation. However, I realized that Jim regenerates the tag files whenever
he
tfpt review /shelveset:hangs;REDMOND\sborde
Comment :
Non-deterministic fixes. I ran all the core\thread specs in a loop in
multiple processes and ran into a few non-deterministic failures. This change
fixes everything I ran into. The only product change is that Thread#wakeup is
not
I noticed that besides not_compliant_on to disable tests on specific Ruby
implementations, there is also compliant_on to enable tests only on selected
implementations. There are ~120 such instances. To make IronRuby compliant, we
not only have to reduce the number of *_tags.txt files, we also
Many tests use Channel to collect data that needs to be tested. For example,
the following in inspect_spec.rb.
compliant_on(:ruby) do
it reports aborting on a killed thread do
c = Channel.new
t = Thread.new { c Thread.current.inspect; Thread.stop }
c.receive.should
There are four ways to check the status of threads, Thread#status,
Thread#inspect, Thread#alive?, and Thread#stop?. Any objection to adding a
single shared file which checks the result of all the four APIs? It won't
follow the standard pattern of it_behaves_like for aliases since these are all
I noticed this in core\thread\current_spec.rb.
it returns the current thread do
t = Thread.new { Thread.current }
t.value.should equal(t)
Thread.current.should_not equal(t.value)
end
Is this any different than writing t.value.should == t? Is either of them the
recommended way?
Hi
I got the latest svn revision for ironruby (r. 182).
I tried upgrading rubygems to version 1.3.1 (rails 2.2.2 needs it)
And it has a similar problem with the path name.
it fails with a directory not found exception
because it created a folder structure like this for generating the bin
folder
Tomas Matousek wrote:
No, Ruby doesn't have any such warning filter. You can place a flag on
RubyContext (via GetOrCreateLibraryData) that remembers for the current runtime
that the warning has already been reported.
I'd expect to do the same in JRuby; it would be a one-time warning for
I think I'm coming around to your side. My position is current the
following:
1. If critical officially remains specified as its current behavior in
MRI, we should be warning people not to use it and should have a warning
emitted at least once.
2. If we can get ruby-core to agree that
Jim Deville wrote:
-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.
From what I can gather, -v, --version, -w and -W (-W
I asked ruby-core whether descheduling other threads is by spec, but no one
other than you replied. Any suggestions on how to nudge others to consider it?
If you want to reply to that thread and provide JRuby's vote of confidence for
the idea, that might help.
We should nail the complete
What Ruby version does ruby-doc.org refer to? The main page has links to 1.8.6,
1.8.7, and 1.9. Following 1.8.6 for Thread takes me to
http://www.ruby-doc.org/core/classes/Thread.html which lists Thread.exclusive
as an api. However, MRI 1.8.6 does not have such an api. There are no RubySpecs
I can check with Brian, but my understanding is as follows. The spec's are
meant to be a complete packaged spec. Tag files are a convenience for using the
spec's as a regression test. I feel, and I would guess this to be Brian's
feelings, that when an implementation is complete (as in
That is correct. The next time I sync up, I will look into the tools for tags
that Brian has in Rubyspec.
JD
From: Shri Borde
Sent: Tuesday, January 06, 2009 11:41 PM
To: Jim Deville
Cc: ironruby-core@rubyforge.org
Subject: Comments in the RubySpec tag files
I added a few comments to
require 'mspec'
describe equals do
it compares objects not values do
a = a
b = a
c = a
a.should equal(c)
a.should_not equal(b)
a.should == b
end
end
On Wed, Jan 7, 2009 at 3:48 AM, Shri Borde shri.bo...@microsoft.com wrote:
I noticed this in
I would rather implement them all separately. They all act differently. Status
returns a simple string, inspect returns an inspection string, and alive and
stop are Boolean. I would leave the shared pattern for the way it is now. You
can probably take advantage of sharing methods in the
I see. should== is value equality, and should+equal is reference equality.
From: ironruby-core-boun...@rubyforge.org
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Michael Letterle
Sent: Wednesday, January 07, 2009 11:26 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core]
Yeah, I can probably unify the fixtures but leave the expectations in the
individual spec files.
From: Jim Deville
Sent: Wednesday, January 07, 2009 11:25 AM
To: Shri Borde
Cc: ironruby-core@rubyforge.org
Subject: RE: Thread status tests
I would rather implement them all separately. They all
I have no clue where that comes from. You should probably email James Britt at
Ruby-doc and ask what is up with that.
JD
From: Shri Borde
Sent: Wednesday, January 07, 2009 10:51 AM
To: Jim Deville
Cc: ironruby-core@rubyforge.org
Subject: Ruby version at ruby-doc.org
What Ruby version does
Along those lines, you have to remember that Ruby has 4 distinct ways to define
equality. #eql?, #equal?, #== and #===. This post covers it:
http://probablycorey.wordpress.com/2008/02/26/ruby-equality-equal-eql-and/
JD
From: ironruby-core-boun...@rubyforge.org
If you're adding value to the RubySpec tests, the rubyspec guys are pretty
good about giving commit access... spread the wealth!
On Wed, Jan 7, 2009 at 2:40 AM, Shri Borde shri.bo...@microsoft.com wrote:
I added a few comments to critical_tags.txt like this:
fails*(need to track which
I see the point of having all the information within the specs. It is useful to
read a spec and to be able to know how other implementations behave (assuming
the implementation is solid enough as to not cause a huge number of usages of
not_compliant_on in the test code base).
However, I think
Jim has commit access and does provide patches to improve the framework. This
thread is about the ironruby tags though, and it would not help anyone other
than IronRuby.
From: ironruby-core-boun...@rubyforge.org
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Michael Letterle
Sent:
http://rubyspec.org/wiki/rubyspec/Guards
If you scroll to the compliant portion of the page, you'll see that they
actually have different meanings, and they are based on the reference
implementation (CRuby). I had forgotten this until just now.
JD
From: Shri Borde
Sent: Wednesday, January 07,
Hello,
How to enumerate the CLR object methods?
I whould like to write some thing like this:
- - -
require 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
include System::Windows::Forms
p Form.new.methods.sort
- - -
and to see methods like:
instance.class.to_clr_type.get_methods.collect { |m| m.name.to_s
}.uniq.sort.each { |m| p m }
or Form.to_clr_type.get_methods.collect { |m| m.name.to_s }.uniq.sort.each {
|m| p m }
On Thu, Jan 8, 2009 at 1:36 AM, Alex 2k8 li...@ruby-forum.com wrote:
Hello,
How to enumerate the CLR object
26 matches
Mail list logo
