Archive

We freely offer those artificial intelligence base software products to our visitors for non-commercial purposes that have been developed earlier in our R&D projects.


DANUBE - a distributed make system

 

We developed the DANUBE system from 1995 to 1997, the latest version of 1997 can be downloaded.

The DANUBE is a programming tool which supports development and maintenance of distributed programs in heterogeneous computer networks. The DANUBE enables programers and users maximally take advantages of peer-to-peer networks of with X-Window based UNIX workstations and MS-Windows based personal computers.

The distributed project monitoring system keeps the heterogeneous network projects up-to-date. Though the DANUBE can be widely used, the most frequent usage if we use it as a distributed version of UNIX „make” program. If there are some changes in the project, the distributed make system checks the dependencies of the project and explores the affected project objects.

In the DANUBE system project objects can be in a heterogeneous network so during the execution of make function the computer platform may change. Both project objects and make execution threads can be transferred from one type of computer to another one. A special service of the distributed make system is that it can concurrently re-run the make on dependencies of a goal object.

The make activities are described as objects. A set of predefined object types (classes) can be used to define activities. This object definitions may take parameters (mostly other objects, but other parameter types are also possible) to describe the unique attributes of the activity. The activities has dependants (objects which the activity depends on), and the program checks if an object is completed (up-todate) before trying to make it. The general improvement in this concept is to use objects as project goals, rather than files (as in the standard Make).

The object-oriented structure of the DANUBE system enables users to define and implement own object classes, relations and actions. This feature makes the DANUBE system a very efficient tool. Because of its openness we have not only a distributed make function but a distributed make generator system as well which enables users to create an individual project-monitoring system based on own demands.

The object-oriented make system uses object-oriented make files, so the makefile contains both object declarations and dependency information. The make actions are determined by the object types. In the makefile we can use instances of predefined classes. The class definitions are 'wired' into the Make program, and can be extended by extending the Object Oriented Make itself.

 

  DANUBE Manual
  DANUBE for Windows (16-bit)
  DANUBE for Sun Solaris
  DANUBE for Linux (ELF)

 


CS-Prolog II

 

We developed the CS-Prolog II Prolog system from 1995 to 1999, the latest version of 1999 can be downloaded. The base for defining the syntax and built-in predicates of CS-Prolog was the Prolog Standard (ISO/IEC 13211-1) which appeared in 1995. This base was extended with several features not included in the present standard — modularity, multi-processing, real-time programming, network communication.

The most interesting property of CS-Prolog II is the possibility of creating processes that run in parallel. Processes created on the same processor are executed in quasi-parallel by Prolog, applying time-sharing technique. Processes can communicate with each other through channels. Real-time techniques are available as, e.g. creation of cyclic processes, reaction on predefined events, alarm clock to set time-outs, etc.  Processes ar independent from each other apart from the communication, eg. a backtrack in one process  doesn’t affect other processes.

A sophisticated exception handling mechanism is implemented in CS-Prolog II. It makes possible to catch an exceptional situation (an error or an interrupt) and handle it with a Prolog procedure written by the user. After exception handling the execution of the program contuniues as if the exception (error) didn’t occur.

The networking communication is an inter-application extension of the channel concept. This feature makes possible that CS-Prolog applications can communicate through the Internet.

The CS-Prolog II programming system consists of a compiler, a linker, a runtime system and an integrated programming environment that combines the previous three components. In the environment, the user can debug the program using an interactive trace. The compiler incorporates a preprocessor, which is very similar to a standard C preprocessor. It helps to write more readable and portable programs. The CS-Prolog II is documented with several manuals.

 

  CS-Prolog II User's Manual
  CS-Prolog II Networking Supplement
  CS-Prolog II Graphical User Interface Manual
  The CLP Solver Developer's Guide
  The ML Linear Solver Description
  CS-Prolog II for Sun Solaris
  CS-Prolog II for Linux/ELF
  CS-Prolog II for FreeBSD
  CS-Prolog II Development Environment for Sun Solaris
  CS-Prolog II Development Environment for Linux/ELF

 


CS-Prolog Interpreter

 

We developed the CS-Prolog interpreter from 1986 to 1991, the latest version of 1991 can be downloaded. The system aimed to extend the traditional Prolog with parallel and simulation possibilities. The new concepts in CS-Prolog are: process, communication through messages and discrete simulation time.

In a CS-Prolog program a new process can be created that is assigned to a goal (a Prolog predicate to be executed) and a termination time. The processes can communicate with each other through messages. A duration time can be assigned to the execution of a Prolog procedure. The system realises the deadlock (when all processes are waiting for a message) and automatically backtracks.

The CS-Prolog interpreter has a monoprocessor (DOS) and a multiprocessor (transputers) implementation. Processes created on the same processor run by the system according to the so-called next-event algorithm. It means that the active process can run until either it has to wait for a message or it sets the time. After deactivating a process the system selects the following runnable process, in the nearest simulation time. It is important that here the time always means simulation time, not the real time.

The CS-Prolog execution algorithm is complete, i.e. if the Prolog goal has a solution, it will be found. For this purpose the effect of a backtrack is global, i.e. if a process backtracks then all the others backtrack too. In the multiprocessor version it is controlled by a sophisticated distributed backtrack algorithm.

The DOS version of CS-Prolog interpreter contains extensions suitable for continuous simulation. We can define continuous processes whose behaviour are expressed with the help of differential equations. As the simulation time goes on, the interpreter determines the solutions of the equation system that can be queried by other (discrete) processes. The usability of DOS version is limited because it can use only the conventional DOS memory (640K). We offer a DOS extender (compiled with DJGPP) version as well. This version has no memory limits but continuous extension and graphical builtin predicates can’t be used. The DOS extender version has no separate documentation, the manual for DOS version can be used considering the mentioned limitations.

In the documentation there are references to the compiler related to the CS-Prolog interpreter. This compiler can’t be downloaded, these parts of description have to be omitted.

 

  CS-Prolog Interpreter Manual for Transputer
  CS-Prolog Interpreter Manual for DOS
  CS-Prolog Interpreter for Transputer
  CS-Prolog Interpreter for DOS
  CS-Prolog Interpreter for DOS + DJGPP DOS Extender
 
 
 
 

© 2010 - 2013 Multilogic. All rights reserved.