Board index FlightGear Development New features

FGPython an propose for Python as an nasal alternative

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Jan 27, 2016 8:04 pm

bugman wrote:The current FGPythonSys subsystem can be initialised at any point and I intend to keep it that way. If I can set up the CppUnit tests then initialising just this subsystem, with absolutely nothing else, will be locked into stone!


You could do that even using fg_init.cxx - i.e., we would only need to add a corresponding --startup-mode=python-only to options.cxx, which could circumvent other logic (think fdm, autopilot, sound etc), similar to the fgGetBool() change you just committed, which could be a good way to do regression testing (possibly even in a headless fashion), i.e. for doing valgrind/gdb runs in an unattended fashion.

The main complexity here is dealing with APIs that depend on other subsystems, at which point you will probably want to revisit my comments on using ::bind() and ::unbind() to add/remove Python APIs to the namespace "on demand".

Thus, one of the most useful APIs to expose to Python at this level would be the fgcommand() API itself, which would include the capability to dynamically start other subsystems using the "add-subsystem" fgcommand you are now familiar with, with the only thing required being a property tree wrapper, i.e. the equivalent of the props.Node class in Nasal.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 9:33 am

Since you asked for it:
bugman wrote:Timers sounds like the biggest of those failures. Do you have any others you can list?

Actually, timers are not all that bad given the design constraints of the FlightGear main loop - there are plenty other issues even apart from timers - and you really only need to look at comments from those core developers more familiar with Nasal internals to get a pretty complete picture - for instance, refer to the core developer comments quoted at: http://wiki.flightgear.org/Initializing_Nasal_early

In summary, the main challenges Nasal is facing in FlightGear (and where it is causing problems in FG) are these:
  • executed in the main loop, so that GC overhead affects frame rate
  • it is added/initialized way too late, so that it is not available for certain purposes (think scripted initialization, benchmarking etc)
  • it cannot be tested in isolation, and also cannot be easily disabled completely
  • there is the hard-coded assumption that the interpreter sees a "full" fgfs session, including bindings for all subsystems, which is incompatible with the ongoing reset/re-init work, but also with the add-subsystem/remove-subsystem fgcommands
  • at run-time, it is next to impossible to clearly separate scripts based on their scope/purpose, i.e. aircraft scripts should not affect scenery/core scripts and vice versa - imagine selectively disabling certain scripts and restarting them (think firefox task manager showing JavaScript callbacks)
  • there is the hard-coded assumption that there will only ever be a single Nasal interpreter active at all times
  • equally, it is not easily possible to look behind the scenes to tell which scripts are "heavy" in terms of CPU/RAM utilization or "GC pressure" - we also cannot easily disable scripts entirely (programmatically)
  • there is no proper dependency resolution - neither in scripting space, nor in C/C++ space (Nasal bindings that depend on C++ subsystems being around)
  • no concept of "run-levels" (think headless, core, scenery, fdm, aircraft etc), so that the globals namespace is a huge mess
  • so far, timers and listeners are the only "building blocks" (hacks) to integrate scripted code with the main loop, which inevitably violate the encapsulation that SGSubsystem/SGSubsystemMgr could provide - equally, many virtual methods are not even implemented for important simulator events (pause, resume, save/load etc)
  • lack of generic building blocks (think abstract base classes/interfaces) to help enable/ensure that contributions are sufficiently general in nature, i.e. are not specific to a single aircraft/instrument, GUI dialog or use-case, and which support multiple independent instances "by design".
  • poor formalization of crucial simulator events at the SGSubsystem level (booting, pausing, resuming, saving/loading), which applies even moreso to Nasal code
  • no tracking of VM overhead in terms of Nasal footprint for different code, so that most people unfamiliar with SG/FG internals are basically unable to troubleshoot issues that might be related to Nasal
  • existing C++ code in SG/FG that is not properly exposed to scripting space, so that people re-implement FDM/AP logic in scripting space (for example)
  • where existing C++ code can be dynamically toggled on/off or customized, it can only deal with a single instance of the class and not allocate new objects on demand (think having more than a single FDM/AP object "live" at the same time) - that is a restriction due to the way the subsystemFactory works
  • Nasal's threading support is extremely rudimentary, i.e. lacking concurrency primitives that make "tasking" more straightforward for less experienced contributors (think design patterns), so that race conditions would inevitably occur sooner or later, even without looking at the FG side of things.

