From: Brent Roman Date: 2009-02-15T15:36:47+09:00 Subject: [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.