On 2019-08-23 10:31, Mutz, Marc via Development wrote:
If that's the case, shouldn't we run, not walk, to replace our
internal uses with std::mutex + std::condition_variable to have only
one mutex?
Since it _is_ the case, I've sat down and ported QReadWriteLock from
QMutex + QWaitCondition to
On Friday, 23 August 2019 01:31:20 PDT Mutz, Marc via Development wrote:
> Do I understand it correctly that the implementation of QWaitCondition
> has _another_ mutex inside?! So, two mutexes? The one users pass in and
> then the one that QWaitCondition uses internally, because it's
>
On Friday, 23 August 2019 14:51:36 CEST Mutz, Marc via Development wrote:
> On 2019-08-23 14:31, Allan Sandfeld Jensen wrote:
> [...]
>
> > condition_variable_any::_M_mutex
>
> I didn't say _any :)
>
> > The std::conditional_variable has the same problem QWaitCondition has.
>
> I don't think
On 2019-08-23 14:31, Allan Sandfeld Jensen wrote:
[...]
condition_variable_any::_M_mutex
I didn't say _any :)
The std::conditional_variable has the same problem QWaitCondition has.
I don't think so:
https://code.woboq.org/gcc/libstdc++-v3/include/std/condition_variable.html#166
takes
On Friday, 23 August 2019 10:31:20 CEST Mutz, Marc via Development wrote:
> On 2019-05-29 12:53, Mutz, Marc via Development wrote:
> > === QWaitCondition -> std::condition_variable(_any) ===
> >
> > Plumbing that std::condition_variable can do better.
>
> So, I've looked at QWaitCondition
With the Windows implementation, there is indeed a mutex to protect an
internal list of waiters.
This is not a problem in itself, because std::condition_variable
probably does the same...
However, a problem with QWaitCondition that forced me to switch to
std::condition_variable
is the following
On 2019-05-29 12:53, Mutz, Marc via Development wrote:
=== QWaitCondition -> std::condition_variable(_any) ===
Plumbing that std::condition_variable can do better.
So, I've looked at QWaitCondition because I had a need to call wait()
with a QBasicMutex instead of a QMutex, and that doesn't
On 19/06/2019 15.03, Giuseppe D'Angelo via Development wrote:
> On 19/06/2019 18:42, Matthew Woehlke wrote:
>> Mark wants to deprecate Q[E]SDP. That implies eventual removal, which
>> absolutely *is* depriving users of something they were previously using.
>> (Even just deprecating is requiring
On 19/06/2019 18:42, Matthew Woehlke wrote:
On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:
On 18/06/2019 23:27, Matthew Woehlke wrote:
So... to be clear, your plan is to deprive Qt users of a (mostly)
perfectly good wheel, that *is* being used by said users, and instead
tell all
On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:
> On 18/06/2019 23:27, Matthew Woehlke wrote:
>> So... to be clear, your plan is to deprive Qt users of a (mostly)
>> perfectly good wheel, that *is* being used by said users, and instead
>> tell all of those users that they need to go
On Tuesday, 18 June 2019 22:34:02 PDT Mutz, Marc via Development wrote:
> I'm not concerned about bugs. I'm concerned that making Qt's pimpl_ptr
> public API constrains how Qt itself is implemented. Sure, we can add yet
> another pimpl_ptr and make that public again, by the same rationale. But
>
On 2019-06-18 22:56, Alberto Mardegan wrote:
[...]
if (d)
It's not if (d) which I expect to be used for detaching, but just the
bool operator itself, if only as a short-cut to d.detach().
[...]
Sure, it is possible that some new issues will be found after the Qt6
release, but given the
On Tuesday, 18 June 2019 13:56:36 PDT Alberto Mardegan wrote:
> Well... Expecting the data to detach on an `if (d)` check seems worth
> incurring into a breakage
> But I certainly cannot exclude that there is some code out there which
> happens to work exactly because of this implicit detach, so
On 18/06/2019 22:56, Alberto Mardegan wrote:
On 18/06/19 10:43, Mutz, Marc via Development wrote:
On 2019-06-18 08:18, Alberto Mardegan wrote:
Adding a const bool operator to QSharedDataPointer would solve the
problem, wouldn't it?
And (silently) break code that relies on the current
On 18/06/2019 03.43, Mutz, Marc via Development wrote:
> BTW: this is the proposed replacement of QSDP/QESDP for Qt-internal use:
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 and no, it will
> most certainly _not_ be public API again. It's the fact that these
> implementation details
On 18/06/19 10:43, Mutz, Marc via Development wrote:
> On 2019-06-18 08:18, Alberto Mardegan wrote:
>>
>> Adding a const bool operator to QSharedDataPointer would solve the
>> problem, wouldn't it?
>
> And (silently) break code that relies on the current behaviour, yes.
Well... Expecting the
On 2019-06-18 08:18, Alberto Mardegan wrote:
On 05/06/19 01:39, Kevin Kofler wrote:
Mutz, Marc via Development wrote:
and produces surprises such as
https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
My existing QSharedDataPointer
On 05/06/19 01:39, Kevin Kofler wrote:
> Mutz, Marc via Development wrote:
>
>> and produces surprises such as
>> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
>
> My existing QSharedDataPointer code always checks truth with
> if
On 11/06/2019 22:13, André Pönitz wrote:
Can we at the very least agree that each party is allowed to use the
same*pattern* of reasoning in this discussion, no matter on how
much merit we see in the individual argument?
I'd rather avoid using any logical fallacy when possible, instead of
On Tue, Jun 11, 2019 at 12:36:12AM +0200, Giuseppe D'Angelo via Development
wrote:
> Il 10/06/19 23:45, Kevin Kofler ha scritto:
> > Perhaps you forgot to read the part where I said:
> >
> > > I, for one, don't give a darn about all those new C++11/14/whatever STL
> > > features.
>
> That's a
On 11/06/2019 15.35, Danila Malyutin wrote:
> вт, 11 июн. 2019 г. в 22:22, Matthew Woehlke:
>> On 04/06/2019 16.41, Mutz, Marc via Development wrote:
>>> How do you intend to address the problem that QHash/QMap are all but
>>> unusable in C++11 ranged for loops, because of decltype(*it)?
>>
>> The
> The converse (always having to write `.second`, not to mention the
*name* "second") has its own annoyances.
You don't have to write that:
for (const auto &[key, value] : m)
вт, 11 июн. 2019 г. в 22:22, Matthew Woehlke :
> On 04/06/2019 16.41, Mutz, Marc via Development wrote:
> > On
On 04/06/2019 16.41, Mutz, Marc via Development wrote:
> On 2019-06-03 11:26, Lars Knoll wrote:
>>> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>>
>> I see no reason at all for removing those, quite to the contrary. They
>> are very helpful for building refcounted classes (explicitly
On 30/05/2019 04.12, d3fault wrote:
> On 5/29/19, Mutz, Marc via Development wrote:
>> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>>
>> These are basically Qt-internals, and should never have been public in
>> the first place.
>
> I disagree (unless there's some replacement you
On 05/06/2019 10.23, Elvis Stansvik wrote:
> Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development:
>> [...] This, and many other such instances, show me that the Qt
>> containers are considered good enough [...]
>
> I guess that is the case. At least I haven't craved for any of the
>
On 03/06/2019 01.49, Thiago Macieira wrote:
> On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
>> I also managed to get that done with a <10 lines of "plain cmake":
>>
>> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05
>> 7/src/CMakeLists.txt#L46-L54
>
>
PS:
Giuseppe D'Angelo via Development wrote:
> That's a straw man. Since YOU don't care, then NOBODY cares.
For the record, I am surely not the only one who thinks that way, see also
Boudewijn Rempt's reply. But it is so much easier to just strawman on the
formulation and attempt to dismiss
Giuseppe D'Angelo via Development wrote:
> Sorry, plonking you.
So is this the discussion culture of the Qt Project? If you don't agree with
somebody, you just ignore him? Way to go…
Kevin Kofler
___
Development mailing list
Il 10/06/19 23:45, Kevin Kofler ha scritto:
Perhaps you forgot to read the part where I said:
I, for one, don't give a darn about all those new C++11/14/whatever STL
features.
That's a straw man. Since YOU don't care, then NOBODY cares.
Sorry, plonking you.
--
Giuseppe D'Angelo |
Giuseppe D'Angelo via Development wrote:
> Perhaps you forgot to read the part where I said:
>
>> Then, it comes a moment when "upstream" stuff has more and more
>> advantages -- more speed (algorithms), more flexibility (e.g. mutex
>> classes and utilities; shared_ptr; etc.), more static
Giuseppe D'Angelo via Development wrote:
> There are some practical problems with this:
>
> 1) It creates technological debt into QtCore, where we have to keep this
> stuff around forever (and working and supported on *all* platforms, and
> compatible with the latest compilers, etc.).
You call
10.06.2019, 13:10, "Giuseppe D'Angelo" :
> On 08/06/2019 21:39, Konstantin Tokarev wrote:
>>> What abouthttps://valdyas.org/fading/hacking/happy-porting/
>>>
>>> "[...] none, not a single one of all of the reasons you want to
>>> deprecate
>>> Q_FOREACH is a reason I care even a
Hi,
On 08/06/2019 19:17, Boudewijn Rempt via Development wrote:
I kept out of this for the longest time, especially because people have been
quoting my blog post, but I give up now.
On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote:
Then, it comes a moment when
On 09/06/2019 00:09, Kevin Kofler wrote:
André Pönitz wrote:
I see that pattern, too. But now, instead putting the break between 3) and
4), the whole thing is killed, and everybody downstream has to do 1)-3)
again, or put up with what the standard offers.
And could prevent overextension by
On 09/06/2019 13:38, André Pönitz wrote:
So effectively, application developers need to support multiple versions
of Qt as they cannot really be sure which of their version the
distributors will combine with which version of Qt which is
conveniently ignored by our deprecators when they
On 08/06/2019 20:31, André Pönitz wrote:
On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development
wrote:
On 05/06/2019 23:01, André Pönitz wrote:
As a matter of fact, some of the previous deprecations, e.g. the removal
of qalgorithm, triggered re-implementing the deprecated
On 09/06/2019 00:00, Kevin Kofler wrote:
There is one option missing:
* We could just keep the Qt equivalent as is, without adding the features
of the STL equivalent if there is no manpower to port them to the Qt
equivalent. Developers using the Qt version are happy with the Qt version
On 08/06/2019 21:39, Konstantin Tokarev wrote:
What abouthttps://valdyas.org/fading/hacking/happy-porting/
"[...] none, not a single one of all of the reasons you want to deprecate
Q_FOREACH is a reason I care even a little bit about. It’s going to
be deprecated? Well, that’s a
On Sun, Jun 09, 2019 at 10:10:36AM +0200, Allan Sandfeld Jensen wrote:
> On Sonntag, 9. Juni 2019 00:09:30 CEST Kevin Kofler wrote:
> > QtAlgorithms should just be undeprecated. I don't care whether std::sort is
> > faster. If the version of Qt I tested with was fast enough, then I'm
> > perfectly
On Sun, Jun 09, 2019 at 12:30:23AM +0200, Иван Комиссаров wrote:
> No, they should not.
>
> C++ committee understands the problem of ugly iterators and it seems they
> have a solution - ranges.
>
> Why do you want to use qSort instead of std::ranges::sort?
Because the compiler might not
On Sat, Jun 08, 2019 at 10:39:09PM +0300, Konstantin Tokarev wrote:
> > What about https://valdyas.org/fading/hacking/happy-porting/
> >
> > "[...] none, not a single one of all of the reasons you want to
> > deprecate Q_FOREACH is a reason I care even a little bit about.
> > It’s going to
On Sonntag, 9. Juni 2019 00:09:30 CEST Kevin Kofler wrote:
> QtAlgorithms should just be undeprecated. I don't care whether std::sort is
> faster. If the version of Qt I tested with was fast enough, then I'm
> perfectly fine with newer versions not being faster, no matter how fast some
>
No, they should not.
C++ committee understands the problem of ugly iterators and it seems they have
a solution - ranges.
Why do you want to use qSort instead of std::ranges::sort?
QVector v;
qSort(v);
std::ranges::sort(v);
I don’t see any advantages of the qSort() here.
No more ugly
09.06.2019, 01:26, "Konstantin Tokarev" :
> 09.06.2019, 01:02, "Kevin Kofler" :
>> Giuseppe D'Angelo via Development wrote:
>>> In other words, the advantages of keeping the Qt equivalents start to be
>>> (seriously) questioned. We're therefore left with the question of what
>>> to do
09.06.2019, 01:02, "Kevin Kofler" :
> Giuseppe D'Angelo via Development wrote:
>> In other words, the advantages of keeping the Qt equivalents start to be
>> (seriously) questioned. We're therefore left with the question of what
>> to do with these equivalents.
>>
>> * We could play the
André Pönitz wrote:
> I see that pattern, too. But now, instead putting the break between 3) and
> 4), the whole thing is killed, and everybody downstream has to do 1)-3)
> again, or put up with what the standard offers.
>
> And could prevent overextension by -x'ing the respective change on
08.06.2019, 19:16, "Giuseppe D'Angelo via Development"
:
> On 05/06/2019 23:01, André Pönitz wrote:
>> As a matter of fact, some of the previous deprecations, e.g. the removal
>> of qalgorithm, triggered re-implementing the deprecated functionality
>> downstream, effectively shifting the
08.06.2019, 21:33, "André Pönitz" :
> On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development
> wrote:
>> On 05/06/2019 23:01, André Pönitz wrote:
>> > As a matter of fact, some of the previous deprecations, e.g. the removal
>> > of qalgorithm, triggered re-implementing
On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 05/06/2019 23:01, André Pönitz wrote:
> > As a matter of fact, some of the previous deprecations, e.g. the removal
> > of qalgorithm, triggered re-implementing the deprecated functionality
> > downstream,
I kept out of this for the longest time, especially because people have been
quoting my blog post, but I give up now.
On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote:
>
> Then, it comes a moment when "upstream" stuff has more and more
> advantages -- more speed
On 05/06/2019 23:01, André Pönitz wrote:
As a matter of fact, some of the previous deprecations, e.g. the removal
of qalgorithm, triggered re-implementing the deprecated functionality
downstream, effectively shifting the burden of doing (or, rather,
*keeping*) them once centrally to all users
> The "mixed signal" here is that someone in an ivory tower decided to
> deprecate something but was not able to offer a viable alternative.
>
> Either because there simply was none (in which case the deprecation was
> wrong, and should be undone) or because the work-around was too much hassle
>
On Wednesday, 5 June 2019 13:36:01 PDT André Pönitz wrote:
> > Yes, I've complained that most distros can't seem to compile them to be
> > compatible correctly. But that's not Qt's problem that one (or most) of
> > them fail to do their job properly.
>
> It's not "Qt's problem" per se, but it's
On Wed, Jun 05, 2019 at 01:41:25PM +0200, Mutz, Marc via Development wrote:
> On 2019-06-05 10:40, Edward Welbourne wrote:
> [...]
> > If some things are deprecated and never removed (QRegEx springs to
> > mind), while others get removed (comparably) soon after deprecation
> > (e.g. everything
On Tue, Jun 04, 2019 at 09:58:18PM -0700, Thiago Macieira wrote:
> On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote:
> > You talk about a particular incarnation of stdlibs, I was talking about
> > the general case. Yes, in the case you describe, and _if_ libc++ is
> >
Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development
:
>
> On 2019-06-03 14:27, Bernhard Lindner wrote:
> >> > > > So, yes, this is borne out of frustration with the lack of
> >> > > > maintenance
> >> > > > of QtCore plumbing. I don't see that changing and I acknowledge and
> >> > > >
On 2019-06-05 10:40, Edward Welbourne wrote:
[...]
If some things are deprecated and never removed (QRegEx springs to
mind), while others get removed (comparably) soon after deprecation
(e.g. everything we're currently deprecating with intent to remove in
Qt
6), maintainers of client code get
On 2019-06-03 14:27, Bernhard Lindner wrote:
> > > So, yes, this is borne out of frustration with the lack of maintenance
> > > of QtCore plumbing. I don't see that changing and I acknowledge and
> > > understand that the focus of development has shifted towards QML.
> > Suppose you implement
Samuel Gaist wrote:
>> On 5 Jun 2019, at 00:39, Kevin Kofler wrote:
>> Can't we just add a keySet() method (named after the Java one that does
>> something similar) that returns a wrapper object that just forwards
>> begin() to the map's keyBegin() etc.? Then you could just write something
>>
[...]
>>> == Java-style iteration
>>> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
[...]
On 2019-06-03 11:26, Lars Knoll wrote:
>> I’m a bit torn here. On code review I gave a +1 on deprecating them,
>> but I see that this could lead to a lot of porting effort on user
>> code that
> On 5 Jun 2019, at 00:39, Kevin Kofler wrote:
>
> Mutz, Marc via Development wrote:
>> I'd still like to deprecate them. QSDP is issuing atomic operations on
>> each mutable access hurting code-gen,
>
> Well yes, you have to use constData() or cast to const where needed. That
> does not
On Monday, 3 June 2019 19:10:12 PDT Thiago Macieira wrote:
> First, I want to pass the XML source through
> xml sel -D -B -t -c /
>
> That will minify the source. That reduces the uncompressed size by about
> 10%.
>
> Second, I'm also thinking of compressing with gzip or zstd. The
On Tue, 04 Jun 2019 22:41:31 +0200
"Mutz, Marc via Development" wrote:
> That QThread is-a QObject has caused problems in the past. How to use
> QThread correctly has been the source of much discussion (e.g.
> https://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/), and any
> thread can
On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote:
> You talk about a particular incarnation of stdlibs, I was talking about
> the general case. Yes, in the case you describe, and _if_ libc++ is
> configured to be compatible (which in the past you have complained is
> not done
On Tuesday, 4 June 2019 13:41:31 PDT Mutz, Marc via Development wrote:
> That QThread is-a QObject has caused problems in the past. How to use
> QThread correctly has been the source of much discussion (e.g.
> https://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/), and any
> thread can have an
Mutz, Marc via Development wrote:
> I'd still like to deprecate them. QSDP is issuing atomic operations on
> each mutable access hurting code-gen,
Well yes, you have to use constData() or cast to const where needed. That
does not reduce QSharedDataPointer's usefulness. It is an implementation
On Mon, Jun 03, 2019 at 10:59:59AM -0700, Thiago Macieira wrote:
> It can only read qmake files.
>
nope
> And it lacks the transform functions to produce an hex dump.
>
nope
___
Development mailing list
Development@qt-project.org
On 2019-06-03 11:26, Lars Knoll wrote:
[...]
== QSharedDataPointer / QExplicitlySharedDataPointer ==
[...]
I see no reason at all for removing those, quite to the contrary. They
are very helpful for building refcounted classes (explicitly or
implicitly shared).
I'd still like to deprecate
On 2019-05-30 20:35, Thiago Macieira wrote:
On Wednesday, 29 May 2019 08:13:51 PDT Olivier Goffart wrote:
[...]
> === QWaitCondition -> std::condition_variable(_any) ===
Yes.
Can't change QWaitCondition without changing QMutex. It's all or
nothing.
I believe std::condition_variable_any
On 2019-05-30 20:27, Thiago Macieira wrote:
On Wednesday, 29 May 2019 08:17:15 PDT Mutz, Marc via Development
wrote:
But of course, that's a fallacy, because as soon as Qt internally uses
said inline functions, every use of them by the user with a different
STL is an ODR violation and therefore
On Monday, 3 June 2019 18:46:31 PDT Konstantin Tokarev wrote:
> This can be done with qmake if we implement ord
I want to do a bit more in the shell script. All steps optional:
First, I want to pass the XML source through
xml sel -D -B -t -c /
That will minify the source. That reduces
03.06.2019, 21:01, "Thiago Macieira" :
> On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote:
>> 03.06.2019, 09:06, "Thiago Macieira" :
>> > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
>> >> I also managed to get that done with a <10 lines of "plain cmake":
>> >>
>>
04.06.2019, 04:41, "Thiago Macieira" :
> On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote:
>> This script takes a hideously enormous amount of time to run. I hope it's
>> because that's just a really long line. Found this script that seems to
>> break every 16 bytes:
>>
On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote:
> This script takes a hideously enormous amount of time to run. I hope it's
> because that's just a really long line. Found this script that seems to
> break every 16 bytes:
> https://github.com/sperner/PowerShell/blob/master/HexDump.ps1
On Monday, 3 June 2019 17:50:58 PDT Danila Malyutin wrote:
> Have you tried running the script with "powershell –ExecutionPolicy Bypass"
> ? IRC, this should work for regular non-admin users to. If that does work,
> I think you can just pipe the script to "powershell -".
That works, thanks.
This
Have you tried running the script with "powershell –ExecutionPolicy Bypass"
? IRC, this should work for regular non-admin users to. If that does work,
I think you can just pipe the script to "powershell -".
вт, 4 июн. 2019 г. в 01:54, Thiago Macieira :
> On Saturday, 1 June 2019 08:14:13 PDT
On Saturday, 1 June 2019 08:14:13 PDT Jean-Michaël Celerier wrote:
> xxd.ps1:
> param([String]$path)
>
> $bytes = [System.IO.File]::ReadAllBytes($path);
> $size = $bytes.length;
>
> $bytes = (($bytes | %{ "0x" + $_ ; }) | Out-String);
> $content = $bytes -replace "`r",", " -replace "`n",""
On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote:
> 03.06.2019, 09:06, "Thiago Macieira" :
> > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
> >> I also managed to get that done with a <10 lines of "plain cmake":
> >>
> >>
On Monday, 3 June 2019 10:31:14 PDT Thiago Macieira wrote:
> A semantic replacement could be used to refactor the code from load() →
> load(std::memory_order_relaxed) and loadAcquire() → load().
Another idea is to introduce loadRelaxed() and storeRelaxed() in Qt 5.13,
right now, so we can mark
03.06.2019, 09:06, "Thiago Macieira" :
> On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
>> I also managed to get that done with a <10 lines of "plain cmake":
>>
>> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05
>> 7/src/CMakeLists.txt#L46-L54
>
> Yup,
On Monday, 3 June 2019 02:26:05 PDT Lars Knoll wrote:
> > == Java-style iteration
> > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
> > It's very easy to write quadratic loops with it.remove(), and a review of
> > Qt code has shown that some users still use container.remove(),
> > > > So, yes, this is borne out of frustration with the lack of maintenance
> > > > of QtCore plumbing. I don't see that changing and I acknowledge and
> > > > understand that the focus of development has shifted towards QML.
> > > Suppose you implement all planned actions for Qt6 (see your
> On 1 Jun 2019, at 21:20, Bernhard Lindner wrote:
>
> Am Mittwoch, den 29.05.2019, 23:34 +0200 schrieb Mutz, Marc via Development:
>
>>> So, yes, this is borne out of frustration with the lack of maintenance
>>> of QtCore plumbing. I don't see that changing and I acknowledge and
>>>
Also here going back to the start of the thread (as I was offline for some days
for a long weekend):
> On 29 May 2019, at 12:53, Mutz, Marc via Development
> wrote:
>
> Hi,
>
> Here's a list of stuff I consider has served it's purpose and is no longer
> needed, with respective replacements:
On Saturday, June 1, 2019 5:36:35 AM CEST Thiago Macieira wrote:
> On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote:
> > rcc should be un-bootstrapped. The only use inside QtCore is for the MIME
> > type database. We don't need a resource, though it compresses really well
> > (roughly
On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
> I also managed to get that done with a <10 lines of "plain cmake":
>
> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05
> 7/src/CMakeLists.txt#L46-L54
Yup, I figured with CMake it would be possible. But I'm
On 01.06.19 17:56, Thiago Macieira wrote:
On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote:
I am getting mildly irritated by those ongoing suggestions (not just
yours) to use anything but Qt to get stuff done, even Qt's own tasks.
It's sending an odd message.
Sure, one can pull e.g.
Am Mittwoch, den 29.05.2019, 23:34 +0200 schrieb Mutz, Marc via Development:
> > So, yes, this is borne out of frustration with the lack of maintenance
> > of QtCore plumbing. I don't see that changing and I acknowledge and
> > understand that the focus of development has shifted towards QML.
Here's a PS1 script that more or less does it (god that language is awful
to use) :
xxd.ps1:
param([String]$path)
$bytes = [System.IO.File]::ReadAllBytes($path);
$size = $bytes.length;
$bytes = (($bytes | %{ "0x" + $_ ; }) | Out-String);
$content = $bytes -replace "`r",", " -replace "`n",""
On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote:
> I am getting mildly irritated by those ongoing suggestions (not just
> yours) to use anything but Qt to get stuff done, even Qt's own tasks.
> It's sending an odd message.
>
> Sure, one can pull e.g. any "plain C++" replacement for
On Fri, May 31, 2019 at 11:22:03AM +0200, Tobias Hunger wrote:
> Hi Thiago,
>
> On Thu, May 30, 2019 at 8:18 PM Thiago Macieira
> wrote:
> > On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> > wrote:
> > > 2) should QRegExp stay in bootstrap? I have no idea of what's
To bypass the MSVC limitation I think that you need to use array notation
instead of string literals, with the help of a tool such as xxd.
Apparently powershell has a command to more-or-less do it (format-hex),
with some PS magic it could maybe work without too much dependencies added
on
On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote:
> rcc should be un-bootstrapped. The only use inside QtCore is for the MIME
> type database. We don't need a resource, though it compresses really well
> (roughly 10:1 with zstd). I'd simply make that a read-only sharable
> variable, which
On Friday, 31 May 2019 11:55:59 PDT Bogdan Vatra via Development wrote:
> > PCH is a nice to have, but does not stop us from building Qt.
> >
> > iOS support is a problem. We need to make sure the tools we choose support
> > us.
>
> Without PCH the build time will increase a lot.
20 to 50% at
În ziua de vineri, 31 mai 2019, la 19:03:46 EEST, Thiago Macieira a scris:
> On Thursday, 30 May 2019 22:45:02 PDT Bogdan Vatra via Development wrote:
> > Hi,
> >
> > În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> > > On Thursday, 30 May 2019 15:51:26 PDT Konstantin
31.05.2019, 12:37, "Tobias Hunger" :
> On Fri, 2019-05-31 at 01:37 +0300, Konstantin Tokarev wrote:
>> > I understand, but aside from qmake, I don't know of any build system that
>> > allows for building both host and target in the same build. That means
>> > whatever we use in Qt 6, we'll a
On Friday, 31 May 2019 02:22:03 PDT Tobias Hunger wrote:
> Hi Thiago,
>
> On Thu, May 30, 2019 at 8:18 PM Thiago Macieira
>
> wrote:
> > On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> >
> > wrote:
> > > 2) should QRegExp stay in bootstrap? I have no idea of what's
On Thursday, 30 May 2019 22:45:02 PDT Bogdan Vatra via Development wrote:
> Hi,
>
> În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> > On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> > > BTW, are you also planning to drop support for using PCH with
On 31/05/2019 11:06, Alberto Mardegan wrote:
I bet it's unused because everyone is using QList. But once we deprecate
QList, people will start asking for a CoW version of std::list.
QList has nothing to do with std::list!
(Except a very similar name.)
How many times does this need to be
On Fri, 2019-05-31 at 01:37 +0300, Konstantin Tokarev wrote:
> > I understand, but aside from qmake, I don't know of any build system that
> > allows for building both host and target in the same build. That means
> > whatever we use in Qt 6, we'll a separate build for host tools when cross-
> >
1 - 100 of 153 matches
Mail list logo
