Interlisp
The different assets in the release are confusing
There are 4 assets listed
loadups runtime sourcecode (zip) sourceode (tar)
The loadups seems just to have the syouts and whereis database. The runtime seems to have all of the directories, but not the loadups.
And when you download and untar them on the Mac, they both create Medley directories (Medley and Medley 2), depending on the order.
There isn't a single asset that gives more or less an Interlisp developer environment (loadups plus sources) in a single download into a single folder, mirroring the git clone environments that we have. It takes some fiddling to move e.g. the loadups subdirectory from the one into the other and merge the library.
I suggest one asset that is set up for Interlisp users (essentially what is now there as the runtime). But the other asset should be complete for Interlisp developers. It should contain the loadup subdirectory in addition to everything else, and exports.all should be in its proper place in the mix of other library files. This could also contain the fuller.database that goes along with the release.
The two links to "source code" are added automatically by GitHub and I've read it's difficult to remove. But it looks like it might be possible to leave out. The layout and details of how loadups are made aren't sacrosanct, but we should make sure the documentation and actions workflows are modified too.
What I've been thinking about is just hiding the complexity of installing/updating into a button that will negotiate some of the difficulties, for mac, windows 11 pro, and ubuntu based linux. Not quite as simple to negotiate as running online.
One hiccup is we don't yet have an automated build of maiko for Apple Silicon-based computers.
This is the problem that the release-loadups has a library directory (in addition to loadups/) that contains only the whereis database.
But the full release, with all of the source files, has a library that doesn't include the whereis.
This doesn't make sense. The whereis database is useless if you don't have the source files, and the source files are pretty much useless if you don't have the whereis.
So I repeat the initial request: include the whereis database in the release tar file that includes the sources, don't bother to include the goofy library/ directory in the loadups release tar.
But it looks like in the -loadups tar file, whereis.hash is in the loadups directory and exports.all (and not whereis.hash) is the sole file in the library directory.
This is how it is setup in the loadup-all.sh script - whereis.hash is left in loadups and exports.all is in library.
So in the -runtime release tar, you want 'whereis.hash' and exports.all to be library. Plus neither of them belong in the -loadups tar. Correct?
My confusion, sorry. It’s the exports.all. But the same issue: they both are useless if they don’t accompany the source files, and the source files aren’t particularly useful without them.
So they should both be in the tar file with the sources. Whether or not they are also in the loadups tar is of no consequence.
On Jul 12, 2023, at 1:39 PM, Frank Halasz @.***> wrote:
But it looks like in the -loadups tar file, whereis.hash is in the loadups directory and exports.all (and not whereis.hash) is the sole file in the library directory.
This is how it is setup in the loadup-all.sh script - whereis.hash is left in loadups and exports.all is in library.
So in the -runtime release tar, you want 'whereis.hash' and exports.all to be library. Plus neither of them belong in the -loadups tar. Correct?
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/879#issuecomment-1633185083, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJLKZSTV42AOKFTPSULXP4DOVANCNFSM55UALPVA. You are receiving this because you authored the thread.
Ok. One final question: whereis.hash is currently put into the loadups directory. I presume it makes more sense for it to be in the library directory. Correct?
The situation is over-constrained. on non-unix platforms it will complain if you load the same file from two different tar files or overwrite files you cloned.
More thoughts…
We should work out more carefully who these 2 release tar-files are aimed at and how the assets should be configured for those uses. This may be different from where the build scripts have put things in the clones.
I have thought that the release is supposed to be a convenient one-step way of getting a fully function snapshot of the master at a weekly point in time. And that it is supposed to be set up so that just untarring it gives a full running system—loadups and databases in the right place so that there is no need to move files around or run build scripts. On that view, sources/library/lispusers/loadups and exports.all and whereis.hash should already be included in a single tar file, with everything in their proper place for a simple .run-medly.
But that’s not the way it is currently set up—the sources are in one tar, the loadups and exports in another, and some screwing around is needed to bring stuff together in the usual workable arrangement.
The user can run the build scripts in the stand-alone source-untarred directory, to get things in the proper place—loadups and exports.all will be created, and there is no need for untarring the separate loadups. Is that the expectation?
I’m not sure what purpose is served by the stand-alone loadup-untarred directory, with just the exports.all, unless the files are merged in to the other one. The sysouts can be started up, but there is no library or lispusers. And it isn’t clear that the exports.all has any value at all in that context, if the sources have to be found somewhere else. You can load exports.all, but then what?
Note also that the 2 tar files untar into directories that want to have the same name “Medley”—on the mac, that gives you “Medley” and “Medley 2”.
On Jul 12, 2023, at 3:34 PM, Larry Masinter @.***> wrote:
The situation is over-constrained. on non-unix platforms it will complain if you load the same file from two different tar files or overwrite files you cloned.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/879#issuecomment-1633293626, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJ26SB2BGKEHQLGST3XP4RAVANCNFSM55UALPVA. You are receiving this because you authored the thread.
Here is the current situation with the releases:
For each platform (Linux, MacOS, Windows Cygwin and Windows WSL) there will be 2 release "vehicles": one is an installer of some sort (e.g., a .deb file on Linux ) that installs Medley/Maiko and friends into a canonical location - e.g., /usr/local/interlisp/ on Linux and an app bundle stored into Applications on a Macos. The second is a tar (actually .tgz) file containing Medley, Maiko, Notecards, etc. that the user can untar into any directory of their choosing.
The first (installer) vehicle is meant for people who want to use Medley but not to work on Medley source code. This is because most of the canonical install locations are protected and available only to root users or, in the case of MacOs buried in an app bundle.
The second (.tgz) vehicle is meant for those want to work on Medley source in a directory of their choosing.
Looking at the .tgz releases, the directory structure is set up as follows (assuming that you decide to untar into a directory called ~/interlisp): there are three (and maybe eventually four) directories. The current three are medley, maiko and notecards. Medley and Notecards contain (a selection) of the source trees for Medley and Notecards exactly as they are structured in git. The maiko directory just contains the executables for the given platform and the scripts that support them.
run-medley and the medley.sh scripts are built to assume this directory structure (medley as a peer to maiko).
This structure also (I think) lets you work with several different versions of the medley source - e.g., the release medley might be considered the working medley and then you can git clone a different tag or branch into gmedley. Running run-medley (or medley.sh) from both medley and gmedley will start up with the sysouts and code from their respective directories.
In the release assets these tgz files are named medley-full-<release tag>-<platform>-<arch>.tgz - for example for linux on x86 the asset would be called medley-full-230708-52499052_230607-d1f4653b-linux-x86_64.tgz.
The release tag is the Medley Medley release tag followed by the Maiko release tag included in this tar. (Now that I write this out, it would make more sense to name these files medley-full-<platform>-<arch>-<release tag>.tgz - a small cosmetic improvement.)
As it currently stands there are medley-full*.tgz files for Linux and WSL. I also have the workflow ready to create the Windows-Cygwin *,tgz.
We currently are not making medley-full-<version>-macos-<arch>.tgz assets - this is mainly because I haven't finished the macos installer and so just haven't put together the github actions workflow to create the macos assets. I guess it would make sense to go ahead and create the macos tgz workflow without waiting for the macos installer workflow to get finished.
Finally, the two release assets labelled medley-<release_tag>-runtime.tgz and medley-<release_tag>-loadups.tgz are Medley only - no Maiko and no Notecards - just (selected) Medley source (and compiled) code and sysouts, respectively (especially after the move of exports.all and whereis.hash from -loadups into -runtime).
What about having just one asset with everything, and just let the installer decide?
This would be in addition to the sources asset (which you can minimize or just use?) and make the installer table-driven.