Board index FlightGear Development New features

FGPython an propose for Python as an nasal alternative

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: FGPython an propose for Python as an nasal alternative

Postby abassign » Tue Dec 29, 2015 10:06 pm

@Hooray

...you are mistaken, and wikipedia can prove it: https://en.wikipedia.org/wiki/Domain-specific_language


I'm sorry, but my direct experience says you are that you're wrong, however, let us not fall immediately into controversy, otherwise someone closes the post ;)

...Sorry, you have no clue what you are talking about: please look up Nasal implementation, and then google the terms "Python GIL" (=global intepreter lock), and then refer to Andy's comments in the devel list archives.


I'm sorry, but my direct experience says you are that you're wrong, however, let us not fall immediately into controversy, otherwise someone closes the post ;)

spend 2 weeks reading, and please come back making a more informed suggestion, ideally taking into account what has been previously said in this context. Sorry that I won't spend much time responding to the remaining part of your posting, but you are -currently- just ill-informed, so you are better off doing a little homework first, or phrasing your suggestions as questions.


Sorry, but it seems that your attitude is just an a priori rejection. If you want to block those who want to test new ways, you can do it with others, if this is the spirit that guides you I think it is useless to waste time writing in this post.

It seems clear that your attitude is lacking in any collaborative capabilities, your answers are just the esperessione the refusal to understand the need to grow FGFS more consistent with the spirit GPL. If Blender, FreeCAD etc... use Python either as a programming language and scripting, there'll be a reason right ? OpenSource is also open in the knowledge, more respects labor standards there is the possibility that more people will want to work with it.
This is a law of the market which also FGFS must submit, we wants to have new forces can improve it. Not enough to have always the same 3-4 programmers ready to block any possible development.
I think it's useless if your intervention does not produce useful information to a test of this type. Trust me do not waste time trying to block who speaks of these things. If you like to use NASAL, you will continue to use NASAL, nobody says he does not use it, it seems clear. If you want to use HLA, you can use HLA, nobody's stopping you. We're just saying that if we want to use Python what changes to make to the code? Where should be changed, what needs to be changed etc ... It makes you hurt all this? I hope not!
abassign
 
Posts: 791
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Dec 29, 2015 10:23 pm

Are you just trolling ?

For the record, had you read the thread, you would have noticed that I am not opposed to Python support at all, however I am not supportive of it for any of the reasons you mentioned, simply because you are lacking information/facts to make your case - what you stated above is either incomplete or plain wrong, and given that you didn't just pose questions but made specific statements, I think it is only fair to point out that others have literally spent years discussing various related ideas - e.g. the whole "HLA" thing you are discarding is so much superior to your abstract suggestion of... well, simply... not using it.

Quite frankly, you are missing tons of background information that is readily available online, if you don't like the FG wiki, just check wikipedia for starters - where you can read all you need to know in order to prove your theories, or just accept that quite a few of your statements above are plain wrong.

None of that is to say that Python support would not be great - however, the reasons you mentioned are not compelling at all, they're just uinformed as far as I can tell, and you would be hard pressed to find someone familiar with Python, Nasal and the FlightGear architecture taking you seriously.

Sorry, no offense intended or taken though

But you are making the case that people should use Python instead of Nasal, despite others (myself included) having already agreed along these lines - which is plain disrespectful, i.e. expecting others to read your posting, while not reading their's

And again, this is not about "me" wanting to use Nasal, HLA or Python - it is about understanding the impact of using different approaches, the one you outlined is inferior to what has been suggested in the context of HLA and Python. I am just pointing this out, because you obviously cannot be bothered to read what others have written, or to even just look up the corresponding wikipedia articles (HLA, Python, global interpreter lock, garbage collection, multithreading)

We're just saying that if we want to use Python what changes to make to the code? Where should be changed, what needs to be changed etc ... It makes you hurt all this? I hope not!


I am not hurt, I did in fact offer my help to get people going with this (Python support in FG), which is more than you have offered so far - you could have known that, had you read the thread, instead of expecting others to read your uninformed ramblings :D

