Path Proposal for Medley

[blakemcbride]

Path Proposal for Medley

Revision History

Blake McBride 2020-12-09 Original proposal

---

Problem

Special configuration options notwithstanding, Medley defaults to storing its lisp.virtualmem, SYSOUT files, and makefiles in the user's home directory. This surely made a lot of sense in the days when machines were smaller and more single-purpose. However, this is a problem with modern machines because:

1. It clutters up a user's home directory.
2. When working on multiple projects, the various lisp.virtualmem, SYSOUT, and makefiles get intermixed.

Proposal

1. Medley's executable programs and scripts should be located in the /usr/local/bin directory.

2. Store other common Medley files (such as standard images, system source code, documentation files, etc. in the /usr/local/share/medley directory. /usr/local is called the Medley Home directory.

3. The directory the user was in when Medley is started is called the "Project Directory".

4. By default, Medley accesses the lisp.virtualmem, SYSOUT files, and makefiles in the Project Directory. It may also have pointers to and read files in the Medley Home directory.

5. If there is no lisp.virtualmem file in the Project Directory, Medley will load a standard SYSOUT located under the Medley Home.

6. Under normal circumstances, Medley does not access any files outside of the Medley Home directory or the Project Directory.

7. Unless explicitly changed, Medley will treat the Project Directory as its home or default path.

8. Users are not allowed to write to the Medley Home.

9. The medley build process should have a make target "install" that sets up and installs the Medley Home.

Advantages:

1. The system will be laid out in a form well understood by the community.

2. The system will be laid out in a practical and clean way that is cooperative with other applications on the system.

3. The system will best support multiple projects as well as multiple users on the same system.

Potential Issues

1. Users are not allowed to write to the Medley Home. Therefore, some procedures will need to be used to support efforts to modify Medley system files when modifying Medley-specific files.

2. This proposal makes sense for Linux, BSD, and other standard Unix-like distributions. It may need adjustments for the Apple Mac environment.

[masinter]

Whatever we do, we should sync with the documentation such as there is (the README files in the medley and maiko repos).
There are probably different configurations depending on what the user is doing (just using it for their own projects vs. developing and testing medley).
There are three windows configurations (Docker, WSL2, maybe cygwin) and probably twice as many when you figure in case-sensitive vs. case-insensitive file systems.

[Anzus]

I'm not sure I understand the problem?
(LOGOUT) writes the sysout to whatever the value of the shell variable LDEDESTSYSOUT is.
(SYSOUT) writes the sysout to the connected directory if there is no file path in the argument, and to the full file path if there is one.
lde without any arguments will load the sysout as defined as follows in main.c:
/* Sysout is found as follows:
If the first argument doesn't begin with '-', assume it's the sysout
Look at the environment variable LDESRCESYSOUT if that fails
Look for ~/lisp.virtualmem if that fails
Barf and print the command line if tha fails
*/

[blakemcbride]

1. If you set no special options or variables, by default, Medley writes to the home directory regardless of where you were when you started the system. This means you'd have to set an environment variable each time you wished to use the system.

2. I do not know what the term "connected directory" means. If there is no path, Medley writes to the user's home directory.

3. What I am suggesting is how all other systems work. It is what new users will expect.

[rmkaplan]

If there is no path on a filename, then that is interpreted as a path relative to the medley-connected directory, established by cd inside medley or by (CNDIR ...). That is the value returned by (DIRECTORY T), which may or may not be the same as the LOGINHOST/DIR which is defined by LOGINDIR and returned by (DIRECTORY NIL). But the medley-connected directory has no defined relationship to the shell connected directory from which the medley was launched.

When you start medley, you are by default medley-connected to your LOGINHOST/DIR. If you don't changed that (by cd or CNDIR), then that's where your relative-path files will go.

Thus, SYSOUT takes a filename (with or without a path, which maybe relative or absolute) as an argument and it writes to the file specified by that filename. If the filename has a relative path (e.g. abc/foo.sysout), then that path is interpreted as relative to the (medley-) connected directory. Simple case: (SYSOUT 'parser.sysout) when medley-connected to {DSK}/Users/kaplan/projects/lfg produces the sysout on file {Dsk}/Users/kaplan/projects/lfg/parser.sysout.

There are some (helpful) defaults defined in BEFORESYSOUTFORMS. If you don't give a file name (e.g. (SYSOUT) or (SYSOUT NIL)), then the filename defaults to WORK.SYSOUT, the medley-connected directory gets attached, and the file gets made in the medley-connected directory.

If the filename is given but without an extension (e.g. (SYSOUT 'FOO)), the default extension SYSOUT is also stuck in, and again it goes in the connected directory.

Almost all relative-path file operations in Medley (except finding the personal greeting file) default to the medley-connected directory. E.g. MAKEFILE for relatively-path filenames when connected to my LFG directory produces files in my LFG directory, not my Mac home directory (which is actually not my LOGINHOST/DIR anyway).

If you execute a shell command from medley (via the functions shell or ShellCommand), that command I presume gets executed in your shell-connected directory. Maybe CHDIR is there to change that in advance of executing in a lower shell?

[rmkaplan]

Perhaps a helpful additional note: Remember that Medley/Interlisp-D was originally built when there was no separate operating system or separate file system with its own notion of connected or current directory. So Medley has its own.

[rmkaplan]

One other note for Blake...

If you are running in an xfull.sysout you can look at the definition of a given system function by using PF (=print function from file) or PF* (=print function from file showing comments). E.g. PF SYSOUT shows you the definition of SYSOUT from whatever file it is defined on. It's convenient to be in the Interlisp package when you do this (Interlisp exec instead of a commonlisp exec), since virtually all of the system functions are in the Interlisp package. Otherwise you'd have to say IL:PF IL:SYSOUT.

[masinter]

I was thinking of changing the default so that it started up with Two exec windows: both an Interlisp Exec and a Common Lisp one.
(Opinions by "reply" to this comment pls)

[blakemcbride]

Thanks for the explanations, however, I think a point may be being missed. I understand that there are commands to do what I want. I've always understood that.

My point is that the way Medley worked made sense in circumstances that existed at that time. Now they are awkward and inconvenient. I think this change makes Medley significantly less awkward and inconvenient in modern environments.

[Anzus]

1) You don’t have to set the environment variable every time, you do it once in your dotfiles 2) “connected directory” means the directory you are currently in, just like ‘cd’ in unix. 3) there are plenty of systems that start out with “put this in your dotfiles” or “ensure that your PATH variable is set thusly”. It’s not unusual. We just need to ensure it’s documented. Arun Welch welch@anzus.com

…

On Dec 9, 2020, at 5:03 PM, Blake McBride ***@***.***> wrote: If you set no special options or variables, by default, Medley writes to the home directory regardless of where you were when you started the system. This means you'd have to set an environment variable each time you wished to use the system. I do not know what the term "connected directory" means. If there is no path, Medley writes to the user's home directory. What I am suggesting is how all other systems work. It is what new users will expect. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP2DB6LH2LXYHCQVBJRI3SUAF4DANCNFSM4UUGEDRA>.

[blakemcbride]

Let's say I have three projects I am working on. I want the lisp.virtualmem, the SYSOUT, and all the makefile for each project in their own, individual "project directory". So there are three different project directories. Would I have to set the environment variable you are referring to to three different values depending on which project I am working on?

[Anzus]

I guess I don't understand why the three projects need worked on in different VM's, but if I were particularly committed to this idea I would probably have a shell script that set up the environment for "work on this project". Are you trying to do this in the python virtualenv style?

[blakemcbride]

Not trying to do it like the python virtualenv. (And, not a fan of Python.) Is Python a good programming language

If I am doing three totally unrelated projects (something I do all of the time) the code for each is separate and unrelated. I think, perhaps, that many of the people who worked from the inside on Medley were primarily working on making the tool (Medley). So there was only one overarching project.

People outside of the Medley development effort want to use Medley as a tool to build other, unrelated to each other, projects. We don't want functionality from one project co-mingled with another project. The clean way to accomplish this is to start all three projects with an initial, default Medley image. As the project evolves (independently) you want the lisp.virtualmem file, SYSOUT, and makefiles separate for each project.

The computing world has solved this issue. The way they do it is as I described in my proposal. Yes, you can set different environment variables for each project. That'll work. It's an unnecessary extra step each time, however. More importantly, however, is that the model you are using, while it is workable, it is foreign and clunky to the general software engineering community.

The proposal I made:

1. Is easy to implement
2. Requires fewer steps for people to use
3. Is a process familiar and comfortable to the software development world

If we want people to use Medley, we need to eliminate unnecessary barriers. Requiring extra steps and working in an unnatural way requiring research to figure out adds unnecessary barriers.

Lastly, while other systems do require the setting of environment variables, not one I've seen in 40 years requires me to change that setting for each project I work on.

[blakemcbride]

Looking at the comments above and the system, I fail to see a single environment variable that sets the medley-connected directory and thus the default location for lisp.virtualmem and all of the SYSOUT and makefile loads and saves.

In other words, if I am correct, you can't even make any practical use of Medley without a great deal of time-consuming research and cumbersome and error-prone fiddling.

[blakemcbride]

Just to underscore the point in real terms - I work on two totally unrelated systems every day. One has around 10,000 source files and the other has around 1,000 source files. Not a single file is in common between the two systems. It is critical for me to keep them utterly separate.

[masinter]

it shouldn't be difficult to set up a branch organizing things Blake's way and try it

[rmkaplan]

I have many projects (LFG is one of them) with their own directories for files which may or may not contain a sysout/makesys with relevant files already loaded. My .rc file has an alias to a wrapper-script around the call to lde (now transformed to a wrapper around Larry’s new runmedley script) that picks a particular sysout (e.g. an -lfg option) from the right place. My personal greeting file defines a new command cdlfg that knows where the lfg project is located, so I can go there easily if I want to work on the lfg files per se as opposed to using the lfg sysout to work on, say, the German or English grammars. The files in the grammar directories are not Medley specific, they are used by other programs as well. I also have commands cdl cdlu cdll that connect to the lispcore, lispcore/library, lispcore/lispusers directories relative to MEDLEYDIR. Typically, when I’m just starting to work on something that may or may not turn into a project, I’ll start by making files in my default LOGINHOST/DIR, then rename them to somewhere else if they really deserve it. Thus, at medley start-up it isn’t clear where I want to be connected, maybe not to the LFG or grammar files at all even if running the LFG sysout, maybe even to my Dropbox (/Users/kaplan/Dropbox) or, if just to fiddle around, maybe leaving it connected to my LOGINHOST/DIR (I have LOGINDIR set to /Users/kaplan/lisp, which is different from MEDLEYDIR). But I certainly don’t have any interest in the directory that I happen to be connected to at the time that I do the runmedley, that’s random. I’ll also note that some files defined for one project are used by others, but I only want the common files to exist in a single place. The various fileCOMS know how to do the cross-linkages as needed (and my personal greeting pushes the various project directories onto the search-path DIRECTORIES). That is, I DO want files from one project to comingle with other projects. The file package keeps track of where various functions come from, building a new sysout for a project will contain the relevant pieces from wherever they originated. You could store the lispcore files and the original xlisp and xfull sysouts somewhere on /usr/, but I don’t see the advantage of that. Wherever you store it, a single variable MEDLEYDIR (set before invoking the runmedley) points to it or defaulting inside runmedley). (Also, /usr/ makes me nervous, Apple seems to think it owns it). For me it is also important for Medley to be able to read and write on the whole disk. On the Mac, I had to give lde full disk access in the Privacy/Security settings. Otherwise I couldn’t even fiddle with files on the Desktop. It may be useful to have some simple conventions to help new people get into this (and to understand that when they start-up a Medley sysout, they “reside” there and not in the operating system—that is the right model to have). But otherwise I don’t see a need to legislate anything. We can set up a branch for some people to use, but I wouldn't see any personal benefit, and might find that it creates a nuisance. —— With respect to the comment below, the reason that there is no single environment variable that sets all that stuff is that those various things are not naturally or necessarily all in the same place. The lisp and full sysouts delivered from the repository logically may go in a place (MEDLEYDIR) relative to the lispcore sources (if those have also been installed), other files go in other places, defined by either the LOGINDIR or anywhere else.

