Forum: Ruby-core [ANN] Ruby 1.9.2dev has passed RubySpec!

Hi,

I'm proud to announce that MRI trunk (1.9.2dev) has finally
passed all specs of RubySpec!


Yugui, the release manager of 1.9, has cancelled the release
schedule of 1.9.2 in [ruby-core:25707] because "Ruby 1.9.2
must pass (RubySpec) before release".  As far as I know, that
was the last official announce about 1.9.2 release.

Yugui, could you rearrange a 1.9.2 release plan?


Though trunk now passes RubySpec, more work is still needed.
RubySpec does not have enough specs about 1.9 features.  There
are even some specs that are actually implementation-detail.
In addition, trunk can pass currently only on Debian/lenny on
IA32 (the only supported platform).
On the other hand, through this activities, we could realize
that some parts of MRI need major redesign.
We should continue to improve both.

Even so, I believe this is a big step for 1.9.2 release and
even 1.9 series.


I'd like to thank everyone who have been working:

- RubySpec folks, especially, Brian Ford who have started
  RubySpec, enhanced mspec to support 1.9's spec and given
  fruitful advice

- core team folks, especially, Yui Naruse who created M17N-
  support patch for RubySpec, and Yusuke Endoh :-) who have
  updated many specs and have asked maintainers to clarify
  spec detail

- maintainers of the standard library who elaborated the spec
  of each library and/or fixed a bug:
  - Tadayoshi Funaba (for Date)
  - matz and nobu (for Delegate)
  - Masatoshi Seki (for ERB)
  - James Edward Gray II (for CSV)
  - Keiju Ishitsuka (for Matrix)
  - Shugo Maeda (for Net::FTP)
  - Aaron Patterson (for YAML)

- those who have tackled RubySpec conformance of 1.9 before
  I do, especially, akasaka.rb folks, Marc-Andre Lafortune,
  Run Paint Run Run, Vladimir Sizikov, ujihisa and who seem to
  commit many patches into RubySpec to support 1.9

(Very sorry if I overlook)

Thanks,

Hi,

On Wed, Feb 24, 2010 at 10:41 AM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> I'm proud to announce that MRI trunk (1.9.2dev) has finally
> passed all specs of RubySpec!

Great news!

> Yugui, could you rearrange a 1.9.2 release plan?

I am sure we are all eager to see 1.9.2 released, especially since it
will probably be the first version of the 1.9 line to be used by a
fairly large audience.

It would be nice if some of the feature requests could be decided for
1.9.2, in particular:
http://redmine.ruby-lang.org/wiki/ruby/SomeCoreFea...

Also, some precisions are still awaited, in particular:
http://redmine.ruby-lang.org/wiki/ruby/SomePrecisionsFor192

> I'd like to thank everyone who have been working:
> - RubySpec folks,

Here's a list of RubySpec contributors (for the last two years or so):
http://marc-andre.ca/posts/ruby-core/rubyspec/

In the order of # of commits:

Run Paint Run Run, Arthur Schreiber, Federico Builes, Brian Ford,
Vladimir Sizikov, Marc-Andre Lafortune, Charles Oliver Nutter,
ujihisa, Yusuke Endoh, Eloy Duran, Jim Deville, Evan Phoenix, Yuki
Sonoda (Yugui), Eric Hodel, David Calavera, Daniel Luz, Tanaka Akira,
Hiro Asari, Yui Naruse, Wilson Bilkovich, Ryan Davis, Charles
Comstock, Michael Latta, Gaston Ramos, Dirkjan Bussink, Peter Burns,
Hongli Lai (Phusion), Gordon Thiesfeld, Robby Russell, Nick Sieger,
Luis Lavena, Gianluigi Spagnuolo, Christopher Thompson, Yehuda Katz,
Thomas E. Enebo, Robert Dober, Pete Bacon Darwin, stass, Jim Kingdon,
Ivan Samsonov, Cezar Sa Espinola, Vincent Lu, Thiago Pradi, Stanislav
Sedov, Shintaro Kakutani, Eero Saynatkari, Dustin Barker, Sean Bryant,
Ondruch Vit, Michael Bevilacqua-Linn, Jari Bakken, Gianluigi, Chad
Fowler, Thomas Enebo, Mark Somerville, Marius Nuennerich, Laurent
Julliard, qbproger, Stephen Veiss, Shugo Maeda, Patrick Ewing, Monty
Williams, Mikko Perttunen, Michael Guterl, Koichiro Ohba, Kirk Haines,
Kenta Murata, Joe, Jake Douglas, Brian Lopez, steve, rohan, coderrr,
benbc, aquasync, Vitaliy Geraymovych, Tom Mornini, Sylvain Joyeux,
Stephen Bannasch, Roland Swingler, Rick DeNatale, Peter Bowen, Pete
Bevin, Patrick Thomson, Ola Bini, Mitsutaka Mimura, Mike Flester,
Michael Tomer, Michael S. Klishin, Matjaz Gregoric, Jeremy Kemper,
Janico Greifenberg, Gregory Brown, Graham, François Beausoleil,
Florent Guilleux, Eugene Pimenov, Eric Allen, Colin Jones, Clayton
Wheeler, Chuck Remes, Brice Figureau, Brad Gignac, Antti, Adam
Gardiner.

