Board index FlightGear Development Nasal

Nasal must go

Nasal is the scripting language of FlightGear.

Re: Nasal must go

Postby Thorsten » Sat Oct 08, 2016 7:54 pm

But it's ok to discuss this without automatically telling people they live in a fantasy world and trying to shut down the whole conversation.


Curt, with all due respect: The whole thread started off with a provocation - is that really supposed to attract support? Seems like a very poor strategy to me. Next I've dared to point out that plenty of points have been made elsewhere - the result? A snappy line that this isn't an argument. I've tried to highlight the cost of porting etc. - no reaction, posting happens as if this is a minor concern - comparing the relative merits in an alternative world in which we have FG with Python and the one in which we have Nasal.

I think that's not a realistic discussion leading anywhere, and, again with all due respect, I think it's a valid point to say that.

I honestly think the whole discussion could have been fruitful leaving out the provocation, reading through all the arguments exchanged before and replying to the concerns rather than ignoring them. So if you're looking for a reason this shuts down, perhaps try looking beyond the messenger.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby bugman » Sat Oct 08, 2016 9:07 pm

For the 'fantasy' aspect, those are my words. That's how I see open source software development. Note though, this is solely from the perspective of a developer. You fantasize about something, then write code, and the fantasy becomes a reality :) If you cannot write the code, or are unwilling to learn, then you obviously have to remain in the realm of fantasy.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Hooray » Sat Oct 08, 2016 9:12 pm

or continue nagging actual developers to inspire them to turn your fantasy into reality ...
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Nasal must go

Postby bugman » Sat Oct 08, 2016 9:22 pm

Well, nagging actual developers will ensure that the fantasy remains forever a fantasy ;)

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Hooray » Sat Oct 08, 2016 10:01 pm

Well, it seems to have worked out for some people/features - besides, the OP wanted to have a discussion (obviously, without wanting to go through the archives to learn more about previous discussions), and given the responses in this thread, the OP seems to have accomplished just that. So this topic isn't entirely pointless, although I agree with Thorsten that it could have been much better, and much more interesting, had the OP done a little more homework and gone through the archives to come up with a few more informed questions - but apart from that, we have seen much less constructive exchanges between people not interested in touching any code and those able to implement the requested changes/functionality.

For now, it seems the ball is in the OPs court, i.e. to follow up on your suggestion to learn more about FGPythonSys - unlike many other "feature requests", this is after all a feature for which we have a number of patches, and even topic branches implementing sufficient functionality to bootstrap the whole thing, and even people willing/able to mentor newcomers
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Nasal must go

Postby Thorsten » Sun Oct 09, 2016 6:53 am

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)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby bugman » Sun Oct 09, 2016 8:02 am

One of the nice things about Python is the really well developed C/C++ interface. For my own software, 99% of the code is Python. However this is scientific number crunching software, and the 1% of the code that takes 99% of the time is in C. With this interface you also have easy access to FORTRAN and the BLAS and LAPACK libraries via C, though I've never used that.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Nasal must go

Postby Hooray » Sun Oct 09, 2016 8:37 am

Next imagine Thorsten using Fortran for his aircraft/scenery work, bugman using Python, abassign "using" Erlang - and now imagine what it will be like to have multiple scripting language next to each other, and some resources (aircraft/scenery) possibly requiring additional modules (libraries) or even different versions of the same language interpreter.

For the record, abassign didn't make that post to provoke, or because he's familiar with the language - Erlang is hugely inappropriate for being an alternative to Nasal in the form that Python, Lua or V8 (JavaScript) could replace Nasal.

Apart from that, we also have core components not written in C/C++, such as the Ada FDM - and I think we all now how that worked out for FlightGear, so it does make sense to learn from such experiences (and to be fair, gnat (the Ada compiler) is easily and freely available on all Linux distros)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Nasal must go

Postby Thorsten » Sun Oct 09, 2016 9:06 am

I've usually written my number crunching in C, linking with Fortran numerical libs - or adapted existing Fortran code.

Come to think of it, I don't know anyone in particle physics who would ever have used Python or even mentioned it - people use all sorts of tools and languages I know, but not that. So communities seem very different...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby www2 » Sun Oct 09, 2016 10:06 am

