ACD Atlas Computing Division PERQ Papers

Jump To Main Content

Jump Over Banner


ACDSingle User SystemsPERQ PapersInternal

Jump Over Left Menu

PNX User Forum, 24 June 1986

Trudy Watson

16 July 1986

Common Base Programme: PERQ User Note 8


The fourth PNX User Forum took place at Rutherford Appleton Laboratory. A mixture of progress reports, users experiences and looking to the future were combined with informal demonstrations. A question and answer session rounded off the day. The users could then take away their copies of PNX5 and PNX SR. About forty Perq users attended the meeting. These were mainly SERC grant holders and users supported by the Computer Board.

Chairman's Introduction and Welcome.

Professor R Morrison, Dept of Computer Science, University of St Andrews.

Prof. Morrison took the chair on behalf of Prof. Atkinson, who is Chairman of the Single User System Interim Panel which recently took over from SUSSG. He welcomed fellow users of the Perq. The aim of the day was to give people plenty of opportunity to talk about problems and share experiences.

Progress Report and Forward Look.

Julian Gallop, Common Base Programme Manager, RAL.

Julian began by advertising the European Perq User Group meeting on 28th-29th July, 1986. He went on to describe the present and future of the Common Base Programme (CBP) and of Perqs in particular.

There had been several changes to the staff and support arrangements since Christmas. Some people were new to Single User Systems (SUS). Ken Robinson is now in charge of the Man Machine Interaction (MMI) section of Informatics Division. CBP is in the Distributed Interactive Computing Group led by Ken Hartley. The group is split into Interactive Computing Facility (ICF) Support led by Mike Jane (grant assessments are dealt with here by Peter Hemmings), Systems and Communications led by Eric Thomas and SUS/ Applications led by Julian Gallop. Julian is in charge of CBP support and development, and graphics and text processing on Multi User Minis also. Members of the CB team are:

Since January 1986 the CB Support arrangements have been to ring RAL Service Line (x6389) during working hours with problems. This has given users a chance to report problems earlier in the day and shortened the time taken to report any hardware faults to ICL. Any software problems are passed on the Common Base Support Desk which is open for 3 hours each working day. Better support for both machines in the Common Base, Perq and Sun, has been achieved this way.

Connections to Wide Area Networks (WANS) have been a problem for a long time. Three solutions are possible:

  1. direct to a LAN which connects to JANET is the most favoured solution.
  2. RS232 connection to an ICF or Unix machine which is on JANET.
  3. A WAN connection on the SUS itself. This is the least favoured as it is expensive and uses up resources on the machine.

So what is happening in LANs? CBP now supports Ethernet based LANs. The Cambridge Ring is no longer supported. There are many ways to provide communications over Ethernet. The problem is to choose the right one. There are some hurdles to overcome: coexistence of different manufacturers machines on the same Ethernet is one. If anyone has this problem we would like to hear about it The ISO protocols will be used so that the coloured book services can be provided on top of them. It has the advantage of being a standard and having the backing of a large company (TP4/LLCl is used by the MAPP project funded by General Motors). On top of this there will be a distributed file system. The options are NFS (already on Suns and others), Newcastle Connection over UDP or LLC1 (a problem of two low level protocols that should communicate, but do not do so) and possibly RFS (it is still on the horizon). There is the question whether to have remote paging?

At present we have NFS on the Sun and Newcastle Connection over LLC1 on the Perq. In the next six months (to be taken with a pinch of salt) the plan is to implement the Coloured Books with ISO class 4 over LLC1 on Perq, Sun and Vax 4.2BSD. Also to have NFS on the Vax as well as the Sun and to put Newcastle Connection on several machines over UDP and LLC1.