…

On Dec 10, 2020, at 8:02 AM, Blake McBride ***@***.***> wrote: Looking at the comments above and the system, I fail to see a single environment variable that sets the medley-connected directory and thus the default location for lisp.virtualmem and all of the SYSOUT and makefile loads and saves. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKV7ME4R4B6PKXJFWTSUDWKBANCNFSM4UUGEDRA>.

[blakemcbride]

First, I am not legislating anything any more than you are legislating the format of a SYSOUT file.

Second, the format I am proposing, as I'm saying repeatedly, is the way virtually all software in the Linux world works. Developers on a Linux box will understand and expect it that way.

Third, you are proving my point. You are going through all sorts of gyrations to get the operations that my proposal gives you for free without wrappers, variables, etc.

Fourth, when you speak of MEDLEYDIR, LOGINDIR, LOGINHOST/DIR, etc. I don't know what you are talking about. Are you talking about variables inside Interlisp or are you talking about environment variables, or something else?

[masinter]

in the directory "makesysout" there are two Lisp files and two scripts
loadup-lisp.sh   which uses the file SYNCLISPFILES(.LCOM) to build xlisp.sysout based on lisp.venuesysoutloadup-full.sh    which uses the file MAKEFULLSYSOUT(.LCOM) to build xfull35.sysout based on xlisp.sysoutand in the directory "greetfiles" there's a file SIMPLE-INIT
I recently moved a lot of the definitions that used to be in SIMPLE-INIT into SYNCLISPFILES so that, well, SIMPLE-INIT could be simple.
@blakemcbride I think we need to build a concrete branch of medley which Ron can try out in his configuration. I'm happy to help out here.

