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 wrote:
> Hello,
>
> How to enumerate the CLR object methods?
>
> I whoul
Hello,
I can't call the object's method, thought it exists.
My ruby script:
- - - - -
# Let's dump .Net methods
far.get_type.get_methods.each { |m| p m.name }
# Try to call 'RegisterTool' method
begin
far.register_tool
rescue => err
p err
end
begin
far.RegisterTool
rescue => err
p err
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: sh
I would prefer using a field rather than a private auto-property for IsSleeping.
Other than that, changes in ThreadOps look good.
Tomas
-Original Message-
From: Shri Borde
Sent: Wednesday, January 07, 2009 2:18 PM
To: ironruby-core@rubyforge.org; IronRuby External Code Reviewers
Subject:
Since no one has reviewed this yet, I have updated the change to factor out the
tests for alive?, inspect, status and stop?
Another product change was that Thread#value should return false if the thread
was killed. Only a thread with an uncaught exception should return nil.
Thanks,
Shri
-O
K, ScratchPad clear: MSpec doesn't provide any contracts. It is up to the user
to clear his own state. This also allows for a test to use ScratchPad across
multiple examples. ScratchPad is only meant to be a formalized global variable.
Channel is actually a part of Rubinius's standard library (I
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,
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: We
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 c
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 wrote:
> I added a few comments to critical_tags.txt like this:
>
>
>
> fails*("need to track which thread owns critical lo
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
[mailto:ironruby-core-boun...@ru
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 ruby-
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 act
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] s
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 fixtures
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 wrote:
> I noticed this in core\thread\current_spec.rb.
>
>
>
>
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 critical_
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 everything
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
for
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 behavi
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 wit
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 critical
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
sure
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
C
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
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
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 in
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 ha
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 q
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
30 matches
Mail list logo
