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 getti
On Mon, 2010-10-11 at 09:28 +0100, James Turner wrote:
> On 10 Oct 2010, at 17:21, Torsten Dreyer wrote:
>
> We need to stop exposing *functions* to Nasal, and start exposing *objects*,
> with properties.
>
> Notably, amongst the airportinfo() structure is a runways hash, which
> contain
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
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 ret
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
5 matches
Mail list logo