[blakemcbride]

Thanks, Larry. I'm happy to help too.

[masinter]

We've been around on this topic a while, I think Blake's viewpoint is similar to @nbriggs

https://github.com/Interlisp/medley/labels/config
#49

[nbriggs]

Well, yes, and no. I'm fine (happy even) with "make install" from the medley git repo building the lde/ldex/other executables and installing them in /usr/local/bin (actuallly $PREFIX/bin, with PREFIX=/usr/local by default, but it's NOT always /usr/local) and I'm fine with that also installing the fonts in $PREFIX/share/medley/fonts, and the library packages (source and compiled) in $PREFIX/share/medley/library, and the lispusers packages (source and compiled) in $PREFIX/share/medley/lispusers -- except that it's entirely possible that a person working on a new lispusers package would want to write there, and FOR SURE a medley system developer is going to want to write to the library as well.

With respect to the startup stuff? No. The sysouts should be able to find my SITE-INIT file, and that should have enough to ensure that it can find my personal greet file which will make any necessary adjustments after that, in Lisp. If I choose to guide that through setting environment variables, fine, but I don't want it to depend on the current working directory when I started the system. I'm pretty much aligned with Ron on this, I think.

[blakemcbride]

I suppose when you run the C compiler, regardless of where you are running it from, it should deposit all of the objects in the user's home directory......

