[Development] CI broken again?
Hello, I'm trying for two days to merge this https://codereview.qt-project.org/77207 patch, but CI doesn't like me. It is a know issue or just me? Should I wait for other patches to be merged before I'll try the 8th time? :) Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
Something similar happened to me too on the dev branch. Tried merging a change. First a test case failed (tst_QDnsLookup) even though it runs fine on my local setup. I tried re-staging the change but now I got some merge errors. Local update of dev and rebase worked. -mandeep On Wed, Feb 5, 2014 at 2:50 PM, BogDan bog_dan...@yahoo.com wrote: Hello, I'm trying for two days to merge this https://codereview.qt-project.org/77207 patch, but CI doesn't like me. It is a know issue or just me? Should I wait for other patches to be merged before I'll try the 8th time? :) Cheers, BogDan. ___ 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] Improving toInt, toLong, etc.
The idea was to silently return a default-constructed type. I'm not keen on that. Aside from adding extra restrictions to the types that the class can be used with as you mention, it runs the much more severe risk of masking serious bugs. Regard, Rob. On 4 February 2014 23:12, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: On 2014-02-04 18:00, Matthew Woehlke wrote: (I might go with 'ifInvalid' though... ) Actually, I'll encourage defaultValue, for consistency with the containers (unless those got renamed?). On 2014-02-04 17:06, Thiago Macieira wrote: Em ter 04 fev 2014, às 16:04:11, Matthew Woehlke escreveu: However, now that I think about it, I still somewhat feel like value() should abort if disengaged, which would also allow a 'T value()' signature. (Maybe the 'const' version could still be as above, depending whether or not it's felt useful to avoid the return value being a copy.) I disagree. Existing value methods in Qt are all const and do not abort. I was thinking of http://qt-project.org/doc/qt-5/qmap-iterator.html#value :-). (I didn't check the code, but I suspect that aborts - perhaps implicitly by SEGV'ing - if the iterator is invalid?) That said, you still raise a fair point... so I guess it depends if you think QOptional should be more like a container or an iterator. I can live with the former, especially if operator*() returns T. A point for consideration on that note... iterators have an operator* which is an alias for (i.e. has same return type and semantics as) value() (or vice-versa). Containers don't have an operator* so that point doesn't apply. OTOH, iterators don't have a value(defaultValue). Again... I could go either way... -- Matthew ___ 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] Build Hotspots in the Qt build process
Hi Shane, thanks again for the presentation at FOSDEM. I really enjoyed it:-) The list of yours seems to be ordered alphabetically. I guess that is not necessarily the order in which we should look at the files:-) This list is rather long and slide 36 of your presentation shows that the files listed trigger between 90s and more than 8000s of rebuild time! That is two orders of magnitude difference, so if we look at this we should start by looking at those in the 8000s range:-) Could you generate a list of files sorted by hotness when you get back to your lab? Maybe the distance of the file's datapoint from the origin would be a good measure for that? That might need some normalizing though. I just went over your list and have not been overly surprised with which files are causing long rebuild times: All of them are header files that are widely used in Qt and by Qt applications. E.g. almost the complete set of non-private headers in qtbase/src/corelib is listed. There actually is one .cpp file in the list, which is rather unexpected. Seeing the same data for Qt webkit would also be cool. That is the part of code that feels like it is taking the longest to build in all of Qt:-) Best Regards, Tobias On Mon, Feb 3, 2014 at 10:39 PM, Shane McIntosh mcint...@cs.queensu.ca wrote: Hi Qt developers! My name is Shane. I’m a PhD student at Queen’s University in Canada. I’ve been working on an approach for detecting build hotspots, i.e., files that not only take a long time to rebuild, but also change often. We think that these files are ideal candidates for refactoring that could shave time off of incremental builds that are really impacting software teams. We came up with an approach that I presented last weekend at FOSDEM ( slides are available here: http://www.slideshare.net/shanemcintosh/identifying-hotspots-in-software-build-process ). One of the projects that we analyzed was Qt. I bumped into Tobias at FOSDEM and he suggested that I post the list of Qt hotspots here. So, I’ve made the hotspot list available here: http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt I’m happy to provide a more detailed Qt dataset when I return to my lab next week. Kind regards, -Shane P.S.: We are conducting a survey on how build performance is impacting developers ( http://is.gd/DbMRTr ). If you could spare 5 minutes to fill out our survey, we’d really appreciate it! ___ 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] Build Hotspots in the Qt build process
Hi Shane, On Monday 3. February 2014 22.39.27 Shane McIntosh wrote: Hi Qt developers! My name is Shane. I’m a PhD student at Queen’s University in Canada. I’ve been working on an approach for detecting build hotspots, i.e., files that not only take a long time to rebuild, but also change often. We think that these files are ideal candidates for refactoring that could shave time off of incremental builds that are really impacting software teams. We came up with an approach that I presented last weekend at FOSDEM ( slides are available here: http://www.slideshare.net/shanemcintosh/identifying-hotspots-in-software-bu ild-process ). One of the projects that we analyzed was Qt. I bumped into Tobias at FOSDEM and he suggested that I post the list of Qt hotspots here. So, I’ve made the hotspot list available here: http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt I’m happy to provide a more detailed Qt dataset when I return to my lab next week. Interesting stuff :) How do you determine that a particular header file is the hot spot? (I didn't understand that part from the slide set) Is that header file commonly included in other files that result in long-building object files? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
Hi John, I’ve now gone through all changes. The set looks pretty good overall, and testing on Linux showed no regressions compared to 5.2. IMO, you can go ahead and stage the first set of changes that are mainly cleanups. There are quite a few comments on the changes adding the new public API. Nothing major, but it would be good if you could go through the series and fix patches according to the comments. There’s also a compile error with QPageMargins that somehow is not catched on Linux (no idea why not). Friedemann said that there were still issues with printing on Windows (see comments on https://codereview.qt-project.org/#change,76913). Could you have a look at these things and update the patch set? Thanks! Lars On 30/01/14 09:35, Sorvig Morten morten.sor...@digia.com wrote: On 30 Jan 2014, at 01:15, John Layt jl...@kde.org wrote: I've just pushed a 33 commit change set for this to Gerrit, my apologies to the people I've tagged as reviewers :-) Any one else interested, feel free to jump in and help. There's 4 main new classes: * QPageSize * QPageMargins * QPageLayout * QPlatformPrintDevice, with backends for Windows, Mac and Cups These are then used in a fairly major rewrite of the platform and PDF print engines and QPrinter itself. I've tested these changes using my limited set of printers and some test painting code, but obviously I can't test for everything, especially the wide variety of drivers and the dodgy data they may return. I'd appreciate if people could check out the last commit in the chain [1] and see if it works OK with your printers and apps and report any problems back here. Thanks for the contribution! My initial impression is that it looks like a solid design and implementaiton. I’m not sure how to review it in detail - you are now the expert on Mac printing. We know from our work with the new platform plugins for Qt 5 that a re-implementation of existing functionality is unlikely to be bug-for-bug compatible. I can’t really say what the state is for printing, but I would like to avoid a situation where 5.3 improves in some areas but regresses in others. Have you considered keeping the current implementation side-by-side with the new one and adding an opt-in/opt-out mechanism for 5.3? This could then be accompanied with a blog post or other suitably public announcement that *now* is your chance to test and report bugs against the new printing implementation before the old one is removed. As a reviewer I will at least be more comfortable giving a +2 if I know that the new code will be field tested before becoming the only print support in Qt. Morten ___ 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] Build Hotspots in the Qt build process
Hi Tobias, On Feb 5, 2014, at 11:45 AM, Tobias Hunger tobias.hun...@gmail.com wrote: The list of yours seems to be ordered alphabetically. I guess that is not necessarily the order in which we should look at the files:-) This list is rather long and slide 36 of your presentation shows that the files listed trigger between 90s and more than 8000s of rebuild time! That is two orders of magnitude difference, so if we look at this we should start by looking at those in the 8000s range:-) Could you generate a list of files sorted by hotness when you get back to your lab? Maybe the distance of the file's datapoint from the origin would be a good measure for that? That might need some normalizing though. D’oh! You’re correct! Sorting by “hotness” is a great idea. I will try this out and share the results next week. I just went over your list and have not been overly surprised with which files are causing long rebuild times: All of them are header files that are widely used in Qt and by Qt applications. E.g. almost the complete set of non-private headers in qtbase/src/corelib is listed. True. It really isn’t too surprising that the corelib header files trigger slow rebuilds. Maybe it will be more useful when we sort by hotness. Perhaps there are specific corelib headers that will pop out. There actually is one .cpp file in the list, which is rather unexpected. Yes, that was an interesting one. My notes seem to suggest that that file is used in several test binaries. Perhaps that’s why its so slow to rebuild? Seeing the same data for Qt webkit would also be cool. That is the part of code that feels like it is taking the longest to build in all of Qt:-) Thanks for pointing this out. I will kick off a new analysis with Qt webkit included when I return to the lab :-) Kind regards, -Shane On Mon, Feb 3, 2014 at 10:39 PM, Shane McIntosh mcint...@cs.queensu.ca wrote: Hi Qt developers! My name is Shane. I’m a PhD student at Queen’s University in Canada. I’ve been working on an approach for detecting build hotspots, i.e., files that not only take a long time to rebuild, but also change often. We think that these files are ideal candidates for refactoring that could shave time off of incremental builds that are really impacting software teams. We came up with an approach that I presented last weekend at FOSDEM ( slides are available here: http://www.slideshare.net/shanemcintosh/identifying-hotspots-in-software-build-process ). One of the projects that we analyzed was Qt. I bumped into Tobias at FOSDEM and he suggested that I post the list of Qt hotspots here. So, I’ve made the hotspot list available here: http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt I’m happy to provide a more detailed Qt dataset when I return to my lab next week. Kind regards, -Shane P.S.: We are conducting a survey on how build performance is impacting developers ( http://is.gd/DbMRTr ). If you could spare 5 minutes to fill out our survey, we’d really appreciate it! ___ 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] Build Hotspots in the Qt build process
Hi Simon, On Feb 5, 2014, at 11:58 AM, Simon Hausmann simon.hausm...@digia.com wrote: On Monday 3. February 2014 22.39.27 Shane McIntosh wrote: Hi Qt developers! My name is Shane. I’m a PhD student at Queen’s University in Canada. I’ve been working on an approach for detecting build hotspots, i.e., files that not only take a long time to rebuild, but also change often. We think that these files are ideal candidates for refactoring that could shave time off of incremental builds that are really impacting software teams. We came up with an approach that I presented last weekend at FOSDEM ( slides are available here: http://www.slideshare.net/shanemcintosh/identifying-hotspots-in-software-bu ild-process ). One of the projects that we analyzed was Qt. I bumped into Tobias at FOSDEM and he suggested that I post the list of Qt hotspots here. So, I’ve made the hotspot list available here: http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt I’m happy to provide a more detailed Qt dataset when I return to my lab next week. Interesting stuff :) Thanks! :-) How do you determine that a particular header file is the hot spot? (I didn't understand that part from the slide set) Is that header file commonly included in other files that result in long-building object files? Specifically, we have a tool for extracting the build dependency graph from a concrete run of the build system. We then annotate the graph with timing information from each build command. Using this graph, we can figure out how long a rebuild will take if a developer changes any source file (add up the times of the edges triggered by changing a source file). We combine this rebuild time info with change frequency data we extract from the version control system (e.g., Git). The hotspots are then the files that change frequently (info from Git) and also rebuild slowly (info from the build dependency graph). Of course, we need to pick thresholds to identify the files that are too slow and change too much. For this experiment, we used the median number of changes and 90 second rebuild time. These thresholds might need some tweaking based on your development culture. For example, maybe 90 seconds is too low for your system? Kind regards, -Shane ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build Hotspots in the Qt build process
Hi Andre, On Feb 5, 2014, at 12:11 PM, Poenitz Andre andre.poen...@digia.com wrote: Shane McIntosh [mcint...@cs.queensu.ca] wrote: Hi Qt developers! My name is Shane. I’m a PhD student at Queen’s University in Canada. I’ve been working on an approach for detecting build hotspots, i.e., files that not only take a long time to rebuild, but also change often. We think that these files are ideal candidates for refactoring that could shave time off of incremental builds that are really impacting software teams. That sounds like a good idea in general. Looking at your list at http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt I wonder a bit how e.g. xmlpatterns can be considered a hotspot that according to your definition changes often. The actual code has not been changed much for a while except for occasional merges and the annual bumps in copyright headers. My gut feeling is that any refactoring there is not worthwhile. Thanks for your perspective! I’m certainly not an expert in Qt development and appreciate your perspective. This could perhaps be due to our use of the median number of changes as the threshold for rate of change. I’ll make the full dataset available when I return to my lab shortly, so we can explore together to find the most appropriate thresholds for Qt. I’m happy to provide a more detailed Qt dataset when I return to my lab next week. It would be nice to see some reason (numbers) why files ended up on the list. I’ll definitely include that data :-) Kind regards, -Shane ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of Qt3D?
Hi Sean, The project is far from dead. We are hacking on it right now, but given how much we want to change from Qt3D 1 we have been working on it in private. However, we are now about to begin upstreaming it to a non-CI controlled branch in the Qt3D repo. Is this non-CI branch already public? Is it still possible for Qt3D to be a part of Qt 5.3, I mean is it possible for a private feature/branch to be pushed on Qt just few days before the feature freeze, without reviews? I'm quite sure you're doing your best (give us some news if possible ;) ) Cheers, Sylvain ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On 05/02/14 13:59, Knoll Lars lars.kn...@digia.com wrote: Hi John, I’ve now gone through all changes. The set looks pretty good overall, and testing on Linux showed no regressions compared to 5.2. One correction here: The paperRect as shown in the preview of the dialogs manual test shows some slightly different results, that look like a rounding issue. Not sure whether that’s a problem that should be fixed or not, but you should have a look. IMO, you can go ahead and stage the first set of changes that are mainly cleanups. There are quite a few comments on the changes adding the new public API. Nothing major, but it would be good if you could go through the series and fix patches according to the comments. There’s also a compile error with QPageMargins that somehow is not catched on Linux (no idea why not). Friedemann said that there were still issues with printing on Windows (see comments on https://codereview.qt-project.org/#change,76913). Could you have a look at these things and update the patch set? Thanks! Lars On 30/01/14 09:35, Sorvig Morten morten.sor...@digia.com wrote: On 30 Jan 2014, at 01:15, John Layt jl...@kde.org wrote: I've just pushed a 33 commit change set for this to Gerrit, my apologies to the people I've tagged as reviewers :-) Any one else interested, feel free to jump in and help. There's 4 main new classes: * QPageSize * QPageMargins * QPageLayout * QPlatformPrintDevice, with backends for Windows, Mac and Cups These are then used in a fairly major rewrite of the platform and PDF print engines and QPrinter itself. I've tested these changes using my limited set of printers and some test painting code, but obviously I can't test for everything, especially the wide variety of drivers and the dodgy data they may return. I'd appreciate if people could check out the last commit in the chain [1] and see if it works OK with your printers and apps and report any problems back here. Thanks for the contribution! My initial impression is that it looks like a solid design and implementaiton. I’m not sure how to review it in detail - you are now the expert on Mac printing. We know from our work with the new platform plugins for Qt 5 that a re-implementation of existing functionality is unlikely to be bug-for-bug compatible. I can’t really say what the state is for printing, but I would like to avoid a situation where 5.3 improves in some areas but regresses in others. Have you considered keeping the current implementation side-by-side with the new one and adding an opt-in/opt-out mechanism for 5.3? This could then be accompanied with a blog post or other suitably public announcement that *now* is your chance to test and report bugs against the new printing implementation before the old one is removed. As a reviewer I will at least be more comfortable giving a +2 if I know that the new code will be field tested before becoming the only print support in Qt. Morten ___ 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
[Development] Qt 5.2.1 Qt Creator 3.0.1 released
Hi all, We are happy to announce that Qt 5.2.1 Qt Creator 3.0.1 is released today, see http://blog.qt.digia.com/blog/2014/02/05/qt-5-2-1-released/ http://blog.qt.digia.com/blog/2014/02/05/qt-creator-3-0-1-released/ Big thanks to everyone who has helped to make the releases happen! Br, Jani -- Jani Heikkinen Release Manager Digia Plc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Bug fixes to Stable or Dev branch?
Hi, I've seeing contradictory advice on Gerrit as to which branch to push bug- fixes to, some say there will be no 5.2.2 so to use dev instead, others say to keep using stable in case there is. What is the current official policy? Oh, and please remember when making such decisions to clearly communicate them to this list, not everyone is in the office or on IRC. Thanks! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] qmlx11 plugin
On 5 Feb 2014, at 11:16 AM, Damian Ivanov wrote: Hi, I made a c++ QML plugin for X11 functions like windowlist, active window, setting, getting icon of apps, names, id and setting netwm properties. Source code is here https://build.opensuse.org/package/show/home:damianator:qmlx11/qmlx11 Right now you can do all the stuff mentioned already, but the windowList and the window properties are not updated automatically via XEvent's instead hackishly I have a Timer reloading the active window and the windowList every few seconds. Could anyone interested assist me in properly receiving the XEvent's so the qmlx11 plugin properly emits signals according to the received XEvent's (actually that's not the problem, but I couldn't manage to receive the XEvents at all). Personally I wish we had some of that as QPA APIs (at least window list and window icons), but of course it assumes that we can do the same thing on the other platforms. In my experience, the window list is tricky stuff on X11 though, because there are so many windows you don't normally want to show in a task list. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug fixes to Stable or Dev branch?
For now the policy is still to push to stable. We haven’t made any decision on whether to do or not do a 5.2.2 release yet, but it’s something we need to figure out rather soon. Cheers, Lars On 05/02/14 15:55, John Layt jl...@kde.org wrote: Hi, I've seeing contradictory advice on Gerrit as to which branch to push bug- fixes to, some say there will be no 5.2.2 so to use dev instead, others say to keep using stable in case there is. What is the current official policy? Oh, and please remember when making such decisions to clearly communicate them to this list, not everyone is in the office or on IRC. Thanks! John. ___ 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] Bug fixes to Stable or Dev branch?
On 5 February 2014 15:55, John Layt jl...@kde.org wrote: Hi, I've seeing contradictory advice on Gerrit as to which branch to push bug- fixes to, some say there will be no 5.2.2 so to use dev instead, others say to keep using stable in case there is. What is the current official policy? Oh, and please remember when making such decisions to clearly communicate them to this list, not everyone is in the office or on IRC. The policy didn't change, see Where to push a change? http://qt-project.org/wiki/Branch-Guidelines It doesn't matter that 5.2.2 is not planned. If the change qualifies for stable, push it to stable. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug fixes to Stable or Dev branch?
We have the branch model to make it easy to choose the right branch, usually without worrying about the releases too much. Normal bug fixes go always to stable. Stable is guaranteed to be merged into dev before the next release, so you'll never have to worry, no patch gets lost. Show stoppers just before the release might have to go into the release branch, this should really be the exception. Sometimes a bug is less critical and/or involves huge changes, these may have to go into the dev branch pending the approvers and your judgement. By the way, I heard quite a few requests for more patch releases, maybe we should aim for 5.2.2 with hopefully only stability improvements. Greetings, Frederik From: development-bounces+frederik.gladhorn=digia@qt-project.org [development-bounces+frederik.gladhorn=digia@qt-project.org] on behalf of Giuseppe D'Angelo [dange...@gmail.com] Sent: Wednesday, February 05, 2014 4:19 PM To: jl...@kde.org Cc: development@qt-project.org Subject: Re: [Development] Bug fixes to Stable or Dev branch? On 5 February 2014 15:55, John Layt jl...@kde.org wrote: Hi, I've seeing contradictory advice on Gerrit as to which branch to push bug- fixes to, some say there will be no 5.2.2 so to use dev instead, others say to keep using stable in case there is. What is the current official policy? Oh, and please remember when making such decisions to clearly communicate them to this list, not everyone is in the office or on IRC. The policy didn't change, see Where to push a change? http://qt-project.org/wiki/Branch-Guidelines It doesn't matter that 5.2.2 is not planned. If the change qualifies for stable, push it to stable. -- Giuseppe D'Angelo ___ 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] Removing MSVC2008 from the CI build farm?
Hello guys Is it maybe time to get rid of MSVC 2008 from our build farm? Do the new versions support wince builds? c:\work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian.cp p(140) : fatal error C1001: An internal error has occurred in the compiler. Build log: http://testresults.qt-project.org/ci/QtBase_dev_Integration/build_02794/w ince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build Hotspots in the Qt build process
Em qua 05 fev 2014, às 14:17:20, Shane McIntosh escreveu: I just went over your list and have not been overly surprised with which files are causing long rebuild times: All of them are header files that are widely used in Qt and by Qt applications. E.g. almost the complete set of non-private headers in qtbase/src/corelib is listed. True. It really isn’t too surprising that the corelib header files trigger slow rebuilds. Maybe it will be more useful when we sort by hotness. Perhaps there are specific corelib headers that will pop out. Well, qglobal.h and everything that that file includes are, of course, hot but there isn't much we can do. Those files are: qconfig.h \ qfeatures.h \ qprocessordetection.h \ qglobal.h \ qsystemdetection.h \ qcompilerdetection.h \ qtypeinfo.h \ qsysinfo.h \ qlogging.h \ qflags.h \ qtypetraits.h \ qatomic.h \ qbasicatomic.h \ qatomic_bootstrap.h \ qgenericatomic.h \ qatomic_msvc.h \ qatomic_armv7.h \ qatomic_armv6.h \ qatomic_armv5.h \ qatomic_ia64.h \ qatomic_mips.h \ qatomic_x86.h \ qatomic_cxx11.h \ qatomic_gcc.h \ qatomic_unix.h \ qglobalstatic.h \ qmutex.h \ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Improving toInt, toLong, etc.
Em qua 05 fev 2014, às 10:37:27, Robert Knight escreveu: The idea was to silently return a default-constructed type. I'm not keen on that. Aside from adding extra restrictions to the types that the class can be used with as you mention, it runs the much more severe risk of masking serious bugs. No way around it if we exclude exceptions. We need to return something. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build Hotspots in the Qt build process
Em qua 05 fev 2014, às 11:58:50, Simon Hausmann escreveu: Hi Shane, Interesting stuff :) How do you determine that a particular header file is the hot spot? (I didn't understand that part from the slide set) Is that header file commonly included in other files that result in long-building object files? Hello Shane I'm with Simon, this is very interesting stuff! I'm wondering if we could make use of your data to figure out what headers we should precompile. You said you extract a graph from the build: is there a way to parse that graph to produce a list of headers most commonly included in a given module? We've had precompilation support in qmake for a decade, but apparently we use that in exactly 3 modules... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug fixes to Stable or Dev branch?
Hi, Regarding Qt 5.2.2 - let's see how well 5.2.1 is received. We have now 1,5 months shorter cycle than the usual 6 months for Qt 5.3. I agree that it was a long wait between 5.1.1 and 5.2.0. Yours, Tuukka Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org [development-bounces+tuukka.turunen=digia@qt-project.org] k#228;ytt#228;j#228;n Gladhorn Frederik [frederik.gladh...@digia.com] puolesta Lähetetty: 5. helmikuuta 2014 17:46 Vastaanottaja: development@qt-project.org Aihe: Re: [Development] Bug fixes to Stable or Dev branch? We have the branch model to make it easy to choose the right branch, usually without worrying about the releases too much. Normal bug fixes go always to stable. Stable is guaranteed to be merged into dev before the next release, so you'll never have to worry, no patch gets lost. Show stoppers just before the release might have to go into the release branch, this should really be the exception. Sometimes a bug is less critical and/or involves huge changes, these may have to go into the dev branch pending the approvers and your judgement. By the way, I heard quite a few requests for more patch releases, maybe we should aim for 5.2.2 with hopefully only stability improvements. Greetings, Frederik From: development-bounces+frederik.gladhorn=digia@qt-project.org [development-bounces+frederik.gladhorn=digia@qt-project.org] on behalf of Giuseppe D'Angelo [dange...@gmail.com] Sent: Wednesday, February 05, 2014 4:19 PM To: jl...@kde.org Cc: development@qt-project.org Subject: Re: [Development] Bug fixes to Stable or Dev branch? On 5 February 2014 15:55, John Layt jl...@kde.org wrote: Hi, I've seeing contradictory advice on Gerrit as to which branch to push bug- fixes to, some say there will be no 5.2.2 so to use dev instead, others say to keep using stable in case there is. What is the current official policy? Oh, and please remember when making such decisions to clearly communicate them to this list, not everyone is in the office or on IRC. The policy didn't change, see Where to push a change? http://qt-project.org/wiki/Branch-Guidelines It doesn't matter that 5.2.2 is not planned. If the change qualifies for stable, push it to stable. -- Giuseppe D'Angelo ___ 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] Improving toInt, toLong, etc.
On Wednesday 05 February 2014 09:44:39 Thiago Macieira wrote:
Em qua 05 fev 2014, às 12:36:42, Matthew Woehlke escreveu:
On 2014-02-05 12:19, Thiago Macieira wrote:
Em qua 05 fev 2014, às 10:37:27, Robert Knight escreveu:
The idea was to silently return a default-constructed type.
I'm not keen on that. Aside from adding extra restrictions to the
types that the class can be used with as you mention,
it runs the much more severe risk of masking serious bugs.
No way around it if we exclude exceptions.
We need to return something.
...or you could abort, which I assume is what operator* does?
That doesn't help.
First, Q_ASSERT() is eliminated in a debug build, so we're left with no
abort.
Second, even if we stick a real call to qFatal() there, we don't have the
noreturn annotation in all compiles -- particularly, it's not there for
MSVC because qFatal *can* return there. That means we still must return
something.
You will just have an undefined behaviour. You will return the content of the
uninitialized memory cast to the type, and it will likely cause a crash later.
Debug build will abort, release build will probably crash somehow too.
Same as QList::at()
// possible implementation
T QOptionalT::operator*() {
Q_ASSERT(isValid());
return reinterpret_castT(data);
};
--
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] Improving toInt, toLong, etc.
On 2014-02-05 12:19, Thiago Macieira wrote: Em qua 05 fev 2014, às 10:37:27, Robert Knight escreveu: The idea was to silently return a default-constructed type. I'm not keen on that. Aside from adding extra restrictions to the types that the class can be used with as you mention, it runs the much more severe risk of masking serious bugs. No way around it if we exclude exceptions. We need to return something. ...or you could abort, which I assume is what operator* does? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Improving toInt, toLong, etc.
Em qua 05 fev 2014, às 09:44:39, Thiago Macieira escreveu: First, Q_ASSERT() is eliminated in a debug build, so we're left with no abort. I meant release build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Improving toInt, toLong, etc.
Em qua 05 fev 2014, às 12:36:42, Matthew Woehlke escreveu: On 2014-02-05 12:19, Thiago Macieira wrote: Em qua 05 fev 2014, às 10:37:27, Robert Knight escreveu: The idea was to silently return a default-constructed type. I'm not keen on that. Aside from adding extra restrictions to the types that the class can be used with as you mention, it runs the much more severe risk of masking serious bugs. No way around it if we exclude exceptions. We need to return something. ...or you could abort, which I assume is what operator* does? That doesn't help. First, Q_ASSERT() is eliminated in a debug build, so we're left with no abort. Second, even if we stick a real call to qFatal() there, we don't have the noreturn annotation in all compiles -- particularly, it's not there for MSVC because qFatal *can* return there. That means we still must return something. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt-5.2.1 + mingw-w64 builds
Hi! Trying build Qt-5.2.1 with mingw-w64 GCC-4.8.2 I got error linking Qt5Test library for both 32 and 64 bit. I fill bug report: https://bugreports.qt-project.org/browse/QTBUG-36661 Regards, Alexey. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Optional (was RE: Improving toInt, toLong, etc.)
I've followed std::optional closely through the standardization process, so I
can give some background info:
- from the beginning Boost::optional was written with a pointer-like syntax:
optionalint op = maybe_get_the_value();
if (op) {
int x = *op;
...
}
The original Boost author felt *strongly* that a pointer-like API would be
best, as developers are familiar with the paradigm.
- optional's constructor allows *implicit* conversion from T, for various
reasons, including so that it is easy to change a function that takes a T into
a function that takes an optionalT.
// version 1:
int function(int);
// version 2:
int function(optionalint);
// my code:
int x = function(17); // works with both versions
- Assuming optionalT == optionalT exists, then implicit constructors means
that things like optionalT == T automatically work (T is implicitly converted
to optionalT)
so optionalbool(false) == bool(false) can compile. But that has the
confusion with if (op). Which is done as an _explicit_ bool conversion.
Once you have == and !=, the next question is ,,=,=. It is easy to say we
don't want/need these. HOWEVER...
We want operator() so that optionals can be placed into ordered containers, be
sorted, etc. More precisely, we want std::less to work. But if std::less
works, shouldn't operator() as well (and shouldn't they give the same results!)
... note that there are some rare cases that std::less works, but operator()
doesn't - ie pointers (in general). Also, sooner or later, probably
std::complex will be similar. (Currently std::complex can't be used as a key
in map, giving it std::less would fix that. But we don't want complex to have
operator() as it doesn't really make sense...)
Overall, optional can be seen in many ways:
1.Just a T with deferred initialization / lifetime management.
2.A discriminated union of types nullopt_t and T.
3.A container of T's with the maximum size of 1.
4.A type T+ which is the same as T, but with one more value
The interface of std::experimental::optional is most closely aligned with 1 and
4. It definitely doesn't have much container interface (like
begin/end/iterator/...).
1 is what optional really is, everything else is extending it to try to be more
than that.
It is really 1 because op = 17 does construction or assignment depending on
whether the optional was already engaged or not. If your class handles
construction and assignment differently, this is an important distinction. (Of
course most types are Regular so not an issue.)
Oh, and then there are (or are not) optionalT types to consider. The
standard is avoiding those for now. (Note that T is not Regular, and that for
references construction and assignment of are different!)
And yes, these issues are why it is in a TS instead of C++14.
Tony
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of Qt3D?
+1 On Wednesday, February 5, 2014, Sylvain THIBAUT sylvain.thib...@amplitude-ortho.com wrote: Hi Sean, The project is far from dead. We are hacking on it right now, but given how much we want to change from Qt3D 1 we have been working on it in private. However, we are now about to begin upstreaming it to a non-CI controlled branch in the Qt3D repo. Is this non-CI branch already public? Is it still possible for Qt3D to be a part of Qt 5.3, I mean is it possible for a private feature/branch to be pushed on Qt just few days before the feature freeze, without reviews? I'm quite sure you're doing your best (give us some news if possible ;) ) Cheers, Sylvain ___ Development mailing list Development@qt-project.org javascript:; 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] QML Audio on Android
I have the same question.
Interesting that assets:/ is used in both android and blackberry 10...
It would be nice if we could get assets:/ to work on the desktop platforms
also,
perhaps by packaging the assets into an accompanying .zip file so it
doesn't cause memory bloat on the executable.
On Tue, Feb 4, 2014 at 2:40 PM, Bruno Coudoin bruno.coud...@gcompris.netwrote:
Le 04/02/2014 08:51, nic...@nicoladefilippo.it a écrit :
Hi,
put your file in android/assets directory and from qml:
MediaPlayer {
id: playMusic
source: assets:/example.mp3
}
Thanks, it works, next question, what is the proper way to manage a list
of sounds in a platform independent way at the .pro level.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Audio on Android
Hi,
Looking at the latest release 5.2.1 the Audio in QRC has been fixed:
https://bugreports.qt-project.org/browse/QTBUG-31422
I have not tested yet, I was in the process of managing the issue in my
application and is is not that easy. I hope the QRC way is working fine.
Bruno.
Le 05/02/2014 21:52, Alan Ezust a écrit :
I have the same question.
Interesting that assets:/ is used in both android and blackberry 10...
It would be nice if we could get assets:/ to work on the desktop
platforms also,
perhaps by packaging the assets into an accompanying .zip file so it
doesn't cause memory bloat on the executable.
On Tue, Feb 4, 2014 at 2:40 PM, Bruno Coudoin
bruno.coud...@gcompris.net mailto:bruno.coud...@gcompris.net wrote:
Le 04/02/2014 08:51, nic...@nicoladefilippo.it
mailto:nic...@nicoladefilippo.it a écrit :
Hi,
put your file in android/assets directory and from qml:
MediaPlayer {
id: playMusic
source: assets:/example.mp3
}
Thanks, it works, next question, what is the proper way to manage
a list
of sounds in a platform independent way at the .pro level.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Improving toInt, toLong, etc.
Em qua 05 fev 2014, às 14:28:36, Matthew Woehlke escreveu:
You will just have an undefined behaviour. You will return the content of
the uninitialized memory cast to the type, and it will likely cause a
crash later. Debug build will abort, release build will probably crash
somehow too. Same as QList::at()
// possible implementation
T QOptionalT::operator*() {
Q_ASSERT(isValid());
return reinterpret_castT(data);
};
Right. I don't see why this seems to be a problem here, but is not for
e.g. an invalid iterator, or at() / operator[] on a container with an
invalid index. Just do what those do.
Fair enough. I hadn't thought of the solution Olivier gave, to be honest.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Audio on Android
Em qua 05 fev 2014, às 12:52:07, Alan Ezust escreveu: I have the same question. Interesting that assets:/ is used in both android and blackberry 10... It would be nice if we could get assets:/ to work on the desktop platforms also, perhaps by packaging the assets into an accompanying .zip file so it doesn't cause memory bloat on the executable. It should either redirect to QRC or to an platform-specific file search methodology. That's what we have QStandardPaths for. assets:/ should be no more than QStandardPaths::locate(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Postponing QOptional till after 5.3
I don't have the time to write the class, the docs, the unit tests, fix all the issues we've found, integrate it with QVariant and possibly QtDBus in the next week. So I'll just proceed to add overloads to toInt family that take an int* instead of bool*. If we decide to add QOptional overloads to them in Qt 5.4, that will be great. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
I’ve now gone through all changes. The set looks pretty good overall, and testing on Linux showed no regressions compared to 5.2. One correction here: The paperRect as shown in the preview of the dialogs manual test shows some slightly different results, that look like a rounding issue. Not sure whether that’s a problem that should be fixed or not, but you should have a look. IMO, you can go ahead and stage the first set of changes that are mainly cleanups. There are quite a few comments on the changes adding the new public API. Nothing major, but it would be good if you could go through the series and fix patches according to the comments. There’s also a compile error with QPageMargins that somehow is not catched on Linux (no idea why not). Friedemann said that there were still issues with printing on Windows (see comments on https://codereview.qt-project.org/#change,76913). Could you have a look at these things and update the patch set? I've also gone through some of the changes and ran the tests on the full set on Mac, I put in the comments I had so far. It generally looks good but once the dust settles on the ones needing changes I'll do a proper test of the functionality on Mac as well to check that actual printing works fine too. I have some things in mind to check as I've dealt with enough printing problems the past year to last me a life time ;) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Audio on Android
Le 05/02/2014 21:58, Bruno Coudoin a écrit : Hi, Looking at the latest release 5.2.1 the Audio in QRC has been fixed: https://bugreports.qt-project.org/browse/QTBUG-31422 I have not tested yet, I was in the process of managing the issue in my application and is is not that easy. I hope the QRC way is working fine. Hi, I just tested with 5.2.1 and there is 2 major issues (tested on Desktop Linux): - Cannot play an ogg vorbis file in a qrc while it works from a file (Could not demultiplex stream.) - A qrc sound is only played once. Should I report a bug for these? Bruno. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Audio on Android
Le 06/02/2014 00:15, Bruno Coudoin a écrit : Le 05/02/2014 21:58, Bruno Coudoin a écrit : Hi, Looking at the latest release 5.2.1 the Audio in QRC has been fixed: https://bugreports.qt-project.org/browse/QTBUG-31422 I have not tested yet, I was in the process of managing the issue in my application and is is not that easy. I hope the QRC way is working fine. Hi, I just tested with 5.2.1 and there is 2 major issues (tested on Desktop Linux): - Cannot play an ogg vorbis file in a qrc while it works from a file (Could not demultiplex stream.) - A qrc sound is only played once. Should I report a bug for these? Another test on Android (Nexus 5 / 4.4.2) with a different set of issues: - The Audio are auto played by defaults, even if we force autoPlay to false - The ogg vorbis sound plays fine - It is not possible to control the volume once the application is started. Overall its way better than with the previous release. Bruno. - Cannot ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing MSVC2008 from the CI build farm?
There are still some very large enterprise users running on vc2008 build systems. Would this mean that all hope for building new releases on vc2008 would be lost, or that it just may take more effort than normal? As it stands, I had to apply some manual fixes to get 5.1 to build with vc2008, but it wasn't the end of the world. My $0.02 is that it may be a year or two too early to completely kick vc2008. After all, it's still the compiler which ships with the Windows 7 .NET 3.5 SDK... On Wed, Feb 5, 2014 at 11:50 AM, Thiago Macieira thiago.macie...@intel.comwrote: Hello guys Is it maybe time to get rid of MSVC 2008 from our build farm? Do the new versions support wince builds? c:\work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian.cp p(140) : fatal error C1001: An internal error has occurred in the compiler. Build log: http://testresults.qt-project.org/ci/QtBase_dev_Integration/build_02794/w ince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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