Thorsten I know that for number crunching i chose to use cython with numpy for the backend and python for the frond end code.

And if i remember correctly cython is not needed for dependency for already compile code that are use by python.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: Nasal must go

Postby Hooray » Sun Oct 09, 2016 10:23 am

Python is commonly used for all sorts of purposes, mainly because of its community and the plethora of modules available, for number-crunching, pyOpenCL would be commonly used, pyCUDA for nvidia specific stuff - basically it allows you to directly access the GPU without having to compile anything, it really is a massive technology enabler like bugman repeatedly said already - there's basically no barrier to entry, because you only ever write your code in an interpreted language with LLVM taking your CL/CUDA kernels to turn them into bytecode for the graphics card.
This goes a little beyond using Fortran numercial libs, e.g. because of libraries like SCOOP that make even heterogenous clusters of machines available to you to run all sorts of "jobs" asynchronously in a master/slave setup - someone mentioned a few days ago ML (machine learning) and neural networks, this sort of thing is fairly straightforward to do using Python, even in a massively parallel and distributed fashion using a handful of modules.
This is one of the key reasons why Python is so extremely popular among data scientists (many of whom have a professional background in physics or maths)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Nasal must go

Postby Thorsten » Sun Oct 09, 2016 4:27 pm

pyOpenCL would be commonly used, pyCUDA for nvidia specific stuff - basically it allows you to directly access the GPU without having to compile anything, it really is a massive technology enabler like bugman repeatedly said already - there's basically no barrier to entry, because you only ever write your code in an interpreted language with LLVM taking your CL/CUDA kernels to turn them into bytecode for the graphics card.


... at which point you discover to your dismay that graphics cards are intrinsically quirky devices. I know people who've tried to run hydrodynamics on GPU clusters - never really worked out because the results always had stability issues. Basically you get your answer a lot faster, but you can't trust it and spend a lot of time verifying them.

I doubt an extra abstraction layer is going to be a big help here...

(Aka - sounds very compelling until you actually git to the nitty-gritty of it...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby Hooray » Sun Oct 09, 2016 4:50 pm

I don't think we are talking about the same thing - i.e. we are probably both right, but having different scenarios in mind.
Python support is indeed a huge technology-enabler, especially in conjunction with modules like PyOpenCL, which would open up a whole new world to FlightGear scripting, without any of it having to run in the main loop or a conventional CPU thread.
I am not saying that Python support is such a great thing (think GIL vs. Nasal), but a technology-enabler it definitely is, because once you have Python support, these things can be had "for free", whereas providing the same functionality in Nasal space would be a ton of work, which is what many users here were hinting at - then again, I do realize that you were asking about "Python the language" and not "Python the community/plethora of modules".

If I were as interested in this as bugman or Curt, I would look for compelling use-cases, e.g. the whole osm2city effort has tons of Python code that could benefit from having Python scripting built into FlightGear - likewise, a Python-based frontend like FFGo could be easily made to work without having to build a launcher from scratch (think the Qt5 effort).

Apart from the IPC bridge that Richard, James and Torsten talken about, there really isn't much missing to come up with a dedicated Python subsystem that asynchronously get/sets properties using an event queue and that can run fgcommands. At that point, you are all set and can do all sorts of fancy stuff without any of it having to clutter the main loop.

But again, when it comes to literally "replacing" Nasal it is worth keeping in mind that the OSG transition was initiated in mid 2006, and since then has never been fully completed, i.e. we still have tons of PLIB code all over the place, including code which is complicating matters for OSG tremendously - and it is particularly important to note that we're talking about native C++ code here - i.e. everything was/is completely under the control of our core developers, whereas that hardly applies to Nasal code (think aircraft scripts, scenery scripts, 3rd party hangars, addons like bombable etc).

In other words, literally ripping out Nasal to replace it by Python is going to be more challenging than refactoring a C++ code base, unless you are using a source-to-source transformation system to help with doing so.

I kinda like the "Superiority" short story you keep posting in these debates, because I can somewhat relate to it - however, it is also worth keeping in mind that with OSG, this whole technology-enabler thing ultimately turned out just right - i.e. shaders/effects, multiple windows/cameras, Rembrandt, ALS, earthview, Canvas etc - none of which would exist today (in its current form) had this not been committed back then.

And back in the early days of the PLIB/OSG transition that was a highly controversial thing, some of the most senior contributors were literally yelling at Curt for committing the patches in their form back then, and tons of debates took place on the devel list (and IRC!), given the plethora of regressions caused by that work.

Given that this debate is about Nasal, Andy Ross was particularly outspoken about the whole situation and not exactly happy with how things were handled back then, but 10+ years later, it seems everybody agreed that the transition to OSG (no matter how incomplete) was a smart move - but back then, Curt had to feel quite brave, and act boldly to actually do so ...
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Nasal must go

Postby Thorsten » Sun Oct 09, 2016 5:19 pm

however, it is also worth keeping in mind that with OSG, this whole technology-enabler thing ultimately turned out just right


Which is why I'd like to see this discussed in terms of realistic transition pain vs. enabling gain. See, right now I see a huge pain with very little gain (essentially a few people who don't feel comfy with Nasal can use another language).