Hi,

2010/2/25 Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca>:
> It would be nice if some of the feature requests could be decided for
> 1.9.2, in particular:
> http://redmine.ruby-lang.org/wiki/ruby/SomeCoreFea...
>
> Also, some precisions are still awaited, in particular:
> http://redmine.ruby-lang.org/wiki/ruby/SomePrecisionsFor192


Nice listing.  I'll check them and encourage decision-makers to
determine.

But, it may take a long time to decide all of them and cause the
delay of release again.  The release is already much-delayed.

To avoid more delay, I think that we should have the deadline of
feature request.  A feature request that we cannot agree by the
deadline will be temporarily rejected until 1.9.2 release.

Yugui, please think about it.

> To avoid more delay, I think that we should have the deadline of
> feature request.  A feature request that we cannot agree by the
> deadline will be temporarily rejected until 1.9.2 release.

+1 for wanting to decide on feature requests.  We've waited a long
time for some of those feature requests to be decided on...

-r

On Wed, Feb 24, 2010 at 4:41 PM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> I'm proud to announce that MRI trunk (1.9.2dev) has finally
> passed all specs of RubySpec!

This is just terrific! Great for MRI, great for alternative
implementations, so everybody wins here!

One thing I'd like to bring an attention to is Windows support. Sorry,
couldn't resist! :)
There are literally thousands of failures (including hangups) when
running RubySpec  against MRI 1.9.2 on Windows. We've fixed some of
the RubySpec tests to be more windows-friendly or to have alternative
tests on Windows altogether, but there is a long, long way to go
still.

Having ruby-core looking at this would be great too, since MRI
behavior on Windows is often differs from its behavior on *nix, and in
plenty of times it is just not clear where there is a bug and where an
intentional change of behavior, dictated by the platform.

Thanks,
  --Vladimir

Yusuke ENDOH wrote:
> 
> Yugui, the release manager of 1.9, has cancelled the release
> schedule of 1.9.2 in [ruby-core:25707] because "Ruby 1.9.2
> must pass (RubySpec) before release".  As far as I know, that
> was the last official announce about 1.9.2 release.

Hi,

Just a reminder that many of the Unicode path failures on
Windows reported in Bug #1685 [ruby-core:24010] are still
present in the latest 1.9.2dev (svn rev 26764.)

Bug report: http://redmine.ruby-lang.org/issues/show/1685

Failures include Dir.mkdir, File.stat, File.exist? and
Kernel#test.


Regards,

Bill

Hi,

2010/2/26 Roger Pack <rogerdpack2@gmail.com>:
>> To avoid more delay, I think that we should have the deadline of
>> feature request.  A feature request that we cannot agree by the
>> deadline will be temporarily rejected until 1.9.2 release.
>
> +1 for wanting to decide on feature requests.  We've waited a long
> time for some of those feature requests to be decided on...


