Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?

[Ron J. <wi...@je...>]

On Thu, 2009-02-26 at 16:05 -0500, Nicolas Quijano wrote:
> Hi all, let me start that my goal here is NOT to start a polemic on
> the reasons for using nasal vs any other scripting language, or the
> scripting vs native code, or any such argument :)
> Thanks for remembering that. 

OK, without getting into a religious discussion about the worth or
advisability of adding another scripting into flightgear, it sounds like
a lot of work and feature bloat for very, very little return.  :)

> That said, being a long time user and proponent of levering scripting
> in games/sims, and particularly, using Lua, I have a keen interest in
> any insights garnered over time by current and past fgfs devs. 
> How coupled are Nasal and the scripting glue in FGFS ? Is there a
> clean break, or if not, can it be refactored without too much pain
> into something that would allow end dev users to use whatever
> scripting language they prefer, or have many modules already writen
> in, etc. 
> 
> If the coupling is not of the hair pulling type, it might be
> conceivable to integrate another scripting language alongside Nasal
> for starters, and in time, completely replace it if one is so
> inclined :) 

It may not be inconceivably hard to add another interpreted language to
flightgear.   The first problem I noticed today is our XML spec didn't
have this in mind, we have:

<nasal>
 <script>
  ... (code goes here )...
 </script>
</nasal>

So I suppose a <lua> tag wouldn't be bad...  But if we wanted to go in
the direction of adding support for random scripting languages we might
want to replace the top level tag with something else:

<userscript>
 <language="nasal">
 <script>
  ... (code goes here )...
 </script>
</userscript> 

or:

<userscript language="nasal">
 <script>
  ... (code goes here )...
 </script>
</userscript> 

or even overload the current nasal tag to allow other languages: 

<nasal language="lua">
 <script>
  ... (code goes here )...
 </script>
</nasal> 

As far as replacing nasal, that project would be very hard.  There are
many vital parts of flightgear currently coded in nasal.  There are also
random bits of nasal code scattered around in joystick configurations,
instrument and aircraft models, scenery models...  everywhere.  It
would, in effect, require starting the whole data project over again.


> For me, this would be Lua, and I'll be working on integrating it in my
> local fork, but as I'm just getting down to tinker with FGFS source
> code, I'm interested in hearing your views on the topic. If there is
> interest in this beyond my own, I'd rather do it in a
> collaborative/friendly way that's not one sided, or in other words,
> I'd rather not rip out Nasal savagely to replace it completely with
> Lua, without thinking about compatibility down the road. 
> My preferred approach would be to start with cohabitation, rather than
> coupling Lua to a local fork... 
>  
> What I'm interested in hearing is about the collective and individual
> experience of working with Nasal at the source code level, the
> API/communication mechanism between its VM/interpreter and "native"
> code, and plenty of other documentation details which do not seem to
> exist or that I haven't been able to find, and can save a lot of time
> in coming to grasp with code you haven't written. 

Nasal is actually implemented in the simgear project.

Nasal "communicates" with flightgear through the property tree, so
you'll have to create lua methods to read, write and create
properties.  

Nasal calls flightgear commands in Main/fg_commands.cxx

Nasal is also purposely limited on disk IO abilities.  It is only able
to read/write from specified directories.   Otherwise it would be
possible for a "rogue" aircraft script to send, say the contents
of /etc/passwd to a random player on the multiplayer server... 

> Thanks in advance for sharing your experiences with Nasal
> integration, 
> Cheers, 
> Nic
> 
> -- 
> Be Kind. 
> Remember, everyone is fighting a hard battle.