[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 28 21:42:26 2000 
Subject:Environment variables and running saved images 
From:Aaron Sloman NB See text for reply address 
Volume-ID:1000328.06 

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

One of the points made earlier is that not all Poplog's environment
variables are for search lists. Some are there as part of a solution
to the problem of starting up in different modes.

This message explains what happens, and at the end reports on an
experiment to replace environment variables set for each user with an
initialisation file.

Then just one environment variable suffices: but when used in that mode
pop11/ved/xved etc. can't be given any arguments when started up, unless
the system is changed. And maybe it is simpler to use a shell script
that sets the environment variables then

THE CURRENT MECHANISM FOR CHOOSING SYSTEM

When poplog is run, the default at present is that you always have to
run the basepop11 executable, and then on top of that you run one or
more saved images, depending whether you want pop11, prolog, lisp, pml,
xved, etc.

By default the saved images go in $popsavelib, i.e.
    $usepop/pop/lib/psv/

though they can also go in $poplocalbin, which at Birmingham is
defined to be this directory
    $usepop/poplocalbin

For pop-11 the saved image to be run is called startup.psv. I.e.

    basepop11 +$popsavelib/startup.psv

is (normally) invoked simply as pop11.


The other systems available as saved images are usually
    Common Lisp, invoked as clisp, i.e.
        basepop11 +$popsavelib/startup.psv +$popsavelib/clisp.psv

    Prolog invoked as prolog,
        basepop11 +$popsavelib/startup.psv +$popsavelib/prolog.psv

    Standard ML invoked as pml
        basepop11 +$popsavelib/startup.psv +$popsavelib/pml.psv

    XVed, invoked as xved
        basepop11 +$popsavelib/startup.psv +$popsavelib/xved.psv

These saved images are all created (or re-created) by running
files in the $popcom directory
    $popcom/mkstartup
    $popcom/mkclisp
    $popcom/mkplog
    $popcom/mkpml
    $popcom/mkxved
and more.

Nobody would wish to start up an editor by having to type:

        basepop11 +$popsavelib/startup.psv +$popsavelib/xved.psv

One of the uses of environment variables in Poplog is to make it easy
to run a particular system, with basepop11 and one or more saved images
on top of it, in a single command.

This had nothing to do with the requirements of the development team,
but was (rightly or wrongly) thought to be convenient for users.

One possible solution would have been to provide a set of aliases, e.g.
    pop11 =  basepop11 +startup.psv
    prolog = pop11 +prolog.psv
    clisp =  pop11 +clisp.psv
    etc.

However, in the earliest unix shell, 'sh' one could not define aliases
or functions.

John Gibson hit on the following solution, which works no matter which
shell you use.

Allow the basic executable to be run under various names (ie. files with
different names linked to basepop11, e.g. pop11, prolog, clisp, xved,
etc.).

Then when the process starts up it looks to see how it was invoked. If
the process was invoked using the file called XXX, it then looks
to see if there is an environment variable pop_XXX, and if that
exists it acts as if the program had been invoked as
    basepop11 $pop_XXX

So if you have a saved image called XXX.psv and you want to run it using
a command XXX, then

1.  Use ln -s to make XXX a symbolic link in a directory in your
    $PATH to $popsys/basepop11
2.  define pop_XXX as an environment variable equivalent
to
        +startup.psv +XXX.psv

3. type: rehash

Then if you give the command XXX, that will be equivalent
to giving the command

    basepop11 +startup.psv +XXX.psv

Moreover, you can add extra arguments.

This solution works for ALL The unix shells, since they all allow
Unix environment variables to be defined (though with different syntax).

There is another type of environment variable provided for easy startup.

If you wish to start up pop11 and immediately have Ved start editing a
file myfile.p, you can type:

    pop11 ":sysinitcomp();ved myfile.p"

So, to avoid having to type all that you can define the file "ved"
as a symbolic link to $popsys/basepop11, and then define the environment
variable pop_ved as equivalent to

     "$pop_pop11 :sysinitcomp();ved"

Then typing "ved myfile.p" will start up pop11, make it go immediately
into ved with myfile.p as argument. (If your vedinit.p file has
    "x" -> vedusewindows;
then it will always start up in Xved.)

All this explains some of the environment variables defined in these
files

    $popsys/popenv
and
    $popsys/popenv.sh

All that is not a *defence* of the current system, but a *description*.
It is explained more concisely in REF SYSTEM.

Following earlier discussions it is now clear that instead of using
environment variables basepop11 could be made to read an initialisation
file, that specifies mappings from the name by which it was invoked
(poparg0) onto a collection of layered saved images to be restored
or other special startup actions.

So when I previously suggested that this particular use of
environment variables could not be replaced by a file that is read when
basepop11 starts up, I was wrong. It could be done. Doing it properly
would require some re-design of the core of poplog.

I have been experimenting with a scheme that gets rid of all environment
variables except one, $popsys.

This uses the fact that when basepop11 starts up, IF THERE ARE NO
COMMAND LINE ARGUMENTS it does this:

    trycompile( '$popsys/init.p' ) ->;

    unless trycompile( '$poplib/init.p' ) then
        trycompile( 'init.p' ) ->;
    endunless;

This means we could put something in $popsys/init.p to set environment
variables (as previously suggested by Andrew Sayer) and ALSO to use
poparg0 to decide which saved image to run. At first I tried using
sysrestore, but that didn't work. It produces

    ;;; MISHAP - sys_timer: NO SPACE LEFT FOR TIMERS
    ;;; DOING    :

I have no idea why.

But then I realised that sysexecute could be used, to replace the
current process with a new one, with a slight efficiency loss.

So I now have an experimental pair of files
    $popsys/init.p
    $popsys/popenv.p

The first one (init.p) simply contains this:

=======================================================================
#_IF systranslate('ARGSDONE')

false -> systranslate('ARGSDONE');

#_ELSE

trycompile('$popsys/popenv.p') ->;

#_ENDIF
=======================================================================

The second file popenv.p (based mainly on $popcom/popenv and
$popsys/popenv) works out what $usepop $popexternlib and all the other
required environment variables should be (on the basis of $popsys) and
also if necessary sets up $LD_LIBRARY_PATH (required on Suns) or
$SHLIB_PATH (required on HP-UX). It sets up all those environment
variables, and adds ARGSDONE=1 as an additional environment variable.

It then uses a list mapping invocation names, e.g. 'pop11', 'prolog',
'xved', etc. to a collection of arguments to give to basepop11.

Then it uses sysexecute to run basepop11 with %nobanner and the
extra arguments and with all the environment variables set up.

When that happens the init.p file is compiled again, but this time
$ARGSDONE is set, so it simply unsets it and continues.

On a 140 Mhz ultrasparc 1, this mechanism takes no more than about
0.2 seconds longer to start up than the normal mechanism using
environment variables. On a Dell 400 mhz celeron Laptop running RedHat
linux, the difference in startup time is much smaller. It is certainly
not noticeable in either case.

Both the init.p and the popenv.p file can be looked at in here:

    http://www.cs.bham.ac.uk/research/poplog/sysinit/

They are both in this tarball
    http://www.cs.bham.ac.uk/research/poplog/sysinit.tar.gz


There is one serious problem. This mechanism is incompatible with giving
pop11, or ved, or xved, etc. any arguments when it starts up. That's
because if basepop11 is run with arguments it will not try to compile
$popsys/init.p

Hence all my code is by-passed. I have not found any way to pass
arguments in: when there are arguments the init.p file is not read.

So if you are prepared to run poplog/pop11/xved with no arguments
you can use ONE environment variable, $popsys, and put the init.p and
popenv.p into the directory of that name.

However, it seems to be more flexible to revert to an earlier suggestion
and run poplog via shell script which does

    setenv usepop ...
    source $usepop/pop/com/poplog

    exec $*

The use of "exec" means that the shell process does not hang around: the
poplog process takes its place, and inherits all of the environment
variables.

In my tests this is pretty quick. I think it works equally well no
matter which shell you are using to start with. And it allows arguments
to be passed to pop11, xved, etc.

Moreover, it too can be invoked from a script by using exec. E.g.
=======================================================================
#!/bin/sh

exec poplog pop11 << \\\\

'Hello world' =>

\\
=======================================================================