Sorry for (matz's) late response.  But, you should think a feature
request is all but rejected if there has been no activity for
certain period.

Feature request is a presentation.  Unless the request is really
nice, it may not be accepted by just waiting.  You should make more
effort (appeal the benefit, write a patch, etc.).  Matz has a right
to determine the request but no obligation, I think.


Note that bug report is in a whole different story.  It is always
welcome because it often helps us itself.  We must reply all of bug
reports, I think.

Hi,

2010/2/26 Vladimir Sizikov <vsizikov@gmail.com>:
> plenty of times it is just not clear where there is a bug and where an
> intentional change of behavior, dictated by the platform.


I know that some people really want windows support, and that you need
spec clarification.  But unfortunately, there is no committer who not
only are interested in RubySpec but also are familiar with windows.
In fact, I'm reluctantly tackling mingw but I'm now dizzy :-(

In addition, no offense to you, but RubySpec is immature as spec for
windows version of Ruby.  Many specs often forgets text mode of IO,
file path handling (e.g., separator and drive letter), IPv6 handling,
etc.
Of course, mingw version of Ruby also has many faults (I already found
some bugs by RubySpec), RubySpec result on windows has still too many
noise.
I'll fix bit by bit, we cannot officially afford to fix RubySpec and
cannot wait for improvement of RubySpec.

Time will solve the problem, but we have no time.  We should not delay
the release any longer unless serious issue is actually identified on
mswin/mingw, "best effort" platforms.

(2010/02/26 8:59), Bill Kelly wrote:
> Just a reminder that many of the Unicode path failures on
> Windows reported in Bug #1685 [ruby-core:24010] are still
> present in the latest 1.9.2dev (svn rev 26764.)
> 
> Bug report: http://redmine.ruby-lang.org/issues/show/1685
> 
> Failures include Dir.mkdir, File.stat, File.exist? and
> Kernel#test.

It seems not to be able to be in time for 1.9.2.
Resource for Windows Support is too few.

> I know that some people really want windows support, and that you need
> spec clarification.  But unfortunately, there is no committer who not
> only are interested in RubySpec but also are familiar with windows.

A few suggestions that may pragmatically help with the windows support 
issues while recognizing the current resourcing concerns:

1) Those interested in getting key Windows issues resolved should create 
a Windows-specific issue summary page similar to 
http://redmine.ruby-lang.org/wiki/ruby/SomeCoreFea...  This 
doesn't have to be an involved process as the fundamental concerns can 
be agreed upon by starting a new thread on this ML.  The issue summary 
makes it easy for all of us to quickly understand where to focus our 
limited resources.  It also makes it easy to remind ourselves (similar 
to what Marc has been doing) of the key Windows issues list and 
requesting resources on specific issues.


2) I request that the current committers who are responsible for 
resolving Windows-specific issues (Nakada-san?, Endoh-san?, ??) and Matz 
review the current process for how Windows issues are resourced, and 
communicate back how (specifically) you would like Windows developers to 
help work the issues.

We all recognize that we'll never have unlimited resources to do the 
things we'd like to do. But I also think we can come up with a process 
that allows us to better utilize existing resources and better leverage 
the Windows developer talents monitoring this list.

I also don't think the process needs to be overly complicated nor 
over-reaching.  "What are the simplest things we can do to make better 
progress on more quickly resolving the Windows issues?" should be the 
question.

Perhaps we could start off with something similar to:

a) Identify the key list of issues as discussed in (1)

b) Identify one current core committer (our Windows Champion) 
responsible for Windows patches committed to core. This does *not* mean 
that committer creates all the patches, but he/she has the final say on 
what goes into core.

c) Windows developers monitoring this ML regularly review the list of 
issues and coordinate the Windows Champion identified in (b).  This 
should enable Windows developers of different experience levels to 
contribute more easily while *not* needing commit rights.

d) The Windows Champion communicate how they'd like to address the 
RubySpec-for-Windows-Issues maturity concern raised by Yusuke.

e) The Windows Champion clearly communicates expectations in a timely 
manner on newly opened Windows issues.  It's important that when one 
opens an issue on the tracker or posts to ruby-core, that we clearly 
understand what's planned to be done and what help the Windows Champion 
needs in order to resolve the issue.  Whether the response is "Will not 
fix because ..." or "Not enough resources, need additional help" or 
"Will be fixed in X.Y.Z" we need clear expectations

f) Refine as needed.

Is something like this guaranteed to fix things?  No.  But the 
discussion should help us identify something that hopefully works better 
than what we currently have.


