This is a report of the Graphics Meeting held on 23 May. Various points were raised and the conclusions (if any) are set down here.
The sequence list concept as set out in the manual has now been implemented. A few problems have been met which are not covered by Paper 21 and Note 8.
As has been mentioned before, it should be possible to specify the state required on-return to a sequence item after ADVFLM. As it is likely that all ADVFLM in a given item should be treated the same way, a marker has been reserved in the sequence item header. It is suggested that this marker be set by an extra argument in ADSQLG, ADSQLL. Suggested values are:
0 No restoration 1 Restore complete state
The default setting applicable to DRAW is 0.
When there is more than one item in the sequence list, DRAW should add the specified file in the same way as ADSQLL: ie, the item should start with the conditions applicable at the time of starting the item rather than those applicable when the DRAW command was given (the global conditions). If a user wishes to start this item with the global conditions, he can use the routine STSQLS (mentioned earlier in connection with local variables) which will merely start the current list without making any additions. It will not be a display routine.
The following additions to the tracing procedure have been made. A new mode (4) includes file stack details every time a block from the file stack is used, and mode 3 (spot check) will give a list of the current stack chains for each item in the list, including an indication of suspension.
While testing the sequence list, a problem arose concerning the modes of file packing. At the moment, no check is made on argument size, so that integer, compact and compressed modes perform their packing function without regard to the values. It is thus possible to truncate file names, for example. In spite of the fact that this may cause a consider able overhead, it was decided that arguments should be checked as well.
Although this item was not discussed at the meeting, a couple of SPROGS users have had difficulty with using fonts-in non-standard region settings. Fonts are defined so that they fit into an absolute grid, chosen to make the characters appear correctly spaced in the basic output region for the SD4020 (with the exception of font ). If the current region has limits other than this, it is necessary to use TEXPAN to get the characters into relative scale. It is suggested that TEXPAN could be called automatically by REGION, RGLIM and LIMIT so that the user would not have to work out the conversion factor. However, this has two drawbacks: any variation in standard relative size would have to be provided by the user, and recalled each time a region changed, and not all fonts are scaled for the same basic region. This last problem could be overcome by keeping in COMMON a record of each font size, but this could be difficult, especially where more than one device is being called.
Progress on the PDP15 is such that we should now think seriously about the form of data mode, since it would appear sensible to let the PDP15 programs communicate with the 1906A in at least a subset of this mode. However, there are many problems associated with it which have yet to be resolved, some of which are listed below.
The standard form so far suggested has been
TODXY,3.0,4.0
(for example). A simple extension allows integer values in place of reals. However, we need some way of specifying variable names, file names, arrays etc. Since file names can contain any characters, including commas, it is necessary to start each special argument with a different form. Also some way of dealing with the triple arguments of arrays should be found.
One possible solution could be to contain each special argument in quotes. Variable references could start with PR, file references could start with AN. It would then be necessary to forbid quotes within file names unless both types of quotes may be used as brackets, in which case only file names which contain both types will be forbidden. Array references could be overcome by using the routine EQUIV to specify one name for the three variables. Then only the one name need be used as an argument.
Thus:
TODXY,3,4
would be acceptable, as would:
TODXY,'PRFRED', 4 (accessing variable FRED) STDF,'ANFRED' (defining file FRED) LOAD,'ANFRED',4 (setting 4 into variable FRED) LOAD,'PRFRED',4 (setting 4 into the variable referenced by FRED) EQUIV,'ANFRED','ANX','ANY','ANZ' (setting FRED to the array (X, Y ,z)) TODXY,'PRFRED',4 (using the array defined by FRED)
This would be greatly simplified if commas and quotes were forbidden from names, since it would then be possible to distinguish PR and ANAME references by placing quotes round one and not round the other, thus:
TODXY,'FRED',4
EQUIV,FRED,X,Y,Z
However, this takes no account of ease of use of such a form from a PDP15 program. WDS and JRG will investigate further.