[nbriggs]

That's a bogus argument.

If you run the C compiler and you don't tell it otherwise where to put the object files it defaults to the directory where you happen to be. Sometimes that's OK, but nobody objects to telling the C compiler otherwise -- e.g. -o ../obj, or ../$HOST-TRIPLET, or some other location.

Medley uses your home directory if you don't tell it otherwise (and since it's a residential environment, that's done INSIDE medley not in the shell that started it) -- but of course you usually tell it otherwise, either directly by "connecting" to a directory (which is the equivalent of cwd), or you might use the SAMEDIR package, which warns you if you're not writing the compiled file into the same directory as the source file, or you might have your Lisp greet file look at which directory you started from and change some defaults.

[blakemcbride]

Errr, no it's not. I'm not going to bother arguing my position further. I've said everything that needs to be said by me.

If there is a way to tell Medley to read and write all SYSOUT's, lisp.virtualmem, lisp, and makefile code, in a particular directory other than my home directory, I would appreciate that information. IMO, Medley is very cumbersome to use without that. (I presume it has it, at least according to Ron.) Please tell me how. Thanks!

[blakemcbride]

BTW, your last paragraph has a chicken-and-egg logic problem - especially since there is no SYSIN. (You can't change anything inside Medley since the image is already loaded. It's done and you can't change it without starting Medley over again - then you get back to the same ~/lisp.virtualmem.....)

[Anzus]

LOGINHOST/DIR is the Interlisp equivalent to $HOME in unix shells. Or, to put it another way, it’s the default directory you end up in when you type in CONN or CD. Arun Welch welch@anzus.com

…

On Dec 10, 2020, at 7:47 PM, Blake McBride ***@***.***> wrote: From Interlisp I did: (SETQ LOGINHOST/DIR "/home/blake/tmp") (LOGOUT) lisp.virtualmem still ended up in my home directory. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP2DBL4KLSNOINH5CDEALSUGB2VANCNFSM4UUGEDRA>.

[rmkaplan]

As I mentioned in a previous message, the path for the virtual memory file is special. It is set by a separate environment variable LDEDESTSYSOUT before lde is called from a shell to start medley (and Nick may know whether lde has a built-in default if that variable is undefined). Larry’s run-medley script sets it to ${HOME}/lisp.virtualmem before calling lde. If you want the flexibility to stash it somewhere else, then Larry’s script should be changed to set that variable to the default only if it isn’t already defined. Then you could set it in your .rc file and be done with it. On the other hand, maybe this default location is not optimal, maybe the script should default it to the value of LOGINDIR if that is defined before lde is invoked. I haven’t bothered to change it in the 3 years since I started again to run this stuff, and it is the only medley-specific thing that shows up at the top-level of my home directory (because I set LOGINDIR to ${HOME}/lisp in my rc file, store other files and sysouts in their respective project directories, and hardly ever go back to my top level from inside medley).

…

On Dec 10, 2020, at 6:47 PM, Blake McBride ***@***.***> wrote: From Interlisp I did: (SETQ LOGINHOST/DIR "/home/blake/tmp") (LOGOUT) lisp.virtualmem still ended up in my home directory. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[nbriggs]

On Dec 10, 2020, at 7:39 PM, rmkaplan ***@***.***> wrote: As I mentioned in a previous message, the path for the virtual memory file is special. It is set by a separate environment variable LDEDESTSYSOUT before lde is called from a shell to start medley (and Nick may know whether lde has a built-in default if that variable is undefined).

Yes, the default is $HOME/lisp.virtualmem

Larry’s run-medley script sets it to ${HOME}/lisp.virtualmem before calling lde.

Which I thought I'd grumbled about. Doing that adds no value (because it's the default if unset), and explicitly setting it prevents you from setting it to what you want it to be, outside the script.

