Update to latest 1.9.3

[Funny Falcon]

Hi

I've updated my patches against today's ruby 1.9.3 . I'm ready to push them as soon as update will be scheduled.

Changes:
 - I will not update cached-lp and sorted-lf branches cause there were merged another patch into trunk.
   So that I just backport changes from trunk.
 - There is one fix in ary-queue branch (patch were merged into trunk and bug were fixed by Yui Naruse)

I will update backport-gc branch, but I'm disappointed with it. It seems that it doesn't save lots of memory, and some
reports slowdown cause of it. I suggest to not include this patch in next tcs-ruby release.

With regards,
Yura

[Jon]

> I've updated my patches against today's ruby 1.9.3 . I'm ready to push them
> as soon as update will be scheduled.
>
> Changes:
> - I will not update cached-lp and sorted-lf branches cause there were
> merged another patch into trunk.
> So that I just backport changes from trunk.
> - There is one fix in ary-queue branch (patch were merged into trunk and bug were fixed by Yui Naruse)

Thank you Yura, it's great to see your hard work finally integrated into trunk.

The questions for all of us include: What next for tcs-ruby? Does an updated tcs-ruby 1.9.3 release add value?

From my perspective, our efforts with tcs-ruby have been a wild success. All of the initial optimizations have been refined and integrated into both ruby_1_9_3 and trunk, and Yura's newer optimizations have been integrated into trunk. While we may have liked the optimizations to have been integrated earlier, the fact is, they were integrated.

Due to Hiroshi, Dusan, Luis, and Yura's development efforts as well as everyone who tested, blogged, documented, and advocated for these optimizations to ruby-core, MRI Ruby is better on both *nix and Windows. And substantially better on Windows. Very importantly, we've managed it in such a way that tcs-ruby isn't viewed as competitive fork to MRI ruby, distracting/confusing both users and valuable developers.

But frankly, I don't see an updated tcs-ruby 1.9.3 release adding much value. Given that Nakamura-san is the ruby_1_9_3 maintainer (and very responsive), for wrapping up our current 1.9.3 efforts I think it's better if we submit backport requests (specific patches is better) for Yura's cached-lp, sorted-lf, and ary-queue mods and decide what the next focus should be. And it's OK if tcs-ruby goes into hibernation mode until it's helpful in focusing efforts to solve the next big challenge.

That said, what are your thoughts on (a) an updated tcs-ruby 1.9.3 release, and (b) what's next for tcs-ruby?

> I will update backport-gc branch, but I'm disappointed with it. It seems
> that it doesn't save lots of memory, and some
> reports slowdown cause of it. I suggest to not include this patch in next
> tcs-ruby release.

Sounds reasonable.


Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

[Dušan D. Majkić]

> ...MRI Ruby is better on both *nix and Windows.
> ...substantially better on Windows.
> ...tcs-ruby isn't viewed as competitive fork to MRI ruby,

These where the goals from day one.

It turned out as an interesting concept to contribute to complex
project like Ruby. Full access to code, yet no strict coding
restrictions. That made it easier to focus on issues.

And everything addressed here went back to MRI Ruby.

> it's OK if tcs-ruby goes into hibernation mode until it's helpful
> in focusing efforts to solve the next big challenge
>

> what's next for tcs-ruby?

I agree that hibernate is Ok.

For "next" - I can't tell. List is here, also repositories and good will.

[Jon]

On Wed, 21 Nov 2012 20:40:23 +0100
Dušan D. Majkić <dma...@gmail.com> wrote:

> > it's OK if tcs-ruby goes into hibernation mode until it's helpful
> > in focusing efforts to solve the next big challenge
> >
> > what's next for tcs-ruby?
>
> I agree that hibernate is Ok.
>
> For "next" - I can't tell. List is here, also repositories and good will.

Indeed. Let's tidy up the repo so it's not too confusing when we return from hibernation.

Specifically:

1) Update ruby_1_9_3 to match current ruby-core ruby_1_9_3.
2) Rebase relevant (not backported to ruby-core ruby_1_9_3) patch branches on top of (1).
* ary-queue/ruby_1_9_3
* cached-lp/ruby_1_9_3
* sorted-lf/ruby_1_9_3
* st_opt/ruby_1_9_3
3) Retire (delete) all backported and uninteresting patch branches. Post a summary message
to the ML listing the SHA's of all retired branches so that anyone can easily re-create a branch.
4) Update tcs-ruby_1_9_3 with patch branches from (2) so tcs-ruby_1_9_3 is buildable. No new
tcs-ruby 1.9.3 release.
5) Maintain branches against ruby-core ruby_1_9_x when necessary.

Do we agree that the four branches in (2) are the only branches containing mods not yet backported to ruby-core ruby_1_9_3?

While I still believe we should submit backport requests/patches for the updated branches from (2), I'm not optimistic they'll be accepted since they're not bug fixes. That said, having updated branches that can easily be rebased onto updated ruby_1_9_3 enables us to quickly attach (updated) patches to the backport requests.

I'll start working on (1), (3), (4), and (5). Yura, I need your help with (2) to ensure those branches contain only the chunks from trunk that need to be backported to ruby_1_9_3.

Anything else?

Jon

[Jon]

> Indeed. Let's tidy up the repo so it's not too confusing when we return from hibernation.
>
> Specifically:
>
> 1) Update ruby_1_9_3 to match current ruby-core ruby_1_9_3.
> 2) Rebase relevant (not backported to ruby-core ruby_1_9_3) patch branches on top of (1).
> * ary-queue/ruby_1_9_3
> * cached-lp/ruby_1_9_3
> * sorted-lf/ruby_1_9_3
> * st_opt/ruby_1_9_3
> 3) Retire (delete) all backported and uninteresting patch branches. Post a summary message
> to the ML listing the SHA's of all retired branches so that anyone can easily re-create a branch.
> 4) Update tcs-ruby_1_9_3 with patch branches from (2) so tcs-ruby_1_9_3 is buildable. No new
> tcs-ruby 1.9.3 release.
> 5) Maintain branches against ruby-core ruby_1_9_x when necessary.
>
> Do we agree that the four branches in (2) are the only branches containing mods not yet backported to ruby-core ruby_1_9_3?
>
> While I still believe we should submit backport requests/patches for the updated branches from (2), I'm not optimistic they'll be accepted since they're not bug fixes. That said, having updated branches that can easily be rebased onto updated ruby_1_9_3 enables us to quickly attach (updated) patches to the backport requests.
>
> I'll start working on (1), (3), (4), and (5). Yura, I need your help with (2) to ensure those branches contain only the chunks from trunk that need to be backported to ruby_1_9_3.

Yura, thank you. I just saw your branch updates. I will start working on the other items as time allows.

Jon