Hound dog departed

[bomber]

https://en.wikipedia.org/wiki/Filibuster

[KL-666]

So the request from Curt to allow a conversation to take place has resulted in Thorsten and Bugman talking shit...

Yup, Bugman introduces the very denigrating notion that the original poster lives in fantasy land here:

https://forum.flightgear.org/viewtopic.php?f=30&t=30606&sid=2e8fe8dd1457b650a94da777e82207c7#p296174

And then he and Thorsten go on for a while kicking the newcomer deep down the mud on this notion.

It is extremely unwelcoming for a newcomer to be treated like this by the established gang of bullies. But what is even more worrying is that a referee not only participates in the gang, but even initiates bullying. An organization with such partial referees is doomed to demise into a small club of single minded people who only encourage each others bad decisions. No good product can come from such organization.

Kind regards, Vincent

[IAHM-COL]

Once again, the beaver's comment are (in my opinion) spot on

https://forum.flightgear.org/viewtopic. ... 15#p296208

I'm mostly using things like Numpy and Pandas, just like many people in the aerospace industry I know. So I don't fear my judgement to be as questionable as you might think. Also, not everybody wants to learn how to master a niche language which has no appeal other than being integrated into FlightGear. I don't get why it should be comforting that experts with years of experience in Nasal and FlightGear are able to do full-featured orbital dynamics in it. I'm not an expert at Nasal, and I don't think it's worth it or even necessary to become one.

I totally understand that Nasal is ingrained in FlightGear, and that it is not going anywhere. But that's precisely the problem. If you wonder why there is a lack of core developers for FlightGear, why people build more free or open source extensions for FSX than for FlightGear, and why for example Blender Addons proliferate like crazy, you only need to look at what is necessary to build good extensions in FlightGear and how hard it is to instruct users how to install 3rd party scripts. Of course it's doable, but at a high cost of frustration. These factors matter.

Neither is this about following "the latest and greatest". Python (also Lua and Javascript) has been great for more than a decade now, and the scientific programming ecosystem is mature and popular. Including in domains where there was only Fortran before. Could you do everything in Fortran? Surely. Is it as much fun? Are you iterating as fast? Is it accessible to potential contributors? Probably not.

I still believe that Nasal is a big factor holding FlightGear back. That doesn't mean there is a way out of this situation with or without ditching Nasal. Hypothetically, and I know this is just speculation, I believe FlightGear would be a better project today if it had chosen Python or Lua at the time. I can't prove it, of course, other than comparing the history of FlightGear and Blender, just stating my opinion.

[bomber]

The replies are leaving me speechless..... I'm starting to think that FG development is so entrenched that change is impossible.

There's a palpable emanation of fear about breaking FG being used to deter people thinking too hard about it.

It's a shame this is being used instead of encouragement of new ideas run alongside existing FG ..

FG is simply too big, too long in the tooth.

[Lydiot]

I think there's something that bears remembering though, and that's the difference between adding content external to the main application like you guys are doing (thanks) with FGMembers, and coding the main app itself: The difference being that the add-on materials are, well, easy to add on, whereas the main app's coding is done by a few people, and unless they all agree to switch over their view is a self-fulfilling prophesy.

Or in other words, nobody but the core is going to bother changing the code, and so if nobody does it, it doesn't happen. I don't code, so I'll just take people's word for other options being technically better, but at the same time I have to say I fully understand that people don't want to sit down and rewrite thousands of lines of code to a different language just so that a few people that currently aren't supplying code to the project think it's better. I mean, it doesn't even matter if it'd put the project in an ultimately better place if the people who are writing core code simply don't have the time.

Another way of looking at it - and it is a problem for sure - is that if Coder X has 6hrs per week to spend on this, then what's the best way to utilize that time? For him it's probably more rewarding to code a new feature or tweak and improve an existing one, than it is rewriting old stuff. So, with only 24-30hrs per month to work with, why would he want to embark on this massive rewrite that'll take a really long time during which he might not output anything else of practical working value?

[KL-666]

Everybody is always panicking about rewriting all nasal in each and every plane. I take a different approach to migration. Temporarily support both languages, until the old one is phased out. There are ways to run the old language in a sandbox for a while without causing much work for the core. But the current core wants to be blind for that and falsely or out of ignorance pretends all nasal in every plane needs to be rewritten before migrating.

Kind regards, Vincent

[IAHM-COL]

Last time I read about python in the devel list, it was actually buggy-boy suggesting to include python parsers as "alternative" to nasal.
The whole thing was shut down in the devel list with the argument of safety. (Again, I am totally non-understanding, what is this security issues that are making FG almost unable to run in most configuration that deviates from the default configuration).

