On Monday, 5 November 2018 21:30:47 PST Tomasz Olszak wrote:
> Still there is a performance regression somewhere and while the C++
> solution is most performant the cause of this regression can hit other
> parts of Qml stack.
Not necessarily. This may be a side-effect of performance improvements
Am 06.11.18 um 06:30 schrieb Tomasz Olszak:
> Still there is a performance regression somewhere and while the C++
> solution is most performant
will try again to find a C++ solution for Android, iOS
> the cause of this regression can hit other
> parts of Qml stack.
have created bug with example
Am 06.11.18 um 06:20 schrieb Thiago Macieira:
> On Monday, 5 November 2018 11:32:03 PST ekke wrote:
>> Thanks, Thiago for the hint - that was the first thing I tried, but
>> couldn't figure out HowTo make it work on Android and iOS.
>> unfortunately now with 5.12 Beta it slows down by 20x.
> Then
Still there is a performance regression somewhere and while the C++
solution is most performant the cause of this regression can hit other
parts of Qml stack.
Ekke do you use prebuilt binaries or do you compile them yourself?
If you compile yourself you can bisect and find the cause. Not many
On Monday, 5 November 2018 11:32:03 PST ekke wrote:
> Thanks, Thiago for the hint - that was the first thing I tried, but
> couldn't figure out HowTo make it work on Android and iOS.
> unfortunately now with 5.12 Beta it slows down by 20x.
Then get a 400x improvement by trying the C++ part
There is a warning in the OS X part of the build instructions (OS X builds with
clang) not to do a parallel build (-J > 1) due to competing dependencies.
> On Nov 5, 2018, at 2:32 PM, interest-requ...@qt-project.org wrote:
>
> Send Interest mailing list submissions to
>
On Monday, 5 November 2018 11:33:58 PST René J.V. Bertin wrote:
> On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
> >In my experience clang generates significantly more compact binaries
>
> Quite: bzipped tarballs of everything except the examples, translations,
> QWE, QtWebView and
On Montag, 5. November 2018 20:33:58 CET René J.V. Bertin wrote:
> On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
> >In my experience clang generates significantly more compact binaries
>
> Quite: bzipped tarballs of everything except the examples, translations,
> QWE, QtWebView and
On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
>In my experience clang generates significantly more compact binaries
Quite: bzipped tarballs of everything except the examples, translations, QWE,
QtWebView and Qt3D:
-rw-r--r-- 1 root root 363M Sep 8 13:22
Am 05.11.18 um 17:59 schrieb Thiago Macieira:
> On Monday, 5 November 2018 05:49:33 PST ekke wrote:
>> created a example app and now noticed, the app doesn't freeze,
>> but the exection of encrypt() slows down from
>>
>> 5 sec (Qt 5.11.2) to
>> 92 sec (Qt 5.12 Beta3)
>>
>> will open a bug report
>
On Monday November 05 2018 16:50:10 Jean-Michaël Celerier wrote:
>it's just the release / dynamic configuration that crashes, and I don't
>know how to instruct Qt's configure to keep debug symbols for release
>builds of the tools in order to get a proper stacktrace.
I use these arguments to
Hi,
Il 05/11/18 16:07, rol...@logikalsolutions.com ha scritto:
Switching the containers to just be wrappers around std::
implementations would also be a dramatic break.
Assuming by "wrappers" you mean "implicitly shared wrappers", why would
it be a break?
Cheers,
--
Giuseppe D'Angelo |
On Monday, 5 November 2018 07:50:10 PST Jean-Michaël Celerier wrote:
> it's just the release / dynamic configuration that crashes, and I don't
> know how to instruct Qt's configure to keep debug symbols for release
> builds of the tools in order to get a proper stacktrace.
Edit the Makefile after
On Monday, 5 November 2018 05:49:33 PST ekke wrote:
> created a example app and now noticed, the app doesn't freeze,
> but the exection of encrypt() slows down from
>
> 5 sec (Qt 5.11.2) to
> 92 sec (Qt 5.12 Beta3)
>
> will open a bug report
How about you encrypt using C++ instead? OpenSSL
Qt is probably only used into a part of the Dashboard or entertainment system,
the controller chip or embedded MCU and other safety controller are probably
not using Qt nor C++. They follow some MISRA, AUTOSAR, CERT standard. They
have a C++ standard, but seriously it prevent a good chunk of
Quoting Jérôme Godbout :
JPL would be a good thing if you were to make a peacemaker for
example. It's more for embedded C software where dynamic alloc is
not allowed (just like car industries). If you plan on running C++
on a
Stupid question, but if dynamic memory allocation is not
I did a few medical application for orthopedic surgery, the coding standard is
not a requirement, but only a simplest way to validate your software. I did
used Qt into all of them and we manage to certify them for surgery room. It
always depend on the level or risk your software lies on. Also
On 11/05/2018 10:38 AM, Allan Sandfeld Jensen wrote:
On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
I tried building everything with clang 7 and libc++ last week but hit a
qlalr segfault during build. I've been trying to debug it ever since to no
avail.
clang sometimes
Quoting Jason H :
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512
> clang sometimes segfaults while compiling, the crash usually goes if I
try
again.
in my case it's not clang which crashes but the qlalr that clang produces.
For some reason it works :
- when building in debug
- when building statically
it's just the release / dynamic configuration that
On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
> I tried building everything with clang 7 and libc++ last week but hit a
> qlalr segfault during build. I've been trying to debug it ever since to no
> avail.
>
>
clang sometimes segfaults while compiling, the crash usually
On Montag, 5. November 2018 12:03:31 CET René J.V. Bertin wrote:
> Hi,
>
> Last time I asked the advice was still not to bother with trying to build
> (all of) Qt with clang on Linux. Is that still the case or is it now safe
> to use clang (5 or 6)?
>
> In my experience clang generates
> Sent: Monday, November 05, 2018 at 9:42 AM
> From: rol...@logikalsolutions.com
> To: "Jean-Michaël Celerier"
> Cc: interest
> Subject: Re: [Interest] Chasing a standard
>
>
> Quoting Jean-Michaël Celerier :
>
> >> As I said a couple of times, we do not intend to break APIs in any major
> >
Quoting Giuseppe D'Angelo:
Hold on -- I don't think that anyone wants to make Qt containers NOT
implictly shared. In other words, Qt 6 containers will be implictly
shared just as today. It would be a gigantic break if we suddenly made
them not shared.
Well, there have been others on
Quoting Jean-Michaël Celerier :
As I said a couple of times, we do not intend to break APIs in any major
way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do
Quoting Tomasz Siekierda :
On Mon, 5 Nov 2018 at 13:35, Roland Hughes
wrote:
On 11/4/18 3:52 PM, Lars Knoll wrote:
>> On 4 Nov 2018, at 22:13, Roland Hughes
wrote:
>>
>>
>> We already lose droves of Qt developers every year when Qt keeps
moving on but medical devices, border
On Mon, 05 Nov 2018 14:41:11 +0100, Giuseppe D'Angelo via Interest wrote:
> Didn't you hear from Microsoft? They went from being the
> slowest adopter to the fastest -- to this date, MSVC 2017.7 is the
> _only_ C++ compiler that supports the entirety of C++17! That indeed
> shows their
created a example app and now noticed, the app doesn't freeze,
but the exection of encrypt() slows down from
5 sec (Qt 5.11.2) to
92 sec (Qt 5.12 Beta3)
will open a bug report
Am 05.11.18 um 12:00 schrieb ekke:
> Qt 5.12 Beta 3. Android and iOS
>
> in one of my apps I had to encrypt the user
Hi,
On 04/11/2018 00:07, Roland Hughes wrote:
Giuseppe,
I missed the beginning of this thread and don't have enough time for one
of my usual missives. I did want to take issue with the comment about
using C++ latest.
It's _never_ a good idea to chase a standard.
[citation needed], I'm
On Mon, 5 Nov 2018 at 13:35, Roland Hughes wrote:
>
>
> On 11/4/18 3:52 PM, Lars Knoll wrote:
> >> On 4 Nov 2018, at 22:13, Roland Hughes wrote:
> >>
> >>
> >> We already lose droves of Qt developers every year when Qt keeps moving on
> >> but medical devices, border security systems like cargo
On 11/4/18 3:52 PM, Lars Knoll wrote:
On 4 Nov 2018, at 22:13, Roland Hughes wrote:
We already lose droves of Qt developers every year when Qt keeps moving on but
medical devices, border security systems like cargo x-ray, train control
systems, etc. have to fork their own version of Qt
On Monday November 05 2018 12:10:15 Jean-Michaël Celerier wrote:
> I tried building everything with clang 7 and libc++ last week but hit a
> qlalr segfault during build. I've been trying to debug it ever since to no
> avail.
Building with libc++ and the very latest Clang may just have been a
Hi,
Il 05/11/18 12:08, Jean-Michaël Celerier ha scritto:
It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display
I tried building everything with clang 7 and libc++ last week but hit a
qlalr segfault during build. I've been trying to debug it ever since to no
avail.
Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Mon, Nov 5, 2018 at 12:04 PM René J.V. Bertin
wrote:
> Hi,
>
> Last time
> As I said a couple of times, we do not intend to break APIs in any major
way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.
It's not only about breaking
Hi,
Last time I asked the advice was still not to bother with trying to build (all
of) Qt with clang on Linux. Is that still the case or is it now safe to use
clang (5 or 6)?
In my experience clang generates significantly more compact binaries, which
should reduce load times. Build time
Qt 5.12 Beta 3. Android and iOS
in one of my apps I had to encrypt the user password using a JavaScript
library
http://www-cs-students.stanford.edu/%7Etjw/jsbn/
from there I put these .js into resources:
js/rsbn/base64.js
js/rsbn/jsbn.js
js/rsbn/prng4.js
Dear Marcus,
Thank you very much!
Kind regards,
Robert Iakobashvili
On Mon, Nov 5, 2018 at 10:50 AM Markus Maier wrote:
>
> Hi,
>
> I didn't look through your logs in detail, but the issue sounds like it might
> be related to
Hi Roman,
I am not aware of any other API. The only reference I can find is pointing the
BluetoothHIDDevice. I'd say this feature is simply not available for any
earlier devices. Of course you can always use reflection via e.g.
QtAndroidExtras to add conditional support for this feature to
Hi,
I didn't look through your logs in detail, but the issue sounds like it
might be related to https://bugreports.qt.io/browse/QTBUG-68813 - I needed
the workaround from the end of the bug's description in order to get my JNI
calls working again. My code also works with Qt 5.9 and doesn't work
40 matches
Mail list logo
