Re: [Development] DST breakage in qtbase

[Marc Mutz]

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  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about the QDataBuffer from src/gui/painting

[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 places where QDataBuffer is used. 

QDataBuffer uses realloc(), which of course std::vector cannot. With a 
geometric growth strategy, this doesn't matter much, and most types held in 
QDataBuffer are PODs (maybe not in C++98, but in C++11), but if it turns out 
that it does matter, then fixing QVector to not shed excess capacity at the 
first opportunity would be the right thing to do.

That said, neither QVector nor std::vector will match the performance of 
QDataBuffer, which declines to care about such basic things as copying and safe 
appends from an already-existing element or Ts which aren't Q_PRIMITIVE_TYPE 
(it should assert that, btw).

But either (QVector w/fixed capacity management or std::vector) should be fast 
enough. Surely, the ported code will be faster, because stuff like calling 
points() over and over in QPathSegments::mergePoints() will be found and fixed.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about the QDataBuffer from src/gui/painting

[Gunnar Sletta]

> 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 be guaranteed, removing the class would be fine by me.
> 
> Since std::vector::erase(f,l) is guaranteed to preserve iterators and 
> references to elements before f, no reallocation can occur (unless f == 
> begin()).

Yeah, but that is kinda the point. I wanted a pool that I could reset and start 
over again and again and it would only reallocate when a previous pool size was 
exceeded. Using std::vector::erase() would mean a realloc could happen when the 
thing is cleared.

> 
> For clear(), that's not guaranteed, but is a common optimisation. So much so 
> that Scott Meyers has an item about how to shed excess capacity in Effective 
> STL.
> 
> We could add a testcase:
> 
>  std::vector v;
>  v.resize(1024);
>  v.clear();
>  QvERIFY(v.capacity() >= 1024);

If that passes on all our compilers, then I'm all for switching. 

> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about the QDataBuffer from src/gui/painting

[Gunnar Sletta]

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 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.

cheers,
Gunnar

> On 25 Oct 2015, at 20:28, Maks Naumov  wrote:
> 
> In my small change https://codereview.qt-project.org/#/c/138795/
> Marc Mutz wrote: "This class deserves to die. If you do not believe, copy an 
> instance and you'll see."
> 
> I agree with him, but it will be quite a big change because it is used in 
> many places.
> https://github.com/qtproject/qtbase/search?utf8=%E2%9C%93=QDataBuffer
> 
> QDataBuffer is a small version of std::vector with disabilities and the 
> constructor
> with one parameter(array size). It is intended only for the primitive data 
> types.
> https://github.com/qtproject/qtbase/blob/5.6/src/gui/painting/qdatabuffer_p.h
> 
> What do you think is it worth to leave QDataBuffer and update it a little?
> For example to add Q_DECL_NOEXCEPT, Q_DECL_CONSTEXPR ...,
> Type * buffer replace with QScopedPointer with QScopedPointerPodDeleter?
> Or replace QDataBeffer where it is used by the std::vector, of course,
> if it doesn't hurt performance?
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about the QDataBuffer from src/gui/painting

[Marc Mutz]

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 std::vector::erase(f,l) is guaranteed to preserve iterators and 
references to elements before f, no reallocation can occur (unless f == 
begin()).

For clear(), that's not guaranteed, but is a common optimisation. So much so 
that Scott Meyers has an item about how to shed excess capacity in Effective 
STL.

We could add a testcase:

  std::vector v;
  v.resize(1024);
  v.clear();
  QvERIFY(v.capacity() >= 1024);

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt static compiler error

[kl222]

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 -nomake tests 
-no-compile-examples -no-sql-sqlite -no-sql-odbc -skip qtdoc -skip 
qtwebkit-examples -prefix 
/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw_static/qt -I 
/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw_static/include -L 
/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw_static/lib -static 
-skip qt3d -skip qtcanvas3d -skip qtserialport -skip qtenginio -skip qtqa -skip 
qtscript -skip qtwayland -skip qtconnectivity -skip qtgraphicaleffects -skip 
qtimageformats -platform win32-g++ -skip qtandroidextras -skip qtx11extras 
-skip qtmacextras  -no-rpath -verbose

 

Ok. It compiled successfully.

 

Then build my program(https://github.com/KangLin/rabbitim/tree/Develop). My 
program with cmake.

The CMakefiles 
file(https://github.com/KangLin/rabbitim/blob/Develop/CMakeLists.txt):

SET(QT_COMPONENTS Core Gui Widgets Network Xml Multimedia)

FOREACH(_COMPONENT ${QT_COMPONENTS})

FIND_PACKAGE(Qt5${_COMPONENT} REQUIRED)

SET(QT_LIBRARIES ${QT_LIBRARIES} ${Qt5${_COMPONENT}_LIBRARIES})

ENDFOREACH()

SET(RABBITIM_LIBS

${RABBITIM_LIBS}

${QXMPP_LIBRARIES}

${OpenCV_LIBS}

${FFMPEG_LIBRARIES}

${VPX_LIBRARIES}

${SPEEX_LIBRARIES}

${CURL_LIBRARIES}

${OPENSSL_LIBRARIES}

${QT_LIBRARIES}

)

add_executable(${PROJECT_NAME} WIN32

${RABBITIM_SOURCES}

${RABBITIM_RCC_FILES}

${RABBITIM_UIS}

)

target_link_libraries(${PROJECT_NAME} 

${RABBITIM_LIBS}

)

 

My configure:

cmake .. -G"MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release 
-DQt5_DIR=/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw_static/qt/lib/cmake/Qt5
 -DCMAKE_VERBOSE_MAKEFILE=TRUE -DOPTION_RABBITIM_USE_STATIC=ON

cmake --build . --config Release

 

Error message:

/D/msys32/mingw32/bin/g++.exe  -std=c++0x -Wno-deprecated -Wextra 
-Woverloaded-virtual -Winit-self -Wmissing-include-dirs -Wunused 
-Wno-div-by-zero -Wundef -Wpointer-arith -Wmissing-noreturn -Werror=return-type 
-std=c++0x -Wunused-but-set-variable -Wlogical-op -Wsizeof-pointer-memaccess 
-Wreorder -Wformat -Wformat-security -fpermissive -O3 -DNDEBUG   -static 
-Wl,-subsystem,windows -mwindows -Wl,--whole-archive 
CMakeFiles/RabbitIm.dir/objects.a -Wl,--no-whole-archive  -o RabbitIm.exe 
-Wl,--major-image-version,0,--minor-image-version,0  
-L/D/source/rabbitim/ThirdLibary/windows_mingw_static/lib  -lqxmpp -lavcodec 
-lavicap32 -lgdi32 -lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi 
-lws2_32 -liconv -lx264 -lpthread -lm -llzma -lbz2 -lz -lpsapi -ladvapi32 
-lshell32 -lswresample -lm -lavutil -lm -lavformat -lavicap32 -lgdi32 -lpsapi 
-lole32 -lstrmiids -luuid -loleaut32 -lshlwapi -lws2_32 -liconv -lx264 
-lpthread -lm -llzma -lbz2 -lz -lpsapi -ladvapi32 -lshell32 -lavcodec 
-lavicap32 -lgdi32 -lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi 
-lws2_32 -liconv -lx264 -lpthread -lm -llzma -lbz2 -lz -lpsapi -ladvapi32 
-lshell32 -lswresample -lm -lavutil -lm -lavutil -lm -lswscale -lm -lavutil -lm 
-lvpx -lm -lcurl -lcurl -lssh2 -lssl -lcrypto -lssl -lcrypto -lwldap32 -lz 
-lws2_32 -lgdi32 -lssl -lws2_32 -lgdi32 -lcrypt32 -lcrypto -lws2_32 -lgdi32 
-lcrypt32 ../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Gui.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Widgets.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Network.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Xml.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Multimedia.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Positioning.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5QuickWidgets.a -lavcodec 
-lavicap32 -lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi -liconv 
-lx264 -lpthread -lm -llzma -lbz2 -lz -ladvapi32 -lshell32 -lswresample 
-lavutil -lavformat -lswscale -lvpx -lcurl -lssh2 -lssl -lwldap32 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Widgets.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Quick.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Gui.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Qml.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Network.a 
../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a 
../ThirdLibary/windows_mingw_static/qt/lib/libqtmain.a -lkernel32 -luser32 
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qregularexpression.o):qregularexpression.cpp:(.text+0x261):
 undefined reference to `pcre16_exec'

../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qregularexpression.o):qregularexpression.cpp:(.text+0x2c6):
 undefined reference to 

Re: [Development] Question about the QDataBuffer from src/gui/painting

[Gunnar Sletta]

> 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 purpose as a resize/clear/append would cause a lot of
>> reallocations for the places where QDataBuffer is used. 
> 
> QDataBuffer uses realloc(), which of course std::vector cannot. With a 
> geometric growth strategy, this doesn't matter much, and most types held in 
> QDataBuffer are PODs (maybe not in C++98, but in C++11), but if it turns out 
> that it does matter, then fixing QVector to not shed excess capacity at the 
> first opportunity would be the right thing to do.

I can't remember why we used realloc. This class was written as part of the 
paint system in 4.0, so it is a long time ago. I agree that it doesn't look 
like it is needed.

> That said, neither QVector nor std::vector will match the performance of 
> QDataBuffer, which declines to care about such basic things as copying and 
> safe 
> appends from an already-existing element or Ts which aren't Q_PRIMITIVE_TYPE 
> (it should assert that, btw).

True, it was never intended to be generic copyable container, just a managed 
memory pool to help with reallocations. 

> But either (QVector w/fixed capacity management or std::vector) should be 
> fast 
> enough. Surely, the ported code will be faster, because stuff like calling 
> points() over and over in QPathSegments::mergePoints() will be found and 
> fixed.

I don't think changing QVector is the right thing. That is bound to have side 
effects elsewhere, so I don't like that. std::vector wasn't an option back when 
the class was written, but it that was a long time ago. Looks more sensible now.

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, after all. 


> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about the QDataBuffer from src/gui/painting

[Marc Mutz]

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, after all. 

Yes, QVarLengthArray would be preferable in many cases.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5 for INTEGRITY RTOS

[Rolland Dudemaine via Development]

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 any HID device
- static linking

What does not yet work but is planned:
- QtQuick (requires OpenGL)
- OpenGL ES (for Mesa, Vivante, SGX)

I will soon push some changes to Gerrit, targeting dev branch for now.

Feel free to contact me if you have any interest in this.

-- 
--
Rolland Dudemaine   tel direct:+33 143 143 702
Green Hills Software   tel:+33 143 143 700
4 rue de la Pierre Levee   mailto:rolland (AT) ghs.com
75011 Parisfax:+33 143 143 707
France  http://www.ghs.com
--


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] 答复: Qt static compiler error

[kl222 via Development]

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
[mailto:development-boun...@qt-project.org] 代表 Thiago Macieira
发送时间: 2015年10月26日 23:32
收件人: inter...@qt-project.org
抄送: development@qt-project.org
主题: Re: [Development] Qt static compiler error

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.

> ../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qregularexpres
> sion.o
> ):qregularexpression.cpp:(.text+0x261): undefined reference to
`pcre16_exec'

> ../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qeventdispatch
> er_win
> .o):qeventdispatcher_win.cpp:(.text+0x8db): undefined reference to 
> `_imp__WSAAsyncSelect@16'

If you're doing a static link, you need to link to the indirect
dependencies. 
The full library list is in the .prl and .pc files for each library. Looks
like cmake doesn't automatically add that...

This doesn't look like a Qt bug, so please drop the
development@qt-project.org mailing list when replying. This is a normal user
error.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 答复: Qt static compiler error

[Thiago Macieira via Development]

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 isn't forgotten.

> 2. No bug for qt. How to use .prl and .pc in cmake or pro file?

In the .pro file, the .prl file is used automatically. You don't have to do 
anything. You won't see this problem with qmake.

Your problem is exclusive to cmake because the information is missing from our 
generated files. Matthew says there's a place to save them, but he doesn't 
know how Qt's buildsystem generates such files.

That's done in mkspecs/features/create_cmake.prf in qtbase using 
mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in as a template. If anyone 
can figure out how to save LIBS and LIBS_PRIVATE in the cmake file, that 
should fix the problem.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] DST breakage in qtbase

[Dmitry Shachnev]

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Overview of tools used in new CI system?

[Edward Sutton]

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 releases.  Did you 
replace Jenkins with improved home-grown or other tools?

Thanks in advance,

-Ed

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt static compiler error

[Thiago Macieira]

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.

> ../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qregularexpression.o
> ):qregularexpression.cpp:(.text+0x261): undefined reference to `pcre16_exec'

> ../ThirdLibary/windows_mingw_static/qt/lib/libQt5Core.a(qeventdispatcher_win
> .o):qeventdispatcher_win.cpp:(.text+0x8db): undefined reference to
> `_imp__WSAAsyncSelect@16'

If you're doing a static link, you need to link to the indirect dependencies. 
The full library list is in the .prl and .pc files for each library. Looks 
like cmake doesn't automatically add that...

This doesn't look like a Qt bug, so please drop the development@qt-project.org 
mailing list when replying. This is a normal user error.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] DST breakage in qtbase

[Tim Zenor]

-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 works. Cf. e.g.
>  
https://codereview.qt-project.org/138771

Exactly, it works now for me
too.

--
Dmitry Shachnev
 
___
Development mailing
list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development