The reality is I am utterly confused
1. Is Thorsten saying that including python scriptability is a total unnecessary mess because we already have nasal? as in: learn nasal or begone?
2. Is buggy boy suggesting that python within FG is "fantasy-land", but at the same time pursuing this on his own fork? and now asking beaver to work for him on that goal?
3. What are Hooray's points again? Yes/No? it already works? Drop the idea? Implement it yourself?
4. Why has no-one brought up the point that python support has recently been vetoed on the argumentation of security?

https://sourceforge.net/p/flightgear/ma ... /34787850/

Hi,

After some long forum discussions [1], followed by some private
discussions with Curt about his own Python property system
developments, I have written some code that might be of general
interest. This started as an experiment to learn more about the
design of the complicated Python object data structure, but it has
expanded somewhat. The code is currently for experimentation, as only
the property tree is accessible. It is written to be compatible only
with Python 3k, as py2 support is not needed for an interpreter
compiled into the fgfs binary. The changes can be summarised as:

- A new FGPythonSys subsystem which initialises the embedded
Python interpreter. This is modelled on the FGNasalSys subsystem, but
with modifications for Python quirks (e.g. execute Py_Initialize()
twice == segfault).

- FGPythonSys support for reading both external and inline Python
scripts from the "/python" property tree path on initialisation (and
reset). This means that <file> and <script> XML tags within <python>
tags can be added to aircraft or other objects to execute Python
scripts. Inline scripts are detabbed prior to execution, based on the
amount of leading whitespace on the first line.

- The Python property tree for accessing the property nodes. This
data structure uses a custom recursive object design to build Python
Node objects on the fly and only when they are accessed. This design
should be one of the fastest for accessing the property tree via the
Python/C interface. It implements a large number of the allowed
Python operations through a mix of C/C++ [2]. A compressive list can
be seen in action in the test.py script [3].

- The Python prop_tree module which contains a few useful
functions [2], and can be imported with "import prop_tree". The
module also contains the prop_tree.Props class which is initialised
once on FG startup and placed in the Python builtin module. Therefore
the property tree is accessible in all Python scripts instantly as the
'props' object. And the prop_tree.Node class which implements the
Node objects. The Props and Node classes never need to be imported.

- A Python data structure to property tree path translation
system. This includes "." to "/", "__" to "_", and "_" to "-".
Therefore props.underscore.a_b__c_d__e corresponds to the path
"/underscore/a-b_c-d_e".

I have added a CMake flag ENABLE_PYTHON so that the Python support is
optional. The current version of the code is in:

https://sourceforge.net/u/edauvergne/fl ... r3/~/tree/
https://sourceforge.net/u/edauvergne/si ... r2/~/tree/

More details are below [4]. Additionally there is a test aircraft -
the py-ogeL, a copy of Torsten's ogeL with <python> tags and scripts
added:

https://sourceforge.net/u/edauvergne/co ... thon/tree/

The py-ogel included test.py Python script is a complete test suite of
the current state of the Python property tree [3].

One problem I am having is with debugging segfaults on reset. The
issue is that these segfaults happen on the HEAD of the next branch,
so I cannot tell if I am introducing any additional problems. Reset
FlightGear enough times and a segfault will eventually occur.

Another thing I am worried about is racing. I cannot find a locking
mechanism for the FlightGear property tree. Therefore racing
conditions could definitely occur. Manipulating the property tree on
the C++ side often involves calls to a series of SGPropertyNode
functions, but the property node value could change during the calls
triggering a race. But the problem seems to be a general FG problem
rather than being specific to this Python subsystem implementation.
Have I missed something important?

Would anyone be interested in playing with this FGPythonSys
implementation? Even though this is experimental and currently quite
limited, I would like to have this optional feature considered for
inclusion after the branching of the next release. The eventual aim
is not to replace, or rather compete with Nasal, but to provide a
clean Python API interface for people to write FlightGear code and
subsystems in pure Python (very likely using HLA as a subsystem
interface and as a way to work around Python's global interpreter
lock).

Regards,

Edward

As discussed at https://wiki.python.org/moin/SandboxedPython , it's hard
to embed Python without giving the scripts it runs full access to your
system; hence, I wouldn't make this available to aircraft/scenery.
(Nasal avoids this security problem by having its I/O functions only
allow access to a limited range of files.)

It could still be good to have available for local experimentation, but
should be clearly labelled as insecure.

Many posters were chiefly enthusiastic about Python because of the many
libraries that can be used. However, I'd much like to avoid a situation
like 'If you fly this plane, you in addition have to install Python libs X
and Y, if you fly that plane it requires lib Z - oh, and that custom
scenery uses lib Q for animation of jetways,...' - I trust you see the
picture.