The links I posted could get you going quickly.

Believe me, I am able to support an idea, without being totally convinced that it is a good thing to do in the long term - which is why I suggested to discuss certain possible challenges, upfront - none of which you addressed above. Obviously, Nasal will never be able to "compete" with Python. The question remains, if it has to though.

The fact is, you need someone able to integrate Python, you need someone familiar with Nasal internals and ideally someone able to hook this up FG in a fashion that the whole thing is not suffering from the same limitations that other SGSubsystems, including FGNasalSys, are subject to. The latter will almost certainly involve HLA, especially if you don't even understand what the Python GIL is about.

Your whole posting is extremely abstract, if not even shallow, i.e. you are ignoring the fact that the limitations you mentioned are not inherent to Nasal (which is designed to be thread-safe without a GIL), but that those are restrictions due to FlightGear's architecture, i.e. its main loop, the proeprty tree and extension APIs not being thread-safe - and those restrictions would apply to a Python SGSubsystem just as well, unless it is implemented separately using IPC/RPC, i.e. HLA.

PS: Your performance related concerns regarding HLA would not even be applicable in an embedded context these days (think mobile phones), you would literally have to use single-threaded 386 generation hardware to see HLA as the bottleneck - is your background possibly in mid 80s embedded systems engineering (retired??)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby curt » Tue Dec 29, 2015 11:12 pm

Hooray: it sounds to me like abassign simply wants to explore building a prototype interface to python, and I can't see any harm in doing some exploration and testing. You and Thorsten enjoy hypothetical debates ad nausium ... there is definitely a great deal of good in thinking things through -- clearly and completely -- ahead of time, but it also starts to feel a bit like a fillabuster when the concerns and debate start ranging into highly pedantic nuance or when emotions start getting a little tweaked. It all seemed pretty good spirited until something went off the rails ... maybe when abassign suggested he might forge ahead anyway to see what he could get working?

Abassign: there are no promises ahead of time that we will roll python integration into the core source code ... especially before seeing actual code and seeing how the integration looks, understanding what parts of the code and build system need to be touched, making sure it can be supported on all platforms, and pondering some of the bigger issues brought up in this thread. But there are a lot of python fans floating around the FlightGear community so I think you could build up some interest, especially if you were able to get some early prototype integration working and show some examples. Maybe in the process you'll stumble on a really compelling or creative use for python that nasal can't match? Maybe in the process you'll stumble on some show stopper problem and we'll learn some lessons. We do have some precident for including optionally compiled features in FlightGear, so if you can come up with a clean integration, but larger objections remain, perhaps we can make it an optionally compiled feature so those with interest can pursue it, and those with concerns can avoid it ... at least for the near term.

As always, there needs to be a balance between thorough design and forward progress ... I've found that overloading on either side can lead to problems. We can debate something to death and decide that it's far too hard to address every concern mentioned, or we design something so extravagant we can never build it in a finite amount of time. Or we can dive headlong with our eyes close and run off a cliff or get stuck in a corner or tangled mess we can't escape from. Neither extreme works very well ... so aim for something in the middle. :-) Having some concrete data or a concrete example to point to can often reign in the far ranging theoretical debates. I would hate to spoil a great debate with an actual working example ... but sometimes these things have to be done. :-)

Both Hooray and Thorsten (as well as many other FlightGear developers) have a lot of personal experience and perspective so it's wise to consider their thoughts and suggestions.

Best regards,

Curt.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Wed Dec 30, 2015 1:59 am

curt and abassign
My idea is a minimal library that support the basic props and canvas api's and the settimer/setlistener/removelistener.
That look like this:
Code: Select all
fgfs
|+canvas # complete canvas api
|+props # the props api
|-settimer()
|-setlistener()
|-removelistener()

And in python code looks like:
Code: Select all
#loading settimer/setlistener/removelistener
from fgfs import settimer, setlistener, removelistener
#loading props
from fgfs import props as props
#loading canvas
from fgfs import canvas as canvas

