Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
He did say he's able to get rid of all file/directory accesses so that will solve that problem. Looks like your first stab got everything covered. 73 Mike W9MDB From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Tuesday, May 05, 2015 8:16 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 05/05/2015 14:06, Michael Black wrote: Hi Mike, Laurie said he doesn't see anything else he needs. Had to tell him Replay was for getting the current statuses which he didn't quite make the connection.he thought it was related to Decode again. Do you think it might be more aptly named StatusReplay and move the description in NetworkMessage.hpp to right below Status since they're related? I am surprised that there are not other bits of status info that would be helpful, I guess since Laurie has other mechanisms in place there is little direct benefit at the moment. The main thing as far as I am concerned is to get rid of the contention on the file based decodes interface which is blocking WSJT-X in its present form. I would have thought the replay is more related to decodes than status. I have keep the list of commands in numerical order which I think probably makes sense for a implementer of the protocol. I was going to revisit the documentation and note the null byte string behaviour since it isn't documented fully in the Qt QDataStream format. I will try and make everything a bit clearer. 73 Mike W9MDB 73 Bill G4WJS. From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Sunday, May 03, 2015 9:58 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 03/05/2015 15:42, Michael Black wrote: Hi Mike, Small bug.I tried to see how this was happening but couldn't quite figure it out. Seems when DXCall is empty it is initialized correctly to a 0-length string when the INI file has it as empty. This is expected behaviour. The Qt serialization format differentiates between a null QString and an empty QString as documented here: http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that both can be interpreted as empty. I am a bit surprised this is happening because we convert to a QByteArray of utf8 code points before we stream the data but looking at the Qt source reveals that QByteArray like QString sets the length to 0x for null as well. It may be because m_hisCall isn't initialized to anything from the INI file. Grid might be same problem too? As Laurie is looking at using this new interface I wonder if there is any other status content that would be valuable to him, particularly if it avoids any Windows cross process gymnastics to discover them? Mike W9MDB 73 Bill G4WJS. From: hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] Sent: Sunday, May 03, 2015 12:18 AM To: hamapps-b...@yahoogroups.com.au Subject: Re: [HamApps-Beta] UDP interface for WSJT-X control. Mike, Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data. When WSJT-X first starts without a DXCall set, the UDP status packet has the length for the DXCall set to 0x, rather than the true length which is 0x. If I enter a character and delete it, so that the DXCall is empty, the Status packet has the correct zero length set in the DXCall utf8 data. So this is only a startup problem which I have coded around, but thought you may like to pass it on as here may be other startup bogus data in the current UDP implementation. de Laurie VK3AMA -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
On 05/05/2015 14:06, Michael Black wrote: Hi Mike, Laurie said he doesn't see anything else he needs. Had to tell him Replay was for getting the current statuses which he didn't quite make the connection…he thought it was related to Decode again. Do you think it might be more aptly named StatusReplay and move the description in NetworkMessage.hpp to right below Status since they're related? I am surprised that there are not other bits of status info that would be helpful, I guess since Laurie has other mechanisms in place there is little direct benefit at the moment. The main thing as far as I am concerned is to get rid of the contention on the file based decodes interface which is blocking WSJT-X in its present form. I would have thought the replay is more related to decodes than status. I have keep the list of commands in numerical order which I think probably makes sense for a implementer of the protocol. I was going to revisit the documentation and note the null byte string behaviour since it isn't documented fully in the Qt QDataStream format. I will try and make everything a bit clearer. 73 Mike W9MDB 73 Bill G4WJS. *From:*Bill Somerville [mailto:g4...@classdesign.com] *Sent:* Sunday, May 03, 2015 9:58 AM *To:* wsjt-devel@lists.sourceforge.net *Subject:* Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 03/05/2015 15:42, Michael Black wrote: Hi Mike, Small bug…I tried to see how this was happening but couldn't quite figure it out. Seems when DXCall is empty it is initialized correctly to a 0-length string when the INI file has it as empty. This is expected behaviour. The Qt serialization format differentiates between a null QString and an empty QString as documented here: http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that both can be interpreted as empty. I am a bit surprised this is happening because we convert to a QByteArray of utf8 code points before we stream the data but looking at the Qt source reveals that QByteArray like QString sets the length to 0x for null as well. It may be because m_hisCall isn't initialized to anything from the INI file. Grid might be same problem too? As Laurie is looking at using this new interface I wonder if there is any other status content that would be valuable to him, particularly if it avoids any Windows cross process gymnastics to discover them? Mike W9MDB 73 Bill G4WJS. *From:*hamapps-b...@yahoogroups.com.au mailto:hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] *Sent:* Sunday, May 03, 2015 12:18 AM *To:* hamapps-b...@yahoogroups.com.au mailto:hamapps-b...@yahoogroups.com.au *Subject:* Re: [HamApps-Beta] UDP interface for WSJT-X control. Mike, Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data. When WSJT-X first starts without a DXCall set, the UDP status packet has the length for the DXCall set to 0x, rather than the true length which is 0x. If I enter a character and delete it, so that the DXCall is empty, the Status packet has the correct zero length set in the DXCall utf8 data. So this is only a startup problem which I have coded around, but thought you may like to pass it on as here may be other startup bogus data in the current UDP implementation. de Laurie VK3AMA -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
On 03/05/2015 15:42, Michael Black wrote: Hi Mike, Small bug…I tried to see how this was happening but couldn't quite figure it out. Seems when DXCall is empty it is initialized correctly to a 0-length string when the INI file has it as empty. This is expected behaviour. The Qt serialization format differentiates between a null QString and an empty QString as documented here: http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that both can be interpreted as empty. I am a bit surprised this is happening because we convert to a QByteArray of utf8 code points before we stream the data but looking at the Qt source reveals that QByteArray like QString sets the length to 0x for null as well. It may be because m_hisCall isn't initialized to anything from the INI file. Grid might be same problem too? As Laurie is looking at using this new interface I wonder if there is any other status content that would be valuable to him, particularly if it avoids any Windows cross process gymnastics to discover them? Mike W9MDB 73 Bill G4WJS. *From:*hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] *Sent:* Sunday, May 03, 2015 12:18 AM *To:* hamapps-b...@yahoogroups.com.au *Subject:* Re: [HamApps-Beta] UDP interface for WSJT-X control. Mike, Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data. When WSJT-X first starts without a DXCall set, the UDP status packet has the length for the DXCall set to 0x, rather than the true length which is 0x. If I enter a character and delete it, so that the DXCall is empty, the Status packet has the correct zero length set in the DXCall utf8 data. So this is only a startup problem which I have coded around, but thought you may like to pass it on as here may be other startup bogus data in the current UDP implementation. de Laurie VK3AMA __._,_.___ Posted by: Laurie, VK3AMA vk3ama.ham.a...@gmail.com mailto:vk3ama.ham.a...@gmail.com *Reply via web post https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/messages/1098;_ylc=X3oDMTJxODBtNDFkBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARtc2dJZAMxMDk4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQzMDYzMDI2NQ--?act=replymessageNum=1098 * • Reply to sender mailto:vk3ama.ham.a...@gmail.com?subject=Re%3A%20%5BHamApps-Beta%5D%20UDP%20interface%20for%20WSJT-X%20control%2E • Reply to group mailto:hamapps-b...@yahoogroups.com.au?subject=Re%3A%20%5BHamApps-Beta%5D%20UDP%20interface%20for%20WSJT-X%20control%2E • Start a new topic https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/newtopic;_ylc=X3oDMTJmMGFjMzc3BF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0MzA2MzAyNjU- • Messages in this topic https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/topics/1058;_ylc=X3oDMTM1djI3MnBoBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARtc2dJZAMxMDk4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQzMDYzMDI2NQR0cGNJZAMxMDU4 (35) *Visit Your Group https://au.groups.yahoo.com/neo/groups/HamApps-Beta/info;_ylc=X3oDMTJmMmFlajFhBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0MzA2MzAyNjU-* https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- • Privacy • Unsubscribe • Terms of Use https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- .https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- __,_._,___https://au.groups.yahoo.com/neo;_ylc=X3oDMTJlcGoxNzhsBF9TAzk3NDkwNDMxBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMDYzMDI2NQ-- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___
