From damian@uk.ac.rl.inf Thu Nov  2 11:40:13 1989
Received: from rl.inf by abacu.strath.ac.uk; Thu, 2 Nov 89 11:40:06 GMT
Received: from pyr-a by inf.rl.ac.uk; Thu, 2 Nov 89 11:31:00 GMT
Date: Thu, 2 Nov 89 11:29:55 GMT
From: damian@uk.ac.rl.inf
Message-Id: <8911021129.AA06824@pyr-a>
To: joe@uk.ac.strath.abacu
Subject: IFE bm
Cc: james@uk.ac.strath.abacu
Status: R

I looked over you program bm.c.  A few comments:

1) You could have used recursion to handle nested "for" loops - ie just
   call for_loop() again from within the for_loop() procedure.  As long
   as you dont hold data in global variables, the for_loop() procedure
   simplifies to a series of get_line, proc_line (for_loop | process_if
   calls

2) You need to store the value of variables extracted from the BB - eg
   no_of_zones.  This means building a lookup table to store the name/
   value pair and providing a retrieve mechanism.  I suspect thast you
   intended to create a shell variable to hold this and have the shell
   automatically retrieve the value.  However, for such things as loop
   controllers, the bm.c program needs the values internally.  Other
   variables would work as shell variables

3) there is a 1k limit on the total space environment variables have
   available.  Any reasonable script would overflow this.

4) you cannot make environment variables of the sort $xyz_$j.  The
   shell only does one pass substituting variables.  You thus have
   either 2 variables $xyz_ and $j or one value eg $xyz_6.  Tough!

What I did was to take your imp.geo script and use awk (quicked than
trying to modify your program) to convert it to an expanded version
of imp.geo which itself can interogate the database and create the
necessary files.  imp.geo thus is a program to create the data files -
in this case the ESPIMP input file rather than the data file itself.
imp.geo is written in a extended shell language - the extensions being
a) a "for i from 4 to $nz" as well as "for i in 1 2 3 4" constructs
b) lines starting with % are BB queries - notes
	space after %
	spaces round =
	one string (shell variable name) between % and =
	rest of line is query of u_cpt area on BB
		Perhaps we should change the = to <= to disringuish it
		from the normal shell = (which doesnt need spaces)
c) lines totally enclosed in quotes are literal data lines - note
	anything other than whitespace outside the "" isn't touched
		Perhaps we could replace this with an echo command
		to make the script look more shell like?
d) the file being created can be changed by a line starting "file "
	one script can create eg geom1 for zone 1, geom2 for zone2, etc
Below is your imp.geo script modified as above.  Note I have given a
number of variables default values eg ${nz:=0) so if the BB returns
null (ie the data wasn't defined), a subsequent for look wont core dump
but just gets skipped (done 0 times).  This is not the ife's problem,
we will assume that the script is correct in all cases - thus the
script programmer must ensure that the variables requested do actually
exist in the reurired form in the u_cpt area (eg your rec_dimensions
doesnt - pick up length, width and height separately; total no wins for
a zone isnt held - calc from adding individual surface numbers) and the
kb which starts the bm running must ensure that all the necessary data
is already on the u_cpt area.  The bm is started by a "new_client"
command to the BB, and it then runs to completion and exits

Later, we can change the query to a posting on a bm area which is
picked up by a kb and the query replied to.  This would allow us to:
a) map language eg no_of_zones -> no_zns
b) map semantics eg no_of_zones -> next_free_zone - 1
c) default data which wasn't available (rather than in the script as
   mentioned above)
d) explicitly ask the user for missing data.
e) avoid the user having to say "finished" or anything like that - when
   the data is available, the bm script would be automatically run.
This requires a bit of thought, some prolog programming and a 1 line
change to the bm's awk script.
We could also replace awk by something faster if necessary (modify your
bm.c?)

I have 90% tested the above.  Problems:
a) if script core dumps, so does BB
b) running bm client twice core dumps IFE
Before continuing to debug the BB, any comments on the above?

Damian

PS  I'll next look at the field dup prolog for the geom (vertex input).

PPS In the imp.geo script I have calculated total_no_wins per zone.
    This should be done in prolog in the bm handler kb - but could be
    done in the geom input kb pro tem.  Could you identify any other
    such cases and give me a list - I really really really really dont
    want the user to be asked for things that can be worked out in the
    IFE

        Damian Mac Randal                Snail Mail: Informatics Dept,
                                                     Rutherford Appleton Lab,
INTERNET: damian%inf.rl.ac.uk@nfsnet-relay.ac.uk     Chilton,    Didcot,
  BITNET: damian%inf.rl.ac.uk@ukacrl.bitnet          Oxon.  OX11 0QX,    U.K.
    UUCP: damian%inf.rl.ac.uk@ukc.uucp        Phone: +44 235 445403
   JANET: damian@uk.ac.rl.inf                   Fax: 445831  Telex: 83159

