- What stage is the project at?
The Opensource application is at a "proof of concept stage". There is a workable graphical user interface with growing set of built in functions and its own execution engine. We are currently working on optimizing the data structures to minimize the memory overhead in embedded applications.
- Isn't it very inefficient?
The execution engine does represent a processing overhead. The impact of this depends on the size of the functions it is controlling - bigger functions mean (proportionately) less overhead. More importantly the saving made through the "only recalculate what is needed" means that the almost every application will run faster.
- Does it produce autocode?
No. It doesn't produce any code at all. All of the code - the functions used - must be predefined. The graphical tool is used to set the sequence in which they are executed. Like a flow chart, it is the order of separately written processing steps that is being defined.
- Is it like a functional language?
In that it uses the dependency structure to determine the sequence of execution the answer is "a little". But functional languages use an "output pull" approach - they know how to recalculate a desired output variable and work back up the hierarchy recalculating the elements needed for the output. DeltaFSD operates the opposite way round - it uses changes in inputs to trigger processing, to push new values through the dependency structure. Outputs are updated only if they are dependent on a changed input.
- What's next?
Our current focus is on the embedded aspects of the concept. How to build efficient data structures, and so minimize the memory requirements, in an execution-only system. This will determine the output file format and in turn set the data structures in the definition tool. The graphics need a lot of work - but first the decision on whether to stick with C or move to Java and then what graphical API to use (ie whether we should switch to a Windows implementation).
- How does it deal with different data types?
It doesn't - yet. This is really a problem for the embedded system. In the graphical tool variables are only ever passed as pointers so having pointers to different data structures wouldn't be a problem - provided they are handled consistently by the functions. This information though needs to be transferred to the embedded system - without requiring vast amounts of memory to be allocated on start-up.
- What resources/environment is required?
The graphical tool needs a basic set of gtk functions - anything after libgtk should do. You can download static executable if you have any doubt. The latest versions V0.4 up need libxml for the data file format and the various files needed for embedding Perl
- How do I add my own functions?
If aren't worried about speed and don't need an embedded application - then write your function as a Perl script. Adding functions directly to deltaFSD isn't difficult though. The Programmer's Manual has some guidance.