new PR

[Larry Masinter]

Merge (rebase) Cleanup-character-IO-interfaces with master by masinter · Pull Request #356 · Interlisp/medley (github.com)

 

Has the merge.  Please try it

             git checkout merge-ron-master

 

 or download from Release merge-ron-cleanup · Interlisp/medley (github.com)

 

Alternatively (and perhaps  I should still) I could have taken Ron’s changed files (sans loadups) and copied to a new branch in logical order (NSIN uses first, RECORD fields second, misc modernization fields third?

It depends on now clean we want the git history to be,

 

I think I need to go through the comments I submitted on Cleanup character io interfaces by rmkaplan · Pull Request #348 · Interlisp/medley (github.com) and raise issues as needed.

 

 

--

https://LarryMasinter.net https://interlisp.org

 

[Nick Briggs]

It's really good to have a functioning system after each individual commit that exists in the final merged history -- then when you're looking for a problem you can use "git bisect" with a test case to locate where a bug was introduced.   If there are places in the history where the system can't run your test case (for other reasons) then this falls flat on its face.

-- 
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/01c201d78402%242854dc10%2478fe9430%24%40acm.org.

[Ron Kaplan]

I tried to do the commits at stages where I thought there was a running system and I hoped that other people would test.

Without getting feedback, I just kept going to the next commit.  Should I have branched at each point, while waiting for test information?

I did branch after I submitted this PR, so I have another round of changes, but those are much more localized—don't involve ripping through and/or recompiling so many files.  (Fixing up the interfaces for define-file-info and the ways in which the format can be specified and/or recognized. That is easier to stage and test.)

For the merge/rebasing that Larry has posted, the important first-principle test, given how much plumbing was affected, is:  does it work at all?

And by my initial testing (including doing a new loadup-all) is that it does.  More specific tests (, load, makefile, see…) also seem OK.

So without object I will approve this PR.

[John Cowan]

You can commit all you want locally (and you should), but merging (or squashing, if you must) shouldn't be done until all tests pass.

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/CB72C6DD-762C-4975-BB84-180C2939A066%40post.harvard.edu.

[Nick Briggs]

Yes... that was more directed at Larry's suggesting reordering the commits to get a cleaner look.

I'm guessing that in this case, since so much changed, if we think it's in a working state we'll do a "squash and merge" -- which means it will turn into a single giant commit in the result, with the text from each original commit presented as a list item in the final commit text.

-- Nick

[Larry Masinter]

Just to clarify – I wasn’t suggesting “reordering the commits”, which is what you get by “cherry-picking”.

What I had in mind is something like “cherry-picking” but on a file-by-file basis (call this “berry-picking”):

Go through the list of “files changed”. If a particular changed file can be adopted without any dependencies
then commit/PR that file. If you find one that depends on other changes, then either combine them
or work on those other changes first.  

 

Anyway, we’re not doing that. Let’s consider that if we get any more massive PRs

 

--

https://LarryMasinter.net https://interlisp.org

 

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/EB1E561B-5C3C-4DBB-86DE-473669B612E8%40gmail.com.

[Larry Masinter]

I don’t think we have any regular users of Medley who you can rely on to test in the same way companies do “alpha” or “beta” releases.

 

I’ve mainly not been running Medley. Maybe Frank Halasz? (not on LispCore).

So the process of introducing changes and hoping problems will show up in “test” won’t work very well.

We need some other way of validating changes.

 

--

https://LarryMasinter.net https://interlisp.org

 

From: lisp...@googlegroups.com <lisp...@googlegroups.com> On Behalf Of Ron Kaplan
Sent: Wednesday, July 28, 2021 4:15 PM
To: Nick Briggs <nicholas...@gmail.com>
Cc: Larry Masinter <L...@acm.org>; Interlisp core <lisp...@googlegroups.com>
Subject: Re: new PR

 

I tried to do the commits at stages where I thought there was a running system and I hoped that other people would test.

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/CB72C6DD-762C-4975-BB84-180C2939A066%40post.harvard.edu.

[Larry Masinter]

“test case”? How can we get some?

 

--

https://LarryMasinter.net https://interlisp.org

 

From: lisp...@googlegroups.com <lisp...@googlegroups.com> On Behalf Of Nick Briggs
Sent: Wednesday, July 28, 2021 3:56 PM
To: Larry Masinter <L...@acm.org>
Cc: Ron Kaplan <ron.k...@post.harvard.edu>; Interlisp core <lisp...@googlegroups.com>
Subject: Re: new PR

 

It's really good to have a functioning system after each individual commit that exists in the final merged history -- then when you're looking for a problem you can use "git bisect" with a test case to locate where a bug was introduced.   If there are places in the history where the system can't run your test case (for other reasons) then this falls flat on its face.

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/B8132A1E-3A2B-440E-98DA-F47B52FCE036%40gmail.com.

[Ron Kaplan]

Well, I’m a regular user when I’m not doing this low-level stuff.  I run some standard tests in LFG, which touches a lot of stuff.