[Development] How long until clang memory model is ready?

Chris L hackthegovernment at hotmail.com
Wed Jan 22 00:39:07 CET 2014


With clang getting complete draft c++14 support, is the memory model sufficient to move to using it by default?  Things like unique_ptr and vector really need this.

> From: development-request at qt-project.org
> Subject: Development Digest, Vol 28, Issue 80
> To: development at qt-project.org
> Date: Tue, 21 Jan 2014 22:25:43 +0100
> 
> Send Development mailing list submissions to
> 	development at qt-project.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> 	development-request at qt-project.org
> 
> You can reach the person managing the list at
> 	development-owner at qt-project.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: How to write a ChangeLog entry (Thiago Macieira)
>    2. Re: frozen tickets on bugreports.qt-project.org in
>       qt-mobility and qt-components (Alan Ezust)
>    3. Re: Prettier printing of Unicode strings (Matt Broadstone)
>    4. Re: Remove OSX 10.6 Build? (Allan Sandfeld Jensen)
>    5. Re: Prettier printing of Unicode strings (Thiago Macieira)
>    6. Re: How to write a ChangeLog entry (Samuel Gaist)
>    7. Re: Remove OSX 10.6 Build? (Samuel Gaist)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 21 Jan 2014 08:58:19 -0800
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] How to write a ChangeLog entry
> To: development at qt-project.org
> Message-ID: <9266008.RhvVODRkx8 at tjmaciei-mobl2>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On ter?a-feira, 21 de janeiro de 2014 08:09:43, Blasche Alexander wrote:
> > Why are you pushing change log items for modules outside of qtbase to
> > qtbase?
> > 
> > http://qt-project.org/wiki/Change-files-in-Qt-5.2
> > 
> > clearly accumulates the various files from the various git repos.
> 
> I'm editing everything in one file so it's easier for me, but I'll split them 
> to each module after we're done.
> 
> Someone will have to put it back together to publish the Qt 5.2.1 changelog in 
> the website, alongside the download packages.
> 
> > >> QtBluetooth
> > >> -----------
> > >> 
> > >>  - Documentation:
> > >>    * Fix cases where device and service discovery classes emitted an
> > >>    error
> > >>    
> > >>      signal but the human readable error string was not adjusted.
> > >
> > >How is this a documentation issue? If it's a minor documentation fix, it
> > >probably isn't relevant for the changelog.
> > 
> > The release branch of the git repo for this module has had the relevant fix
> > for the above issue for some time.
> 
> You mean in the changes file?
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url : http://lists.qt-project.org/pipermail/development/attachments/20140121/32f435f1/attachment-0001.bin 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 21 Jan 2014 10:30:02 -0800
> From: Alan Ezust <alan.ezust at gmail.com>
> Subject: Re: [Development] frozen tickets on bugreports.qt-project.org
> 	in qt-mobility and qt-components
> To: deDietrich Gabriel <Gabriel.deDietrich at digia.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> 	<CALy5K9ocwnLOi5D7=UWu4wPfz-L9H=tTBZJ+vygbZ6c2gYBHrw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Exactly my point. Why does someone need superpowers in order to edit these
> tickets?
> Shouldn't it be possible for developers to reorganize or close or add info
> to these things?
> It doesn't serve any purpose to keep them open and frozen like this.
> 
> Anyway, I am requesting said superpowers so I can help organize and triage
> these tickets.
> But I think they should be granted to all devs :-)
> 
> 
> On Mon, Jan 20, 2014 at 12:43 PM, deDietrich Gabriel <
> Gabriel.deDietrich at digia.com> wrote:
> 
> >
> >  On Jan 20, 2014, at 7:52 PM, Alan Ezust <alan.ezust at gmail.com> wrote:
> >
> >
> > I was looking at this one in particular:
> > https://bugreports.qt-project.org/browse/QTCOMPONENTS-930
> >
> >
> >  Hi Alan,
> >
> >  As the header says on that page, QTCOMPONENTS is deprecated. Those
> > tickets relate to an old set of components from the Nokia times. We keep
> > them around for reference (although I don?t think any of that code is in Qt
> > 5), and we should definitely close them (and by ?we,? I mean anyone with
> > the right superpowers).
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.qt-project.org/pipermail/development/attachments/20140121/445b273f/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 21 Jan 2014 13:31:40 -0500
> From: Matt Broadstone <mbroadst at gmail.com>
> Subject: Re: [Development] Prettier printing of Unicode strings
> To: Thiago Macieira <thiago.macieira at intel.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> 	<CAMsD-yBwe2OSPw3MGox+cK-rVAAUBS3wRxNRS9QTg2qcGck1ZQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Mon, Jan 20, 2014 at 7:05 PM, Thiago Macieira
> <thiago.macieira at intel.com>wrote:
> 
> > I was writing a test today and QtTest told me:
> >
> >    Actual   (s) : ?12???
> >    Expected (s2): ?12???
> >
> > So I went, "duh, ok, it looks the same to me but what's behind those
> > question
> > marks".
> >
> > After a bit of changes [https://codereview.qt-project.org/76100], it now
> > prints:
> >
> >    Actual   (s) : \u221212\u20A0\uD800\uDC00
> >    Expected (s2): \u221212\u20AC\uD800\uDC00
> >
> > Which tells me what I got wrong.
> >
> > Ok to submit this change then? It will make all toString(QString) print
> >
> >  - all backslashes as \\
> >  - the following characters as their escape sequences: \r, \n, \t, \b, \f
> >  - all other control characters (including 0x7f) as \u00XX
> >  - all other characters with \uXXXX, including text otherwise readable in
> > the
> >    terminal in the locale
> >
> > One major advantage of this is that it does not depend on the locale codec
> > being set up or even working, as the previous code did. So we get
> > consistent
> > results even if there's a bug in that.
> >
> > Is this ok?
> >
> >
> +1
> 
> 
> > Should I also print quotes as \" ? And should I surround the string with
> > quotes?
> >
> > Should I also do the same for QByteArray? Reading hex dumps isn't very
> > nice.
> >
> 
> I think this would be great as well, but also if there was maybe an io
> manipulator to print the hex if you want to look at that as well. Ideally
> such a manipulator would print the whole hex, currently the hex printed for
> QByteArrays is truncated which in my experience makes it pretty useless in
> most cases..
> 
> Matt
> 
> 
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.qt-project.org/pipermail/development/attachments/20140121/5f297727/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 21 Jan 2014 19:48:17 +0100
> From: Allan Sandfeld Jensen <kde at carewolf.com>
> Subject: Re: [Development] Remove OSX 10.6 Build?
> To: development at qt-project.org
> Cc: Sorvig Morten <Morten.Sorvig at digia.com>
> Message-ID: <201401211948.17736.kde at carewolf.com>
> Content-Type: Text/Plain;  charset="windows-1252"
> 
> On Tuesday 21 January 2014, Sorvig Morten wrote:
> > Obviously it?s not going to stand forever, especially when seeing the
> > strong opinions from the Qt on Mac developers. We are moving in the
> > direction of not supporting 10.6. The 5.3 binary packages will not support
> > it. QtWebkit lives its own life - if upstream does not support 10.6 then
> > there is little we can do.
> > 
> QtWebKit in Qt 5.2 does support 10.6, and since the branch used by 5.2 is 
> scheduled to be the last upstream branch of WebKit, it should not be a problem 
> (at least not any more, I had to perform major surgery on the code to even 
> build with gcc 4.2). So QtWebKit should have no problem continuing the same 
> support as the rest of Qt for 10.6.
> 
> Regards
> `Allan
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 21 Jan 2014 11:29:25 -0800
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] Prettier printing of Unicode strings
> To: development at qt-project.org
> Message-ID: <26291257.SFQX9ifhbG at tjmaciei-mobl2>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On ter?a-feira, 21 de janeiro de 2014 13:31:40, Matt Broadstone wrote:
> > I think this would be great as well, but also if there was maybe an io
> > manipulator to print the hex if you want to look at that as well. Ideally
> > such a manipulator would print the whole hex, currently the hex printed for
> > QByteArrays is truncated which in my experience makes it pretty useless in
> > most cases..
> 
> Comment from qtestcase.cpp:
>     /* We output at maximum about maxLen characters in order to avoid
>      * running out of memory and flooding things when the byte array
>      * is large.
>      *
>      * maxLen can't be for example 200 because Qt Test is sprinkled with fixed
>      * size char arrays.
>      * */
> 
> I don't know how relevant that comment still is. But it's normal for the data 
> to be limited, we can't flood the output with huge strings.
> 
> If you want, you can contribute a feature that shows which element in an 
> array-like type differs (QByteArray, QString, QLists, QVectors).
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url : http://lists.qt-project.org/pipermail/development/attachments/20140121/6d25a341/attachment-0001.bin 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 21 Jan 2014 22:07:32 +0100
> From: Samuel Gaist <samuel.gaist at edeltech.ch>
> Subject: Re: [Development] How to write a ChangeLog entry
> To: Thiago Macieira <thiago.macieira at intel.com>
> Cc: development at qt-project.org
> Message-ID: <9F39BC4F-9A5B-4341-A07E-CC57A1DDEB44 at edeltech.ch>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On 21 janv. 2014, at 00:43, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> > On segunda-feira, 20 de janeiro de 2014 23:58:21, Samuel Gaist wrote:
> >> On 20 janv. 2014, at 23:44, Thiago Macieira <thiago.macieira at intel.com> 
> > wrote:
> >>> On segunda-feira, 20 de janeiro de 2014 22:59:09, Samuel Gaist wrote:
> >>>> Yes it does, with that, QLocale supports the various possible negative
> >>>> signs> 
> >>> Can you verify if the change also affects QString::toInt, toDouble, etc.?
> >>> 
> >>> 5.1.1 doesn't support U+2212.
> >> 
> >> Sure, I'll do it tomorrow
> >> 
> >> IIRC, the patch went in for 5.2
> > 
> > Right, this is the 5.2.1 change log.
> 
> As promised:
> 
> QString str("\u2212\x31\x36");
> 
> qDebug() << str.toShort() << str.toInt() << str.toDouble() << str.toLong() << str.toLongLong() << str.toFloat();
> 
> all returns -16
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 21 Jan 2014 22:25:38 +0100
> From: Samuel Gaist <samuel.gaist at edeltech.ch>
> Subject: Re: [Development] Remove OSX 10.6 Build?
> To: Jake Petroules <jake.petroules at petroules.com>
> Cc: Sorvig Morten <Morten.Sorvig at digia.com>,
> 	"<development at qt-project.org>" <development at qt-project.org>
> Message-ID: <D8E517B5-D6D3-49F6-9776-6AB514F70454 at edeltech.ch>
> Content-Type: text/plain; charset=windows-1252
> 
> 
> On 21 janv. 2014, at 14:25, Jake Petroules <jake.petroules at petroules.com> wrote:
> 
> > On Jan 21, 2014, at 7:36 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> > 
> >> On 21 Jan 2014, at 11:51, Simon Hausmann <simon.hausmann at digia.com> wrote:
> >> 
> >> That depends on how much time we spend releasing Qt :) 
> >> 
> >> I realize that if I?m the only one who want?s to keep supporting 10.6 then that?s not going to work. The most important thing to me is to have a somewhat predictable deprecation plan. For example (and at the risk of making this example ?the plan?):
> >> 
> >> 5.3 - Remove support from binary packages.
> >> 5.4 - 10.6 support is deprecated.
> >> 5.5? - Remove support.
> > 
> > I think this is relatively reasonable. By 5.5 (mid-2015, right?) we will have or almost have OS X 10.11 which is three versions into the OS X free pricing model. Given the fast uptake of OS X Mavericks in just a few short months, by then it seems to me that it will be the ideal time to say goodbye to the last of the Leopards. The gap between Snow Leopard and Lion is also probably the most technically significant between any two recent versions of OS X, so when it's 10.7's time to go we may not even need any code changes.
> > 
> > Also, keep in mind that ARC requires the Objective-C Modern Runtime i.e. dropping support for 32-bit 100% (ARC + 32-bit = compile error). Despite us not currently providing any 32-bit packages, the CI system still has at least one 32-bit configuration if I remember correctly. So, if there are any use cases for a 32-bit build of Qt on modern versions of OS X, let's keep that in mind before moving to ARC.
> > 
> 
> One that I can see is the direct use of the old QuickTime framework to have a complete access to the available set of codecs and their parameters. 
> IIRC, QTKit was not on par with QuickTime in terms of codec handling and ease of access.
>  
> I know it might not be a common use case, just my 2 cents
> 
> >> 
> >> Now you could argue that ?deployment only? is de facto ?deprecated?, but I think we should explicitly state it. Also, some time need to pass between ?deprecated? and code removal, we can?t deprecate in 5.4 and then remove the code in dev the day after the release.
> >> 
> >> This thread should then be titled ?Deprecate Mac OS 10.6 Build??. The arguments for are:
> >> - Parts of the dev team do not want to maintain it
> >> - We want to free up CI resources 
> >> - Questionable install base size
> >> 
> >> Sending a loud and clear ?deprecated? message could actually help clear up that last point.
> >> 
> >> Morten
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Development mailing list
> >> Development at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > -- 
> > Jake Petroules
> > Chief Technology Officer
> > Petroules Corporation ? www.petroules.com
> > Email: jake.petroules at petroules.com
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> End of Development Digest, Vol 28, Issue 80
> *******************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140121/be7b6f6c/attachment.html>


More information about the Development mailing list