[ruby-core:22132] Re: A short memorandum (Re: 1.8.7 Specifics)

Nobu and Urabe,

I never said I did not want merge these patches onto the mainline.
I was commenting on the way 1.8.6 might be insulated from changes in other
versions.
As I said at the end of my previous post on this thread,
"I'm not a configuration management guru".

As many non-committers do, I misunderstood the way patches flow into the
various Ruby versions.
And, while I was composing my last post, I missed some of the rapid
responses by others clarifying how this actually worked.  I think I've got a
better understanding now.
It's all part of the learning in a public forum.

Just to clarify where I am with the patches:
  I didn't myself believe that MBARI7 was ready for the 1.8 head when
  you first encouraged me to produce such a version.  At the time, there
were various
  CPU/Build environment dependent problems surfacing that I wanted to
address first.
  Only last week did I get to a point where I thought MBARI7 was robust
  enough to submit.  (Remember, I have a full-time day job)

1.   The first move was getting them onto git and github, yesterday.

2.   Now, my plan is to merge your modifications into my stable patches
     (and test them against 1.8.7).  

3.   Create a branch (or even a just build time flag) that hides the few API
changes I made.

4.   merge with 1.8.6-p287 and test against it.

I hope to have this all done by the end of next week.
Does this sound like a reasonable approach?

Notes:  The only modification of yours I probably will not merge is
the winding back of the stack.  I like it, but I've got some ideas for
eliminating stack copying entirely with which rewinding the stack is
incompatible.  

Here is the complete list of the "significant API changes" the MBARI patches
introduced:

Added:
    Continuation#thread   #returns the thread that will be continued

    GC.increase       #returns the number of bytes allocated since the last
garbage collection
    GC.limit              #returns the maximum allowed GC.increase
    GC.limit= bytes  # sets the maximum allowed GC.increase
    GC.exorcise        #Manually purge ghost refs from recently freed stack
space (debugging only)

    Proc|Method|UnboundMethod#__line__   #line on which these objects were
defined
    Proc|Method|UnboundMethod#__file__    #file name in which these objects
were defined

Removed (because they slow allocations slightly)
   GC.stress
   GC.stress=   #GC.stress=true is equivalent to GC.limit=0

While I appreciate that your recent negative experiences with 1.8.7 makes
you suspicious of any API changes whatsoever,  I think you'll agree that
there's nothing on this list as far reaching as String#chars or returning
Enumerators.   The above changes certainly shouldn't be too scary for a
point release.

Nonetheless, I accept Nobu's comment about needing to submit any API changes
separately.
After I've got a this stuff merged into 1.8.6-p287 (for EngineYard), that's
what I'll do next.

- brent



Nobuyoshi Nakada-2 wrote:
> 
> Hi,
> 
> At Sun, 15 Feb 2009 08:07:48 +0900,
> Urabe Shyouhei wrote in [ruby-core:22123]:
>> I see no reasons to reject them for forthcoming 1.8.* versions.  It seems
>> some
>> of them has already been merged by nobu.  For 1.8.6 and 1.8.7, you should
>> really carefully watch your step, because I see some API addition on
>> those
>> patches.  You know why 1.8.7 is hated this much (in spite of it's being
>> almost
>> backward compatible).
> 
> And I'm still awaiting the newer patches for 1.8 head, but now
> Brent seems interested in making private fork of 1.8.6 rather
> than merging into the mainline.
> 
> -- 
> Nobu Nakada
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A21997--1.8.7-Specifics-tp21961585p22020081.html
Sent from the ruby-core mailing list archive at Nabble.com.