Le mer. 14 juin 2023, 08:35, a écrit :
> Send Development mailing list submissions to
> development@qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.qt-project.org/listinfo/development
> or, via email, send a message with subject or body
Le mer. 18 nov. 2020 à 08:36, a écrit :
> -- Forwarded message --
> From: Thiago Macieira
> On Tuesday, 17 November 2020 15:41:10 PST Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > - qtplugininfo: I sincerely don't know how it's being used.
>
> I was going to suggest it, but I
Hi all,
> (a) implies one change in behaviour (5.14.2 to 5.15.0)
> > (b) implies two changes in behaviour (to and from 5.15.0)
> > (c) implies three changes in behaviour: 5.14.2→5.15.0, 5.15.0→5.15.1,
> 5.15.x→6.0
>
I would appreciate option b) or c)
We do not use x.x.0 versions so it would be tr
>
> QUtf8StringIterator can be easily added to extract Unicode codepoints from
> the UTF-8 string like QStringIterator exists for the same in UTF-16.
>
I have discovered QStringIterator in KDAB blog, it is nice, thanks!
A QUtf8StringIterator would boost Qt utf8 support like easily
splitting/filter
Hi all,
As a user, I am happy with simplifications regarding string handling and I
think the choice of utf16 for QString makes sense for most code except for
file/networking code.
I was once concerned about not being able to distinguish between QByteArray
containing utf8 text and QByteArray conta
Hi,
Considering your previous remarks, I would make the following amendments:
Le jeu. 23 janv. 2020 à 15:07, Kari Oikarinen a écrit :
> On 6.12.2019 19.36, Arnaud Clère wrote:
> > Name: QtDataTransforms ?
QtSerialization (more pragmatic and self explanatory)
> > Responsible per
Hi,
Le lun. 9 déc. 2019 à 22:05, Lukast dev a écrit :
> But stack sampling sometimes sucks because you don't see if the function was
> called million times and thus it shows up in the profile
> or it is called once and is expensive and thus it shows up as hot spot.
> That's the benefit of traci
Hi,
Le lun. 9 déc. 2019 à 16:34, a écrit :
> > Should I go on creating a QTQAINFRA issue for that?
>
> You can create a QTQAINFRA ticket, although that will just help in it
> not being forgotten by the admins. The decision on creating the new repo
> happens here on the mailing list.
Yes, that is
> -Original Message-
> From: Milian Wolff
>
> On Mittwoch, 4. Dezember 2019 12:23:00 CET Lukast dev wrote:
> > is there some Qt solution for producing traces used for performance
> > analysis?
> >
> > There is on-going work for LTTNG and ETW in Qt I noticed, e.g. here
> > https://coderevie
w.
Thanks,
Arnaud
-- Forwarded message -
De : Arnaud Clère
Date: jeu. 28 nov. 2019 à 13:25
Subject: Re: [Development] FW: QtCS19 Serialization session
To:
-Original Message-
From: Thiago Macieira
>
> Would it make sense if this API were not in QtCore?
> Then we coul
-Original Message-
From: Thiago Macieira
>
> Would it make sense if this API were not in QtCore?
> Then we could give it a try and see how many people think it's useful, what
> its pitfalls are, etc.
Yes, it is possible and it perfectly makes sense. It does not have to
wait for Qt6 too.
-Original Message-
From: Thiago Macieira
> > value.meta(qmColumns,"key,value").bind(map.iterator())
>
> I really, REALLY do not like this line.
I was going to explain all meta(...) were never required, but well,
you have pretty well summarized your arguments so I will just stop
wasting o
Now, this is the discussion I was hoping for at QtCS :-)
> -Original Message-
> From: Thiago Macieira
>
> > - it is frequent to have to save/load our types and then send/receive
> > them to some server/device using, say QSettings/QJsonDocument for the
> > first and JSON/CBOR for the latte
-Original Message-
From: Thiago Macieira
>
> My point is that I can see the value in providing a single method whereby our
> and users' types
> can provide a descriptive format for their serialisation, regardless what the
> serialisation backend is.
> That way, a single method could be u
Hi all,
Thank you for the discussions at QtCS19!
The notes regarding the session on serialization are on the wiki:
https://wiki.qt.io/Rethinking_serialization_for_Qt6
To summarize:
- Although it seemed strange to many people, it is possible to provide an
API so that a single T::zap() method can r
In your examples, you know the destination types statically so my suggestion
did not seem off-topic.
Cheers
From: Vasily Pupkin
To: Arnaud Clère
> Using QVariant as an intermediate data structure is not optimal to
> read/write your QList
> It also prevents from directly using
c_asserts complaining at
compile time).
Arnaud Clère
From: Vasily Pupkin
Sent: 01 April 2019 15:44
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] QVariant container API
> By the way, conversions through QVariant are *exactly* wha
> -Original Message-
> From: Jason H
> Sent: vendredi 25 janvier 2019 17:40
> Cc: development@qt-project.org
> Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString
>
> > By all means, let's make sure the internals are efficient for the more
> > common languages and scr
> Original Message-
> From: Thiago Macieira
>
> But we WILL NOT change from UTF-16 in the next 2 years.
From a user standpoint, this seems perfectly Ok to me.
I do not buy the argument that if switching QString to utf8 make developer bugs
appear sooner, this is a good thing.
Most use
> -Original Message-
> From: Thiago Macieira
>
> On Tuesday, 22 January 2019 09:01:16 PST Arnaud Clère wrote:
> > QByteArray is the official way to deal with utf8 strings but:
> > 1. This discussion shows it is not as known as it should be and I
> >
> Original Message-
> From: Jason H
>
> > From: "Arnaud Clère"
> >
> > > -Original Message-
> > > From: Allan Sandfeld Jensen
> > >
> > > Use QByteArray when you can.
> >
> > I think a QUtf8Strin
> -Original Message-
> From: Allan Sandfeld Jensen
>
> On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote:
> > Any chance of having UTF-8 storage support for QString?
> >
> Use QByteArray when you can.
I think a QUtf8String class derived from QByteArray would help a lot makin
rpedoes"
unless I am sure they are targeting the right thing 😊
Cheers,
Arnaud
-Original Message-
From: Thiago Macieira
Sent: jeudi 16 août 2018 22:11
To: development@qt-project.org
Subject: Re: [Development] unified data model API in QtCore => thin wrapper
proposal
On Wednes
Hi,
Thiago, did you decide on something regarding QCborValue in Qt5.12?
For structured traces, we have to deal with any user-defined data types so, we
can do with QCborValue, QJsonValue or QFoo too. Now, the value of exposing the
common backend of QJson and QCbor as a QFoo binary format is not c
> From: Dmitry Volosnykh
> Sent: lundi 18 juin 2018 13:40
>
> FYI, there's QTBUG-29095 and QTBUG-25723 that feel like somewhat related to
> the problem under discussion.
I guess QTBUG-25723 is the kind of problem that Thiago solved for QCborValue
For the use case described in QTBUG-29095, I thi
-Original Message-
From: Thiago Macieira
Sent: jeudi 14 juin 2018 02:08
> This email is to start that discussion and answer these questions:
> a) should we have this API?
> b) if so, what would this API look like?
> c) if not, should we unify at least JSON and CBOR?
> c) either w
Hi all,
Following up on https://wiki.qt.io/QtCS2017_Discuss_Qt_Logging_enhancements I
have posted at the bottom of the page a quick survey of the tracing/logging
landscape.
My own conclusions are that there is almost no overlap between the 2 use cases
and proposals.
For #1 (high-perf tracing
Hi,
Regarding ETW, I found this blog post interesting as they are pursuing very
similar goals wrt to convenience of trace analysis vs performance of tracing:
https://blogs.msdn.microsoft.com/vancem/2015/09/20/rich-payload-data-in-eventsource-v4-6/
It points to a slightly more detailed explanation
Hi Christian,
Thanks for the pointers regarding LTT and the underlying Common Trace Format,
that was very informative.
The fact that CTF supports variants and dynamically sized structures makes it a
possible output for modmedLog, as is IETF's Compressed Binary Object
Representation.
What is not
native APIs certainly provide very
efficient solutions.
On our side, if we avoid dynamic allocations, we should be able to avoid 99% of
the locks by writing in a reasonably large buffer before sending the result to
native APIs. Would that be enough?
Regards,
Arnaud Clère
-Ori
30 matches
Mail list logo
