-
Notifications
You must be signed in to change notification settings - Fork 2
Running banpipe scripts
Once installation of banpipe is completed, you can load banpipe using the command
{banpipe(init)}.
A banpipe script is loaded using the command
banpipe::load(Filename)
where Filename is a relative or absolute file name in the filesystem.
You need to supply the full filename including possible extensions, e.g. .pl
To run a goal in a banpipe script the command,
banpipe::run(Goal)
is used. This will run the scripts sequentially in a bottom-up, left-to-right fashion, i.e., dependencies are computed first left-most dependencies in a task are computed before right-most dependencies.
To get the filename corresponding to the goal, call instead,
banpipe:run(Goal,File)
This will unify File to the generated file corresponding to Goal.
When banpipe::run(Goal) is called, scripts are run in a sequential fashion. It is possible also to run scripts with automatic parallelization, so that all independent tasks will be run simultaneously. This is achieved by calling,
banpipe::prun(Goal).
Runnings scripts with parallization is only available when running banpipe with logtalk on a Prolog system which has threads, e.g., SWI-Prolog.
Scripts are not type checked when calling banpipe::runor banpipe::prun. Is perfectly possible to
run a script that is not well-typed. However, type checking a script in advance may help to avoid
errors. To typecheck a script use the goal,
banpipe::typecheck(Goal)
or similarly
banpipe::typecheck(Goal,Type)
to get the Type corresponding to Goal. banpipe::typecheck fails with a report of the type error,
if the script is not well-typed.
A call graph shows the interdependencies between tasks and may be used as a way to debug scripts. Even though it is a graph, it is displayed as a tree where nodes which are shared in the graph are shown as multiple branches of the tree. A call graph is obtained by calling,
banpipe::callgraph(Goal)
For instance, for the hello world example, the following call graph is produced:
?- banpipe::callgraph(helloworld(english)).
+1 ready helloworld::helloworld([hello(english),world(english)],[])
|--+3 ready helloworld::world([],[language(english)])
|--+2 ready helloworld::hello([],[language(english)])
The trace semantics...
There is really nothing special about change propagation. Applying change propagation is
achieved be re-running goals. However, changes to modules are not detected automatically.
Instead, each task declaration in a module may include a version option.
When the the version option is changed, the task gets a new signature and will be recomputed
the next time a goal involving the task is called.