getprop and setprop is an alias for props.globals.getNode(node).getValues() and props.globals.getNode(node).setValues(value)
My preference is props api above the clasic getprop and set prop.
On a later moment we can port the rest of the interface. (see list here under)
Code: Select all
airportinfo()
airwaysRoute()
courseAndDistance()
createWP()
createWPFrom()
findAirportsByICAO()
findAirportsWithinRange()
findFixesByID()
findNavaidByFrequency()
findNavaidsByFrequency()
findNavaidsByID()
findNavaidsWithinRange()
flightplan()
geodinfo()
interpolate()

The rest of the code can be done in python library’s
www2
 
Posts: 254
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Wed Dec 30, 2015 7:06 am

This is a law of the market which also FGFS must submit, we wants to have new forces can improve it.


There's no shortage of people who code what they need in Nasal - if anything, there's a shortage of GLSL and C++ programmers.

3. Python, unlike other scripting languages, has an almost endless amount of libraries, that help solve problems in many fields of technology. The libraries allow to develop very quickly, otherwise achievable solutions in short times and with a planning effort relatively contained.


... and allow to bloat FG very quickly - from all I've read in this discussion, that's about the least desirable feature about the whole thing.

4. Python enables true multitasking with the possibility of spreading processes on multiple CPUs, this finally makes it possible to overcome one of the major bottlenecks of FGFS!


Just maybe you should make an effort to actually find out where the bottlenecks are?

I try to explain, let's say you have a GPU high performance that generates a complete image in 20 ms, we make the assumption that there are many processes that consume a total NASAL 10 ms, at the end of the frame-rate will be 1000 / (20 + 10) = 33 fps.


No it won't - because the 10 ms of Nasal will run while the GPU does its frame because - wow - they actually work in parallel :-) So your whole example is dead from the start - the framerate won't be 33 fps but 50 fps.

But it is necessary to read the status of a process every 1/33 of a second? Or it is sufficient, for example, do it every 1/10 of a second?


For running flight dynamics, you need to read the status even more often - say 120 times per second. For smooth movement of an instrument hand, you need to read the status once per frame - no more and no less. For updating a digital clock, you need to read the status once per second. For the decision to compute a new cloud scenery, you need to check the status perhaps every 30 seconds.

It really depends on what you do.

Which is why we usually code these tasks at the frequency they need to be done (the loops accept a timer argument...) - yet take care to stagger them across different frames to avoid a high latency. It's one of these things which you need to understand and play with for a while. Definitely not something you should comment on without having some hands-on experience.

I think the best thing is to try to see if the work can be done with a genuine benefit.


Indeed, that was what I wanted to find out from this thread - is Python going to be an enabler, aka does it allow to do things we can't currently do, or is it the same experience we currently have with a different syntax and a new bag of complications?

From what I've read so far, I lean more towards the latter unfortunately.
Thorsten
 
Posts: 10832
Joined: Mon Nov 02, 2009 8:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby sanhozay » Wed Dec 30, 2015 9:53 am

abassign wrote in Tue Dec 29, 2015 8:38 pm:3. Python, unlike other scripting languages, has an almost endless amount of libraries, that help solve problems in many fields of technology. The libraries allow to develop very quickly, otherwise achievable solutions in short times and with a planning effort relatively contained.

I'm finding it difficult to think of parts of Flightgear where development is slowed because Nasal lacks libraries? Do you have specific examples of existing Python libraries that would speed up Flightgear development?
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Dec 30, 2015 12:34 pm

@www2: you don't want to provide problematic APIs like setlistener/removelistener or settimer - but instead use their RAII equivalent, i.e. maketimer() and makelistener() respectively, for all the reasons mentioned by Zakalawe at: viewtopic.php?f=30&t=21185&p=201811&hilit=#p192767

Canvas itself works primarily via properties, so you would inevitably also need to wrap props.nas using native code, and quite a few cppbind APIs, that don't even use the property tree, but which access C++ ghosts directly.

