Why not use Erlang instead of NASAL?

[abassign]

Sorry if I introduce this topic in its own post NASAL, but it seems the most appropriate context for my proposal / provocation:
Why not use Erlang instead of NASAL?

Erlang is a functional programming language that supports concurrent
programming. Computations in Erlang can proceed in parallel on
a network of computers, and the language is designed to ensure that
no unwanted interactions occur.
The key concepts in Erlang are: functions, single-assignment variables,
tuples, pattern matching, race conditions, message-passing and
recursion.

(I am analyzing the use of Erlang to program a set of Raspeberry of my laboratory, this oriented language on interprocess messages and on parallel processes I can solve many problems that Python and Java can not solve in a fast and reliable and at the same time. .. with compact code)

I honestly do not find Python suitable for FGFS, the reason is the lack of a message handling interprocess and the difficulty of performing parallel processes. Python was born as a scripting language to run on a single CPU. Then there have been extensions, excellent libraries (but very tied to the operating system ...) and many programmers who know him. But it scares me the idea of replacing NASAL with Python, as a plane has many systems and each of these is executed in parallel. Then these processes will have to speak ... etc ...

NASAL, is certainly a primitive language and poor, but has developed a very good idea, to run each process with their own interpreter, small lightweight and fast enough for many applications. But NASAL is not a widespread language ... very few developers (1..3?) Very few programmers (10 ... 100?) And in any case is not a good language because its virtual machine does not handle more than one CPU, the interprocess messages are there but ... honestly ... are not the best ...

Erlang instead has a large base of professional users and companies (such as FaceBook uses it to chat). There are also OpenGL extensions (Has anyone tested the application of 3D graphics: Wings3D ... that uses a full and fast OpenGL interface?)
Obviously Erlang has a very good documentation and many examples that can guide those who want to challenge themselves with this language.
You can be used in parallel with NASAL? Why not ! Just declare the XML script that the code we have written in Erlang and is not NASAL and the game is done!
Erlang provides a complete C ++ bindings using its own messaging, which binds well with the data model of FGFS.

Let us read this paper on Erlang:
http://www.tamale.net/erlang/tutorial.shtml
http://www.it.uu.se/edu/course/homepage/prognovis/st11/reading/erlang-concepts.pdf

An official user guide:
http://erlang.org/doc/getting_started/users_guide.html

An easy tutorial:
http://learnyousomeerlang.com/introduction#kool-aid

Does it make sense?

[Hooray]

Not sure if you even the slightest bit familiar with Erlang (or using it another host application) - to be honest, it doesn't seem so.
The only component for which considering Erlang would make "somewhat" sense is the FlightGear multiplayer system, i.e. re-implementing fgms functionality.
Besides, if you have ever written code in Erlang, you will appreciate the accessibility (=lower barrier to entry) of Python, Lua or even Nasal.
If we were to assume that Erlang would replace Nasal, that would basically be the end of any aircraft/fgdata scripting not done by people with a professional background in software engineering (i.e. excluding those of us not holding a MSc/PhD in CS/SE).
If you don't believe me, I suggest that you consider writing a portion of Erlang code re-implementing functionality that currently exists in Nasal - such as e.g. tanker.nas, you can interface the whole thing with FlightGear via the telnet/props system, so you can even make it work.

So, no it's not a good idea (and not because I dislike the language, but because I am a little familiar with it and its strengths and weaknesses), so I don't need to read those papers you linked (I actually have read most of them years ago), Erlang is inappropriate for replacing Nasal. And I really suggest that you try to write/port an existing Nasal script to erlang to see what this language is all about to appreciate the point I am making.

http://bluegraybox.com/blog/2011/09/18/ ... -language/
http://stackoverflow.com/questions/1938 ... nterpreter

[abassign]

It is not a goal to attract more developers by having feature X, where X is a different value for every FlightGear user.

