* Fixed the callback system for messages so that the callback is always executed by the thread that registered it. * Reworked the rendering system to get rid of redundant rendering and to remove some structural limitations that were increasingly hard to work with.
The visible effect is that browsing animations did not finish as they should before default ticking would take over and paint the widget again.
suggestions. The number of characters is equal to the number of NUM* entered on the remote.
following certainly happens with a very high level of certainty: Start conman with the "--scan" option. Try playing a FLAC file while the scan is going on. If the playback caused a search for frames in the FLAC file, then there is a high probability that a SIGSEGV will be caught somewhere in or below the ctypes interface to libFLAC. What is really weird is that *no* *one* *else* is using libFLAC when this happens. Some experimentation also confirmed (in a separate program) that enough threaded but unrelated activity will crash the ctypes interaction with libFLAC. How is this possible? Both ctypes and libFLAC are supposed to be thread safe! Resolved the issue by putting the frame scan on a separate process. By running in a separate process, it is also possible to catch the SIGSEGV if it should ever occur (although it seems it never will).
worker threads to stop the CM from becomming unresponsive. The threads have .daemon set to make sure they are automatically shut down when the program terminates.
present and CM got removed.
to the main thread. Changed the format slightly as there is no need to track more than one backend. * Bugfix: Error message in device.py was wrong.
to handle differently for different environments.
automatically to sub-processes (but not threads) so no particular handling of SIGINT is needed to shut down the started sub-programs.
the shortest candidates make it into the first-20 list.
remembered by ctypes. If the Python caller also does not store refs to the parameters, then the GC will eventually deallocate the params even though the C lib may or may not be using them. Had to prevent this with the callbacks passed to FLAC__stream_decoder_init_file().
interface is written against ctypes to make it pure Python without the need for architecture specific building.
* Create a socket with a timeout. * Try to connect() the socket in a way that fails for a proper reason. E.g. "connection refused". * Retry connect(). No matter whether a serice is running on the other end, this second call (and all following it) will fail with errno 22 (invalid argument). For whatever reason, this always happens on OS X 10.5 but I have never seen it on Linux. I.e. sockets have to be closed and discarded on OS X if the first connect() fails. Seems a bit over-zealous, but that's it. Weird...
The handler was running in a CM's thread and caused race connditions in the renderer objects.