Howto:Extend Nasal: Difference between revisions

Jump to navigation Jump to search

Howto:Extend Nasal (view source)

Revision as of 22:17, 26 March 2013

5,473 bytes removed ,  26 March 2013
→‎Background: cppbind is now available, no need to collect reasons for implementing it still
(→‎Background: cppbind is now available, no need to collect reasons for implementing it still)
Line 303: Line 303:
Also, the implementation of the SGPropertyNode bindings in [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/nasal-props.cxx nasal-props.cxx] contains additional examples.
Also, the implementation of the SGPropertyNode bindings in [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/nasal-props.cxx nasal-props.cxx] contains additional examples.
-->
-->
== Background ==
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17546.html
<pre>
Absolutely agreed that making as much data as possible 
available is valuable - as you say, I'm always amazed by the neat 
things people do in nasal scripts. [...]
I'm still thinking on different ways to make the core datasets a 
bit more 'lazy'.
</pre>
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29032.html
<pre>
One problem is that functions like airportinfo() already do *way* too much, and making it do more will not
help. We need to stop exposing *functions* to Nasal, and start exposing *objects*, with properties.
Notably, amongst the airportinfo() structure is a runways hash, which contains data that depends on the Airport Scenery data - this means it can trigger the
lazy loading of that data, and hence require a disk access. I've noticed the same problem with the map dialog. Most people accessing airportinfo() only want
one or two pieces of info, but we compute the whole lot each time. I realise that making proper Nasal ghosts for FGPositioned, FGNavRecord,
FGRunway, FGAirport is more work, but it would be the right path to putting the Nasal API on parity with the C++ one, and would enable a huge amount of
FMS/digital charting/ATC functions to be built in Nasal.
If that sounds impossible, then I'd strongly advocate creating separate special purpose-functions in the short term, that do *one* thing, and be more easily
subsumed if/when we properly expose the C++ types to Nasal.
</pre>
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29034.html
<pre>
Yes I'd like to second the idea of returning objects (with attributes
and methods for doing interesting things), I'm guessing we don't need to
abstract it too far from what is provided underneath.
However I really like the idea of getting back an array of airports
within some radius of a centre lat/lon pair, and/or within a bounding
box (2 or 4 lat/lon pairs), and if the same could be done with other
navigation elements in nav.dat it would be most excellent!
</pre>
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29035.html
<pre>
Well, this is exactly what all the query methods on FGPositioned do - the
problem is, they return FGPositioned subclasses, which aren't much use to Nasal
right now! Exposing the FGPositioned query interfaces (and the related,
specialised versions on FGAirport, FGNavRecord, etc) would be quite quick, but
it's pointless until the results are useful / interesting to Nasal..
One interim step - it would be possible to wrap the query methods, but write
code (exactly as airportinfo() is currently implemented!) to map the
FGPositioned subclasses to a 'static' naHash. That's easier than creating
proper naGhosts, and could have a forwards-compatible APi when the ghosts are
written.
</pre>
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37134.html
<pre>
I'm overhauling how we expose FMS related data to Nasal, to hopefully make
FMS/CDU construction in Nasal easier, but also re-using the C++ code we already
have, since many systems tie into the data.
Along the way, I'm learning a lot about the easiest way to expose C++ data to
Nasal, and I'm also trying to reduce code duplication. So where we have an
fg-command for an operation, I'll try to wrap the command in a nice Nasal
syntax. (With some exceptions).
As part of this, there's various features that I'd like to clean up, but I need
to be careful about compatibility. I'll list them below, but in general the
question is how conservative or aggressive I can be in changing this stuff now,
given it's 50 days until freeze - and more than 100 until release.
The things I'd propose to remove / change / break:
1)
        on navinfo() results, I want to remove the 'distance' and 'bearing'
values, since these depend on the query position, and can be computed easily
*if necessary* by the new courseAndDistance method. (Which works for any
waypoint / navaid / airport / geo.Coord / etc)
        [as far as I can tell, nothing in fgdata uses this feature anyway]
2)
        on airportinfo() results, I'd like to make the runways hash be a
function, instead of a child hash. This will mean it can be generated lazily,
and since airports have many runways, and we have quite a lot of data in the
runways hash, it would save a ton of hash-building.
        In practice the only change to code would be calling apt.runways()
instead of apt.runways, but that will still break aircraft that use the old
syntax...
        [the only users of this data I can find in fgdata are GUI dialogs which
are easy to fix, and actually would benefit from a revised API to get a single
runway by ident, which I plan to add - but I assume this is the feature other
FMS/CDU scripts are most likely using ....]
3)
        The route-manager has an internal 'command' API to manipulate the route
- this is used by the route-manager dialog. With the new Nasal functions, this
could be replaced with nicer Nasal calls. The question is if anyone has code
which is using this API - it's been around for a long time. Again, in fgdata,
no one is.
1) is low risk, I will almost certainly do it.
2) I would really like to do, but it really depends on the fall-out.
3) is less important, since the old interface can remain in parallel
</pre>
== A standard interface for mapping C++ classes to Nasal objects (Status 2013: implemented in cppbind) ==
== A standard interface for mapping C++ classes to Nasal objects (Status 2013: implemented in cppbind) ==


Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/59067"

Navigation menu