Encrypted aircraft dynamics

[Philosopher]

Lol, I don't know either Java or Ada, but I just heard about Rust today: http://www.rust-lang.org/. Concurrency support anyone?

[Hooray]

right, concurrency support in Java cannot really be compared to Ada tasking, protected types and having well-defined interfaces for interaction between threads (entries).
But the number of people familiar with Ada is probably relatively low in comparison to the number of people familiar with C-like languages like C++ and/or Java.
For FlightGear even a purely functional language would be a good choice.

Regarding the Fortrant comments above, it would not be too difficult to write a Nasal parser to support a subset of Fortran (e.g. F) if someone really wanted to take advantage of its expressiveness - Philosopher even has working code to hook into, and access, VM internals - including the OP code generator itself - which would basically make it possible to implement things like Fortran (or even Forth) on top of the existing Nasal VM without it having to involve any Nasal syntax at all.

Overall, it's unfortunate that there's only a tiny fraction of FlightGear written in Ada (i.e. a single FDM) - otherwise, FlightGear could easily be more relevant to industry leaders in the aviation/aerodynamics, but also realtime simulation world. However, given that there's ongoing work on HLA, it seems foreseeable that there'll be better ways to interface Ada code with FlightGear. Somewhere in the OpenRTI sources, Mathias specifically invites people to help provide OpenRTI bindings for Java and Ada.

Basically, people doing professional real-time simulation will not be bothered too much by a niche language language like Nasal, but will be much more affected by FlightGear's much more dominant C++ issues, especially the way the threading architecture has never been formalized (as can be currently seen on the devel list), but also the way all systems/scripts are running right in the rendering/main loop.
Ada would really only help with the main loop itself, but for general purpose concurrency, it would make sense to use OpenCL bindings for better parallelism - while those could still be exposed via Nasal, people would have no easy way to mess up concurrency that way because OpenCL forces you to think about the problem.

Kernel threads are too low-level as a concurrency primitive for any non-trivial application - which is why people tend to come up with all kinds of design patterns to encapsulate different kinds of threading models and to better understand how these can interoperate - which is why there are more and more languages that have native support for parallelism, and synchronization, without involving manual mutex/semaphore/join management.

Rust is looking cool - but while it would be great to have a massively concurrent scripting language in FlightGear, that would also increase the barrier to entry quite significantly - e.g. just imagine having Haskell or even Erlang support in FlightGear - there wouldn't be too many aircraft developers writing scripts anymore - and in fact, most people would then find it easier to just add to the C++ code, which is relatively straightforward in most places.

[curt]

Todo list: finish that ada compiler I started in 1986.

[onox]

Todo list: finish that ada compiler I started in 1986.

LOL! GCC already has a very good and free Ada 2012 compiler

[Hooray]

Right, the other good thing about Ada is that it is designed to work well with existing C/C++ code - which is how the GNAT front-end is integrated with gcc's middle/back-end (code generator/optimizer and linker dealing with various tree representations ).
In other words, it would actually be possible to partially modernize/re-implement certain unmaintained C++ code using Ada and still link the whole thing - on Linux, it's fairly straightforward to link a heterogeneous code base that consists of C, C++ and Ada sources - but I don't know about the Windows side of things, where building FG can already be a nightmare.

But apart from Java, and its obvious JRE/GC issues, Ada would probably seem like one of the more obvious candidates for implementing a real-time app/simulator like FlightGear these days, i.e. without being overly "niche", but even pretty relevant to aviation/avionics manufacturers who are likely to already be familiar with Ada-based projects - the syntax is straightforward, almost BASIC/PASCAL-like .

And Ada has also ben getting quite some mention on the OSG mailing list, for pretty much the same reasons that people keep mentioning Ada on the FlightGear devel list:

http://osdir.com/ml/graphics.opensceneg ... 00390.html

since
threading in OSG has been a critical issue, I thought I'd bring it to the
attention of
others and see what they thought.

