We developed a GUI application to simplify the process of creating and running configurations.
The main screen from this is shown in figure 6.4.
Figure 6.4: The GC GUI main screen.
The configuration that the user is currently developing is shown in the Processes panel. This is a list of the processes that will be attached when the workspace is started. The Parameters panel displays the parameters for the currently-selected process and allows the user to adjust them. The Available Processes panel is a list of all available processes, i.e., all those provided with GC and all those the user has written themselves. Users can add new processes to their configurations by dragging processes into the Processes panel and can remove them by hitting
“delete”. The Description panel provides a description of the currently-selected process. The user can determine what appears here by implementing a process’s getDescription() method, which is called by the GUI to populate this panel. The Feedback panel gives feedback to the user, for example when configurations have been saved, loaded or run. Several buttons in the right-hand bottom corner allow the user to load and save configurations. In addition, there
6.3. GC Configuration GUI 109
is a Combine button which allows the user to combine two configurations by adding all the processes of a previously saved configuration into the current one. In future work, as discussed in §13.4.4, we will enhance this interface by, amongst other things, giving the user the ability to drag and drop specific sub-groups of processes rather than just individual processes. The other buttons in this panel are used to run the configuration or adjust settings via the Settings GUI described below.
6.3.1 Runtime Settings
The Settings GUI has five tabs, each of which is shown in Figure 6.5. These are various settings that GC will use when it runs a configuration. The five Settings panels do the following:
Output indicates where the output from a run is to be logged. A run generates three files as follows. The broadcasts file, which mirrors the console output, contains details of the broadcasts and other runtime statistics, such as the number of attached processes in a round, the number of proposals, timings, memory usage etc. The proposals file stores details of all the proposals that were made in each round, whether broadcast or not. The processes file provides a log of all processes created during a run of the configuration. Example output files, from running the example configuration in §5.4, whose GC configuration file is shown as figure 6.3, are shown as Appendix B.
Extensions specifies where the code for the available workspace processes are stored.
This information is used to populate the Available Processes panel of the GUI. The processes in these directories will be picked up by the GUI and the user will be able to drag them into their configurations. Currently, in order for the processes to appear correctly in the Available Processes GUI, they must be compiled in a package with a
“gc.process.” prefix. This panel exists because the core GC code has no knowledge of the processes that have been developed. GC provides the framework for creating processes but, aside from that, they are independent and can perform limitless tasks. As GC has been compiled with no reference to concrete WProcess classes, it must be told where the code for the available process classes is stored. When it knows this, it can populate the
Figure 6.5: The GC settings interface.
available process panel on the GC GUI. Furthermore, GC relies on the information in the extensions panel and uses dynamic run-time class loading to load the code for any new type of WProcess that is attached. For example, when a configuration file, such as the one shown in figure 6.3, is loaded, the class names for the attached processes are given as strings and so they are not necessarily loaded because the compiler may not have checked this. We do not think it would be beneficial, or indeed possible, to pre-load all possible classes. This would either require creating an instance of each of these objects, which would require knowledge of valid constructors and parameters, or require encoding a reference to each in the core GC code, which destroys the modularity.
6.3. GC Configuration GUI 111
Methods lists those broadcast-analysis methods which should be run each round. These methods are used to boost the workspace efficiency and are discussed in §6.3.3.
Variables details any user-defined variables. These are similar to the environment vari-ables commonly used by operating systems. Their purpose is to allow the user to run the same configurations on different systems. A common use of an environment variable would be to specify the location of executables or directories on the local host system.
Options allows users to specify the stop round. In addition, it lets them determine how the workspace chooses between equally-ranked proposals. A fully-random, seeded-random or lexicographic ordering can be selected.
6.3.2 Parameter Setting
Users may wish to define run-time parameters for the processes they create. This allows them to change their initial conditions, for instance the background knowledge to use for a particular run. Additionally, such parameters make it easier to adapt processes to new applications. GC attempts to simplify the process of defining and setting run-time parameters in several ways, as follows.
When a user defines a new process and they extend the WProcess class, they are advised to prefix the variable name they use for their parameter with “param ”. This will act as a flag to GC, which will pick this variable up and include it in the parameter list on the GUI, as shown in figure 6.4 (GC will exclude the “param ” part of the name). GC will then ensure that any value that the user enters is appropriate for the type of the given parameter. For example, GC will not allow float type parameters to be given String values unless they represent numbers.
In addition, the user can have GC automatically check the validity of a parameter’s value by defining some other variables. For example, the user could define a field, as follows, for the importance ranking that a process should apply to its proposals.
int param Importance = 100;
This would automatically appear in the list of parameters for that process, with a default value of 100. The user could then make the following declarations in their process:
static int min Importance = 0;
static int max Importance = 1000;
This would instruct GC to allow a user to only set the Importance parameter, as named in the GUI, to a value between 0 and 1000. Note, the static modifier saves memory, as only only one copy of the variable will be held rather than one in each process. These help to prevent errors and potentially increase efficiency by removing the need to check parameters at run-time. The user can over-ride the setParameter(String, String) method of the WProcess class if they want more complex behaviour. WProcess provides the invalidParameter(String,String) method to allow users who do this to flag appropriate errors. All WProcess objects have a pre-defined boolean parameter, enabled, which allows them to be turned on or off for different runs without dragging them in and out of the configuration and re-setting their parameters.
Figure 6.6: The GC Parameter Update screen.
In order to change the value of a parameter, the user clicks on the parameter’s value in the main GUI. This brings up the dialog box shown in figure 6.6. This provides a list of suggested values for the parameter, which will be all the different values that the currently-selected processes have for that parameter. In addition, the user may select from the list of user-defined GC variables, as discussed in §6.3.1, and add them to the parameter’s value. Alternatively, the user can manually enter anything they wish. When the user presses “OK”, the chosen value is applied to all currently-selected processes.
6.3. GC Configuration GUI 113
6.3.3 Broadcast Analysis Methods
GC provides a method by which the user may boost the run-time efficiency of their configu-rations. The broadcast format, as we described earlier, is a list of Strings. Each process must therefore parse the strings in order to determine whether a process is relevant to them and to extract any information they are interested in. This represents a large processing overhead when there are many attached processes. For example, in our theory formation application, described in chapter 7, we use the first String in the broadcast to indicate the type of broad-cast. This is a major determinant of whether a process reacts to a given broadcast or not.
Consequently, this will be parsed by the vast majority of processes each round, and there are often thousands of such processes attached to the workspace.
In order to mitigate this overhead, we introduced the ability for the user to run specific methods each round to perform analysis tasks on the current broadcast. The results of these analyses are then stored as static class variables in the Java Virtual Machine. It can be used to set flags to identify, for example, the type of broadcast. In addition, it can be used to parse elements of the broadcast, such as numbers, into their primitive counterparts. As an example, in our theory formation application, described in chapter 7, we call the Artefact.analyse(Proposal) method each round. This sets a number of static fields in the Artefact class according to the specifics of the broadcast, such as the boolean isBroadcastConcept field. This field is set to true if the first element of the broadcast String list is equal to “conc”. All processes can then make this check by referencing Artefact.isBroadcastConcept rather than re-parsing the String.
By instructing the workspace to call these methods each round, we ensure that the analysis of the broadcast has been performed and that the attached processes can rely on this fact without having to do the analysis themselves. An alternative equivalent approach, for users who do not wish to specify analysis methods, would be to concatenate additional flags to the end of the broadcast. It would be slightly quicker for reacting processes to parse these flags, which are likely to be short, rather than parsing and analysing the elements of the broadcast that are used to set them. However, it would still be slower for a process to read and interpret, say, a single character string, e.g. a “0”, as false as opposed to simply reading a boolean field.
Analysis methods have the added benefit that the broadcast string arrays are kept shorter and
therefore are likely to be cleaner and more human-readable.
In some sense, using this approach can be seen as a strict departure from the GWA principles.
Some external process is performing the analysis and is essentially communicating this to all attached processes. However, it does not break the strict rules of the framework on inter-process communication. It’s just a method of speeding up the work that each of the inter-processes would normally do themselves, rather than an amendment to the communication protocol. The approach to designing combined systems is not affected by having this facility. It is important to note that the GC framework does not restrict users in any way from fully harnessing the usual benefits of the Java language, such as methods, encapsulation etc. Indeed, we make use of these benefits quite often in our applications. For example, we often use static methods for code which several processes use, for example the code to construct well-formed broadcasts.
6.4 Conclusions
In this chapter, we have described the software toolkit we developed to enable users to develop configurations according to the framework we described in chapter 5. The toolkit allows users to develop or adapt processes for use in their own configurations. The GUI we have designed allows users to bring processes together into configurations, to easily control the initial set-up and run the systems that their configurations define. The toolkit also aims to improve the efficiency of developers and their systems in a number of ways such as automatic parameter handling, environment variables, and analysis methods. In the long term, we would like GC to reach a point where users simply drag and drop pre-defined processes into configurations to create their own applications. This would remove the need for skill in programming or any knowledge of how to run the underlying reasoning tools. This would all be abstracted from the user, removing many of the barriers faced by novice users in creating combined systems.
In chapters 7, 8 and 9 we describe applications we have developed using GC and how they perform relative to the bespoke combined reasoning systems from which they take their inspi-ration. In chapter 10 we describe how we have adapted GC to run in a parallel manner over multiple hosts.