geed wrote in Sat Mar 11, 2017 5:01 pm:@abassign, How far did you get in analyzing Erlang? Please try to implement a real world application or solve a real world problem with it and I would like to know how you evaluate the language or the environment afterwards. This is not meant as a joke or to mock you, please Test Erlang and come back and present the problem you solved with the solution you came up with. I would be extremely interested in your approach and what analysis you made and how you relate that to a possible implementation as a scripting language in Flightgear.
Meanwhile, I'm sorry for the delay in the response.
Erlang is a language to manage applications with highly fragmented and driven by events on multi-CPU systems. I would say is just perfect for simulation applications such as FGFS!
FGFS is fundamentally based on a hierarchical data structure (Property Tree or PT), structure in which Erlang (As LISP, from which derives ...), it has a correct and complete syntax for access to these particular data structures.
When building a complex plane (777-200, SU15, Mig15, F14, A10 etc ...) we observe an immediate explosion of subsystems, such as the electrical system, the hydraulic system, instrumentation (especially if the analog type) etc . All these objects interact with each other through messages that are currently managed by PT. I have often noted that such "explosion" of tasks leads to a real slow system performance, regardless of the problem of slowness due to the graphics card.
Certainly an approach based only on messages (Where Erlang is great) would reduce much stress and allow to operate on a real distribution of the workload across multiple CPUs.
Unfortunately we live in a real world and profoundly change the data structure based on the PT, is not currently feasible.
At this point I feel that if it were possible to implement a bind, or build a SOLID C ++ interface with PT. This would open the possibility of a much more extensive use of other languages such as Java, javscript, Erlang, Python etc ... to be inserted directly into the folder that contains the plane's data.
Now it becomes more complicated, a bind is efficient if you do directly on the system if it is implemented and not through a high-level access code (TCP-UDP). You can also create bindings using special system calls but are dependent heavily of the OS installed on.
Personally I like the idea of an application operating at the TCP level, the reason is that in the current multi-CPU systems, TCP transactions are handled by separate task in multi-CPU mode and then have a weight reduction of the frame rate, very low.
Now what I am saying is true for any language that will want to interface with FGFS:
1. Through the XML it must be possible to activate / deactivate an external interpreter (Erlang, Python, Java, javscript, LISP, etc.) which itself loads the program to run it becomes an independent task of FGFS.
2. The interpreter needs to know what IP address to start the conversation and have a series of commands that allow you to build a dynamic transmission protocol between the data in the PT. Because the PT is very complex it is useful to assume that each task will take charge of getting what he wants and be then the connection system that distributes data in an appropriate manner.
Better to make an example:
1. In FGFS an XML declaration that opens an external interpreter (eg Python, Erlang, LISP, Java, JavaScript ...) and activates the TCP connection channel.
2. The interpreter runs the application.
3. The application for example require to read the altitude and speed of the aircraft and will send back the value of the throttle.
4. The application then opens a data read/write channel, to the PT. In this way, the PT can build a data packet send with an unique and short TCP transaction. These channels are no more than a data structure to be built / dynamically destroy that allow a high read / write speed. Personally I believe incorrect use more sophisticated methods (and therefore slow ...), because it makes no sense. The important thing is that the individual tasks have the ability to see the PT data in reading and in writing with an optimal speed of less than 10 ms.
5. From now all the processing load is the responsibility of tasks that have been opened by the interpreter. When individual tasks performed processing, they send their responses (eg the throttle value) to the output channel, which, every 5-10 ms, is sent to the PT to update it.
The solution I have proposed is designed for external tasks, with other languages, on different machines (!), Using only a few commands and a few transactions.
Transactions will be faster if they are few per unit of time and only with the data that we need!