Being able to do computations on the graphics card easily isn't going to cut it for me - because the GPU is full right now when we do good rendering effects. Being able to do numerics isn't going to cut it for me, because numerical intense jobs need to go to C++. Being able to run a huge collection of diverse modules calling the whole thing FG isn't going to cut it for me, because this is /not/ scientific computing but simulation where all tasks need to be finished within a frame, and here I think a monolithic design is much easier and more efficient. osm2city in my view is one of the computations that should run offline - they're welcome to use Python to do it, but personally I think generating scenery runtime is as wasteful as it gets.

Whereas I see the gains of OSG readily, and they're substantial. OSG enables stuff we actually need - lots of it.

Keep in mind - the actual use case why we need Python was 'I want to write a flight instructor module and I can't do it in Nasal'. That's the opposite of 'compelling' as far as I'm concerned.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Nasal must go

Postby Hooray » Sun Oct 09, 2016 5:31 pm

I agree, however pyOpenCL was just one example (I also mentioned SCOOP) - the thing being far from specific to GPUs (pyOpenCL can just as well be told to run on idle cores or other non-graphics hardware, e.g. dedicated FPGAs), i.e. it's just a generic way to code "computation kernels" (akin to GLSL) that can be told to run on whatever idle hardware you throw at it - imagine it like writing a GLSL kernel that you are "abusing" for number crunching, just without having to marshal everything into a graphics problem, because OpenCL is just about computing, not about graphics.

But I really never meant for OpenCL support to be the sole/primary reason to go "all-in" on Python support - it's just one of those things that would be a huge technology enabler that comes to mind.

I do agree that this discussion didn't provide any good technical points, but this is the user's forum after all - so it'd be a little far-fetched to expect truly compelling arguments to be exchanged here.

Like I said previously, I don't expect Nasal to go anytime soon, and I am also convinced that for any other language to be implemented next to, or instead of, Nasal - people will have to review the current situation with Nasal, which also includes looking at major contributions, and contributors, whose work is written in Nasal.

Apart from that, the OP's key message is wrong anyway: he can already use Python and websockets to remote control FG just like he wants, he does not need any other functionality - going down the FGPythonSys route however means facing all the challenges that I repeatedly mentioned.

I do agree that most points made in favor of Python are primarily about its syntax, it being hugely successful, having an enormous community and following and a plethora of 3rd party modules - but like I said already, that is going to prove problematic for many reasons, because it is only going to make FlightGear's shortcomings at the core level much more prominent to the layman - right now everbody thinks that Nasal is the culprit, once they have actual working Python support, they'll realize that those Nasal folks may not have been all that wrong, and that the problem is elsewhere (as per the comments made by Richard, James and Torsten)

Personally, I am far from opposed to working out how to make that happen, but I am firmly convinced that to make any progress with additional scripting support, people need to understand how the Nasal engine is integrated and what/where those limitations are coming from - and that will entail adding support to disable parts of Nasal, and to incrementally initialize the interpreter - as well as eventually adding a mode to entirely disable it, and in the process of doing so, common functionality would ideally be added to a common baseclass that other scripting languages can inherit from, especially when it comes to machinery for getting/setting properties and invoking fgcommands.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Nasal

Who is online

Users browsing this forum: No registered users and 5 guests