[#50466] [ruby-trunk - Bug #7492][Open] Segmentation fault at DL::TestDL#test_call_double on x64 Windows 8 — "phasis68 (Heesob Park)" <phasis@...>

23 messages 2012/12/02

[#50558] [ruby-trunk - Feature #7511][Open] short-circuiting logical implication operator — "rits (First Last)" <redmine@...>

12 messages 2012/12/04

[#50575] [ruby-trunk - Feature #7517][Open] Fixnum::MIN,MAX — "matz (Yukihiro Matsumoto)" <matz@...>

20 messages 2012/12/05

[#50755] Becoming a committer — Charlie Somerville <charlie@...>

Hi ruby-core,

21 messages 2012/12/11
[#50759] Re: Becoming a committer — Yukihiro Matsumoto <matz@...> 2012/12/11

Hi,

[#50784] Re: Becoming a committer — Charles Oliver Nutter <headius@...> 2012/12/11

It's really this easy? If so, I'll send over my public key today :)

[#50795] Re: Becoming a committer — Yukihiro Matsumoto <matz@...> 2012/12/11

Hi,

[#50806] [ruby-trunk - Feature #7548][Open] Load and Require Callbacks — "trans (Thomas Sawyer)" <transfire@...>

12 messages 2012/12/12

[#50810] [ruby-trunk - Feature #7549][Open] A Ruby Design Process — "brixen (Brian Ford)" <brixen@...>

34 messages 2012/12/12

[#50867] [ruby-trunk - Bug #7556][Assigned] test error on refinement — "usa (Usaku NAKAMURA)" <usa@...>

14 messages 2012/12/13

[#50900] [ruby-trunk - Bug #7564][Open] r38175 introduces incompatibility — "tenderlovemaking (Aaron Patterson)" <aaron@...>

14 messages 2012/12/14

[#50951] [ruby-trunk - Bug #7584][Open] Ruby hangs when shutting down an ssl connection in gc finalization — "bpot (Bob Potter)" <bobby.potter@...>

12 messages 2012/12/17

[#51076] [ruby-trunk - Feature #7604][Open] Make === comparison operator ability to delegate comparison to an argument — "prijutme4ty (Ilya Vorontsov)" <prijutme4ty@...>

12 messages 2012/12/22

[#51170] [ruby-trunk - Bug #7629][Open] Segmentation fault — "atd (Antonio Tapiador)" <atapiador@...>

13 messages 2012/12/28

[ruby-core:50758] Re: Ruby Implementers Meeting Summary

From: Yusuke Endoh <mame@...>
Date: 2012-12-11 13:33:37 UTC
List: ruby-core #50758
Aaron and drbrain, thank you for coordinating the meeting!
I've read the discussion log.


Please let me confirm my understanding first.  The current is:

  1. A feature proposal to "Ruby" requires only matz's approval.
  2. "MRI" specifies "Ruby" as a reference implementation.

You suggest changing these points to:

  1. A feature proposal to "Ruby" requires not only matz's approval,
     but also other implementors' approvals.
  2. "MRI" does NOT specify "Ruby", but "RubySpec" does.

Okay?


If I'm correct, I have concerns for each.  Let me state them.
(This is just my personal opinion; you can ignore it if you think
it is unfair to attempt to speak after the meeting)


For part (1), it is still difficult enough to get matz's approval.
Making feature request more difficult will make Ruby's evolution
slower, or even stopped.  I don't think it is a good idea.


For part (2), I'm not against.  I prefer "reference implementation"
style, though.  Anyway, you should first persuade brixen because
this requires RubySpec to change the policy about implementation-
defined behavior.

brixen said to me (in IRC) in the past:

  - The goal of RubySpec is to provide an executable spec for Ruby
    implementors to check their implementation to comply with "Ruby".

  - But, most people think "MRI" behavior as a official feature set
    of "Ruby" even if some of them are actually MRI implementation-
    defined behavior.

  - Thus, he regards "MRI" as "Ruby" ("the Standard" in RubySpec
    terminology) and tries to include all MRI behaviors (including
    implementation-defined one and undefined one) as a "spec".

I thought that his policy was consistent.  (brixen, please correct
me if I'm wrong)

However, if rubyspec now speficies "Ruby", it should accept
implementation-defined, undefined, or unspecified behaviors as is.

There are more MRI implementation-defined behavior than you expect.
For example, AFAIK, "Ruby" does not specify the Float internal
representation, while RubySpec assumes that it is IEEE754.

Such specs that "specifies" implementation-defined behavior, must
be removed from RubySpec.  I'm not sure if brixen is satisfied with
this fact.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread