of this week, 13), which
requires that QMetaEnums have their meta objects.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
that was passed to your type to access the
extra fields.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://
https://bugs.kde.org/show_bug.cgi?id=486076
--- Comment #4 from Thiago Macieira ---
(In reply to Nicolas Fella from comment #3)
> We still have reports from 6.1, so doesn't seem fixed on our side at least
That would match my not seeing any changes to the source code that could
explain
cally register an enum with the meta-type
> system (so that QMetaEnum.metaType().isValid() returns true)?
Sure. And registration is automatic anyway.
All you should need to do is pass the necessary QMetaType
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI
he metatype of properties and methods
Additionally Metatypes for enums and properties are mandatory too. For
methods, they are allowed to be nullptr.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIM
to the meta-object. It would
> be nice to be able to register an enum with the meta-type system
> dynamically.
Or you can set the EnumOrFlag flag in the QMetaProperty flags field to force
the
constructor to search.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
he release is near.
The feature system is not guaranteed to work. If you use *any* -no-feature
option, you assume responsibility for submitting build fixes. This task didn't
get assigned to me, but if it had been, I'd have closed it with that.
--
Thiago Macieira - thiago.macieir
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
ors" sounds like a nice feature to have cross-platform.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
On Monday 30 September 2024 15:22:48 GMT-7 Thiago Macieira wrote:
> 2) Jøger reports that VS is failing to compile the meta object of a private
> class. I think that's a compiler bug, because there is an equivalent test in
> tst_Moc and that compiles. I can't reproduce the is
On Thursday 12 September 2024 06:59:55 GMT-7 Thiago Macieira wrote:
> > +1 for that! That's one of the things that we pay attention to during API
> > review in Qt, so hopefully all new Qt APIs will either use `enum class`,
> > or explicitly define an underlying type.
>
nt, but where is
> the explanation for interpreting results?
There usually isn't a target for the benchmark. We're not trying to hit a
specific value.
The benchmark results are only interesting over time, to see whether we've
gained or lost performance.
--
Thiago Macieira - thiago.maci
https://bugs.kde.org/show_bug.cgi?id=486076
--- Comment #1 from Thiago Macieira ---
I haven't seen this crash in months, probably coinciding with the 6.1 update.
--
You are receiving this mail because:
You are watching all bug changes.
e you pasted, I see no reason it shouldn't work.
Maybe there's some non-obvious mistake. Implementing it directly in
qprocess_win.cpp may make it work.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description
handles that can be used to get
> output from the QProcess m_process.
>
> Any pointers how to do that correctly would be very welcome. (or if I
> just missed to used the proper Qt API for that)
Since you want no handles but the standard three, would setting
args->inheritHan
t a git show of this commit shows the annotation:
Notes (cherry-picks):
6.7: 8dd7aba7fd2e6edeee33e97879f7e891028bad7d
And that commit is name-rev'ed to tags/v6.7.0-rc1~141.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
a76dec51de48af99132b91 (which is dated over 3 months before
the first public commit) and Marius S-O wrote:
Add hardcoded qclass_lib_map.h based on 4.8
This is only until UIC/Designer handles this properly
Permanent temporary...
--
Thiago Macieira - thiago.macieira (AT) intel.com
er we have to write
the keyword or not).
That said, the inline keyword can be omitted for functions, so moving it to
the right where we usually won't try to grep makes some sense.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System
On Thursday 19 September 2024 08:07:19 GMT-7 Thiago Macieira wrote:
> On Thursday 19 September 2024 01:11:54 GMT-7 Halla Rempt wrote:
> > Who knows whether anyone is using it? There are zillions of projects using
> > Qt out in the world, but the people developing Qt keep assuming
submitting to useless clean-ups that nobody
> seems to have thought were an imposition. I've been through Qt1..2..3..4..5
> and now going through 6.
And the reports we've had is that however painful this transition is, it's the
least painful of all.
--
Thiago Macie
> also inline.
Yeah, but by the same token you could be searching for static inline, of which
we have far more in our sources.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographi
to adopt.
Arthur doesn't conclude very well whether constinit comes all the way first
(because it modifies how the initialisation happens) versus being placed where
constexpr would be.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & S
> Whether inline or constexpr comes first has none, IMNSHO.
I'm thinking of new code and how we usually write code. We don't enforce the
static inline / inline static, for example, but most people write the former.
I'm just wondering which one we prefer.
--
Thiago Mac
erefore, our constexpr variables should be explicitly inline too, to avoid
those problems. The question is only the order in which we spell those two
keywords out.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
p 'static constexpr inline' \* '!*/3rdparty/*' | wc -l
57
$ git sgrep 'static inline constexpr' \* '!*/3rdparty/*' | wc -l
53
$ git sgrep 'inline static constexpr' \* '!*/3rdparty/*' | wc -l
16
$ git sgrep 'inline constexpr stat
ttps://codereview.qt-project.org/c/qt/qtbase/+/586454:
QMetaMethod: make some QByteArray-returning methods slightly faster
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signatur
On Tuesday 10 September 2024 10:33:32 GMT-7 Thiago Macieira wrote:
> Is this supported? I didn't know about it until yesterday. I doubt anyone is
> using it, though it's possible some code carried over from Qt 3 was left
> unmodified like that.
QGroupBox:
Q_PROPERTY(Qt::
On Tuesday 10 September 2024 10:12:10 GMT-7 Andreas Aardal Hanssen wrote:
> Tir 10 sep 2024 kl. 18:55 skrev Thiago Macieira:
> > Any objections?
>
> Please don’t break source compatibility?
It does appear that a Q_PROPERTY of a Q_FLAG whose getter and setter operate
on integers
On Tuesday 10 September 2024 09:55:24 GMT-7 Thiago Macieira wrote:
> 1) I will fix moc to *not* manipulate int for property enum types, which
> means it will not use QFlag at all
https://codereview.qt-project.org/c/qt/qtbase/+/589897
If we need to keep compatibility with integer gette
if'ed on sizeof(QFlags) == sizeof(int)
4) I will not mark them or QFlag as deprecated
Any objections?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development
On Tuesday 10 September 2024 04:56:40 GMT-7 Thiago Macieira wrote:
> In Qt 3, QVariant could only contain a closed set of types, so QObject::
> QObject::setProperty would only be able to write QFlags if the QVariant
> contained an int, and QMetaProperty already had isEnumType() at
in type compared
to the norm.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
) = _t->flags(); break;
case 2: _t->setFlags(*reinterpret_cast< Qt::WindowFlags*>(_v)); break;
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development m
ommit did not include any changes to moc, tst_moc or testlib.
But there is one change in COIN itself relating to the windows minimal-static
build, which was the update from MSVC 2019 to 2022.
I also see more than one qt5 integration passing earlier today.
--
Thiago Macieira - thiago.macieira (
> nothing to do with C++26/29 contacts.
And this proprietary solution of ours could be made so it throws for user-
compiled inline code, but not for the same inline functions compiled inside
the Qt libraries. In this case, I agree it can be done.
--
Thiago Macieira - thiago.macieira (A
in a bad state.
Either way, it doesn't change our conclusion. Throwing on precondition
violation is a useful tool for unit-testing some APIs and we want to have
that, but using it in production code is dangerous because it's untested. Use
at your own peril.
--
Thiago Macieira - thiago.ma
proper correction code for it.
>
> I have that "correction code".
Sure, but "bugs happen". I am arguing that putting the contract checker into
exception mode expands the blast radius of when those bugs do occur.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal
ure/promise doesn't know how many results will be provided, so there's
a race condition in it flagging the future has arrived with more results
arriving.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smim
tst_QList can test its
operator[], but tst_QObject shouldn't.
I don't think we'll prohibit this. But it will be a gun and there's your foot
over there...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Enginee
time
choice (as Marc says, decided by the owner of main()), we'll need to be very
clear we do not support it and do not recommend it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
work. I'll even review the patches and
provide feedback. But I don't think it's a good use of our time, especially
when we call out to non-Qt code that isn't exception- or even unwind-safe
(q.v. the crashes on macOS on ARM64).
--
Thiago Macieira - thiago.macieira (A
On Saturday 31 August 2024 08:26:06 GMT-7 Thiago Macieira wrote:
> You can now choose: 64-bit QFlags or MSVC 2019. I don't think it's worth
> keeping compatibility with the old moc way of doing things for a now 5-year-
> old compiler. More to the point, I refuse to do the work
sn't seem
> to be a way to do this.
The cache key is invalidated the moment you call bits()
If it stays the same, it's because it was not cached by anything.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smi
On Saturday 3 February 2024 09:08:25 GMT-7 Thiago Macieira wrote:
> The compiler is pretty buggy and has several, unfixed conformance issues
> with C++.
>
> One year ago I asked on the interest mailing list about using a non-latest
> MSVC:
> https://lists.qt-project.org/piper
exception may be generated
anyway. Because that noexcept expression is currently noexcept(true) for all
major Standard Libraries whose headers I can see, there is no behaviour change
and no incompatibility.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Plat
of restricting to performance-critical code. Either we
use the macro everywhere where we apply a noexcept where preconditions exist,
or we don't.
Said macro should be tied to the precondition itself, if we can. I haven't
looked at the syntax: can one macro in one location expand to precond
On Thursday 29 August 2024 13:33:55 GMT-7 Marc Mutz via Development wrote:
> On 29.08.24 17:31, Thiago Macieira wrote:
> > What I'd like to change is:
> > - for inline code, where the function's noexceptness is likely to be used
> > in a>
> > noexcept exp
knows* whether something threw or not.
Examples are QStringView::sliced() or the QCborStreamReader members.
What I'd like to change is:
- for inline code, where the function's noexceptness is likely to be used in a
noexcept expression elsewhere and that causes slower code to be used
-
checked
preconditions that may throw, we copy their solution and apply the same.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Developm
ting
each element in case the *comparison* throws, even if the element copy/move is
noexcept.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote:
> On Tue, 27 Aug 2024 at 17:15, Thiago Macieira
wrote:
> > The point is that this putative mistake has no consequences, today. It
> > remains to be seen whether it will with contracts, when those come. When
> &g
so doesn't operator[].
>
> We can decide otherwise -- and that's orthogonal to if and when
> contracts actually land, as Marc says.
Can we decide otherwise? Doesn't the underlying Standard C++ library
implementation's choice make the same choice for us?
--
Thiago Macie
n whether it will with contracts, when those come. When contracts
come, if those noexcept are a problem, then both libc++ and libstdc++ will
deploy a solution, which should suffice for us too. Until then, I don't see a
reason to deprive ourselves of any potential benefits that the noexce
ould allow having one set remaining in a
build type and not the other too. But it might be confusing to teach our own
developers.
I don't remember what the issue with Q_ASSUME was any more. As we failed to
reach an agreement, there was no point in retaining any knowledge about why. I
just
(which it
may if it has a precondition).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
those noexcepts?
And where does it end? Do any pointer dereferences imply a precondition and
thus not-noexcept?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
ector::operator[]. Are you
proposing that it a) become non-noexcept, b) have its UB not defined by the
boundary of the precondition, or c) have a precondition that cannot be turned
into an exception?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
hat happens to parameters that have non-noexcept destructors?
We have both callee-destroys and caller-destroys systems.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signatu
On Monday 26 August 2024 15:47:10 GMT-7 Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 22:29, Giuseppe D'Angelo via Development
>
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> > > I'd like to request Qt code not obey that rule. In my o
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
uggy implementation or
corrupted memory. Neither of which you can recover from with C++ code.
[This code isn't noexcept because QUuid::fromRfc4122 wasn't noexcept when it
was written]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform &am
as compiled without exception support.
So I am asking that we be pragmatic and cater for the needs we have, not the
hypothetical needs that have not yet materialised in 15 years.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Enginee
rithm, and so on).
Then let's go for it: a clazy warning.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project
On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
wrote:
> Il 26/08/24 19:56, Thiago Macieira ha scritto:
>
> > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > defect
in the contract implementation rather than on
rue before the method is called and
therefore the method's own noexcept specification does not apply *yet*.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Devel
destructor.
A compile-time warning implies having a way to disable it with "I know that,
just ignore it" which is maintenance for us. My problem with this is the cost
on us, to maintain such a thing that has never been a problem and likely never
will.
--
Thiago Macieira - thia
On Monday 19 August 2024 15:59:15 GMT-7 Thiago Macieira wrote:
> I replaced the use of std::array with plain arrays. It's now passed with a
> full precheck, even on INTEGRITY. Please review the series.
GHS compiler bug:
"/home/qt/work/qt/qtbase/src/corelib/kernel/qtmochelpers.h&
On Sunday 18 August 2024 09:07:27 GMT-7 Thiago Macieira wrote:
> On Saturday 17 August 2024 22:13:44 GMT-7 Thiago Macieira wrote:
> > I'm running it through the CI now to see if there's anything I
> > missed and if QNX and INTEGRITY will join us or if they will keep t
On Saturday 17 August 2024 22:13:44 GMT-7 Thiago Macieira wrote:
> I'm running it through the CI now to see if there's anything I
> missed and if QNX and INTEGRITY will join us or if they will keep the old
> moc- generated content. I will not spend any time at all trying to
&g
On Sunday 11 August 2024 10:31:06 GMT-7 Thiago Macieira wrote:
> It might be possible to consult the string array and avoid having to have
> string indices all over the place. This will require some more testing,
> especially with the QtOpcUA::NodeIds massive listing.
>
> I may
https://bugs.kde.org/show_bug.cgi?id=479841
--- Comment #10 from Thiago Macieira ---
See also https://bugreports.qt.io/browse/QTBUG-125721
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=479841
Thiago Macieira changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
cases, to silence the tidy tool, you should cast
the signed type to the unsigned equivalent and not use intcmp().
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
On Friday 9 August 2024 13:26:12 GMT-7 Thiago Macieira wrote:
> I've thrown it at the CI to check more:
> https://codereview.qt-project.org/c/qt/qtbase/+/582313
Making lots of modifications but it seems to be working. I've also managed to
also calculate the metatype array a
autogen/include/moc_qtpropertymanager.cpp
2844668 ./qtopcua/src/opcua/OpcUa_autogen/include/moc_qopcuanodeids.cpp
QOpcUa::NodeIds contains a single enum with 16162 entries. I'll need to test
that too. The other ones are not big meta objects; the files are big because
there are multiple classes in
f another bit extracted into the QMTI, and impact everyone else's
runtime to check that bit and warn or reject. We'd probably not do the runtime
checking at all, because of the side effect and because the construction of the
user code as above could mean the developer never sees the pro
very cumbersome anyway. I
think I have a better solution anyway.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.or
On Thursday 8 August 2024 11:22:39 GMT-7 Thiago Macieira wrote:
> My solution is to have moc parse a new declaration Q_DECLARE_FLAGS64, which
> indicates the flag is 64-bit, and then generate different data. I have not
> implemented Q_FLAGS64 or Q_ENUM64 yet.
An alternative solution I a
r we can have moc generate the same
content for both macros, regardless of class.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-p
not fix bugs
relating to issues not found on later versions, but it shouldn't stop working
all of a sudden.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Descripti
s://wiki.qt.io/Qt_Contribution_Guidelines
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.or
Right, the documentation doesn't explain what line endings are supported.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
__
an LF.
Is your text file using CRs alone for line breaks?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing
https://bugs.kde.org/show_bug.cgi?id=484119
--- Comment #3 from Thiago Macieira ---
Created attachment 171892
--> https://bugs.kde.org/attachment.cgi?id=171892&action=edit
Problem in KMail 6.1.2
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=484119
--- Comment #3 from Thiago Macieira ---
Created attachment 171892
--> https://bugs.kde.org/attachment.cgi?id=171892&action=edit
Problem in KMail 6.1.2
--
You are receiving this mail because:
You are the assignee for the bug.
le to.
Short of that, we'll need a reproducer.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest ma
tion yet (that would be a livelock, not a deadlock)?
Or has it notified by the other thread didn't get it?
Either way, I think you've found a Qt bug. Please test with 6.7 or 6.8 betas,
and report it with the updated backtrace.
--
Thiago Macieira - thiago.macieira (A
you reproduce the problem *at all*?
If you can, then simply get the stack trace of all threads when the problem
happens. You'll see at least two threads stalled and waiting for each other
(not in an event loop).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer
u do, it's a poor implementation compared to even FreeBSD's equivalent
(truss).
If you need to trace system calls on macOS, my recommendation is to trace on
Linux or FreeBSD first.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform &
On Tuesday 9 July 2024 03:33:16 GMT-7 Marc Mutz via Development wrote:
> We should really try to fix this before 6.8.0 (LTS).
I won't have time for QDataStream and especially QTextStream & QDebug, which
are required for QMetaType.
--
Thiago Macieira - thiago.macieira (AT) intel.com
iguring the project, either via IDE
> kit settings, or on the command line.
What example needs to know that in the first place? Examples should use the
QtNetwork API and that completely hides which TLS backend is in use.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer
27;s not a problem that needs solving.
We already enforce in QCoreApplication where it matters: the setlocale() call.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
users, how to market the versions, and
whether it is worth the hassle are completely separate topics.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing
https://bugs.kde.org/show_bug.cgi?id=484119
Thiago Macieira changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=484119
Thiago Macieira changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=484296
Thiago Macieira changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=484296
Thiago Macieira changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
1 - 100 of 3698 matches
Mail list logo
