Waldek wrote: on Thu, 20 Aug 2020
> ...
> I am reluctant to add things from packages to 'startup.p':
> if added it would be no longer possible to build without
> packages.
My answer is very long. Perhaps I've missed the point.
My answer is that it can all be done by indirection so that everything
works if the packages directory is absent, as long as nothing searches in
that directory for one of the packages.
If the packages directory is present a search will be successful because
the packages directory includes a mechanism for extending the standard
search lists, via
$usepop/pop/packages/lib
as I'll try to explain for anyone who doesn't find the solution obvious:
Everything starts from these two scripts (originally from Sussex):
(which may need minor updates):
for bash/sh users source:
$usepop/pop/com/poplog.sh
for csh/tcsh users source:
$usepop/pop/com/poplog.csh
among other things those files source, respectively
$usepop/pop/com/popenv.sh
$usepop/pop/com/popenv
which set up a battery of environment variables that are inherited later by
scripts used in various places.
(Some may no longer be needed becauase their functions have been taken over by
Waldek's install
mechanisms, but I currently lack the time --and courage?-- to try to
work out exactly what can be removed!).
However both scripts set up environment variables used later for building
search lists etc. And they include contents of the packages directory,
only indirectly: the packages directory if present, contains a directory
of files, each of which extends search lists for a particular package.
If the package directory is not present those extensions do not occur,
and attempts to access them will simply fail, while everything else works.
In more detail: within the packages directory there is a directory to which
information about new packages can be added (this was a rapidly designed
system for use at Birmingham which worked there, but there may be far
better solutions).
For each new package a suitable .p information file can be added here:
$usepop/pop/packages/lib/
These are the current inhabitants:
packages/lib/AREADME
packages/lib/bhamlib.p
packages/lib/brait.p
packages/lib/lockfile.p
packages/lib/master.p
packages/lib/neural.p
packages/lib/newkit.p
packages/lib/popmatlab.p
packages/lib/poprulebase.p
packages/lib/popvision.p
packages/lib/prblib.p
packages/lib/rclib.p
packages/lib/rcmenu.p
packages/lib/simlib.p
packages/lib/teaching.p
packages/lib/vedgn.p
packages/lib/vedlatex.p
packages/lib/vedmail.p
packages/lib/vedutils.p
So it is not necessary for any of Waldek's scripts to know what's in the
packages library apart from the directory:
$usepop/pop/packages/lib/
When a user starts up poplog, depending what is in the user's
$poplib directory, the appropriate init file there will be
used to determine whether something has to be added from the packages
directory.
For example, my $poplib directory includes an init.p file that includes,
among other things
uses teaching
uses vedmail
Those will trigger searches when pop11 (or ved) is run and if the two files
teaching.p
vedmail.p
are not found in any of the standard Poplog (pop11) library directories
then the information found in these two files in the packages directory
$usepop/pop/packages/lib/teaching.p
$usepop/pop/packages/lib/vedmail.p
will be used to extend appropriate search lists (e.g. for program and
documental libraries).
Various comands in pop11 that use search lists, e.g.
help
teach
ref
lib
auto
will look in the packages directory if it is present, but not if it is
absent.
So I get a mishap when starting pop11 if the packages directory is missing.
But the mishap doesn't occur if I temporarily rename my $poplib directory.
Of course, all of this works only if the entries in
$usepop/pop/packages/lib/*.p
conform to a standard format, which is the same as the format used in the
core lib auto teach help ref doc etc. directories directly or indirectly
referenced from here:
$usepop/pop/lib
$usepop/pop/auto
etc.
The instructions in the file INSTRUCTIONS.txt downloaded by the getpoplog.sh
now include this as a first draft, after instructions to set $usepop:
To set up paths and environment variables do one of these:
sh/bash users:
source $usepop/pop/com/poplog.sh
csh/tcsh users:
source $usepop/pop/com/poplog.csh
After that, a variety of commands will be available to you, including
pop11, prolog, clisp or pml
Waldek raised another point:
> Also, currently images work with '-nonwritable',
> but IIRC trying to add some packages leads to errors
> (which can be avoided by making image writable).
I have not looked at any of those mechanisms and will leave it to others to
comment.
Certainly some of the variables provided in saved images can have values
changed by users, e.g. vedhelplist, etc., so in some sense they must be
writeable. Perhaps that is specified at the level of individual identifiers
in the poplog sources?
The poplog dictionary, created when it starts up includes some constants
that are not writeable and some variables that are.
> IMO better alternative is to handle extra things
> by explicit uses (or maybe package autoload).
I think that is what I have described above as already done.
> Another issue are extra commans: doc, help, im, ref, teach
> During porting I had to rebuid multiple times and
> not having those commands made my work a bit simpler.
> So I changed build to avoid making them (and this
> wnet to git repo). But if they are expected by users
> I can add them back.
As long as they are available once poplog/pop11 starts up (with similar
comments for the other languages) that should suffice.
At present this is handled in the directory
$usepop/pop/pop
which includes, besides basepop11 (hard) links to it with different names,
e.g.
pop11, clisp, pml, prolog, ved, xved
which are all hard links to basepop11.
When basepop11 starts up it checks to find out by which name it was
invoked, and performs appropriate actions. E.g. if invoked as pop11, it
runs basepop11 extended by the saved image:
$usepop/pop/lib/psv/startup.psv
prolog runs basepop11 extended by startup.psv and then by prolog.psv
similarly for clisp and pml. xved uses the same mechanism and sets up
the environment for running pop11 + ved + Xwindow extensions (multiple
windows).
The script
$usepop/pop/com/mkeliza-speak
creates a saved image
$usepop/pop/lib/psv/eliza.psv
which can be run as
pop11 +eliza
which starts a loop repeating:
read - process - reply
and the reply section uses eliza's rules to work out a text reply, then
invokes espeak to 'say' the reply.
$usepop/pop/com/mkgblocks
creates a saved image
$usepop/pop/lib/psv/gblocks.psv
So typing
pop11 +gblocks
does the same as running pop11 and the loading the rc_blocks library and
then starting the program. (You get the option to use a standard ved
or xved window to type commands or questions to the 'robot'.)
If the packages directory is not present the command 'mkgblocks' will fail.
So the basic pop11 system does not need to know anything about the commands
that it wll later understand when asked to run a saved image.
Using this mechanism a local installation could have a large number of
saved images invoked by new commands. If they locally use login scripts to
define appropriate aliases they can then invoke the saved images using the
aliases, instead of
pop11 +ved +xxx +yyy
for a multi-layer saved image.
I apologise if I've misunderstood the problem you are referring to.
Aaron