That's an old problem rooting to the fact that C++ standard does not
have notion of multiple threads. It turns out that just hawing wrapper
for some OS threading API (and that is what OpenThreads and POSIX are)
is not enough for consistent multithreaded program. Currently, only
java has it right (from 1.5 ))
The good thing is the solution is in on the horizon (possibly in C++0x).

http://osdir.com/ml/graphics.opensceneg ... 00391.html

Anyone here remember Ada?

When I learned Ada, I was working for a real-time company that had a platform with support for Ada. The Ada run-time has a scheduler (as all threading run-times require), which was implemented in pthreads, which also had a run-time, which was implemented with ligh-weight kernel threads on the real-time OS. So, to be able to get the scheduling to work the way you wanted to, you needed to manage your thread a three different levels. Ugh.

But this brings up a the point (might as well slaughter English also): Threads ain't a Library and Threads ain't a Language. The essence of threading is found in a run-time scheduler, which is an executable that runs either inside an OS kernel, or runs in user space. That scheduler could be written in FORTRAN for all we know, but it exists as an executable piece of code. The "Threads" themselves are nothing more than data structures that contain information the scheduler can use to manage them and run them in some order or priority. Sometimes these can be run on parallel hardware and a good thread run-time will know how to do this, either through or in the OS kernel.

So, the programming interface is what is being discussed. At the heart of it, the API does little more than provide a way to modify the data structures that contain the threading information and communicate with the treading run time. This can be done with a library of subroutines, or a compiler that compiles a parallel language into code that modifies these data structures and communicates with the run-time.

One approach hands you a gun and asks that you learn how to use it and the other provides you with a restricted environment with lots of red-tape to insures you make no mistakes.

When it comes to software, it is a battle of survival. As a developer, I favor standard methods that allow me to develop cross platform applications without the need for platform specificity. It looks like HP labs is reinventing a wheel and that's OK. If it becomes a widely used standard I'll adopt.

Otherwise my faith in it goes as far as the credibility of the subject line.

And now, compare this to FlightGear related job openings like these:

There must be 20-30 jobs they are looking to fill. If anyone is interested,
contact me off line and I can get you more details. They are looking for
mechanical engineers, software engineers, systems engineers, and even a
couple co-op students. I believe they deal with military contracts so USA
citizenship would be required. They are looking for graphics/opengl
programmers, C/C++ programmers, even some fortran/ada, linux, unix,
networking, cockpit systems, avionics experience, there appears to be some
manager/team leader level positions, real time software, geospatial
databases, physics, etc.

In other words, increasingly adopting Ada in FlightGear would probably not even be such a bad thing, as long as the build system can deal with (i.e. cmake) and people on Windows find a good way to still build FG

[hvengel]

No. I am not going to get involved in a discusion about modern day computing, which is way over my head.

It is a shame that a few lines af Fortran from an old autopilot of mine now take up a few pages of XML. (i.e. Just the same as it did in machine code when I tried to hand optimise the compiled code )

Such is progress.

Alan

About 8 months ago I translated a FORTRAN gun sight lead computer algorithm from a 1974 paper published by the US Air force Academy into NASAL to create a generalized lead computer for use in FG. This turned out to be fairly straight forward to do and NASAL handled this nicely in spite of not having worked in FORTRAN since the early 1990s.

Most of the "issues" where related to interfacing the translated FORTRAN algorithm to the needed inputs/outputs in the property tree. The basic algorithm turned out to be nearly the same number of lines of code in NASAL as the original FORTRAN subroutine but I was able to translate many of the original 3 and 4 character variable names (cryptic) into more meaningful variable names in the NASAL translation so the code is actually easier to read/understand in the NASAL version. The translation and interfacing work took about 2 full days (IE. around 16 hours) and only required minor debugging to get it working once the basic coding was done. So going from FORTRAN to NASAL is not difficult and it does not have any of the verbosity issues of using XML.

The fact that FORTRAN is not supported by FG was at most a minor issue in this case since a large part of the work involved interfacing the algorithm to FG and even if FORTRAN was directly supported this interfacing work would have still been necessary.