If you want the flexibility to stash it somewhere else, then Larry’s script should be changed to set that variable to the default only if it isn’t already defined.

That would be ok, the set-only-if-unset would document (if you read the script...) that you might expect to set it.

Then you could set it in your .rc file and be done with it. On the other hand, maybe this default location is not optimal, maybe the script should default it to the value of LOGINDIR if that is defined before lde is invoked.

I think that Blake's request came down to... the default for LOGINHOST/DIR, from the run-medley+SIMPLE-INIT should be PWD rather than HOME if LOGINDIR is not set.

I haven’t bothered to change it in the 3 years since I started again to run this stuff, and it is the only medley-specific thing that shows up at the top-level of my home directory (because I set LOGINDIR to ${HOME}/lisp in my rc file, store other files and sysouts in their respective project directories, and hardly ever go back to my top level from inside medley).

Random ramblings: One of the new-user frustrations with a lot of systems is that there isn't "one right way" to do things. That's true in spades for Medley. We do need to provide simple defaults, but without rendering it impossible for the more sophisticated user to get the behavior they want/need. I think we're also seeing a mismatch between the new user's model of how to use the system (coming from Unix), and the model that the Medley system implements/supports. We can match these up a little through the default startup script+init file, and also adjusting the user's expectations through documentation. Because few people today are particularly familiar with a residential system like Interlisp it feels foreign to, for example, have multiple project's code loaded at the same time and only use a single VM. In terms of style-of-use, though, my whole laptop today feels rather as Interlisp did back in the day...

…

-- Nick

> On Dec 10, 2020, at 6:47 PM, Blake McBride ***@***.***> wrote: > > > From Interlisp I did: > > (SETQ LOGINHOST/DIR "/home/blake/tmp") > (LOGOUT) > > lisp.virtualmem still ended up in my home directory. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWISUN4UIQDF5YK7I53SUGH7XANCNFSM4UUGEDRA>.

[masinter]

#78 changes the defaults to run-medley:

• If you supply a -vmem file parameter
• else, if you set the LDEDESTSYSOUT environment variable
• else, if LOGINDIR is set, default is $LOGINDIR/lisp.virtualmem
• else $HOME/lisp.virtualmem

[blakemcbride]

On Fri, Dec 11, 2020 at 12:35 AM Nick Briggs ***@***.***> wrote: [...] I think that Blake's request came down to... the default for LOGINHOST/DIR, from the run-medley+SIMPLE-INIT should be PWD rather than HOME if LOGINDIR is not set.

I believe that is correct. We may be talking about just a few lines of code to change the whole thing.