Software for Common Base Machines is classified in four groups:

  1. Common Base (and software using Common Base). Software that is portable across all the machines ie. GKS, F77, Pascal, 'NAG Mk 11', 'NAGGRAF Mk 2' (the first one to use GKS) and some of the Kent Tools.
  2. Discipline specific software. For example LISP for the IKBS community, Modula-2 for the Software Engineers and software for other engineering disciplines. This software may become generally available later.
  3. Experimental software. This may become generally available later. For example C++ and some of the Kent Tools.
  4. Non-Common Base Software which is available but has no commitment for provision on other systems. For example, ICL's TECDOC.

At present there are 130 Perq 1 (of which 100 are now maintained), 70 Perq 2, 60 Sun2 (funded mainly by Alvey) and 80 Sun3 (funded by Alvey and SERC). Only Sun3s are being purchased at the moment. All these machines will be supported for their grant lifetime. The Perq1s will not be maintained by us when their grants expire but they will get copies of PNX SR.

Looking to the future for CB Hardware, assessments of servers, low cost workstations (LCWs) and high performance workstations are being made. The goal for servers and LCWs is to maximize the facilities for the user on the money available. Sharing of facilities will take place where possible. For example discs (for paging, dumping and storage), WAN connections, and printers can be shared. Paging servers (like the Sun) will be looked at, not compute servers. We are investigating servers of this type, but actual purchase this financial year depends on funding.

SUS machines are too expensive (perq2 £25k, Sun3 £30k with sufficient disc, £10k discless). We have to decide what we are willing to compromise on when looking at LCWs. Software and communications interfaces are vital, especially validated software. Resolution of the screen, size and speed, and capacity all need bearable thresholds defined. We will also look at the ergonomics of the machines. They will be Unix based, either System V or 4.2BSD.

Finally Julian proposed that as there are more than one machine range in the Common Base the meeting should decide whether to have a User meeting for each machine range or to have one user meeting for all Common Base users with some machine specific talks in parallel but having joint talks on overall strategy and applications. This was discussed at the question and answer session.

Questions that followed:

Software Tools for the Perq - Update on Kent Software Tools.

Mark Russell, University of Kent at Canterbury.

The tools described were created under a grant whereby the University of Kent acts as a software tools centre for the SERC Common Base Program. Some of the tools replace existing non graphical UNIX tools, others put a graphical interface on an existing tool. The aim is to exploit the graphics of a workstation. There are general purpose tools, for example minit, vdiff, fs and view. Also tools for software developers like ups and the menu package. Fortran tools have been ported to the Perq (various numerical libraries), TOOLPACK has been mounted with graphical interfaces to some of its tools.

The tools were then described in detail. Examples of the tools appearance on the screen are in an appendix of this report

minit is a window manager with a history mechanism. It takes a different approach to command submission, all text-entered commands are entered in the window manager window and saved in a history list. A command in the history list can be resubmitted (perhaps in a different window) simply by pointing at it with the puck. minit also provides command line editing with the puck, thus changes can be make anywhere in the command line. The history list can be saved for use in a later session. minit also provides all the window management functions of winit.

vdiff is a graphical front end for diff. It is an example of how to add a graphical front end to an existing UNIX tool. Diff is useful for comparing files, but its output is hard to read. vdiff reads this output and produces a display of the files side by side, with the differences highlighted. The user can scroll the displayed files up or down. They can also scroll left and right to see all of the longer lines on an A4 screen.

view is an intelligent file browser. It has the speed of cat with some of the facilities of spy. View tries to determine a file's type (text, font, cursor, object etc) and to display the contents of the file intelligently. A window on the flies is displayed which can scrolled horizontally or vertically with the puck. View can be used to watch growing (or shrinking!) files. It can be used in conjunction with fs.

fs is a screen editor for the file system. Files are displayed as editable objects. On the screen indentations is used to show the directory structure. Directories can be expanded to show their contents, and collapsed to hide them. Thus you can wander around the directory hierarchy. All of the commands in fs operate in the same way:

