[#17055] Set#map! vs. map — "David A. Black" <dblack@...>
Hi --
Hi,
At Tue, 3 Jun 2008 10:13:07 +0900,
At Tue, 3 Jun 2008 13:39:10 +0900,
Hi --
At Tue, 3 Jun 2008 18:03:23 +0900,
[#17067] Eval'ing 'yield' in 1.8 and 1.9 — "Vladimir Sizikov" <vsizikov@...>
Hi,
Hi,
[#17069] Ruby on zLinux — "Eric K. Dickinson" <eric.dickinson@...>
I posted this on the Ruby-Talk list with no success.
[#17084] Enumerable::Enumerator#with_memo — "Akinori MUSHA" <knu@...>
Hi,
Akinori MUSHA wrote:
Akinori MUSHA wrote:
On Mon, Jun 9, 2008 at 12:11 PM, David Flanagan <david@davidflanagan.com> wrote:
On Mon, Jun 9, 2008 at 10:57 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:
Martin DeMello wrote:
On Tue, Jun 10, 2008 at 10:04 AM, David Flanagan
David Flanagan wrote:
[#17092] Iconv#iconv(str, start, length) doesn't really convert str[start, length] — Vincent <vincentlu@...>
Hi Core,
Hi Core,
Hi,
[#17106] r16747: This commit and comment are real? — "Luis Lavena" <luislavena@...>
Checking a feed of the changes in ruby repository found this:
On Wed, Jun 4, 2008 at 7:21 PM, Luis Lavena <luislavena@gmail.com> wrote:
[#17116] Standardizing RUBY_PLATFORM — Brian Ford <brixen@...>
Hi all,
On Jun 4, 8:52=A0pm, Brian Ford <bri...@gmail.com> wrote:
[#17126] remove ObjectSpace.each_object from test/unit — Tanaka Akira <akr@...>
I wrote a patch to remove ObjectSpace.each_object from test/unit.
[#17155] lambda { break } — ts <decoux@...>
Hi,
[#17161] Ruby 1.8.7-p17 has been released — "Akinori MUSHA" <knu@...>
Folks,
[#17162] Release Plan: Ruby 1.9.0-2 — SASADA Koichi <ko1@...>
Hi,
Hi,
Hi,
Hi,
Kouhei Sutou <kou@cozmixng.org> writes:
I have to agree, on the documentation side.
SASADA Koichi wrote:
[#17167] Mail count in Subject — "Dirk Traulsen" <dirk.traulsen@...>
Hi!
All,
Warren Brown wrote:
At 11:54 08/06/10, Urabe Shyouhei wrote:
On Tue, Jun 10, 2008 at 4:54 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
Luis Lavena wrote:
[#17186] REXML Separation — Federico Builes <federico.builes@...>
Hello,
[#17261] [Ruby 1.9 - Bug #161] (Open) Profile library seems broken in 1.9 15427cat t.rv — Dave Thomas <redmine@...>
Issue #161 has been reported by Dave Thomas.
[#17272] [Ruby 1.9 - Bug #167] (Open) net/telnet login() method no longer works under 1.9 — Dave Thomas <redmine@...>
Issue #167 has been reported by Dave Thomas.
On Jun 15, 2008, at 11:25 PM, Dave Thomas wrote:
Yes, indeed it does...
[#17283] Major change in 1.8.6: convert_type now uses private conversion methods too — "Vladimir Sizikov" <vsizikov@...>
Hi,
Vladimir Sizikov wrote:
Hi,
[#17291] miniruby dependencies broken in 1.9 — Ryan Davis <ryand-ruby@...>
I've been having builds break with -j 4. This should add $(PREP) to
Hi,
[#17293] [Ruby 1.8 - Bug #175] (Open) Rational#power2 raises a NameError or causes infinite loops when passed a Rational — Arthur Schreiber <redmine@...>
Issue #175 has been reported by Arthur Schreiber.
[#17310] [Ruby 1.9 - Bug #178] (Open) File.open on sprintf-formatted string fails with encoding conversion error on OS X — Eric Hodel <redmine@...>
Issue #178 has been reported by Eric Hodel.
Issue #178 has been updated by Yui NARUSE.
[#17327] A plea for a release process — Brian Ford <brixen@...>
Hi all,
Hello,
On Jun 18, 1:12=A0pm, "U.Nakamura" <u...@garbagecollect.jp> wrote:
[#17345] Understanding the output of Kernel#caller — "Wilson Bilkovich" <wilsonb@...>
I am trying to understand what Ruby 1.8 outputs when "caller" is invoked.
[#17353] patches for tests of rubygems — "Yusuke ENDOH" <mame@...>
Hi,
Hi,
On Jun 24, 2008, at 05:55 AM, Yusuke ENDOH wrote:
On Jun 25, 2008, at 11:21 AM, Eric Hodel wrote:
[#17356] A faster Array#delete — Daniel Berger <djberg96@...>
Hi all,
[#17377] Re: Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix) — "Bill Kelly" <billk@...>
Hi,
[#17392] XMLRPC socket patch — Dario Meloni <mellon85@...>
Hi,
[#17393] URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — "Igal Koshevoy" <igal@...>
All currently available versions of MRI Ruby are either vulnerable to
Sorry for a late reply but I think I've fixed this issue. Can someone
Urabe Shyouhei wrote:
Igal Koshevoy wrote:
Urabe Shyouhei wrote:
Igal Koshevoy wrote:
Urabe Shyouhei wrote:
Hello, I think current 1.8.6/1.8.7 is stable than p230/p22, so I decided
On Wed, Jul 2, 2008 at 12:41 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
Hello,
Hi Urabe,
Vladimir Sizikov wrote:
Charles Oliver Nutter wrote:
Urabe Shyouhei wrote:
Igal Koshevoy wrote:
Charles Oliver Nutter wrote:
On 7/3/08, Igal Koshevoy <igal@pragmaticraft.com> wrote:
Wilson Bilkovich wrote:
Charles Oliver Nutter wrote:
On 02/07/2008, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
In article <a5d587fb0807160533r4534fabdg257b4a9523b15f1e@mail.gmail.com>,
On Sat, Jul 19, 2008 at 02:18:05PM +0900, Federico Builes wrote:
On Sun, Jul 20, 2008 at 12:43:46AM +0900, Federico Builes wrote:
When will we see a new 1.8.6 release?
Hi,
Hi,
On Fri, Jul 25, 2008 at 02:04:15AM +0900, Vladimir Sizikov wrote:
On Fri, Jul 25, 2008 at 04:35:43AM +0900, Jeremy Henty wrote:
Jeremy,
Hi,
On Thu, Jul 24, 2008 at 9:19 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>
Hi,
Hi,
When can we expect a release?
Hi Vladimir, hi Urabe,
Thank you, I merged this revision into 1.8.7.
Hi,
In article <48662E99.7030508@pragmaticraft.com>,
Federico Builes wrote:
Igal Koshevoy wrote:
M. Edward (Ed) Borasky wrote:
Igal Koshevoy wrote:
Igal Koshevoy wrote:
Tanaka Akira wrote:
In article <48678E3D.8020602@pragmaticraft.com>,
Tanaka Akira wrote:
In article <4867A6AC.4060902@pragmaticraft.com>,
[#17412] Time for a release management committee? — Charles Oliver Nutter <charles.nutter@...>
It seems like recent problems with patchlevel and minor 1.8 releases
[#17427] 1.8 release management — Yukihiro Matsumoto <matz@...>
Hi,
On Sun, Jun 29, 2008 at 06:06:14PM +0900, Yukihiro Matsumoto wrote:
Hi,
Let me describe some simple questions about Ruby 1.8.6 that are not
For what I know,
On 6/30/08, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
Wilson Bilkovich wrote:
On Thu, Jul 3, 2008 at 4:41 PM, Igal Koshevoy <igal@pragmaticraft.com> wrote:
Luis Lavena wrote:
Urabe Shyouhei wrote:
Igal Koshevoy wrote:
Urabe Shyouhei wrote:
Hi,
Vladimir Sizikov wrote:
On Fri, Jul 4, 2008 at 10:49 PM, Igal Koshevoy <igal@pragmaticraft.com> wrote:
[ruby-core:17139] Re: Standardizing RUBY_PLATFORM
RFC.
Excerpting brixen, Thu Jun 05 00:12:24 -0400 2008:
> On Jun 4, 8:52pm, Brian Ford <bri...@gmail.com> wrote:
>
> > Charles Nutter suggested in the Ruby design meeting on June 4/5, that
> > the value of RUBY_PLATFORM should reflect the layer just below Ruby
> > code, which is really the implementation. That layer should be
> > identified by RUBY_ENGINE instead. The value of RUBY_ENGINE has been
> > agreed on but I don't believe it's been implemented anywhere outside
> > of Rubinius. RUBY_ENGINE would be 'ruby' on MatzRuby, 'jruby' on
> > JRuby, 'rbx' on Rubinius, and undefined as yet AFAIK on IronRuby,
> > MacRuby, and MagLev.
>
> After more discussion, it would appear inescapable that we actually
> need *three* standard values to distinguish this. One is
> RUBY_PLATFORM, whose value needs to be defined. One is RUBY_ENGINE,
> whose value has been defined. And the third is another constant that
> would represent 'java', 'clr', etc. Essentially, the layer between the
> OS+arch at the bottom, and the implementation at the top, just below
> the Ruby code.
>
> We need a name for the new constant. We need to define it's contents.
> And we need to define what RUBY_PLATFORM will mean.
Revised proposal for the common constants
===========================================
RUBY_ENGINE
-------------
Single-word lowercased name of the implementation codebase. MatzRuby's
is "ruby", the other engines will come up with their own name although
this is usually just the project name. For example, Rubinius will have
RUBY_ENGINE == "rubinius".
RUBY_PLATFORM
---------------
A string generally in the format currently used for RUBY_PLATFORM, with
the exception that it may also contain the additional compatibility
layer name like e.g. "java" or "java6" for JRuby, "clr" for IronRuby
and so on. Each engine team can define the exact string and its
location although it would probably be simplest to just prepend it.
The information is accessible in the string, usually using a regexp:
# MatzRuby
RUBY_PLATFORM = "mips64-Plan9-edition4"
# JRuby
RUBY_PLATFORM = "java-mips64-Plan9-edition4"
# Etc.
I do not feel it is necessary for every engine to have the same
number of components or use the same format in the platform string
but if it is needed, something like "none" or "unknown" could be
used as the default and then JRuby can substitute that with "java"
and so on.
This could be further enhanced by creating a specialised object
to contain the platform information. The object would be usable
transparently as a String in the above format, but platform info
would actually be stored as discrete data so that users have
easier access to the various components, e.g. RUBY_PLATFORM.cpu.
RUBY_VERSION
--------------
Version of the Ruby language implemented by the engine, as set by
MatzRuby. A RUBY_VERSION of "1.8.6" means that any code that works
on the 1.8.6 release from http://ruby-lang.org should work exactly
the same on this engine. Same for any other version.
Versioning has been a source of contention recently, mainly because
_PATCHLEVELs have been used to actually make changes in functionality.
In the future, they should be used strictly for bugfixes (and they
should only ever be checked by users to see whether the bug has
been fixed.)
In the long term, Ruby versioning would benefit from adding a 4th
component to the version string, e.g. "1.8.6.p114" instead of the
patchlevel being a separate entity. This simplifies version checks.
In the short term, regardless of decisions made for the above, the
version should be made available as an Array of Fixnums rather than
or in addition to the current String. For example, we could have a
constant RUBY_VERSION_NUMBER == [1, 8, 7, 114]. The Array is trivial
to compare against incomplete versions, e.g. when someone just wants
to make sure they are dealing with an 1.8.x rather than a 1.6.x. It
can be joined wherever the String version is needed. One alternative
would be to use a specialised object here as well: the data could
be transparently used either as an Array or the traditional String.
#{RUBY_ENGINE.upcase}_VERSION
-------------------------------
Freeform version identifier for the engine. For MatzRuby, the constant
is the same, RUBY_VERSION, while RUBINIUS_VERSION could be "0.9.0-rc1"
and other platforms are free to use "1.2," "some droll version name"
or whatever happens to apply. The contents are engine-specific.
Any other details beyond these will be accessible in some unspecified,
engine-dependent way whether through RbConfig or some other means. It
could be stored in RUBY_PLATFORM, for example, if it is promoted to a
full-fledged object.
Thoughts?