[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>

Feature #2032: Change the license to "GPLv2+ or Ruby's original".

51 messages 2009/09/02
[#25368] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Kazuhiko Shiozaki <redmine@...> 2009/09/04

Issue #2032 has been updated by Kazuhiko Shiozaki.

[#25461] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Gregory Brown <gregory.t.brown@...> 2009/09/07

On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<redmine@ruby-lang.org> wrote:

[#25463] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yukihiro Matsumoto <matz@...> 2009/09/08

Hi,

[#30610] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Shyouhei Urabe <redmine@...> 2010/06/06

Issue #2032 has been updated by Shyouhei Urabe.

[#30611] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

Hi,

[#30614] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/06

> To avoid enbugging a new bug, we must choose the another solutions.

[#30616] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

2010/6/6 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#30652] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/08

(2010/06/06 20:27), Yusuke ENDOH wrote:

[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>

Feature #2033: Move Core Development to Git

75 messages 2009/09/02
[#25290] [Feature #2033] Move Core Development to Git — Yui NARUSE <redmine@...> 2009/09/02

Issue #2033 has been updated by Yui NARUSE.

[#25297] Re: [Feature #2033] Move Core Development to Git — Jon <jon.forums@...> 2009/09/02

> Some commiter of Ruby live on Windows.

[#25342] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Jon wrote:

[#25343] Re: [Feature #2033] Move Core Development to Git — Michal Suchanek <hramrach@...> 2009/09/03

2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#25345] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Michal Suchanek wrote:

[#25299] Re: [Feature #2033] Move Core Development to Git — Eric Hodel <drbrain@...7.net> 2009/09/02

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>

Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support

16 messages 2009/09/03

[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <drbrain@...7.net>

On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:

10 messages 2009/09/05

[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>

Bug #2054: Onigurma Isn't Documented

17 messages 2009/09/05

[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>

Is there a way in 1.9 to turn off only indentation warnings? I like

19 messages 2009/09/06
[#25510] Re: turning off indentation warnings — Nobuyoshi Nakada <nobu@...> 2009/09/10

Hi,

[#25511] [Bug #2079] win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined — Bruno Antunes <redmine@...>

Bug #2079: win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined

18 messages 2009/09/10

[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>

Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

12 messages 2009/09/19

[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>

Bug #2131: f(not x) => syntax error

16 messages 2009/09/22

[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>

I have a challenge for anyone who wants to discuss, propose

25 messages 2009/09/25
[#25782] Re: A challenge: Enumerator#next in JRuby — Tanaka Akira <akr@...> 2009/09/26

In article <f04d2210909251312q46bd51c0teacc4b0a8c417f0c@mail.gmail.com>,

[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>

Feature #2152: Split functionality of Float#inspect and Float#to_s

32 messages 2009/09/28

[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>

Bug #2160: JSON can't parse input where top-level object is a string

11 messages 2009/09/29

[ruby-core:25775] Re: A challenge: Enumerator#next in JRuby

From: Charles Oliver Nutter <headius@...>
Date: 2009-09-26 00:34:59 UTC
List: ruby-core #25775
On Fri, Sep 25, 2009 at 4:01 PM, Marc-Andre Lafortune
<ruby-core-mailing-list@marc-andre.ca> wrote:
> I'm curious as to what are good examples of uses of #next. Personally,
> I don't mind the fact that its use comes with a big warning "might be
> slow or unsupported".

I don't dispute that it's a useful construct. Hell, Java developers
have gotten by with *just* external enumeration forever, and managed
to get by. It's also nice if you want to walk a collection in pairs or
walk a bit and then have some other piece of code walk the rest.
There's lots of uses for it.

And it's not really the "cursor" style enumeration (Enumerator#next)
that's a problem...it's the ability to maintain a cursor over
arbitrarily complex iteration logic. Another example to illustrate how
complex it can get:

class StreamGenerator
  def initialize(io); @io =3D io; end
  def each
    until @io.eof?
      yield @io.gets
    end
  end
end

In this case, any IO-like object with eof? and gets can be fed into
enumeration, and Enumerator#next over this "collection" must pause the
execution after each yield. But this is also easily turned into a
non-fiber-based enumeration by implementing to_enum yourself, since
the only state that *actually* needs to be saved between elements is
the position in the stream.

One of my concerns about supporting Enumerator#next on any object that
implements #each is that people will use this rather than implement a
lightweight enumerator of their own...resulting in lots of fibers or
generators on Ruby 1.8.7 or Ruby 1.9 and lots of threading hassles on
JRuby and IronRuby. But if Enumerator#next were predicated on a
collection implementing both each and to_enum.

It's also worth noting that using Enumerator#next is *really* slow
right now, very likely *because* it's continuation-based. Any use of
Enumerator#next is going to have similar performance characteristics
without custom enumerators (best) or threads (workable, but problems I
mentioned).

~/projects/jruby =E2=9E=94 time ruby1.9 -e "ary =3D Array.new(10000, 1); a =
=3D 0;
10000.times { ary.each {|i| a +=3D i} }"

real	0m13.100s
user	0m12.555s
sys	0m0.055s

~/projects/jruby =E2=9E=94 time ruby1.9 -e "ary =3D Array.new(10000, 1); a =
=3D 0;
10000.times { e =3D ary.each; 10000.times { a +=3D e.next }}"

real	2m50.966s
user	2m48.892s
sys	0m0.921s

- Charlie

In This Thread