[Development] Request for Volunteers - Qt 5.0.2 Testing
Hello, We're planning to start Qt 5.0.2 framework testing on the 7th of March 2013, before the final release. I kindly ask all volunteers to send the answer to this email to me (rafal.mot...@digia.commailto:forename.surn...@digia.com). Any help will be highly appreciated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FW: Preparing Qt 5.0.2 release
Hi, Merge from stable to release branch is now done. Changes that are intended to get in for Qt 5.0.2 need to be pushed into release branch. Br, Akseli -Original Message- From: Salovaara Akseli Sent: 18. helmikuuta 2013 13:15 To: releas...@qt-project.org; development@qt-project.org Subject: [Development] FW: Preparing Qt 5.0.2 release Hi, We are delaying move into 'release' branch from today 18th of February to Wednesday 20th of February aiming to have more fixes for Qt 5.0.2 release. After Wednesday 20th February any changes that are required to get in for 5.0.2 need to be pushed into 'release' branch. Br, Akseli -Original Message- From: Salovaara Akseli Sent: 12. helmikuuta 2013 15:24 To: development@qt-project.org Subject: [Development] Preparing Qt 5.0.2 release -Original Message- From: Iikka Eklund Sent: 12. helmikuuta 2013 12:47 To: releas...@qt-project.org Subject: [Releasing] Preparing Qt 5.0.2 release Hi, Making of Qt 5.0.2 patch release has started: - Plan is to move into 'release' branch 18th February. So there is roughly 6 days left to get your fixes into 'stable' - After 18th February any changes that are required to get in for 5.0.2 need to be pushed into 'release' branch. Release team will then decide if the change will be taken in (P0, P1) - First 5.0.2 offline installers for testing will become available into: releases.qt-project.org/digia/5.0.2/ - Expected release time for 5.0.2 is in March - New reference installer is planned to be provided as well: Win8/msvc2012 64bit -- Br, Mr. Iikka Eklund Senior software engineer Email: iikka.ekl...@digia.com Visit us at: www.digia.com or qt.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- ___ Releasing mailing list releas...@qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On 21 February 2013 12:53, Turunen Tuukka tuukka.turu...@digia.com wrote: This is incorrect assumption as we have discussed this before making the RC1 - it just took a lot of time due to other release creation activities to continue the releasing work, so it seems that some persons (at least Thiago) just noticed it now when we are making RC2. The problem is that you never announced the SHA1 of the commits of the RC releases, and thus nobody immediately figured out that you were going to release from the digia branches, not the official ones. (You didn't even push the tags on the repository -- there are no v4.7.6-rc* or v4.6.5-rc* around.) What I do see instead that you *already pushed* the v4.7.6 and v4.6.5 tags without telling anyone, and those tags were created *more than one week* before the first message of this thread (in which you announced that you wanted to create release candidates): $ git show v4.7.6 tag v4.7.6 Tagger: Marko Valtanen marko.valta...@digia.com Date: Wed Dec 12 17:04:36 2012 +0200 Qt 4.7.6 opensource release commit 41d648720d9bd87381b85ade3da0d91456ff31e0 (tag: refs/tags/v4.7.6) $ git show v4.6.5 tag v4.6.5 Tagger: Marko Valtanen marko.valta...@digia.com Date: Wed Dec 12 12:27:38 2012 +0200 Qt 4.6.5 opensource release commit 63eb2e6a39c1a5bee6551cd6a7749a85856d5393 (tag: refs/tags/v4.6.5, refs/remotes/origin/4.6-digia) I don't have access to the reflog, but according to gitorious, they have been pushed the same day at 15:04 / 15:07 CET. Also, v4.7.6 seems to point at the wrong commit, as it's a commit outside any branch: $ git log --graph --oneline --decorate origin/4.7-digia v4.7.6 * 41d6487 (tag: v4.7.6) Changes-4.7.6 file updated * 436cf69 Fix binary incompatibility between openssl versions | * 090ca16 (origin/4.7-digia) Changes-4.7.6 file updated | * 7ce4690 Fix binary incompatibility between openssl versions |/ * b67ee40 updated LICENSE.PREVIEW.COMMERCIAL * cba3ada Nokia to Digia for LGPL-exception file So at the very least (no matter what we decide to do with the version numbering) that tag needs to be deleted and recreated. man git-tag at On Re-tagging offers a nice email template you could use for the purpose. Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
I'm not sure what you mean. OpenMP, Pthreads and Boost threads are independent; there is no backend here. Anyway, as Thiago mentioned in another post, OpenMP is not supported on all the compilers that Qt supports, so we can't use it in Qt. (http://openmp.org/wp/openmp-compilers/) Regards, Sze-Howe On 22 February 2013 03:16, Ing. Reynier Pupo Gomez rgo...@uci.cu wrote: The only problem that I see in OpenMP is it backend, Pthread. I think actually Qt switch form PThread to boost threads. But on the other side the code injected for programing with OMP is very simple. It is possible to develop a secuential program and prepare for parallel use with non-intrusive directives depending on a compilation flag. Im just starting with this library, so I cant help so much. On Viernes, 22 de febrero de 2013 12:15:19 AM usted escribió: On 21 February 2013 02:31, Ing. Reynier Pupo Gómez rgo...@uci.cu wrote: What about using of OpenMP standard? It could be very usefull and well known by the C/C++ comunity. Thanks for the suggestion. I had a quick look, but it seems to be on the low-level side. I'm not sure if we want to use #pragmas for regular code... Have you had experience with it? Is it easy to use? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On 20 February 2013 22:45, Sze Howe Koh szehowe@gmail.com wrote: Hi all, Some time ago there was some talk about improving Qt's multithreading API. I'm summarizing them here to stop them from fading into obscurity, and to see if there's any interest in following them up. Here are the tasks mentioned: - Replace/Rewrite QtConcurrent [2] - Create/Find a good API to replace QtConcurrent::run() for one-shot tasks [1] - Find a third-party solution for high-level multithreading [2] - Find more uses for QFuture, outside of QtConcurrent [3] - Influence C++1y by creating a nice multithreading API [4] Some suggestions were raised: - Put a Qt-ish wrapper around TBB [1] - Integrate ThreadWeaver back into Qt? [2] Separately, someone was experimenting with ways to spawn a QObject in a secondary thread, without first constructing it in the current thread [5] Do you think any of these avenues are worth pursuing? I've had a quick look at TBB vs. ThreadWeaver. The latter specializes in task-oriented programming, while TBB is a more swiss-army-knife toolkit, which includes container-based operations similar to QtConcurrent. So, if we're to integrate 3rd-party option into Qt, TBB would be more worth it (although it'd involve more work too) Actually, I just realized that the open-source flavour of TBB is licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing). Doesn't that mean that Qt TBB, if it were to become reality, can't be licensed under the LGPL? Regards, Sze-Howe [1] http://lists.qt-project.org/pipermail/development/2012-November/007901.html [2] http://lists.qt-project.org/pipermail/development/2012-November/007921.html [3] http://lists.qt-project.org/pipermail/development/2012-November/007944.html [4] http://lists.qt-project.org/pipermail/development/2012-November/007933.html [5] http://lists.qt-project.org/pipermail/interest/2013-January/005740.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 22-2-2013 11:57, Sze Howe Koh schreef:
On Feb 22, 2013 12:33 AM, Olivier Goffart oliv...@woboq.com wrote:
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.
I don't really like the need to create a watcher in order to get a
signal at all, to be honest. Never did.
My own implementation of a task-based system that I recently did,
involved returning a QSharedPointerTask from the task manager. Task
derives from QObject, and has signals and slots that can be used
notification. It is similar to QThread, in that it lives in the thread
that requested the task. It is inspired on QNetworkAccessManager, that
immediately gives back an instance of a reply that you can either
directly connect to or ignore.
Using a shared pointer gave me these advantages:
* No need for explicit deletes on either side: the requester can hold on
to the pointer and use it directly, or use a generic signal from the
task manager object that also contains a shared pointer to the same
task. When nobody is interested in the task object any more, it is
automatically deleted.
* Easily connect to signals like finished() or error() (though it would
be nice if you could directly connect to a
QSharedPointerQObjectDerivedClass instead of having to use .data() );
no need for a separate watcher object
* Value semantics, just like QFuture: a shared pointer is quite cheap to
pass around
Just like QFuture, it is possible to wait for the task to finish when
needed.
I'd really like to see such a structure in Qt, as generic as possible.
Tasks are not only relevant in the context of threads, but also for
things like network operations and perhaps even I/O operations,
printing, etc.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On 19.02.13 18:25, Frederik Gladhorn frederik.gladh...@digia.com wrote: See also my mail from two weeks ago ([Development] issue tracker rights). I think we need to make a few more adjustments and really need more people with bug triaging rights. Actually, there is a good reminder, since there were others concerns with the way how bugs are currently triaged. Peter was commenting about labels, for example. I would like to bring up another aspect. We (Qt in BlackBerry) are strongly considering to move known Qt issues from an internal tracker into https://bugreports.qt-project.org/ and later on, redirect Qt related issues reported by BackBerry developers into BlackBerry https://bugreports.qt-project.org/ as well. Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. Handling a few BlackBerry related issues which were already posted on https://bugreports.qt-project.org/, I started doubting if we can really use https://bugreports.qt-project.org/ for operations. The major problem is that the only what a normal user do is commenting on bugs. I know this topic is not directly related to the actual posting by Andy. I just wanted to raise my hand and underline that there are more triage related problems with https://bugreports.qt-project.org/ -- Vladimir Minenko Technical Manager, Qt http://developer.blackberry.com/qt +49 160 9898 3242 - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Preparing Qt 5.0.2 release
Merge from stable to release branch is now done. Changes that are intended to get in for Qt 5.0.2 need to be pushed into release branch. Now that the merge has done, doesn't this in effect mean that stable is now in reality Qt 5.1.0 based as dev will be merged to stable on 15th March? If that is the case, then shouldn't this be made clearer somewhere so it is pointed out that there is no plan for a Qt 5.0.3 release currently? Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On Wednesday 13 February 2013 08:49:56 Knoll Lars wrote: * Friday 22. February: If you have a larger feature/feature branch (not yet merged) that you want to have in the release you must have told the release team (by mail to releases@) by then. QLockFile is almost ready, I've been revising it countless times since initial submission, based on [conflicting...] feedback, can we aim at including it in 5.1 if I can get it merged soon? https://codereview.qt-project.org/46583 by mail to releases@ Did you mean releasing@ ? Nice trap :) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
2013/2/22 Sze Howe Koh szehowe@gmail.com:
Yes, that was my original plan. Someone complained that they couldn't
bind a function + arguments to QtConcurrent::run() first, then run it
at a later time. This approach gives them the opportunity to start it
whenever they want.
The problem is QtConcurrent does 2 separate things.
It binds function and run them asynchronously.
To me that's two different issues, so, if one want to bind a function
and run it later,
just use std::bind ( hence my QFunction patch for c++03 support )
On second thought, I'm not sure if this would be commonly needed. We
can make it start immediately instead, BUT this requires a guarantee
that the first thread can always connect the finished() signal, before
the new thread runs and finishes. Can that be guaranteed?
Think about QNetworkAccessManager :
reply = nam-get(url); // start the request
connect(reply, QNetworkReply::finished(), doSomething()); // you can
connect later
I think that work just fine because the connection is queued,
But I'm not sure exactly how.
If not,
we'll need:
QThread *thread = QThread::runFunction([]() { return
doSomethingComplicated(); });
connect(thread, QThread::finished, this, MyObject::doStuff);
thread-start(); // Manual start, after all connections have been made
OR
QThread *thread = QThread::runFunction([]() { return
doSomethingComplicated(); });
thread-wait(); // Wait for auto-started thread to end
doStuff();
The latter is like Corentin's approach using QFuture. Which is better?
(Personally I think the latter defeats the purpose of having a 2nd
thread)
Of course that was a silly example, you would connect the QFuture
finished signal
to a slot, or use QFutureSynchronizer to run run multiple treatments
concurrently.
Regarding deletion, we can follow the example of QAudioInput::start()
-- it returns a pointer to a QIODevice for reading, but retains
ownership of the device and auto-deletes it when stopped. Automatic
deletion is needed to prevent a memory leak in the nice simple pattern
you wrote above.
The implementation use the same sort of generator that QtConcurrent.
Thiago suggested making this feature only compatible C++11, which
would make it easier to maintain. I actually envisaged to send a mail
about that particular issue.
Can c++03 really be dropped for that particular feature ?
Also, I we were to make a c++11 only feature, what would be the
benefits over std::async ?
I would love to see an implementation using C++11. I think that
decision can't be made lightly though, and should be a separate
discussion -- it has implications for all other Qt modules.
What do you mean?
Do you mean an implementation of QThread that would use std::thread as an
internal rather than pthread/windows API? (qthread_cxx11.cpp)
Here again, two different issues.
1/ can we use the c++11 functional features and variadic templates
for the biding part.
2/ should we use the c++11 thread api somehow ( that looks like a huge
- unnecessary ? - change )
I think it would be good to have. But would just be another layer, and more
code to maintain.
I meant variadic templates and std::bind. QtConcurrent::run() uses a
code generator to produce 6 separate templates. In theory, we can
replace all that with 1 variadic template. No code generator, fewer
templates, less maintenance.
template typename TFunc, typename... TArgs
static QThread* setupSimpleThread(TFunc func, TArgs... args)
{
// Private class, derived from QThread
return new QFunctionThread(
std::bind(std::forwardTFunction(a_func),
std::forwardTArgs(a_args)...));
}
Exactly, there are real benefits to use c++11 only.
We do have many older compilers to support still. Is Qt ready to start
introducing features that require C++11? Are we in a position to drive
its adoption, as Thiago put it?
(http://www.macieira.org/blog/2011/09/cxx11-support-in-qt-5/)
QtConcurrent somehow does works so people with no c++11 support, could
still use that even if its not ideal.
I was actually wondering if QtConcurrent couldn't be upgraded/recycled
* adding QtConcurrent::runFunctionInNewThread(function, ...)
* adding QtConcurrent::runFunctionInThreadPool(QThreadPool* p,
function, ... )
* adding QtConcurrent::runFunctionInGlobalThreadPoool(function, ...);
* deprecating QtConcurrent::run and make it an alias of
QtConcurrent::runInGlobalThreadPoool
This way, QThread keeps its current purpose of exclusively handling thread.
(Or we could add another class or namespace, like QAsynchronous,
reusing QtConcurrent would meant keeping c++03 compat and its suppose
we will still return QFuture)
About returning QThread* : what about the function return value ? That
should be accessible, easily.
It's one of the reason I prefer QFuture over QThread*
Regards,
Corentin
Re: [Development] Evolving Qt's multithreading API
Op 22-2-2013 14:31, Corentin Jabot schreef:
On second thought, I'm not sure if this would be commonly needed. We
can make it start immediately instead, BUT this requires a guarantee
that the first thread can always connect the finished() signal, before
the new thread runs and finishes. Can that be guaranteed?
Think about QNetworkAccessManager :
reply = nam-get(url); // start the request
connect(reply, QNetworkReply::finished(), doSomething()); // you can
connect later
I think that work just fine because the connection is queued,
But I'm not sure exactly how.
It works for QNAM, because the request is guaranteed to be made async.
The work is only started when control is returned to the eventloop. For
this to work in the threading context, you'd have to make a similar
guarantee. Otherwise, you might end up in the situation that you start
the thread, and before the connection is made, the thread already
finishes, resulting in the slot never being called. That would result in
only starting the work in the other thread when either the result is
requested, or control is returned to the eventloop so you're sure all
connectes are made.
Alternatively, you'd have to start doing the work explicitly as written
here:
If not,
we'll need:
QThread *thread = QThread::runFunction([]() { return
doSomethingComplicated(); });
connect(thread, QThread::finished, this, MyObject::doStuff);
thread-start(); // Manual start, after all connections have been made
OR
QThread *thread = QThread::runFunction([]() { return
doSomethingComplicated(); });
thread-wait(); // Wait for auto-started thread to end
doStuff();
The latter is like Corentin's approach using QFuture. Which is better?
(Personally I think the latter defeats the purpose of having a 2nd
thread)
Of course that was a silly example, you would connect the QFuture
finished signal
to a slot, or use QFutureSynchronizer to run run multiple treatments
concurrently.
If only QFuture allowed you to connect... Unfortunately, it is not a
QObject.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
2013/2/22 André Somers an...@familiesomers.nl If only QFuture allowed you to connect... Unfortunately, it is not a QObject Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. I wonder why by the way: We could have something like QObject - QFutureBase (with all requiered signals/slots) - QFutureT or is there something I'm not seeing ? Of course now its too late, but we could introduce something new, like QFutureObject ? Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] pushing/staging around branching time (Re: [Releasing] Some CMake patches for 5.0.2)
On Fri, Feb 22, 2013 at 03:11:14PM +0100, Stephen Kelly wrote: I misunderstood the branch situation for Qt 5.0.2, and I pushed commits to stable which need to be in 5.0.2 (specifically 7661e39c022f76da34fcd5d38ecb93c86e01f1b7 and 7477d50fce9a0008ff4e050285e146ebc0c1e163 which fix a regression introduced in 316d8ececa3314ec16baf46ec4f1c5440cd951ef). Without those patches the cmake files are unusable, so they need to be in 5.0.2. The easiest way I can see to fix that situation is to fast-forward the release branch to 7661e39c022f76da34fcd5d38ecb93c86e01f1b7. As it is a fast-forward, all commits have already been through CI. i fast-forwarded the branch with akseli's permission after reviewing what i'd push. however, this was most definitely an exception, because it looked harmless and the release testing didn't really start yet. i also noticed at least one other change which had a fixed-in 5.0.2 in jira, which most definitely would not be in the release without magic/ugliness. what this means for *you*? *don't* stage anything which is aiming for timely release around the announced branching/merging time. when your change didn't make it before the deadline, abandon it immediately, and re-push for the release branch after successful branching was announced. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Preparing Qt 5.0.2 release
On Fri, Feb 22, 2013 at 12:36:07PM +, Shaw Andy wrote: Now that the merge has done, doesn't this in effect mean that stable is now in reality Qt 5.1.0 based as dev will be merged to stable on 15th March? this may very well happen, yes. it's still a good idea to push fixes to stable: a) you never know and b) distributors may pick them up even if we never make another release of the branch. conversely, this means that stable is still utterly taboo for features. If that is the case, then shouldn't this be made clearer somewhere so it is pointed out that there is no plan for a Qt 5.0.3 release currently? i think that would be moderately counter-productive in the light of the above paragraph. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] pushing/staging around branching time (Re: Some CMake patches for 5.0.2)
On Friday, February 22, 2013 15:39:57 Oswald Buddenhagen wrote: On Fri, Feb 22, 2013 at 03:11:14PM +0100, Stephen Kelly wrote: I misunderstood the branch situation for Qt 5.0.2, and I pushed commits to stable which need to be in 5.0.2 (specifically 7661e39c022f76da34fcd5d38ecb93c86e01f1b7 and 7477d50fce9a0008ff4e050285e146ebc0c1e163 which fix a regression introduced in 316d8ececa3314ec16baf46ec4f1c5440cd951ef). Without those patches the cmake files are unusable, so they need to be in 5.0.2. The easiest way I can see to fix that situation is to fast-forward the release branch to 7661e39c022f76da34fcd5d38ecb93c86e01f1b7. As it is a fast-forward, all commits have already been through CI. i fast-forwarded the branch with akseli's permission after reviewing what i'd push. however, this was most definitely an exception, because it looked harmless and the release testing didn't really start yet. Great, thanks for that. I know I got lucky this time. -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. But is that really feasible? You'd have to make sure it's a general Qt problem first and not related to some interaction with Blackberry specifics. Or the Qt bugtracker is fine with having vendor-specific components. Handling a few BlackBerry related issues which were already posted on https://bugreports.qt-project.org/, I started doubting if we can really use https://bugreports.qt-project.org/ for operations. The major problem is that the only what a normal user do is commenting on bugs. I know this topic is not directly related to the actual posting by Andy. I just wanted to raise my hand and underline that there are more triage related problems with https://bugreports.qt-project.org/ It would be an interesting experiment to just open up the bug handling privileges for most JIRA accounts, if not even all. I would assume people will use their privileges with care although some might start playing the close/reopen bugs game. ciao Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Preparing Qt 5.0.2 release
On sexta-feira, 22 de fevereiro de 2013 15.43.57, Oswald Buddenhagen wrote: On Fri, Feb 22, 2013 at 12:36:07PM +, Shaw Andy wrote: Now that the merge has done, doesn't this in effect mean that stable is now in reality Qt 5.1.0 based as dev will be merged to stable on 15th March? this may very well happen, yes. it's still a good idea to push fixes to stable: a) you never know and b) distributors may pick them up even if we never make another release of the branch. conversely, this means that stable is still utterly taboo for features. Indeed, there's still time to do a 5.0.3 if we wanted to. Here's a good question: should we tag/branch the stable branch just before the dev merge? Otherwise finding those commits later (think one year later) might be difficult. But this is the sign I was waiting for to switch my main development branch from stable to dev. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On sexta-feira, 22 de fevereiro de 2013 16.18.13, Michael Hasselmann wrote: On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. But is that really feasible? You'd have to make sure it's a general Qt problem first and not related to some interaction with Blackberry specifics. Or the Qt bugtracker is fine with having vendor-specific components. That's no different from any other bug report where we must determine whether the problem lies in Qt code or in the underlying platform (e.g., bionic shortcomings), or whether it lies in the application itself or third-party Qt- based libraries (e.g., kdelibs). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
However, std::function and std::bind were already in tr1, which AFAIK is already supported by all the compiler we support (Tier1 + Tier2) (MSVC 2008 and gcc 4.2 have it) For VC 2008 it is part of an add-on pack [1], but it is available. We could have something like QObject - QFutureBase (with all requiered signals/slots) - QFutureT or is there something I'm not seeing ? QObject is heavy - in terms of memory usage, construction/destruction cost etc. - if there are scenarios where you are creating thousands of such objects, this could be a problem. Regards, Rob. [1] http://www.microsoft.com/en-gb/download/details.aspx?id=6922 On 22 February 2013 14:28, Corentin Jabot corentin.ja...@gmail.com wrote: 2013/2/22 André Somers an...@familiesomers.nl If only QFuture allowed you to connect... Unfortunately, it is not a QObject Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. I wonder why by the way: We could have something like QObject - QFutureBase (with all requiered signals/slots) - QFutureT or is there something I'm not seeing ? Of course now its too late, but we could introduce something new, like QFutureObject ? Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On sexta-feira, 22 de fevereiro de 2013 15.28.44, Corentin Jabot wrote: 2013/2/22 André Somers an...@familiesomers.nl If only QFuture allowed you to connect... Unfortunately, it is not a QObject Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. I wonder why by the way: We could have something like QObject - QFutureBase (with all requiered signals/slots) - QFutureT or is there something I'm not seeing ? Of course now its too late, but we could introduce something new, like QFutureObject ? That's QFutureWatcher. The fact is that any QObject that is returned from those functions -- if any -- must belong to the calling thread. That implies the necessary guarantees in terms of signal emissions. For example, if the functions return a QObject pointer, a signal-signal connection from the actual target object's finished() signal to the returned object's finished() will apply the necessary queueing semantics. That also speaks against returning a QThread*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On sexta-feira, 22 de fevereiro de 2013 15.21.50, Olivier Goffart wrote: Variadic template, we can clearly not rely on it. It only came in MSVC really recently (patch release in nov 2012) Yes, we can rely on it. That just means MSVC 2012 RTM doesn't get the feature. As Marc put it, C++98 costs more. My suggestion is: design the API for C++11, then after it's done, we look into how much more is needed to support C++98. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On sexta-feira, 22 de fevereiro de 2013 19.26.06, Sze Howe Koh wrote: Actually, I just realized that the open-source flavour of TBB is licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing). Doesn't that mean that Qt TBB, if it were to become reality, can't be licensed under the LGPL? It's GPLv2+exceptions: The source code of Threading Building Blocks is distributed under version 2 of the GNU General Public License, with the so-called runtime exception, as follows (or see any header or implementation file): As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. I believe it's the same exception as the one in GNU libstdc++, -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for Volunteers - Qt 5.0.2 Testing
Rafal, will you tag your Qt 5.0.2 RC? If yes, I will provide a coverage report of QtBase between Qt 5.0.1 and this RC Regards, Sébastien Am 22.02.2013 um 10:33 schrieb Motyka Rafal rafal.mot...@digia.com: Hello, We're planning to start Qt 5.0.2 framework testing on the 7th of March 2013, before the final release. I kindly ask all volunteers to send the answer to this email to me (rafal.mot...@digia.com). Any help will be highly appreciated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for Volunteers - Qt 5.0.2 Testing
On sexta-feira, 22 de fevereiro de 2013 17.59.45, Sébastien Fricker wrote: will you tag your Qt 5.0.2 RC? Note that we changed again the release procedures after complaints on how we handled 5.0.1. There will be no 5.0.2 tags until the final release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Preparing Qt 5.0.2 release
On sexta-feira, 22 de fevereiro de 2013 10.52.38, Salovaara Akseli wrote: Merge from stable to release branch is now done. Changes that are intended to get in for Qt 5.0.2 need to be pushed into release branch. Please create the 5.0.3 entry in JIRA, even if we never actually make that release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