The NavDB (FGPositioned) stuff would be better handled via HLA, i.e. delegated to the process holding the database, see Stuart's recent HLA related comments on the list:
http://sourceforge.net/p/flightgear/mai ... /34725710/
Stuart wrote:James - when you get the chance we'll need the
capability to to have two clients access the NavDB concurrently - I've
hit lots of errors trying to do this


In other words, you could treat the navdb as what it is, a database and deal with it using a conventional client/server approach.

To be honest, I have no doubt that, by adopting Python (next to/instead of Nasal) would significantly boost the rate of scripting that fgdata/fgaddon contributions are seeing, especially given cool stuff like OpenCV etc.

Had we Python support today, we would simply not be facing certain issues at all, but would almost certainly have to deal with other issues, i.e. the sheer rate of adoption Python support would inevitably bring, especially compared with Nasal.

It seems everybody agrees that they don't want "Python the language", but "Python, the sheer number of modules" - however, those cannot be expected to run in a "time-sharing" multitasking environment like the FlightGear main loop, where each Subsystem running will affect the frame rate, and spacing (latency), you are getting.

Which is why you need to use some form of IPC/RPC to ensure that Python can run outside the main loop, or it will be subject to the same issues that Nasal is seeing.

A number of core developers have repeatedly expressed, that they are concerned about the degree of scripting going on in FlightGear, Python would not address that issue, but make it even more prominent, especially given the sheer number of 3rd party modules that people will sooner or later want to use.

With "Nasal", the FlightGear project has a certain degree of control over the degree of scripting going on, once Python is added/supported, scripting in FG would be boosted significantly, and could easily get out of of control if this is not thought through.

So I do think that Python would be a huge technology enabler, but also that it will cause tons of new problems, especially if tackled by people who are not aware of the current system and its limitations.

Which is why I think that it is important to discuss the pros & cons before spending any time coding. Disregarding the HLA/IPC option is not just plain wrong, but also disrespectful towards those who spent years coming up with the infrastructure, code and plans to make this happen.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Wed Dec 30, 2015 1:44 pm

To be honest, I have no doubt that, by adopting Python (next to/instead of Nasal) would significantly boost the rate of scripting that fgdata/fgaddon contributions are seeing, especially given cool stuff like OpenCV etc.


Is there any evidence to support this assertion?

For instance, how many people do you know who don't contribute because they'd have to learn Nasal and don't want to, but claim they would contribute if they could write in Python? And what fraction of people who said they'd contribute if only X have actually contributed once X was realized?

How many actual use cases do you know where development is stalled because there's no XXX Nasal library available (say, matrix multiplication, fast fourier transformation)? And for what fraction of those use cases does it make even sense to script?
Thorsten
 
Posts: 10832
Joined: Mon Nov 02, 2009 8:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Dec 30, 2015 2:17 pm

That's interesting, first I am getting told off for being critical about adopting Python, and now I am supposed to find reasons for supporting Python.

