[Interest] Q(Tcp/Udp)Socket stall
Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtSql database insertion issues...
Karl, don't worry. the SQL module is not going anywhere. Jason is right in the sense that it's considered done. He's wrong in thinking this has anything to do with NoSQL. NoSQL isn't emerging as a the SQL killer that NoSQL guys believe it is. Instead it's a different tool that has other use patterns. On 04/23/2015 04:45 PM, Karl Ruetz wrote: I sincerely hope you are wrong; at least for the next several years. (Like 10 years.) Staying on the bleeding edge is simply not an option for many of us that are simply Qt users (not developers). It took us years to update to Qt 5 because they killed QFTP without a fully functional replacement. QNAM does not have all the functionality for FTP that QFTP did and building QFTP with the newest versions of Qt is problematic at best. Killing the SQL module would probably mean the end of Qt for our organization. I realize that cutting edge stuff is more fun. But we live in a world where our customers keep old equipment around for decades and they are willing to pay to keep it running. So we still have to support Windows NT 4 and RHEL 4 even though it’s not as fun as working with the latest and greatest. So please, I beg of you, do not remove any functionality without a complete, viable, fully functional replacement. Karl On Apr 23, 2015, at 9:35 AM, Jason H jh...@gmx.com mailto:jh...@gmx.com wrote: Very true. If you need something like that to be agnostic, then you need to use a query builder or ORM. But it's not like Qt is very agnostic. Pragmatically speaking, the lack of constistent binding across of drivers kills it right out of the gate. In days like this, where NoSQL is an emerging trend I can't see anything really happening at the SQL module anymore. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
Are you on Wifi (only)? We did run into similar issues on 5.3.2 (but I don't know whether this is related to your problem, too): The reason for our problem was/is, that ... ...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi engine every 10 seconds for available networks. This in turn will call Windows’ WlanScan function which “… requests a scan for available networks on the indicated interface…” (see qnativewifiengine::requestUpdate, line 517) Could be right, could be wrong - but this is what I've seen. Thanks, Andre -Original Message- From: interest-bounces+andre.barth=autodesk@qt-project.org [mailto:interest-bounces+andre.barth=autodesk@qt-project.org] On Behalf Of Nuno Santos Sent: Friday, April 24, 2015 1:01 PM To: Interests Qt Subject: [Interest] Q(Tcp/Udp)Socket stall Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
This happens, even with Wifi turned off. Nuno On 24 Apr 2015, at 12:18, Andre Barth andre.ba...@autodesk.com wrote: Are you on Wifi (only)? We did run into similar issues on 5.3.2 (but I don't know whether this is related to your problem, too): The reason for our problem was/is, that ... ...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi engine every 10 seconds for available networks. This in turn will call Windows’ WlanScan function which “… requests a scan for available networks on the indicated interface…” (see qnativewifiengine::requestUpdate, line 517) Could be right, could be wrong - but this is what I've seen. Thanks, Andre -Original Message- From: interest-bounces+andre.barth=autodesk@qt-project.org [mailto:interest-bounces+andre.barth=autodesk@qt-project.org] On Behalf Of Nuno Santos Sent: Friday, April 24, 2015 1:01 PM To: Interests Qt Subject: [Interest] Q(Tcp/Udp)Socket stall Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
We had the same problem. setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem Von: interest-bounces+michael.klank=amk-antriebe...@qt-project.org [mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org] Im Auftrag von Nuno Santos Gesendet: Freitag, 24. April 2015 13:24 An: Andre Barth Cc: Interests Qt Betreff: Re: [Interest] Q(Tcp/Udp)Socket stall This happens, even with Wifi turned off. Nuno On 24 Apr 2015, at 12:18, Andre Barth andre.ba...@autodesk.com wrote: Are you on Wifi (only)? We did run into similar issues on 5.3.2 (but I don't know whether this is related to your problem, too): The reason for our problem was/is, that ... ...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi engine every 10 seconds for available networks. This in turn will call Windows’ WlanScan function which “… requests a scan for available networks on the indicated interface…” (see qnativewifiengine::requestUpdate, line 517) Could be right, could be wrong - but this is what I've seen. Thanks, Andre -Original Message- From: interest-bounces+andre.barth=autodesk@qt-project.org [mailto:interest-bounces+andre.barth=autodesk@qt-project.org] On Behalf Of Nuno Santos Sent: Friday, April 24, 2015 1:01 PM To: Interests Qt Subject: [Interest] Q(Tcp/Udp)Socket stall Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest Persönlich haftende Gesellschafterin: AMK Verwaltungsgesellschaft mbH, Kirchheim/Teck Geschäftsführer: Dr. Thomas Lützenrath, Jochen Breßmer, Dr. Ulrich Viethen Registergericht Stuttgart HRB 230208; HRA 230681 Die in dieser E-Mail enthaltenen Informationen sind vertraulich. Diese E-Mail ist ausschließlich für den Adressaten bestimmt und jeglicher Zugriff durch andere Personen ist nicht zulässig. Falls Sie nicht der beabsichtigte Empfänger sind, ist jegliche Veröffentlichung, Vervielfältigung, Verteilung und sonstige in diesem Zusammenhang stehende Handlung untersagt und unter Umständen ungesetzlich. Falls Sie diese E-Mail irrtümlich erhalten haben, leiten Sie sie bitte weiter an die folgende E-Mail-Adresse: i...@amk-antriebe.de The information in this e-mail is confidential. It is intended solely for the address and access to the e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or committed to be taken in reliance on it, is prohibited and may be unlawful. If you have received this e-mail in error please forward to this e-mail-address: i...@amk-antriebe.de ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
I have already tried that. No effect! Is there any special care when applying it? -- Nuno Santos No dia 24/04/2015, às 13:11, Klank, Michael michael.kl...@amk-antriebe.de escreveu: We had the same problem. setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem Von: interest-bounces+michael.klank=amk-antriebe...@qt-project.org [mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org] Im Auftrag von Nuno Santos Gesendet: Freitag, 24. April 2015 13:24 An: Andre Barth Cc: Interests Qt Betreff: Re: [Interest] Q(Tcp/Udp)Socket stall This happens, even with Wifi turned off. Nuno On 24 Apr 2015, at 12:18, Andre Barth andre.ba...@autodesk.com wrote: Are you on Wifi (only)? We did run into similar issues on 5.3.2 (but I don't know whether this is related to your problem, too): The reason for our problem was/is, that ... ...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi engine every 10 seconds for available networks. This in turn will call Windows’ WlanScan function which “… requests a scan for available networks on the indicated interface…” (see qnativewifiengine::requestUpdate, line 517) Could be right, could be wrong - but this is what I've seen. Thanks, Andre -Original Message- From: interest-bounces+andre.barth=autodesk@qt-project.org [mailto:interest-bounces+andre.barth=autodesk@qt-project.org] On Behalf Of Nuno Santos Sent: Friday, April 24, 2015 1:01 PM To: Interests Qt Subject: [Interest] Q(Tcp/Udp)Socket stall Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest Persönlich haftende Gesellschafterin: AMK Verwaltungsgesellschaft mbH, Kirchheim/Teck Geschäftsführer: Dr. Thomas Lützenrath, Jochen Breßmer, Dr. Ulrich Viethen Registergericht Stuttgart HRB 230208; HRA 230681 Die in dieser E-Mail enthaltenen Informationen sind vertraulich. Diese E-Mail ist ausschließlich für den Adressaten bestimmt und jeglicher Zugriff durch andere Personen ist nicht zulässig. Falls Sie nicht der beabsichtigte Empfänger sind, ist jegliche Veröffentlichung, Vervielfältigung, Verteilung und sonstige in diesem Zusammenhang stehende Handlung untersagt und unter Umständen ungesetzlich. Falls Sie diese E-Mail irrtümlich erhalten haben, leiten Sie sie bitte weiter an die folgende E-Mail-Adresse: i...@amk-antriebe.de The information in this e-mail is confidential. It is intended solely for the address and access to the e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or committed to be taken in reliance on it,
Re: [Interest] Q(Tcp/Udp)Socket stall
Hi, I have just isolated the problem. In program B i’m also using libimobiledevice to browse for attached iOS devices. The functions that establishes a callback for devices attach/detach notifying was causing the stall. I think I will need to move this object to a different thread. Nuno On 24 Apr 2015, at 15:24, Nuno Santos nunosan...@imaginando.pt wrote: Well, I was just trying to create an small example to send to the list and it didn’t show the problem. I think I have just found the problem. The B program I mentioned has Bonjour browsing service implemented by a really old Qt project BonjourServiceRegister. I have commented it out and the problem disappeared. I don’t know why, but it seems that Bonjour Service Register is provoking this stall. Can anyone guess why? Does anyone know any more recent Qt wrapper for dns_sd? Regards, Nuno Santos Founder / CEO / CTO www.imaginando.pt http://www.imaginando.pt/ +351 91 621 69 62 On 24 Apr 2015, at 13:11, Klank, Michael michael.kl...@amk-antriebe.de mailto:michael.kl...@amk-antriebe.de wrote: We had the same problem. setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem Von: interest-bounces+michael.klank=amk-antriebe...@qt-project.org mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org [mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org] Im Auftrag von Nuno Santos Gesendet: Freitag, 24. April 2015 13:24 An: Andre Barth Cc: Interests Qt Betreff: Re: [Interest] Q(Tcp/Udp)Socket stall This happens, even with Wifi turned off. Nuno On 24 Apr 2015, at 12:18, Andre Barth andre.ba...@autodesk.com mailto:andre.ba...@autodesk.com wrote: Are you on Wifi (only)? We did run into similar issues on 5.3.2 (but I don't know whether this is related to your problem, too): The reason for our problem was/is, that ... ...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi engine every 10 seconds for available networks. This in turn will call Windows’ WlanScan function which “… requests a scan for available networks on the indicated interface…” (see qnativewifiengine::requestUpdate, line 517) Could be right, could be wrong - but this is what I've seen. Thanks, Andre -Original Message- From: interest-bounces+andre.barth=autodesk@qt-project.org mailto:interest-bounces+andre.barth=autodesk@qt-project.org [mailto:interest-bounces+andre.barth=autodesk@qt-project.org mailto:interest-bounces+andre.barth=autodesk@qt-project.org] On Behalf Of Nuno Santos Sent: Friday, April 24, 2015 1:01 PM To: Interests Qt Subject: [Interest] Q(Tcp/Udp)Socket stall Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. The result is the following: latency 19 latency 60 latency 60 latency 60 latency 51 latency 59 latency 80 latency 61 latency 60 latency 58 latency 50 latency 60 latency 59 latency 538 latency 0 latency 43 latency 58 latency 62 latency 79 latency 50 latency 50 latency 61 latency 61 latency 58 latency 60 latency 80 latency 31 latency 59 latency 1946 latency 0 latency 54 latency 61 latency 49 latency 59 latency 52 latency 60 latency 58 latency 60 latency 60 latency 60 latency 60 latency 60 latency 51 latency 533 latency 0 latency 16 latency 60 latency 60 latency 60 latency 50 latency 60 latency 61 latency 60 latency 59 From time to time, in a pretty much regular way, the message receiving stalls and the latency is printed as being around 500ms/1000ms/2000ms. Even the interval between stalls is pretty much regular, around 14 packets. Each packet is 76 bytes, which multiplied by 14 gives around 1024. I didn’t rest while I couldn’t who the fault was. So I did a C program that receives data on a socket from the same source to ensure that there was no stalls or latency. The result was NO STALLS. Then, I have done another program, this time built in Qt, to send data via QUdpSocket to the program B. The result was: STALLS again! My conclusion is that somewhere in the underlying Qt socket handling, there is a buffer, to be filled before readyRead is sent. Is anybody familiar with this problem and know how to work around it? Is this a setting that can be tweaked? This doesn’t seem normal or acceptable. Thx, Regards, Nuno Santos
[Interest] QMAKE_EXTRA_TARGETS not called for iOS targets ( Works fine for OS X targets ) ?
I use QMAKE_EXTRA_TARGETS to set version info in version.h and Info.plist files
before builds using subwcrev. It works great for Android, Windows, and OS X
but not iOS. I *assume* this is because iOS builds are much different than OS
X under the hood.
Are there any tips for qmake alternative to work-around this?
# Auto-generate iOS Info-additions.plist version info
# Warning: This does not get executed when building for iOS
# Consider resorting to SED
versionIosInfoPlist.target = $${PWD}/platform/ios/Info-additions.plist
versionIosInfoPlist.commands = $$PYTHON_EXE $${PWD}/scripts/subwcrev.py $${PWD}
$${PWD}/platform/ios/Info-additions-template.plist
$${PWD}/platform/ios/Info-additions.plist
message(dbg: $$versionIosInfoPlist.commands)
versionIosInfoPlist.depends = FORCE
PRE_TARGETDEPS += $${PWD}/platform/ios/Info-additions.plist
QMAKE_EXTRA_TARGETS += versionIosInfoPlist
QMAKE_INFO_PLIST = $${PWD}/platform/ios/Info-additions.plist
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
On Friday 24 April 2015 12:01:10 Nuno Santos wrote: Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. Let's stop here. There's one too many programs in the description. Please tell us whether the problem is in program A or in program B. You need a traffic sniffer/analyser to do that. Tell us whether the packet is being sent at the correct time by program A. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] iOS Accelerometer doesn't work; sensor_explorer crashes on iOS.
On 23/04/2015 19:19, Jason H wrote:
I went to move the Android-developed accelerometer feature to iOS and it
doesn't work. I don't get any updates.
I went to use the sensor_explorer example and it crashes with some errors:
sensor_explorer.qml:46 module Explorer is not installed
Error: your root element must be a Window.
I think it
I was looking at accelbubble.pro example and noticed this:
ios {
QMAKE_INFO_PLIST = Info.plist
# manual plugin loading needed with older Qt
# QTPLUGIN += qsvg qtsensors_ios qtsensors_generic
}
accelbubble itself did not compile on iOS, but
I did a trivial QML test which just logs Accelerometer values.
If I add the line
QTPLUGIN += qtsensors_ios
to .pro it started to work!?
Is this documented somewhere? On Android the plugin is not needed in .pro.
This is with Qt 5.4.1. I wonder what the older Qt above means?
If someone could clarify this or point to documentation that would be nice.
Accelerometer documentation itself did not mention about any plugin
requirements.
Harri
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] how to caculate the qml animation frames
Hi all
I write a simple qml animation to run on platform wayland. The duration is
100ms.
First, the animation run 8 frames and animation is smooth.
Then I do a little optimization in Weston. The animation run 11 frames and
blocked. The shift is 42 when blocked.
I feel very strange. Why the frame number is different between two times? How
to calculate the frame in one animation?
Qml case:
import QtQuick 2.0
Rectangle {
id: root
width: 600
height: 600
color: blue
Rectangle {
X: 20+shift
}
Rectangle {
X: 140-shift
}
property real shift: 0
SequentialAnimation on shift {
NumberAnimation {to: 120; duration: 100; easing.type:
Easing.InOutSine }
NumberAnimation {to: 0; duration: 100; easing.type:
Easing.InOutSine }
loops: 1
}
Text {
text: shift: + shift
}
}
Best Regards
Nancy
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
You can now access the wide range of products powered by aptX at www.aptx.com
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q(Tcp/Udp)Socket stall
Thiago, Thanks for your reply. It happens that the problem was in program B because it was also using libimobiledevice. This is a C lib used to talk with iOS devices. It happens that it’s internal mechanisms were blocking the program execution and consequently the sockets data flow. I have only realized that when tried to create a standalone example to share with the list. The example I was producing didn’t had the problem I was observing. The obvious solution for this problem was to run the classes that invoked libimobiledevice calls in another thread. There is no problem anymore. Sorry if the description was not completely clear but I didn’t want to create even more confusion explaining all that was involved. Regards, Nuno On 24/04/2015, at 16:56, Thiago Macieira thiago.macie...@intel.com wrote: On Friday 24 April 2015 12:01:10 Nuno Santos wrote: Hi, I have passed the last 48 hours trying to understand a problem I was having with sockets. I was driving crazy but I think I finally reached a conclusion. Let me summarize: - Program A that sends data via sockets to localhost - Program B, built in Qt, receives data via QUdpSocket (I have also tried with QTcpSocket and the problem is the same). Program A sends constant size messages (76 bytes) each 60 ms. Program B receives the message and prints the latency between the current message and the last message. Let's stop here. There's one too many programs in the description. Please tell us whether the problem is in program A or in program B. You need a traffic sniffer/analyser to do that. Tell us whether the packet is being sent at the correct time by program A. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
