Fixing core/time/asctime

jballanc · May 30, 2009, 1:41am

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?

jballanc · May 30, 2009, 11:12pm

Hi Joshua,

Here is a quick answer to your questions. 1.should == 2 results in this
error.
Expected 1
to equal 2
So the first line is actually the answer returned by the implementation,
and the second line is what was expected by the spec author. So you are
reading the result the wrong way. Hope this helps drill into the
strftime issue…

About NaN and Inf, you will see “not_compliant_on :rubinius, :jruby do”
around the test case. So the different implementations already have
different implementations. We will need to think of whether IronRuby
should try to follow MRI 1.8.6 or if its OK to differ. I would look at
other issues for now…

Thanks for your interest in contributing! Do go through all the
information in http://wiki.github.com/ironruby/ironruby and
http://rubyspec.org/wiki/rubyspec/ to help you get up and running
quickly, and feel free to ask any questions you might have.

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Friday, May 29, 2009 4:41 PM
To: [email protected]
Subject: [Ironruby-core] fixing core/time/asctime

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?

jballanc · May 31, 2009, 7:52am

Thanks for the response Shri.

I guess I wasn’t entirely clear. I am really after a policy decisions
here. I realize that IR is a 1.8x implementation. And if it is a blatant
incompatibility, fixing the code is easy. However, in the two cases I
pointed out, the answers aren’t as black and white (to me anyway).

For asctime: Given the command: Time.now.strftime("%a %b %e %H:%M:%S
%Y")

    IronRuby outputs: "Fri May e 14:00:42 2009"

```
    Ruby1.8.6 outputs: ""
```

    Ruby1.9 outputs: "Sat May 30 22:21:39 2009"

How does the IronRuby team want this (and really, any rspec break)
fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9
(which is how I might interpret this one)? To the IR way, an make a spec
exception for IR?

For issue with Inf, the same question stands. I was surprised you said,

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Once I get a feel for the project, and gain some insight on the
goals/direction, this will be easier for me to decide. Until then, I
need some policy guidance.

Thanks

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Saturday, May 30, 2009 2:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Hi Joshua,

Here is a quick answer to your questions. 1.should == 2 results in this
error.
Expected 1
to equal 2
So the first line is actually the answer returned by the implementation,
and the second line is what was expected by the spec author. So you are
reading the result the wrong way. Hope this helps drill into the
strftime issue…

About NaN and Inf, you will see “not_compliant_on :rubinius, :jruby do”
around the test case. So the different implementations already have
different implementations. We will need to think of whether IronRuby
should try to follow MRI 1.8.6 or if its OK to differ. I would look at
other issues for now…

Thanks for your interest in contributing! Do go through all the
information in http://wiki.github.com/ironruby/ironruby and
http://rubyspec.org/wiki/rubyspec/ to help you get up and running
quickly, and feel free to ask any questions you might have.

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Friday, May 29, 2009 4:41 PM
To: [email protected]
Subject: [Ironruby-core] fixing core/time/asctime

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?

jballanc · May 31, 2009, 8:06am

How does the IronRuby team want this (and really, any rspec break) fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9 (which is how I might interpret this one)? To the IR way, an make a spec exception for IR?

For existing Ruby libraries/applications it’s best to lean towards 1.8.6
compatibility; otherwise you’d have to run them on IronRuby with the -19
flag and that’s incorrect if they run on 1.8.6 just fine. RubySpec (you
said “rspec”, but I assume you’re talking about the RubySpec test suite
… different than “rspec”) shouldn’t have any IronRuby-specific
exception for things that aren’t platform related, like Time. So I vote
to follow 1.8.6 behavior if some app depends on this (does
Rails/RSpec/RubyGems test failures occur because of this?), otherwise
it’s fine to support the 1.9 behavior.

In general, IronRuby supports 1.8.6, unless it’s a special 1.9 feature.
It’s even more important to support the 1.8.6 behavior if existing apps
depend on it.

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Shri meant for just this case; as I said described above, “it depends”.
=)

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Saturday, May 30, 2009 10:50 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Thanks for the response Shri.

