Hi All,
It hasn't been discussed for at least a couple of months, so I thought I'd
bring up that old chestnut, "when are we going to have a new release?".
>From the website, here are the pervious release dates:
0.9.5 - 2004/07
0.9.6 - 2004/10
0.9.8 - 2005/01
0.9.9 - 2005/11
0.9.10 - 2006/04
Stuart Buchanan wrote:
> Functionally, it seems reasonable to force all IO access through a
> wrapper .nas file in $FG_ROOT/Nasal that could attempt to restrict
> dangerous activities.
This is actually possible, albeit obtuse. In the existing io.nas file
(which currently adds the soft-coded readf
* Melchior FRANZ -- Friday 30 March 2007:
> And if someone does a $ ln -s / ~/.fgfs/foo, why not?!
Assuming that Nasal/IO can't make such links itself, of course. ;-)
m.
-
Take Surveys. Earn Cash. Influence the Future of I
* Gene Buckle -- Friday 30 March 2007:
> Would it be reasonable to add a RESTRICT_IO define within Nasal itself
> that stripped any path data from a filename and forced it to /tmp or some
> other default directory specified by a non-nasal Nasal configuration file?
Not sure what you mean with "Nasa
--- Melchior FRANZ wrote:
> * Stuart Buchanan -- Friday 30 March 2007:
> > Functionally, it seems reasonable to force all IO access through a
> wrapper
> > .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous
> > activities.
>
> But every Nasal code would have to have access to use
> * Stuart Buchanan -- Friday 30 March 2007:
> > Functionally, it seems reasonable to force all IO access through a wrapper
> > .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous
> > activities.
>
> But every Nasal code would have to have access to use those
> wrapper/validator fu
* Stuart Buchanan -- Friday 30 March 2007:
> Functionally, it seems reasonable to force all IO access through a wrapper
> .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous
> activities.
But every Nasal code would have to have access to use those
wrapper/validator functions ... a
I don't know the right answer to any of this, but what I do know is that the
internet is a much different place compared to a few years ago when we
launched the FlightGear project.
Originally the internet was much like a university, not without it's
problems, but generally you could assume that e
--- Melchior FRANZ wrote:
> Nasal (in SimGear) already had support for file I/O since the
> last Nasal update, but the line that would have activated it was
> commented out until yesterday. The now available Nasal "io"
> module allows some interesting stuff, such as direct appending
> of OBJECT ent
Nasal (in SimGear) already had support for file I/O since the
last Nasal update, but the line that would have activated it was
commented out until yesterday. The now available Nasal "io"
module allows some interesting stuff, such as direct appending
of OBJECT entries to *.stg files from nasal code.
10 matches
Mail list logo