ups is a graphical run time and postmortem debugger for C and FORTRAN programs. No typed commands are used, interaction is by selecting commands from the menu or editing displayed fields. The program being debugged (the target) runs in its own window, so program and debugger output do not interfere. When the target stops, ups displays a stack trace (a list of functions defining where the target has stopped). The users can then select any of the displayed functions and expand it to show the values of its arguments and local variables. The source of the program can be viewed in a spy-like window separately as well. An example of a C program and Fortran program were given. C structures, linked lists and F77 2 dimensional arrays can be displayed. Sadly FORT object files do not have enough information to give array dimensions and other details.

Why was the menu package written?

Menus are the standard method of user interaction for applications on graphical workstations. The design of the menu is an important factor in the user interface of a program, and in the appearance of the display. The best way to design effective menus is by experiment. So it is useful to change menus easily. Menus are not trivial to implement, especially if they are hierarchical or use popup submenus. So a need for the menu editor and the menu library was seen.

The menu package consists of the menu editor med, and a set of library routines to use the menus created with the editor. Library routines are provided to read in menus created with med, to display them and to make selections from them. The menu package provides static and popup menus, various forms of highlighting, dynamically alterable captions and multiple fonts. All the Kent software tools use the menu package for their menus. An example of med was given showing how to add a box to a menu and make a sub menu like search on spy. Different fonts can be used. The return values for the menu selection can also be defined. The menu description is written to a file. This can be read by a program if you are still experimenting (saving compilation time) and when you are happy with it, it can be included in the program to save execution time.

Finally Mark described the FORTRAN tools.

Several linear algebra libraries were ported to the Perq including BLAS, UNPACK, SPARSPAK, LANCZOS and YALE. TOOLPACK was ported to the Perq. A graphical post processor for the TOOLPACK profiler and a graphical version of the TOOLPACK formatter options tool are also available. Examples of these are in the first appendix.


LUNCH and informal demonstrations.

The demonstrations were:

The PERQ as an Applications Development Machine.

B Colyer, Technology Division, Rutherford Appleton Laboratory.

Bryan uses Single User Systems as tools to do applications programming for research and development into Finite Element Analysis. He uses the Perq to develop programs specifically for SUSs and to develop programs that will eventually run on other machines as the development environment is good on the Perq. Most of the Finite Element work has been in processing data for 2D structures. 3D structure representation would be better so they are working towards that.

One of his projects on the Perq is a program which solves potential Finite Element problems. The program is called "apple". This is useful in electromagnetics, electrostatics, structural analysis and many other areas. He is experimenting with man machine interfaces and graphics as aids to the user who is trying to solve problems. The first work was about 4 years ago on POS using Pascal. When PNX came he used sed to help translate the programs to F77 and wrote a C interface to access the graphics primitives from F77. Algorithms for automatic meshing were incorporated and the boundary algorithms were improved. Recently the code has been extensively rewritten to improve the speed of execution of the code and the readability of the source. Better graphical display of data was incorporated. They have also written a 2D stress analysis program.

Software development was easier on the Perq than on a mainframe as the results of the program were graphical so debugging is more obvious. Spy was a useful tool.

Apple is free to academics. Commercial users have to pay for it. Contact Bryan direct for more details.

Bryan explained how they would extend the 2D meshing to 3D in apple. This is very complicated. He uses Delaunay's Lemma to calculate the mesh in 3D. Part of the mesh can be written out to a file at any time so it can be displayed separately and a few points examined.

SUS graphics enabled the models to be drawn faster and easier. A wire frame model program written about 2 years ago was adapted for present needs on the Perq. It did zoom, rotate and shift on the model. The biggest improvement to Perq is the FORT compiler as its compilation time is a lot faster. There are a few bugs in the optimising option. Bryan has a HP Laserjet printer attached to the Perq to produce high quality output and screendumps.

Why yet another Window Manager?

Dr A S Williams, Informatics Division, Rutherford Appleton Laboratory.

Tony addressed this question by talking about the Window Manager (WM) project in MMI section; its history, goals, the work and its current state.