I guess I wasn’t entirely clear. I am really after a policy decisions
here. I realize that IR is a 1.8x implementation. And if it is a blatant
incompatibility, fixing the code is easy. However, in the two cases I
pointed out, the answers aren’t as black and white (to me anyway).

For asctime: Given the command: Time.now.strftime("%a %b %e %H:%M:%S
%Y")

    IronRuby outputs: "Fri May e 14:00:42 2009"

```
    Ruby1.8.6 outputs: ""
```

    Ruby1.9 outputs: "Sat May 30 22:21:39 2009"

How does the IronRuby team want this (and really, any rspec break)
fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9
(which is how I might interpret this one)? To the IR way, an make a spec
exception for IR?

For issue with Inf, the same question stands. I was surprised you said,

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Once I get a feel for the project, and gain some insight on the
goals/direction, this will be easier for me to decide. Until then, I
need some policy guidance.

Thanks

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Saturday, May 30, 2009 2:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Hi Joshua,

Here is a quick answer to your questions. 1.should == 2 results in this
error.
Expected 1
to equal 2
So the first line is actually the answer returned by the implementation,
and the second line is what was expected by the spec author. So you are
reading the result the wrong way. Hope this helps drill into the
strftime issue…

About NaN and Inf, you will see “not_compliant_on :rubinius, :jruby do”
around the test case. So the different implementations already have
different implementations. We will need to think of whether IronRuby
should try to follow MRI 1.8.6 or if its OK to differ. I would look at
other issues for now…

Thanks for your interest in contributing! Do go through all the
information in http://wiki.github.com/ironruby/ironruby and
http://rubyspec.org/wiki/rubyspec/ to help you get up and running
quickly, and feel free to ask any questions you might have.

From: removed_ema[email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Friday, May 29, 2009 4:41 PM
To: [email protected]
Subject: [Ironruby-core] fixing core/time/asctime

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?

jballanc · May 31, 2009, 8:37am

To make compat decisions a bit less subjective, it is preferable that
there be a bug on http://redmine.ruby-lang.org/ that can be referred in
the RubySpecs using the “ruby_bug” RubySpec helper method. In such
cases, it is possible that the bug is fixed in a future patch-level (see
http://redmine.ruby-lang.org/wiki/ruby-18/ReleasePlan) of mri 1.8.6
itself. In such cases, IronRuby need not be compatible (unless a
significant number of apps depend on it).

Not all differences may have a bug. Some behavior differences can be
considered acceptable implementation differences (like the ANSI C spec
does not specify the order in which arguments to a function are
evaluated - I think). MRI itself could potentially change behavior here
in some future release, on some different platform, etc. This bucket can
be subjective. In such cases, you can send email to
[email protected] (subscribe at
http://www.ruby-lang.org/en/community/mailing-lists) and
[email protected]mailto:[email protected] to see
if the difference is considered acceptable or not.

For the strftime issue, offhand, it sounds like a bug in 1.8.6, though I
don’t see a bug at http://redmine.ruby-lang.org/. You could open one.
For the Inf/INF issue, you can match MRI though it would not be the most
important bug to fix.

From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Saturday, May 30, 2009 11:04 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

How does the IronRuby team want this (and really, any rspec break) fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9 (which is how I might interpret this one)? To the IR way, an make a spec exception for IR?

For existing Ruby libraries/applications it’s best to lean towards 1.8.6
compatibility; otherwise you’d have to run them on IronRuby with the -19
flag and that’s incorrect if they run on 1.8.6 just fine. RubySpec (you
said “rspec”, but I assume you’re talking about the RubySpec test suite
… different than “rspec”) shouldn’t have any IronRuby-specific
exception for things that aren’t platform related, like Time. So I vote
to follow 1.8.6 behavior if some app depends on this (does
Rails/RSpec/RubyGems test failures occur because of this?), otherwise
it’s fine to support the 1.9 behavior.

In general, IronRuby supports 1.8.6, unless it’s a special 1.9 feature.
It’s even more important to support the 1.8.6 behavior if existing apps
depend on it.

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Shri meant for just this case; as I said described above, “it depends”.
=)

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Saturday, May 30, 2009 10:50 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Thanks for the response Shri.

I guess I wasn’t entirely clear. I am really after a policy decisions
here. I realize that IR is a 1.8x implementation. And if it is a blatant
incompatibility, fixing the code is easy. However, in the two cases I
pointed out, the answers aren’t as black and white (to me anyway).

For asctime: Given the command: Time.now.strftime("%a %b %e %H:%M:%S
%Y")

    IronRuby outputs: "Fri May e 14:00:42 2009"

```
    Ruby1.8.6 outputs: ""
```

    Ruby1.9 outputs: "Sat May 30 22:21:39 2009"

How does the IronRuby team want this (and really, any rspec break)
fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9
(which is how I might interpret this one)? To the IR way, an make a spec
exception for IR?

For issue with Inf, the same question stands. I was surprised you said,

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Once I get a feel for the project, and gain some insight on the
goals/direction, this will be easier for me to decide. Until then, I
need some policy guidance.

Thanks

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Saturday, May 30, 2009 2:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Hi Joshua,

Here is a quick answer to your questions. 1.should == 2 results in this
error.
Expected 1
to equal 2
So the first line is actually the answer returned by the implementation,
and the second line is what was expected by the spec author. So you are
reading the result the wrong way. Hope this helps drill into the
strftime issue…

About NaN and Inf, you will see “not_compliant_on :rubinius, :jruby do”
around the test case. So the different implementations already have
different implementations. We will need to think of whether IronRuby
should try to follow MRI 1.8.6 or if its OK to differ. I would look at
other issues for now…

Thanks for your interest in contributing! Do go through all the
information in http://wiki.github.com/ironruby/ironruby and
http://rubyspec.org/wiki/rubyspec/ to help you get up and running
quickly, and feel free to ask any questions you might have.

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Friday, May 29, 2009 4:41 PM
To: [email protected]
Subject: [Ironruby-core] fixing core/time/asctime

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?

jballanc · May 31, 2009, 8:44am

Great. This clears things up a bit. I knew there would be some
subjectivity, of course, but I can now at least attempt a reasonable
decision.

Thanks again.

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Saturday, May 30, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

To make compat decisions a bit less subjective, it is preferable that
there be a bug on http://redmine.ruby-lang.org/ that can be referred in
the RubySpecs using the “ruby_bug” RubySpec helper method. In such
cases, it is possible that the bug is fixed in a future patch-level (see
http://redmine.ruby-lang.org/wiki/ruby-18/ReleasePlan) of mri 1.8.6
itself. In such cases, IronRuby need not be compatible (unless a
significant number of apps depend on it).

Not all differences may have a bug. Some behavior differences can be
considered acceptable implementation differences (like the ANSI C spec
does not specify the order in which arguments to a function are
evaluated - I think). MRI itself could potentially change behavior here
in some future release, on some different platform, etc. This bucket can
be subjective. In such cases, you can send email to
[email protected] (subscribe at
http://www.ruby-lang.org/en/community/mailing-lists) and
[email protected]mailto:[email protected] to see
if the difference is considered acceptable or not.

For the strftime issue, offhand, it sounds like a bug in 1.8.6, though I
don’t see a bug at http://redmine.ruby-lang.org/. You could open one.
For the Inf/INF issue, you can match MRI though it would not be the most
important bug to fix.

From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Saturday, May 30, 2009 11:04 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

How does the IronRuby team want this (and really, any rspec break) fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9 (which is how I might interpret this one)? To the IR way, an make a spec exception for IR?

For existing Ruby libraries/applications it’s best to lean towards 1.8.6
compatibility; otherwise you’d have to run them on IronRuby with the -19
flag and that’s incorrect if they run on 1.8.6 just fine. RubySpec (you
said “rspec”, but I assume you’re talking about the RubySpec test suite
… different than “rspec”) shouldn’t have any IronRuby-specific
exception for things that aren’t platform related, like Time. So I vote
to follow 1.8.6 behavior if some app depends on this (does
Rails/RSpec/RubyGems test failures occur because of this?), otherwise
it’s fine to support the 1.9 behavior.

In general, IronRuby supports 1.8.6, unless it’s a special 1.9 feature.
It’s even more important to support the 1.8.6 behavior if existing apps
depend on it.

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Shri meant for just this case; as I said described above, “it depends”.
=)

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Saturday, May 30, 2009 10:50 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Thanks for the response Shri.

I guess I wasn’t entirely clear. I am really after a policy decisions
here. I realize that IR is a 1.8x implementation. And if it is a blatant
incompatibility, fixing the code is easy. However, in the two cases I
pointed out, the answers aren’t as black and white (to me anyway).

For asctime: Given the command: Time.now.strftime("%a %b %e %H:%M:%S
%Y")

    IronRuby outputs: "Fri May e 14:00:42 2009"

```
    Ruby1.8.6 outputs: ""
```

    Ruby1.9 outputs: "Sat May 30 22:21:39 2009"

How does the IronRuby team want this (and really, any rspec break)
fixed? Strictly to 1.86? To 1.86, unless it might make sense to do 1.9
(which is how I might interpret this one)? To the IR way, an make a spec
exception for IR?

For issue with Inf, the same question stands. I was surprised you said,

“We will need to think of whether IronRuby should try to follow MRI 1.8.6 or if it is OK to differ.”
Has this really not been discussed and decided yet?

Once I get a feel for the project, and gain some insight on the
goals/direction, this will be easier for me to decide. Until then, I
need some policy guidance.

Thanks

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Saturday, May 30, 2009 2:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] fixing core/time/asctime

Hi Joshua,

Here is a quick answer to your questions. 1.should == 2 results in this
error.
Expected 1
to equal 2
So the first line is actually the answer returned by the implementation,
and the second line is what was expected by the spec author. So you are
reading the result the wrong way. Hope this helps drill into the
strftime issue…

About NaN and Inf, you will see “not_compliant_on :rubinius, :jruby do”
around the test case. So the different implementations already have
different implementations. We will need to think of whether IronRuby
should try to follow MRI 1.8.6 or if its OK to differ. I would look at
other issues for now…

Thanks for your interest in contributing! Do go through all the
information in http://wiki.github.com/ironruby/ironruby and
http://rubyspec.org/wiki/rubyspec/ to help you get up and running
quickly, and feel free to ask any questions you might have.

From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua B.
Sent: Friday, May 29, 2009 4:41 PM
To: [email protected]
Subject: [Ironruby-core] fixing core/time/asctime

Hi all,
I am new to Ruby and IronRuby as well, but I would like to help if I
can.
Last week, I submitted a request for ssiadmin, but haven’t heard back
yet.

Meanwhile, I am trying to find some low hanging fruit.
I found a test in rspec that is failing, namely:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

It looks like the underlying spec was mistyped:
It currently reads:
t.send(@method).should == t.strftime("%a %b %e %H:%M:%S %Y")
but I believe should read:
t.send(@method).should == t.strftime("%a %b %d %H:%M:%S %Y")

Of course, it isn’t quite as easy as that. I tried the above string on
1.86 and received the following:
irb(main):005:0> t.strftime("%a %b %e %H:%M:%S %Y")
=> “”

However, IronRuby puts out:

Time.now.strftime("%a %b %e %H:%M:%S %Y")
=> “Fri May e 14:00:42 2009”

So, we have two issues here, and this leads me to one more issue. The
error that rspec out puts:

Time#asctime returns a canonical string representation of time FAILED
Expected “Fri May 29 13:44:16 2009”
to equal “”

This error would suggest to me that the constant of what SHOULD happen
is Expected “Fri May 29 13:44:16 2009”, but what actually is happen in
IronRuby was the empty string, “”.

In reality, IronRuby is putting out the formatted String, and I think
what should happen is the NULL string. Is this just backwards, or is
this just an artifact of the dispatch from one test to another.

Thanks for the help.
joshua

PS
I also noticed a number of tests that were 'gig’ing IronRuby for
capitalization issues like:
String#% supports float formats using %E, and upcases Inf, -Inf, and NaN
FAILED
Expected “Inf”
to equal “INF”

How are you all going to handle that? Is that an rspec issue or an
IronRuby issue?