I can't comment on the autopilot XML since I have not used it for more than minor stuff.

[onox]

Right, the other good thing about Ada is that it is designed to work well with existing C/C++ code - which is how the GNAT front-end is integrated with gcc's middle/back-end (code generator/optimizer and linker dealing with various tree representations ).
In other words, it would actually be possible to partially modernize/re-implement certain unmaintained C++ code using Ada and still link the whole thing - on Linux, it's fairly straightforward to link a heterogeneous code base that consists of C, C++ and Ada sources - but I don't know about the Windows side of things, where building FG can already be a nightmare.

In other words, increasingly adopting Ada in FlightGear would probably not even be such a bad thing, as long as the build system can deal with (i.e. cmake) and people on Windows find a good way to still build FG

With GNAT you usually create a simple .gpr file and then gnatmake does all the hard work for you. I'm not sure how integration with cmake would look like.

[Tomaskom]

In some ways this is true, but still, Nasal is very limited, it is like going to back to the stone age, having to fight with sticks and stones. Some tiny problems I noticed for example is that you cannot do setprop("/some/property", true) or return true. You have to write A <= B and B <= C instead of A <= B <= C. No proper API for manipulating data structures and regular expressions

This probably depends on what you're used to. I have mainly C/C++ background, the only really high level language I know "well" being Wolfram Mathematica.
I find Nasal to be really easy to learn and use. Those tiny problems you mentioned, the boolean values - why not simply use 1 or 0 instead of true/false? Setprop handles it as you expect if the target property has the bool type. And about the other missing features you list... Remember that Nasal is supposed to be tiny extension language, not something huge like most languages with advanced features are!

You might like to read this (Design document): http://plausible.org/nasal/doc.html

I have to say that Nasal seems to me as an ideal language for extending FlightGear

[Bomber]

I could spend hours chewing the fat with you guys about flight modelling, not the stuff the professional aerodynamics experts with master degrees talk about here but actual 'flight'.... You know getting to grips with what happens at this point and that point, where the forces and moments are during a flight...

But it wouldn't get us anywhere...

What flightgear need is to listen to flight modellers, not preach to them, about this language or that language.... get over yaselves programmers.

Flighgear should have concentrated on a single flight-modelling engine JSBsim.... It should have focused any C++ skills it had on working with JSBsim in a divergent yet co-operative path to enhance flight modelling specifically for Flightgear,

As it is a flight modeller like me first has to learn xml and jsbsim and the implementation of it here at flightgear... We also have to get our heads around aerodynamics, piston, prop and jet engine physics .. So we have enough on our plate. But what takes the biscuit is the disconnection between FG and JSBsim communities with it comes to highlighting an issue... Because either both parties wash their hands saying it's the other parties responsibility or the response is " If you want it fixed go learn C++"

Well how much of team working is that ? I'll tell ya......none !

Flight modellers would create for you the best flight models, but when they identify a problem with the tools they work with they're then instructed by the people who know C++ and could fix it to go learn C++ them selves, whilst they themselves do other more 'meaningful' work for FG....

Well the sign above the door for this forum says how important flight modelling is in a flight sim... so tell me how come the other work is more meaningful for those that preach to us about which programming language is best ?

Wake up an smell the roses guys

https://www.youtube.com/watch?v=2HaeWQPg40w

https://www.youtube.com/watch?v=8saphXmNvXc

Oh yes that IS multiple iterations of JSBsim working at the same time you're seeing

Regards

Simon

[onox]

Flight modellers would create for you the best flight models, but when they identify a problem with the tools they work with they're then instructed by the people who know C++ and could fix it to go learn C++ them selves, whilst they themselves do other more 'meaningful' work for FG....

Well the sign above the door for this forum says how important flight modelling is in a flight sim... so tell me how come the other work is more meaningful for those that preach to us about which programming language is best ?

Of course flight modelling is important, but so are the aircraft systems. And just like you I identify problems with the tools I have to work with (Nasal)...

[Bomber]

