Adjustments to GITFNS #2321

rmkaplan · 2025-10-21T06:43:31Z

prc status is C if changes requested, prc comparison runs in its own process, initial changes for gwc to treat the clone as UNIX, not DSK, so branch-switching doesn't cause files from other branches to pile up.

pamoroso · 2025-10-21T17:02:44Z

On Linux Mint 22.1 Cinnamon I checked out this branch up to commit 301c4f7, ran PRC, clicked on the first line #1960 fgh_lfg-loadup of the PR menu, and got this error:

FILE-NOT-FOUND
In \OPENFILE:
File not found: {FROMGIT1}<pr>scripts>loadup-app-setup.sh;1

The backtrace:

prc/7(debug)BTV
OPENSTREAM
   DIR "{FROMGIT1}<pr>"
   INCLUDEDFILES (*.* *>*.* .* *>.*)
   EXCLUDEDFILES ("EXPORTS.ALL" "RDSYS" "RDSYS.LCOM" 
"loadups/" "patches/" "tmp/" "fontsold/" "clos/" 
"cltl2/" "deleted/" --)
   ALLVERSIONS NIL
   DEPTH NIL
   USEDIRECTORYDATE NIL
   INCLUDEAUTHOR NIL
   STARTPOS 15
   FULLNAME 
"{FROMGIT1}<pr>scripts>loadup-app-setup.sh;1"
   TYPE NIL
   LDATE NIL
   STREAM NIL
COMPAREDIRECTORIES.INFOS
   DIR1 "{FROMGIT1}<master>"
   DIR2 "{FROMGIT1}<pr>"
   SELECT (> < ~= -* *-)
   INCLUDEDFILES (*.* *>*.* .* *>.*)
   EXCLUDEDFILES ("EXPORTS.ALL" "RDSYS" "RDSYS.LCOM" 
"loadups/" "patches/" "tmp/" "fontsold/" "clos/" 
"cltl2/" "deleted/" --)
   USEDIRECTORYDATE NIL
   OUTPUTFILE NIL
   ALLVERSIONS NIL
   FIXDIRECTORYDATES NIL
   SHORTDIRNAMES (master pr)
   DATE "21-Oct-2025 18:50:08"
   INFOS1 NIL
   INFOS2 NIL
   CDENTRIES NIL
   DEPTH1 NIL
   DEPTH2 NIL
   CDVALUE NIL
COMPAREDIRECTORIES
   BRANCH1 origin/master
   BRANCH2 "origin/fgh¬lfg-loadup"
   LOCAL NIL
   PROJECT (GIT-PROJECT MEDLEY {MEDLEY} NIL (
"EXPORTS.ALL" "RDSYS" "RDSYS.LCOM" "loadups/" "patches/"
 "tmp/" "fontsold/" "clos/" "cltl2/" --) (greetfiles 
scripts sources library lispusers internal doctools 
rooms) "{UNIX}/home/paolo/medley/medley" origin/master)
   SHORT1 "origin/master"
   SHORT2 "origin/fgh¬lfg-loadup"
   CDVALUE NIL
   DIRS ("{FROMGIT1}<master>" "{FROMGIT1}<pr>" NIL)
   NENTRIES NIL
   MAPPINGS NIL
GIT-BRANCHES-COMPARE-DIRECTORIES
   RB "origin/fgh¬lfg-loadup"
   PROJECT MEDLEY
GIT-PR-COMPARE
   *FORM* (GIT-PR-COMPARE "origin/fgh¬lfg-loadup" (QUOTE
 MEDLEY))
   *ARGVAL* NIL
   *TAIL* NIL
   *FN* GIT-PR-COMPARE
\EVALFORM
   %#FORM# (GIT-PR-COMPARE "origin/fgh¬lfg-loadup" (