[...] I think we're also seeing a mismatch between the new user's model of how to use the system (coming from Unix), and the model that the Medley system implements/supports. We can match these up a little through the default startup script+init file, and also adjusting the user's expectations through documentation. Because few people today are particularly familiar with a residential system like Interlisp it feels foreign to, for example, have multiple project's code loaded at the same time and only use a single VM. In terms of style-of-use, though, my whole laptop today feels rather as Interlisp did back in the day... -- Nick

That describes the crux of the problem - "though, my whole laptop today feels rather as Interlisp did back in the day...". It seems to me that many on the group just want access to an old Interlisp machine rather than bringing Interlisp to a modern environment. No one outside of the old group wants "my whole laptop today feels rather as Interlisp did back in the day". While they'd like to use Interlisp/Medley, they don't want their whole machine taken over by it. It must cooperate with the other things they do with the machine. My proposal does that. So, it appears to me that a far more fundamental decision needs to be made by the group. That decision will be a measuring stick against which proposals may be judged. That decision can be called our "Mission Statement". Given the difficulties and importance of discussions like this one, I think creating a Mission Statement may be the single most important next step. This Mission Statement is more important than any code changes because the Mission Statement would drive the code changes. Off the cuff, I can see where my mission statement would differ from much of the group's. I think it is worth hashing out. I'll take a stab at it: What I perceive the main group's mission statement might look like: Make Medley operate on a modern machine in a reliable way that is as similar to the way it operated on the old lisp machines as possible without purposely inhibiting other uses of the machine but also without regard to other uses of the machine. My mission statement would look more like: Make Medley operate on a modern machine in a reliable way that is as similar to the way it operated on the old lisp machines as possible except that changes will need to be made to make Medley more seamless, native, and cooperative with a modern environment and to bring Common Lisp up to ANSI Common Lisp. I'm sure these mission statements are crude and poor, but they are a starting point. I think it is vitally important for us to jointly create a meaningful mission statement that we can all back. That mission statement can be the measure we can use to decide the direction. Blake

[masinter]

continued via email https://groups.google.com/g/lispcore/c/3KYOpXgU940

[Anzus]

This [default openingd two windows, one for IL and another for CL] is reasonable. I don’t remember if this was how one of the early Lyric sysouts did it in release, but I’ve been doing it in my personal full sysout for a while. By “Common Lisp”, I assume you mean XCL and not the pure CL one? Arun Welch welch@anzus.com

…

On Dec 11, 2020, at 9:21 AM, Larry Masinter ***@***.***> wrote: I was thinking of changing the default so that it started up with Two exec windows: both an Interlisp Exec and a Common Lisp one. (Opinions by "reply" to this comment pls) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP2DEM2YT5N42EYZEMJ6TSUJBJ7ANCNFSM4UUGEDRA>.

[rmkaplan]

Then I would want to know how my greeting file could find the one I don’t want and take it down, and make sure the one that stays up is or moves to the right place. You would be optimizing for someone who wants to alternate back and forth between the two environments? Who is that? What’s wrong with leaving it the way it is (a commonlisp window if that’s what the default should be), and then advertising the INTERLISPMODE function that a personal greeting file can use to coerce it to Interlisp.

…

On Dec 11, 2020, at 8:21 AM, Larry Masinter ***@***.***> wrote: I was thinking of changing the default so that it started up with Two exec windows: both an Interlisp Exec and a Common Lisp one. (Opinions by "reply" to this comment pls) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJP2GV22H75W7HINKWTSUJBJ7ANCNFSM4UUGEDRA>.

[rmkaplan]

Why does it default to a name like lisp.virtualmem instead of something like medleycheckpoint.sysout? It may have been the page-swapping backing store in the old days, but now it’s just a sysout file that SAVEVM and LOGOUT happen to write out, and then its the default image if you run medley without specifying a particular sysout or makesys. It’s now kind of a misleading name. It doesn’t even exist if you haven't explicitly checkpointed. And the checkpointing logic of that may now be a little goofy and perhaps even a little dangerous, given that you can run 2 or more medleys side by side starting from different terminal windows. Presumably the named file will checkpoint only the last one that you saved in or logged out of—and overwrite a checkpoint that you thought you had safely cached away.

…

On Dec 12, 2020, at 8:41 PM, Larry Masinter ***@***.***> wrote: #78 <#78> changes the defaults to run-medley: If you supply a -vmem file parameter else, if you set the LDEDESTSYSOUT environment variable else, if LOGINDIR is set, default is $LOGINDIR/lisp.virtualmem else $HOME/lisp.virtualmem — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOBF2XIV622C4LQ4ZDSURAY5ANCNFSM4UUGEDRA>.

