Dear colleagues, I've pushed the changes I've accumulated over the last week to my github repository ( https://github.com/ivan4th/commonqt/ ). Please review them and let me know whether I should push some of them to the main repo.
Some comments.
1. I've fixed OUTPUT-FILES method on CPP->SO in qt.asd. Without this change, commonqt was being reloaded every time, at least when loading it via quicklisp, due to problems with FASL relocations. Also, SWANK:DELETE-SYSTEM-FILES was deleting only commonqt.so which didn't get restored by make during compilation.
2. When unparseable signal/slot signature was encountered, a rather mysteriously looking error was displayed. I've added a check to MAKE-SLOT-OR-SIGNAL with more readable error message.
3. To make QTYPEP more useful outside CommonQt's own code I've made it recognize type argument specified as string (integer values are still accepted of course).
4. I've added more QVariant conversions to qvariant.lisp. It's still doesn't support all necessary types but at least now it's possible to colorize and decorate these Q*Views.
5. UNMARSHALLER now caches unmarshalled closures. This seems to improve performance a bit in %METHOD-INVOCATION-CALLBACK as it doesn't cache anything itself. Also, I've got rid of redundant NONCONST-NAME function I've introduced previously. I did some tests on a QListView code with custom model with SBCL statistical profiler and seems like all this indeed helps (will later distill that test code into automatic benchmark).
6. The most recent commit is an attempt to cache marshaller closures too, which didn't succeed so far (perhaps I've did something silly there). If you enable cached version of MARSHALLER CommonQt crashes pretty soon when method invocation callbacks happen. This commit shouldn't be pushed to the main repository yet of course.
I've tried to research problems with Qt Hemlock. On my machine it causes memory fault soon after (hi::hemlock) on (#_show window) in HI::%INIT-SCREEN-MANAGER. After some debugging with gdb attached to SBCL I've managed to get stack trace of the problem (see attached file). If you google for "QVector<QPair<double, QVariant> >::end" you'll see that the problem is not unique. It happens somewhere in Qt intestines in animation fx related code. Seems like QPropertyAnimation object (it's also QVariantAnimation and QAbstractAnimation) gets destroyed to early. I doubt this problem is directly related to CommonQt changes and most likely it's a bug in Qt which gets triggered by current stack state and other random reasons. I will research it further in coming days.