[realXtend-dev] Naali py api upgrade & cleanup

[Toni Alatalo]

Hi,

in this sprint, after 0.2.1 was tagged, I've been upgrading and cleaning
up things in the Naali Python API. Otherwise there is also another track
of work, planning and designing the overall platform work for the rest
of the year, but this post focuses on the concrete things made for
current Naali.

First merged a branch where had already tested upgrading to circuits
1.3, which adds a new feature to circuits event handlers: return values
(~futures). The Naali event system on the c++ side works so that any
handler can return true/false to say whether the event was already fully
handled (true), or whether it should still be passed also to possible
remaining other handlers for the same event (false). We've been using
the small circuits event lib to bridge these to Naali python modules,
which are circuits components listening to circuits events. Earlier we
had to pass a callback func for the handlers so that they could set the
True/False flag based on whether they wanted to override default
handlers on the c++ side or not. Now circuits has a return value system
so that when pushing an event you get a value object to where return
values from the handlers will come, so I got to remove that ugly
callback passing, and the handlers can just return True normally when
want to override. I verified this by repeating the overriding of the
MoveForward input event (what gets sent if you press arrowup or w) with
which Petri tested this earlier, works with the new system too.

The value objects there are interesting otherwise too, they send events
when they are modified etc -- perhaps similarily to the new Naali
Attribute objects that Lasse has been writing for the experimental EC
data sync in Naali, and what Ryan's Subject thing is in his Scaffold
experiment. But that's another story for a later email, not used for
anything in Naali yet.

The mechanism for adding new Python modules to load automatically at
Naali startup, to show in the GUI or work otherwise, has been for long
this pymodules/autoload.py file which started very simple: you just
added an import to your module, and added the class name to a list of
modules. However, we soon wanted to start using live reloading of the
code to speed up the dev of e.g. editing tools. It is *much* faster to
not have to quit the viewer, login to a server again, find the object
with you were testing etc., when you are e.g. hunting some bug in your
vector math or anything. Originally, last summer or so, I didn't succeed
in making this work fully so that the whole c++ written Naali py support
module would be reloaded, it worked in simple situations perhaps once,
but crashed upon multiple sequential reloads. Nothing else in Naali does
unloading & reloading c++ modules either. It was much simpler and robust
to have the c++ side remain there, and just unregister all the Python
side circuits plugins from the py written manager and use the py reload
mechanism for them, this is what we've been using. It took some time to
get the code right so that all possible error situations are nicely
handled and reported, e.g. syntax errors at plugin loading or code
errors in plugin constructor etc., and in the meantime autoload.py
exploded to a terrible mess with copy-pasted boilerplate with the reload
logic. I now managed to finally isolate the loading & error reporting to
a reusable function, freshimport, actually again drawing from another
circuits project (an irc knowledge bot) which also uses circuits as a
plugin system (uses a .ini file to config what is loaded, supports live
reloading too etc). So got to clean autoload.py and it's short and quite
nice now, and adding a new a Naali py module/plugin with reload support
is just a matter of adding the name of it to the list.

The list is already strings so could be easily read from a .ini file too
if that's useful - have been thinking that to support custom configs a
mechanism similar to our CMakeLists.txt and CMakeOptionalModules.txt
would be good: have a defaults.ini where the bundled py plugins are
listed, which you don't normally need to touch, but support also having
some additional.ini where you can locally add more plugins to load .. or
perhaps handle *.ini in the pymodules dir so that projects can name
their module confs how they want? Another option would be loading all
that are in the directory (Blender 2.4 does this, you must just add some
special registration string to the top of the file - am not sure how it
is in 2.5 now), but at least in my work it's handy to just comment out a
line in a config file to quickle enable/disable some module (while Naali
is running) without needing to move dirs/files around.

In the future if this add-ons (the term Mozilla uses) system catches up
we need to add some GUI support for it, so that you can see what py
modules are running and manage them there etc. On the Blender side where
a similar system has been used for long there is now again talks about
making some repo from where add-ons are easy to install, upgrade etc -
hopefully someone does something we can just adopt :) . For current use
the multiple *.ini system would probably suffice, and we'll be learning
more now (this month) 'cause there is at least one project where several
small simple custom py Naali modules are being devved by a couple
different people. If there are others interested in this, please comment
and tell your requirements etc. In the extensible virtual worlds
workshop (x10) in SL recently I was surprised that many of the
participants said that trusted viewer plugins/add-ons which you need to
install are useful -- before that I was thinking they can be a bit
irrelevant, mostly useful for viewer devs and a few customizing needs,
and the real beef will be in running of untrusted code from the servers.
I guess we need both, like on the web there's both browser addons and
the websites themselves, both running custom code in the client but with
different featuresets available.

I've been also continuing the on-going work of making py tools use the
Naali internals via the automatic dynamic bindings that PythonQt
provides for QObjects with Qt slots etc, and removing the old manual
bindings for those functions. RexLogic is now a QObject so we'll be able
to do a lot of that, and also with entity-component access there were
things like MeshID assigning for which could remove the manual binding
code. This results in much less code, and has the added benefit that the
same mechanism works for Javascript too using the Qtscript engine in Qt.
In previous sprint I added some things to the Javascript side and used
the JS support in Naali succesfully to run some Syntensity unit tests,
but that's again a part of the other story.

On the immediate side, I'm next testing threaded plugins and ones that
run a separate process to do work. Either might be a simple solution to
have the current blocking lib for webdav inventory not block. It might
suffice there though just to use the new qt using async http transfer
manager in AssetService for the webdav inv asset transfers, and have
sending the little commands in the main thread .. that's how the lludp
inventory code works. Am just afraid that due to network trouble etc.
also sending little http commands can block the viewer annoyingly

There is also the camera / machine vision based head tracking module we
made in last July and which basically works ok, using the py subprocess
module and a recipe for async comms for the interprocess comms between
Naali and the head tracking process. There is the prob that I only got
the async comms work in one way for some reason .. the cam part runs ok,
reading commands from Naali doesn't block it, but when Naali reads data
from it, it gets blocked untill gets data. So for it to work well now
have to adjust timings carefully for the FPSes in the particular setup.
James Mills, the author of circuits, just rewrote his Process and Bridge
components, and added subprocess pipe (stdin/stdout) support there too,
and verified it works async both ways. So porting the headtrack thing
from the own subprocess using code to use the new circuits stuff should
both make our code simpler and work well. I may give a shot if have time
after the more critical non-blocking webdav, *.ini files, and the
planning of the future works is done .. which sounds like a "no" :p .

BTW besides subprocesses, circuits.Bridge was actually first written for
network sockets, so that you can have components that send events to
each other (a publish-subscribe system) on different computers as well
.. can be useful for upcoming AR / Cave / something experiments with
special equipment, or something? I think things like these are fun
benefit of using an existing event lib, instead of rolling our own (like
already last summer having circuits there gave us the webserver plugin
for free). Perhaps we could even write some simple sim server or p2p
support so that have a circuits.Bridge Naali plugin sync Naali events
between clients over a network :p (had never thought of that, just came
to mind now, I'll try to not thinks this too much yet ;)

Sorry for the long post, but at least there's the info now of what's
going on in this department. if someone is interested. Time for docs for
the py stuff is coming too as things are starting to stabilize in the API.

~Toni


--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org