On Mon, Aug 24, 2020 at 02:27:18AM +0100, Aaron Sloman wrote:
> 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.
>
<snip details>
> If the package directory is not present those extensions do not occur,
> and attempts to access them will simply fail, while everything else works.
>
<snip details>
>
> 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.
>
<snip details>
>
> 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.
Well, I was writing specificaly about startup image. V15.65 in
'pop/com/mkstartup' among others contains:
$packages/teaching/teaching.p \
$packages/bhamlib/bhamlib.p \
$packages/vedutils/vedutils.p \
$packages/rclib/rclib.p \
$usepop/pop/lib/lib/prwarning.p \
$usepop/pop/lib/lib/emacsreadline.p \
$packages/vedutils/lib/vedscreendown.p \
$packages/bhamlib/auto/vedsetwindow.p \
$packages/rclib/auto/rc_control_panel.p \
$packages/rcmenu/rcmenu.p \
$packages/vedmail/vedmail.p \
If any of the files above is missing, then 'mkstartup' will
fail. For V16 'mkstartup' was just as in Sussex version: it
only loaded 'pop/lib/lib/startup.p' (and 'startup.p' was as
before). For V16.0001 I moved some position from Birmingham
'mkstartup' to 'startup.p'. However, trying to add files
from list above would lead to build failure if package tree
is not present. To put it differently, in V16.0001 agrees
with your text above. V15.65 loaded files from packages
tree to startup image with two consequences:
- build would fails if package was not present. I discovered
problem during porting, when my code which worked in
earlier versions (IIRC V15.53) failed when I tried to use
'mkstartup' from V15.65
- some 'uses ....' are not needed
The second point affects user programs. In some cases
when Poplog reports undefined operation, user can
infer need for appropriate 'uses'. Some other cases
are more nasty: without uses operations are available,
but work differently.
General isssue is how to avoid fragmentation. With flexible
and customizable system like Poplog users can easily create
incompatible versions. Incompatiblities may inhibit sharing
of code... One solution is to have standard base version that
is accepted by comunity and in code have explicit 'uses' for
local extentions (or appropriate loader type code which creates
environment expected by rest of the code). AFAICS in last
20 years Birmingham version de facto served as such standard
version. But as I wrote, there is technical problem
with V15.65 (build without package tree), and trying
to fix this problem introduces incompatibility
Let me reiterate that I am here concerned only with
'startup' image. Other images stacked on 'startup' are
different story.
> > 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.
All what changed is that there are less links. More precisly
newpop no longer creates links to doc, help, im, ref and teach.
OTOH 'teach teach' in pop11 or ved works as before.
I changed 'pop/src/newpop_options', changing it back to old
version would give back the links.
--
Waldek Hebisch
