On 2017-03-30 14:00-0700 Alan W. Irwin wrote:
> [] The
> commit [25d120e] message indicates the comprehensive test script options that
> should be used to do the requested testing [of wxwidgets].
P.S.
Those options included -DPLPLOT_WX_DEBUG_OUTPUT=ON
-DPLPLOT_WX_NANOSEC=ON. The first of th
The new three named semaphores approach to wxwidgets IPC that I
implemented should "just work" on all platforms. The reason why I
claim that is the method works on Linux and POSIX named semaphores are
widely supported on all POSIX platforms (so should work on all free
Unix platforms and Mac OS X an
On 2017-03-09 23:07-0800 Alan W. Irwin wrote:
[...]
> In sum, I believe we need to make the two improvements above (solve
> the wxPLViewer order of magnitude inefficiency issue and display
> wxPLViewer plots immediately for each part of plbuf that is received)
> before we can get believable timing
To Phil and Pedro:
On 2017-03-09 23:07-0800 Alan W. Irwin wrote:
[...]
> Unnamed POSIX semaphores are known not to work on Mac OS X (and likely
> a number of other proprietary Unices) and Windows. Thus, for the
> -DPL_WXWIDGETS_IPC3=ON case I plan to implement a CMake test that will
> determine
To Phil and Pedro:
I have now (commit 096527c) implemented named semaphores variants (both
POSIX and Windows) of the 3-semaphore approach that was previously
only implemented for POSIX unnamed semaphores. This should complete
my planned wxwidgets work (except for the test of unnamed semaphores
ca
On 2017-02-28 12:19-0800 Alan W. Irwin wrote:
> On 2017-02-27 15:34-0800 Alan W. Irwin wrote:
[...]
> My remaining plans for the -DPL_WXWIDGETS_IPC2=ON case are as follows:
>
> 1. Implement interactivity so that C example 1 works with -locate mode
> and C example 20 works.
>
> 2. Named semaphore v
Hi Phil:
I have now had more of a chance to read your e-mail so I
have some more detailed responses to it below.
On 2017-03-03 16:02- Phil Rosenberg wrote:
[...]
> So a couple of things spring to mind. Firstly you must at some point
> renter the event loop to allow the viewer to start doing
On 2017-03-03 16:02- Phil Rosenberg wrote:
> Hi Alan
> Sorry for not replying sooner. I was waiting until I had time to
> actually read the code, which unfortunately I haven't had chance to do
> still, but I didn't want to leave it any longer without at least
> guessing what might be happening
On 2017-02-28 12:19-0800 Alan W. Irwin wrote:
My remaining plans for the -DPL_WXWIDGETS_IPC2=ON case are as follows:
1. Implement interactivity so that C example 1 works with -locate mode
and C example 20 works.
Hi Phil:
I am having trouble with implementing interactivity and could use some
On 2017-02-27 15:34-0800 Alan W. Irwin wrote:
> The current status is all examples work (i.e., there are no obvious
> run-time errors and there are no rendering issues other than
> previously known ones for the -DPL_WXWIDGETS_IPC2=OFF case) other than
> 02 and 14 (where an exception is consistentl
On 2017-02-26 22:51-0800 Alan W. Irwin wrote:
[]
> Therefore, I plan to turn the current two-semaphore approach into a
> three semaphore approach where m_wsem and m_rsem will continue to be
> used for the details of a complete transfer of an array of bytes, but
> an additional m_tsem semaphore
it's just not good practice.
Phil
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 27 February 2017 06:51
To: p.d.rosenb...@gmail.com
Cc: PLplot development list
Subject: Re: [Plplot-devel] The status of the wxwidgets IPC development
On 2017-02-25 17:44-0800 Alan W. Irwin wrote:
&g
On 2017-02-25 17:44-0800 Alan W. Irwin wrote:
> However, I certainly agree mutual use of the same resource (shared
> memory) is a tricky world. And now that you have encouraged me to
> think about races, I discovered there is indeed a race condition that
> could explain this bug. I have now work
On 2017-02-25 12:12- p.d.rosenb...@gmail.com wrote:
>
>
>> But that failure (one or both semaphores are not blocked with zero
>> values) should be impossible because the fact is both semaphores are
>> initialized in that expected (blocked) state (that check succeeded for
>> the initial call to
>But that failure (one or both semaphores are not blocked with zero
>values) should be impossible because the fact is both semaphores are
>initialized in that expected (blocked) state (that check succeeded for
>the initial call to moveBytesReaderReversed on the wxPLViewer side),
>and at the end o
On 2017-02-24 21:32-0800 Alan W. Irwin wrote:
> In sum, the -DPL_WXWIDGETS_IPC2=ON has been largely matured with the
> only [3 issues left].
Hi Phil:
The corollary to this maturation which I forgot to mention is all
remaining changes to the -DPL_WXWIDGETS_IPC2=ON code should be small.
So I than
On 2017-02-24 00:19-0800 Alan W. Irwin wrote:
> I am currently trying to track down a bug (uncaught exception on the
> wxPLViewer side) that shows up whenever there is an attempt to plot
> multiple pages. I tried to copy the code stanzas from the old
> wxplframe.cpp code to the #ifdef PL_WXWIDGET
Hi Phil:
At long last I have some preliminary code (commit 635df69) for you to
look at that produces (for -DPL_WXWIDGETS_IPC2=ON) good results for
one-page plots such as x00c, x01c, and x24c, but which currently has a
bug for multipage plots which I am trying to understand.
Sorry this took so lon
Hi Phil:
I am still progressing at a steady pace with this wxwidgets IPC
development effort. There are no additional commits to share with you
at this time (but coming soon!), and I appreciate that you haven't
caused me any conflict resolution issues as I work on what previously
had been largely y
Hi Phil:
I have found a bug in the "catch(char *)" commands used in
drivers/wxwidgets.cpp. I have discovered this bug from my attempts to
use throw("some message") style exceptions in my (currently unpushed)
-DPL_WXWIDGETS_IPC2=ON version of wxPLDevice::TransmitBuffer. Those
catches did not work
On 2017-02-13 20:24- p.d.rosenb...@gmail.com wrote:
> I have absolutely no efficiency concerns. The cpu cycles will be
totally negligible compared to the time to copy the memory. To be
honest I rarely stress about efficiency. Premature optimisation is
usually a bad thing – don't forget that th
good intro to good C++ style.
Phil
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 13 February 2017 19:05
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] The status of the wxwidgets IPC development
On 2017-02-12 22:51-0800 Alan W. Irwin wrote:
> I plan to
On 2017-02-12 22:51-0800 Alan W. Irwin wrote:
> 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 effic
On 2017-02-12 23:08- 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 wit
24 matches
Mail list logo