"Good sims require good FDMs (the "thing" that makes an aircraft behave like an aircraft)."

"Modeling aircraft systems, like electrical stuff, hydraulics, pneumatics? Feel free to ask support."

It's not an individual issue , it's an issue as a community..... ya took ya eye off the ball.

[Hooray]

• not sure if we can expect people to adopt gnatmake over cmake
• if you want to use true and false in Nasal, here's the required secret code to make it work:
  

  Code: Select all

  var true = 1;
var false = 0;


• regarding Bomber's comments: It's worth keeping in mind that JSBSim and FlightGear are separate projects - while a few core developers may be involved in both, both projects are separate, and there isn't much coordination going at all - whenever "JSBSim" (aka Jon) has attempted to formalize things and establish "standards" there was little, if any, feedback from the FlightGear side - mainly because all the standardization would take out all the fun ... but people doing this professionally, obviously need to work in terms of standards and interfaces - as you can tell by looking at some of Jon's more detailed proposals (which often ended up getting zero feedback). Unlike FlightGear, JSBSim is very much relevant in the professional industry, not just for visualization purposes, but for actually solving concrete problems - FlightGear is being developed very much like a "toy" in comparison and there's not as much consistency involved unfortunately - to see for yourself, just look at the excellent JSBSim reference/development manuals.
• Likewise, it isn't feasible for FlightGear to focus on a single FDM engine - variety and diversity are technology enablers, and making FlightGear dependent on a single external project would not have been particularly wise, no matter if it's open source or not - we've seen what happened when FlightGear depended on PLIB and PLIB got stalled - it took years until a few developers stepped up to address this issue and actually port all the existing code and adopt another scene graph: OpenSceneGraph (OSG). While OSG is certainly far from being dead, the few people involved in making this change happen, actually prefer encapsulating such dependencies, so that future scene graphs can be more easily supported:
  

  The reason is to have something self contained here.
  Sure we already rely on osg at many places. But if I build an aplication on
  simgear, I hope to have simgear classes there. SGProperties are simgear
  classes, and if you use the property system you may not want to rely on osg.
  
  ... also from my past experience switching to an other scenegraph, I would
  prefer to see no osg::.. references at all in flightgear - except some few
  viewer related stuff. But the simulation part of FlightGear should not need to
  know that the viewer runs on osg/OpenGL.
  So looking at SimGear as a utility library for simulation applications, this
  make sense from my point of view ...
  
  So, even if you will need some more glue code, I would prefer to avoid osg
  classes in simgears parts that are not scenegraph related.
  The property system is such an area IMO ...
  

  Seriously, I didn't realize that reducing dependencies on OSG in simgear is a
  design goal. That's fine, but I would really prefer to not think about whether
  I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart
  pointer should be an osg::ref_ptr or an SGSharedPtr or...

• In other words, the people working with, and developing/writing, the actual code are very much aware of what it means to have certain dependencies, no matter if it's a certain scene graph implementatoin, or a certain FDM. FlightGear's way of interfacing FDMs has greatly benefited from the way an FGInterface is established - likewise, FlightGear will benefit from supporting other scripting languages, or even additional scenery engines (like osgEarth). And as currently can be seen, supporting alternate rendering pipelines is another promising thing - these are all loosely coupled methods to explore different parts of FlightGear, without introducing "dead ends" - e.g. these days, YASim is considered a "dead end" by many - even though others suggested years to abandon JSBSim in favor of YaSim - so it is far to easy to draw conclusions based on actual history and developments - it is far more difficult to predict the future, which is why it's a good thing to let FlightGear evolve in parallel. As was said previously, FlightGear's AP system has become much more advanced than JSBSim's internal building blocks in the meantime, and it would actually be a good thing to "back-port" those to JSBSim. Likewise, there are useful extensions to the property tree found in JSBSim that never made it back into SimGear. And JSBSim in particular is much more "religious" about using XML "properly" in comparison to FG.
• On the other hand, JSBSim's scripting capabilities are suprisingly inferior to to anything offered by FlightGear.
• the disconnection that is there between FlightGear and JSBSim is there for a reason: these are two independent projects that will continue to exist no matter what happens to the other project.
• There's a lot of good stuff done in JSBSim that is done "properly" - but that is never adopted by FlightGear - and then there are important features on the FlightGear side, that are never adopted/supported by JSBSim, such as in-sim W&B configuration, run-time resets, in-air starts, flight replays or different startup situations/cockpit configurations. So there are problems on both sides, and the reason those are not fixed is mainly because people involved in either project all have different priorities - what is most important to you, may not matter at all to people able, and willing, to fix it in a few minutes. That's life
• what is "meaningful" is a matter of opinion obviously - there's a certain number of people doing contract work involving JSBSim and FlightGear, and obviously their priorities are hugely different from "yours" - no matter if you are an accomplished aircraft developer or not, and no matter if you're entirely correct about something.