QUOTE MEDLEY))
   *CURRENT-PROCESS* #<Process prc/173,116000>
   HELPFLAG BREAK!
   \CURRENTDISPLAYLINE 8
   \#DISPLAYLINES 13
   \LINEBUF.OFD #<IO Linebuffer Stream/127,5700>
   *READTABLE* #<ReadTable INTERLISP/173,152714>
   \PRIMTERMTABLE {TERMTABLEP}#173,145740
   \PRIMTERMSA {CHARTABLE}#173,146000
   TtyDisplayStream #<Output Display Stream/173,47700>
   SI::*RESETFORMS* NIL
   \INTERRUPTABLE T
   \TTYWINDOW {WINDOW}#120,101570
   READBUF NIL
   \TERM.OFD #<Output Display Stream/145,125500>
   *STANDARD-OUTPUT* #<Output Display Stream/145,125500>
   *STANDARD-INPUT* #<IO Linebuffer Stream/127,5700>
\MAKE.PROCESS0
T

The loadup* files in the Medley scripts directory:

paolo@lispmachine:~/medley/medley$ ls scripts/loadup*
scripts/loadup         scripts/loadup-db.sh
scripts/loadup-all.sh  scripts/loadup-full.sh

scripts/loadups:
loadup                    loadup-db.sh              loadup-mid-from-init.sh
loadup-all.sh             loadup-full-from-lisp.sh  loadup-setup.sh
loadup-apps-from-full.sh  loadup-full.sh            obsolete
loadup-aux.sh             loadup-init.sh            thin_loadups.sh
loadup-db-from-full.sh    loadup-lisp-from-mid.sh

I use the apps sysout and I'm on nhb-rewrite-version-parser-v2/60e12da of Maiko.

nbriggs · 2025-10-21T17:37:08Z

I notice that the branch it's working with is BRANCH2 "origin/fgh¬lfg-loadup", though the actual name is fgh_lfg-loadup -- notice the underscore (0x5F) vs logical not (0xC2AC). I'm guessing that the MCCS translations are somehow involved (unexpectedly missing, or unexpectedly present)

rmkaplan · 2025-10-21T18:59:40Z

Yes, I may have gotten out of step during the MCCS PR delay. But I don't yet understand why it appears to fail only when it is working on the master side.

…

On Oct 21, 2025, at 10:37 AM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2321) <#2321 (comment)> I notice that the branch it's working with is BRANCH2 "origin/fgh¬lfg-loadup", though the actual name is fgh_lfg-loadup -- notice the underscore (0x5F) vs logical not (0xC2AC). I'm guessing that the MCCS translations are somehow involved (unexpectedly missing, or unexpectedly present) — Reply to this email directly, view it on GitHub <#2321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNX4WG5XJIMR75JGE33YZVNVAVCNFSM6AAAAACJYALFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRYGE3DKMBYHE>. You are receiving this because you authored the thread.

rmkaplan · 2025-10-21T19:45:57Z

The low-level function is issuing a git command to retrieve the contents of a particular file, which it then stores in a local tmp/ file. It is called first to obtain the file from master, then to obtain the corresponding file from the pr. For this particular pr, PROCESS-COMMAND gets an error code 128 when it tries to retrieve the master but it gets a code 0 when it asks for the version of the file in the pr. Here are the actual (MCCS) command strings given to PROCESS-COMMAND:

For the master file (fails):
"cd /Users/kaplan/Local/medley3.5/git-medley/ && git show %"origin/master:scripts/loadup-app-setup.sh%" > /tmp/medley-1791044136-55954-result 2> /tmp/medley-1791044136-55954-error"

For the pr file (succeeds):
"cd /Users/kaplan/Local/medley3.5/git-medley/ && git show %"origin/fgh_lfg-loadup:scripts/loadup-app-setup.sh%" > /tmp/medley-1791044219-36169-result 2> /tmp/medley-1791044219-36169-error"

Note the (MCCS) underscore (0,255) in the string passed to PROCESS-COMMAND for the pr but not for the master, so you would think that that one might fail. But streams on the SHELL-DEVICE default to :UTF-8, and that appears to be working as expected--it does seem to find the file.

I don't understand why the master command fails just for this pr. Any ideas?

rmkaplan · 2025-10-21T19:52:55Z

I inserted the offending command in a terminal window, and finally got a helpful error message: the path scripts/loadup-app-setup.sh does not exist. So it the problem is probably at a higher level, where it is interpreting the ADD return from the difference function, not at the bottom character level. Another mystery: how did it ever work?