Not sure whether abassign is doing it on purpose, but I think this illustrates the 'X is different for everyone' point rather nicely. I guess we've also seen Lua and javascript proposed elsewhere (did I miss anything?)

(Come to think of it, I really do like Fortran... and it's very fast)

Obviously, I am absolutely provocative in a context of calm sea that seems to be the place of amusement by Fgfs developers.
I like to shake up the waves if this can lead to thinking in a less obvious way.

Deepening the short text of my opening remarks, I can summarize as follows:

NASAL was born to solve the problem of the need to be able to perform many tasks in parallel, efficiently and disconnected on the operating system.

The NASAL programs are generally very small and immersed inside the XML which is the interface to the structure of FGFS data.

NASAL suffers from being too specialized and therefore an unsuitable development which unfortunately makes it a scripting language related only to the environment of FGFS.

Throw away the NASAL development environment is still a shame because many of FGFS objects were written in NASAL.
Many find themselves well to develop the so NASAL environment because breaking the toy that pleases many developers?

The extreme specialization of NASAL indicates that it is not easy to find something alternative that can actually give evolutionary advantages to the developer of FGFS.

I think it was in January when it was proposed Python, I liked the idea, I write Python code since 2000, I use it for many problems and I am moderately satisfied. Unfortunately, with time, I noticed a big problem with Python is an efficient environment to manage individual processes, but it has no facilities that can comfortably handle multi-processes that need to exchange data. This applies to almost all procedural languages, as they are derived directly from the typical batch methods of execution of Fortran / Cobol / PL-1 / C. Perhaps only JavaScript makes sense as it is a language that is typically dipped into the XML structure. But I see a great advantage in this, its just-in-time compiler is very efficient, but then must still interact with the XML that is to bind with the FGFS core.

However, the basis of everything I do not like XML, I find it distracting and redundant, in the context of the Web makes sense as used to describe a single page, but when you have to build dynamic pages, the music changes! Of course there is the JavaScript that helps, but it is a language aimed at the execution of code on the client with the ability to send / receive, with only some method.
Javscript has good performance as can be compiled just-in-time, but the executable works only on a thread. With HTML5, something is changing by the insertion of WebWorker, but paliative care to enlarge the application area of a language born for other things.

I'd rather something that would eliminate the XML! He would put everything in one language that allows to have an efficient interprocess activities and essentially consists of small modules that can be easily synchronized.
Erlang being designed as PBXs programming language (https://en.wikipedia.org/wiki/Erlang_(programming_language)) has many useful features in the FGFS ambient. Obviously has a very different programming paradigm, certainly a few of you you can mentally accept ... and so it is natural to ask the ability to have a connector that might serve as an interface between the FGFS and Erlang world. This is also true for other languages, such as Python. Personally I do not think it makes sense to develop libraries that emulate what makes NASAL, I see only a huge waste of time, while I would focus on the binding of those essential functions described in XML that can be substitute, and at this point, by a program Python or other language like Erlang.

At this point my reasoning is simple: to have APIs that allow to retrieve the XML functions that are the basis of all FGFS world. These can be in C ++ and then will be those who want to implement a certain environment to build its counterpart via the interface libraries of its programming language.

[Hooray]

I am familiar with functional programming (as per LISP/Scheme), Nasal scripting in FlightGear, the way the Nasal engine is integrated into FlightGear, and the way Nasal works under the hood (i.e. the whole codegen and bytecode interpreter thing). With that background, Erlang makes zero sense - supporting Python, and particularly Lua, would make much more sense (I am not suggesting to do so, just stating the obvious).
Erlang would shine for anything involving binary data processing, networking and HA (high-availability/redundancy), it would be a good fit for coming up with a revamped MP/fgms re-implementation on top of "XDR-encoded remote properties" in a PUB/SUB fashion, requiring very little code.
Python's GIL (=global interpreter lock) is making Nasal's threading support looking much more appealing than Python for anything involving multiple threads/processes.

If you want to understand (and possibly address) most/all of the issues that Nasal and fgfs are facing without having to go through hundreds of postings made over the course of over a decade, it would be a good idea to review Richard's postings in the other thread, specifically look at Torsten's mongoose work and then read up on James' proposal: https://sourceforge.net/p/flightgear/ma ... /34790212/

In combination all of these ideas are very much aligned, and they would make it possible to provide an alternative scripting environment within a few release cycles, possibly even preparing the groundwork to replace Nasal in its entirety (once you have a sound alternative, coming up with a translator that translates idioms between both languages isn't that much work, Nasal is much less sophisticated than Python, so the translation is relatively straightforward, because there's a 1:many mapping).

Either way, I am -again- finding your postings way too abstract and hard to process/understand the key message, you may want to consider formatting your postings or even introducing headlines, because it is hard following your line of reasoning - or even consider posting in your native language to make more specific points

PS: Given your interest in multi-process IPC you may want to look at Google Go and its notion of "channels".

[abassign]

I am familiar with functional programming (as per LISP/Scheme), Nasal scripting in FlightGear, the way the Nasal engine is integrated into FlightGear, and the way Nasal works under the hood ...

My idea, which generated by my provocation, is not simply to elect a replacement to NASAL, but to define a methodology for direct exchange with a generic interface in C++ that can replace the XML interpreter! This way you can make bind with any language, without having to stand behind the preferences of each programmer. The interface can be specified eg Python and Lua, but by filling in a timely manner it is possible to build other interfaces for other languages. This would make it very simple to do interfacing applications, such as an HTML5 browser with its good JavaScript interpreter etc ...
Mine is an absolutely crude and probably inaccurate diagram (it is very imprecise means that the program inside it has layers of software not entirely consistent, but that is another problem ...). That could, with ease, allows everyone to use FGFs as he wishes. And if a particular language implementation, and related libraries, will be successful I believe there will be a natural integration of the new code within the main line of development. Something that was made for other open-source projects.

I add that I do not like being forced to something if this can be avoided. FGFS is a good environment to develop a fairly realistic virtual world, to simulate the behavior of objects in this world and to see it all on a monitor. But the objects that occupy this virtual world must be made with greater freedom according to the desires of their creators. FGFS is not a commercial program that locks all, but it is a platform under the guarantee of freedom of the open source licenses.

[Hooray]

There are quite a few misconceptions here - the XML interpreter processing PropertyList XML file is using EasyXML (SAX), but it has zero to do with any Nasal code embedded in XML files - that's separately handled by the corresponding subsystem, which has to specifically look for a corresponding tag, get out the source code, compile it and run it (think GUI dialogs, joystick/keyboard bindings etc).

So, Nasal code and XML have little/zero to do with each other - so that 90% of the assertions you are making here are simply plain wrong.

Replacing/augmenting FlightGear scripting (via Nasal or not) has nothing to do with the way XML is handled - that part is very minor in comparison to all the other challenges we outlined in the other topics - it really is the equivalent of 5 lines of code to support another script/FOO tag, that is trivial to do.

The meat of it really is the IPC part, as Richard and others mentioned - if you don't understand why that is the case, you are really wasting your own time coming up with these postings (and diagrams), because you are missing the full picture - anybody familiar with these internals will confirm that the XML part supporting Nasal (or Python, Lua etc) is not at all problematic - and actually, even the Nasal FAQ mentions that, in fact Melchior himself mentioned that in a number of responses in the original debate.

As a matter of fact, I encourage you to review these debates, or at the very least, the corresponding wiki articles summarizing them - because you are missing some very important background information.

[curt]

It would be close to trivial to write a json -> property-tree loader and property-tree to json writer. Once this is in place, an xml2json conversion script would be only a handful of lines of code. (Load the xml into a property tree, save it out to json.) So yes, nasal is tied to the flightgear property tree in order to interface with other flightgear subsystems, but otherwise has no connection to xml.

Also keep in mind that nasal scripts are executed sequentially when their call back is triggered or the place in the c++ that references a nasal script is reached. Nasal scripts are not executed concurrently (and referring to them as a process and drawing a bunch of those side by side would be misleading in that respect.)

The "generic interface" you have drawn in your diagram *is* the flightgear property tree. The property tree is the bridge between config files (currently xml) saved on disk, the C++ code, nasal scripts, external IO, 3d model animations, cockpit animations, systems modeling, etc. etc. etc. If you want to add support for another scripting language simply build an interface to the property tree and add hooks (wherever appropriate) to execute your scripts. If you want to add support for json, toml, cap'n proto, protocol buffers, bson, win.ini, or what have you ... just build read/write functions to the property tree.

xml was the thing when we first set this up. It is a little verbose, but we are talking a few bytes of disk storage so it's really not much of a downside. We aren't using this to send data between processes, so if the format is buried beneath a load/save function, niggling about syntax is pretty arbitrary, there isn't really any functional or performance problem with xml we need to solve here. json is a subset of javascript so it is really sensitive to syntax errors ... personally I find it easier/safer to hand edit xml than json ... that's just me though. That said, I think json actually maps a bit more cleanly to our property system, so maybe some day converting all our xml to json could be another topic of discussion here.

[Hooray]

Nasal's hash syntax is already close enough to JSON that Nasal could even serialize a property tree without requiring much work, analogous to props.getValues() which is already traversing a property tree node and which turns it into a Nasal data structure (hash).

Like Curt said, there is no concurrency when it comes to Nasal - not that it is impossible, Nasal does support threading (and has no GIL), but the FlightGear side has no/little support for accessing the corresponding APIs concurrently (from multiple threads), you would need some form of serialization to make that possible.

And as a matter of fact, whenever Nasal "hooks" (e.g. scenery related Nasal code) was triggered from a different thread due to some threaded OSG machinery, this was usually causing race conditions, i.e. hardly reproducible segfaults due to Nasal code being called from another thread.

The Property tree is the primary IPC mechanisms between most FG/SG subsystems, with only very few subsystems having other means to communicate with the rest of FG, such as e.g. Nasal which is also using extensions functions and higher level classes/objects (think Canvas).

Apart from that, there are full APIs modeled, and exposed, on top of the FG property tree using the notion of listeners that "parse" a subset of the tree for certain "events" (such as properties being written/updated that have certain names/types), which is how the AI subsystem has become so powerful, and sccriptable, despite not having a single dedicated scriptable API.

Under the hood, that is also how the Canvas system works.

The way FG is using XML it HAS to be so verbose, and it has to be a subset of XML, because it needs to map nicely to the PropertyTree structure at runtime (and vice versa).

Adding support for another scripting language has extremely little to do with XML, the grunt work has to do with the property tree, fgcommands and other extension APIs - and when it comes to "concurrency", you definitely need to have a sane form of IPC to begin with.

But again, Nasal is much more ready for multithreaded programming than FlightGear is - while the corresponding APIs are fairly low-level, they actually work ALREADY

Converting XML to JSON would not be difficult - but I highly doubt it's worth it.

[abassign]

There are quite a few misconceptions here - the XML interpreter processing PropertyList XML file is using EasyXML (SAX), but it has zero to do with any Nasal code embedded in XML files - that's separately handled by the corresponding subsystem, which has to specifically look for a corresponding tag, get out the source code, compile it and run it (think GUI dialogs, joystick/keyboard bindings etc). ...

Indeed my premise was right in saying that I was not sure of the diagram, but at this point it might be something "good and fair" make a diagram, by those who know the code, which finally explains this part of the system . I think a little of system documentation is not bad.

My question at this point is this:
Working only on "Properties tree" you can do anything you can to make the XML or NASAL inside of files that describe any plane?

Greetings

[Hooray]

The first step of loading an aircraft is loading its -set.xml file, which is then processed and turned into a property tree data structure, which is then processed by various parts of the initialization sequence to actually "build" an aircraft and load its resources (3D model, textures, nasal, bindings etc).

Anyway, all of this is extensively covered in the wiki, and I think you would be well-advised to review such details before making certain suggestions - otherwise you're really just wasting your time, because almost everyone and their dog can tell that you are just juggling abstract ideas without having taken to understand the actual situation at hand.

[curt]

abassign: feel free to ask well crafted and specific questions about how the system works and we will do our best to answer them. I have trouble parsing/understanding your most recent question. Perhaps you could contribute some documentation as you better learn the specific details? I agree that full and complete documentation would be ideal to have already, and many of us have not documented our work as well as we could have or should have, but we are all busy, and here we are. Documentation can be a great place to contribute so that the next person who comes along doesn't have to go through as much work as yourself. I would also like to mention that documentation is hard to do and any time you write, you have a specific audience in mind. So perhaps the documentation that does currently exist isn't helpful to you from your starting point, but might be helpful to someone else starting at different point? It's really hard to write documentation that answers everyone's questions exactly the way they need when they need it. And if you do write a document that does answer everyone's question at every level of experience, you risk the documentation growing so large the no one can find anything and you are back to square one of not having workable documentation!

Best regards,

Curt.

[abassign]

The first step of loading an aircraft is loading its -set.xml file, which is then processed and turned into a property tree data structure, which is then processed by various parts of the initialization sequence to actually "build" an aircraft and load its resources (3D model, textures, nasal, bindings etc).

I love to have fun, but not in these things, if information is missing ... missing, if the information is buried under mountains of papers ... are buried in mountains of papers. My question is perfectly logical, is not a game, what you do when you talk like that to whoever asks you a specific question on a specific question, if you know then answer or do not know well, as they say IBM ... "I'm going at informing." But to answer so, as you have answered the question, not deliberately saying absolutely nothing, is proof that you are a person absolutely arrogant. I do not like the arrogant, so avoids responding if your spirit wants to answer with this nonsense, totally different from my question.

[abassign]

abassign: feel free to ask well crafted and specific questions about how the system works and we will do our best to answer them. I have trouble parsing/understanding your most recent question

I understand your answer and I appreciate and understand the difficulty, code development, and I have directed the working groups within the SW for various application areas both scientific and commercial and I know the difficulties you've told me.
So if I have a plan to do something I do some, in my opinion, basic questions that allow me to see if it makes sense to continue on a certain way.
If I think develop a bit of software in a certain language to modify a certain development model that I think improved, before I ask, who knows much better than me the program code, a few points that I consider binding.
Moreover I think that my question is generalized, in addition to the Erlang language, even for a possible application in Python or Java. It is clear that in my mind is being born the idea that with a few lines of code you can generate interfaces that can, with efficiency, replace the XML and NASAL without reducing performance.

Reasoning on the various pieces of information that I had today, I found perhaps the real point on which depends the ability to easily make this change:
"Working only on" Properties tree "you can do anything you can to make the XML or NASAL inside of files That describe any plane?"

Surely it is too synthetic, but it means that you can fly a plane, to operate the various effects, etc ... you can do it by only changing/inserting the "Properties tree" params ?

If so, and there are no "secret routes" that alter the diagram I have shown before, then this change is relatively simple, if not even immediate! Otherwise, if it were not so, it is an issue that really gets inside the kernel of the program, and then the programming effort is too high for me, but also for the desire that demonstrate some kernel developers.

To this question I could certainly answer from me, looking at the code, and after a year maybe say, "we can not do"! If instead of wasting one year to say I can not do. I think is better to lose ten minutes to ask the question and hope someone can give a good answer

[psadro_gm]

Ah, erlang - I worked for Ericsson in the early 90s. Memories.

I feel the obvious answer to this is - erlang requires compilation. Do we want to ditch scripting all together?

[Thorsten]

the idea that with a few lines of code you can generate interfaces that can, with efficiency, replace the XML and NASAL without reducing performance.

Ah - magic...