So I was working on File, but that had a few routines which returned Time objects, so I started a sidetrack on that which took a little longer than I expected. I have most of it complete (except for strformat) implemented as an extension to the .net Date/DateTime class. I''ve also integrated the Rubinius Time specs into the test project with some hiccups. Almost half of the tests are passing, with the bulk of the failures due to the specs use of the "ENV" object to set the time zone before testing out the Time class. Personally I think that monkeying with the system clock isn''t a great test idea anyway, and I don''t know of a good cross platform way to handle it. So what do you suppose I should do here? * Implement new tests that are more portable (I doubt I have time to work out Rubinius'' commit/patch requirements) * Just disable the tests that use ENV * Implement new tests just for IR Thanks! Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20071026/34caead9/attachment.html
Eric Nicholson wrote:> So I was working on File, but that had a few routines which returned > Time objects, so I started a sidetrack on that which took a little > longer than I expected. I have most of it complete (except for > strformat) implemented as an extension to the .net Date/DateTime class. > > I''ve also integrated the Rubinius Time specs into the test project with > some hiccups. Almost half of the tests are passing, with the bulk of > the failures due to the specs use of the "ENV" object to set the time > zone before testing out the Time class. Personally I think that > monkeying with the system clock isn''t a great test idea anyway, and I > don''t know of a good cross platform way to handle it. > > So what do you suppose I should do here? > * Implement new tests that are more portable (I doubt I have time to > work out Rubinius'' commit/patch requirements) > * Just disable the tests that use ENV > * Implement new tests just for IRPlease don''t implement tests that target a specific implementation, especially for core classes. Spend the time to make the tests work everywhere. For what it''s worth, though, ENV is required by *lots* of apps and script in Ruby. You''re going to need to have it working anyway. As for time-zone tweakage...anything that''s a side effect of setting ENV should probably be modified. You should also talk to the rubinius guys about how to run the specs such that they filter out things IR might never support. - Charlie
23 of the tests fail with MRI/CRuby as well due to the ENV[:TZ] thing, although that number may be higher or lower if you are in a different time zone... I suppose the tests could be rewritten with a lookup table of timezones and test values. The JRuby tests are significantly better with just 2 of 49 tests failing on MRI/CRuby (missing strftime features), but time zones aren''t really tested at all. That seems like the most reasonable approach to me: test with gmt for specific dates and localtime for generic "today" type tests. But you will have to trust that the localtime logic is implemented correctly on your system. JRuby tests depend on minirunit right now which doesn''t run under IR. It needs at least the IO class implemented, and unfortunately I put my name beside that one on the wiki. Doh! -Eric On 10/26/07, Charles Oliver Nutter < charles.nutter at sun.com> wrote:> > Eric Nicholson wrote: > > So I was working on File, but that had a few routines which returned > > Time objects, so I started a sidetrack on that which took a little > > longer than I expected. I have most of it complete (except for > > strformat) implemented as an extension to the .net Date/DateTime class. > > > > I''ve also integrated the Rubinius Time specs into the test project with > > some hiccups. Almost half of the tests are passing, with the bulk of > > the failures due to the specs use of the "ENV" object to set the time > > zone before testing out the Time class. Personally I think that > > monkeying with the system clock isn''t a great test idea anyway, and I > > don''t know of a good cross platform way to handle it. > > > > So what do you suppose I should do here? > > * Implement new tests that are more portable (I doubt I have time to > > work out Rubinius'' commit/patch requirements) > > * Just disable the tests that use ENV > > * Implement new tests just for IR > > Please don''t implement tests that target a specific implementation, > especially for core classes. Spend the time to make the tests work > everywhere. > > For what it''s worth, though, ENV is required by *lots* of apps and > script in Ruby. You''re going to need to have it working anyway. As for > time-zone tweakage...anything that''s a side effect of setting ENV should > probably be modified. > > You should also talk to the rubinius guys about how to run the specs > such that they filter out things IR might never support. > > - Charlie > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20071026/48207389/attachment-0001.html
On 10/26/07, Eric Nicholson <enicholson at gmail.com> wrote:> > 23 of the tests fail with MRI/CRuby as well due to the ENV[:TZ] thing, > although that number may be higher or lower if you are in a different time > zone... I suppose the tests could be rewritten with a lookup table of > timezones and test values.Echoing what Charlie said, if ENV["TZ"] is a common-enough convention in Ruby then IronRuby should implement this value. Having said that, the TZ environmental variable is a UNIXism; do these tests pass for CRuby under Windows at all? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20071026/8def0be3/attachment.html
On 10/26/07, Curt Hagenlocher <curt at hagenlocher.org> wrote:> > > Having said that, the TZ environmental variable is a UNIXism; do these > tests pass for CRuby under Windows at all? >No. They run without throwing an error, but there is no effect on date processing due to setting ENV[:TZ] on a windows system so the tests that use it all fail unless you are coincidentally in the correct time zone. -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20071026/df47284b/attachment.html
On 10/26/07, Eric Nicholson <enicholson at gmail.com > wrote:> > > No. They run without throwing an error, but there is no effect on date > processing due to setting ENV[:TZ] on a windows system so the tests that use > it all fail unless you are coincidentally in the correct time zone. >Sorry... I just realized you said this in your previous post. I''ve done enough Googling to see that there are at least some people who expect that setting ENV["TZ"] from within Ruby will affect the values returned by certain of Time''s methods -- despite this not working under the standard (?) build for Windows. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20071026/cbeec7f2/attachment.html
Eric Nicholson wrote:> > On 10/26/07, *Curt Hagenlocher* <curt at hagenlocher.org > <mailto:curt at hagenlocher.org>> wrote: > > > Having said that, the TZ environmental variable is a UNIXism; do > these tests pass for CRuby under Windows at all? > > > No. They run without throwing an error, but there is no effect on date > processing due to setting ENV[:TZ] on a windows system so the tests that > use it all fail unless you are coincidentally in the correct time zone.That''s one issue with the Rubinius specs; nobody''s developing Rubinius on Windows, so those tests are probably *never* being run there. On JRuby, I know we have at least one core dev on Windows, but we''re not a whole lot better. The community helps though, at least for reporting lots of Windows bugs none of us want to fix. - Charlie