Finally, Outerra is a fairly recent and modern code base - so it isn't exactly fair to compare it to FG, simply because they started over from scratch and they're using a completely different license - while FG has to work with a lot of legacy code, a low number of contributors and within the constraints of the GPL. And the same thing applies to comparisons between FG and XPlane/FSX - things simply change dramatically once there are paychecks involved.
For the time being, FlightGear development simply "happens" and is primarily motivated by "what is fun" - and not by "what needs to be done" (Zakalawe being the most obvious exception to this rule, because he seems to be enjoying doing what has to be done ...)

PS: @Bomber: I don't know what you mean by "multiple iterations of JSBSim" here - if you're referring to "multiple instances" that is indeed great, but it's on of those things that people have been wanting to support in FlightGear for over a decade and it used to be JSBSim restrictions that would make that very difficult - all the FGFDMExec refactoring is fairly "recent" in FlightGear terms unfortunately - and all the people interested in exploring this are no longer involved in FG. But back when I told you (T4T) how to do this in FlightGear, you guys basically disregarded any constructive feedback - these days, running multiple JSBSim FDM instances concurrently is no longer too much work - the necessary steps are well-understood, and people are working towards this anyway - but the way the AI traffic system was originally designed, people would consider FDM-driven AI traffic a huge waste of CPU cycles, which is no longer the predominant consensus among core developers:

Subject: how can I control two aircraft?

Currently, there is exactly one FDM controlling exactly one aircraft model in one session of FlightGear.

We have a very clever guy working on integrating HLA into FlightGear. Once that is implemented, the idea is already there to be able to virtually walk along a number of parked aircraft on the apron, click on any of them, enter the cockpit and go for a flight. But that's definitely still a long way to go.

Torsten

[Bomber]

"you guys basically disregarded any constructive feedback"

Rubbish....... we listened to everything and then came up with an opinion..... one by one.

"PS: @Bomber: I don't know what you mean by "multiple iterations of JSBSim" here - if you're referring to "multiple instances" that is indeed great,"

This is what's wrong... you knew full well what I meant but you wanted to be a clever dick and point out the correct term so as to score some point over me...


Simon

[Hooray]

Your "opinion" is meanwhile proving to have been wrong, which is kinda backed up by you posting videos of Outerra doing what you could have done in FlightGear by following the advice given back then (as in years ago). And no, I didn't know what you were referring to: an "FDM iteration" is just as correct as an "FDM instance" - so technically, you could have been referring to something that I didn't quite understand - the number of iterations per FDM instance basically determine the accuracy of the solver which is integrating usually dozens of times per simulation frame - thus, the use of the word "iteration" was not simply "wrong". Many of us have been wanting to run more than just ~ 100 iterations per FDM run/frame for years, thus your comments made me wonder what you were referring to here.

PS: Watch your language: Gijs is meanwhile watching both of us ...

[Bomber]

http://www.answers.com/Q/What_is_the_or ... lever_dick

http://www.todayifoundout.com/index.php ... r-richard/

Not every thing is about your penis...

I posted those videos not as a slap in the face of FG but as an example of what can be achieved,