nbriggs · 2025-10-21T19:54:04Z

That's a new file, it doesn't exist in master, so git is saying (try it in a Terminal in the medley directory)

 % git show origin/master:scripts/loadup-app-setup.sh 
fatal: path 'scripts/loadup-app-setup.sh' does not exist in 'origin/master'

and if we just look at what changed between the two branches --

briggs@macrobiotic medley % git whatchanged origin/master..origin/fgh_lfg-loadup 
commit d91176bc908b851289abdde0f768d4a297372ef1 (origin/fgh_lfg-loadup)
Author: Frank Halasz <frank@halasz.org>
Date:   Mon Jan 6 23:59:20 2025 -0800

    Minor fixes to loadup-lfg and related scripts as result of debugging.

:100644 100644 fde59bf6 76c574d9 M      scripts/loadup-app-setup.sh
:100755 100755 a0d84bbc 590a9dab M      scripts/loadup-lfg.sh

commit a55246bc5937d93e8f843ac6ea1d3926f792c9ae
Author: Frank Halasz <frank@halasz.org>
Date:   Mon Jan 6 22:49:21 2025 -0800

    Create loadup-lfg.sh script and helper script loadup-app-setup.sh.  The former is intended to be installed in the LFG directory (in the scripts subfolder).  The later is to remain in the medley scripts direcory.

:000000 100644 00000000 fde59bf6 A      scripts/loadup-app-setup.sh
:000000 100755 00000000 a0d84bbc A      scripts/loadup-lfg.sh

So in one commit he added the files, then in the second commit he modified them. Did GITFNS get confused by the modification vs addition?

rmkaplan · 2025-10-21T20:42:48Z

This is what comes back from the call to GIT-BRANCH-DIFF in GIT-GET-DIFFERENT-FILES:
((ADDED scripts/loadup-app-setup.sh) (COPIED scripts/loadup-apps-from-full.sh 64))

This is based on the result of the ind-copies-harder command, which returns a file with lines
"A scripts/loadup-app-setup.sh"
"C064 scripts/loadup-apps-from-full.sh scripts/loadup-lfg.sh"

So I don't see any residue of the modify commit.

So suppose that it is correct that the modify is not relevant and the Add is the only thing it should pay attention to. Then what may be special about this particular pr is that the app-setup file exists only in that pr subdirectory and not in the master (because it was added). Since this pr has no other files in that subdirectory, the later attempt at enumeration sees a nonexistent directory and fails.

nbriggs · 2025-10-21T20:52:06Z

Something is being too smart --

"C064 scripts/loadup-apps-from-full.sh scripts/loadup-lfg.sh"

If you copy a file to a different name, the target name may well be a new file. I don't know that it's guaranteed to be new (it could be being replaced, I suppose) but... in this case it IS a new file based on a old file.

rmkaplan · 2025-10-22T01:48:15Z

On reflection, the most obvious approach would be for GITFNS to treat git-copy as a git-add of the target file. The comparison won't tell you where the new file came from (presumably git transfers the history on a copy?), but that's not relevant for the compare. The merge would do whatever it would do wrt history.

That now behaves well in my working directory, and I can commit an updated GITFNS. But I think that, because of the underscore, it won't work for Frank's old pr until the MCCS filename pr gets approved and merged.

rmkaplan · 2025-10-22T15:38:46Z

I committed the updated GITFNS and related updated COMPAREDIRECTORIES. prc should work for all PR's except for the #1960 (with the underscore). That will work when #2320 is merged.

pamoroso · 2025-10-23T09:42:59Z

I updated to commit bde0b3d and PRC works fine except for PR #1960 as expected.

pamoroso · 2025-10-26T17:52:19Z

I updated to commit 44f767e, nothing unusual to report.

rmkaplan · 2025-10-26T18:53:20Z

The last commit is a refinement on the DSK/UNIX issue. I assume there are 2 working modes: people doing development in the clone and expecting Medley version numbers to work there (at least up until a branch switch), and people (like me) doing development in a separate pure Medley working environment and using the GITFNS gwc command to copy things over to the clone in preparation for a commit and push.

