<div dir="ltr"><div><div><div><div><div><div><div>I spent a good amount of time working through the Windows problem today, and I think it might actually be a bug with Qt on Windows. I've also figured out a work-around.<br><br></div>Here is the problem. It has to do with operator<<(QDataStream &out, const QByteArray &ba).<br><br><a href="https://code.woboq.org/qt5/qtbase/src/corelib/tools/qbytearray.cpp.html#_ZlsR11QDataStreamRK10QByteArray">https://code.woboq.org/qt5/qtbase/src/corelib/tools/qbytearray.cpp.html#_ZlsR11QDataStreamRK10QByteArray</a><br></div></div></div><br><a href="https://github.com/OpenChemistry/molequeue/blob/master/molequeue/servercore/localsocketconnection.cpp#L153">https://github.com/OpenChemistry/molequeue/blob/master/molequeue/servercore/localsocketconnection.cpp#L153</a><br><br></div>It is supposed to work with QLocalSocket by creating a packet where the first few bytes are a quint32 (which represents the size) and the rest of the bytes are the actual data, and then send this packet. On Linux and Mac this seems to work just fine. But on Windows, it creates two packets: the first packet is the quint32 size and the second packet is the data. I don't think it is supposed to create two packets, because the reading operator on the other end of the communication (operator>>(QDataStream &in, QByteArray &ba)) assumes it is one packet and fails to read it correctly.<br><br></div>My current work-around is to avoid using operator<<(QDataStream &out, const QByteArray &ba) to send that data via two packets by creating the single packet myself and sending it manually. It is done like so:<br><br></div>  // the Json file we are wanting to send is the QByteArray, jsonData<br><div><br>  QByteArray byteArray;<br>  QDataStream tmpStream(&byteArray, QIODevice::WriteOnly);<br>  tmpStream << jsonData;<br>  socketDataStream.writeRawData(byteArray, byteArray.size());<br><div><br></div><div>This still uses operator<<(QDataStream &out, const QByteArray &ba), but it only uses it to write to byteArray (instead of writing it directly to the socket). We then write to the socket manually by using writeRawData().<br><br></div><div>This worked perfectly for me, and the messages are received just as they should be. I'll document this in my how-to markdown file I write.<br><br></div><div>The return messages in the RPC server have the same problem. Perhaps I should implement my work-around in them so that Windows clients can receive correct messages back (instead of the two-packet problem).<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 11:06 PM, Patrick Avery <span dir="ltr"><<a href="mailto:psavery@buffalo.edu" target="_blank">psavery@buffalo.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Actually, for Windows, it looks like it might be working - partly at least. The same code I wrote for communicating through the RPC on Mac and Linux kind of works. As in, it seems that some messages get through, but not all. I might need to play around with it some and see if I can get the communication working consistently. <br><br>I used the program "pipelist" to check if the avogadro server is being created, and it looks like it indeed is. I haven't tried compiling Avogadro2 on Windows myself yet, though.<br><br></div><div>For Mac, however, my own compiled Avogadro2 generates the server correctly, but the mac binary on the website does not. I have been able to check it multiple ways - including seeing if my program can communicate with the server. When the server gets created, it is placed in $TMPDIR. So if I type "ls $TMPDIR/avogadro", I can check to see if it exists. When I am running the binary from the website, this is what happens:<br></div><div><br><div dir="ltr"><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">Mac-mini:~ patrick$ ls $TMPDIR/avogadro</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">ls: /var/folders/90/6dyftwnx3jz5q4<wbr>qwr79yb9f00000gp/T//avogadro: No such file or directory</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></p></div></div>But when I am running the binary that I compiled:<br><br><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">Mac-mini:prefix patrick$ ls $TMPDIR/avogadro</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">
</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,189,38)"><span style="font-variant-ligatures:no-common-ligatures"><b>/var/folders/90/6dyftwnx3jz5q4<wbr>qwr79yb9f00000gp/T//avogadro</b></span></p></div><div><br></div>it's there. So I'm not sure why the binary on the website isn't producing it, then.<br><br></div>Anyways, I'm going to keep looking at the Windows one for now. And I'll work on making some markdown documentation soon as well - since I know how to do it for sure on Linux at least.<br><br></div>Thanks,<br></div>Patrick<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 7:41 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, May 25, 2017 at 7:22 PM, Patrick Avery <span dir="ltr"><<a href="mailto:psavery@buffalo.edu" target="_blank">psavery@buffalo.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><br></div>I was able to meet (in person) and speak with Geoff yesterday. I think we are both on the same page that we'd like to see the RPC features in Avogadro2 be available in the binaries (and perhaps some documentation so that other programmers can more easily use it as well).<br></div></div></div></div></div></blockquote><div><br></div></span><div>Patrick, that sounds good. There was never an intentional removal of the RPC procedure from the binaries, and I have been on this page for quite a few years already ;-) </div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>It is attractive because it would allow programmers working on any kind of molecular code to use Avogadro2 for the rendering of their molecules/crystals without having to link with Avogadro2 during compilation. It also allows for the rendering to be easily optional for users (if the user wants to render molecules with that program, they can download and start up Avogadro2; and if they don't want to render molecules, they don't have to do anything). I think this would certainly increase the number of people who use Avogadro2.<br></div></div></div></div></blockquote><div><br></div></span><div>Agreed, that is why I wanted to add some RPC capabilities, and think that it is an important feature. This is why we worked on the RPC stuff, and I have some ideas of doing this from a Python-based project. </div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>I'm willing to help clean it up and write some documentation for it. So I was just wondering: what kinds of changes (if any) do you think need to be made to get the RPC features as a part of the released binaries? And where would the documentation go? I could write a "how to get your program to render molecules with Avogadro2 RPC".<br><br></div></div></div></blockquote></span><div>There isn't a great deal I am aware of, we could add an option to disable the feature at runtime, but I think it is reasonable to enable it by default. I will make sure the new binaries have the feature enabled (and am not certain why this wasn't enabled last time). The local sockets mean that only the local user can remote control Avogadro 2.</div><div><br></div><div>In the first instance for documentation you could add a markdown file, or put something  on the wiki. I have always hated the assumption that you must link to C++ to use it, and would like to promote more local services like this. Did you confirm this was not working on Windows and macOS? Windows has always been a little finicky as it uses a different API than macOS and Linux, but these are based on QLocalSocket.</div><div><br></div><div>Hope that helps, and like I said more than happy to ensure the next release features the RPC server, it reuses what was build for MoleQueue, so I will see if I can find any issues in that.</div><span class="m_-4627718747629769605HOEnZb"><font color="#888888"><div><br></div><div>Marcus</div></font></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>