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

F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-02-24 16:41
(Received via mailing list)
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,
86c07aa43c6df798df005edd84ee8b56?d=identicon&s=25 Marc-Andre Lafortune (Guest)
on 2010-02-25 02:46
(Received via mailing list)
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.
F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-02-25 17:31
(Received via mailing list)
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.
947c97a2c119e85989d2ca63135a5b5e?d=identicon&s=25 Roger Pack (Guest)
on 2010-02-25 20:08
(Received via mailing list)
> 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
Ba2f834cba243e6d678c06626d544918?d=identicon&s=25 Vladimir Sizikov (Guest)
on 2010-02-25 21:52
(Received via mailing list)
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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2010-02-26 01:00
(Received via mailing list)
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
F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-02-26 04:38
(Received via mailing list)
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.
F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-02-26 09:40
(Received via mailing list)
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.
9361878d459f1709feec780518946ee5?d=identicon&s=25 NARUSE, Yui (Guest)
on 2010-02-26 11:08
(Received via mailing list)
(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.
D469019a435a5dbd5c792016fdf67a0b?d=identicon&s=25 Jon Forums (jonm)
on 2010-02-26 19:49
(Received via mailing list)
> 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
F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-02-27 01:41
(Received via mailing list)
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 :-)
D469019a435a5dbd5c792016fdf67a0b?d=identicon&s=25 Jon Forums (jonm)
on 2010-02-27 03:17
(Received via mailing list)
> > 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
This topic is locked and can not be replied to.