The point was not that I have "evidence" to support my opinion - but it is obviously true that 1) Nasal is a niche language, that 2) is poorly supported and maintained, 3) which does not come with much documentation/examples (please let's not exchange arguments about that, I have probably touched/maintained/written ~80-90% of the Nasal tutorials on the wiki).

I don't think that NOT supporting Python is "blocking" FlightGear development, I am only saying that -given the sheer number of 3rd party modules, Python scripting would almost certainly (inevitably) boost FlightGear scripting.

So I can see the benefits of exchanging the pros & cons of supporting/not supporting Python scripting "in" FlightGear, i.e. you can find me on both sides of the argument, I am just more inclined to think that Python adoption is going to cause certain challenges/problems simply due to the degree of fgdata/fgaddon scripting we are already seeing, despite Nasal being fairly poorly supported compared to Python, referring to documentation, examples, support and 3rd party modules.

You bring up valid questions, and stuff like FFT would obviously not be suitable to be done in scripting space - yet, we have seen such threads on the forum:

Subject: "Image-Processing" or FFT in NASAL/FG ???
St.Michel wrote:Is there generally the possibility to use image-processing-algorithms in NASAL? I mean things like FFT, convolution or a sobel-operator...
This is not only for image-processing of course, but will be used often for this. And it is not only for Images!, also for other 2d-datas like a terrain-representation to detect edges there or so...


That is not supposed to prove anything, but Python is definitely a huge technology enabler given the sheer number of 3rd party modules, and we would be also deluding oursleves by ignoring that fact - heck, even osg is available as a python module.

I am not saying that this is inevitably a good/required thing in FG, just that people are generally more likely to be able to do certain things in Python that would otherwise require tons of C/C++ coding, because of the sheer number of libraries and modules available.

Like you say, it many cases it would not necessarily make sense to use "scripting" - however, the lines are blurred, because these days, you could even use Python to implement an application like FlightGear, in scripting space - i.e. just by making use of 3rd party code (modules) that is using native code under the hood.

The point of this is that adopting Python is not just bringing tons of potential with it, but also causing tons of challenges and issues, because the rate of adoption is likely going to be much higher than Nasal use in FG, which is already considered problematic by many core developers.

Which is also why I am convinced that it would be a dumb idea to pursue a SGSubsystem-based implementation strategy for Python integration, and instead focus on/wait for IPC-mechanisms like HLA instead, at which point Python/HLA could be much more compelling than Nasal currently is.

For instance, had Python support been available in FG, we would almost certainly not have the Canvas system these days, because OpenGL/OSG and OpenCV support can just be "pip installed" easily. But the main reason for the Canvas system to come into existence was that 2D rendering was not available to fgdata developers.

And we did in fact see Python based prototypes using glitz to create MFDs for FG.

I am not saying that this is a good thing, just that this is a possible - and I am seeing not just the potential of that, but also its repercussions, i.e. the lack of oversight and management, which is already hugely problematic for Nasal based contributions - including Canvas MFDs that are not suitable for multi-instance setups, or multiplayer use.

Thus, my assertion would be two-fold: 1) Python availability is definitely going to boost FG scripting, 2) it is going to cause chaos due to the power available to people without having to be familiar with FG internals, i.e. imagine running OpenCV/FFT or numpy code in the main loop by having a FGPythonSys-equivalent of FGNasalSys.

Somewhere down the line, we would then also be facing potential security issues, because the barrier to entry would be significantly lowered.

So I can see the potential of Python scripting in FG, and I am not opposed to Python in general, I am just vary of the repercussions - and would personally be more inclined to favor Lua. But as long as Python is supported externally (via IPC), it is probably the "better" choice.

However, the FlightGear project should be prepared to deal with issues arising from supporting Python - otherwise, I am seeing the potential for huge chaos resulting from all this, especially in an increasingly distributed project were resources and assets are no longer maintained by a single "umbrella entity"
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Wed Dec 30, 2015 2:42 pm

Thus, my assertion would be two-fold: 1) Python availability is definitely going to boost FG scripting, 2) it is going to cause chaos due to the power available to people without having to be familiar with FG internals, i.e. imagine running OpenCV/FFT or numpy code in the main loop by having a FGPythonSys-equivalent of FGNasalSys.


I got your opinion the first time. I still want to know where the 'definitely' comes from. As I said, I'd want to see this discussion grounded in evidence and case history.

Which is to say - what actual thing useful for FG is going to be enabled? It's nice to be theoretically able to write FG in Python, however that's not what we use scripting for - we use it ideally for high-level management tasks which are too complicated to code in xml.

So if all Python would do is enable to do heavy-duty numerics in scripting space, I doubt you'll find open ears for that application. Likewise, OSG as a Python module isn't going to make friends.

Thus - within the reasonable use cases of scripting in FG - what can Python do Nasal can't? If all that Python does is enable misuses of scripting, it's not that useful.
Thorsten
 
Posts: 10832
Joined: Mon Nov 02, 2009 8:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby curt » Wed Dec 30, 2015 3:05 pm