The current work has developed from the original workstations and CBP systems development work with ICL. The aim was to have GKS input types implementable on the window manager software interface without significant degradation of response time. The WM user interface was also looked at later to see how it could be improved. The Spy editor was developed as a testbed for ideas on interaction techniques which were then included in the WW graphics library. The use of WW with spy led to WW becoming the toolkit for spy-like programs. Examples of programs exploiting WW are a clock on which the time and date can be modified using the puck, a continuous graphical ps, and a control panel for puftp.

The proposal for a Window Management project was first written in 1982 and accepted in 1983 but there was no money available from SERC at the time. It was then submitted to Alvey with no response until the MMI directorate was prompted by other Alvey directorates to produce some guidelines on Window Managers as it was essential to their work. So in April 1985 a Window Management Workshop was convened. The proceedings are published in Methodology of Window Management: Hopgood et al. eds. Published by Springer Verlag, 1986, in the Eurographics Seminar Series. Then funding was made available for work to begin on specifying interfaces to Window Management functions.

The context of the work is that applications need supportive toolkits and they need to be portable. Also new workstations need applications to be available quickly. All WMs are very different and toolkits are tied to the WM and often are proprietary. At present graphics standards are inadequate (at least current implementations are; they are slow on workstations in current active user and do not provide sufficiently responsive interaction). In short there is no single toolkit, User Interface (VI) Management System or graphics package that is suitable for all applications.

There are some standards in preparation for Window Management. ANSI is not expected to report before 1989, but MIT has the Athena project (the X window manager), IBM has Topview and PC/RT, the MAC has windows, and GEM is offered by Digital Research. ANSI may be optimistic; GKS took seven years to become a standard. MIT is public domain, free, portable and network transparent if you have the correct protocols. But the latency of I/O is not fast enough. IBMs Topview is text only. PC/RT's manager allows multiple windows but you can only see one at a time. GEM is tied to MS/DOS. The MAC and GEM are geared to a single process environment not a multi-process one. So the future is not too bright.

A solution to the problem is to design an interface that separates the toolkit from the window system. This is called the Client Server Interface (CSI). This means the toolkit may have to be ported with the application. This method is used by MIT.