[nbriggs]

On Dec 12, 2020, at 10:07 PM, rmkaplan ***@***.***> wrote: Why does it default to a name like lisp.virtualmem instead of something like medleycheckpoint.sysout? It may have been the page-swapping backing store in the old days, but now it’s just a sysout file that SAVEVM and LOGOUT happen to write out, and then its the default image if you run medley without specifying a particular sysout or makesys. It’s now kind of a misleading name. It doesn’t even exist if you haven't explicitly checkpointed.

The fact that its name includes "virtualmem" is indeed a historical artifact, because that's what the file was called on the Alto disk partitions (or lisp.vmem?) and it was the actual swap file for the virtual memory system. As you point out, it is only used as the image for SAVEVM snapshots, and to save state at LOGOUT. The naming of the file should, I think, not be like a standard sysout -- because it hasn't been sanitized, and it's NOT the right choice for giving to another user (use SYSOUT or MAKESYS and tell it the file name you want). You probably don't want the file to collide with some xxx.sysout name that someone else might use (e.g., lisp.sysout would be a bad choice). It's not a file that I would generally expect someone to name -- mostly just point at a directory for it to be put in, and it shouldn't ever be confused with the LDESOURCESYSOUT/LDESRCESYSOUT/name in the lde command line arguments.

And the checkpointing logic of that may now be a little goofy and perhaps even a little dangerous, given that you can run 2 or more medleys side by side starting from different terminal windows. Presumably the named file will checkpoint only the last one that you saved in or logged out of—and overwrite a checkpoint that you thought you had safely cached away.

Yes, the checkpoint logic is dangerous as it stands. Blake proposed that it use the current working directory at startup -- so if you keep individual projects in separate directories like ~/lisp/project1/ you could just "cd" there, start Lisp, and it would by default be back where you left off at logout. So, I guess I'd be OK with Larry's proposal below if the place of last resort was $PWD/[[whatever name we end up agreeing on]].

…

> On Dec 12, 2020, at 8:41 PM, Larry Masinter ***@***.***> wrote: > > > #78 <#78> changes the defaults to run-medley: > > If you supply a -vmem file parameter > else, if you set the LDEDESTSYSOUT environment variable > else, if LOGINDIR is set, default is $LOGINDIR/lisp.virtualmem > else $HOME/lisp.virtualmem > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOBF2XIV622C4LQ4ZDSURAY5ANCNFSM4UUGEDRA>. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWNYJIIW7APWULTOF2DSURK3ZANCNFSM4UUGEDRA>.

[rmkaplan]

That’s good if you never use it to checkpoint two different states of the same project in the same directory.

…

On Dec 12, 2020, at 10:45 PM, Nick Briggs ***@***.***> wrote: Yes, the checkpoint logic is dangerous as it stands. Blake proposed that it use the current working directory at startup -- so if you keep individual projects in separate directories like ~/lisp/project1/ you could just "cd" there, start Lisp, and it would by default be back where you left off at logout. So, I guess I'd be OK with Larry's proposal below if the place of last resort was $PWD/[[whatever name we end up agreeing on]].

[masinter]

I've been imagining a rolling buffer of timestamped lisp.vmem files (at least for running diagnostics, but might be useful for regular users). So you could SaveVM whenever idle. This would be even more important with a docker/cloud configuration where disconnecting the client would cause a logout, and reconnecting would run-medley and resume.

…

On Sat, Dec 12, 2020 at 11:36 PM rmkaplan ***@***.***> wrote: That’s good if you never use it to checkpoint two different states of the same project in the same directory. > On Dec 12, 2020, at 10:45 PM, Nick Briggs ***@***.***> wrote: > > Yes, the checkpoint logic is dangerous as it stands. Blake proposed that it use the current working directory at startup -- so if you keep individual projects in separate directories like ~/lisp/project1/ you could just "cd" there, start Lisp, and it would by default be back where you left off at logout. > > So, I guess I'd be OK with Larry's proposal below if the place of last resort was $PWD/[[whatever name we end up agreeing on]]. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIQTK3RZBJRGCS5OH46PA3SURVHLANCNFSM4UUGEDRA> .

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

[masinter]

remember that Hansen Hsu from Computer History Museum wanted a way to run Medley in the browser.
I don't think we could run Medley in a browser easily, but it is possible to run a VNC client in a browser, talking to a Medley server (launched by a VNC connect/login). Not pinning the CPU when not connected is also important.

