Pyshake Changelog
New in release 0.3.0
- Pyshake is now fully thread-safe and compliant with Python thread handling. Most importantly, this means that you can now spawn Python threads from within Shake for background processing.
- All functions needed for basic message passing are exposed so that background threads can safely communicate with the main Shake thread. See README.multi-threading for more details.
- The loadScript function now behaves more like nuiLoadScript by restoring any GUI settings.
- pyEval* functions now have pyEval*WithModule siblings so that Python code can now be evaluated after importing a Python module. This was previously not possible.
- Documentation for both the shake and the shake.sdk modules can now be generated using Pydoc. Run make htmldocs to generate two HTML files in the build directory, shake.html and shake.sdk.html.
- A bugfix to Py++ means that C++ virtual methods can now be overridden with Python code in any class. Formerly, virtual methods could only be overridden in the class that defined the virtual method. An unfortunate side-effect of this is that the size of the wrapper code roughly doubled. We hope that with further improvements to Py++ this bloat can be reduced.
- Fortunately, an improvement to the build process which prevents unneeded symbols from being kept in the Pyshake libraries means that they shrunk by about 50%. Therefore, pyshake 0.3 binaries are still roughly the same size compared to 0.2. On the upside they should load a lot faster as there are far fewer symbols to resolve during dynamic linking.
- When a Python method overriding a C++ virtual method throws an exception it is now printed to stderr to aid debugging. Pyshake will however still have to immediately abort Shake as there is no safe way to handle this situation.
- On Linux, the Pyshake plugin no longer links to Python statically. This means that native Python extensions can now be used in plugin code without ill side effects. This problem is currently unresolved on Darwin.
- All Pyshake objects can now be compared with "==", "<", ">" and used as keys in maps (they all implement __hash__). Note however that the "is" operator will still return False for two different Python objects even if they both wrap the same C++ object.
- Better handling of void pointers.
- A number of small bugfixes for NRiListView object ownership. Bugfix for NRiNode::getHooks() return value policy. Removed bogus hard-wired paths from Makefile.
- OpenEXR is now an optional dependency.
- There is rudimentary documentation in the form of READMEs about best practices, multi-threading, and debugging.
- All enumerations are now exposed, including anonymous ones.
- Newly exposed classes and functions:
NRiCmplr::execute NRiValue (use PyshakeValue) NRiType NRiScope NRiGlobals::def NRiArray<*> NRiPArray<*>::append NRiRender NRiRenderQSubmit NRiMenuEntry::findMenu NRiMenuEntry::findMenuByHotKey NRiMenuEntry::getPopup NRiNodeColor::getClassColor NRiNodeView::getTopCanvasObj NRiScrubValues NRiPArray<NRiScrubValues> NRiPArray<NRiGlobalEventMgr::GlobalEventEntry> - Unexposed NRiLex::map as it caused problems with pydoc
- The autoconf-based build infrastructure has been improved. Autoconf macros now live in individual files in the "m4" subdirectory. Redundant files have been removed and now need to be generated using the bootstrap script after a svn checkout or svn update.
New in release 0.2.0
- This release now wraps up large parts of the Shake API. Most importantly, you can now build GUI extensions in Python. See examples/modalDialog.py - a straightforward port of the modalDialog.cpp example that comes with the Shake SDK - for a taste of what is now possible.
- Pyshake is now known to work on Mac OS X.
- The installation process has been improved and is now based on autoconf.
- This release requires gcc 4.0 which is incompatible with the Shake 4.0 SDK. This means that pyshake 0.2 can only be used with Shake 4.1. Shake 4.0 is no longer supported.
- One problem with this release is that pyshake has grown quite large. Both the Shake plugin and the Python module currently weigh in at around 40 MB. We are working on improving this situation. If memory usage or startup time is a concern for you, you might want to stick with the 0.1.0 release for the time being.