The {MEDLEY} pseudohost remains on {DSK} in this commit, so working there in a single branch will continue to produce a proper sequence of versioned files. The refinement in this commit is that the gwc copy command when copying to the clone treats it as a UNIX device--the new file overwrites the old file, previous versions don't stack up. On a switch, you would see only the files on the new branch, you won't run over old detached versions. So you have a typical Unix/git environment on one side, a typical Medley environment on the other, with gwc bridging between them.

masinter · 2025-10-26T19:58:54Z

There's a problem in most of these working styles that filemaps seem to be tied to the Medley version number, so if you make a file in one system and then interact with the file to another version number, the filemap doesn't match. Perhaps it's only a problem in the same image?

Anyway, i think the simplest relaible fix would be to change things so that file maps are proper caches -- get recomputed whenever they're wrong.

rmkaplan · 2025-10-26T20:37:56Z

That seems to be OK. The Unix (unversioned) file EXAMINEDEFS shows up as version 1 when connected to the clone as DSK, internally the file itself is version 59 from my working directory. But GETDEF, PF etc all seem to work, FINDFNDEF gets the filemap. Which is not to say that, as a separate issue, the filemap shouldn't be reconstructed if it turns out to be inconsistent with the file.

…

On Oct 26, 2025, at 12:59 PM, Larry Masinter ***@***.***> wrote: masinter left a comment (Interlisp/medley#2321) <#2321 (comment)> There's a problem in most of these working styles that filemaps seem to be tied to the Medley version number, so if you make a file in one system and then interact with the file to another version number, the filemap doesn't match. Perhaps it's only a problem in the same image? Anyway, i think the simplest relaible fix would be to change things so that file maps are proper caches -- get recomputed whenever they're wrong. — Reply to this email directly, view it on GitHub <#2321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLKSBO5BTDZCY6RA3L3ZURZJAVCNFSM6AAAAACJYALFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBYHA4DKMZWGM>. You are receiving this because you authored the thread.

pamoroso

Except as noted in the discussion it works with no issues in my testing of PRC.

Adjustments to GITFNS

301c4f7

prc status is C if changes requested, prc comparison runs in its own process, initial changes for gwc to treat the clone as UNIX, not DSK, so branch-switching doesn't cause files from other branches to pile up.

rmkaplan added 2 commits October 22, 2025 08:35

Better interpretation of git-copy

7ce5eeb

COMPAREDIRECTORIES: don't fail on empty directory

b75c561

rmkaplan added 2 commits October 22, 2025 13:21

Bug in slashit

76b3090

{MEDLEY} is on {UNIX}

bde0b3d

gwc copies to UNIX--doesn't track Medley version numbers in the clone

44f767e

pamoroso approved these changes Oct 27, 2025

View reviewed changes

rmkaplan merged commit aae53a7 into master Oct 27, 2025

Uh oh!

Adjustments to GITFNS #2321

Adjustments to GITFNS #2321

Uh oh!

Conversation

rmkaplan commented Oct 21, 2025

Uh oh!

pamoroso commented Oct 21, 2025

Uh oh!

nbriggs commented Oct 21, 2025

Uh oh!

rmkaplan commented Oct 21, 2025 via email

Uh oh!

rmkaplan commented Oct 21, 2025

Uh oh!

rmkaplan commented Oct 21, 2025

Uh oh!

nbriggs commented Oct 21, 2025

Uh oh!

rmkaplan commented Oct 21, 2025

Uh oh!

nbriggs commented Oct 21, 2025

Uh oh!

rmkaplan commented Oct 22, 2025

Uh oh!

rmkaplan commented Oct 22, 2025

Uh oh!

pamoroso commented Oct 23, 2025

Uh oh!

pamoroso commented Oct 26, 2025

Uh oh!

rmkaplan commented Oct 26, 2025

Uh oh!

masinter commented Oct 26, 2025

Uh oh!

rmkaplan commented Oct 26, 2025 via email

Uh oh!

pamoroso left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants