It looks like PyOpenCL obsoleted the enqueue_read_buffer method, and
enqueue_copy should be used instead. Even though enqueue_copy already exists
with the earliest version of PyOpenCL I looked at, I wrote it in a
backwards-compatible way so that it doesn't break in case I missed something.
Tested on OSX in frozen mode, but it should be platform-independent.
- fix requesting the same object over and over again, now it continues to
iterate through the other objects and only resets the queue after a timeout
after the last received object
- a bug in RandomTrackingDict caused requesting to download the same objects
over and over
- the bug is that the lastObject wasn't properly initalised, this caused the
write buffer to fill with "getdata" requests until the first object was
received
- this PR should address both the excessive bandwidth as well as excessive CPU
usage during downloading
- instead of being processed in the ReceiveQueue thread, uploads are now done
in a dedicated thread. Only the parsing is done in ReceiveQueue thread.
- the UploadThread is modelled based on the DownloadThred, but simpler.
- it checks for intersection attack, eliminates duplicates and restricts the
write buffer size to 2MB (may still grow slightly higher if too many big
objects are requested, but the absolute limit appears to be about 4.5MB in the
worst case scenario).
- the restriction of the write buffer may cause some upload throttling (to
about 2MB per second per connection), but can be optimised later
- fixes#1414
* separate method MyForm.resetNamecoinConnection() - sets MyForm.namecoin
to fresh instance of namecoin.namecoinConnection, tests it and shows or
hides "Fetch Namecoin ID" button;
* that method is called when MyForm initializes and when settingsDialog
instance is accepted;
* namecoin.namecoinConnection.query() checks found address and always
prepends it with display name, if query result doesn't contain "name"
field it will be the query string.
Due to the way Qt.KeyboardModifiers works, treating it as an integer results in
unexpected behaviour. As a result, When deleting from Sent, it always deleted
rather than moved an item to trash, when selecting "Move to Trash" from the
context menu. This fixes it.