[blakemcbride]

On Sun, Dec 13, 2020 at 12:07 AM rmkaplan ***@***.***> wrote: [...] And the checkpointing logic of that may now be a little goofy and perhaps even a little dangerous, given that you can run 2 or more medleys side by side starting from different terminal windows. Presumably the named file will checkpoint only the last one that you saved in or logged out of—and overwrite a checkpoint that you thought you had safely cached away.

Exactly my point.

…

[masinter]

i think for my purposes of SaveVM before every test case I will want to savevm to a new /tmp file/directory

[nbriggs]

See section 12.3, page 222 of the Interlisp Reference Manual volume 1.

…

On Dec 13, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote: i think for my purposes of SaveVM before every test case I will want to savevm to a new /tmp file/directory — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWPZNKI5MAUMCDCKT6LSUUY55ANCNFSM4UUGEDRA>.

[rmkaplan]

In the scanned copy the VM saving discussion begins on p 12.6. Is any of this dirty-page stuff still relevant?

…

On Dec 13, 2020, at 3:26 PM, Nick Briggs ***@***.***> wrote: See section 12.3, page 222 of the Interlisp Reference Manual volume 1. > On Dec 13, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote: > > > i think for my purposes of SaveVM before every test case I will want to savevm to a new /tmp file/directory > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWPZNKI5MAUMCDCKT6LSUUY55ANCNFSM4UUGEDRA>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJR7YDX2ASWSVIKPHDSUVETTANCNFSM4UUGEDRA>.

[nbriggs]

I think that most of it gets disabled in Medley. I do know that the allocation of new VM pages bottoms out in the emulator in storage.c (because it's where I went looking at why there appeared to be duplicate pages written to the lisp.virtualmem) But, the manual reference was that SAVEVM doesn't take a file argument. If he wants to SYSOUT to a new file that should just work.

…

-- Nick

On Dec 13, 2020, at 4:01 PM, rmkaplan ***@***.***> wrote: In the scanned copy the VM saving discussion begins on p 12.6. Is any of this dirty-page stuff still relevant? > On Dec 13, 2020, at 3:26 PM, Nick Briggs ***@***.***> wrote: > > > See section 12.3, page 222 of the Interlisp Reference Manual volume 1. > > > On Dec 13, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote: > > > > > > i think for my purposes of SaveVM before every test case I will want to savevm to a new /tmp file/directory > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWPZNKI5MAUMCDCKT6LSUUY55ANCNFSM4UUGEDRA>. > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJR7YDX2ASWSVIKPHDSUVETTANCNFSM4UUGEDRA>. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWI2GTXOBRV6VJBX56TSUVIW7ANCNFSM4UUGEDRA>.

[rmkaplan]

SAVEVM, MAKESYS, SYSOUT, LOGOUT are all defined on ADIR. We can extend them any way we want.

…

On Dec 13, 2020, at 4:23 PM, Nick Briggs ***@***.***> wrote: I think that most of it gets disabled in Medley. I do know that the allocation of new VM pages bottoms out in the emulator in storage.c (because it's where I went looking at why there appeared to be duplicate pages written to the lisp.virtualmem) But, the manual reference was that SAVEVM doesn't take a file argument. If he wants to SYSOUT to a new file that should just work. -- Nick > On Dec 13, 2020, at 4:01 PM, rmkaplan ***@***.***> wrote: > > > In the scanned copy the VM saving discussion begins on p 12.6. Is any of this dirty-page stuff still relevant? > > > On Dec 13, 2020, at 3:26 PM, Nick Briggs ***@***.***> wrote: > > > > > > See section 12.3, page 222 of the Interlisp Reference Manual volume 1. > > > > > On Dec 13, 2020, at 1:47 PM, Larry Masinter ***@***.***> wrote: > > > > > > > > > i think for my purposes of SaveVM before every test case I will want to savevm to a new /tmp file/directory > > > > > > — > > > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWPZNKI5MAUMCDCKT6LSUUY55ANCNFSM4UUGEDRA>. > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJR7YDX2ASWSVIKPHDSUVETTANCNFSM4UUGEDRA>. > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWI2GTXOBRV6VJBX56TSUVIW7ANCNFSM4UUGEDRA>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJI7L4S2MBTZ777UF6TSUVLG7ANCNFSM4UUGEDRA>.