This release is again about bugfixes, test fixes and documentation improvement, with some small features.
qi::unicodeFacet
which was useful when used with boost::path
. If you
really need it, this function was moved to qi/path.hpp. You should also
consider using qi::Path
instead.qi::Atomic
is now implemented as a wrapper over boost::atomic
and thus
supports other types than int
.qi::ScopedThreadName
allow to set the current thread name in a RAII fashionqi::Session::waitForService
now returns a cancellable future.addCallback()
now returns a link
that you can use with disconnect()
.The SDK paths returned by libqi (in all qi::path
methods, like
qi::path::findLib
) are no longer deduced from the running executable
(/proc/self/exe on Linux) but from
argv[0]. This change should not break existing code since usually the
executable is the same as argv[0].
However, this implies changes for Python in case of deploys. Currently, the returned paths were always taken from /usr since the executable was /usr/bin/python2.7. They will now be deduced relatively to the python script if it is located in a SDK, with a fallback to the old behavior. This is useful for dynamic module loading.
The LogManager now holds a ring buffer that allows to get past logs coming before you register your LogListener to it.
void onLogMessages(std::vector<qi::LogMessage> msgs)
{
for (unsigned int i = 0; i < msgs.size(); ++i)
{
qi::LogMessage msg = msgs.at(i);
std::stringstream ss;
ss << msg.level
<< " " << msg.category
<< " " << msg.message
<< std::endl;
std::cout << ss.str() << std::endl;
}
}
int main(int argc, char** argv)
{
qi::ApplicationSession app(argc, argv);
app.start();
app.loadModule("qicore");
qi::LogListenerPtr listener = logger->getListener();
listener->onLogMessagesWithBacklog.connect(&onLogMessages);
app.run();
}
The errors:
[E] 6298 qipy.object: Error while registering function '__str__': TypeError: <method-wrapper '__str__' of MenuCook object at 0xb588f5ac> is not a Python function
are now fixed.
In the following code:
qi::AnyObject obj = ...;
obj.connect("signal", &myCallback);
myCallback
would be called synchronously by the signal handler. It will now
be called asynchronously as the user would expect.