Alan I have made a quick couple of changes that makes locate work correctly again with wxWidgets by simply halting checking for new data while doing a locate, then starting again when locate is complete.
However I don't want to commit anything that may clash with any changes that you are making. Let me know if you have started making any changes in wxplframe in the wxPLViewer and if so I'll just send you a patch to avoid any clashes. I had a quick skim through the 3sem code, but you might be the best person to add a timeout to that code. Phil On 2 October 2017 at 21:22, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > Hi Alan > I literally just logged onto my email to say stop whatever you are > doing on this the locate mode is broken!!! :-D > > I think there may be a couple of different issues here. One is that > the viewer is checking for more data being sent and the core code is > waiting for the location information so we have a form of deadlock. > The receiveBytes functions needs a timeout otherwise it will hang the > viewer if there is a problem at the other end. Also with the 3sem > method it probably makes no sense to keep checking for data once we > have received a locate request. This is set by the m_locateMode > variable. > > I also noticed that you have #ifdefed out the keypress code. Please > don't remove this as it will need reinstating with the new method. > > Phil > > On 2 October 2017 at 19:29, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >> On 2017-10-02 08:02+0100 p.d.rosenb...@gmail.com wrote: >> >>> Hi Alan >> >> >>> I haven't really en through that code, but yes I have been using t >> >> and yes I'm happy for that cleanup to occur. The joy of git is that >> the code history is still here if needed. >> >>> So yes, feel free to clean up as you wish. >> >> >> Well, I did one last check, and it turns out I got ahead of myself in >> making this request, but I do appreciate the keeness you share with me >> to get this code cleaned up as soon as warranted. But that time has >> not (quite) arrived yet. >> >> The issue I spotted that currently (for the current HEAD of master) >> has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF >> is -locate mode for example 1. >> >> If you run >> >> examples/c/x01c -dev wxwidgets -locate >> >> on Linux you get a blank screen with both the above configurations >> which is a bug for both configurations. But now that I have looked >> further, if you click blindly on the location of one of the 4 >> subpages, you get some cursor position information printed to stdout >> for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is >> actually displayed for that case. In contrast for >> -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a >> cursor position I know is in the right place, and therefore the >> code is apparently in an infinite loop which never displays >> anything other than a blank screen. >> >> Could you take a look at the above screen display issue, and also at >> why there is no response to mouse clicks in locate mode for just the >> -DPL_WXWIDGETS_IPC3=ON case? >> >> To familiarize yourself with how locate mode should work for this >> example, you should try other interactive devices as well. For example, >> >> examples/c/x01c -dev wingcc -locate >> >> and/or >> >> examples/c/x01c -dev wingdi -locate >> >> should give good locate mode results (which is that if the mouse [or >> some keyboard key if the driver supports keyboard clicking] is >> clicked when the cursor corresponds to one of the 4 viewports, the >> cursor position and other information is dumped to stdout; and if the >> mouse [or keyboard key] is clicked when the cursor corresponds to a location >> outside one >> of the 4 viewports, locate mode terminates, and then hitting the enter >> key will terminate the example.) I just checked, and the >> old wxwidgets device you can still get access to using >> -DOLD_WXWIDGETS=ON still builds and >> >> examples/c/x01c -dev wxwidgets -locate >> >> gives the good locate mode results (both with mouse clicks and >> keyboard key clicks) described above. >> >> [out of order]: >>> >>> One question i did have though – I remember my code being set up >> >> like a ring buffer, and you saying yours wasn't. But I presume it can >> still cope with large transfers bigger than the shared memory block? >> >> Yes, transferring large blocks of bytes in either direction is what >> two of the three semaphores control. This works without any timed >> waits at all. (The other semaphore controls use of the entire >> transfer method similar to your mutex). My speed tests showed that >> method of transferring bytes stopped being significantly dependent on >> shared memory buffer size as soon as that shared memory size (+ a >> small overhead) was 1KB or greater. So to be absolutely safe >> concerning efficiency I set it to 10KB (+ a small overhead). See the >> note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h. >> That value is significantly smaller than the ring buffer size which is >> set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when >> PL_WXWIDGETS_IPC3 is not #defined. >> >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
