[Plplot-devel] The status of the wxwidgets IPC development

[Alan W. I. <ir...@be...>]

On 2017-02-12 23:08-0000 Phil Rosenberg wrote:

> Hi Alan
>
> The short answer is yes use a transmit and receive function to send
> the data, but no don't create a new object every time you want to
> send something. The current private object is definitely the way to
> go.

OK.

I plan to stick with my local instance approach for now (automatically
constructing a PLTwoSemaphore instance and destroying it again for
each call to my transmitBytes and receiveBytes methods), but move to
the private object approach for efficiency later on once I understand
(hopefully with some further help from you) exactly what it does at
run time compared with the local instance approach.

> I should have used a transmit and receive function in the current
> code. If I wasn't going to trample your uncommitted changes I would
> actually do that right now. The reason is partitioning of
> functionality. The job of the Memory map, as it stands is to provide a
> space in memory where the wxDevice can write data. You are absolutely
> correct that it would be much better to have a send and receive method

Yes, that was my exact motivation.

[...]
> However, if you pull out the semaphores and have wxPLDevice look after
> those then we have messed up our nice separation of functionality
> again. Our wxPLDevice now knows that we are communicating with
> semaphores and memory maps.

> So what I should have done (and this probably came from the way things
> evolved and got more complicated than I expected) is created a
> PLCommunicator class. Then I could have inherited from this to make a
> PLMemoryMapCommunicator and all the code from wxDevice::Transmit,
> should go in there. In fact if you can give me some time to do that
> without stepping on your uncommitted edits then I will as I think it
> will make your life easier.

Actually, I am right in the middle of modifying
wxPLDevice::TransmitBuffer and wxPlFrame::ReadTransmission to use the
transmitBytes and receiveBytes methods of PLMemoryMap (which are now
completely implemented and they build, but I haven't pushed that
commit because I have no way of testing those methods until the
modifications to wxPLDevice::TransmitBuffer and
wxPlFrame::ReadTransmission are done).  So I have invested
considerable time in understanding those routines as they are now
organized.  Also, my ongoing changes for the -DPL_WXWIDGETS_IPC2=ON
case clearly separate assembling the data in
wxPLDevice::TransmitBuffer and acting on it in
wxPlFrame::ReadTransmission from the task of transmitting the
assembled array of bytes from wxPLDevice::TransmitBuffer and receiving
that same array of bytes in wxPlFrame::ReadTransmission.  So my
separation work (already mostly completed now) should give you a good
start on that desired reorganization.  So please hold off until later
to reorganize the code.

To summarize, here are the next steps I plan to do.

(1) Get the two-semaphores approach fundamentally working one
way from -dev wxwidgets to wxPLViewer by ignoring interactive examples
and temporarily dropping text size feedback from wxPLViewer back to
-dev wxwidgets and ultimately the PLplot core.

(2) Refine that approach to make it two-way so that the
-DPL_WXWIDGETS_IPC2=ON result passes all tests (including text size
feedback as well as including example 1 with the -locate option) that
are currently passed by the -DPL_WXWIDGETS_IPC2=OFF case.

(3) Measure the efficiency of that local instance method and then try
the private object method (once I understand exactly what it does at
run-time) to see how much that efficiency improves.

(4) Decide (with you) based on the simplicity and speed of the
two-semaphores approach compared with the one-semaphore approach which
approach we will take after that.

(5) If the decision is for two semaphores, then the further steps I
have in mind would be to (i) (Alan) implement a _named_ two-semaphores
variation on the unnamed two-semaphores approach, (ii) (Phil)
implement a named two-semaphores approach for the Windows case, and
(iii) (Alan or Phil) completely remove all one-semaphore code.  But if
our decision goes against the two-semaphores approach, then (i') (Alan
or Phil) strip all the two-semaphores code out instead but (ii')
(Phil) keep the idea of separating the transmitBytes and receiveBytes
methods (which have no logic other than to transmit and receive arrays
of bytes) from everything else.

It is not at all clear how long these steps are going to take, but I am
hoping for a time scale of something like one day each for (1) through
(3).  And I hope you don't mind holding off any of the changes you are
thinking about (especially the reorganizing ones) since such changes
would slow me down, and we, in any case, really have no idea where we
are going with the wxwidgets IPC until (4) is done.

More later as I continue to make progress on (1) through (3).

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
__________________________