Note that this isn't intended to sound like I am bashing Nasal here - it's just sharing some of the less obvious quirks, many of which have nothing to do with the language per se, but with the way the interpreter is integrated and used/mantained in FlightGear.

The whole "timers suck" thing isn't relevant here, because timers are -given the current fgfs design- the only reliable way to be sure that there are no race conditions introduced by Nasal code, which is pretty much the same reason why we don't see PUI related race conditions, it is basically using a similar mechanism to integrate code with the main loop that would otherwise have to be running in a separate thread.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 10:16 am

Regarding your recent commits:

  • if you want the non-Python build to succeed, you also need to wrap your #include <> statements in between #IF HAVE_PYTHON/#endif
  • you will want to do a null pointer check before calling a method, i.e. if(python!=NULL) or if (python)
  • anything that may raise an exception can be wrapped in a try/catch block, grep for "sg_io_exception" for details/examples (IIRC)
  • new subsystems would normally be added to Globals.hxx or added as a smart pointer (SGSharedPtr<> template)
  • the --disable-python option would normally be documented via $FG_ROOT/options.xml

Finally, availability of optional features is normally documented by setting a boolean property and setting a corresponding version attribute, e.g. something like python-version, so that $FG_ROOT/gui/dialogs/about.xml can show if HLA/RTI is available or not:

Image

To see how this is done, refer to: http://sourceforge.net/p/flightgear/fli ... i.cxx#l112
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 28, 2016 10:23 am

@Hooray: Thanks for all the info! That will really help moving things forwards. I think I can see ways of advancing FGPythonSys that would be a huge benefit to Nasal integration as well. I don't know if this is the vision of the future of FlightGear yet - but the C++ std::thread, Nasal thread, and Python threading module, combined with easy user offloading of heavy workloads to HLA, which should be a piece of cake to do using the Python HLA bindings, should help eliminate CPU bottlenecks. I can see how to remove everything from the main thread using threaded subsystems and a heartbeat signalling system using the current event manager code paths, instead of thread-nullifying timers + call-back functions (both are based on the observer design pattern though). I'm still working out how we can provide an incredibly simple Python/HLA interface for content developers. The implementation of any of my ideas would however cause FGPythonSys to become unstable, until the major FlightGear systems are made thread-safe, racing-free and rock solid (which a threaded, non-main thread FGPythonSys will absolutely require and force development to head in that direction). Anyway, I'll wait until I can align my ideas with the future direction FlightGear is taking.

Oh, if someone would like to have an off-forum discussion or talk about technical details, instead of using the PM system here, I have created the following discussion forum under my SourceForge user account:


This is for discussing the python/r* branches in my fork of the flightgear repository.

Regards,
Edward
Last edited by bugman on Thu Jan 28, 2016 10:50 am, edited 1 time in total.
bugman
Moderator
 
Posts: 1668
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 10:38 am

right, the major issue is getting things to work with the existing legacy code base and "architecture".

However, exposing the fgcommand() should be pretty simple already right now - many fgcommands are not even working with the global property tree, but just a temporary object (node) for passing arguments in a props.Node.new( {key0:value, key1:value, key2:value, })

Also, some don't even require any arguments at all - e.g. getting the do_null() command to execute should be trivial given all your recent progress: http://wiki.flightgear.org/Howto:Add_ne ... FlightGear

For the time being, these are not designed with thread-safety in mind, but would be trivial to fix up accordingly, due to their simple nature.

Note that this should allow you to already remove/add subsystems dynamically from your Python interpreter, so if/once you start up Python earlier than the others, you could selectively enable/disable certain systems and experiment with using some of those from a Python thread, i.e. those not requiring much in terms of synchronization with other systems (think sound).

Regarding your C++/std::thread ideas, I suggest to refer to Thorsten's comments at: http://sourceforge.net/p/flightgear/mai ... /34523327/

Looking at some of the subsystems currently running in the main loop, a few would seem pretty straightforward to move to a separate thread (e.g. the history/fight recorder subsystems are really just "recording" properties after all-and particularly the former is really tiny/self-explanatory):

http://wiki.flightgear.org/FlightGear_Headless
Image

I don't think you can expect to single-handedly re-architect a legacy architecture like FlightGear, but there are some low hanging fruits, and you can use those to learn a few lessons that may come in handy at a later time, while helping reduce main loop overhead in the mid-term.