I have grown to really like "python the language." It can lead to very clean and lean (i.e. understandable) code -- for people that care about that sort of thing. I like how it does classes (objects) for those that care about object oriented style programming. Repeatedly asserting that no one cares for the language, just the supporting library may be rolling too much of your own personal view point into the "universal we."

Before I took a hard look at python, I was much more of a perl (and /bin/sh) guy for my general purpose scripting needs. I had trouble looking at python code and understanding the loop and conditional structures. Add python's weird dependence on exact indented white space, and I was pretty skeptical of the language. I assumed the white space rigidity would cause all kinds of problems as code is edited and massaged.

As I have used python more and more, I see that the loop and conditional structures are actually very straightforward. They look a bit different from C-style equivalents, but it's all the same stuff written a slightly different way. After using python a bit it now makes a lot of sense to me. Despite my worries about white space indenting issues, I can remember a grand total of one time that I shot myself in the foot with careless indenting ... and I figured that out pretty quickly. Think about all the unique ways you can shoot yourself in the foot with C (pointers, array overruns, etc.) I've lost count of the times that C/C++ 'features' have caused me to stumble into unexpected stupid bugs. In the grand balance of things, armed with a decent editor that groks python syntax, python indenting is really easy to handle and never was the big problem I expected it to be.

I think that you can often understand how a person thinks and what they value by reading their code. When I look at YASim and Nasal, I see that Andy puts a very high value on compact and simple code. I have never seen anyone else in the world with his ability to pack so much high level functionality into such a few lines of simple looking code. He has an extremely rare gift that probably most people do not appreciate or understand the signficance.

I'm not arguing for or against Nasal here ... Nasal is a brilliant chunk of code that has served FlightGear extremely well. It allows a range of cool things in FlightGear ... from embedding fragments of scripts into 3d model files to enhance their animations to far more sophisticated things.

I am pointing out that personally, for myself, my own perspective, with my computer science hat on, I really like python "the language". Nothing is perfect, but it's very well done from a "language" design perspective. It doesn't guarantee good code, but it enables someone who cares about clean, compact, readable code to pursue those goals. C and C++ can be far more verbose (code-wise) to accomplish the same functionality. It makes it 'tedious' to go back to C++ from python because of all the extra coding details and structure you have to connect together in C++ just to make a basic class work. I think python is a pretty cool language. (I think Nasal is also very cool and very brilliant for some similar and some different reasons.)

Thorsten: just taking a small step backwards to see a bit higher view. We have someone (maybe a few people) that are interested in doing some exploration. They think there could be some interesting things to be found. You are demanding that all the things that will be found in the expedition be enumerated in detail ahead of time and their value measured before authorizing the expedition. It's good to think things through ahead of time, but you don't start an adventure knowing all the answers. Why send a probe past Pluto? What does Pluto have that the other planets don't already provide in abundance? Tell me exactly what valuable things you will find that we don't already have. There has to be balance of course, but no one knows all the answers at the start of a journey ... it's just that some people speak more persuasively and confidently than others. Usually the people that do know all the exact answers ahead of time and can present them in a clear and compelling way ... those people are politicians.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Dec 30, 2015 4:30 pm

I kinda agree with Curt, even though I don't need to be convinced that Python is going to have a major impact on FlightGear scripting.

I do disagree that this is going to be primarily based on the difference in syntax/language, i.e. that the main factor will indeed be the plethora of modules available, and excellent support from a tooling/community and maintenance standpoint.

You need to have tons of programming experience to appreciate language differences like those Curt mentioned, many people are unlikely to have that, and they will just use the "best tool" for the job, especially aircraft developers with little or no background in coding - i.e. whatever is available that suits their needs, and that does not have much of a barrier to entry associated with it.