3) And finally, I suspect there may be a perception that Windows issues 
for the MRI implementation may not be taken as serious as MRI impl 
issues for other platforms.  Whether this perception is right or wrong 
in reality is open for discussion, but we sometimes see responses on the 
ML's to Ruby Windows issues something unhelpful along the lines of 
"...you need to switch to Linux..." or something similar.  I think this 
tone is unfortunate and sells Ruby short as I think many people find 
Ruby really great on multiple platforms.  I personally enjoy using it on 
both my Linux and windows boxes.

I think it would go a long way to setting the proper tone and reminding 
people that Ruby the Language is really about providing a great 
experience on the multiple platforms it (Ruby) targets if Matz and other 
core developers could be more vocal in reminding us that "...a great 
experience on Windows is very important to Ruby's success..."


> In fact, I'm reluctantly tackling mingw but I'm now dizzy :-(

Perhaps we can help reduce your struggling at 
http://groups.google.com/group/rubyinstaller as we have people of 
varying skill sets monitoring the list.


Jon

Hi,

2010/2/27 Jon <jon.forums@gmail.com>:
> A few suggestions that may pragmatically help with the windows support issues while recognizing the current resourcing concerns:
>
> 1) Those interested in getting key Windows issues resolved should create a Windows-specific issue summary page similar to http://redmine.ruby-lang.org/wiki/ruby/SomeCoreFea...

Yes, it will be very helpful for us.


> 2) I request that the current committers who are responsible for resolving Windows-specific issues (Nakada-san?, Endoh-san?, ??) and Matz review the current process for how Windows issues are resourced, and communicate back how (specifically) you would like Windows developers to help work the issues.
>
*snip*
>
> b) Identify one current core committer (our Windows Champion) responsible for Windows patches committed to core.

http://redmine.ruby-lang.org/wiki/ruby/Maintainers

mswin32, mswin64 : NAKAMURA Usaku (usa)
mingw32          : Nobuyoshi Nakada (nobu)
mingw64, cygwin  : none


> 3) And finally, I suspect there may be a perception that Windows issues for the MRI implementation may not be taken as serious as MRI impl issues for other platforms.

This is because few committers are interested in windows (only
usa, nobu, eban, and ko1?).  Though I tries mingw now, I'm not
going to continue.

If anyone arranges a nightly build/test environment for windows
and reports to us whenever any regression occurs, I guess it will
be really helpful.
Of course, I'm talking about a topic after 1.9.2 is released and
current errors on windows are fixed enough.


>> In fact, I'm reluctantly tackling mingw but I'm now dizzy :-(
>
> Perhaps we can help reduce your struggling at http://groups.google.com/group/rubyinstaller as we have people of varying skill sets monitoring the list.

Thanks, but I managed to get the current result of RubySpec on
windows and fix many trivial issues.  But I confirmed that very
many false errors (wrong specs for windows) seem to still remain.

Anyone please check them and contribute to RubySpec :-)

> > 1) Those interested in getting key Windows issues resolved should create a Windows-specific issue summary page similar to http://redmine.ruby-lang.org/wiki/ruby/SomeCoreFea...
> 
> Yes, it will be very helpful for us.

I will start a new thread on this ML unless someone beats me to it.

The MRI issues I'm concerned with appear to be related to IO/Encoding 
performance but I want to search the ruby-core mail archives and RedMine 
to provide specific examples for discussion.  I think some of the old 
ruby-core ML issues were from Roger Pack dealing with IRB performance 
and I'm not sure whether they've all made it to RedMine yet.

Also, these blog posts have gotten my attention as potentially being 
related:

http://antoniocangiano.com/2009/08/03/performance-...

http://antoniocangiano.com/2009/08/04/a-faster-rub...


> >
> > b) Identify one current core committer (our Windows Champion) responsible for Windows patches committed to core.
> 
> http://redmine.ruby-lang.org/wiki/ruby/Maintainers
> 
> mswin32, mswin64 : NAKAMURA Usaku (usa)
> mingw32          : Nobuyoshi Nakada (nobu)
> mingw64, cygwin  : none

My appologies for not searching for this very visible information that 
core has already taken the time to provide :(


> Anyone please check them and contribute to RubySpec :-)

Indeed :)

Jon