For instance, the performance monitor subsystem is basically also just a mechanism to run a bunch of SGTimeStamp::now() statements to determine the time required to execute ::update(dt) for each subsystem, something which could also be handled at the SGSubsystem level directly, i.e. so that subsystems can be queried directly.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 28, 2016 10:49 am

Hooray wrote in Thu Jan 28, 2016 10:16 am:Regarding your recent commits:

[list]
[*] if you want the non-Python build to succeed, you also need to wrap your #include <> statements in between #IF HAVE_PYTHON/#endif


Just a small point, but because I don't include Python.h in the headers, the PythonSys.hxx includes are fine on systems without Python. But I'll add it anyway to avoid any future issues.

Cheers,
Edward
bugman
Moderator
 
Posts: 1668
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 10:54 am

sorry, you are right - I missed that obviously - I was skimming through your commits via the sourceforge commit logs without actually building anything, which is why I suggested to take my advice with a grain of salt ... the null-pointer check should still be useful though (imagine running the shutdown code when the subsystem is not even running)

EDIT: @Anybody interested in the FlightGear-scriting debate pre-dating Nasal/JavaScript and the requirements stated there (13+ years ago), I suggest to take a look at the original "FGScript" thread: http://www.mail-archive.com/flightgear- ... 18478.html
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 11:42 am

www2 wrote:how soon i can except canvas, settimer and navdb api in python?


As you can see, I am not generally opposed to the idea of Python support in FlightGear, but I somehow doubt that having support for the Canvas system will provide what you are hoping for - so maybe you could fill us in and tell us what you'd like to do exactly ?

Keep in mind that the Canvas system is running in the single-threaded main loop, and it is directly rendering related (most of it is using native OSG code, unlike other legacy code using raw OpenGL). In other words, Canvas is really just an abstraction mechanism for 2D rendering - and it is doing that using the property tree, which it treats as a "dump space" for events, where you can create a hierarchy of primitives and trigger events to create/update/animate/transform and remove primitives that reside in the global FlightGear property tree.

For the time being, the whole Canvas system is a conventional SGSubsystem, where each "canvas" is represented in the form of a RTT/FBO (offscreen rendering context), so textures get basically updated sequentially (with a few exceptions, mainly nested Canvases, i.e.a texture referencing another Canvas via a sub-texture lookup).

Also, Canvas is primarily a FlightGear specific technology, i.e. it's OSG code mapped onto the FlightGear property tree code to trigger C++ method calls, so unlike most existing libraries, there is not much of a technology stack outside SG/FG when it comes to Canvas. The primary bindings/code is available in FlightGear, and happens to be in written in Nasal.

That being said, once bugman has provided integration with properties and the global property tree, you could -in theory- access the global tree and trigger events in /canvas/texture[x] to create/update textures dynamically - so you don't need much in terms of explicit bindings to do that.

To see for yourself, I suggest to use the telnet/httpd interfaces to modify a Canvas dynamically, e.g. a tooltip or the Aircraft Center dialog (while it is shown) - you will find that you can directly manipulate the sub-tree without any Nasal code whatsoever.

So at the end of the day, it all boils down to what your goals are here - because Python support may not buy you much.

If you are hoping for multi-threading, that is a completely different issue - and it would require establishing the "one-tree-per-canvas" concept, so that each texture maps to a private property tree that is owned by the SGSubsystem/SGThread, so that Python (or Nasal) can safely lock/access it, without much impact on frame rate/spacing.

Obviously, that would then also mean that the same tree would no longer be safe to mutate/modify from other threads, including the main thread. But it would mean that people could have worker threads per Canvas texture, which could be mapped to osg::UpdateVisitor for better efficiency.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 28, 2016 1:37 pm

Hooray wrote in Thu Jan 28, 2016 10:54 am:EDIT: @Anybody interested in the FlightGear-scriting debate pre-dating Nasal/JavaScript and the requirements stated there (13+ years ago), I suggest to take a look at the original "FGScript" thread: http://www.mail-archive.com/flightgear- ... 18478.html


Wow, I remember those conversations :) That was a long time ago! It's interesting to see the origin of Nasal in FlightGear:

Andy Ross wrote:[snip]

