Re: [Development] Evolving Qt's multithreading API
Op 22-2-2013 11:57, Sze Howe Koh schreef:
Some more common use case would be (pseudo-code)
auto watcher = new QFutureWatcher;
QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
watcher-setFuture(QThrerad::run([]() { return computeStuff(); } ));
// who deletes the watcher?
If the caller creates the watcher, I think it's fine to let the caller
delete it too. It's an ordinary C++ practice.
Actually, how do you feel about adding an optional _then_ argument to
the list of arguments of the functions in QtConcurrent and whatever is
decided to replace the QtConcurrent::run feature? Such a _then_ argument
could be a slot signature, a function pointer or a lambda function
(basically, whatever you can use in the Qt 5 QObject::connect). That
would make it quite a bit easier to work with, I think. It would
eliminate the need to create (and delete) a QFutureWatcher for a lot of
cases. The method you passed into the _then_ argument would be called
when the future is ready. It would be very nice if the _then_ argument
could optionally have an argument of the return type of QFuture::result.
For this to work, QFuture would not need to be a QObject itself, and
because you pass in the _then_ argument with the call itself, you don't
have the race issues that you get if you need to connect in separate
calls after you have already fired off the thread: no need for
trampoline objects or the like.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Failure in tst_qwidget
On Saturday 02 March 2013 09:45:28 Alberto Mardegan wrote: Hi all! The CI bot reported a failure in tst_qwidget when merging https://codereview.qt-project.org/#change,42990,patchset=8 (see the last comment from Qt Continuous Integration System). I can reproduce the same failure under ubuntu 13.04 running XFCE. Then I removed my patch (by checking out an older version of the dev branch, c65ecc50ae4c322294f01685a2b2d2a748a9c940), and ran make clean from the qtbase root directory. After having rebuild everything (by just running make), I tried running the tst_qwidget again, but I still get the same failure. Interestingly, the failure does not occur if I run the individual test which is failing (both with my patch and without): tests/auto/widgets/kernel/qwidget$ ./tst_qwidget showHideShowX11 * Start testing of tst_QWidget * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QWidget::initTestCase() PASS : tst_QWidget::showHideShowX11() PASS : tst_QWidget::cleanupTestCase() Totals: 3 passed, 0 failed, 0 skipped * Finished testing of tst_QWidget * So, I wonder: 1) Did I take to correct steps to rebuild qtbase? 2) Did someone else experience this failure as well? Or is it definitely related to my patch? 3) Any idea why the individual test works? Could it be a WM timing issue? I beleive the test is unstable. That means that it may often passes, but on some cases, it does not. If i understand the test properly, it waits two seconds for a window to receive some events. But it may very well happen that the seconds are not enough, because the tests are run on some busy virtual machine or because the window manager is busy or anything. The test should be stabilized by sending a signal when they receive an event, and waiting for this event to be received. Test that waits an arbitrary amount of time are flawed. It can either be too small and then the test is unstable, or too long and then the running time of the tests increase. (If every test was taking two second, the CI system would take forever) It is better to fire stop the event loop when the condition is met, or use QTRY_VERIFY or something. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On Fri, Mar 1, 2013 at 3:50 PM, Thiago Macieira
thiago.macie...@intel.comwrote:
On sexta-feira, 1 de março de 2013 10.52.41, Olivier Goffart wrote:
qdisplayinfo_linux.cpp:50 is:
Q_GLOBAL_STATIC_WITH_ARGS(const QString, BACKLIGHT_SYSFS_PATH,
(QStringLiteral(/sys/class/backlight/)))
Is that something we should fix in Q_GLOBAL_STATIC_WITH_ARGS ? or should
we jsut say that lambda expressions or QStringLiteral are not allowed in
Q_GLOBAL_STATIC_WITH_ARGS ?
It's just too much overhead the way it's written. It's much simpler as:
static QString backlightSysfsPath()
{
return QStringLiteral(/sys/class/backlight/);
}
QStringLiteral is optimised for that case.
Actually, there was a change submitted about a month ago for this issue
apparently: https://codereview.qt-project.org/#change,46455
Laszlo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Remote use of resources for cross-platform checking of solutions.
Hello, guys. I have an interesting question for Digia. Can Digia provide a collection of several servers (hosts) with a fixed set of multiple operating systems? For example, three host with three OS: Linux, Windows, MacOSX, and give them remote access to some third-party developers to contribute to Qt. For example, for us (QtSerialPort developers) the MacOSX is a deficit OS, and we will not can be able to quickly check and correct some have reported errors. For remote access, suggest using TeamViewer. Or, if this is not possible, may be someone of the users (from community) can be provide the resources of its OS to solve problems? Best regards, Denis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remote use of resources for cross-platform checking of solutions.
On 2 March 2013 18:41, Denis Shienkov scap...@yandex.ru wrote: For remote access, suggest using TeamViewer. Or, if this is not possible, may be someone of the users (from community) can be provide the resources of its OS to solve problems? I don't own a Mac, but I have one at my work place. I could test some stuff myself for you, but I'm afraid getting a remote session will not be possible (company network, firewalls, etc.). And, I'm there only in office hours, of course (~7-15 CET/ CEST). sierdzio ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On Sat, Mar 2, 2013 at 3:34 PM, Laszlo Papp lp...@kde.org wrote: I will take you meant QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/license/tst_licenses.pl Yeah, I used this script earlier, but I did not know it is already integrated into the CI. Couldn't this be integrated into a bot rather than CI? It would be nice to know even before pressing the staging button. It does not seem to run long either. Sure, there is a long standing task for that, https://bugreports.qt-project.org/browse/QTQAINFRA-309 . It just waits for somebody to do the work. The current sanity bot has all checks implemented in a couple of big loops and is not designed to call out to separate scripts, so this task may include some refactoring of the sanity bot. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
