On Sunday 25 October 2015 19:07:49 Thiago Macieira wrote:
> Is it a persistent problem? Or did it fail only in the change-over hour?
>
> There are always problems with the changeover hour.
It failed all of yesterday. Now works. Cf. e.g.
https://codereview.qt-project.org/138771
--
Marc Mutz
On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
> The purpose of QDataBuffer is to provide a managed pool of memory that can
> grow, but does not shrink unless shrunk explicitly. QVector is unusable
> for this purpose as a resize/clear/append would cause a lot of
> reallocations for the
> On 26 Oct 2015, at 09:56, Marc Mutz wrote:
>
> On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
>> I don't know if std::vector::erase() and std::vector::clear() can guarantee
>> that the data is not reallocated, even if reserve() has been specified. If
>> that can
The purpose of QDataBuffer is to provide a managed pool of memory that can
grow, but does not shrink unless shrunk explicitly. QVector is unusable for
this purpose as a resize/clear/append would cause a lot of reallocations for
the places where QDataBuffer is used.
I don't know if
On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
> I don't know if std::vector::erase() and std::vector::clear() can guarantee
> that the data is not reallocated, even if reserve() has been specified. If
> that can be guaranteed, removing the class would be fine by me.
Since
Hi all:
Qt statically build program is fail.
libQt5Core.a depend on libpcre16
libQt5Gui.a depend on -lopengl32, -lglu32
What do I?
Here is my configuration and compilation:
Qt5.5.1 statically compiled, my configure:
./configure -opensource -confirm-license -nomake examples
> On 26 Oct 2015, at 10:12, Marc Mutz wrote:
>
> On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
>> The purpose of QDataBuffer is to provide a managed pool of memory that can
>> grow, but does not shrink unless shrunk explicitly. QVector is unusable
>> for this
On Monday 26 October 2015 09:41:00 Gunnar Sletta wrote:
> Also, given the purpose of this class, then using QDataBuffer as an
> on-the-stack member in a function (like in mergePoints()) will pretty much
> always be wrong. There is no point in using a pool when it is discarded
> after a single use,
Hi All,
I have started resurrecting support for building Qt for the INTEGRITY
RTOS using the Green Hills toolchain.
Right now, what works includes:
- Core, Gui, Network, Xml, Sql, Widgets
- Qml without Quick
- QImageFormats
- XmlPatterns
- Svg
- rendering to a classic framebuffer and input from
Thiago Macieira:
1. I think this is a bug. When using cmake project file, it has the
responsibility to deal with it automatic dependency, rather than by the user
to deal with.
2. No bug for qt. How to use .prl and .pc in cmake or pro file?
-邮件原件-
发件人: development-boun...@qt-project.org
On Tuesday 27 October 2015 09:05:34 kl222 via Development wrote:
> Thiago Macieira:
>
> 1. I think this is a bug. When using cmake project file, it has the
> responsibility to deal with it automatic dependency, rather than by the user
> to deal with.
That might be. So please report it so this
Hi,
On Mon, 26 Oct 2015 12:43:48 +0100, Marc Mutz wrote:
> It failed all of yesterday. Now works. Cf. e.g.
> https://codereview.qt-project.org/138771
Exactly, it works now for me too.
--
Dmitry Shachnev
signature.asc
Description: OpenPGP digital signature
I am interested in learning more about the core tools used in Qt's new CI
system.
I would also like to create a job to build Qt from source for OSX-Android-iOS,
and Windows binaries to help me keep up with the dev branch progress better.
I use Jenkins CI to build desktop / mobile app software
On Monday 26 October 2015 15:57:30 kl222 wrote:
> Hi all:
>
> Qt statically build program is fail.
>
> libQt5Core.a depend on libpcre16
>
> libQt5Gui.a depend on -lopengl32, -lglu32
>
> What do I?
You link to those libraries.
>
-Original Message-
From: Dmitry Shachnev
To: development
Sent: Mon, Oct 26, 2015 8:11 am
Subject: Re: [Development] DST breakage in qtbase
Hi,
On Mon, 26 Oct 2015 12:43:48 +0100, Marc Mutz wrote:
> It failed all of
yesterday. Now
15 matches
Mail list logo