And now the plug. :) I wrote a scripting language of my own at one
point (http://www.plausible.org/nasal) which is closer to Perl or
Javascript. It's semantically richer than PSL, supporting all the
stuff you expect like vectors, hashes/objects, garbage collection,
et. al. It's also quite small; a little over 100k of source code
these days. No work has been done to integrate it into
FlightGear/SimGear (I wrote it for my own game project last spring),
but I'd be happy to do so if there was interest.

Languages are like religions though. Some people are going to hate
the idea, some people are going to like it except for one or two
things that *have* to be fixed first, some will want to use a
different language. No one seems to want to use PSL yet, though, so
it seems to me like the door is still open for alternatives. :)


Regards,
Edward
bugman
Moderator
 
Posts: 1668
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Thu Jan 28, 2016 1:41 pm

yeah, it's pretty interesting - also looking at the original goals/statements and how FlightGear has evolved since then - in particular referring to some very valid design considerations/issues that were already voiced back then, and that are even today very relevant, especially in the context of increasing distribution and the ongoing HLA/RTI work:

http://thread.gmane.org/gmane.games.fli ... ocus=13342
Andy Ross in 2003 wrote:Lots of existing code was written to
reference "The Panel" and some work had to be done to enable the
notion of multiple panel objects. Likewise, there was no easy notion
of "this aircraft" within the rendering tree (all you get is an ssg
node walk back). I just hacked around this one and put in a global
array of panel objects with a (hopefully obvious) comment that these
should be per-aircraft when that capability arrived.

FlightGear is an old code base, and lots of the old assumptions (like
a single aircraft) need to be teased out of the code before progress
can be made on new features. This kind of work isn't glamorous, and
often requires more effort than the new development does. But it's
not brain surgery either. The problem with some great new features is
that they show up with code that is "ready" to integrate, but without
the integration work done. So they languish in the CVS tree until
everyone forgets about them. I can recall at least one occasion where
a unused module got replaced by a simpler (and arguably less
functional) one precicely because the original never got integrated
very well and the replacement actually worked.

The extreme programming cult manages to get this idea right (every
religion has a kernal of truth, right?) with their insistence on
constant refactoring and integration. Features are useless in
isolation.

Andy
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Thu Jan 28, 2016 2:06 pm

Hooray wrote in Thu Jan 28, 2016 10:16 am:* you will want to do a null pointer check before calling a method, i.e. if(python!=NULL) or if (python)


I guess you mean for the outside calls to the "python" subsystem standard methods, and python here is the subsystem class instance (or NULL).

* anything that may raise an exception can be wrapped in a try/catch block, grep for "sg_io_exception" for details/examples (IIRC)


For most of this I'll actually explicitly raise a Python error/exception, as most code will be called by the user doing something. The code that doesn't form part of the Python/C++ interface layer is currently tiny, and I haven't seen a need yet. But for the Python/C++ interface, I plan on providing a very rich set of Python exceptions, as the prop_tree module currently does, for providing large amounts of feedback to the Python developer.

* new subsystems would normally be added to Globals.hxx or added as a smart pointer (SGSharedPtr<> template)


I've followed what Nasal has done here, as it is important for the scripts in $FG_ROOT to be run after everything else has initilised (well, according to the source code comments for the Nasal initialisation).

* the --disable-python option would normally be documented via $FG_ROOT/options.xml


Finally committed and pushed :)


Finally, availability of optional features is normally documented by setting a boolean property and setting a corresponding version attribute, e.g. something like python-version, so that $FG_ROOT/gui/dialogs/about.xml can show if HLA/RTI is available or not:


Do you think it's really worth adding Python version info to the About dialog? I have HLA/RTI 1.3 compiled into my builds, but this info is not present in the about dialog. It might be better for Stuart to add that instead.

Regards,
Edward
bugman
Moderator
 
Posts: 1668
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Fri Jan 29, 2016 8:56 am

regarding the version info - that's obviously your call - however, I suggest to take a look at /sim/version (?) using the property browser - you will find tons of info there that is exposed via the property tree for troubleshooting purposes, despite not currenttly being shown in the about dialog.

Normally, there will be a property to tell if an optional feature is built-in or not, then if it's active/inactive and what version of the library is built-in.

The main purpose really is better troubleshooting, i.e. if/once someone reports a bug related to a certain feature - which is why you will find that there's usually 2-3 lines of SG_LOG() calls to log those facts to the log file in $FG_HOME, so that we can tell immediately if something is related to a certain feature or not.


