Re: [Flightgear-devel] [patch] Improved Nasal access to airport information
On 10 Oct 2010, at 17:21, Torsten Dreyer wrote: Sounds like a good idea. I am working on an extended METAR system allowing to fetch METAR data for an arbitrary number of stations. This will allow lateral (not only timed) interpolation of weather. Looks like these two systems might be a perfect fit. I'm not keen on this idea, even though I very keen on the concept. My problem is airportinfo() already does *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. James -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved Nasal access to airport information
On Mon, 2010-10-11 at 09:28 +0100, James Turner wrote: On 10 Oct 2010, at 17:21, Torsten Dreyer wrote: bits snipped 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. 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! S. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved Nasal access to airport information
On 11 Oct 2010, at 10:52, Scott Hamilton wrote: 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! 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. James -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [patch] Improved Nasal access to airport information
Hi All, I've been working on a small patch to change the existing global Nasal function airportinfo() to return more than one result. With this patch, and optional argument allows the caller to specify the number of nearest airports to return. E.g. airportinfo(10), returns the nearest 10 airports, and airportinfo(55.5, -3, 10) returns the 10 nearest airports to lat 55.5M, lon 3W. This changes the return values of this function from a hash containing a single airport to a vector of hashes, so requires a very straightforward update to all Nasal calls to airportinfo(). Previously one would call var airport = airportinfo(); After this patch, this must be changed to var airport = airportinfo()[0]; I'm happy to make this change to the dozen or so instances in fgdata (I have commit permissions to fgdata but not the flightgear source), assuming people approve of the change. I'm away on business this week, so it would probably best wait until next weekend unless someone is particularly keen to patch fgdata as well. My original motivation for this change is to create a Nasal-driven dialog displaying the local airport frequencies, something previously provided by ATCDCL, and which hasn't yet been replaced. Unfortunately I only noticed that frequency information isn't distributing through the FGAirport object after writing the patch below! The patch is available from http://www.nanjika.co.uk/flightgear/airport.patch Comments etc. very welcome as always. -Stuart -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved Nasal access to airport information
Am 10.10.10 18:06, schrieb Stuart Buchanan: Hi All, I've been working on a small patch to change the existing global Nasal function airportinfo() to return more than one result. With this patch, and optional argument allows the caller to specify the number of nearest airports to return. E.g. airportinfo(10), returns the nearest 10 airports, and airportinfo(55.5, -3, 10) returns the 10 nearest airports to lat 55.5M, lon 3W. This changes the return values of this function from a hash containing a single airport to a vector of hashes, so requires a very straightforward update to all Nasal calls to airportinfo(). Previously one would call var airport = airportinfo(); After this patch, this must be changed to var airport = airportinfo()[0]; I'm happy to make this change to the dozen or so instances in fgdata (I have commit permissions to fgdata but not the flightgear source), assuming people approve of the change. I'm away on business this week, so it would probably best wait until next weekend unless someone is particularly keen to patch fgdata as well. My original motivation for this change is to create a Nasal-driven dialog displaying the local airport frequencies, something previously provided by ATCDCL, and which hasn't yet been replaced. Unfortunately I only noticed that frequency information isn't distributing through the FGAirport object after writing the patch below! The patch is available from http://www.nanjika.co.uk/flightgear/airport.patch Comments etc. very welcome as always. Sounds like a good idea. I am working on an extended METAR system allowing to fetch METAR data for an arbitrary number of stations. This will allow lateral (not only timed) interpolation of weather. Looks like these two systems might be a perfect fit. Torsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
