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 th
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:
>> https://githu
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
B
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 Jean
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","" -repl
Il 03/06/19 23:04, Kevin Kofler ha scritto:
Giuseppe D'Angelo via Development wrote:
Also, please name me 3 GUI frameworks that have not broken APIs for 30
years.
Also also, please name me 3 libraries that have not broken APIs for the
30 years.
There is at least one (almost): Win32 has now ex
Giuseppe D'Angelo via Development wrote:
> Also, please name me 3 GUI frameworks that have not broken APIs for 30
> years.
>
> Also also, please name me 3 libraries that have not broken APIs for the
> 30 years.
There is at least one (almost): Win32 has now existed for 26 years without
an ABI bre
Den mån 3 juni 2019 kl 20:29 skrev Richard Weickelt :
>
>
> > I think this was asked on the interest list back in January [1].
>
> I did search on the Qt mailing lists, but even when I type exactly the
> subject of the thread you referred to, google doesn't find it. I would
> expect "Official build
> I think this was asked on the interest list back in January [1].
I did search on the Qt mailing lists, but even when I type exactly the
subject of the thread you referred to, google doesn't find it. I would
expect "Official builds configuration options site:lists.qt-project.org" to
bring this p
Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik :
>
> Hi Richard,
>
> I think this was asked on the interest list back in January [1].
>
> The answer is here:
>
> https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config
>
> I seem to remember some recent Qt developer thread about m
Hi Richard,
I think this was asked on the interest list back in January [1].
The answer is here:
https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config
I seem to remember some recent Qt developer thread about making these
more accessible, but can't find it now.
HTH,
Elvis
[1]
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":
> >>
> >> https://github.com/woboq/moc-ng/blob/7cfa2b65efa
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 lo
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(), which
Hi,
where can I find the configure command lines that have been used for Qt
binary releases provided at https://download.qt.io/official_releases/qt/ ?
Is there also more information available about the environment they have
been built on? I am particularly interested in the Linux release.
Thanks
On Monday, 3 June 2019 06:26:36 PDT Giuseppe D'Angelo via Development wrote:
> > QList::prepend has O(1) amortized and O(n) worst case time complexity.
> > QVector::prepend has O(mn) (always!) time complexity.
> >
> > If you are dealing with a large class or struct, e.g. 800 bytes, then the
> > QV
On Monday, 3 June 2019 04:34:27 PDT Kevin Kofler wrote:
> Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years.
And yet, we can look at this exact
On Monday, 3 June 2019 01:50:26 PDT Giuseppe D'Angelo via Development wrote:
> At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus
> a couple of pointers or so, to bring it to 64 bytes (~ a cacheline).
The minimum size for a QString is 3 pointers, which would be 12 bytes on 32-
> On 3 Jun 2019, at 13:34, Kevin Kofler wrote:
>>> I'd rather get fewer (or even no) new features than losing existing ones.
>>
>> How is this even an argument? Qt will need to evolve and acquire
>> features to remain competitive. Again, development bandwidth is finite:
>> either the overall qual
Il 03/06/19 13:34, Kevin Kofler ha scritto:
Giuseppe D'Angelo via Development wrote:
Il 03/06/19 00:08, Kevin Kofler ha scritto:
What you call "obsolete functionality" is functionality that existing
code relies on and rightfully expects to remain there.
Rightfully? By what right exactly?
A
On 6/3/19 2:35 PM, Bernhard Lindner wrote:
What would be your story proposal? "Make Widgets great again"?
That would be one I would like to see.
But the story I'm actively working on is about a different Qt/Quick
framework. I hope, that we are allowed to give a presentation of what
this is
Hi,
Qt Design Studio 1.2 final is released today, see
https://blog.qt.io/blog/2019/06/03/qt-design-studio-1-2-released/
Big thanks to everyone involved!
Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
https://lis
> Actually each major release should have a story, that has to do with
> some sort of innovation that might require to remove old stuff.
Very good statement.
The current implicit stories seems to be: "Throw out some parts we can't
afford" and
"Replace the builds system". Which are both not a
> > > > 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 o
On 6/3/19 1:34 PM, Kevin Kofler wrote:
So I disagree with the assertion that Qt needs more features to
remain competitive.
Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that
does not make use of the graphics hardware, is begging for being replaced.
Quick Controls 1 was onc
> APIs in libraries are meant to be used. I consider it an entirely reasonable
> expectation by developers using the APIs that they will not be removed under
> them because the library developers consider them "obsolete". Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete"
Giuseppe D'Angelo via Development wrote:
> Il 03/06/19 00:08, Kevin Kofler ha scritto:
>> What you call "obsolete functionality" is functionality that existing
>> code relies on and rightfully expects to remain there.
>
> Rightfully? By what right exactly?
APIs in libraries are meant to be used.
> 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
>>> underst
On Sat, 1 Jun 2019 14:36:12 +0200
André Pönitz wrote:
> On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry
> > poorly designed architecture or APIs around with us throughout the Qt
> > 6 series, and as long as w
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote:
How is this even an argument? Qt will need to evolve and acquire
features to remain competitive.
The probably most important module - Qt/Widgets - sits on a graphic
stack, that had been identified as not being competitive many years
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:
Going back to the beginning of the thread.
> On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> It seems to me that many emails in the earlier deprecation thread were from
> users concerned by the problem of removal of functionality. This is not an
> old story.
> On 3 Jun 2019, at 08:00, Thiago Macieira wrote:
>
> On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote:
>> Well, something has to give. Either
>> a) Qt can never remove superseded APIs and classes (which is what
>> you suggested previously) and will eventually collapse under its own
>>
Il 03/06/19 00:08, Kevin Kofler ha scritto:
Ballast (obsolete functionality, for various degree of "obsolete") has
to be dropped from time to time, causing API breaks. The question in
this thread is how to manage those API breaks to be as painless as
possible.
What you call "obsolete functional
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 10:1
38 matches
Mail list logo