I've followed what Nasal has done here, as it is important for the scripts in $FG_ROOT to be run after everything else has initilised (well, according to the source code comments for the Nasal initialisation).


right, that's one of the restrictions I mentioned, but it's not because of Nasal, but because of the way modules are written and loaded, which assume a fully working fgfs session/environment, with all subsystems up and running - you said you wanted to avoid such issues with FGPythonSys, so it would probably make sense to move away from the assumption that fgfs is fully up and running whenver Python is initialized - for instance, using the remove-subsystem fgcommand you could probably safely remove ~6 subsystems and would get a much more lightweight runtime environment (imagine starting just the fgfs/osgviewer window, the property tree and python) - such an environment could be really useful for benchmarking purposes, e.g. loading an aircraft model like the Su15 and re-enabling features (subsystems) one by one to see if/how overall performance is affected by adding certain subsystem (or not).

Many subsystems can be disabled, and even put in a parent group (SGSubsystemMgr), because they belong together (imagine having an "aircraft" group that keeps instances to fdm, autopilot, systems, instrumentation, hud, cockpit-displays - once that is the case, we can safely instantiate multiple aircraft with their own copies of fdm/autopilot or hud - which is touching on the refactoring work that Andy mentioned a long time ago (see above).

And most of this has become possible already thanks to James' reset/re-init work:

http://wiki.flightgear.org/FlightGear_Run_Levels
Image

Note that such an arrangement will make it much easier to specifially suspend/resume (or save/load, continue) scripts that are specific to a certain environment (think aircraft related systems), because all subsystems related to an aircraft would be neatly kept together, i.e. someone starting up fgfs with aircraft disabled (think for regression testing/benchmarking purposes), would not even run into the problem of disabling the corresponding Python/Nasal scripts.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Sun Jan 31, 2016 12:15 pm

bugman wrote:I've followed what Nasal has done here, as it is important for the scripts in $FG_ROOT to be run after everything else has initilised (well, according to the source code comments for the Nasal initialisation).


for the time being, none of your scripts should depend on any subsystems being around, other than the global property tree - which is a good thing, because there are no implicit dependencies - so if/when you start working on bindings for other systems (think navdb), you could selectively make those available depending on the availability of the corresponding subsystem.

Note however that the navdb (I think it was mentioned previously) is not a "proper" SGSubsystem at - i.e. it's a pseudo subsystem last time I checked, and one that could greatly benefit from being moved to a worker thread that can deal with concurrent requests: http://wiki.flightgear.org/Navdata_cache

This work would also be overlapping with the ongoing HLA/RTI effforts:

http://sourceforge.net/p/flightgear/mai ... /34725710/
Stuart wrote:we'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this


In other words, if you are hoping to introduce threaded subsystems, the SQLite based NavDB might be an interesting candidate system to do just that, i.e. so that it can serve requests coming from C++ code, but also from Python code runniny asynchronously.

bugman wrote:Do you think it's really worth adding Python version info to the About dialog? I have HLA/RTI 1.3 compiled into my builds, but this info is not present in the about dialog. It might be better for Stuart to add that instead.


It's not that much work to expose availability of a feature at the property tree level:

http://wiki.flightgear.org/File:Sim-ver ... python.png
Image

Code: Select all
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index 20039d6..b48dbda 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -231,6 +231,12 @@ void fgSetDefaults ()
     v->setValueReadOnly("build-number", HUDSON_BUILD_NUMBER);
     v->setValueReadOnly("build-id", HUDSON_BUILD_ID);
     v->setValueReadOnly("hla-support", bool(FG_HAVE_HLA));
+#ifdef HAVE_PYTHON
+    v->setValueReadOnly("python-support", true);
+#else
+    v->setValueReadOnly("python-support", false);
+#endif
+
 #if defined(FG_NIGHTLY)
     v->setValueReadOnly("nightly-build", true);
 #else


To also expose the Python version, you would want to use some Python specific version macro like PY_VERSION.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby www2 » Mon Feb 01, 2016 12:56 am

I start with bootstrap code for python that sandbox some of the io function in python like open, os.mkdir and delete and remove other functions like os.chmod and os.chown.
www2
 
Posts: 250
Joined: Thu Apr 16, 2009 1:58 pm

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Mon Feb 01, 2016 8:27 am

you may also want to look at how Nasal handles sandboxing currently, and how bootstrapping works at the moment - even if only to learn how not to do it for Python:

Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests