Me again ...
Doing
(ql:quickload :qt)
(qt:ensure-smoke :qtcore) (qt:ensure-smoke :qtgui)
(ql:quickload :qt-tutorial)
and finally
(qt-conv:main)
results in the following errors:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
Ok, so maybe I am running into issues as described on "Known issues", "Callbacks from threads" - am I?
Thanks again for looking at this.
Regards Frank
Frank Goenninger frgo@me.com writes:
Me again ...
Doing
(ql:quickload :qt)
(qt:ensure-smoke :qtcore) (qt:ensure-smoke :qtgui)
(ql:quickload :qt-tutorial)
and finally
(qt-conv:main)
results in the following errors:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
Ok, so maybe I am running into issues as described on "Known issues", "Callbacks from threads" - am I?
Thanks again for looking at this.
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter stassats@gmail.com:
Frank Goenninger frgo@me.com writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line
1: ("foreign function: call_into_lisp")
from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ...
To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource).
I am still hoping for someone having had the same problem.
Thanks again for helping out.
Kind regards
Frank
Frank Gönninger frank.goenninger@consequor.de writes:
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter stassats@gmail.com:
Frank Goenninger frgo@me.com writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line
1: ("foreign function: call_into_lisp")
from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ...
It is a callback from the signal handler, which was triggered by the memory fault.
To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource).
You don't need the sources of Qt. You just need to have a single consistent Qt version for compiling and running smoke and commonqt.
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :(
On Sat, Apr 26, 2014 at 8:07 PM, Stas Boukarev stassats@gmail.com wrote:
Frank Gönninger frank.goenninger@consequor.de writes:
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter stassats@gmail.com:
Frank Goenninger frgo@me.com writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line
1: ("foreign function: call_into_lisp")
from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ...
It is a callback from the signal handler, which was triggered by the memory fault.
To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource).
You don't need the sources of Qt. You just need to have a single consistent Qt version for compiling and running smoke and commonqt.
-- With best regards, Stas.
Commonqt-devel mailing list Commonqt-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/commonqt-devel
Ivan Shvedunov ivan4th@gmail.com writes:
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :(
It is possible with threaded SBCL, the initial REPL thread is the main thread.
Indeed, sorry for my mistake. Note that when using SLIME the REPL you see in *slime-repl* buffer is not the main one. So you may try the code without SLIME to see whether the problem is indeed thread-related.
On Sat, Apr 26, 2014 at 8:25 PM, Stas Boukarev stassats@gmail.com wrote:
Ivan Shvedunov ivan4th@gmail.com writes:
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :(
It is possible with threaded SBCL, the initial REPL thread is the main thread.
-- With best regards, Stas.
commonqt-devel@common-lisp.net
-
Frank Goenninger -
Frank Gönninger -
Ivan Shvedunov -
Stas Boukarev