Python can literally shine here (IDEs, debuggers, documentation etc - you name it, it's basically available)

Nasal is currently serving that purpose, especially compared to core development - and Python could serve that purpose, even if compared to Nasal scripting in its current form.

If you want to see a "case history", I am not sure anybody will be able to make a compelling case at all - even the migration to OSG was a controversial one, as was the introduction of the effect system, and we all know the debates that Qt5 has caused recently.

And even HLA used to be fairly controversial among core developers, the whole issue of being CPU or GPU bound is another recurring debate.

Nasal is not necessarily the best tool for many of the current scenarios it is used in. And there is a technology lock-in, i.e. the remaining number of core developers are very much hesitant to review/discuss and commit Nasal engine related patches. With Python, the situation is hugely better - i.e. maintenance of the interpreter would be no longer a responsibility that FlightGear would need to handle.

Adopting "standard" solutions (like OSG, Qt5, HLA or CIGI) is generally a good thing for the project in the long term, and OSG is probably the most compelling "case history" you can find so far, with HLA only just about to become one.

Thus - within the reasonable use cases of scripting in FG - what can Python do Nasal can't? If all that Python does is enable misuses of scripting, it's not that useful.

right, but to be fair, even Nasal has been used for implementing unprecedented things, including a dogfighting addon, but also a weather simulation engine - and as you know yourself, a number of core developers didn't/don't agree with Nasal as an implementation language.

The thing is, Python is going to make even more things possible, without much oversight from the project (core developers and project "leaders") as a whole.

After 5+ years of contributing to FlightGear, you may have arrived at a solid understanding of what technologies to use in a certain context (think Nasal, properties, property rules, fgcommands, jsbsim systems, effects, shaders etc) - but many other people, including current contributors, don't have such a solid understanding, especially not in a novel technology stack. We are already seeing that in the way the Canvas system is being used by aircraft developers to implement features in a fashion that prevents them from being compatible with other features, such as the "flight recorder", "multiplayer", "multi-instance setups (FSWeekend/LinuxTag)" etc

Python adoption is going to make that even more prominent, unless it is based on an IPC stack (like HLA) that forces people to think about the problem, or we're just adding to the mess we are seeing in Nasal space already.

At the end of the day, I am not trying to convince anybody here - in fact, we can just go ahead and prototype Python integration using Curt's suggested subset of property tree functionality, possibly in conjunction with Stuart's and Mathias' HLA code, and see how that will evolve over time.

If I am wrong, that would be great - if I am right, we will be seeing more and more 3rd party addons using approaches, and technology stacks, that the FlightGear project (aka core developers) would be very much hesitant to adopt/support in stock FG, at which point the project is going to increasingle divide/split up, because the motivation for people to join "us" (the community of contributors) may not be all that compelling, especially given that the GPL is dead-easy to circumvent LEGALLY using HLA/RTI, and that we will see more and more debates about problematic approaches with tons of Python modules used in "addons", and a plethora of potential issues arising from that (security, deployment, backward compatibility).

Nasal scripting is already not very formalized, and compared to core development it's frankly a huge mess, unless the corresponding code is written by experienced FG core developers, like TheTom.

I still appreciate having the theoretical discussion, to exchange the pros & cons of adopting/supporting Python, even just as an option like Curt suggested.
Then again, there isn't much that hasn't already been said in this context, by people much more familiar with FG/Nasal and scripting internals than most of us, e.g. Andy or Melchior:

http://wiki.flightgear.org/Nasal_success_stories

Melchior Franz (former Nasal maintainer) wrote:Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat ("re-invention of the wheel" is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable.


That is not to say that Python support could not be very empowering, but let's not ignore the potential issues arising from the increased popularity of FG scripting that /might/ bring over time (and I assert that this would be visible within 2-3 release cycles).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Dec 30, 2015 4:49 pm

curt wrote:
abassign wrote:We're just saying that if we want to use Python what changes to make to th code? Where should be changed, what needs to be changed etc ...
it sounds to me like abassign simply wants to explore building a prototype interface to python



If you don't want to use HLA, but just use a conventional subsystem:
  • you need to link to the Python library (DLL/DSO), by changing the CMakeLists.txt file
  • you need to add a dedicated subsystem to the main loop
  • you need to initialize a python interpreter instance
  • you need to hook that up to different subsystems (think properties, GUI etc)
  • you need to expose SG/FG APIs to Python

It's not rocket science, and given Python's popularity, there is excellent documentation, and tooling, available to help with that.

Anybody seriously interested in coming up with a prototype, here's the relevant info to get you going:

http://python.readthedocs.org/en/latest ... dding.html
https://ironpython-test.readthedocs.org ... dding.html

If you need a high-level overview, look at tutorials like these: https://www6.software.ibm.com/developer ... pt-ltr.pdf

You will also find that multi-threaded host applications, and the GIL in particular, require separate handling: http://danielpocock.com/embedding-pytho ... readed-cpp

A much easier option being boost: https://wiki.python.org/moin/boost.pyth ... dingPython
http://members.gamedev.net/sicrane/arti ... Part1.html
http://thejosephturner.com/blog/post/em ... on-part-1/

(you will probably come to appreciate boost/python once you want to expose C++ data/classes to Python and vice versa, e.g. properties, canvas, timers, listeners etc)

And here's the FlightGear boilerplate you need to add a new subsystem to the main loop: http://wiki.flightgear.org/Howto:Create_new_subsystems

The next step would be hooking this up to different embedded uses (dialogs, aircraft, scenery models, bindings etc), but that's the easy part.

Once you are done doing that, you will hopefully understand the arguments made by Thorsten and myself here.

I stand by my assertion, that anybody understanding FlightGear internals, and Nasal limitations, will sooner or later want to go the HLA/IPC route anway, though.

None of that is addressing the added management overhead resulting from that, i.e. arbitrary python modules being available to python code in FG.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Wed Dec 30, 2015 5:02 pm

Hooray wrote in Wed Dec 30, 2015 4:49 pm:None of that is addressing the added management overhead resulting from that, i.e. arbitrary python modules being available to python code in FG.


I just have to comment on this one, because enough is enough :( This is simply not possible. Look at what embedded Python is! It is not what you think it is, it is a very different beast to standalone Python. The amount of noise here is insane. My advice to those interested in doing something - as I have gone through the same experience - is just do it. Don't listen to the insane masses of information, opinions and some misinformation. This will just smother the fire!

Regards,
Edward

Edit: My experience with Python is what you'd call extensive (having worked with versions 1.0 to 3.5), so if you need any help, just shout out.
bugman
Moderator
 
Posts: 1684
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Dec 30, 2015 5:09 pm

bugman wrote in Wed Dec 30, 2015 5:02 pm:
Hooray wrote in Wed Dec 30, 2015 4:49 pm:None of that is addressing the added management overhead resulting from that, i.e. arbitrary python modules being available to python code in FG.


I just have to comment on this one, because enough is enough :( This is simply not possible. Look at what embedded Python is! It is not what you think it is, it is a very different beast to standalone Python. The amount of noise here is insane. My advice to those interested in doing something - as I have gone through the same experience - is just do it. Don't listen to the insane masses of information, opinions and some misinformation. This will just smother the fire!


I was going to send a PM to you asking you to post your opinion here, given your background/experience with a massive Python based project - admittedly, hoping for more than just 2-3 sentences.

I still stand by my statement that it will be very easy to make arbitrary python modules available to an embedded Python interpreter - but like you say, it is much easier to come up with a prototype than have this discussion in its current form. I think you are having a concrete "abuse scenario" in mind, whereas I am more concerned about long-term use/evolution of Python, an its modules.

Like I said, I suggest that you make a more detailed posting, based on your "relax" experience, to fill people in on the details where you think were are wrong. But please also look at what abassign and others have said, especially in the context of multi-threading (GIL) and the current FlightGear main loop, and what you think about IPC/HLA.

As far as I can tell, you are in an excellent position to provide quite a bit of useful background information, i.e. beyond just disagreeing with a single statement I made :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to New features

Who is online

Users browsing this forum: Applebot [Bot] and 8 guests