Things you MUST know!
Previous: About Brain Aid Prolog
Next: Frequently Asked Questions
1.2.2. Things you MUST know!
Reading this section (with some knowledge about the system, gained by exercising a few examples) will help you to avoid a lot of trouble.
The Importance of the Console Window
The console window is the center of the BAP system. It gains special importance as an output device for error and warnings, that are not severe enough to cause a nonmodal error box. If anything goes wrong with your application, please have a look into the console window first.
Environment Variables
Please refer to the "read.me" file on your distribution media for the latest information of environment variables. Missing or bad set environment variables are the major cause for non-running system components.
Preliminary example setting are:
PATH = c:\bap\bin;\windows;... BBIN = c:\bap\bin BINC = c:\bap\include
Code Management
Code in BAP is split into modules , that export and import predicates. All these exported and imported predicates are managed by a symbol table that is local to each node in the network.
The most interesting feature of the code management is the runtime link capability, that load and links a module at runtime, when an exported predicate of this module is called.
A problem arises with the 'call()' and 'not()' predicates, when a predicate is called for that no reference exist at all (no export and no import statement in any module, already loaded). Note that the compiler discards import statements if you do not use the imported predicate in any compiled subgoal. The 'call()' will fail and will only display a nonexistence warning in the console window. This can especially cause problems when a large application consisting of many modules is only partially load onto the network. It is advisable to create a predicate like 'load_xxxxxx()' (where xxxxx is the name of your application) to load the application onto the network. This should be done using the 'load_all()' statement. The use of 'load()' (which loads code only onto the local node) is recommended for special purposes only.
Server Management
The BAP servers represent the (restricted) processing resources of a network. They play the key role in application parallelism. For this reason, the free servers are permanently displayed in the "System Status" window. In theory there would be no problems creating an infinite number of processes (that server as servers) in a Transputer network. Practical considerations of memory restriction (a PROLOG process needs at least 32 Kbytes RAM) and of overhead (creating and killing processes) lead us to a (more or less) fixed number of servers per Transputer node. This restricted number can be increased by the user (using 'create_processes()') but the limited processing resources somehow fit pretty good into the coarse grain parallelism scheme of BAP. Please see the section about Server Management on details about the mechanism.
Directories
The WIO by default starts up in the "/BAP/EXAMPLES" directory. This default can be changed with the properties menu on your host computer (please see installation of the WIO) or by the "cd()" predicate. "Cd(X)" returns the actual directory and cd("/bap/myproject") changes to the given path.
WIO uses this directory for its search for files. First the current one is searched and than all others, given in your PATH environment variable (especially "/BAP/BIN", too).
Atoms
Atoms normally are stored in one global atom (or symbol) table to reduce string compares and to save memory. This is not possible within BAP because local (local to each node in the network) atom tables would cause inconsistencies and the implementation of one global table would cause an unacceptable overhead. Our solution is to treat atoms just like other items, e.g. integers. Furthermore, strings are treated the same way (instead of being a list of characters) and a fast string library is provided to manipulate both strings and atoms.
Dynamic Programming
Dynamic predicates, known from some frequently used PROLOG systems, would cause similar problems as the atoms above. The rather complex structure of code management on a large sized network (to avoid to load the entire code to all network nodes and to reduce host server I/O) prevents a consistent AND elegant implementation of dynamic predicates. We decided to keep the code itself static, but to provide two ways for "dynamic programming": Using the PROLOG Inference Engine ("PIE", a small PROLOG interpreter) and using the runtime recompile feature that allows compilation and linking of modules at runtime.
Operating System like Features in BAP
The BAP runtime system is widely influenced by the (negative) experiences with Transputer operating systems that never archived a satisfying stability (due to the lack of a memory management unit and other restricted resources on a Transputer). Real multi-application programming was never a goal in the development of the BAP system. Instead a compile-and-boot model seemed to be much more promising, known from all major development systems for Transputer.
Unfortunately standard PROLOG requires something like an interactive shell to operate, and soon we arrived at an operating system like level where a user can launch several independently running applications. If you run several applications, a reboot will be necessary from time to time to release unnecessary code loaded to the network and to defragmentate the memory. This should be thought of a the normal case. However it is possible to operate BAP quite a while until the (especially memory) resources are getting low.
BAP Online Manuals : BAP Overview : Introduction : Things you MUST know!
Previous: About Brain Aid Prolog
Next: Frequently Asked Questions