The project in MMI section is simply to specify the CSI. The goals are flexibility of having different toolkits, performance (otherwise the WM won't be used), high throughput and low latency, display independence/adaptability. All user interface choices should be left open so the VI or Layout Manager can determine them as client's of the WM. It is more difficult for the program to specify what to do if we need to know the properties of menus etc. Tiling vs. overlapping, window properties, control objects, access rights and protection should all be left open to the clients decision.

The CSI does not provide windows. It does provide the building blocks for windows: a hierarchy of viewports mapped to images which are mapped to the display. Input events are passed via viewports onto queues. The hierarchy provides inheritance of position, rank, colour, depth and input properties (event masks, cursor shape) between viewports. The Layout Manager is a client of the CSI. It can take events from the background and the title bars. Typing goes to the tty or application processes. Clients may associate viewports with queues at will. The whole idea is founded on the premise that viewports and low level (pixel oriented) I/O are cheap.

The state of the project is that the CSI is having a final review with manufacturers. Next it will be circulated to the user community for comment. Emulations on the Perq and Sun are starting to be designed to test portability. Porting WW to the CSI will be done later as we need it to port our code. Discussions about the CSI on other UK machines are being encouraged by Alvey. We are looking for major applications to port to it so more people can get involved and so the concepts will be exercised in real situations.


Question and Answer Session with Panel.

ICL and RAL Support Staff.

The panel were

Initials of the panel have been attached to replies to questions.


Examples of Kent Tools

  1. med with 2 windows and the manager driver in the bottom right.
  2. vdiff with diff on the same files above it.
  3. View on text, font and cursor files.
  4. Fs with the current level expanded and some files selected.
  5. Fs after expanding selected directories.
  6. Fs with view running on the selected file (an object file).
  7. ups on fs. Stopped at a breakpoint. A function is selected.
  8. Ups in window 1 with the function expanded and variables displayed. In window 2 a structure is expanded.
  9. Ups. Stopped on a breakpoint with the source in window 2 and the target process in another window.
  10. as 9 but with the function expanded.
  11. Values of the array TREE displayed in a separate window.
  12. med: menu editor. Window 2 adding a 5th option
    • Window 0: giving it a string and return value.
    • Window 3: equalising the boxes of the menu.
    • Window 3: making a sub-menu.
    • Window 0: subdividing and adding titles.
    • Window 2: changing the font.
  13. Toolpack profiler.
  14. Toolpack profiler option modifier.

Figure 1: med with 2 windows and the manager driver in the bottom right

Figure 1: med with 2 windows and the manager driver in the bottom right
Full Size Image

Figure 2: vdiff with diff on the same files above it

Figure 2: vdiff with diff on the same files above it
Full Size Image

Figure 3: View on text, font and cursor files

Figure 3: View on text, font and cursor files
Full Size Image

Figure 4: Fs with the current level expanded and some files selected

Figure 4: Fs with the current level expanded and some files selected
Full Size Image

Figure 5: Fs after expanding selected directories

Figure 5: Fs after expanding selected directories
Full Size Image

Figure 6: Fs with view running on the selected file (an object file)

Figure 6: Fs with view running on the selected file (an object file)
Full Size Image

Figure 7: ups on fs. Stopped at a breakpoint. A function is selected

Figure 7: ups on fs. Stopped at a breakpoint. A function is selected
Full Size Image

Figure 8: Ups in window 1 with the function expanded and variables displayed.
In window 2 a structure is expanded

Figure 8: Ups in window 1 with the function expanded and variables displayed. In window 2 a structure is expanded
Full Size Image

Figure 9: Ups. Stopped on a breakpoint with the source in window 2 and the target 
process in another window

Figure 9: Ups. Stopped on a breakpoint with the source in window 2 and the target process in another window
Full Size Image

Figure 10: as Figure 9 but with the function expanded

Figure 10: as Figure 9 but with the function expanded
Full Size Image

Figure 11: Values of the array TREE displayed in a separate window

Figure 11: Values of the array TREE displayed in a separate window
Full Size Image

Figure 12: med: menu editor. Window 2 adding a 5th option

Figure 12: med: menu editor. Window 2 adding a 5th option
Full Size Image

Figure 13: Continued

Figure 13: Continued
Full Size Image

Figure 14: Toolpack profiler

Figure 14: Toolpack profiler
Full Size Image

Figure 15: Toolpack profiler option modifier

Figure 15: Toolpack profiler option modifier
Full Size Image

List of Attendees

Name                  Institution
J Bovey               Kent
B Brough              ICL
Mrs M Bullen          QMC
Mr Cardew             Sheffield
D Chiu                QMC
B Colyer              R24 5 - RAL
T Conway              R1 -RAL
R Cooper              Glasgow
Mr Datardina          NAG
A Dearle              St Andrews
C Downes              Salford
G Ellis               Aberdeen
J Gallop              R1 - RAL
D Gibson              R1 - RAL
S Guest               Loughborough
Mr Hadjicostas        QMC
K Hartley             R1 - RAL
P Hemmings            R1 - RAL
B Kay                 UCL
P Kent                R1 - RAL
Mr Lai                QMC
K M Lewis             R32 - RAL
J Malone              R1 - RAL
Prof McGreavy         Leeds University
R Morrison            St Andrews
M Prime               R1 - RAL
B Read                R27 - RAL
G Reynolds            East Anglia
D Rickets             Oxford Univ
K Robinson            R1 - RAL
M Russell             Kent
A Sherwood            North Staffs Poly
J Steel               QMC
J Stewart             Southampton
R Stroud              Newcastle
J Tierney             Liverpool
Dr Visvalingam        Hull Univ
Dr Wait               Liverpool
T Watson              R1 - RAL