Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
373 stars 19 forks source link

SYSOUT doesn't work to a pseudohost #940

Open rmkaplan opened 2 years ago

rmkaplan commented 2 years ago

(SYSOUT '{WMEDLEY}/tmp/foo.sysout) doesn't work.

There is a lot of filename and host hacking inside \COPYSYS to get a file name, and then it does a RENAMEFILE after that. I think it would work if the original sysout was made to a standard name, like /tmp/xxx and let only the rename deal with Medley conventions. But I'm not sure.

masinter commented 2 years ago

RENAMEFILE is only a fast, atomic action if the source and destination are on the same file system. Otherwise it's a copy-and-delete. The maiko code for SAVEVM actually saves it to lisp.virtualmem-temp (or whatever LDEDESTSYSOUT is) and then renames it if it can.

This would be OK except when you have two processes running, both trying to write out lisp.virtualmem-temp which makes savevm no longer (as) fast or atomic.

masinter commented 2 years ago

see #923 for more discussion. Pseudohost adds another layer of complexity ... maybe we should do a review ?

rmkaplan commented 2 years ago

A review of all of this would be good. But I think that the SAVEVM issues are different than the SYSOUT or MAKESYS issues, where the problem is to get to a particular file with a particular name in the file system. They may interact if the \FLUSHVM has to go through the virtual memory file, but if so, I presume that that then gets copied into a separately named file. The problem here is that \COPYSYS is doing its own fooling with curly brackets and the like, not going through generic interfaces.

On Sep 15, 2022, at 9:15 AM, Larry Masinter @.***> wrote:

see #923 https://github.com/Interlisp/medley/issues/923 for more discussion. Pseudohost adds another layer of complexity ... maybe we should do a review ?

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/940#issuecomment-1248318051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJXDLIBWMZI6EFPHQTV6NDTLANCNFSM6AAAAAAQNC6OYY. You are receiving this because you authored the thread.

masinter commented 2 years ago

The Msiko code goes through extra steps to insure sysouts are not versioned. See dsk.c


 * Examines the statistics of the file system on which the specified sysout file
 * resides, and returns the number of available free blocks through the specified
 * buffer.
 * This routine is invoked just before the Lisp flushes its image on a sysout file so
 * as to make sure the Lisp image is gracefully written on a sysout file.  See
 * \MAIKO.CHECKFREESPACE in MOD44IO.
 * The version control based on a file naming convention is not applicable to a
 * sysout file, even if the sysout file is specified on {DSK} device.  The Lisp code
 * strips the version field by invoking DSK_getfilename with NON recognition mode.
 */

and

    case RECOG_NON:
      /*
       * "Non" recognition is used to recognize a sysout file.  The sysout
       * file is dealt with specially, it does not have any version, even
       * if it is on {DSK} device.  Only we have to do here is to make
       * sure the path to reach to the specified file is an existing
       * directories.  The file name itself is recognized as if.
       */

but 14-Oct-2020 sysout was changed to make it versioned anyway

image

recover-versions.sh ADIR

combined with CSBROWSER is a useful tool for seeing versions in Lisp code.

rmkaplan commented 2 years ago

I made that change. Maiko apparently doesn’t want to deal with version numbers, no matter what the device. And presumably that is certainty true for the lisp.virtualmemory file.

But there is no reason why, at the Medley level that sysout and makesys files can’t be versioned, if they are being made on a versioned file system. Hence the explicit RENAMEFILE in \COPYSYS, to do the versioning after the return from Maiko.

Otherwise, the user would have to provide a new name for each sysout in a sequence of check points. No more “REDO SYSOUT”.

I think the problem is that this was done (maybe by me) in a clunky way, not respecting proper interfaces.

On Sep 15, 2022, at 12:53 PM, Larry Masinter @.***> wrote:

I wrote a longer note but lost it. ADIR was changed in 2020 to create new versions -- despite the fact that there's code in maiko/src/dsk.c to explicitly not do versions even if the sysout name is on {DSK}.

https://user-images.githubusercontent.com/1116587/190496138-d06341ca-df6e-4ff8-bd36-1ad06a02c8a9.png — Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/940#issuecomment-1248544291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJMPZ4KBY4MWNVF7USLV6N5EXANCNFSM6AAAAAAQNC6OYY. You are receiving this because you authored the thread.

masinter commented 2 years ago

What I'm saying is that if you want version numbers in sysouts, we should consider turning off the code in Maiko so it will treat sysout file names like any other file name.

nbriggs commented 2 years ago

Here's how I think it should work: the maiko code should be using the filename from the LDEDESTSYSOUT as the place that the VM is written to after it has loaded it from the LDESRCESYSOUT... (that would be lisp.virtualmem if not otherwise specified). I don't think the virtual memory files should have versions. If you do a SYSOUT or MAKESYS, then before the file name is passed down to the maiko code, virtual hostnames should be resolved, and the real file name (e.g., {dsk}... or {unix}...) should be passed down. Maiko should not have to deal with virtual hosts. If Maiko needs a temporary filename, it should create a unique one and then rename it -- it can (and probably should) do that on the same host filesystem that it is going to write the final file to so that the rename IS an atomic operation.

masinter commented 1 year ago

recent changes to 'medley' start-up script to manage lisp.virtualmem files? @fghalasz comments?