https://sourceforge.net/p/flightgear/ma ... /34789666/

The security issue is that I expect FlightGear aircraft and scenery to
be "content", i.e. safe to use even if I don't trust their authors with
all my files, not "executables" (such as standalone-Python scripts),
i.e. unrestricted so only to be installed from trusted sources.

I agree it would be access as the FlightGear user and not as root, but
that's already enough for the common home-user-targeted forms of
malware. (And it might be remotely exploitable: last time I looked,
Terrasync was un-authenticated, which is fine for a content-delivery
channel but means it shouldn't be used for executables.)

Inkscape, Gimp, etc only expose their scripting interface to plugins,
not image files (i.e. the equivalent of giving FlightGear a Python
interface but not allowing aircraft to use it, which I don't object to);
Blender has an option to allow scripts in model files, but it is off by
default

https://sourceforge.net/p/flightgear/ma ... /34790653/

So what are we really trying to solve:

Is Nasal somehow conceptually flawed, limited, not secure enough, i.e. are
we trying to overcome a genuine limitation?

Do we have genuine use cases of libs which are not coded and would take
too long to code in Nasal?

Are people just uncomfortable learning a FG-specific scripting language
because it's 'useless' otherwise?

Do we in the end want a scripting language that is more widely used just
because it is more widely used (which is a disadvantage if you think of
malicious code), because we hope to re-use other code, because there's
less transition time learning a slightly differently syntax?

Lets just say if I end up for months having to fix e.g. AW because the
translation procedure to language XY wasn't perfect and we did this for
the sole reason that some people prefer the syntax of
Lua/Python/Anaconda/... over Nasal, I am going to be really unhappy.

[IAHM-COL]

https://forum.flightgear.org/viewtopic. ... 83#p289080

To keep the FGPythonSys experiment current, I have pushed another set of branches rebased on the main repositories, as of today:

u-edauvergne-flightgear python/r7 branch
u-edauvergne-simgear python/r5 branch
u-edauvergne-fgdata python/r3 branch

It also seems to me that by buggy-boy keeping his side project he is maintaing

a hostile fork!!

Or else, what exactly does it mean not accepting the consensus of the core group, and having a fork against their stated intentions (here of the actual core?)

[KL-666]

Do we in the end want a scripting language that is more widely used just
because it is more widely used (which is a disadvantage if you think of
malicious code)

This is such a scribblers argument for security. Obscurity is not security. Everything you program must be secure, no matter how obscure it is. No wonder half every governments automation lays open to the streets, because it is built by guys like Torsten who think: If i hide it, they can't find it. Wrong!

Kind regards, Vincent

[Richard]

I'm starting to think that FG development is so entrenched that change is impossible.

Everyone knows that the FlightGear core is monolithic and needs some serious work; there have been discussions going back years about how to fix it; but the problem is the same as with any established code base; you have to support all of the baggage or break compatibility. Breaking compatibility is not really an option; look at the fuss when old stuff stops working; or when a new launcher is introduced.

Change isn't impossible; it's happening all the time, just slowly as time permits. The next big changes (that I'm aware of) will likely be scenery and HLA (if these get finished).

It's a shame this is being used instead of encouragement of new ideas run alongside existing FG ..

Firstly the actual idea of adding python to FG isn't new and it has been discussed already. I don't see that python would bring anything really that special; I'm not going into the advantages and disadvantages with python as it's already been discussed at length in the forum and on the list.

There are lots of ways to achieve what the OP is looking to achieve; sockets, logfiles, httpd. Years ago I wrote a Java library that would interface to the properties over some sort of socket to allow external control; this took me a few hours - it'd probably be just as easy in Python. So for me the language side isn't an issue. Nasal isn't exactly hard to learn at a basic level.

FG is simply too big, too long in the tooth.

Which ironically enough is one of the key reasons for using it. There is so much stuff in there; and a lot of it has been well thought out and done right. There are some dubious bits and it's not perfect so I'm not saying that there is no room for improvement, of course there is, it's just that adding Python isn't even on my list of things that I'd like to see in the core. I think it's understood that Python might be neat, but also that it belongs outside the core interfaced via an appropriate method.

Good ideas are best discussed and then expressed in working code samples. Some ideas aren't good after discussion and when you've seen them running and it all goes horribly wrong. Sometimes one has to accept the opinion of those who know the code best, or to prove their opinion was wrong by writing code.

Finally; does anyone actually think that removing Nasal is a good idea in terms of modelling / models ?