Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Hi Hazen
Yes, a multiple of around 2.5.

But for my current scenario, that's the difference between a plot taking 5-10 
minutes to render Vs 15-30 minutes. So it's a big difference.

Basically the code spends nearly three quarters of its time changing the 
locale, and only a quarter of its time rendering.

But setting/getting the locale is a a file write/read, so it's wy slower 
than setting a few pixels.

Phil



Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: Hazen Babcock 
Sent: Wednesday, June 14, 2023 6:03:03 PM
To: Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 
Subject: Re: [Plplot-devel] setlocale


Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what
you wrote below I get the impression that just removing the locale calls
alone would only improve things by about 2.5x? Is that correct?

It sounds like you might have done some profiling, so you might already
have the numbers for memory churn versus the calls to the C locale
function(s)?

best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:
> Hi Hazen
> I hadn't considered what you say about libraries. Let's rule out option 1.
>
> Yes you are correct that drawing large numbers of lines would probably
> have a similar poor performance.
>
> I think the act of checking the locale would be similarly slow. I don't
> think it's memory churn that is causing slowness. I think it's because
> checking and setting the locale involves checking environment variables
> or registry entries. I'm not entirely sure though.
>
> I think if options 1 and 2 are disliked, then option 3 is probably the
> best option.
>
> I can set things up so that the local only gets set for the first
> fill/line and is reset for the last fill/line.
>
> Does that sound okay?
>
> Phil
>
>
>
> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
> ----
> *From:* Hazen Babcock 
> *Sent:* Tuesday, June 13, 2023 1:31:38 PM
> *To:* Phil Rosenberg ;
> plplot-devel@lists.sourceforge.net 
> *Subject:* Re: [Plplot-devel] setlocale
>
> Hi Phil,
>
> I don't think (1) is a good idea. It seems like this only effects
> somewhat extreme plotting situations? Some of the examples also use
> plshade() and they don't seem to be particularly slow.
>
> Alan I think was concerned that the libraries that come with a driver
> might change the locale. The cairo driver for example has a rather large
> library behind it. This library might not change the locale, but it
> would be hard to be sure, and this might change as the library changes.
>
> Also it seems that the overhead of setting and restoring the locale
> would affect any situation with a complicated plot, perhaps most easily
> created using plshades, but if you tried to dray 1M lines you might see
> something similar? So perhaps there are some optimizations that could be
> made instead? For example we could check if the locale was already "C"
> before setting it to "C" and then restoring? We could change
> saved_lc_numerical_locale to a static variable (and not free it in
> plrestore_locale) to reduce the amount of memory churn? We could add a
> compiler flag that makes plsave_set_locale() and plrestore_locale() into
> nops for those who are okay with this?
>
> best,
> -Hazen
>
> On 6/2/23 05:55, Phil Rosenberg wrote:
>> Hi Hazen, Arjen
>> Thanks for the detective work - Alan has used that feature to help me in
>> the past and I had totally forgotten about it.
>>
>> I can see Alan's intention here. In the wxWidgets driver I did similar
>> things with other properties. For example I ensure the device context
>> pen and brush are always set and reset during calls to the driver. This
>> is so that if the user draws to the device context between calls, then
>> plPlot does not cause problems for the user and visa-versa.
>>
>> Setting and resetting the brush was also an expensive operation, so to
>> avoid those calls I have added an escape for starting and stopping
>> plshade. I know that between these escapes there is no need to worry
>> about setting and restoring the state.
>>
>> I think there are a few options, from most intrusive to least intrusive.
>> 1. Undo Alan's work and make it the responsibility of the driver to
>> restore the locale. This is what wxWidgets does with device context brushes.
>> 2. Find where we think the locale might need saving and restoring and
>> only do it for these calls. I'm not sure I like this, as it makes
>> responsibility a grey area. Also I just tried 'ack locale' and 'ack
>> LC_NUMERIC in the src directory and found references only in pl

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Hi Hazen
I hadn't considered what you say about libraries. Let's rule out option 1.

Yes you are correct that drawing large numbers of lines would probably have a 
similar poor performance.

I think the act of checking the locale would be similarly slow. I don't think 
it's memory churn that is causing slowness. I think it's because checking and 
setting the locale involves checking environment variables or registry entries. 
I'm not entirely sure though.

I think if options 1 and 2 are disliked, then option 3 is probably the best 
option.

I can set things up so that the local only gets set for the first fill/line and 
is reset for the last fill/line.

Does that sound okay?

Phil



Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: Hazen Babcock 
Sent: Tuesday, June 13, 2023 1:31:38 PM
To: Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 
Subject: Re: [Plplot-devel] setlocale


Hi Phil,

I don't think (1) is a good idea. It seems like this only effects
somewhat extreme plotting situations? Some of the examples also use
plshade() and they don't seem to be particularly slow.

Alan I think was concerned that the libraries that come with a driver
might change the locale. The cairo driver for example has a rather large
library behind it. This library might not change the locale, but it
would be hard to be sure, and this might change as the library changes.

Also it seems that the overhead of setting and restoring the locale
would affect any situation with a complicated plot, perhaps most easily
created using plshades, but if you tried to dray 1M lines you might see
something similar? So perhaps there are some optimizations that could be
made instead? For example we could check if the locale was already "C"
before setting it to "C" and then restoring? We could change
saved_lc_numerical_locale to a static variable (and not free it in
plrestore_locale) to reduce the amount of memory churn? We could add a
compiler flag that makes plsave_set_locale() and plrestore_locale() into
nops for those who are okay with this?

best,
-Hazen

On 6/2/23 05:55, Phil Rosenberg wrote:
> Hi Hazen, Arjen
> Thanks for the detective work - Alan has used that feature to help me in
> the past and I had totally forgotten about it.
>
> I can see Alan's intention here. In the wxWidgets driver I did similar
> things with other properties. For example I ensure the device context
> pen and brush are always set and reset during calls to the driver. This
> is so that if the user draws to the device context between calls, then
> plPlot does not cause problems for the user and visa-versa.
>
> Setting and resetting the brush was also an expensive operation, so to
> avoid those calls I have added an escape for starting and stopping
> plshade. I know that between these escapes there is no need to worry
> about setting and restoring the state.
>
> I think there are a few options, from most intrusive to least intrusive.
> 1. Undo Alan's work and make it the responsibility of the driver to
> restore the locale. This is what wxWidgets does with device context brushes.
> 2. Find where we think the locale might need saving and restoring and
> only do it for these calls. I'm not sure I like this, as it makes
> responsibility a grey area. Also I just tried 'ack locale' and 'ack
> LC_NUMERIC in the src directory and found references only in plargs.c,
> plcore.c and plctrl.c. So I don't think any drivers do actually change
> the locale.
> 3. I can add a variable to the PLStream which records when we enter and
> leave a plshade call. This can be checked during plfill calls so that
> only direct plfill calls save and restore the locale.
>
> My preference is for 1 or 3, does anyone else have a preference or other
> thought? 3 is certainly an easier change, but I'm happy to go down
> another route if people think it will be an improvement.
>
> Just to give an idea of the overall benefits here. I'm plotting data on
> a grid with millions of points. The wxWidgets driver changes I mentioned
> above and the removal of the locale save/restore and the changes I
> mentioned a few weeks ago with buffer memory, mean that instead of
> giving up after plPlot had been rendering for a few hours, the plot is
> rendered in under 2 minutes. So that's around two orders of magnitude
> speed increase at least.
>
> Phil
> 
> *From:* Arjen Markus 
> *Sent:* Friday, June 2, 2023 7:47:08 AM
> *To:* Hazen Babcock ;
> plplot-devel@lists.sourceforge.net 
> *Subject:* Re: [Plplot-devel] setlocale
> Hi Hazen, Phil,
>
> If the setting and restoring of the locale takes so much time, then
> would it be an option to use this only on the plot functions that might
> actually be affected by th

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

ion=10383
"""

-Hazen

On 5/31/23 10:56, Phil Rosenberg wrote:
 > Sorry, I was wrong in my last email - removing the locale calls from 
 > plP_state as well (used to reset the width after a contour draw within
plshade) I ended up with a 2.5 times speed increase  >  > Phil  >  > On Mon, 29 
May 2023 at 00:38, Phil Rosenberg mailto:p.d.rosenb...@gmail.com>> wrote:
 >
 > Hi all
 > I have been making further optimisations to the wxwidgets backen, as
 > I have still been finding it painfully slow for plshade calls.
 > It turned out that almost all the time within the backend (>99%) was
 > spent selecting pens and brushes and allocating memory for every
 > fill within the plshade call. Less that 1% was actually spent within
 > the rendering call to wxWidgets. I have made some good improvements
 > here.
 >
 > However, in addition to this, about 50% of the total execution time
 > is spent in the setlocale function. This is called before and after
 > each polygon fill in the core plplot code.
 >
 > I wondered if anyone really knows the purpose of these calls?
 > Perhaps they are to ensure we have consistent numeric
 > representations across regions? If so, then I don't really
 > understand why they are needed for polygon fills.
 >
 > Any thoughts would be welcome
 > Phil
 >
 >
 >
 > _______
 > Plplot-devel mailing list
 > Plplot-devel@lists.sourceforge.net
 > https://lists.sourceforge.net/lists/listinfo/plplot-devel



On 5/31/23 10:56, Phil Rosenberg wrote:
> Sorry, I was wrong in my last email - removing the locale calls from
> plP_state as well (used to reset the width after a contour draw within
> plshade) I ended up with a 2.5 times speed increase
>
> Phil
>
> On Mon, 29 May 2023 at 00:38, Phil Rosenberg  <mailto:p.d.rosenb...@gmail.com>> wrote:
>
> Hi all
> I have been making further optimisations to the wxwidgets backen, as
> I have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was
> spent selecting pens and brushes and allocating memory for every
> fill within the plshade call. Less that 1% was actually spent within
> the rendering call to wxWidgets. I have made some good improvements
> here.
>
> However, in addition to this, about 50% of the total execution time
> is spent in the setlocale function. This is called before and after
> each polygon fill in the core plplot code.
>
> I wondered if anyone really knows the purpose of these calls?
> Perhaps they are to ensure we have consistent numeric
> representations across regions? If so, then I don't really
> understand why they are needed for polygon fills.
>
> Any thoughts would be welcome
> Phil
>
>
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://list/
> s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel=05%7C01%7Carj
> en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed
> 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb
> 7gY%3D=0



___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Sorry, I was wrong in my last email - removing the locale calls from
plP_state as well (used to reset the width after a contour draw within
plshade) I ended up with a 2.5 times speed increase

Phil

On Mon, 29 May 2023 at 00:38, Phil Rosenberg 
wrote:

> Hi all
> I have been making further optimisations to the wxwidgets backen, as I
> have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was spent
> selecting pens and brushes and allocating memory for every fill within the
> plshade call. Less that 1% was actually spent within the rendering call to
> wxWidgets. I have made some good improvements here.
>
> However, in addition to this, about 50% of the total execution time is
> spent in the setlocale function. This is called before and after each
> polygon fill in the core plplot code.
>
> I wondered if anyone really knows the purpose of these calls? Perhaps they
> are to ensure we have consistent numeric representations across regions? If
> so, then I don't really understand why they are needed for polygon fills.
>
> Any thoughts would be welcome
> Phil
>
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Just checking again if anyone has any knowledge of this?

As far as I can see, plsave_set_locale and plrestore_locale temporarily set
the LC_NUMERIC locale to "C" during calls to the driver. This sets the
decimal delimiter and the thousands separator and how many digits are
between the thousands separator.

I really can see no use at all to do this for a fill call or most of the
other calls where it is used. Do some drivers convert numbers to text
during their rendering?

I have just tested and I get a 50% speed increase for my shades calls by
removing the locale calls from grfill. This seems pretty significant.

Thanks
Phil

On Mon, 29 May 2023 at 00:38, Phil Rosenberg 
wrote:

> Hi all
> I have been making further optimisations to the wxwidgets backen, as I
> have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was spent
> selecting pens and brushes and allocating memory for every fill within the
> plshade call. Less that 1% was actually spent within the rendering call to
> wxWidgets. I have made some good improvements here.
>
> However, in addition to this, about 50% of the total execution time is
> spent in the setlocale function. This is called before and after each
> polygon fill in the core plplot code.
>
> I wondered if anyone really knows the purpose of these calls? Perhaps they
> are to ensure we have consistent numeric representations across regions? If
> so, then I don't really understand why they are needed for polygon fills.
>
> Any thoughts would be welcome
> Phil
>
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] setlocale

[Phil Rosenberg]

Hi all
I have been making further optimisations to the wxwidgets backen, as I have
still been finding it painfully slow for plshade calls.
It turned out that almost all the time within the backend (>99%) was spent
selecting pens and brushes and allocating memory for every fill within the
plshade call. Less that 1% was actually spent within the rendering call to
wxWidgets. I have made some good improvements here.

However, in addition to this, about 50% of the total execution time is
spent in the setlocale function. This is called before and after each
polygon fill in the core plplot code.

I wondered if anyone really knows the purpose of these calls? Perhaps they
are to ensure we have consistent numeric representations across regions? If
so, then I don't really understand why they are needed for polygon fills.

Any thoughts would be welcome
Phil
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] bug in notpointinpolygon

[Phil Rosenberg]

Hi all
Running example 25 highlighted another couple of issues, which I have now
fixed and I have pushed the final version.

It might be worth noting that some of the images on the web page were
suffering from a variant of this bug. If you check example 25, pages 5 and
6, the two lower plots on the right hand column have been solid filled
rather than gradient filled. This is because devices without native
gradient filling use plshades, so are succeptible to this bug. In this case
the fill is clipped within the polygon being gradient filled. Someone may
wish to update the web page now this has (hopefully) been fixed.

Thanks
Phil

On Thu, 11 May 2023 at 21:42, Phil Rosenberg 
wrote:

> I have managed to further isolate the issue and I've attached a minimum
> example. Internal integer pixel units are a factor, so it might not show up
> on all devices. This example shows up the error on my Windows machine with
> the wxWidgets device.
>
> The example draws a single rectangle using plfill, but the rectangle
> itself is well outside the range of the axes. Despite the position of the
> rectangle, the result is that the whole plot area is filled.
>
> The bug occurs when drawing polygons with a very high aspect ratio (tall
> and thin), outside the plot area in certain positions. It may even only
> happen for polygons one internal plot unit wide.
>
> As part of the plP_plfclp code, we check if each of the bottom left corner
> of the plot area is within the polygon and if no edges of the polygon
> intersect the plot area. If both these conditions are true, the polygon
> must cover the whole plot area, so we fill it all. To check if the bottom
> left corner is within the polygon, we trace a ray from that point in a
> particular direction. If the ray crosses an even number of polygon edges
> the point is external and if it crosses an odd number of edges then the
> point is internal. The crossings are checked by a function called
> notcrossed and they are accumulated over a whole polygon by a function
> called notpointinpolygon.
>
> However, there is some ambiguity due to floating point arithmetic when
> lines are close to parallel and intersections are close to vertices. Hence,
> notcrossed can return 0 (crossed) 1 (notcrossed) and a series of other
> values indicating that we are uncertain if we have crossed or not. One of
> those return values is PL_NEAR_PARALLEL(32), however, notpointinpolygon
> does not check for this and counts it as true, i.e. not crossed. In almost
> all scenarios, the return of PL_NEAR_PARALLEL for one edge, results in a
> PL_NEAR_POINT (where POINT is A1, A2, B1 or B2) return for another edge.
> This return value is picked up by notpointinpolygon and is reflected in its
> return value, so this bug almost never manifests.
>
> However, it turns out that a polygon edge with size of 1 internal unit, if
> intersected, will always generate a PL_NEAR_PARALLEL return value, even if
> the lines are close to perpendicular. this is treated as not crossed. If
> the polygon has a large aspect ratio, the ray can intersect another edge
> significantly far from its ends that it does not trigger a PL_NEAR_POINT
> return value. notpointinpolygon therefore misses one edge intersection and
> incorrectly thinks the point is in the polygon.
>
> Where this happens for the bottom left corner, and no edges cross the plot
> area we end up filling the whole box. Although it might seem like this is
> very unlikely, if you use plshades to do a contour plot  with very fine
> horizontal resolution and much coarser vertical resolution and zoom in on
> the y axis to crop some of the data out, then it turns out to be almost
> inevitable that at least one polygon will trigger the problem. In my case
> I'm plotting data from a meteorological lidar - high temporal resolution,
> coarser vertical resolution.
>
> To fix this I've written an optimised version of notcrossed, called
> notcrossedhorizontalray. This uses a horizontal ray rather than a ray to a
> point near the polygon. It uses entirely boolean logic and integer maths
> except for one division, so it should be accurate. I updated
> notpointinpolygon to use the new function and recognise the unsure case. I
> added some extra checks in plP_plfclp. I attach a patch if anyone wants to
> test it. Clearly I'm not the first person to wrestle with this code as
> there is another commented out version. In my
> code USE_FILL_INTERSECTION_POLYGON is not defined, so there is a large
> chunk of code unused. I don't know if this gets used in some builds, but
> maybe it could be cleaned up if not.
>
> If nobody objects I will commit the change to the repo
>
> Thanks
> Phil
>
> On Wed, 10 May 2023 at 10:38, Phil Rosenberg 
> wrote:
>
>> Hi again
>> I just found

Re: [Plplot-devel] bug in notpointinpolygon

[Phil Rosenberg]

I have managed to further isolate the issue and I've attached a minimum
example. Internal integer pixel units are a factor, so it might not show up
on all devices. This example shows up the error on my Windows machine with
the wxWidgets device.

The example draws a single rectangle using plfill, but the rectangle itself
is well outside the range of the axes. Despite the position of the
rectangle, the result is that the whole plot area is filled.

The bug occurs when drawing polygons with a very high aspect ratio (tall
and thin), outside the plot area in certain positions. It may even only
happen for polygons one internal plot unit wide.

As part of the plP_plfclp code, we check if each of the bottom left corner
of the plot area is within the polygon and if no edges of the polygon
intersect the plot area. If both these conditions are true, the polygon
must cover the whole plot area, so we fill it all. To check if the bottom
left corner is within the polygon, we trace a ray from that point in a
particular direction. If the ray crosses an even number of polygon edges
the point is external and if it crosses an odd number of edges then the
point is internal. The crossings are checked by a function called
notcrossed and they are accumulated over a whole polygon by a function
called notpointinpolygon.

However, there is some ambiguity due to floating point arithmetic when
lines are close to parallel and intersections are close to vertices. Hence,
notcrossed can return 0 (crossed) 1 (notcrossed) and a series of other
values indicating that we are uncertain if we have crossed or not. One of
those return values is PL_NEAR_PARALLEL(32), however, notpointinpolygon
does not check for this and counts it as true, i.e. not crossed. In almost
all scenarios, the return of PL_NEAR_PARALLEL for one edge, results in a
PL_NEAR_POINT (where POINT is A1, A2, B1 or B2) return for another edge.
This return value is picked up by notpointinpolygon and is reflected in its
return value, so this bug almost never manifests.

However, it turns out that a polygon edge with size of 1 internal unit, if
intersected, will always generate a PL_NEAR_PARALLEL return value, even if
the lines are close to perpendicular. this is treated as not crossed. If
the polygon has a large aspect ratio, the ray can intersect another edge
significantly far from its ends that it does not trigger a PL_NEAR_POINT
return value. notpointinpolygon therefore misses one edge intersection and
incorrectly thinks the point is in the polygon.

Where this happens for the bottom left corner, and no edges cross the plot
area we end up filling the whole box. Although it might seem like this is
very unlikely, if you use plshades to do a contour plot  with very fine
horizontal resolution and much coarser vertical resolution and zoom in on
the y axis to crop some of the data out, then it turns out to be almost
inevitable that at least one polygon will trigger the problem. In my case
I'm plotting data from a meteorological lidar - high temporal resolution,
coarser vertical resolution.

To fix this I've written an optimised version of notcrossed, called
notcrossedhorizontalray. This uses a horizontal ray rather than a ray to a
point near the polygon. It uses entirely boolean logic and integer maths
except for one division, so it should be accurate. I updated
notpointinpolygon to use the new function and recognise the unsure case. I
added some extra checks in plP_plfclp. I attach a patch if anyone wants to
test it. Clearly I'm not the first person to wrestle with this code as
there is another commented out version. In my
code USE_FILL_INTERSECTION_POLYGON is not defined, so there is a large
chunk of code unused. I don't know if this gets used in some builds, but
maybe it could be cleaned up if not.

If nobody objects I will commit the change to the repo

Thanks
Phil

On Wed, 10 May 2023 at 10:38, Phil Rosenberg 
wrote:

> Hi again
> I just found a bug in plP_plfclp.
>
> I hit a scenario where during a plshades call, my whole window (including
> outside the x and y limits of the data) got filled with one of the colours.
> I've traced this to plP_plfclp, the drawable variable and notpointinpolygon.
>
> What happens is that, while filling one polygon the bottom left corner
> gets incorrectly assigned as inside the polygon and drawable gets
> incorrectly assigned as false. This results in plP_plfclp thinking that the
> polygon encircles the whole plot window and the plot window gets filled
> with the colour.
>
> I haven't had chance to check why drawable ends up as false, however, the
> error in notpointinpolygon comes from notcrossed returning
> PL_NEAR_PARALLEL. notpointinparallel doesn't deal with this special return
> value and instead treats it as returning true. In this particular case, it
> should be returning false and so everything goes wrong.
>
> I suggest a couple of fixes.
>
> in notpointinpolygon, 

[Plplot-devel] bug in notpointinpolygon

[Phil Rosenberg]

Hi again
I just found a bug in plP_plfclp.

I hit a scenario where during a plshades call, my whole window (including
outside the x and y limits of the data) got filled with one of the colours.
I've traced this to plP_plfclp, the drawable variable and notpointinpolygon.

What happens is that, while filling one polygon the bottom left corner gets
incorrectly assigned as inside the polygon and drawable gets incorrectly
assigned as false. This results in plP_plfclp thinking that the polygon
encircles the whole plot window and the plot window gets filled with the
colour.

I haven't had chance to check why drawable ends up as false, however, the
error in notpointinpolygon comes from notcrossed returning
PL_NEAR_PARALLEL. notpointinparallel doesn't deal with this special return
value and instead treats it as returning true. In this particular case, it
should be returning false and so everything goes wrong.

I suggest a couple of fixes.

in notpointinpolygon, we should check if the point is outside the polygon
bounding box. This will catch many of the near parallel cases.

For the reminder we then need a better way to find a point to do the ray
tracing or to catch the special codes and then choose another point. This
is easier to do when we know the point is close to the polygon, because
then moving our ray tracing point has a bigger effect. We can also afford
to do some more complicated maths here because almost all cases will be
picked up by the bounding box case.

I'll work on this a bit today and send round a patch for people to review
if they wish before committing.

Thanks

Phil
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] buffer growth

[Phil Rosenberg]

Been a while since I've committed anything to the plplot repo, so I wanted
to check in before I did anything.

I just wanted to push a change to buffer growth, so that it grows
exponentially rather than linearly (doubles every time it needs to grow). I
have some rather large data being plotted by plshades and plplot is doing a
lot of reallocs to grow the buffer 128kB at a time.

Let me know if it's okay to push the commit.

Phil
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] CSA NaNs and Visual Studio 2019

[Phil Rosenberg]

I've just updated to using VS2019 and found a problem with csa/nan.h

Basically this file calls ymath.h when compiled on VS. According to this
forum post PLplot / Discussion / Open Discussion: Error compiling in
MSVC2019 (sourceforge.net)

it's
due to VS mixing C and C++. I've never really heard of ymath.h, but a quick
google seems to hint that it is part of Microsoft's implementation of the
C++ Standard Template Library - so maybe it should never have been called
from C code in the first place.

The problem itself appears in plgridd.c where csa/nan.h is #included even
when we are not building with csa.

My feel is that plgridd.c should simply not use csa to get its NAN
implementation. So I'm about to commit a fix that defines PLFLT_NAN along
with PLFLT_HUGE_VAL, etc in plplot.h.

I'm posting to ask what (if anything) we should do with CSA?

>From what I understand CSA is external to PLPlot and was just pulled into
the repo some time ago. It is not code written by PLPlot devs. CSA is now
available on github at cameronbracken/csa
, although it hasn't been updated
for around 9 years. Arjen - if you read this, it looks like it was you that
added the ymath.h code.

I've never used csa, so for now I won't change anything within the CSA
code. But I guess we can either revert to the non ymath.h code or do
something entirely different.

For now, my changes will mean when CSA is off PLPlot will still build.
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] test-drv-info

[Phil Rosenberg]

Hi Alan
I think I have found a problem with test-drv-info. I think it is
unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using
-DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the
end of all debug libraries. But this causes test-drv-info to report:
Could not open the driver module 
If I go onto the command line ant try running test-drv-info myself,
adding d to the module name, I get
Could not read symbol plD_DEVICE_INFO_d in driver module d

Is it possible to pull the postfix into the test-drv-info source? It
would simply need concatenating at line 76 of test-drv-info.c

Phil


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Plplot-general] Problem with LNK2019 error unresolved external

[Phil Rosenberg]

Here are a set of instructions that seem to work for me to build a set of
dlls. I created a new user on my machine and a fresh directory structure
and from this clean setup I got good build results.

1. Download wxWidgets-3.0.4 to C:\test\src\ and use 7zip to extract to a
folder called wxWidgets-3.0.4
   C:\test\src\wxWidgets-3.0.4 now contains files called configure,
.gitattributes, etc
2. Open C:\test\src\wxWidgets-3.0.4\build\msw\wx_vc12.sln, I get asked
about retargetting projects. I leave everything ticked and hit OK
3. Select DLL Debug and x64 configurations. Hit f7 to build.
4. Change DLL Debug to DLL Release and keep x64. Hit f7 to build again.
5. Add C:\test\bin;C:\test\src\wxWidgets-3.0.4\lib\vc_x64_dll; to the path
variable.
6. Create a variable WXWIN with a value of C:\test\src\wxWidgets-3.0.4\
7. Download plplot-5.15.0 to C:\test\src\ and use 7zip to extract to a
folder called plplot-5.15.0. The folder C:\test\src\plplot-5.15.0 now
contains the ABOUT and INSTALL files etc.
8. Start a developer command prompt for VS 2017 and execute these commands
(if you started this already, close it and reopen to see the new
environment variables)
   cd C:\test\src\plplot-5.15.0
   mkdir build
   cd build
   set CXXFLAGS=/DUNICODE /D_UNICODE
   set CFLAGS=/DUNICODE /D_UNICODE
   cmake .. -G "Visual Studio 15 2017 Win64"
-DCMAKE_DINSTALL_PREFIX="C:\test" -DCMAKE_DEBUG_POSTFIX=d
   NOTE THE DEBUG POSTFIX IS TO ENABLE RELEASE AND DEBUG LIBS TO INHABIT
THE SAME DIRECTORY AS IT ADD d TO THE FILENAMES
9. Open the file C:\test\src\plplot-5.15.0\build\plplot.sln
10. Ensure Dubug and x64 configuration are selected. Right click the
INSTALL project and select build.
11. Change to Release, sticking with x64 configuration. Right click the
INSTALL project and select build.


I have never built the examples in the share/plplot/examples directory. But
Let me know how you get on with this setup.

Phil



On Mon, 9 Sep 2019 at 20:38, David Bergman 
wrote:

> No it is not.
>
>
> On 9/9/2019 3:33 PM, Phil Rosenberg wrote:
>
> Is the directory containing your old dlls listed in your path variable. If
> so, the old ones can be found by mistake and erroneously used.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* stuntguitar1969 
> 
> *Sent:* Monday, September 9, 2019 7:37:47 PM
> *To:* Phil Rosenberg  ;
> plplot-gene...@lists.sourceforge.net
> 
> 
> *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
> I will double check everything.   Past issues in the thread have resolved
> by rebuilding and making sure x64 is chosen everywhere.   I cannot rule out
> that something might be 32 bit but I tried to be thorough in the last build
> and install of everything.   I do have my old libs and dlls but they are in
> a different dir which is not used in the project.  I'll try the example
> again just to be sure.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>  Original message 
> From: Phil Rosenberg  
> Date: 9/9/19 2:20 PM (GMT-05:00)
> To: plplot-gene...@lists.sourceforge.net, David Bergman
>  
> Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
> Corrupt file error sounds like you are mixing 64 and 32 bit exes and dlls.
> I think I've had that error with some libraries before and found that was
> my mistake.
>
> Is your install bin directory on your path? Do you have any old dlls
> somewhere that might be on your path?
>
> I usually use static libs. I used a dll version of wxwidgets about 6
> months ago, so I know things worked back then. But I'm back to using static
> libs again. I will build a dll version of plplot this evening and send you
> exactly the commands I used.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* David Bergman 
> 
> *Sent:* Monday, September 9, 2019 6:31:00 PM
> *To:* Phil Rosenberg  ;
> plplot-gene...@lists.sourceforge.net
> 
> 
> *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
>
> Phil,
>
> I've gotten a little further.  I tried to run one of the examples building
> a VS project and sln.  Making sure everything was aligned w/r to he choice
> x64 I got a corrupted file error.
>
> ErrorLNK1107invalid or corrupt file: cannot read at 0x310
> plplotExamplesC:\build-plplot-new-man\dll\csirocsa.dll1
>
> I am not sure what to do.  Looking through some of the old blog posts of
> the issues I had last year it seems that is was also an issue then.
>
> When you do your build were you able to get everything using the sln or
> did you have to install at the command prompt too.  That rings a bell and I
> think I wound

Re: [Plplot-devel] uncrustify msys2

[Phil Rosenberg]

Sorry, my last email wasn't sent to the list - see below.

I think I have found the solution, by changing the shebang to python2
rather than python.

I'm going to commit this change as it is a change that only affects us
developers. Alan - if you could test to check it works on your linux
system, that would be great.

On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg  wrote:
>
> Hi Alan
> The error message I gave is the complete error message, there is no
> output of the line variable. This, combined with the fact that the
> carat is pointing to the end of the line of python code, made me think
> this was a syntax error in the python code itself.
>
> When I opened convert_comment.py in visual studio, the error
> highlighting underlined all instances of raise RuntimeError. Hovering
> the mouse over displayed the following error
>
> invalid syntax, only exception value is allowed in 3.x
>
> Googling this error lead me to
> https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception
>
> So I think, basically the syntax for raise has changed between 2.x and
> 3.x and for whatever reason, on my system the script is being executed
> using 3.x
>
> Any fix suggestions? I don't really know python at all.
>
> Phil
>
> On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin  
> wrote:
> >
> > On 2019-07-31 12:44+0100 Phil Rosenberg wrote:
> >
> > > Thanks Alan
> > > I've just tried again with the style_source script, but I'm hitting
> > > another problem. I now get the error:
> > >
> > > File "scripts/convert_comment.py", line 72
> > >raise RuntimeError, "Cannot interpret trailing character(s) after
> > > */ for this line"
> > >  ^
> > > SyntaxError: invalid syntax
> > > ERROR: scripts/convert_comment.py failed for file plplot_config.h.in
> > >
> > >
> > > Any suggestions? I have both python 2 and 3 installed.
> >
> > That error message comes from this logic in scripts/convert_comment.py
> > which hasn't been changed (from git blame -w) since 2010.
> >
> >  # Note trailing "\n" has not (yet) been removed from line so
> >  # that the next to last character is at position len(line) - 3.
> >  if end_comment >=0 and end_comment !=  len(line) - 3:
> >  if ifsingleline and start_comment >=0:
> >  # Skip most further processing for a line with embedded
> >  # comments outside of multiline blocks of comments.
> >  start_comment = -1
> >  end_comment = -1
> >  else:
> >  sys.stderr.write(line)
> >  raise RuntimeError, "Cannot interpret trailing character(s) 
> > after */ for this line"
> >
> > So that error message should have included the results from 
> > sys.stderr.write(line)
> > from the line in plplot_config.h.in that is stored in the Python "line" 
> > variable
> > that appears to be causing this python logic problem.
> >
> > The usual interpretation of this error message is you have commentary
> > in plplot_config.h.in which is not in legitimate form.  For example,
> > you might have forgotten the trailing "*/" on a comment.  So I would
> > test that possibility by attempting to build the plplot target before
> > styling, which would necessarily attempt to compile the configured
> > plplot_config.h.
> >
> > However, if that "easy" answer is not the correct one, please send the
> > complete error message including the output of the Python "line" variable
> > that is causing the issue.
> >
> > Of course, the above Python logic only works if there are no
> > line-ending issues in Python, i.e., the Python "line" variable
> > contains a string that is terminated simply by \n rather than
> > \r\n. And note that by git default plplot_config.h.in will have \r\n
> > line endings on MSYS2.  But the discussion in
> > <https://stackoverflow.com/questions/10785131/line-endings-in-python>
> > seems to imply that on Python automatically converts all \r and \r\n
> > line endings for text files to \n.  Also, my impression is you have
> > exercised the above scripts/convert_comment.py logic from 2010 with no
> > issues in the past on Cygwin (where again, the checked out
> > plplot_config.h.in should have \r\n line endings.) So I would only
> > look at this potential line ending issue (by dumping out each raw byte
> > of the above line) only as a last re

Re: [Plplot-devel] uncrustify msys2

[Phil Rosenberg]

Thanks Alan
I have a commit ready to go that removes a plexit call if the .fnt hershey font 
files are missing for some reason.

I'll wait for your uncrustify change then before I push it.

Get Outlook for Android<https://aka.ms/ghei36>


From: Alan W. Irwin 
Sent: Wednesday, July 24, 2019 9:40:16 AM
To: Phil Rosenberg 
Cc: PLplot development list 
Subject: Re: [Plplot-devel] uncrustify msys2

Hi Phil:

On 2019-07-23 18:44+0100 Phil Rosenberg wrote:

> Hi
> I just wanted to check if anyone on the list has used uncrustfy in
> msys2 to run the style-source script?

 I am very happy to hear you are making progress with MSYS2, and I
look forward to your comprehensive test reports for that platform..

>
> I couldn't find an uncrustify package to install via pacman, so I
> built it from source. However, when I run style_source.sh I get the
> following error
>
> Detected uncrustify version = 'Uncrustify-0.69.0_f'.
> This script only works with uncrustify 0.60.

Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously
way past time to move to the latest version (0.69.0) so I have taken
responsibility for making that change.

One minor issue that I am currently looking at is the following (mild) warning
message I encountered from the CMake-based build system for uncrustify:

-- scripts/make_version.py exited with code 64: Unknown version control system 
in '/home/software/uncrustify/uncrustify-0.69.0'.

As a fallback, version 'Uncrustify-0.69.0_f' will be used.

Since the version string reported by you is
'Uncrustify-0.69.0_f' I assume your build has the same warning message.

I am virtually positive that warning is due to us both building from
the appropriate tarball rather than appropriate git tag, but I will
know a lot more tomorrow (after getting some sleep) after I finish
implementing a bash script to configure, build, install, and test from
the appropriate git tag corresponding to the desired uncrustify
version.  (For git enthusiasts like me such a build is actually easier
to do than a build from a tarball).  But my guess at this stage is
that script result will be the above minor issue will be fixed (since
git is virtually certainly the version control system that their build
system is looking for) and the uncrustify executable version string we
both encountered with the tarball build of 'Uncrustify-0.69.0_f' will
likely be replaced by 'Uncrustify-0.69.0'.  But I will see about that
version string tomorrow and see also the FIXME note below concerning
that.

Here is the PLplot commit message I have in mind for tomorrow (adapted
from the git commit message when I updated from 0.58 to 0.60 ~5 years
ago):

 Update from uncrustify version 0.60 to 0.69.0.

 This commit includes the following changes.

 1. Update annotated configuration file using
 uncrustify --update-config-with-doc -c uncrustify.cfg > 
uncrustify-0.69.0.cfg
 mv uncrustify-0.69.0.cfg uncrustify.cfg

 2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the
 allowed uncrustify version string to either 'Uncrustify-0.69.0' (built 
from appropriate
 git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME 
if the git
 version of the build provides a version string different than 
'Uncrustify-0.69.0')

 3. Run that script to update the style of a large number of our source code
 files according to the uncrustify 0.69.0 rules.  We ascribe these large 
number
 of whitespace changes to changes in the implementation (new features
 with default configuration, bug fixes, and/or introduced bugs) between
 uncrustify 0.60 and 0.69.0.  Note that visual sampling of these changes 
didn't
 reveal any obvious style issues, and these changes also passed the test
 below:

 Tested by Alan W. Irwin  on Linux
 (Debian Buster) by building the test_noninteractive target in the
 build tree and evaluating the result to demonstrate no build-time or
 run-time errors, and no issues with the SVG difference report.

Finishing implementing the uncrustify build, install, and test script
and all the above changes, tests, and test evaluations is obviously
going to take me a while, but it all appears to be entirely
straightforward so my current ETA for the above proposed commit is
late tomorrow (Wednesday) or so.

More then.

Alan
__
Alan W. Irwin

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.org); 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
__
___
Plplot-devel mailing list
P

[Plplot-devel] uncrustify msys2

[Phil Rosenberg]

Hi
I just wanted to check if anyone on the list has used uncrustfy in
msys2 to run the style-source script?

I couldn't find an uncrustify package to install via pacman, so I
built it from source. However, when I run style_source.sh I get the
following error

Detected uncrustify version = 'Uncrustify-0.69.0_f'.
This script only works with uncrustify 0.60.


Phil


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake problem with hyphen in path

[Phil Rosenberg]

Hi Alan
You may be right.
I tried commenting out the offending regex replace, which meant cmake finished 
with no issues. But, when I tried to compile I found I had a similar problem 
with header files. I couldn't actually find the offending code that is causing 
that problem. I tried adding some quotes, but that didn't seem to help.

So whatever workload you thought it was, it is actually double!

Would it be relatively straightforward to add a check, so if the user supplies 
an install or library/header path that contains " -" then we error out at that 
point? This way if anyone else hits this problem it would be very clear to the 
user what the problem is and how to fix it.

I presume we can't check each library individually - or it would be easy to 
fix. But I am setting cmake_install_prefix to a path that is bad, so maybe that 
could be checked. I think there are other variables too. Link_directories and 
include_directories, any more?

I'll set a workaround up on my computer by symlinking my usr directory from 
c:\usr or something. But it's a work computer and I'll need someone with admin 
rights to sort it for me next week.

Phil

Get Outlook for Android<https://aka.ms/ghei36>


From: Alan W. Irwin 
Sent: Saturday, July 13, 2019 6:42:20 AM
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: CMake problem with hyphen in path

On 2019-07-13 00:35+0100 Phil Rosenberg wrote:

> There are no .pc files. I'm building on native windows with visual
> studio (not with Cygwin or MSYS2) so there is no pkg-config. All
> libraries get found with the findXXX.cmake modules. In this case it is
> shapelib and wxwidgets libraries.
>
> On windows CMake basically hunts in certain locations for the libs and
> headers. In this case it finds shapelib by checking in my
> CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment
> variable.

[...]
> Output
> (original _link_flags_list) = debug;C:/Users/earpros/OneDrive -
> University of 
> Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

> (post regex replace _link_flags_list) =
> debug;C:/Users/earpros/OneDrive;- University of
> Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

Hi Phil:

Thanks for the above detailed information which contradicted some of
my assumptions (natch).

However, I am frankly beginning to get cold feet about working much
further on this topic since from my Linux test of the case where
external libraries have blanks and hyphens in their installation
prefixes, there are a huge bunch of issues we would have to deal with
before that case worked, i.e., it would be a lot of work for little
real gain.

For example, my understanding is Windows installers typically give you
a choice of any installation prefix you want.  So wouldn't it be a lot
easier to ask our Windows users to be careful of that choice, i.e.,
pick installation prefixes without blanks or hyphens?  For example,
MSYS2 allows users to choose any installation prefix they like.  And
I think they even recommend not choosing an installation prefix with
spaces because of all the trouble that causes with free software.

Alan
__
Alan W. Irwin

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.org); 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
__
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake problem with hyphen in path

[Phil Rosenberg]

cmake_link_flagsHi Alan
There are no .pc files. I'm building on native windows with visual
studio (not with Cygwin or MSYS2) so there is no pkg-config. All
libraries get found with the findXXX.cmake modules. In this case it is
shapelib and wxwidgets libraries.

On windows CMake basically hunts in certain locations for the libs and
headers. In this case it finds shapelib by checking in my
CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment
variable.

However I have attached below, the value of _link_flag_list just
before and just after the regex replace in cmake_link_flags

Cmake code
message("(original _link_flags_list) = ${_link_flags_in}")
# Convert link flags to a list.  Note some link flags are blank-delimited
# (such as "-framework whatever") so preserve those by splitting into
# separate list elements only if the next element starts with a hyphen.
string(REGEX REPLACE " -" ";-" _link_flags_list "${_link_flags_in}")
message("(post regex replace _link_flags_list) = ${_link_flags_list}")


Output
(original _link_flags_list) = debug;C:/Users/earpros/OneDrive -
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32
(post regex replace _link_flags_list) =
debug;C:/Users/earpros/OneDrive;- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive;-
University of 
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive;-
University of 

Re: [Plplot-devel] Possible Windows development agendas for the next 6 months

[Phil Rosenberg]

Hi Alan, Jim, Arjen

I will try and sort that submitted patch asap.

I will also experiment with MSYS2 - I now have a windows laptop at
work and need a linux-like system on there. I did intend to use the
Ubuntu Bash on Windows System, but my IT dept seem to have blocked
this - at least for now. So I may try MSYS2 ather than Cygwin.

I would also like to get the wxWidgets driver sorted as you described.
This is time limited unfortunately.

Just a note about MSVC, what are the ABI concerns you have? It is of
note that GCC for windows does not provide ABI forward compatibility
https://stackoverflow.com/a/23521099. My understanding is that MSVC's
C ABI is consistent across versions and I just did a quick google and
found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible.
https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/

Interestingly it looks like Microsoft is also developing some sort of
open source library packaging system, called Vcpkg, to reduce the
existing pain of having to build all open source libraries from
scratch 
https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/.
Might be worth looking into. Had a quick scan down the list of
available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA
- JUST CHECKED AND SO IS PLPLOT!!! At version 5.13.

Phil

On Thu, 13 Jun 2019 at 00:10, Alan W. Irwin  wrote:
>
> On 2019-06-12 12:27-0700 Alan W. Irwin wrote:
>
> >> On 2019-06-11 17:29-0400 Jim Dishaw wrote:
> >> I think the earliest version of windows we should
> >> support is win7. Keeping XP support will be a challenge.
> >
> > According to , XP was introduced 
> > in
> > 2001, Microsoft
> > quit fundamental support for it in 2014, and the percentage of Windows users
> > who
> > are still using it has dropped to ~2 per cent as of a few months ago.  So
> > yes, I am fine
> > with us dropping XP support as well.
>
> I have just discovered my answer above did not go far enough because I
> forgot XP was followed by Vista which was followed by Windows 7.  From
>  Vista share of the
> Windows market is down to 0.5% while from
>  the Windows 7 share is still
> at 33% with both numbers sampled just a few months ago.  So I agree we
> should drop support for both XP AND Vista now so that the earliest
> version we should support is Windows 7.
>
> Alan
> __
> Alan W. Irwin
>
> 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.org); 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
> __
>
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] findwxwidgets.cmake module

[Phil Rosenberg]

Okay, well it sounds like the best thing to do is when you bump the minimum 
version, remove the find wxwidgets module too. Or if you prefer me to get rid 
of it now, then just say.

Get Outlook for Android<https://aka.ms/ghei36>


From: Alan W. Irwin 
Sent: Thursday, January 31, 2019 9:01:23 PM
To: Phil Rosenberg
Cc: PLplot development list
Subject: findwxwidgets.cmake module

On 2019-01-31 17:37-0000 Phil Rosenberg wrote:

> Hi Alan
> I half thought that we had scrapped our findwxWidgets.cmake module,
> but I just found that this isn't actually the case.
>
> I've just disabled our version by renaming it, and I've found that the
> CMake version does appear to work on Windows. This is using cmake
> 3.13.3 (the latest release as of writing this email).
>
> I seem to remember that it was for windows builds that we were
> maintaining our own version. Perhaps this can now be removed?

Hi Phil:

I am moving this development discussion to the plplot-devel list since that is 
what
that list is for, and plplot-general is normally just used for user support.

I followed up on your question by using

git log cmake/modules/FindwxWidgets.cmake

to check the history of this file.  As of commit 59344dc51a25
it was updated to the official upstream version for
CMake-3.9.0-rc3, and since there has been 3 commits, but
one of them cancelled another one so the net effect of our changes
since commit 59344dc51a25 is as
follows:

software@merlin> git diff 59344dc51a25 HEAD cmake/modules/FindwxWidgets.cmake
diff --git a/cmake/modules/FindwxWidgets.cmake 
b/cmake/modules/FindwxWidgets.cmake
index 82f34ec32..4d3a2d115 100644
--- a/cmake/modules/FindwxWidgets.cmake
+++ b/cmake/modules/FindwxWidgets.cmake
@@ -915,8 +915,17 @@ if (_wx_lib_missing)
  endif()
  unset(_wx_lib_missing)

-# Check if a specfic version was requested by find_package().
+# Check if a specific version was requested by find_package().
  if(wxWidgets_FOUND)
+  # On at least one Windows platform (MinGW/MSYS) find_file fails
+  # unless convert from // form to :/
+  # form.  So use both forms to be sure on that platform without
+  # disrupting other platforms.
+  string(REGEX REPLACE ";/([a-zA-z])/" ";\\1:/" wxWidgets_search_path 
";${wxWidgets_INCLUDE_DIRS}")
+  list(REMOVE_AT wxWidgets_search_path 0)
+  if(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
+list(APPEND wxWidgets_INCLUDE_DIRS ${wxWidgets_search_path})
+  endif(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} 
NO_DEFAULT_PATH)
dbg_msg("_filename:  ${_filename}")

That change was to help support the legacy MinGW/MSYS system which is now likely
of zero interest to us (since its successor MinGW-w64/MSYS2 is so much better).
And this change may not be necessary on any other platform.

Meanwhile, since CMake-3.9.0-rc3 the CMake developers have been
actively maintaining the upstream version of FindwxWidgets.cmake to
the point that from your experience it is a big improvement on our
version.

So yes, I agree that it is time for us to drop our own version, and if
we find the above patch is necessary on any Windows platform of
interest to us we can always submit that change for inclusion into the
upstream version.

Meanwhile, the upstream version of this find module would likely fail
for our users that are using cmake versions less than 3.9.0.  But that
is not going to be an issue since I plan in any case today to bump the
minimum version of cmake that PLplot accepts to a version of CMake
that all modern Linux, Mac, and Windows free software distributions
support.  That new minimum version will be 3.13.2 for Linux, but I
still have to look at the Mac OS X distributions Fink, MacPorts, and
HomeBrew, and the Windows distributions Cygwin, and MinGW-w64/MSYS2 to
see if that or a higher version of CMake is available for all of
those.

Just to remind developers here that are not aware of this, the
motivation for such bumps in the minimum version of CMake we accept
for PLplot configuration is all the bug fixing and improved find
capability (e.g., for the wxwidgets find module) that has gone on, and
the improved CMake policy that has been established for modern CMake
versions.  So in general every such bump makes our build system more
robust and easier to maintain (e.g., it allows us to drop our own
version of the wxwidgets find module).

Alan
__
Alan W. Irwin

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 proj

Re: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

[Phil Rosenberg]

Sounds like a generally good plan to me. The only issues might be picking what 
is a bug fix commit vs a non bug fix commit - I'm sure we are all guilty of 
finding a bug while changing code and not submitting it as a separate commit. 
But providing we all try to be good in that sense, I think a bug fixes release 
is a good idea.

Phil

Get Outlook for Android


From: Alan W. Irwin 
Sent: Monday, December 17, 2018 5:31:31 AM
To: PLplot development list
Subject: [Plplot-devel] git workflow plans for the proposed bug-fix 
plplot-5.14.1 release

Can some git guru here review my proposed git workflow for the planned
5.14.1 release below?

The reason I ask for that review is because I currently have no
practical experience with some of the special git commands that will
be needed.  In fact, because of that lack of experience I previously
did not create a bug-fix release in an earlier release cycle for
PLplot (at least in its git era) when I likely should have!  So this
bug-fix release will be a long-overdue learning experience for me.

That said, I am pretty sure from reading on-line material and a hint
from one of our users what git steps I would have to take.  Also note
these proposed steps do not violate our (enforced) workflow rule that
no merge commits other than fast-forwarded ones are allowed.

Those git steps are as follows:

* Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 
tag.

* Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that 
branch.

* Go through the usual release procedure while staying strictly on
   that branch which will add other commits to that branch such as the
   new (short) release notes and ChangeLog for that 5.14.1 release
   without ever merging those commits back to master.  Which means none
   of this bugfix release work impacts on the ordinary development of
   the master branch.  One of the last steps in that procedure would be
   to push the local tag that points to the tip of 5.14.0-bugfix
   (called plplot-5.14.1 in this case) to our SF git repository (again
   without changing the master branch).

* From remarks in
   

   it appears that pushing a tag pushes the associated commit and also
   pushes all ancestors of that commit that have not been pushed
   before.

   If that is correct, then all commits on my local branch called
   "5.14.0-bugfix" will end up accessible at SF but not organized as a
   formal branch there.  That result is fine with me since it doesn't
   clutter the SF version with extra branch names, and the result is
   enough to allow anybody (after they use the "git refresh" command)
   to access the commit corresponding to the plplot-5.14.1 tag or any
   of that commit's ancestors.  For example, if later on during the
   release cycle I decided to release another bug-fix release called
   5.14.2, I could start that process by branching from the
   plplot-5.14.1 tag.

   Furthmore after pushing the plplot-5.14.1 tag I would likely delete
   the 5.14.0-bugfix local branch to be consistent with the SF repository;
   I would have no further use for that branch; and
   that branch deletion does not get rid of the plplot-5.14.1 tag,
   the associated commit or any ancestors of that commit;

   Of course, with this model of workflow for bug-fix releases, no
   attempt would ever be made to merge bug-fix branches back to master
   since that makes no sense in any case and would violate our
   (enforced) rebase work flow rule that there can be no merge commits
   that cannot be fast-forwarded.

Again, comments on this plan from the git gurus here will be most welcome.

Alan
__
Alan W. Irwin

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
__


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] How to use plplot in my own project?

[Phil Rosenberg]

Hi Laurent
Just a not about naming - I too expected a d suffix on the library
name to represent debug when I first started using plplot. There used
to be a cmake option to add a suffix to the name, but it is no longer
listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
- Alan do you know if it is still implemented and if so what it is?
There used to be a d suffix added to represent the fact that the
library was built with double precision floating point variables, but
I don't think this is the case any more.

I used to add the d suffix for debug builds, but in the end I stopped.
I came across too many libraries that didn't do it. I have a feeling
it is an inherently windows style thing (you only need debug libraries
if they are static rather than shared and Linux users never seem to
build static libraries), so many Linux-centric open source projects
don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
Anyway, my solution was to install my debug libraries in a folder
specific to debug libraries. Almost every library has a way to specify
the install prefix. With plplot you can do this with the
-DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX

Whether you go for a prefix option or if a suffix is possible you will
need to run cmake twice, once for release and once for debug and once
for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
"Debug" or "Release".

Phil
On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin  wrote:
>
> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I want to use plplot in my own project using cmake and I miss something. my
> > cmakelists.txt is see below and it works. But in include_directories cmake
> > command I must write :
> >
> > include_directories(${plplot_DIR}/../../../include) and it is really weird.
> > what's variable name for include ?
>
> [...]
>
> > CMakeLists.txt
> >
> [...]
> > find_package(plplot)
> [...]
> > ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
> [...]
> > if (plplot_FOUND)
> >
> > include_directories(${plplot_DIR}/../../../include)
> > target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> > else (plplot_FOUND)
> > message( " PROBLEME" )
> > endif(plplot_FOUND)
>
> Hi Laurent:
>
> I have reviewed the redacted version above, and all seems well.  For
> example, our installed examples are similarly built against the
> installed version of PLplot, and what you have implemented above
> follows that same method.  For example, you can see
> "find_package(plplot)" (in the non-CORE_BUILD part of
> examples/CMakeLists.txt), and a combination of add_executable,
> include_directories (which refers to the installed location of PLplot
> for the non-CORE_BUILD case just like you apparently have
> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>
> However, you were right to question that include_directories command
> which is necessary now, but should not be necessary in future once I
> set up the export of PLplot to handle compile options properly.  But
> that implementation is a little tricky so although it is on my ToDo
> list now, I am going to put it off until after the 5.14.0 release that
> is coming soon.
>
> Alan
> __
> Alan W. Irwin
>
> 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
> __
>
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil Rosenberg]

Good news! Thanks for reporting the problem.

Phil

Get Outlook for Android<https://aka.ms/ghei36>


From: Laurent Berger 
Sent: Sunday, September 23, 2018 11:12:50 AM
To: Alan W. Irwin; Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] Cannot compile plplot using VS 2017

Hi,

https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/
: It works thanks!


New file is now

// Headers needed for Rand
#ifdef _WIN32
// This include must occur before any other include of stdlib.h due to
// the #define _CRT_RAND_S
#define _CRT_RAND_S
#include 
#else
#include 
#endif

// wxwidgets headers
#include 
#include 
#include 
// PLplot headers
#include "plDevs.h"
#include "wxwidgets.h" // includes wx/wx.h


// std and driver headers
#include 
#include 


Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
>> Hi Laurent
>>
>> I have implemented your first solution. If you could let me know that
>> things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __
> Alan W. Irwin
>
> 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
> __

___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil Rosenberg]

Excellent, thanks Alan
On Sun, 23 Sep 2018 at 01:25, Alan W. Irwin  wrote:
>
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
> > Hi Laurent
> >
> > I have implemented your first solution. If you could let me know that
> > things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __
> Alan W. Irwin
>
> 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
> __


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil Rosenberg]

Hi Laurent

I have implemented your first solution. If you could let me know that
things now work for you that would be great.

Thanks

Phil
On Sat, 22 Sep 2018 at 11:44, Laurent Berger
 wrote:
>
> I tried  2 solutions :
>
> FIRST solution
>
> don't change wxwidgets_dev.cpp
>
> and change include order in wxwidgets.h #include  after
>  and before  // plplot headers
>
> then  $ git diff is
> diff --git a/drivers/wxwidgets.h b/drivers/wxwidgets.h
> index 884292d07..0818f357c 100644
> --- a/drivers/wxwidgets.h
> +++ b/drivers/wxwidgets.h
> @@ -22,13 +22,14 @@
>
>   #include 
>   #include 
> +#include 
>
>   // plplot headers
>   #include "plplotP.h"
>   #include "wxwidgets_comms.h"
>
>   // some special wxWidgets headers
> -#include 
> +//#include 
>   #include 
>   #include 
>
> SECOND solution
>
> add #include  in wxwidgets_dev.cpp at line 41
>
> then $git diff is
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..07089d83a 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,7 @@
>   #else
>   #include 
>   #endif
> -
> +#include 
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
> Le 22/09/2018 à 12:26, Phil Rosenberg a écrit :
> > Hi Laurent
> >
> > Okay, well if your solution works, the I think we should add it in.
> >
> > Could I please ask for you to check what the minimum list of headers
> > to be included needs to be? Would just adding wx/wx.h be sufficient or
> > do all those headers need to be added?
> >
> > Phil
> >
> > Phil
> > On Sat, 22 Sep 2018 at 10:24, Laurent Berger
> >  wrote:
> >> Hi Phil, Alan,
> >>
> >> I check everything this morning (local time) and I have got same errors.
> >>
> >> I attached my cmakecache for plplot and cmakecache for wxwidgets
> >>
> >> git diff
> >>
> >> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> >> $ git diff
> >> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> >> index 6351c6893..27b20750e 100644
> >> --- a/drivers/wxwidgets_dev.cpp
> >> +++ b/drivers/wxwidgets_dev.cpp
> >> @@ -38,7 +38,15 @@
> >>#else
> >>#include 
> >>#endif
> >> +#include 
> >> +#include 
> >> +#include 
> >>
> >> +#include "plDevs.h"
> >> +
> >> +// plplot headers
> >> +#include "plplotP.h"
> >> +#include "drivers.h"
> >>// PLplot headers
> >>#include "plDevs.h"
> >>#include "wxwidgets.h" // includes wx/wx.h
> >>
> >>
> >>
> >>
> >> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> >>> Hi Laurent
> >>> What a strange set of compilation errors. They are all from windows
> >>> sockets headers, rather than from wxWidgets.
> >>>
> >>> Here is my guess at what is happening - but I have not been able to
> >>> reproduce the error (I am using VS 2015 still).
> >>>
> >>> In the code before your edits following the #includes through, it
> >>> turns out we include  into wxwidgets_dev.cpp before any
> >>> wxWidgets headers. This is done via "wxwidgets.h", then
> >>> "wxwidgets_comms.h". The winsock related functions probably get pulled
> >>> in via windows.h. I have a feeling that one of the wx headers is then
> >>> pulling in alternate definitions of those winsock functions, but I'm
> >>> not sure from where.
> >>>
> >>> By shuffling the headers round as you have, you include 
> >>> before we pull in . The  file will in turn pull in
> >>>  itself. then our include windows.h should get ignored.
> >>>
> >>> I can't think how exectly it might work, but I bet there is some weird
> >>> inconsistency between how  is pulled in by us, vs how it is
> >>> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> >>> or extern "C".
> >>>
> >>> Anyway I might guess that moving the headers around is simply masking
> >>> some other problem. Can I check that you have built wxWidgets with the
> >>> same virsion of visual studio? And that it is also built as a static
> >>> lib? Just a hunch but maybe something to do 

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil Rosenberg]

Hi Laurent

Okay, well if your solution works, the I think we should add it in.

Could I please ask for you to check what the minimum list of headers
to be included needs to be? Would just adding wx/wx.h be sufficient or
do all those headers need to be added?

Phil

Phil
On Sat, 22 Sep 2018 at 10:24, Laurent Berger
 wrote:
>
> Hi Phil, Alan,
>
> I check everything this morning (local time) and I have got same errors.
>
> I attached my cmakecache for plplot and cmakecache for wxwidgets
>
> git diff
>
> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> $ git diff
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..27b20750e 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,15 @@
>   #else
>   #include 
>   #endif
> +#include 
> +#include 
> +#include 
>
> +#include "plDevs.h"
> +
> +// plplot headers
> +#include "plplotP.h"
> +#include "drivers.h"
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
>
> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> > Hi Laurent
> > What a strange set of compilation errors. They are all from windows
> > sockets headers, rather than from wxWidgets.
> >
> > Here is my guess at what is happening - but I have not been able to
> > reproduce the error (I am using VS 2015 still).
> >
> > In the code before your edits following the #includes through, it
> > turns out we include  into wxwidgets_dev.cpp before any
> > wxWidgets headers. This is done via "wxwidgets.h", then
> > "wxwidgets_comms.h". The winsock related functions probably get pulled
> > in via windows.h. I have a feeling that one of the wx headers is then
> > pulling in alternate definitions of those winsock functions, but I'm
> > not sure from where.
> >
> > By shuffling the headers round as you have, you include 
> > before we pull in . The  file will in turn pull in
> >  itself. then our include windows.h should get ignored.
> >
> > I can't think how exectly it might work, but I bet there is some weird
> > inconsistency between how  is pulled in by us, vs how it is
> > pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> > or extern "C".
> >
> > Anyway I might guess that moving the headers around is simply masking
> > some other problem. Can I check that you have built wxWidgets with the
> > same virsion of visual studio? And that it is also built as a static
> > lib? Just a hunch but maybe something to do with the wxwidgets library
> > configuration is causing the issue.
> >
> > Phil
> > On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin  
> > wrote:
> >> On 2018-09-21 18:38+0200 Laurent Berger wrote:
> >>
> >>> Hi,
> >>>
> >>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> >>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >>>
> >>> and delete cmakecache.txt and I I'm trying to build plplot in static
> >>>
> >>> BUILD_SHARED_LIBS:BOOL=OFF
> >>>
> >>> and ENABLE_DYNDRIVERS:BOOL=OFF
> >>>
> >>> and I have got 59 errors compiling wxwidgets_dev.cpp.
> >>>
> >>> In git repo I can find this file
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >>>
> >>> I copy
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> >>> and insert those lines here
> >>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >>>
> >>> I can compile and link plplot.
> >> Hi Laurent:
> >>
> >> Thanks for your test of my recent PLplot development activity.
> >>
> >> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> >> and caf4801dfe (current master tip), and your description of the
> >> required change appears to correspond to copying some wxwidgets includes 
> >> from
> >> one part of the old commit (or alternatively the latest commit since
> >> those lines haven't changed) to just after
> >>
> >> #include "wxwidgets.h"
> >>
> >> As far as I can tell such a copy of includes should have zero effect
> >> so it appears either I misunderstood the change you described above or
> >> else the github 

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil Rosenberg]

Hi Laurent
What a strange set of compilation errors. They are all from windows
sockets headers, rather than from wxWidgets.

Here is my guess at what is happening - but I have not been able to
reproduce the error (I am using VS 2015 still).

In the code before your edits following the #includes through, it
turns out we include  into wxwidgets_dev.cpp before any
wxWidgets headers. This is done via "wxwidgets.h", then
"wxwidgets_comms.h". The winsock related functions probably get pulled
in via windows.h. I have a feeling that one of the wx headers is then
pulling in alternate definitions of those winsock functions, but I'm
not sure from where.

By shuffling the headers round as you have, you include 
before we pull in . The  file will in turn pull in
 itself. then our include windows.h should get ignored.

I can't think how exectly it might work, but I bet there is some weird
inconsistency between how  is pulled in by us, vs how it is
pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
or extern "C".

Anyway I might guess that moving the headers around is simply masking
some other problem. Can I check that you have built wxWidgets with the
same virsion of visual studio? And that it is also built as a static
lib? Just a hunch but maybe something to do with the wxwidgets library
configuration is causing the issue.

Phil
On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin  wrote:
>
> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> > ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >
> > and delete cmakecache.txt and I I'm trying to build plplot in static
> >
> > BUILD_SHARED_LIBS:BOOL=OFF
> >
> > and ENABLE_DYNDRIVERS:BOOL=OFF
> >
> > and I have got 59 errors compiling wxwidgets_dev.cpp.
> >
> > In git repo I can find this file
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >
> > I copy
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> > and insert those lines here
> > https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >
> > I can compile and link plplot.
>
> Hi Laurent:
>
> Thanks for your test of my recent PLplot development activity.
>
> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> and caf4801dfe (current master tip), and your description of the
> required change appears to correspond to copying some wxwidgets includes from
> one part of the old commit (or alternatively the latest commit since
> those lines haven't changed) to just after
>
> #include "wxwidgets.h"
>
> As far as I can tell such a copy of includes should have zero effect
> so it appears either I misunderstood the change you described above or
> else the github repo for PLplot is not properly up to date with the
> definitive SourceForge repo.  So to remove this uncertainty please
> give us the results of
>
> git diff
>
> to describe the definitive version of the change to the master tip of
> PLplot that works for you (i.e., allows a static build of PLplot to
> compile and link for your VS2017 platform).
>
> By the way, a comprehensive test of PLplot has recently (one commit
> behind master tip) worked perfectly here on Linux (Debian Buster).
> Such comprehensive tests include not only building a static wxwidgets
> device but run-time testing it as well.  Also that last commit on the
> master branch is a minor one involving how to control the Lua version
> that is searched for and is therefore extremely unlikely to introduce
> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> so someone with access to recent Windows platforms will have to
> attempt that instead.
>
> Alan
> __
> Alan W. Irwin
>
> 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
> __
>
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] rgb colourscale interpolation

[Phil Rosenberg]

Hi Again Alan

>>
>> I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3
>> changed member names] in the PLControlPt struct are likely a good idea
>> since h,l,s was a misnomer.  Nevertheless, those changes did cause
>> important build problems in the Tk-related part of the build which I
>> have now fixed (commit 94e2e5b01).
>
> Is this struct really part of our public API? It is not mentioned
> anywhere in the docs as far as I can tell so I presumed this was an
> internal use only structure.

I take it back - just found it in the docs regarding ABI

--
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

Re: [Plplot-devel] rgb colourscale interpolation

[Phil Rosenberg]

Hi Alan

On 31 July 2018 at 19:21, Alan W. Irwin  wrote:
> Hi Phil:
>
> I am moving this discussion to plplot-devel where it belongs.

Sorry, I hadn't realised we'd gotten off list. Thanks for moving it back.

>
> I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3
> changed member names] in the PLControlPt struct are likely a good idea
> since h,l,s was a misnomer.  Nevertheless, those changes did cause
> important build problems in the Tk-related part of the build which I
> have now fixed (commit 94e2e5b01).

Is this struct really part of our public API? It is not mentioned
anywhere in the docs as far as I can tell so I presumed this was an
internal use only structure.

>
> Example 12 (which uses RGB interpolation) shows the effect of your
> change.  The old code produced
>  which shows fairly
> discontinous colour results from 1982 to 1986, while the new code
> produces much smoother colour changes in that date range.  So from
> this evidence I feel your change is a nice win.
>
> I previously said (in response to your question about how you
> should edit README.release):
>
>> I assume you will want to insert a paragraph concerning
>
> your change in a new section 2.8 of "Improvements relative to the
> previous release".  Also, since you changed the semantics of the two
> functions (although not their API) for the RGB case you should
> probably specifically warn the users of this forthcoming release about
> that semantics change by adding a one-sentence new section 1.10 in
> "OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for
> the details.
>
> Since your backwards-incompatible API change to the PLControlPt struct is
> going
> to cause build problems (just like it did in our Tk-related code)
> for the minority of our users who actually use that struct
> in their code, you should expand that suggested single sentence in 1.10 to
> warn users of this specific change to PLControlPt.
>
> I look forward to your commit with the suggested changes in README.release.

They'll arrive this afternoon all being well.

>
>
> Alan
> __
> Alan W. Irwin
>
> 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

Re: [Plplot-devel] [Plplot-general] More questions about install

[Phil Rosenberg]

Hmm, not sure.

Are you rebuilding the whole library? Did you clean out the old build
directory? How did you download? Are any cygwin binary directories on your
path?

Phil

On Feb 4, 2018 11:32, "David Bergman" <davidrberg...@yahoo.com> wrote:

I am building on windows, DOS cmd build instructions as per

https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_Visual_CXX_CLI/

as before. cmake, nmake, nmake install.

I downloaded from the link you sent, not sure what happened.






On Sunday, February 4, 2018, 4:45:29 AM EST, Phil Rosenberg <
p.d.rosenb...@gmail.com> wrote:


Hi David
Can I as what toolset you are using to build with?
Libltdl appears to be gnu related, but I thought you were building with the
standard windows toolset.

Phil

Get Outlook for Android <https://aka.ms/ghei36>



From: David Bergman
Sent: Sunday, February 4, 03:41
Subject: Re: [Plplot-general] More questions about install
To: Phil Rosenberg


Scratch this last email, I discovered a typo in my cmake command.  However,
after getting past this I am now getting the following,

Could not open driver module wxwidgets
libltdl error: No error information
NMAKE : fatal error U1077: '..\dll\test-drv-info.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.



On Saturday, February 3, 2018, 8:59:14 PM EST, David Bergman <
davidrberg...@yahoo.com> wrote:


Phil,

I have the latest but I'm getting new build errors.
The IDE install failed for most projects and eventually hung.  This
occurred before but restarting usually fixes.
The DOS install failed on the nmake command,

NMAKE : fatal error U1073: don't know how to make 'C:\\all'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.

There were no errors in the cmake command and I'm doing this the same as
before (after help from Arjen to turn off cairo devices).

Could I manually add the code snippet to the header or do the libs need to
be rebuilt with the change?

Thanks,
David




On Saturday, February 3, 2018, 4:12:57 PM EST, Phil Rosenberg <
p.d.rosenb...@gmail.com> wrote:


Hi David
I just had another look at the code comparing to the release you are using
and you were absolutely right, there is a bug there. I have just fixed that
and pushed the resulting code up to our git repo. You can pull the latest
code from there at https://sourceforge.net/p/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>ci
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/master/tree/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/> in your browser,
or using git using the command

git clone git://git.code.sf.net/p/plplot/plplot

Let us know if you are having any difficulties grabbing it.

Phil
*From:* David Bergman <davidrberg...@yahoo.com>
*Sent:* Saturday, February 3, 2018 6:49:13 PM
*To:* Phil Rosenberg
*Subject:* Re: [Plplot-general] More questions about install

Phil,
Would the bug be in the header or the the call in the test code *.cpp?
If it's the header then I'd like the new version.  But if it's the driver
then would the documentation on wxWidgets classes be informative?
I notice typical declarations have wxTemplate * x = something(NULL),
to initialize the variable.
No such input appears in the driver.
Thanks,
David


On Saturday, February 3, 2018, 11:20:08 AM EST, Phil Rosenberg <
p.d.rosenb...@gmail.com> wrote:


Hi David
Can I just confirm which version of PLplot you are using or if it is a
version grabbed from the git repo?

I ask because the line numbers don't seem to match up with the version I
have. But looking at my code I have a feeling that bug has been fixed.

Phil


On Feb 3, 2018 15:56, "David Bergman" @yahoo.com <davidrberg...@yahoo.com>> wrote:

I tried running the wxPLplotDemo example and got the following compilation
error:

error C4703: potentially uninitialized local pointer variable 'drawDc' used
on line 378 of wxplplotwindow.h

Looking through the code it appears that every declaration of drawDC is as
follows

wxDC *drawDc = m_memoryDc;

except the last function

void wxPLplotwindow:: setUseGraphicsContext( bool
useGraphicsContext )
{
wxDC *drawDc;
...
}

I am not familiar with the details of the code but it appears tha

Re: [Plplot-devel] [Plplot-general] More questions about install

[Phil Rosenberg]

Hi David
Can I as what toolset you are using to build with?
Libltdl appears to be gnu related, but I thought you were building with the 
standard windows toolset.

Phil

Get Outlook for Android<https://aka.ms/ghei36>



From: David Bergman
Sent: Sunday, February 4, 03:41
Subject: Re: [Plplot-general] More questions about install
To: Phil Rosenberg


Scratch this last email, I discovered a typo in my cmake command.  However, 
after getting past this I am now getting the following,

Could not open driver module wxwidgets
libltdl error: No error information
NMAKE : fatal error U1077: '..\dll\test-drv-info.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.



On Saturday, February 3, 2018, 8:59:14 PM EST, David Bergman 
<davidrberg...@yahoo.com> wrote:


Phil,

I have the latest but I'm getting new build errors.
The IDE install failed for most projects and eventually hung.  This occurred 
before but restarting usually fixes.
The DOS install failed on the nmake command,

NMAKE : fatal error U1073: don't know how to make 'C:\\all'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.

There were no errors in the cmake command and I'm doing this the same as before 
(after help from Arjen to turn off cairo devices).

Could I manually add the code snippet to the header or do the libs need to be 
rebuilt with the change?

Thanks,
David




On Saturday, February 3, 2018, 4:12:57 PM EST, Phil Rosenberg 
<p.d.rosenb...@gmail.com> wrote:


Hi David
I just had another look at the code comparing to the release you are using and 
you were absolutely right, there is a bug there. I have just fixed that and 
pushed the resulting code up to our git repo. You can pull the latest code from 
there at 
https://sourceforge.net/p/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>ci<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/master/tree/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>
 in your browser, or using git using the command

git clone git://git.code.sf.net/p/plplot/plplot

Let us know if you are having any difficulties grabbing it.

Phil
From: David Bergman <davidrberg...@yahoo.com>
Sent: Saturday, February 3, 2018 6:49:13 PM
To: Phil Rosenberg
Subject: Re: [Plplot-general] More questions about install

Phil,
Would the bug be in the header or the the call in the test code *.cpp?
If it's the header then I'd like the new version.  But if it's the driver then 
would the documentation on wxWidgets classes be informative?
I notice typical declarations have wxTemplate * x = something(NULL), to 
initialize the variable.
No such input appears in the driver.
Thanks,
David


On Saturday, February 3, 2018, 11:20:08 AM EST, Phil Rosenberg 
<p.d.rosenb...@gmail.com> wrote:


Hi David
Can I just confirm which version of PLplot you are using or if it is a version 
grabbed from the git repo?

I ask because the line numbers don't seem to match up with the version I have. 
But looking at my code I have a feeling that bug has been fixed.

Phil


On Feb 3, 2018 15:56, "David Bergman" 
<davidrbergman<mailto:davidrberg...@yahoo.com>@yahoo.com<mailto:davidrberg...@yahoo.com>>
 wrote:
I tried running the wxPLplotDemo example and got the following compilation 
error:

error C4703: potentially uninitialized local pointer variable 'drawDc' used on 
line 378 of wxplplotwindow.h

Looking through the code it appears that every declaration of drawDC is as 
follows

wxDC *drawDc = m_memoryDc;

except the last function

void wxPLplotwindow:: setUseGraphicsContext( bool useGraphicsContext )
{
wxDC *drawDc;
...
}

I am not familiar with the details of the code but it appears that the variable 
is set to something before it is used.  This is not modified code.

Please advise.
Thanks,
David








On Saturday, February 3, 2018, 4:01:05 AM EST, Phil Rosenberg 
<p.d.rosenb...@gmail.com<mailto:p.d.rosenb...@gmail.com>> wrote:


Hi David
Yes, that's exactly what you need to do.  can be pretty much any wxWidget 
window class, although I suggest using wxPanel. Using wxFrame works on Windows, 
but is apparently not good practice and some things don't work properly if you 
render directly to a wxFrame on Linux

Re: [Plplot-devel] [Plplot-general] More questions about install

[Phil Rosenberg]

Hi David
Yes, that's exactly what you need to do.  can be pretty much any wxWidget 
window class, although I suggest using wxPanel. Using wxFrame works on Windows, 
but is apparently not good practice and some things don't work properly if you 
render directly to a wxFrame on Linux.

In terms of a demo, check out wxPLplotDemo.cpp in the PLplot source code. It is 
in examples/c++

Phil


From: David Bergman <davidrberg...@yahoo.com>
Sent: Saturday, February 3, 2018 1:59:39 AM
To: plplot-devel@lists.sourceforge.net; Phil Rosenberg
Subject: Re: [Plplot-general] More questions about install

Phil,

I am at the point where I have been able to successfully build new projects for 
wxWidgets and PLplot independently from scratch, compile-link-run.
I copied some code from a wxPLplotDemo into a new GUI I've developed.

The following declaration gives an error,

wxPLplotwindow* plotwindow;

"argument list missing"

Should the format be

wxPLplotwindow etc

or is there still an issue with the wx drivers?  I have header, lib, and dll 
for wxwidgets functions, and enable_wxwidgets = ON was present in the cmake 
output.

Thanks in advance for our help.
David


On Friday, February 2, 2018, 12:14:04 PM EST, Phil Rosenberg 
<p.d.rosenb...@gmail.com> wrote:


Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN 
system variable before running cmake. Cmake should see that and automagically 
find wxWidgets and build that backend for the library along with the example.

Where things may get complicated is matching the library settings for Unicode, 
static vs dynamic runtimes and debug vs release builds. I'm not sure if these 
only need matching for static libraries or if dlls need these matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" 
<davidrberg...@yahoo.com<mailto:davidrberg...@yahoo.com>> wrote:
Phil,

Thanks for reaching out.
At this point the VS IDE build and install has never worked right, without 
massive errors.  The latest trial produced the release version without error 
but not the debug.

Following the instructions for a command line build, with help from Arjen, in 
windows (not Cygwin) produced a directory without errors.  The IDE build and 
the command prompt build are significantly different in the content (in my 
opinion).

I've been able to build a VS project from scratch using PLplot headers and dll 
and it worked.  So, I'm counting that as a success.  I have not yet had a 
chance to do more complex plots, fully test the functions, or integrate with 
widgets which is my intent.  I may need more help in the future.

I will say that there was one dll that the VS compiler/linker said was 
corrupted but I don't recall which one.
Just to get past it and get something working I deleted this from the project.  
It may come back to bite me later.

David



On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg 
<p.d.rosenb...@gmail.com<mailto:p.d.rosenb...@gmail.com>> wrote:


Hi David
I would have gotten involved in this thread earlier if I had realised it had 
moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for just 
reading the title and not the text.

I always use the visual studio IDE, I don't know if that is the route you ended 
up going down. Have you found the instructions at https://sourceforge.net/p/ 
plplot/wiki/Configure_PLplot_ 
for_the_Visual_Studio_IDE/<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>?
 They are a little out of date, but I don't think much has changed.

Phil

On 26 January 2018 at 14:57, David Bergman via Plplot-general 
<plplot-general@lists. 
sourceforge.net<mailto:plplot-gene...@lists.sourceforge.net>> wrote:
That worked.  Are there any good tutorials for using this with wxWidgets and 
VC++?
I think I need to set up the wxWidgets driver.
You may hear from me again...
David


On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus 
<arjen.mar...@deltares.nl<mailto:arjen.mar...@deltares.nl>> wrote:



Hi David,



That is easier – did you install the stuff via “nmake install” or are you 
working from the build directory?



That is what I usually do and then I have to expand the PATH environment 
variable:



set PATH=d:\plplot-build-dir\dll;% PATH%

cd examples\cxx

x01.exe



Fill in the right directory for “plplot-build-dir” above.



Regards,



Arjen



From: David Bergman [mailto:davidrbergman@yahoo. 
com<mailto:davidrberg...@yahoo.com>]
Sent: Friday, January 26, 2018 3:34 PM
To: Arjen Markus
Cc: Plplot-general@lists. 
sourceforge.net<mailto:plplot-gene...@lists.sourceforge.net> 
(plplot-general@lists. 
sourceforge.net<mailto:plplot-gene...@lists.sourceforge.net>)
Subject: Re: RE: RE: [Plplot-general] More questions about install



Arjen,

Thanks, that worked to get past this hurdle.  nmake and 

Re: [Plplot-devel] [Plplot-general] More questions about install

[Phil Rosenberg]

Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN
system variable before running cmake. Cmake should see that and
automagically find wxWidgets and build that backend for the library along
with the example.

Where things may get complicated is matching the library settings for
Unicode, static vs dynamic runtimes and debug vs release builds. I'm not
sure if these only need matching for static libraries or if dlls need these
matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" <davidrberg...@yahoo.com> wrote:

> Phil,
>
> Thanks for reaching out.
> At this point the VS IDE build and install has never worked right, without
> massive errors.  The latest trial produced the release version without
> error but not the debug.
>
> Following the instructions for a command line build, with help from Arjen,
> in windows (not Cygwin) produced a directory without errors.  The IDE build
> and the command prompt build are significantly different in the content (in
> my opinion).
>
> I've been able to build a VS project from scratch using PLplot headers and
> dll and it worked.  So, I'm counting that as a success.  I have not yet had
> a chance to do more complex plots, fully test the functions, or integrate
> with widgets which is my intent.  I may need more help in the future.
>
> I will say that there was one dll that the VS compiler/linker said was
> corrupted but I don't recall which one.
> Just to get past it and get something working I deleted this from the
> project.  It may come back to bite me later.
>
> David
>
>
>
> On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg <
> p.d.rosenb...@gmail.com> wrote:
>
>
> Hi David
> I would have gotten involved in this thread earlier if I had realised it
> had moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for
> just reading the title and not the text.
>
> I always use the visual studio IDE, I don't know if that is the route you
> ended up going down. Have you found the instructions at
> https://sourceforge.net/p/plplot/wiki/Configure_PLplot_
> for_the_Visual_Studio_IDE/? They are a little out of date, but I don't
> think much has changed.
>
> Phil
>
> On 26 January 2018 at 14:57, David Bergman via Plplot-general <
> plplot-gene...@lists.sourceforge.net> wrote:
>
> That worked.  Are there any good tutorials for using this with wxWidgets
> and VC++?
> I think I need to set up the wxWidgets driver.
> You may hear from me again...
> David
>
>
> On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus <
> arjen.mar...@deltares.nl> wrote:
>
>
> Hi David,
>
>
>
> That is easier – did you install the stuff via “nmake install” or are you
> working from the build directory?
>
>
>
> That is what I usually do and then I have to expand the PATH environment
> variable:
>
>
>
> set PATH=d:\plplot-build-dir\dll;% PATH%
>
> cd examples\cxx
>
> x01.exe
>
>
>
> Fill in the right directory for “plplot-build-dir” above.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* David Bergman [mailto:davidrbergman@yahoo. com
> <davidrberg...@yahoo.com>]
> *Sent:* Friday, January 26, 2018 3:34 PM
> *To:* Arjen Markus
> *Cc:* Plplot-general@lists. sourceforge.net
> <plplot-gene...@lists.sourceforge.net> (plplot-general@lists.
> sourceforge.net <plplot-gene...@lists.sourceforge.net>)
> *Subject:* Re: RE: RE: [Plplot-general] More questions about install
>
>
>
> Arjen,
>
> Thanks, that worked to get past this hurdle.  nmake and nmake install
> worked.
>
> Frankly, I'm not sure what state plplot is in but I tried running an
> example exe and got an error message that plplotcxx.dll is not installed on
> my computer.
>
> However, this *.dll does exists in the dll folder.
>
> How does that work?
>
> David
>
>
>
>
>
> On Friday, January 26, 2018, 8:15:24 AM EST, Arjen Markus <
> arjen.mar...@deltares.nl> wrote:
>
>
>
>
>
> Hi David,
>
>
>
> I was a bit hasty, I think – the cairo device driver actually consists of
> a whole slew of them and you would have to set all of them to off to avoid
> the cairo device (things like PLD_wincairo and PLD_epscairo). If I read the
> CMake files correctly, then you should be able to turn off that family of
> devices by -DDEFAULT_NO_CAIRO_DEVICES=ON. (I hope I am right this time)
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* David Bergman [mailto:davidrbergman@yahoo. com
> <davidrberg...@yahoo.com>]
> *Sent:* Thursday, January 25, 2018 2:12 PM

Re: [Plplot-devel] Issues with locate mode for the non-IPC3 case

[Phil Rosenberg]

On 7 October 2017 at 02:14, Alan W. Irwin  wrote:
> Hi Phil:
>
> I just discovered on Linux that your IPC3 workaround does allow
> -locate mode for example 1 to work perfectly for mouse clicks.  (IPC3
> locate mode key hits are not implemented yet.) But I also think that
> workaround should not be necessary, and the fundamental problem is
> when I originally implemented IPC3 locate mode I used the non-IPC3
> version of wxPlFrame::ReadTransmission to model what the IPC3 version
> of that routine should do in locate mode, but it turns out that is a
> flawed model!  So it is no wonder that you had to implement a
> workaround to get locate mode to work at all for the IPC3 case.
>
> Here are the current (master HEAD) problems with locate mode for the
> non-IPC3 case as demonstrated when I run
>
> examples/c/x01c -dev wxwidgets -locate
>
> on Linux.
>
> 1. The initial wxPLViewer response is always a blank screen.
>
> 2. Furthermore, initial blind mouse clicking on the position of
> viewports 2, 3, and 4 gets no response at all.  Blind clicking on the
> (upper-left) position of viewport 1 does typically get a response (but
> sometimes only after several clicks), and if I keep clicking
> eventually the actual plot appears, and then after that clicking on
> viewports 2, 3, and 4 finally begins to work.

Just tested the latest master head on Windows and it works perfectly.
Not sure why it would be different on Linux.
>
> 3. In no case have I gotten key hits to work (even though there is
> code to handle that case for the non-IPC3 version of
> wxPlFrame::ReadTransmission).
>

You are correct, key presses don't work on Linux, that is due to a
difference between Linux and windows in ter,s of event capture that I
wasn't aware of when I wrote the viewer. It is on my fix list, but
feel free to add it to the bug tracker so I don't forget.

> My guess is most or all of symptoms 1 and 2 are due to some screwup
> with the way events are being handled in the non-IPC3 case, and I
> likely propagated those same problems to the IPC3 side of things when
> I implemented the IPC3 version of locate mode. I have no explanation
> as to why hitting keys gets no response (symptom 3) for the non-IPC3
> case.
>
> In any case, I hope you are willing to fix the above set of non-IPC3
> issues because once they are solved I believe I should be able to
> quickly follow up with a reliable IPC3 variant using your corrected
> non-IPC3 implementation as a model.
>
> 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

Re: [Plplot-devel] Run-time issue on Linux (wxWidgets 3.0.2) that was introduced for commit e4fb932 or later.

[Phil Rosenberg]

Hi Alan
Try it now. Fingers crossed :-)

On 6 October 2017 at 20:44, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-05 20:44-0700 Alan W. Irwin wrote:
>
>> On 2017-10-06 00:19+0100 Phil Rosenberg wrote:
>>
>>> This is a GCC vs Visual Studio difference I have seen before. I think
>>> my latest commit should have fixed it, but I don't have access to a
>>> linux system right now to test on.
>>
>>
>> Hi Phil:
>>
>> Your commit got rid of this Linux build issue for both
>> DPL_WXWIDGETS_IPC3=ON and
>> OFF.  Thanks for the quick fix!
>
>
> Hi Phil:
>
> I spoke a bit too soon since your commit 3379c4e (current master HEAD)
> solved the build error introduced by commit e4fb932, but it turns out
> there is also currently a wxwidgets run-time error with master HEAD
> i.e., the following failed assert is generated:
>
> software@raven> examples/c/x02c -dev wxwidgets
> ../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in GetWidth():
> invalid bitmap
>
> This also happens for std example 1 (and presumably all other standard
> examples) and whether DPL_WXWIDGETS_IPC3=ON or OFF.
>
> This run-time issue does not occur for the commit just
> preceding e4fb932 (i.e.,
>
> e4fb932^ = ff29053... Attempted workaround for wxPLViewer IPC3 hangs
>
> ) so the issue must have been introduced
> by commit e4fb932 or a later commit in the master branch.
> I cannot bisect this problem further because of the Linux build error
> that is fixed by current master HEAD, but if you can replicate
> the above failed assert on Windows, then git bisect should
> work for you to nail down which commit in the range from
> commit e4fb932 to master HEAD caused this current
> run-time issue.
>
> 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

Re: [Plplot-devel] wingcc and wingdi build bugs

[Phil Rosenberg]

Given that the libraries in question are in the standard c and C++
libraries. I just tested to see what the impact is of simply
commenting out the checks for these two libraries.

The result is that wingcc is accepted onto the driver list, appears in
my plplot VC++ project, everything builds correctly and I can run the
examples and select the wingcc device and everything runs fine.

Given that this is the case is there even a need to check for these
libraries? Or is this test needed for Cygwin or minGW builds?

I also did a quick google and spotted this bug report
https://cmake.org/Bug/view.php?id=15831. I think the gist of it is
that find_library will only search in Windows SDKs that are at least
as old as the one used to build that version of Cmake. This seems a
bit daft to me as it forces upgrade whenever a new SDK is released - I
know in the past Alan has mentioned the need to not upgrade due to a
bug in a release, but that may not be an option if this is the case.
Again maybe this suggests that we should simply not use find_library
and simply assume that these libraries will be included in with the
standard libraries.

Phil

On 5 October 2017 at 22:42, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-05 09:10+0100 Phil Rosenberg wrote:
>
>> On 5 October 2017 at 04:10, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
>> wrote:
>>>
>>> The cmake messages above come from cmake/modules/wingcc.cmake and the
>>> first part of the relevant logic is
>>>
>>>   find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH}
>>> ${BORLANDLIBPATH})
>>>   if(GDI32_LIBRARY)
>>>   find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
>>> ${BORLANDLIBPATH})
>>>   endif(GDI32_LIBRARY)
>>>
>
>> gdi32.dll and comdlg32 are both in the standard system directory
>> c:/windows/system32/
>
>
>>> If both those libraries are installed on your system but in a
>>> non-standard location that CMake doesn't know about, then
>>> you may have to give CMake a hint where they are by setting
>>> CMAKE_LIBRARY_PATH appropriately.
>
>
> Hi Phil:
>
> One thing I noticed from your previous post that included all the
> information from cmake was your cmake version was 3.7.1. My impression
> is there has been a lot of churn in the various Windows IDE generators
> since 3.7.1 due to lots of bug fixing so this issue might be solved
> simply by downloading and using the latest binary version of CMake
> (3.9.4) directly from Kitware.
>
> But if you would prefer to stick to 3.7.1 for now or if 3.9.4 still
> has the same symptoms, then from the above collection of information I
> suggest you add c:/windows/system32/ to the CMAKE_LIBRARY_PATH
> information you already have (on Linux the format is a colon-separated
> list of library locations, but on Windows that may be a
> semicolon-separated list), and I am virtually positive that will solve
> the library finding issue for wingcc.  And if you set -DPLD_wingdi=ON,
> it should also solve it for wingdi (since that device uses the same
> libraries and same library finding logic as wingcc).
>
> By the way I am virtually positive that if CMake cannot find these
> standard system libraries in one of the expected standard locations
> without user help via CMAKE_LIBRARY_PATH, then that is a clear CMake
> bug (likely for the particular generator you are using). So if you
> confirm that this bug still persists with 3.9.4 directly downloaded
> from Kitware, then to help other users in your position, I plan to
> follow up with the CMake developers about this bug, but before
> starting that discussion I will need to know the exact
> generator you are using for your Windows IDE.
>
>
> 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

Re: [Plplot-devel] Commit e4fb932 introduced a wxPLViewer build bug on Linux (wxWidgets 3.0.2)

[Phil Rosenberg]

This is a GCC vs Visual Studio difference I have seen before. I think
my latest commit should have fixed it, but I don't have access to a
linux system right now to test on.

Phil

On 5 October 2017 at 22:33, Alan W. Irwin  wrote:
> Hi Phil:
>
> The wxwidgets-related parts of my cmake output are
>
> software@raven> grep -i wx cmake.out
> -- Found wxWidgets:
> -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0
> (found suitable version "3.0.2", minimum required is "3.0.0") --
> wxWidgets_FOUND : TRUE
> -- wxWidgets_INCLUDE_DIRS  :
> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0;/usr/include/wx-3.0
> -- wxWidgets_LIBRARIES :
> -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0
> -- wxWidgets_LIBRARY_DIRS  : /usr/lib/x86_64-linux-gnu
> -- wxWidgets_DEFINITIONS   : _FILE_OFFSET_BITS=64;WXUSINGDLL;__WXGTK__
> -- wxWidgets_DEFINITIONS_DEBUG : -- wxwidgets_COMPILE_FLAGS =
> -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0
> -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ --
> wxwidgets_LINK_FLAGS =
> -pthread;/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so;/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so
> -- WARNING: The test_octave_wxwidgets target can be run independently but
> does not
> DRIVERS_LIST:
> cairo;qt;mem;ntk;null;pdf;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;xwin
> DEVICES_LIST:
> memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;xcairo;epsqt;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;ntk;null;pdf;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;xwin
> ENABLE_wxwidgets:   ON
>
> Note especially my wxWidgets library version (3.0.2) because I think
> that may be relevant to this build bug.
>
> The compressed version of wxPLViewer.out that shows the build bug is
> attached
> where that file was created with
>
> make VERBOSE=1 wxPLViewer >& wxPLViewer.out
>
> Those results were for commit 476ce73 (current master HEAD) on
> Linux.  I just did a git bisect, and the first commit that introduced
> this issue was actually
>
> e4fb932... Set the option of a render delay after resizes on
> wxPLplotwindows.
>
> The above results were for the -DPL_WXWIDGETS_IPC3=OFF case,
> but there are similar (and possibly the same) issues for the
> -DPL_WXWIDGETS_IPC3=ON (default) case so whatever the problem
> is, it is likely common to both the IPC3 and non-IPC3 cases.
>
> Since presumably you did a successful build test yourself for commit
> e4fb932 or after, my best guess is this issue has to do with our
> differing wxWidgets library versions (3.0.2 for me and 3.1.0 for you).
> Since I believe you throughly understand the differences between 3.0
> and 3.1, I hope the issue is due to that difference and will therefore
> be easier for you to fix.
>
> 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

Re: [Plplot-devel] wingcc and wingdi build bugs

[Phil Rosenberg]

On 5 October 2017 at 04:10, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-05 00:57+0100 Phil Rosenberg wrote:
>
>> The my cmake command and its output are attached. I noted particularly the
>> lines
>>
>> -- Looking for gdi32 header and library
>> -- Looking for gdi32 header and library - not found
>> -- WARNING: Setting PLD_wingcc to OFF.
>>
>
>> I do set the cmake lib directory in my command to point it to the
>> location of shapelib, I don't know if that affects anything.
>
>
> Setting CMAKE_LIBRARY_PATH to help CMake find shapelib should not
> interfere with CMake's ability to find other libraries.
>
>> I am on Windows 10 64 bit.
>
>
> Thanks for that important information concerning your Windows version.
>
> The cmake messages above come from cmake/modules/wingcc.cmake and the
> first part of the relevant logic is
>
>   find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   if(GDI32_LIBRARY)
>   find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>   endif(GDI32_LIBRARY)
>
> If you read through the rest of the logic, the above output is telling
> you that either the gdi32 (gdi) or comdlg32 (dialog box) libraries
> cannot be found by CMake in standard system locations (as determined
> by CMake) for your platform.
>
> What does your cache file say about the variables GDI32_LIBRARY and
> (possibly) COMDLG32_LIBRARY?  From those values you can determine
> whether gdi32 was not found (and therefore comdlg32 never looked for)
> or gdi32 found but comdlg32 not found.

//Path to a library.
GDI32_LIBRARY:FILEPATH=GDI32_LIBRARY-NOTFOUND

There is no similar line for comdlg32.

However, both these libraries feature in the standard libraries

//Libraries linked by default with all C++ applications.
CMAKE_CXX_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
advapi32.lib

//Libraries linked by default with all C applications.
CMAKE_C_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
advapi32.lib

gdi32.dll and comdlg32 are both in the standard system directory
c:/windows/system32/

Dependency walker also shows that wxPLViewer uses both of them.



>
> If both those libraries are installed on your system but in a
> non-standard location that CMake doesn't know about, then
> you may have to give CMake a hint where they are by setting
> CMAKE_LIBRARY_PATH appropriately.
>
> However, I suspect instead the problem may be that the GDI API and
> Dialog Box API (which apparently are still used heavily on all Windows
> platforms
> including Windows 10) are located in libraries with names other than
> gdi32 and comdlg32 for your 64-bit Windows 10 platform.  If so, and
> you know those alternate names, then all you have to do is to change
> the above logic to
>
>   find_library(GDI32_LIBRARY NAMES gdi32  HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   if(GDI32_LIBRARY)
>   find_library(COMDLG32_LIBRARY NAMES comdlg32  comdlg32> HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   endif(GDI32_LIBRARY)
>
> @Arjen and Jim:
>
> Please chime in as well especially on the question of what library
> names provide the GDI API and Dialog Box API for the 64-bit Windows 10
> platform if Phil doesn't figure those names out before you.
>
>
> 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

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil Rosenberg]



On 5 October 2017 at 00:38, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-05 00:28+0100 Phil Rosenberg wrote:
>
>>>
>>> Once confirmed, then the obvious next question is why are we using a
>>> subset of the wxGraphicsContext class indirectly via the wxGCDC class
>>> rather than using the wxGraphicsContext class directly (which would
>>> provide important native gradient capability for the new wxwidgets
>>> device driver)?
>>>
>>
>> Ah, there are some good reasons. Because by using a wxDC we get access
>> to the following derived classes which render to the following formats
>> wxGCDC (GraphicsContext, which renders to memory or to a printer)
>> wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg,
>> tiff, png) or blitted to a window - on windows lower quality than GCDC
>> but hardware accelerated)
>> wxMetafileDC (Windows metafile)
>> wxMirrorDC (reflects allong x=y line and passes to another wxDC)
>> wxPostscriptDC (postscript files)
>> wxPrinterDC (Printing)
>> wxScreenDC (Rendering directly onto the screen rather than a window)
>> wxSVGFileDC (SVG file output)
>> wxPaintDC (Rendering to a window)
>> Plus quite possibly other people's custom wxDCs - for example I once
>> started writing a Direct2D wxDC, but never finished it.
>>
>> Thats kind of how OO programming works. A base class defines a common
>> structure and the derived classes expand that base structure. But if I
>> do not care what kind of DC I am working with then I just request a
>> wxDC* and use just that common base structure can deal with all the
>> derived classes equally. Then when I call wxDC->DrawRectangle() I
>> neither know nor care whether that writes text to a ps file, sends a
>> command to a printer or sets pixels in memory.
>>
>> As it happens when I slimmed things down to just accepting wxDCs in
>> the wxWidgets driver, the wxGCDC had just become available which was
>> brilliant, but either wxGraphicsContexts were not able to render to a
>> printer or I wasn't aware of that option. So those things swung me in
>> favour of wxDC over wxGraphicsContext.
>>
>> So having access to all the derived classes is one reason. The other
>> is that if we swapped to using a wxGraphicsContext we would silently
>> break everyone's code because of our casting of a void* to a wxDC,
>> that would instead get cast to a wxGraphicsContext, this would just
>> generate segfaults in all our users' code. The final reason is time. I
>> don't have time to rewrite the driver again using wxGraphicsContext
>> and I deliberately went for only wxDC at the last rewrite because
>> wxGCDC had become available and it halved the maintenance time
>> compared to having two separate backends.
>>
>> Lastly I will say that it is possible to check if we are dealing with
>> a wxGCDC and get access to the underlying wxGraphicsContext. I have
>> done this for text rendering because wxDC does not support arbitrary
>> affine transformations as needed for the 3D style text. But I really
>> don't want to make a habit of it. I'd much rather try the rotated
>> clipped rectangle and keep total consistency.
>>
>> Anyway that was a much longer explanation than intended ;-)
>
>
> That's fine.  I liked all those details in your good answer to my
> question.  :-)
>
>
> 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

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil Rosenberg]

>
> Once confirmed, then the obvious next question is why are we using a
> subset of the wxGraphicsContext class indirectly via the wxGCDC class
> rather than using the wxGraphicsContext class directly (which would
> provide important native gradient capability for the new wxwidgets
> device driver)?
>

Ah, there are some good reasons. Because by using a wxDC we get access
to the following derived classes which render to the following formats
wxGCDC (GraphicsContext, which renders to memory or to a printer)
wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg,
tiff, png) or blitted to a window - on windows lower quality than GCDC
but hardware accelerated)
wxMetafileDC (Windows metafile)
wxMirrorDC (reflects allong x=y line and passes to another wxDC)
wxPostscriptDC (postscript files)
wxPrinterDC (Printing)
wxScreenDC (Rendering directly onto the screen rather than a window)
wxSVGFileDC (SVG file output)
wxPaintDC (Rendering to a window)
Plus quite possibly other people's custom wxDCs - for example I once
started writing a Direct2D wxDC, but never finished it.

Thats kind of how OO programming works. A base class defines a common
structure and the derived classes expand that base structure. But if I
do not care what kind of DC I am working with then I just request a
wxDC* and use just that common base structure can deal with all the
derived classes equally. Then when I call wxDC->DrawRectangle() I
neither know nor care whether that writes text to a ps file, sends a
command to a printer or sets pixels in memory.

As it happens when I slimmed things down to just accepting wxDCs in
the wxWidgets driver, the wxGCDC had just become available which was
brilliant, but either wxGraphicsContexts were not able to render to a
printer or I wasn't aware of that option. So those things swung me in
favour of wxDC over wxGraphicsContext.

So having access to all the derived classes is one reason. The other
is that if we swapped to using a wxGraphicsContext we would silently
break everyone's code because of our casting of a void* to a wxDC,
that would instead get cast to a wxGraphicsContext, this would just
generate segfaults in all our users' code. The final reason is time. I
don't have time to rewrite the driver again using wxGraphicsContext
and I deliberately went for only wxDC at the last rewrite because
wxGCDC had become available and it halved the maintenance time
compared to having two separate backends.

Lastly I will say that it is possible to check if we are dealing with
a wxGCDC and get access to the underlying wxGraphicsContext. I have
done this for text rendering because wxDC does not support arbitrary
affine transformations as needed for the 3D style text. But I really
don't want to make a habit of it. I'd much rather try the rotated
clipped rectangle and keep total consistency.

Anyway that was a much longer explanation than intended ;-)

--
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

Re: [Plplot-devel] Update of the Wiki: obsolete information?

[Phil Rosenberg]

Good shout for updating these.
I notice that the Visual Studio IDE page that I wrote is woefully out
of date. I should sort that.

Phil

On 3 October 2017 at 07:50, Arjen Markus  wrote:
> Hi Alan, others,
>
>
>
> I have updated the Wiki page on the status of PLplot for the Windows
> platforms. I noticed however that we list information about the Borland and
> Open Watcom compilers, as well as the CGM device. I have not seen any
> mention of the two compilers or of the CGM device for many years now. Is it
> really convenient to continue displaying that information?
>
>
>
> By the way, I have added the newer languages to the overview and some of the
> newer components as well. I would appreciate comments – especially as far as
> the restrictions are concerned. If someone can point me to the missing
> components for Ocaml for instance or to a D compiler for Windows platforms,
> that would be great.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
> --
> 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
>

--
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

[Plplot-devel] xor mode and the buffer

[Phil Rosenberg]

Currently and rendering performed in xor mode is not recorded to the
buffer. I can understand why this would be the case as xor mode is
often used for rendering temporary lines then erasing them. However,
because wxPLViewer relies on the buffer for all its rendering this
means that it cannot support xor rendering. Does anyone have any
thoughts on the possibility of putting xor mode drawing in the buffer?
Or maybe making it an option? There are alternatives, but all of them
are significantly more conplex then simply logging xor rendering in
the buffer. Perhaps this could be a device option?

--
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

[Plplot-devel] Fwd: Returned mail: see transcript for details

[Phil Rosenberg]

Resending as I got a wierd unable to deliver message - i tink some
email address confusion happend. see below

-- Forwarded message --
From: Phil Rosenberg <p.d.rosenb...@gmail.com>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: plplot_de...@beluga.phys.uvic.ca
Bcc:
Date: Wed, 4 Oct 2017 12:11:48 +0100
Subject: Re: Some remaining wxwidgets inefficiency concerns for
examples 17 and 08
On 4 October 2017 at 05:54, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-03 23:44+0100 Phil Rosenberg wrote:
>
>> On Windows the fill test took 5 seconds using the old comms method and
>> 12 with the new. That's with optimisations turned on and I just timed
>> it with my phone stopwatch from the point where I hit enter after
>> choosing the driver.
>>
>> Interestingly I ran the viewer in a profiler to see why the
>> differences. Running the 3sem version first, it spent almost all its
>> time in a GDI rendering function, so no reason to think that the
>> different comms would make any difference. However, when I profiled
>> the old comms method, the profiler showed that the viewer spent all
>> it's time in a different GDI rendering function - this time called
>> NtGDIPolyPolyDraw. I saw something in wxWidgets the other day. This
>> was a function also called something like PolyPolygonFill and it said
>> that using this function plotting many polygons at once was faster
>> than plotting them all individually. So I am going to guess that GDI
>> maybe has some runtime optimisation or something and it was able to
>> better optimise the old comms than the new 3sem one. Maybe the
>> polygons arrive more rapidly?
>
>
> That's an interesting comparison, and it sure is a surprise that the
> IPC method affects how the GDI rendering is optimized.  My bet is it
> has nothing to do with specifically how the data are transmitted and
> assembled, and instead that difference in GDI rendering optimization
> is due to some "minor" difference in the code paths between IPC3 and
> non-IPC3 case on the viewer side.  In other words, instead of looking
> at transmitBytes and receiveBytes details, I think you should be
> looking for IPC3 and non-IPC3 differences in utils/wxplframe.cpp
> concerning how wxPlFrame::ReadTransmission() is called and also the
> large number of IPC3 versus non-IPC3 code-path differences within that
> routine.
>
> Since the above is an interesting comparison I have decided to add
> it to my results as well.
>
> Just to be clear about nomenclature,
>
> IPC3 wxwidgets is what I previously called default wxwidgets and which you
> have called new comms.  You get that by default or by
> specifying -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON
>
> The non-IPC3 wxwidgets result I have added is what you have called
> old comms.  You get that by specifying -DOLD_WXWIDGETS=OFF
> -DPL_WXWIDGETS_IPC3=OFF
>
> The old wxwidgets result corresponds to Werner's wxwidgets-related
> software as updated by you until you decided to do completely rewrite
> that software.  You get that by specifing -DOLD_WXWIDGETS=ON
>
> So here is my old timing result table with non-IPC3 wxwidgets timings added
> where those added timings are defined in exactly the same way and with
> the same compiler options as the others.
>
> device  plline testplfill test
> IPC3 wxwidgets  26  seconds32  seconds
> non-IPC3 wxwidgets  27  seconds32  seconds
> old wxwidgets   18  seconds30  seconds
> xcairo  1.4 seconds2.2 seconds
> qtwidget1.5 seconds1.6 seconds
> xwin9.5 seconds3.4 seconds
>
> So on Linux there is no significant measured time difference between
> what you call new comms (IPC3) and old coms (non-IPC3) contrary to
> your results on MSVC Windows.
>
> So just one timing comparison like you did on a given platform is
> tricky to generalize, and to get a better idea of what is going on for
> a given platform it is a good idea to get as many comparisons as
> possible. Therefore, could you please fill out a similar table to the
> above with the first 3 devices the same and the last two for wingcc
> and wingdi?  For example, if the three wxwidgets variants are roughly
> the same speed as wingcc and wingdi, then it is likely there is
> some remaining efficiency issue that just occurs for the Linux case.
> But if on your platform all wxwidgets variants are roughly an order of
> magnitude slower
> than wingcc and wingdi, then we likely have a cross-platform efficiency
> issue
> with -dev wxwidgets.

For some reason I cannot build wingcc or wingdi, they do not come up
as enabled on my system when I run cmake. I have n

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

On 3 October 2017 at 22:01, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
>>> Hi Alan
>>> I have been trying to work through your semaphore code, but I'm afraid
>>> I just don't quite get it.
>>>
>>> At the heart of this bug is the fact that receiveBytes() should be
>>> able to accept a timeout for waiting for the semaphore to unlock and
>>> instead of being void it should return the number of bytes it actually
>>> read.
>>>
>>> When I tried to implement this I just kept getting deadlocks because
>>> I'm not really sure how it all works.
>>
>>
>> Hi Phil:
>>
>> Because you are having trouble understanding the transmitBytes and
>> receiveBytes design, I think the best thing to do is for me to look
>> closely at the deadlock scenario you have described previously to see
>> if the current design answers it.  And if it doesn't, I will modify
>> transmitBytes and receiveBytes appropriately.  But this all will take
>> some substantial time on my part because I have other PLplot issues
>> (such as the cross-talk between streams that some interactive devices
>> show for example 14) on my plate right now.
>>
>> Meanwhile, you did say you had some sort of fix for locate mode
>> which you (much earlier in the recent discussions between us) described as
>>
>>> 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.
>
> Yes, plus a full fix for the old style comms. I have also realised
> that I am not correctly filling in the state variable for the locate
> info, so example 20 is still not quite working as it should. However I
> am having some trouble capturing the mouse button release. Once I have
> that worked out I will push the changes.
>
>>
>>
>> But you were reluctant to push those changes at that time, and I don't
>> think you have done so since.  If these changes do not involve the
>> introduction of timed waits or modifications to transmitBytes and
>> receiveBytes is there any reason to not push them? But if they do
>> involve such changes (e.g., to work around the deadlock you think is
>> there), then please don't push them and send me the patch instead to
>> help educate me about that issue.
>
> Yes it's a workaround rather than a proper fix. There really does need
> to be a timeout when the viewer checks for more data otherwise it
> causes all sorts of problems with possible deadlocks and also just
> unresponsive windows, i.e. resizes won't work and windows won't close
> while the viewer is waiting for the semaphore. You can see the
> deadlock by running example 20 with -nosombrero (you need this as
> there is another problem that will be fixed by the commit I mentioned
> above). You will find both sides of the communication hang. You can
> also uncomment the #define WXPLVIEWER_DEBUG line in wxWidgets_dev,
> then run x20c in a debugger - it will give you the command to run
> wxPLViewer in another debugger instance so you can see the point at
> which the hang occurs. Basically the core code is sat waiting for the
> locate data and the viewer has carried on repeatedly checking for new
> data so cannot actually collect the locate data.

I have just commited the workaround. But sadly it turned out not to be
very reliable. I'm not sure why. I am now sometimes able to get past
page 2 of example 20, but sometimes it hangs before I can leave and
sometimes it hangs later in the sequence. The non-IPC3 method is
currently working perfectly with locate.

--
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

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil Rosenberg]

On 3 October 2017 at 18:00, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-03 11:24+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> It may be possible to do as you said with a clip region and an affine
>> transform. I did consider this but I am not sure if the gradient gets
>> transformed or just the polygon shape. I would have to check.
>>
>> Regarding inheritance, you have the correct syntax. wxDC and
>> wxGraphicsContext are pretty close to top level classes so only
>> inherit from wxObject, which many wxWidgets classes inherit from and I
>> think it basically allows conversion between classes and strings which
>> specify the class name. If you look in the docs,
>> e.g.http://docs.wxwidgets.org/3.1/classwx_d_c.html, there is usually
>> an inheritance diagram. You have access to all the functions towards
>> the base of the tree, but the magic of C++ is that the behaviour of
>> some of the functions can be redefined towards the branches of a tree
>> by using the virtual specifier. So for example wxDC has a virtual
>> function DrawLines. So if I have a pointer to a wxDC I can always call
>> myDcPointer->DrawLines(/*params*/). But then if that pointer actually
>> points to an inherited class then the inherited class's version of
>> that function is called, so a wxPostscriptDC would write the vector to
>> the file, a wxMemoryDC would work out which pixels need shading and
>> shade them, etc.
>
>
> Hi Phil:
>
> I don't claim to understand everything you have said above in your
> second paragraph, but if the upshot is there are C++ ways to give us
> access to all wxWidget library methods regardless of the class they
> are in, then I suggest the most promising way forward (since the
> documentation does not mention any limitations on this brush) is
> likely to be to use wxGraphicsContext::CreateLinearGradientBrush
> rather than wxDC::GradientFillLinear (which does have many documented
> limitations).

No, sadly it does not. I can only access functions that are in wxDC.
wxGraphicsContext is neither a parent nor a child class to wxDC, it is
totally unrelated.
The wxGCDC class is a child of wxDC. It takes wxDC commands and then
calls equivalent wxGraphicsContext commands. This is how we make use
of the wxGraphicsContexts rendering.

--
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

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

Hi Alan
I have been trying to work through your semaphore code, but I'm afraid
I just don't quite get it.

At the heart of this bug is the fact that receiveBytes() should be
able to accept a timeout for waiting for the semaphore to unlock and
instead of being void it should return the number of bytes it actually
read.

When I tried to implement this I just kept getting deadlocks because
I'm not really sure how it all works.

Can I also just check, in the end what was wrong with the previous
comms that I put in place? Didn't we eventually find that the source
of the delays was the random number generator for determining the name
of the shared memory and nothing to do with the actual comms?

On 3 October 2017 at 09:07, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
>>
>> It is good that you are doing some critical thinking about my bytes
>> transmission logic this way.  However, it appears you are referring to
>> the case where there are two separate but simultaneous uses of IPC
>> (one to send an array of data from core to viewer and one to send an
>> array of data from viewer to core).
>
> Hi Alan
> Actually I am talking about the opposite case. Both core and viewer
> make a receive request. In both cases the receiveBytes function will
> not return until the data is received, but the other party can never
> send it because it is also sat in the receiveBytes function.
>
> Here what happens is the core sends a locate command and calls
> receiveBytes waiting for a response.
>
> The viewer receives the locate command and flags this so that we
> capture the next mouse click, however before that happens the timer
> triggers the viewer to check for some more data, it calls receiveBytes
> then sits waiting for data. But of course the core won't send any data
> until it has received the locate data.
>
> The result is deadlock and the viewer hangs.
>
> The proper fix should be that there is an option in receiveBytes to
> return immediately if there is no data to grab. This option should
> always be used by the viewer to avoid both this kind of deadlock, but
> also to avoid hangs when the core is very busy - don't forget that the
> user program might be doing some very intense stuff in between
> plotting commands.
>
> Phil

--
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

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

[Phil Rosenberg]

My best guess to this would be that every time new data is added to
the plot the wxPLViewer gets some new data and probably then calls
plreplot(). This then replots all the data from the beginning of the
stream including all the data that has previously been cleared and all
the clears. Whereas other plots probably just add the new data onto
the existing plot.

If this is the case then really the only fix for this inefficiency
would be an API change to allow plotting only part of a buffer or some
smart parsing of the buffer by plreplot to not render data before a
clear, but because clears are subpage specific and the current subpage
is not recorded anywhere this is a very large bit of work. In fact I
would go as far as suggesting that the amount of time that we would
spend resolving this issue might be orders of magnitude longer than
the total amount of time all our users would spend waiting because of
this inefficiency!

On 3 October 2017 at 08:05, Alan W. Irwin  wrote:
> On 2017-10-03 00:20+0100 p.d.rosenb...@gmail.com wrote:
>
>> Hi Alan
>>
>> Are those timing values from the console side or the viewer side?
>
>
> I failed to state how I measured time for the example 17 case but that
> was done essentially identically to what I stated for the example 8
> case, i.e., total time from start of example (core) to finish of all
> rendering.  So for new wxwidgets it is a combination of short core
> time plus long wxPLViewer rendering time, while for old wxwidgets it
> is total core time alone because wxPLViewer is irrelevant in that case
> (i.e., core does its own rendering).
>
> [out of order]
>>
>> I'm not sure what the cause is right now, but I'll run those examples
>> through a profiler and see.
>
>
> Thanks!
>
>
> 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

Re: [Plplot-devel] Slave displays

[Phil Rosenberg]

Yes I agree

On 3 October 2017 at 10:24, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-03 00:50+0100 Phil Rosenberg wrote:
>
>> I think I see how this works now.
>> Basically the example plots to both streams then execution halts while
>> it waits for the page to advance on the "master" plot. But this isn't
>> specifically due to coms between any of the streams, it is simply
>> because without setting plspause(0) execution hangs until the page
>> advances. Once enter is hit, the next page for both streams gets
>> rendered.
>
>
> I realize now that explanation is not complete, and I believe the
> following explanation clarifies matters.  Example 14 calls plspause(0)
> only for the second (slave) stream.  Because of that false argument
> that sets plsc->nopause to true (the same setting as you get with just
> one stream if you use the -np ("no pause") command-line option).  So
> this means there should be NO pauses at page end waiting for the event
> of the user to hit the enter key FOR the second slave stream, but
> there will be such pauses for the master stream. The key additioal
> point is the slave stream must halt in any case (at least when core is
> also doing the rendering) whenever plsstrm is called to switch from
> slave stream to he master stream.  So the behaviour for tk, xcairo,
> and qtwidget follows automatically from this with the master stream
> the only stream in charge of waiting for the enter key from the user
> at page end for the master stream.  So there must be some
> long-standing bugs (likely some event variable that should be stored
> in the pls->dev struct associated with the device but because it is
> not it is causing pause cross-talk between the master and slave
> streams) for the xwin and old wxwidgets devices (and possibly wingcc
> and wingdi as well).
>
> I will look into that side issue soon.  But please read on for my
> advice to get the new wxwidgets device driver to act the same way as
> the currently correct behaviour for the tk, xcairo, and qtwidget
> devices.
>
>> With wxWidgets however, when we reach the end of a page execution
>> doesn't stop.
>
>
> True for plsc->nopause true, but if plsc->nopause is false, the
> wxplViewer rendering does pause while waiting for the event of the
> user hitting the return key to complete the page and start the next
> one.  However, it is true that at the same time, I don't think
> the core stops, and I believe that is the key to this bug fix.
>
>> The plplot core code continues to execute and send the
>> commands to the wxPLViewer ready for rendering. This means the
>> execution just runs all the way through and the slave plot basically
>> disappears as it gets plotted.
>>
>> I'm not sure this behaviour is documented specifically anywhere. We
>> can force execution to pause while we wait for a page advance to
>> happen I guess. It's just a question of whether we want that or
>> whether we would prefer to just plough through all the commands and
>> have them sat ready to execute.
>
>
> If plsc->nopause is false (the usual case), interactive devices which
> are not the "new" wxwidgets deal with events in such a way that by
> definition (since there is no separate viewer) the core AND further
> rendering pauses at the end of each page to wait for the event of the
> user hitting the enter key.  So I strongly believe (now) that "new"
> wxwidgets should act the same
> way for the core, i.e., when wxPLViewer is pausing the rendering at
> the end of each page to wait for the event of the user hitting the
> enter key, the core should be waiting as well.
>
> In other words, what I think is happening for example 14 is the master
> stream core continues and that mistake allows the slave core just to
> continue as well (since the switch from slave stream to master stream
> just keeps on trucking with master stream core passing control back
> soon after to the slave stream core even though the wxPLViewer
> corresponding to the master stream (but not master stream core) is
> paused at page end waiting for the event of the user hitting the enter
> key.)
>
> So I predict this change will make new wxwidgets act correctly like
> tk, xcairo, and qtwidget for example 14.  I assume to make the core
> stream stop when the wxPLViewer corresponding to that stream is at
> page end and waiting for the event of the user hitting the return key
> means using transmitBytes in viewer and receiveBytes in core
> appropriately to send a command to the core to stop.  But it would
> take me a long time to implement that (because of low C++ skills and
> not much understanding of the w

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

>
> It is good that you are doing some critical thinking about my bytes
> transmission logic this way.  However, it appears you are referring to
> the case where there are two separate but simultaneous uses of IPC
> (one to send an array of data from core to viewer and one to send an
> array of data from viewer to core).

Hi Alan
Actually I am talking about the opposite case. Both core and viewer
make a receive request. In both cases the receiveBytes function will
not return until the data is received, but the other party can never
send it because it is also sat in the receiveBytes function.

Here what happens is the core sends a locate command and calls
receiveBytes waiting for a response.

The viewer receives the locate command and flags this so that we
capture the next mouse click, however before that happens the timer
triggers the viewer to check for some more data, it calls receiveBytes
then sits waiting for data. But of course the core won't send any data
until it has received the locate data.

The result is deadlock and the viewer hangs.

The proper fix should be that there is an option in receiveBytes to
return immediately if there is no data to grab. This option should
always be used by the viewer to avoid both this kind of deadlock, but
also to avoid hangs when the core is very busy - don't forget that the
user program might be doing some very intense stuff in between
plotting commands.

Phil

--
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

Re: [Plplot-devel] Slave displays

[Phil Rosenberg]

I think I see how this works now.
Basically the example plots to both streams then execution halts while
it waits for the page to advance on the "master" plot. But this isn't
specifically due to coms between any of the streams, it is simply
because without setting plspause(0) execution hangs until the page
advances. Once enter is hit, the next page for both streams gets
rendered.

With wxWidgets however, when we reach the end of a page execution
doesn't stop. The plplot core code continues to execute and send the
commands to the wxPLViewer ready for rendering. This means the
execution just runs all the way through and the slave plot basically
disappears as it gets plotted.

I'm not sure this behaviour is documented specifically anywhere. We
can force execution to pause while we wait for a page advance to
happen I guess. It's just a question of whether we want that or
whether we would prefer to just plough through all the commands and
have them sat ready to execute.

Phil

On 2 October 2017 at 23:30, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-02 16:10+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I've been going through the various wxWidgets bugs on the bug tracker.
>> The ones that remain are the rather more technical ones or the ones
>> that I'm not sure what the correct behaviour should be.
>>
>> In particular the slave display thing is a bit of a puzzle to me.
>> Searching for slave in the documentation doesn't yield any results and
>> all I see in example 14 is two streams used, the second of which has
>> had plspause( 0 ) called on it. Is that what sets up a slave display.
>> If so it really needs some documentation indicating what triggers a
>> slave display and how they should work.
>
>
> To Phil, Maurice, Hazen, Hez, and Andrew:
>
> @Phil:
>
> I don't understand the details about exactly what plspause does, but
> it does depend on an implementation in each individual interactive
> device driver so you are going to have to read the plspause parts of
> the source code for one or more other devices to make further progress
> on this bug.
>
> However, to help you to choose what to look at I did some further
> experiments.
>
> For the new wxwidgets device I still get the same incorrect behaviour
> as reported in the bug report.  That is, the slave plot GUI first
> displays a blank plot rather than the actual slave plot and then
> immediately dies.  Meanwhile, the primary plot GUI displays
> fine, and moves to the second page and exits if the user hit the enter
> key twice.  This result is the same both for -DPL_WXWIDGETS_IPC3=ON
> and OFF.  For the old wxwidgets device (-DOLD_WXWIDGETS=ON) the
> behaviour is exactly the same as -dev xwin. That is both primary and
> secondary master and slave GUI's display their respective plots, and
> if you hit the enter key on either of those two GUI's, BOTH plots
> advance a page (which is actually also incorrect behaviour, but at
> least you don't have the "blank page and die" behaviour for
> the slave that you get with new wxwidgets).
>
> So the xwin and old wxwidgets models are not quite the best ones to
> follow here for master/slave behaviour.  And I suspect that is also
> true of -dev wingcc and -dev wingdi because I think they modelled
> their plspause on -dev xwin.  But you should double-check that.
>
> Instead, you should be attempting to implement the same behaviour as
> demonstrated by any of the tk, qtwidget and xcairo
> devices;
> both master and slave GUI plots are displayed, but the enter key is a no-op
> for the slave
> GUI, and only for the master GUI does the enter key advance the pages
> for both GUI's and eventually exit the example.
>
> In sum, I suggest you look carefully at the old wxwidgets device code
> to solve the "blank plot and die" issue with the slave plot for new
> wxwidgets. Once that bug is solved, then I would follow exactly
> however either of our qtwidget or xcairo devices implement plspause to
> obtain the correct master/slave behaviour.  I am not suggesting you
> attempt to understand plspause parts of the -dev tk code because that
> device driver logic is tough to follow in my opinion.  But it is
> interesting that although the -dev tk logic uses important parts of
> the -dev xwin code it gets the master/slave behaviour correct while
> pure -dev xwin code does not achieve that.
>
> @Maurice:
>
> I believe plspause was implemented by you long ago and presumably tested
> by you on the interactive devices available to you (i.e, -dev xwin
> and -dev tk since our cairo and qt device drivers hadn't been
> implemented back then).  I would appreciate you commenting further
> and especially about the differences

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

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
>> 

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

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  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 

[Plplot-devel] Slave displays

[Phil Rosenberg]

Hi Alan
I've been going through the various wxWidgets bugs on the bug tracker.
The ones that remain are the rather more technical ones or the ones
that I'm not sure what the correct behaviour should be.

In particular the slave display thing is a bit of a puzzle to me.
Searching for slave in the documentation doesn't yield any results and
all I see in example 14 is two streams used, the second of which has
had plspause( 0 ) called on it. Is that what sets up a slave display.
If so it really needs some documentation indicating what triggers a
slave display and how they should work.

Phil

--
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

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

[Phil Rosenberg]

>
> The eofill setting is saved by the plbuf at a bop (see line 176 and 359 in 
> plbuf.c).
>
Hi Jim - These are changes I made over the weekend. I guess you're not
subscribed to get code change notifications or maybe you missed them
:-)


>
> I have noticed some inconsistencies in the mash-up of plbuf and drivers when 
> it comes to handling state and escape (e.g. plD_esc) functions.  Based on my 
> recollection of old graphics devices, I think I understand the difference 
> (state has to do with internal plplot and escape has to do with commands to 
> the graphic device) but with the way graphics devices have evolved we may 
> want to revisit the implementation (e.g. make sure no settings are getting 
> lost on a replot).

My understanding is the same. state commands change something that
plplot remembers - usually something that is saved in the PLStream,
whereas escapes are commands sent to the drivers to perform an action
- usually rendering. Always thought that was an odd name, when I think
of escape I think of escape sequences in text etc. I guess there is a
historical reason. I also guess that a number of things like setting
the rotation or clipping region or subpage or other things are really
changes of state, but don't go through that code. Again I guess these
are for historical reasons.

>
> The biggest weakness in plbuf is that what it thinks should be saved may not 
> match what is needed.  When working on the core and drivers, it is easy to 
> add a bit of state and not update plbuf.  There might be a way to make plbuf 
> be more aggressive in saving state information and restoring it when 
> replaying the buffer.  I can make the aggressiveness be a setting that a 
> driver can set it if it wants the current behavior—I am concerned that some 
> of the older drivers might have issues.

I actually think that now that the wxWidgets interactive driver (i.e.
the one that gets called from a command line application, rather than
what gets called when you pass in a wxDC) uses the buffer for all its
rendering, we now do rather a good job of keeping on top of these
things. The biggest problems have turned out to be, things that are
stored in PLStream, but don't go through the Plp_State code. The
things that I think still pose challenges are
1) Initialisation and beginning the first page - it can be that when
passing a buffer around we end up initialising more than once and this
has caused issues. I these are mostly sorted now though.
2) Resizing - the buffer stores the coordinates for rendering and the
sizes of text. But if we resize then we may want to scale the text
size, or keep the text size the same and keep the distance of labels
from the axis the same. Currently we keep the text size the same, but
they move relative to the axes.
3) Changes of aspect ratio - This can cause a big mess, especially for
rotated text on plots, axis label positioning and tick mark length.

Actually now that I have listed these, I am going to add 2 and 3 to
the bug tracker so they don't get totally forgotten.

Phil

--
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

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

[Phil Rosenberg]

On 1 October 2017 at 21:01, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2017-10-01 09:49+0100 Phil Rosenberg wrote:
>
> [Alan said]
>>>
>>> With regard to your remark concerning writing a plsfillrule() function
>>> and systematically using it throughout src/plargs.c, I wouldn't want
>>> to do that myself, but if you or Jim want to make such a change and it
>>> passes comprehensive testing, I certainly would not object.
>>
>>
> [Phil responded]
>>
>> I can add a new API function if you think it is useful, but I can only
>> propagate it as far as the C and C++ APIs, someone else would have to
>> propagate it to other languages as needed.
>>
>
> From what has been said, my impression is a plsfillrule() function is
> C-only functionality to make src/plargs.c easier to understand and use
> correctly. If that impression is correct there should be no need to
> propagate this functionality even to our C++ binding since all our bindings
> simply wrap the C plparseopts routine without knowing its
> internal implementation details. But please educate me if that
> impression is incorrect.
>

Hi Alan
I actually meant, do we want to add plsfillrule as an API function? It
feels more like it should be an API function rather than a command
argument. It would be little trouble to allow users to swap back and
forward between the two rules. But I have a feeling this functionality
is not used that often so maybe it's not worth the effort.

Phil

--
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

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

[Phil Rosenberg]

Fixed

My test for initialisation was incorrect.

On 1 October 2017 at 20:50, Alan W. Irwin  wrote:
> On 2017-09-30 19:22-0700 Alan W. Irwin wrote:
>
>> Anyhow, thanks very much for this fix, and I have changed the status
>> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.
>
>
> I have just discovered a really strange problem with your recent
> -eofill fix (commit b603fd22). The issue is that valgrind results on C
> and Fortran standard examples show no memory-management issues, and
> you would expect that good result would continue with all bindings
> since your commit made changes only to C language files associated
> with our core C library and not the bindings. However, for some
> strange reason your change does cause segfaults for all C++ examples
> and all devices that I have tried for those examples whenever the
> -eofill option is used.  There are no such issues when the -eofill
> option is not used.
>
> Here are typical valgrind results for the two cases where I
> have chosen to use one of our simpler C++ examples (x00)
> and one of our simpler devices (svg).
>
> software@raven> valgrind examples/c++/x00 -dev svg -o test.svg
> ==1930== Memcheck, a memory error detector
> ==1930== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==1930== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==1930== Command: examples/c++/x00 -dev svg -o test.svg
> ==1930== ==1930== ==1930== HEAP SUMMARY:
> ==1930== in use at exit: 0 bytes in 0 blocks
> ==1930==   total heap usage: 463 allocs, 463 frees, 148,933 bytes allocated
> ==1930== ==1930== All heap blocks were freed -- no leaks are possible
> ==1930== ==1930== For counts of detected and suppressed errors, rerun with:
> -v
> ==1930== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> software@raven> valgrind examples/c++/x00 -dev svg -o test.svg -eofill
> ==1931== Memcheck, a memory error detector
> ==1931== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==1931== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==1931== Command: examples/c++/x00 -dev svg -o test.svg -eofill
> ==1931== ==1931== Invalid read of size 8
> ==1931==at 0x5C3656E: plP_state (plcore.c:257)
> ==1931==by 0x5C24C42: opt_eofill (plargs.c:2845)
> ==1931==by 0x5C22BED: ProcessOpt (plargs.c:1140)
> ==1931==by 0x5C22A1D: ParseOpt (plargs.c:1068)
> ==1931==by 0x5C22779: c_plparseopts (plargs.c:935)
> ==1931==by 0x4E40719: plstream::parseopts(int*, char**, int)
> (plstream.cc:1283)
> ==1931==by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
> ==1931==by 0x400D92: main (x00.cc:79)
> ==1931==  Address 0x48 is not stack'd, malloc'd or (recently) free'd
> ==1931== ==1931== ==1931== Process terminating with default action of signal
> 11 (SIGSEGV)
> ==1931==  Access not within mapped region at address 0x48
> ==1931==at 0x5C3656E: plP_state (plcore.c:257)
> ==1931==by 0x5C24C42: opt_eofill (plargs.c:2845)
> ==1931==by 0x5C22BED: ProcessOpt (plargs.c:1140)
> ==1931==by 0x5C22A1D: ParseOpt (plargs.c:1068)
> ==1931==by 0x5C22779: c_plparseopts (plargs.c:935)
> ==1931==by 0x4E40719: plstream::parseopts(int*, char**, int)
> (plstream.cc:1283)
> ==1931==by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
> ==1931==by 0x400D92: main (x00.cc:79)
> ==1931==  If you believe this happened as a result of a stack
> ==1931==  overflow in your program's main thread (unlikely but
> ==1931==  possible), you can try to increase the size of the
> ==1931==  main thread stack using the --main-stacksize= flag.
> ==1931==  The main thread stack size used in this run was 8388608.
> ==1931== ==1931== HEAP SUMMARY:
> ==1931== in use at exit: 29,775 bytes in 265 blocks
> ==1931==   total heap usage: 314 allocs, 49 frees, 74,436 bytes allocated
> ==1931== ==1931== LEAK SUMMARY:
> ==1931==definitely lost: 0 bytes in 0 blocks
> ==1931==indirectly lost: 0 bytes in 0 blocks
> ==1931==  possibly lost: 0 bytes in 0 blocks
> ==1931==still reachable: 29,775 bytes in 265 blocks
> ==1931== suppressed: 0 bytes in 0 blocks
> ==1931== Rerun with --leak-check=full to see details of leaked memory
> ==1931== ==1931== For counts of detected and suppressed errors, rerun with:
> -v
> ==1931== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> Segmentation fault
>
> 1930 (without -eofill) shows perfect valgrind results while 1931 shows
> shows showstopping (segfault) memory management issues with -eofill.
>
> I hope you can figure out this peculiar issue with your fix because
> it has me completely stumped!
>
>
> 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
> 

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

[Phil Rosenberg]

>> Note that I have tested this up to the point of checking in the
>> debugger that the correct fill rule is recognised by the viewer and
>> the correct parameter is passed in to the wxWidgets fill function.
>> This definitely works correctly both with and without -eofill
>> specified for example 27. However I didn't spot a difference in the
>> output. Maybe you can check it if you know how it should look
>
>
> Hi Phil:
>
> I suspect you didn't go far enough into the pages of the example to
> encounter the fill results for the more complex figures. If you do
> that, e.g., page 19 of the example (see
>  which was
> generated with -dev pngcairo and the -eofill option), the result
> should have many holes in the fill region relative to the same page
> generated without the -eofill option.  If you don't see that
> difference on Windows, I feel that is likely due to a wxWidgets
> library bug on Windows since that difference does show up in the Linux
> case.
>
> Anyhow, thanks very much for this fix, and I have changed the status
> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.

I get output just like that image without the -eofill parameter. I
suspect that as you said this is a bug in wxWidgets on Windows. I'm
not exactly sure how the differences are supposed to manifest. If you
could send me a relatively simple polygon that should give different
output depending upon which rule is used and a description of what
should be different then I will generate a test case and submit a bug
report.

>
> With regard to your remark concerning writing a plsfillrule() function
> and systematically using it throughout src/plargs.c, I wouldn't want
> to do that myself, but if you or Jim want to make such a change and it
> passes comprehensive testing, I certainly would not object.

I can add a new API function if you think it is useful, but I can only
propagate it as far as the C and C++ APIs, someone else would have to
propagate it to other languages as needed.

--
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

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Phil Rosenberg]

Hi Mark, well spotted. Patch applied. Thanks for the contribution.

On 29 September 2017 at 11:00, Mark de Wever <m.de.we...@datawell.nl> wrote:
> Hi Phil,
>
> On 28.9.17 22:31, Phil Rosenberg wrote:
>>
>> I have just fixed the map plots. Apologies that this has taken
>> sooo long. The changes have just been pushed to the development
>> version and have been checked on my windows machine. Note that you
>> were correct also about there being an issue with using plmapfill. It
>> turned out that the type specified in the shapefile was overriding the
>> render type specified by the user.
>
>
> Thanks for the fixes.
>
> I just tested with HEAD and the polygon code no longer crashes.
>
> Next I wanted to test with a map with lines and no fill. Unfortunately
> plmapline also draws filled polygons. I did this test with the same
> shapefiles [1] as the original test.
>
> I assume it is caused by the code: src/plmap.c:324
> if ( shapetype == SHPT_NULL )
> {
> shapetype = fileShapeType;
> }
>
>
> The attached patch lets plmapline draw lines instead of filled polygons.
>
> I tested HEAD+patch and the coastal lines no longer disappear, so that issue
> is also fixed.
>
> I will do more testing next week, thanks again for the fixes.
>
>
> [1]
> http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
>
> Regards,
> Mark de Wever

--
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

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Phil Rosenberg]

Hi Mark and anyone else who is listening
I have just fixed the map plots. Apologies that this has taken
sooo long. The changes have just been pushed to the development
version and have been checked on my windows machine. Note that you
were correct also about there being an issue with using plmapfill. It
turned out that the type specified in the shapefile was overriding the
render type specified by the user.

While I was there I realised there was a problem with rendering
polygons that wrap round the whole globe such as Antarctica so that
should now be fixed too.

For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?

Phil

On 18 November 2016 at 10:41, Mark de Wever  wrote:
> Hi,
>
> Recently I ran into an issue with the plplot 5.11.1 on Windows. The plmap
> code seems to omit lines entirely when a part of the line is not visible.
> This only occurs when the line is not visible on the left hand side of the
> plot. When a part is not visible on the right hand side it is properly
> shown.
>
> At my Debian Stable system I use the system's 5.10.0 version. There the
> issue doesn't occur. (I noticed the plmap code has been rewritten between
> 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 5.11.1 and a
> recent master [d71e48], both have the issue.
>
> Attached a modified example 19 where the bug is shown. The first plot shows
> the entire coast of Ireland. The second plot should only omit a small part
> of the coast, but instead the entire coast has been removed. Only the
> internal border of Ireland remains visible. This seems to happen with all
> coast lines; I picked Ireland since it shows the bug nicely.
>
>
> Regards,
> Mark de Wever
>
> PS: It seems the old deprecated plmap code no longer shows a map (at least
> on Windows). I didn't investigate further, I just installed the shapelib
> library.
>
> PPS: There also seems to be another issue with a filled polygon map, but I'm
> still investigating. If it really is an issue, I'll report it.
>
> --
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

--
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

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Phil Rosenberg]

Hi Mark
Thanks for the reminder. I will definitely put as much effort as I can
into getting this sorted pre release.

Phil

On 24 July 2017 at 13:27, Mark de Wever  wrote:
> Hi Phil,
>
> I saw the release of 5.13 is being planned. I wondered whether it is
> possible to fix this issue before the release.
>
> Regards,
> Mark de Wever
>
>
> On 18.11.16 18:30, p.d.rosenb...@gmail.com wrote:
>>
>> Hi Mark
>> Thanks for the report. I'll have a look at your example over the weekend
>> and see if I can fix the issue.
>>
>> Phil
>>
>> Sent from my Windows 10 phone
>>
>> From: Mark de Wever
>> Sent: 18 November 2016 11:06
>> To: plplot-dev
>> Subject: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of
>> themap
>>
>> Hi,
>>
>> Recently I ran into an issue with the plplot 5.11.1 on Windows. The
>> plmap code seems to omit lines entirely when a part of the line is not
>> visible. This only occurs when the line is not visible on the left hand
>> side of the plot. When a part is not visible on the right hand side it
>> is properly shown.
>>
>> At my Debian Stable system I use the system's 5.10.0 version. There the
>> issue doesn't occur. (I noticed the plmap code has been rewritten
>> between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with
>> 5.11.1 and a recent master [d71e48], both have the issue.
>>
>> Attached a modified example 19 where the bug is shown. The first plot
>> shows the entire coast of Ireland. The second plot should only omit a
>> small part of the coast, but instead the entire coast has been removed.
>> Only the internal border of Ireland remains visible. This seems to
>> happen with all coast lines; I picked Ireland since it shows the bug
>> nicely.
>>
>>
>> Regards,
>> Mark de Wever
>>
>> PS: It seems the old deprecated plmap code no longer shows a map (at
>> least on Windows). I didn't investigate further, I just installed the
>> shapelib library.
>>
>> PPS: There also seems to be another issue with a filled polygon map, but
>> I'm still investigating. If it really is an issue, I'll report it.
>>
>>
>

--
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

Re: [Plplot-devel] Third proof of concept for the "exception handling" topic -- Further discussion

[Phil Rosenberg]

On 23 July 2017 at 12:27, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> Hi Phil:
>
> Here is further discussion of what you have said as opposed to the
> error report I sent you in my previous post concerning your 3rd
> iteration.
>
> Do keep in mind the possibility for the future that the memory
> allocation part of your commits are worthwhile in their own right and
> could be finished and landed on master much sooner than the rest of
> your commits that are concerned with implementation of C exception
> handling and use of that for handling our errors.

I'm not sure how useful they really are without exception handling.
Without such handling there is no location in the code where the array
of pointers to the allocated memory is reviewed and in addition the
best response to a failed allocation may not be a call to plexit (but
I guess mostly it would be).

>
> I suggested in my big e-mail to you early this week (Mon, 17 Jul 2017
> 14:59:00 -0700 (PDT)) concerning your second iteration a method of doing
> this using a list of plstream heap pointers.  Please respond to that
> suggestion.

When you said a list I'm not sure I understood. Do you mean a linked
list rather than an array?

>
> Also please respond to my suggestion (with appropriate code changes
> while I handle the CMake part) in that e-mail concerning
>
> #define PL_IMPLEMENT_EXCEPTION_HANDLING and
> #ifdef PL_IMPLEMENT_EXCEPTION_HANDLING
>
> On 2017-07-22 22:47+0100 Phil Rosenberg wrote:
>
>> [in that same e-mail] You asked why every API call required a PLTRY block.
>> You are correct
>> that actually they don't. Every API call that may result in a call to
>> plexit needs a PLTRY block.
>
>
> I initially didn't understand this explanation, but after _much_ too
> long a time considering various scenarios to explain my point of view
> the light finally dawned. Exception handling does not allow you to
> transfer control to arbitrary places in the code (a stupid assumption
> I was making). Instead, it merely allows you to unwind the call graph
> from the plexit call (in this case that is the only current use of
> PLTHROW in our source code) to return control to a routine potentially
> far up the call stack from there such as _any_ of the public API
> routines (as you said) that have a possible call to plexit somewhere
> lower down on their call graph.

Yes correct, we just unwind the stack to a certain point in the call
sequence (or whatever terminology you choose as you mentioned in your
ps and pps). This is good, because the user application is still sat
waiting for our API function to return. We don't want to jump to some
specific execution point, we need that function to return and for the
user to find out somehow that there has been an error.

>
> So sorry for my previous noise on this sub-topic, but
> now we are finally on the same page in this regard, I have some
> further questions and comments about your implementation of
> exception handling and how you are using that exception handling
> to deal with bad errors.
>
> * If you miss putting a PLTRY and PLCATCH block in one of those public
>   API cases where a potential call to plexit is somewhere lower on the
>   call graph, then what does the current code do?  Does it simply
>   crash (i.e., is that the potential cause of the serious issues I
>   have reported to you in my previous post) or do you handle that
>   internal error case by, e.g., emitting an "internal error: unhandled
>   exception" message followed by an exit?

I think that currently something very odd. The value of
pls->currentjumpbuffer used in PLTHROW would be either out of date or
NULL, so probably some sort of crash. This is why it is important that
every API entry function includes a PLTRY, PLCATCH, PLENDTRY sequence.
Of course we could set things up to check for this scenario, but then
what would we do? Call exit()? I had been trying to think if there was
a C method to check at compile time, but I cannot think of one (there
would be ways in C++ I think). But the API changes so infrequently
that I think just ensuring all API functions include the PLTRY,
PLCATCH, PLENDTRY code is probably okay - open to suggestions though.

>
> * What happens when an external application calls a "first" public API
>   which has another "second" public API lower down in its call graph
>   and even further down on the call graph of that second API occurs a
>   potential call to plexit? Then if plexit is called that will PLTHROW
>   control to the catch block of that second API rather than the first.
>   So for this particular call graph case for the first API this second
>   API needs to PLTHROW control to that first PLCATCH block rather than
>   simply returning.  And, of course, since tha

Re: [Plplot-devel] First proof-of-concept versions of PLplot "memory allocation" and "exception handling" topics

[Phil Rosenberg]

Just a note to say that as far as I can tell from the Visual Studio
memory tools, it appears that the memory leak is wxWidgets related and
not to do with the exception testing. The actual data in the leaked
memory appears to be class information text for wxWidgets dynamic
casting of pointers and occurs when using the null device, so I have a
feeling it is a wxWidgets bug, not a plplot bug. I'd be interested to
know what you see on Linux Alan.

Phil

On 17 July 2017 at 11:31, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> Hi Alan
> Please find attached a new patch series.
>
> I should have fixed the segfault issue. Note I have done some rebasing
> so you will probably need to create new branches. I think there is a
> memory leak somewhere. I will look into this.
>
> But you may have something you can play with to test a bit better now.
> I have added specific comments below.
>
>
>> I used "git am" apply your first two commits (which should be handled
>> as a separate topic) cleanly to a private topic branch I created here
>> called "memory_allocation".  That clean result was based on the tip of the
>> current
>> master branch.
>
> That's good, as I said I have quite old source and didn't want to risk
> introducing any changes in the build system that may have cost me time
> as I only had a few hours to set this up and send it to you. I will
> update once I get chance.
>
>>
>> I similarly applied your four commits cleanly to a private topic branch
>> which
>> I call "exception_handling".  i.e., I assumed for this topic branch
>> the memory_allocation topic would be merged before the exception
>> handling part of your commits, although I doubt that would be actually
>> necessary, i.e., both these topics are completely independent of each
>> other.
>
> Yes, the memory management is independent of exception handling, but
> exception handling requires memory management to avoid memory leaks.
>
>>
>> I extensively tested your "memory_allocation" topic as follows.
>>
>> I configured cmake with the option -DVALGRIND_ALL_TESTS=ON and built
>> the test_c_psc target (which builds all our c standard examples
>> for the psc device and runs them all using valgrind).  Those
>> valgrind reports were perfect, i.e., the list of such
>> reports without the phrases "no leaks are possible" and "0 errors from 0
>> contexts") is empty as can be seen from
>>
>> software@raven> ls examples/*.log
>> examples/valgrind.x00c.psc.log  examples/valgrind.x11c.psc.log
>> examples/valgrind.x22c.psc.log
>> examples/valgrind.x01c.psc.log  examples/valgrind.x12c.psc.log
>> examples/valgrind.x23c.psc.log
>> examples/valgrind.x02c.psc.log  examples/valgrind.x13c.psc.log
>> examples/valgrind.x24c.psc.log
>> examples/valgrind.x03c.psc.log  examples/valgrind.x14c.psc.log
>> examples/valgrind.x25c.psc.log
>> examples/valgrind.x04c.psc.log  examples/valgrind.x15c.psc.log
>> examples/valgrind.x26c.psc.log
>> examples/valgrind.x05c.psc.log  examples/valgrind.x16c.psc.log
>> examples/valgrind.x27c.psc.log
>> examples/valgrind.x06c.psc.log  examples/valgrind.x17c.psc.log
>> examples/valgrind.x28c.psc.log
>> examples/valgrind.x07c.psc.log  examples/valgrind.x18c.psc.log
>> examples/valgrind.x29c.psc.log
>> examples/valgrind.x08c.psc.log  examples/valgrind.x19c.psc.log
>> examples/valgrind.x30c.psc.log
>> examples/valgrind.x09c.psc.log  examples/valgrind.x20c.psc.log
>> examples/valgrind.x31c.psc.log
>> examples/valgrind.x10c.psc.log  examples/valgrind.x21c.psc.log
>> examples/valgrind.x33c.psc.log
>>
>> and the empty results from
>>
>> software@raven> grep -L "no leaks are possible"
>> examples/valgrind.x??c.psc.log
>> software@raven> grep -L "0 errors from 0 contexts"
>> examples/valgrind.x??c.psc.log
>
> This is not surprising. I Don't think the plmalloc or plrealloc
> functions are actually used anywhere yet :-D
>
>>
>> Furthermore, I like what you have done with plmalloc, plrealloc, and
>> plfree where if inside those routines malloc, realloc, or free
>> respectively fail, plexit is called with appropriate error message.
>> Assuming, then you want to replace all our current direct calls to
>> malloc, realloc and free with these pl* variants, this solves a major
>> problem we have which was all the wide range of different treatments
>> of how malloc, realloc and free errors were checked, i.e., in the best
>> cases plexit is called, but more usually no error checking is done at
>> all!
>
> Not quit

Re: [Plplot-devel] First proof-of-concept step requested to implement PLplot errorhandling

[Phil Rosenberg]

Hi Alan et al

Please find attached some patches that show some bare bones start to using
setjmp and longjmp exception style error handling in plplot. Please have a
look at the log for a detailed description of what is going on and how it
works.

What this is: A first start with enough code to show the basic principles
of how this could work.

What this isn't: A fully working version that should go anywhere near the
actual repo. I have only tested to see if it compiles, builds and that x00c
runs. In fact I get some tcl related exception on exit, which I'm not sure
if I just caused or if it was there before.

I am sending out this super early untested code that may still have major
bugs and is based on whatever (quite old) plplot source I happened to have
on my machine so that you can see the PRINCIPLES of how it works. And
because I have other stuff on today so I might not get chance to look at
this for a while and I know Alan was keen to see something asap. So feel
free to be critical, but please not too critical :-)

Alan, have a look, have a play. Thoughts welcome.

Phil



On 16 July 2017 at 00:24, <p.d.rosenb...@gmail.com> wrote:

> Hi Alan
>
> Proof of concept was a little more than 20 or so lines 
>
>
>
> I'll pull out the code I started and check where is stands.
>
>
>
> Phil
>
>
>
> Sent from my Windows 10 phone
>
>
>
> *From: *Alan W. Irwin <ir...@beluga.phys.uvic.ca>
> *Sent: *15 July 2017 21:50
> *To: *Phil Rosenberg <p.d.rosenb...@gmail.com>; Ole Streicher
> <debian-de...@liska.ath.cx>
> *Cc: *Hazen Babcock <hbabc...@mac.com>; andrewr...@users.sourceforge.net; 
> PLplot
> development list <plplot-devel@lists.sourceforge.net>
> *Subject: *First proof-of-concept step requested to implement PLplot
> errorhandling
>
>
>
> On 2017-07-15 11:49+0200 Ole Streicher wrote:
>
>
>
> > Another (probable longer-standing) topic would be the use of exit() in
>
> > several libraries in case of error. That usually has the disadvantage
>
> > that it makes debugging more complicated, since you don't get a
>
> > stacktrace; abort() may be the better solution here. Any thoughts about
>
> > that?
>
>
>
> To Phil and Ole (with CC to Hazen and Andrew):
>
>
>
> @Phil:
>
> There is a key question for you at the end.
>
>
>
> @Ole:
>
>
>
> Here is some background on the issue you brought up above.
>
>
>
> An even more important issue with exit that concerns PLplot developers
>
> is, for example, some poor guy has been working on some interactive
>
> session for 4 hours, (e.g., octave) and then attempts to finish up by
>
> plotting his results, but he makes a wrong PLplot call ==> exit, loses
>
> all those 4 hours of work!  Not pretty!
>
>
>
> The obvious solution is to implement a proper error handling system
>
> for the PLplot libraries, bindings libraries, and device drivers that
>
> avoids the use of exit and simply propagates an error condition to
>
> whatever library or user routine calls PLplot routines if something
>
> goes wrong anywhere in any of the PLplot-related source code.
>
>
>
> We have discussed here fairly recently the best way to implement such
>
> an error handling system. There have been two schools of thought about
>
> how we implement that which I will attempt to summarize here.
>
>
>
> 1. Implement our error handling using normal C methods.  That is,
>
> change our API to return an error code for each PLplot routine that
>
> can possibly have an error condition or which calls a PLplot routine
>
> that itself could have an error condition. (This turns out to be most
>
> PLplot-related routines).  Then those error conditions codes must be
>
> checked and propagated further if necessary after virtually all
>
> returns from PLplot routines that occur within the PLplot libraries,
>
> bindings libraries, and device drivers.
>
>
>
> 2. Implement our error handling system using longjmp and setjmp
>
>
>
> See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html>
>
> for an example of how to use those two C library routines (both
>
> available since c89 and also supported by Windows) to implement
>
> exception handling in C that is quite similar to exception handling in
>
> C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based
>
> error handling system he was unaware of this example so his proposal
>
> likely varied in many details from this example.  But the overall
>
> principle was the same which is you can use these two functions to
>
> avoid the laborious process of having to propagate error codes via
>
> f

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Phil Rosenberg]

Last email of speculation

I have found in the latest source that the file include/wx/gdicmn.h
includes the inline definition for the constructor, but the file
interface/wx/gdicmn.h does not include the inline definition for the
constructor. The former should be used by external applications like
ours, the latter is for building the wx libraries themselves. Is it
possible that you are loading the latter somehow from somewhere?

On 10 July 2017 at 11:18, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> Hi Arjen
> Doing a git blame on GitHub indicates that the relevant constructor
> line was last edited 10 years ago, which seems strange. However that
> is probably the header used when building the library rather than put
> in the include directory for use by external programs. Maybe the two
> are not the same :-s.
>
> If you are building with Visual studio, then you can find an example
> of wxSize being used and right click it, then go to
> definition/declaration. This should take you to the actual header file
> being parsed and you can check it is the one you expect (hover over
> the filename tab to show the full path or right click the tab and hit
> open containing folder) and you can check the constructor is inlined.
>
> Phil
>
> On 10 July 2017 at 11:10, Arjen Markus <arjen.mar...@deltares.nl> wrote:
>> Hi Phil,
>>
>>
>>
>> I am using MSVC and nmake to compile this under bare Windows. I remember
>> seeing some confusion over what installation CMake came up with exactly, but
>> I do not recall the details. That may have been with the MinGW experiments.
>>
>>
>>
>> I will have to check this – tonight if possible.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>> -Original Message-
>>> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
>>
>>> Sent: Monday, July 10, 2017 12:04 PM
>>> To: Arjen Markus
>>> Subject: Re: The wxwidgets version you use for MSVC
>>>
>>> Ah, so you do have the inlined function definition. In that case I am
>>> confused.
>>>
>>> Is there any possibility that you have more than one set of wxWidgets
>>> headers
>>> installed, the one you are looking at and a latest dev version?
>>>
>>> What are you using to compile are you using visual studio or minGW?
>>>
>>> Phil
>>>
>>> On 10 July 2017 at 10:52, Arjen Markus <arjen.mar...@deltares.nl> wrote:
>>> > Hi Phil,
>>> >
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
>>> >> Sent: Monday, July 10, 2017 11:49 AM
>>> >> To: Arjen Markus; plplot-devel@lists.sourceforge.net
>>> >> Cc: Alan W. Irwin
>>> >> Subject: Re: The wxwidgets version you use for MSVC
>>> >>
>>> >> Hi Arjen
>>> >> That looks like the class you are looking for. Those comments
>>> >> shouldn't be important. They just mean that you can access x and y
>>> >> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
>>> >> But the comment says please don't do this.
>>> >>
>>> >
>>> > Right, I misread that as meaning the data AND the method members, but
>>> > it only refers to the data members.
>>> >
>>> >> Further down in that class is there a constructor? it will look
>>> >> something like wxSize( int w, int h). It looks like a function
>>> >> declaration, but with no return type. The variable names may be
>>> >> different too - probably some variation on width and height or x and
>>> >> y.
>>> >>
>>> > There are two in fact:
>>> >
>>> > // constructors
>>> >
>>> > wxSize() : x(0), y(0) { }
>>> >
>>> > wxSize(int xx, int yy) : x(xx), y(yy) { }
>>> >
>>> > Regards,
>>> >
>>> > Arjen
>>> >
>>> > DISCLAIMER: This message is intended exclusively for the addressee(s)
>>> > and may contain confidential and privileged information. If you are
>>> > not the intended recipient please notify the sender immediately and
>>> > destroy this message. Unauthorized use, disclosure or copying of this
>>> > message is strictly prohibited. The foundation 'Stichting Deltares',
>>> > which has its seat at Delft, The Netherlands, Commercial Registr

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Phil Rosenberg]

Hi Arjen
Doing a git blame on GitHub indicates that the relevant constructor
line was last edited 10 years ago, which seems strange. However that
is probably the header used when building the library rather than put
in the include directory for use by external programs. Maybe the two
are not the same :-s.

If you are building with Visual studio, then you can find an example
of wxSize being used and right click it, then go to
definition/declaration. This should take you to the actual header file
being parsed and you can check it is the one you expect (hover over
the filename tab to show the full path or right click the tab and hit
open containing folder) and you can check the constructor is inlined.

Phil

On 10 July 2017 at 11:10, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> Hi Phil,
>
>
>
> I am using MSVC and nmake to compile this under bare Windows. I remember
> seeing some confusion over what installation CMake came up with exactly, but
> I do not recall the details. That may have been with the MinGW experiments.
>
>
>
> I will have to check this – tonight if possible.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>> -Original Message-
>> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
>
>> Sent: Monday, July 10, 2017 12:04 PM
>> To: Arjen Markus
>> Subject: Re: The wxwidgets version you use for MSVC
>>
>> Ah, so you do have the inlined function definition. In that case I am
>> confused.
>>
>> Is there any possibility that you have more than one set of wxWidgets
>> headers
>> installed, the one you are looking at and a latest dev version?
>>
>> What are you using to compile are you using visual studio or minGW?
>>
>> Phil
>>
>> On 10 July 2017 at 10:52, Arjen Markus <arjen.mar...@deltares.nl> wrote:
>> > Hi Phil,
>> >
>> >
>> >
>> >> -Original Message-
>> >> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
>> >> Sent: Monday, July 10, 2017 11:49 AM
>> >> To: Arjen Markus; plplot-devel@lists.sourceforge.net
>> >> Cc: Alan W. Irwin
>> >> Subject: Re: The wxwidgets version you use for MSVC
>> >>
>> >> Hi Arjen
>> >> That looks like the class you are looking for. Those comments
>> >> shouldn't be important. They just mean that you can access x and y
>> >> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
>> >> But the comment says please don't do this.
>> >>
>> >
>> > Right, I misread that as meaning the data AND the method members, but
>> > it only refers to the data members.
>> >
>> >> Further down in that class is there a constructor? it will look
>> >> something like wxSize( int w, int h). It looks like a function
>> >> declaration, but with no return type. The variable names may be
>> >> different too - probably some variation on width and height or x and
>> >> y.
>> >>
>> > There are two in fact:
>> >
>> > // constructors
>> >
>> > wxSize() : x(0), y(0) { }
>> >
>> > wxSize(int xx, int yy) : x(xx), y(yy) { }
>> >
>> > Regards,
>> >
>> > Arjen
>> >
>> > DISCLAIMER: This message is intended exclusively for the addressee(s)
>> > and may contain confidential and privileged information. If you are
>> > not the intended recipient please notify the sender immediately and
>> > destroy this message. Unauthorized use, disclosure or copying of this
>> > message is strictly prohibited. The foundation 'Stichting Deltares',
>> > which has its seat at Delft, The Netherlands, Commercial Registration
>> > Number 41146461, is not liable in any way whatsoever for consequences
>> > and/or damages resulting from the improper, incomplete and untimely
>> > dispatch, receipt and/or content of this e-mail.
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

--
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

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Phil Rosenberg]

I just checked in my version. I have

class WXDLLIMPEXP_CORE wxSize
{
public:
// members are public for compatibility, don't use them directly.
int x, y;
// constructors
wxSize() : x(0), y(0) { }
wxSize(int xx, int yy) : x(xx), y(yy) { }

The last line is the important one. What does it look like in your version?

I have just looked on GitHub on the latest source
(https://github.com/wxWidgets/wxWidgets/blob/master/interface/wx/gdicmn.h)
and this constructor has indeed changed to not inlined and instead
looks like

wxSize(int width, int height);

I would suggest that there is some mismatch between the headers you
have and the dll. The dll used inlined version, so includes no
definition and the headers have the non inlined version so also
includes no definition. The linker is therefore rightfully complaining
there is no definition. If this is the case then it's a bug with the
wxWidgets distribution.

Phil

On 10 July 2017 at 10:48, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> Hi Arjen
> That looks like the class you are looking for. Those comments
> shouldn't be important. They just mean that you can access x and y
> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> But the comment says please don't do this.
>
> Further down in that class is there a constructor? it will look
> something like wxSize( int w, int h). It looks like a function
> declaration, but with no return type. The variable names may be
> different too - probably some variation on width and height or x and
> y.
>
> On 10 July 2017 at 10:25, Arjen Markus <arjen.mar...@deltares.nl> wrote:
>> Hi Phil,
>>
>>
>>
>> That is definitely a possibility. I had another search for wxSize. At first
>> I only found wxSizer (which is not the class I was looking for), but finally
>> I did – in a header file “gdicmn.h”:
>>
>>
>>
>> class WXDLLIMPEXP_CORE wxSize
>>
>> {
>>
>> public:
>>
>> // members are public for compatibility, don't use them directly.
>>
>> int x, y;
>>
>>
>>
>> I have no idea what to make of the comment …
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>
>>
>> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
>> Sent: Monday, July 10, 2017 10:59 AM
>> To: Arjen Markus; Alan W. Irwin
>>
>>
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets build of
>> the dlls, but then not during the build of plplot. That would explain a
>> linker error there i think.
>>
>>
>>
>> You could search for wxSize::wxSize which should locate the constructors for
>> that class, if they exist.
>>
>>
>>
>> Phil
>>
>>
>>
>> Sent from my Windows 10 phone
>>
>>
>>
>> From: Arjen Markus
>> Sent: 10 July 2017 08:22
>> To: p.d.rosenb...@gmail.com; Alan W. Irwin
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hi Phil,
>>
>>
>>
>> See my answers below in context.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>
>>
>> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
>> Sent: Monday, July 10, 2017 12:24 AM
>> To: Alan W. Irwin
>> Cc: Arjen Markus
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hi Arjen
>>
>> Have you built any other wxWidgets applications with this library version.
>> Also is there a chance that you could be accessing headers from a version
>> that s different to the dll?
>>
>>
>>
>>>>AM: I have not tried to build anything else. I had a “hello, world”
>>>> example, but I compiled that under MinGW and as that worked and the PLplot
>>>> build failed, I do not think it is representative for the current problem.
>>
>>
>>
>> Usually when I see wxString involved my first guess s a Unicode related flag
>> miss match. But with those two particular methods being unrelated and
>> probably relatively small functions, I wondered if they have been swapped
>> from inline to not inline between wx versions, and hence if you pick up a
>> header without inlined versions but a dll with inlined versions you will get
>> linker errors. Just a guess though.
>>
>> Also try using dependency walker or dumpbin (fed into grep if you have
>> access to it) to check if those methods or some va

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Phil Rosenberg]

Hi Arjen
That looks like the class you are looking for. Those comments
shouldn't be important. They just mean that you can access x and y
exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
But the comment says please don't do this.

Further down in that class is there a constructor? it will look
something like wxSize( int w, int h). It looks like a function
declaration, but with no return type. The variable names may be
different too - probably some variation on width and height or x and
y.

On 10 July 2017 at 10:25, Arjen Markus  wrote:
> Hi Phil,
>
>
>
> That is definitely a possibility. I had another search for wxSize. At first
> I only found wxSizer (which is not the class I was looking for), but finally
> I did – in a header file “gdicmn.h”:
>
>
>
> class WXDLLIMPEXP_CORE wxSize
>
> {
>
> public:
>
> // members are public for compatibility, don't use them directly.
>
> int x, y;
>
>
>
> I have no idea what to make of the comment …
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
> Sent: Monday, July 10, 2017 10:59 AM
> To: Arjen Markus; Alan W. Irwin
>
>
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets build of
> the dlls, but then not during the build of plplot. That would explain a
> linker error there i think.
>
>
>
> You could search for wxSize::wxSize which should locate the constructors for
> that class, if they exist.
>
>
>
> Phil
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Arjen Markus
> Sent: 10 July 2017 08:22
> To: p.d.rosenb...@gmail.com; Alan W. Irwin
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hi Phil,
>
>
>
> See my answers below in context.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
> Sent: Monday, July 10, 2017 12:24 AM
> To: Alan W. Irwin
> Cc: Arjen Markus
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hi Arjen
>
> Have you built any other wxWidgets applications with this library version.
> Also is there a chance that you could be accessing headers from a version
> that s different to the dll?
>
>
>
>>>AM: I have not tried to build anything else. I had a “hello, world”
>>> example, but I compiled that under MinGW and as that worked and the PLplot
>>> build failed, I do not think it is representative for the current problem.
>
>
>
> Usually when I see wxString involved my first guess s a Unicode related flag
> miss match. But with those two particular methods being unrelated and
> probably relatively small functions, I wondered if they have been swapped
> from inline to not inline between wx versions, and hence if you pick up a
> header without inlined versions but a dll with inlined versions you will get
> linker errors. Just a guess though.
>
> Also try using dependency walker or dumpbin (fed into grep if you have
> access to it) to check if those methods or some variants are really in the
> dll.
>
>
>
>>>AM: The libraries and header files come from the “official” wxWidgets
>>> site. But they are the DLLs only, not the static ones. I searched for the
>>> string “wxString” in the header files and the libraries (import and DLL),
>>> but it is ubiquitous – 904 header files contain that string. Luckily that
>>> was not the case for ~wxString. That is defined in the string.h header file,
>>> but conditionally:
>
>
>
> #if wxUSE_STRING_POS_CACHE
>
>   ~wxString()
>
>   {
>
>   // we need to invalidate our cache entry as another string could be
>
>   // recreated at the same address (unlikely, but still possible, with
> the
>
>   // heap-allocated strings but perfectly common with stack-allocated
> ones)
>
>   InvalidateCache();
>
>   }
>
> #endif // wxUSE_STRING_POS_CACHE
>
>
>
> No such luck though with wxSize – 504 header files.
>
>
>
> I have not yet inspected the 34 DLLs … that is for later.
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> 

Re: [Plplot-devel] Best git version for Windows?

[Phil Rosenberg]

Hi Jim
Good luck with the restoration. If this helps for the future then as a
windows user you can get 1 TB of OneDrive space as part of an Office
365 subscription. I basically symlinked my Documents folder into my
OneDrive folder so that everything I do gets continually synced with
the cloud.

Anyway, as far as git is concerned I use Git within Cygwin even for my
Windows development. I always feel the Linux environment that goes
along with this gives the best development environment. You could
probably get an identical setup by using the new Bash on Ubuntu on
Windows feature if you are using Windows 10. Windows now ships with
the ability to install a native but stripped down (command line only)
version of Ubuntu within Windows. This runs native Linux executables
and you have access to apt-get so it's pretty handy!

Phil

On 21 February 2017 at 21:45, Alan W. Irwin  wrote:
> To Jim, Phil, and Arjen:
>
> On 2017-02-20 00:38-0500 Jim Dishaw wrote:
>
>> I need your help to sort out git.  Long story short, I had a disk
>
> corruption on the VM that I was doing my development work and had to
> recover my work.  I manage to get my wingdi driver recovered from the
> smoking heap.
>
> @Jim:
>
> My sympathies concerning your hardware troubles.  I am especially
> sensitive to that issue because I just went through a hardware scare
> myself (spent a lot of yesterday running hardware tests when I ran
> into the *.pyc corruption issue).  But amazingly this 9-year-old
> hardware (with an ASUS motherboard which might be the reason for this
> longevity) still passes all hardware tests, and I have concluded (with
> a fair amount of confidence) that the *.pyc corruption issue must be
> due to some Python bug.  So I plan to keep using this hardware for
> a while longer.
>
>> Unfortunately, I appear to be having problems with the git
>
> repository on SourceForge and I am not sure of the cause—I cannot even
> clone from SourceForge.
>
> @Jim, Phil, and Arjen:
>
> I used the git SF server just this morning with no issues.  Also, for
> the reasons discussed in README.developers you should avoid all gui
> versions or "enhanced" versions of git (i.e., try to stick as much as
> possible to the real thing).  Bearing those constraints in mind, that
> file recommends  for Windows
> users, but I just discovered from looking at that site that it has
> been obsoleted and msysgit developers now recommend using the "Git for
> Windows"  version of git instead.
> (I confirmed from that website it considers itself light-weight
> [check!] and it does have a command-line version [check!]).  So please
> give the command-line version of that project a try, and let us know
> whether it works well for you (which would allow us to recommend that
> Windows version of git in our README.developers file).
>
> 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

Re: [Plplot-devel] C++ class constructor question

[Phil Rosenberg]

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.

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
- in reality the wxDevice does not care how the data gets sent, either
via shared memory, over a network port, by writing to a file on the
disk drive or even by messenger pigeon - it just wants to send it and
sometimes get some back. By adding those functions we totally separate
out the transmission from the other stuff that wxPLDevice does. This
would mean actually we could create different classes that do the
transmission in different ways and we could use different objects as
slot in replacements if we liked.

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.

Now in terms of having a default constructor that initialises
everything invalid, well there is nothing wrong with that. I don't see
how constructing a new object for every use is simpler, in fact the
opposite. I'm also not sure where exactly you will be creating your
shared memory. In PLMemoryMap? If you keep creating and destroying
your PLMemoryMap objects then you will keep scrapping and recreating
your shared memory won't you? It also seems that although you would
remove a small amount of code from PlMemory map, you instead make the
class more difficult to use, so it doesn't seem like the right choice
for me in many ways.

I hope that makes sense.

Phil


On 11 February 2017 at 21:46, Alan W. Irwin  wrote:
> Hi Phil:
>
> I have noticed the style of communications you are using between various
> classes typically involves private variables such as
>
> PLMemoryMap  m_outputMemoryMap;
>
> for wxPLDevice, a default constructors for
> PLMemoryMap that essentially sets everything relevant to invalid
> values, and no explicit use of the constructor that does valid
> initialization for PLMemoryMap from within wxPLDevice.  (Instead an
> explicit create method is called to do the required valid
> initialization.)
>
> Would there be anything wrong with dropping that private variable,
> dropping the default invalid constructor, dropping the create method,
> creating an instance of PLMemoryMap (with correct explicit valid
> constructor with a mustExist argument to decide if you are going to
> reuse external memory locations from a previously initialized
> instance), and using the methods of that instance when you need them?
>
> That latter simplified approach is the one I have tentatively adopted
> for the new PLTwoSemaphores class I have just implemented (see commit
> cd13d65).  The (only) constructor checks that the argument values
> corresponding to the addresses of the two semaphores are non-NULL, and
> then the internal private variables of the instance that correspond to
> those two addresses are updated.  If mustExist is true, nothing more
> is done, but if mustExist is false, then sem_init is called for each
> of those pointers. The (only) destructor for the PLTwoSemaphores class
> calls sem_destroy for each of the (internal) pointers and sets those
> internal pointers to NULL.  And all other methods of PLTwoSemaphores
> that use those internal pointers check that they are non-NULL.
>
> So far the two-semaphores implementation is incomplete so I have only
> tested the new PLTwoSemaphores class with a build (with the g++
> compiler finding no issue with it).  Do you anticipate I will be
> running into trouble later on with the above simplified constructor
> approach once I start to use PLTwoSemaphores class instances (e.g., in
> the arguments for the currently empty PLMemoryMap::sendBytes and
> PLMemoryMap::receiveBytes methods?
>
> If it turns out you do believe the current simplified PLTwoSemaphores
> constructor approach will work OK, should we also switch to that
> simplified approach everywhere else (e.g., to handle wxPLDevice's use
> of PLMemoryMap)?
>
> Alan
> __
> Alan W. Irwin
>

Re: [Plplot-devel] Recent progress with wxwidgets IPC

[Phil Rosenberg]

Hi Alan
That seems reasonable. I'm not sure what the benefits are though.
Should the new way be quicker?

In terms of the overall complexity here are some of the things I found
while setting up the current system that each made the system more
complex than I initially envisaged. I imagine you will come across
many of these too.

The reason that I went for a circular buffer is that data can
continuously be being sent even while the reader is reading. That is
until the writer catches up with the reader. In a simple
restart-from-the-beginning buffer like you seem to be proposing the
sender must wait until the reader has read all the data from the
buffer before it can send more data.

In fact I have a feeling that the system as I have it now makes little
or no use of the actual semaphores and just uses flags in specified
locations in the shared memory. I would have to look through the code
properly to check. Don't forget also that while waiting for new data
the semaphore cannot block indefinitely. To do so would hang
wxPLViewer or the sender software. I think also there is no way to
tell if a page is finished or whether there is more data to come.
Therefore you must use non- blocking semaphores and poll them on
regular intervals.


If you want to do two way communications you will need two areas of
shared memory, one for each direction, otherwise you will likely have
a race condition for which process will write next. As it happens,
like you said the transfer is almost all one way, with just a small
amount being returned. So I just allocated a small portion of the
shared memory to represent a struct to hold some specific returned
information. I'm doing this from memory, but I think it would work
like this for the case of getting text size.

Sender zeros the flag which indicates a text size is available.
Sender sends a message to the Viewer saying it wants a text size and
with the string it wants sizing
Sender starts checking the flag to say that the text size is available.
Viewer receives the message requesting text size
Viewer determines the text size and writes it to the location in
shared memory reserved for text size
Viewer sets the flag which indicates text size is available to 1
Sender sees the text size flag it one
Sender reads the text size from the location in shared memory that is
reserved for text size.

The same is basically true for getting position information for
pllocate calls. But there is a pause on the Viewer side while it waits
for user input.

Of course the alternate is to set up a totally generic symmetric
system, I'm not sure if one is easier or faster.

I guess all these things contribute to the complexity of the code that
is there, but I'm not sure that it is more complex than necessary.
I'll be interested to see how your setup differs :-)

Phil



On 7 February 2017 at 02:01, Alan W. Irwin  wrote:
> On 2017-02-06 23:52- p.d.rosenb...@gmail.com wrote:
>
>> Hi Alan
>
>
>> Not exactly sure what you mean by complex? It is not always possible
>
> to send all data, as the shared memory is finite size and therefore
> the data to be sent may be bigger than the shared memory.
>
> Hi Phil:
>
> To get a preview of what I mean by implementing an approach that is
> simpler than the current one, I suggest you take a look at the code in
> cmake/test_linux_ipc.  There, the shared memory buffer size is
> relatively small, that buffer is _not_ a circular buffer, and
> typically the amount of data to be transmitted >> shared memory buffer
> size.  The data are split up into chunks that fit into the buffer on
> the sending side and those chunks are assembled on the receiving side
> under the control of two semaphores.  The result is an efficient
> transfer of the entirety of what can be an extremely large amount of
> data (25MB in one test) between sender and receiver with relatively
> simple code and relatively small shared memory buffer.
>
> My current plan is to have a generic function "send" for sending a
> generic array of bytes and a generic function "receive" for receiving
> that array where those functions contain all the details of the
> two-semaphore method for transmitting and receiving a generic data
> array.  Then higher level code would create an array to be sent or
> received and then they would use this send/receive API to transfer
> those arrays.  Of course, the usual case is that -dev wxwidgets
> normally would call the "send" API and wxPlViewer normally would
> normally call the "receive" API, but when those roles are reversed
> (e.g., when transmitting back the physical size of displayed text
> strings), then wxPlViewer will be calling the "send" API and -dev
> wxwidgets will be using the "receive" API.
>
>> I presume it's this named semaphore and/or memory flags that you intend to
>> remove?
>
>
> I am definitely going to keep named semaphores (see step 3 in my
> original plan where a small change to the two-semaphores approach
> should change that 

Re: [Plplot-devel] C++ help requested for step 1. (fwd)

[Phil Rosenberg]

Hi Alan
Your ears must be burning! (not sure if you have that phrase
stateside?) I was just looking through the code and trying to
understand the issue. then when I came back to reply I found another
email :-)

As it stands I don't see in your source code where you have called
m_unamed_semaphore_MemoryMap.create(  );

I think what is happening is that you construct your PLnamedMutex
which constructs all the member variables using their default
constructors (the ones which take no variables). The default
constructor for PLMemoryMap just sets m_buffer to NULL. Your call to
getwsem then takes m_buffer, which is NULL and tries to access some of
it's data and I imagine that is the point that everything goes wrong.

I think it is actually impossible for your getwsem method to return
NULL. Because this function returns the address of member data of
m_buffer (which will just be the m_buffer pointer plus a few bytes)
then the only way it could return NULL would be if m_buffer was 2^64
minus a few and the memory locations wrapped round - but I'm sure that
can't happen.

Anyway, the fix is to either call m_unamed_semaphore_MemoryMap.create
just before getwsem, or call this in the constructor of PLNamedMutex,
or tell PLNamedMutext to use the non-default constructor for
m_unamed_semaphore_MemoryMap. To do the last of these the syntax would
be as follows in wxWidgets_comms.cpp

PLMemoryMap::PLMemoryMap( const char *name, PLINT size, bool
mustExist, bool mustNotExist )
: m_unamed_semaphore_MemoryMap()
{


Hopefully email line breaks haven't messed that up. Just to be clear
after the method definition, but before the opening curly bracket ad a
colon followed by a comma separated list of all the non default
constructors you wish to call. this is called the constructor
initialiser list. You would need to add this for each of the
constructors of PLMemoryMap and of course you would need to add in
your #ifdef statements.


I hope this fixes it!

Phil


On 5 February 2017 at 20:27, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> @everybody (other than Phil who has already been most helpful):
>
> I would really appreciate some timely help with my C++ questions.
>
> Although, my (fairly elementary) C++ question below was initially
> directed to Phil because he has been kind enough to answer such
> questions from me before, if you have some C++ knowledge please don't
> be hesitant about jumping in with your own answer to such questions.
> After all, Phil is not available 24x7 (in fact he appears not to be
> available at the moment) so if you do jump in with the answer, it
> should help me reach my wxwidgets development goals much quicker than
> if you don't.
>
> And, by the way, this "jumping in" attitude should be encouraged in
> general on this list if you have any relevant knowledge about the
> question being discussed.  So don't hold back out of some sense of
> politeness that you are interrupting someone else's conversation.
>
> @everybody (including Phil if someone else doesn't beat him to the
> answer):
>
> So to summarize the current status for _everybody_ here, gdb tells me
> that calls to m_outputMemoryMap.getBuffer() and
> m_outputMemoryMap.getswm() in, wxPLDevice::SetupMemoryMap obtains the
> address of the buf char array and wsem in the shared memory shmbuf
> struct without issues, and with the expected address 0x48 offset
> between the two.  However, a few steps later control passes to
> PLNamedMutex::create, and the m_unamed_semaphore_MemoryMap version of
> those calls produce incorrect addresses (0x48 for the first 0x0 for
> the second).  So why that difference considering that
> m_unamed_semaphore_MemoryMap is defined in a similar way for the
> PLNamedMutex class as m_outputMemoryMap is defined for the wxPLDevice
> class?
>
> I feel like I am on the edge of solving this, but I must be missing
> something that should be obvious to someone knowledgeable in C++.  From
> these gdb results I now expect more has to be done than the single statement
>
> PLMemoryMap  m_unamed_semaphore_MemoryMap;
>
> (see diff below) to set up access to the PLMemoryMap class methods from the 
> PLNamedMutex class.
>
> But what is that "more"?
>
> 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).
> __
>
> L

Re: [Plplot-devel] Error propagation

[Phil Rosenberg]

Hi Andrew
Thanks for adding to the discussion. Further additions below

On 3 February 2017 at 11:15, Andrew Ross
<andrewr...@users.sourceforge.net> wrote:
>
> Hi all,
>
> Sorry I have been silent for so long. Work and life have rather got in
> the way of plplot development. This is something I have raised a couple
> of times in the past and something I have thought about a fair bit.
>
> Comments on Phil's proposals below.
>
> Andrew
>
> On Mon, 2017-01-30 at 11:00 +, Phil Rosenberg wrote:
>> Hi all
>> We have had this discussion in the past. But I would like to reopen
>> it.
>>
>> We really really need to get id of the exit() calls in PLplot. I
>> don't
>> think that we can really make any recommendation that our library is
>> "industrial strength" while they are their and I would be very
>> nervous
>> about using PLplot in production software with them in - plus even
>> using PLplot for science work I have been caught out be these calls
>> in
>> the past.
>>
>> I think there are a few options we have got
>>
>> Firstly with our internal propagation we can either do
>> A1) Set up our functions so they return error codes and make sure we
>> check these. I feel there is a tendency for this to be bad because I
>> know that I am inherently lazy if I am frank (and I'm sure we all
>> have
>> our lazy moments) and tend to write code without these checks then
>> (try to) go back and add them later. Missing checks are likely to
>> cause segfaults or memory corruptions which are even worse than the
>> exit calls().
>
> Laziness is no excuse! The advantage of this proposal is that is allows
> the library to clean things up as we unwind the stack and so (if done
> properly) it will minimise any chance of problems down the line. Even
> if this is a fatal error from plplot's perspective (e.g. memory
> allocation failure), then we must return control to the calling
> programme in a clean and controlled manner.

I wasn't saying it's an excuse, and perhaps I am being flippant using
the term laziness. I guess that what I meant is that it is easy to
forget to do the checking and can be painful, error prone and take a
long time to implement/manage and the result of a single forgotten or
missed error check is equal to a single exit call - i.e. likely
segfault and immediate program termination. Currently a single memory
allocation imposes a single plexit() function call - so at least there
aren't many of them and we know where they are. In a returned error
code solution there will be many function calls to deal with for each
of our current exit calls. Is there a way we can manage this with code
style? Maybe could we label internal functions that can result in
failures with a prefix like plcf (for pl can fail - better prefix
suggestions welcome) Then only functions which have the plcf prefix or
API entry points are allowed to call other functions with the plcf
prefix? Could something like this be checked with a script?
Could we have a required format of checking that we can police with a
script? like if a plcf call is made, the next like should contain if(
err ) or something?

>> A2) Set up an error flag in PLStream which can be set on error and
>> checked after every function call. This would avoid having to change
>> functions that already return values, but still relies on manual
>> checks which I think will be a big weak point.
>
> I would agree that this is still subject to human laziness in checking
> return codes. The advantage of explicitly returning values is that it
> is at least more obvious you need to check them. On the other hand, if
> functions already return values this gets tricky. We probably need to
> do something of a code audit to see if this is likely to be an issue
> before making final decisions.

Same comment as above.
>
>> A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
>> level of every API call and on error we call longjmp which returns
>> the
>> execution point back to the point setjmp was called. There is some
>> extra setup time here to avoid memory leaks and other resource leaks,
>> but once that is done we can all write code with almost no worry
>> regarding error propagation.
>
> This has advantages in terms of not requiring explicit error code
> checking. The bigger problem is making sure we tidy up properly to
> avoid leaks. As Phil says, it requires some care thinking about how we
> deal with non-C drivers as well. I can't say I'm too keen on
> setjmp/longjmp. It can be a lazy solution to the problem rather than
> writing better code in the first place, but given we have a fairly
> large heritage codebase it might be an easier solutio

[Plplot-devel] Error propogation

[Phil Rosenberg]

Hi all
We have had this discussion in the past. But I would like to reopen it.

We really really need to get id of the exit() calls in PLplot. I don't
think that we can really make any recommendation that our library is
"industrial strength" while they are their and I would be very nervous
about using PLplot in production software with them in - plus even
using PLplot for science work I have been caught out be these calls in
the past.

I think there are a few options we have got

Firstly with our internal propagation we can either do
A1) Set up our functions so they return error codes and make sure we
check these. I feel there is a tendency for this to be bad because I
know that I am inherently lazy if I am frank (and I'm sure we all have
our lazy moments) and tend to write code without these checks then
(try to) go back and add them later. Missing checks are likely to
cause segfaults or memory corruptions which are even worse than the
exit calls().

A2) Set up an error flag in PLStream which can be set on error and
checked after every function call. This would avoid having to change
functions that already return values, but still relies on manual
checks which I think will be a big weak point.

A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
level of every API call and on error we call longjmp which returns the
execution point back to the point setjmp was called. There is some
extra setup time here to avoid memory leaks and other resource leaks,
but once that is done we can all write code with almost no worry
regarding error propagation.

Once we decide on our internal method we need to decide how we can
inform the user. We have a number of options again:

B1) An API change so that all our functions return an error code.

B2) Make use of our current plabort call and let the user pass in a
plabort handler.

B3) If we have an error, store an error code in PLStream and add an
API function called plgeterr or similar which allows the user to check
for error after any other function call.

B4) In the C++ binding we could throw an error. Not sure if other
languages have similar throw/catch style options.

B4) Some combination of the above.

I will add there are some specific things we need to think about for
our C++ drivers. These are not so much options, but things we need to
deal with anyway.

C1) Our C++ drivers cannot be allowed to throw an error out of the
driver code and into the main C code. That would potentially end up
with the throw going all the way out to the user's top level code
which may be in C, Fortran, or any other language that can't deal with
it. Note that even if the driver doesn't call throw, it may call
either something in the stl or another driver (in Qt or wxWidgets for
example) that does throw. This is easy to avoid by wrapping the intry
points in try blocks. I have done this for wxWidgets, but haven't
checked the other C++ drivers to see if they are the same.

C2) If we go for option A3, then we cannot allow longjmp over C++
code. This is because nontrivial destructors are not called when
longjmp is called and if objects with these destructors are jumped
over then the result is undefined behaviour - which again is worse
than exit calls.

The fix for C2 - and I think this would be a good thing anyway - would
be to have a specific driver API. This would allow us to have setjmp
calls when we enter that API and avoid jumping over drivers. I think
this would be nice in general as it is not well documented how to
write a driver and a proper driver API would address that.

I am well aware that the use of setjmp and longjmp is very divisive.
So my intention is to work this code up only for the case of memory
allocation failures. This code will consist of:
D2)A set of plmalloc, plrealloc and plfree fuctions which will replace
the usual versions. As well as allocating/freeing memory these
functions will record the allocations in the PLstream.
D1)PLTRY, PLENDTRY macros which will go in each API call. PLTRY will
have the setjmp call. This will be followed by the current code in the
function as it is now then PLENDTRY will deal with what happens if
longjmp has been called - it will check for memory allocations
recorded in the PLStream and will free them. For now it will then just
call exit() so we get the same behaviour but this can be changed later
if we want to go down this route. Once we have this first look at how
setjmp/longjmp can work in our code then I think it will be easier for
us to make an informed choice about the A options.

Does that sound sensible to people? If anyone would like to look at
what would be involved in doing a similar thing using the other
options then it would be really nice to be able to compare the work
and admin/code practices needed for those too.

Phil

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! 

Re: [Plplot-devel] Your development plans for this release cycle

[Phil Rosenberg]

Hi Alan

So I think here are my priorities, in no particular order:

1) wxWidgets Docs - the driver doc is currently well out of date and
the binding docs are non-existent. I have rewritten the driver docs
and started on the bindings. As you said in your release notes the
docs are probably still a weak point and I'm a firm believer that a
library is only as good as it's documentation - clever features are no
god if the users don't know they exist or how to use them.

2) The fill bug where the whole plot gets accidentally filled - I
can't remember if that still exits or if a workaround fix was added.

3) I have on my old to do list something about the selectable region
in x03.3 not being implemented. I should look at that.

4) Plexit. I agree this really needs sorting. However I found at least
one side effect that we would need to deal with - I'll send another
email out immediately after this one.

5) I'll add that incorrect background colour to my list.

6) I would like to add some useful additional features to the
wxPLplotstream API that are particularly wxWidgets relevant. This
would be some additional overloaded constructors and perhaps some
features for plotting - for example it would be nice to be able to set
the actual font face so that in a wxWidgets application a programmer
could use a font dialog to ask the user which font they would like to
use and then use it. This isn't currently possible at the moment where
we just set the family.

I think that's most of it. We will see how fast I can make progress.

Phil

On 30 January 2017 at 05:36, Alan W. Irwin  wrote:
> To Phil and Pedro:
>
> Now that 5.12.0 has been released, I am writing a series of posts to
> our active developers with this subject line.
>
> If either of you has any additional wxwidgets development in mind beyond
> what I
> discuss below, please let me know.
>
> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs (such as the unexpected
> black rather than expected white background color for the first page
> of example 16) to complement the work I plan to do deal with the last
> of the wxwidgets device driver efficiency issues on Linux. Your goal
> should be that each of our C examples with -dev wxwidgets should
> produce exactly the same results (except possibly for text size) as
> given at /examples.php>.
>
> It would be great if one of you got the currently retired wxpng file
> device going again as an aid for such comparisons with other
> file-based plot results.  But even better would be if you implemented
> a wxwidgets-based SVG device (see
> ).  The reason I particularly
> mention SVG as a file format is the generated results are written in
> XML and therefore are straightforward to interpret and debug by visual
> comparison of that XML result with other SVG (from -dev svg, -dev
> svgcairo, or -dev svgqt) results for the same standard example.
>
> @Phil: We were all agreed (see the February 2016 thread with the
> subject line "Error report system plus thread safety" that our current
> use of calls to exit() or the equivalent plexit whenever an error
> condition was encountered was an important issue for our
> users using interactive environments, i.e., one PLplot error ==> takes
> down entire interactive work without giving the user a chance to save
> anything ==> one less user interested in using PLplot!
>
> During that thread you were strongly recommending using a
> setjmp()/longjmp() C-based exception model because you are very
> comfortable with using exception handling in C++ and the amount of
> editing required to implement it would be much smaller than the return
> code method.  Although Hazen had a substantially more cautious
> attitude, I was happy to go along with that C exception approach
> rather than the alternative return code method because of my knowledge
> of the extreme length of many of our call/caller graphs and the large
> amount of the work it would be for us to check _all_ calls of _all_
> PLplot functions within our C library code for invalid return codes.
>
>A google search for the search terms 
>   gives lots of hits.  Phil, I would appreciate you looking at the top
>   several and letting me know which you think is the best for learning
>   about exception handling in C.
> 
>
> The final upshot of that thread was you planned to make a proof of
> concept for us to look at (and help you propagate it to everywhere
> else in our C code during this release cycle if we liked that proof of
> concept). Anyhow, could you please implement that proof of concept
> now?
>
>
> 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 

[Plplot-devel] plreplot and clearing the page (jim please read if you'e around)

[Phil Rosenberg]

I think I've found the issue with clearing the page when using plreplot.
Basically the issue is that the driver bop function is not being
called, because at the point of replaying the buffer, the stream is
already at the beginning of page. This means that the driver does not
clear the page.

There is a line in plFlushBuffer() which calls plP_eop() to avoid
exactly this behaviour, however it is commented out. Using git blame I
found the commit that commented the line out

commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
Author: Jim Dishaw 
Date:   Mon Jun 15 12:10:04 2015 -0400
Fix to the multiple keypress bug on page advance
- The "wait for user input" is not part of an EOP.
  -- A new function plP_wait() was created
  -- plP_wait() calls were added next to plP_eop() calls to generate
 a wait (if specified by nopause) after an EOP event
- The plot buffer was modified to insert an EOP into the buffer
  -- No wait is inserted into the plot buffer because the plot buffer
 only regenerates plots
- A new entry was added to the PLDispatchTable for the wait function
  -- The table initialization sets all function pointers to NULL via
 a memset
  -- If a driver does not specify a wait function, either it is not
 needed (e.g. the ps driver) or it is part of the EOP handler
 (legacy behavior)
- The following drivers were modified to support the new
implementation: cairo, qt, tkwin, and xwin.  The wingcc update will be
in a seperate fix.

It's not entirely clear from the message, however it looks to me like
this line was commented out to avoid odd behaviour when nopause was
specified, but then Jim has fixed that issue in a different way and
then perhaps forgotten to uncomment this line???

Jim, I know it's a long time ago when we were fixing the buffer, I
don't suppose you have any memories of this? I have some vague ones
but nothing concrete.

Basically I'd like to put that line back for the upcoming release
because I have code that is using plreplot that is currently broken
because of this issue. I don't know what anyone thinks of that or what
anyone thinks is an appropriate set of tests to do to ensure there
isn't any odd side effects.

Phil

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] legend and label using wxWidgets

[Phil Rosenberg]

Hi Laurent
I'm glad the text alignment issues are fixed. :-)

In terms of the text size. We have had discussions on the list before about
this. The wxWidgets backend takes the text size given to it by Plplot in mm
and converts it to pt (assuming on pt is 1/72 of an inch) and requests that
size text from wxWidgets. So the text size requested should be consistent
with any other text requested from wxWidgets.

I have just followed some of the wxWidgets code through and it seems that
the height in points gets converted to logical units (pixels) using the
screen dpi and then I think (although I'm not sure) that the Windows API
function CreateFont get's called with this size. It seems that the text
size requested is the size of the cell the text resides in, i.e. it
includes leading.

So for the wxWidgetsDemo, The text size requested is 2.342mm, which is 7pt
(rounding to integer values) and is converted to 9 logical units
(pixels) by wxWidgets. This uses the screen dpi so round(7 * 96 / 72)
= 9. And I think this font size is requested using the CreateFont function
as the cell size. In fact when I do a screenshot, zoom in and look at the
text, the bracket in the title is 9 pixels from top to bottom. So it seems
everything is how it should be.

I don't know if other devices use similar metrics for the text, but I
assume they must be pretty similar. I guess that the issue really is that
the demo windows are rather small (at least on my system) because they use
the default window size. I could adjust this and make it some other fixed
size, but I'm a bit nervous to do so in case I make them larger than
somebodies screen. I'm happy to take suggestions?

Phil

On 8 January 2017 at 13:20, Laurent Berger <laurent.ber...@univ-lemans.fr>
wrote:

> Hi phil,
>
>
> I have updated all my repo wxwidgetts and plplot and now everything is OK
> using VS 2015 or MSYS2-mingw64. Thanks you very much.
>
> Only one thing wxplplotdemo legend are small (may be tiny)
>
> Le 05/01/2017 à 15:58, Phil Rosenberg a écrit :
>
> Hi Laurent
> Although I haven't upgraded to wxWidgets 3.1. I think I have isolated
> and fixed the issue. It turned out to affect all wxDCs that support
> transformations so I was able to reproduce your bad results on a
> wxMemoryDc. If you grab the latest version from the Git repo then you
> should find everything is working correctly again. If not then please
> let me know.
>
> Phil
>
> On 5 January 2017 at 00:42,  <p.d.rosenb...@gmail.com> 
> <p.d.rosenb...@gmail.com> wrote:
>
> Hi Alan
>
> I agree it would be good to look at this pre release. It's on my to do list
> for asap.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Alan W. Irwin
> Sent: 04 January 2017 20:37
> To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
> Subject: Re: [Plplot-devel] legend and label using wxWidgets
>
>
>
> On 2016-12-28 23:19+0100 Laurent Berger wrote:
>
>
>
>
> wxwidgets commit 0bf38e1 x04 y axis label is good
>
> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
> wxwidgets commit 49000def x04 y axis label is false
>
> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)
>
>
>
> Hi Phil:
>
>
>
> Assuming (subject to Pedro's further extensive testing) that you have
>
> found a good fix for that bug he had discovered, then the only
>
> remaining potentially release critical issue for the wxwidgets-related
>
> components of PLplot is the issue discovered by Laurent above.
>
>
>
> So to learn more about what Laurent reported above,
>
> I described those two commits as follows:
>
>
>
> software@raven> git clone https://github.com/wxWidgets/wxWidgets.git
> wxwidgets.git
>
> software@raven> cd wxwidgets.git
>
> software@raven> git branch
>
> * master
>
> software@raven> git describe 0bf38e1
>
> v3.1.0-620-g0bf38e1
>
> software@raven> git describe 49000def
>
> v3.1.0-621-g49000de
>
>
>
> So it is clear from these results that Laurent already bisected this
>
> issue with the 621st commit beyond the last official release (3.1.0)
>
> of wxwidgets showing the issue for the first time.  And since this is
>
> an issue that will not affect any user of an official wxwidgets
>
> release at this time, that gives us a good excuse to do nothing at
>
> this time if the potential fix is going to be intrusive.
>
>
>
> Of course, this issue will affect our users as soon as the next
>
> wxwidgets official release is out so it would be nice at this time for
>
> you to (a) confirm the above results for 0bf38e1 and 49000def from
>
> Laurent and figure out what the issue is.  If it

Re: [Plplot-devel] legend and label using wxWidgets

[Phil Rosenberg]

Hi Laurent
Although I haven't upgraded to wxWidgets 3.1. I think I have isolated
and fixed the issue. It turned out to affect all wxDCs that support
transformations so I was able to reproduce your bad results on a
wxMemoryDc. If you grab the latest version from the Git repo then you
should find everything is working correctly again. If not then please
let me know.

Phil

On 5 January 2017 at 00:42,  <p.d.rosenb...@gmail.com> wrote:
> Hi Alan
>
> I agree it would be good to look at this pre release. It's on my to do list
> for asap.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Alan W. Irwin
> Sent: 04 January 2017 20:37
> To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
> Subject: Re: [Plplot-devel] legend and label using wxWidgets
>
>
>
> On 2016-12-28 23:19+0100 Laurent Berger wrote:
>
>
>
>> wxwidgets commit 0bf38e1 x04 y axis label is good
>
>>
>> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
>>
>
>> wxwidgets commit 49000def x04 y axis label is false
>
>>
>> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)
>
>
>
> Hi Phil:
>
>
>
> Assuming (subject to Pedro's further extensive testing) that you have
>
> found a good fix for that bug he had discovered, then the only
>
> remaining potentially release critical issue for the wxwidgets-related
>
> components of PLplot is the issue discovered by Laurent above.
>
>
>
> So to learn more about what Laurent reported above,
>
> I described those two commits as follows:
>
>
>
> software@raven> git clone https://github.com/wxWidgets/wxWidgets.git
> wxwidgets.git
>
> software@raven> cd wxwidgets.git
>
> software@raven> git branch
>
> * master
>
> software@raven> git describe 0bf38e1
>
> v3.1.0-620-g0bf38e1
>
> software@raven> git describe 49000def
>
> v3.1.0-621-g49000de
>
>
>
> So it is clear from these results that Laurent already bisected this
>
> issue with the 621st commit beyond the last official release (3.1.0)
>
> of wxwidgets showing the issue for the first time.  And since this is
>
> an issue that will not affect any user of an official wxwidgets
>
> release at this time, that gives us a good excuse to do nothing at
>
> this time if the potential fix is going to be intrusive.
>
>
>
> Of course, this issue will affect our users as soon as the next
>
> wxwidgets official release is out so it would be nice at this time for
>
> you to (a) confirm the above results for 0bf38e1 and 49000def from
>
> Laurent and figure out what the issue is.  If it turns out to be a
>
> wxwidgets regression introduced for 49000def it would be good for you
>
> to draw this quickly to the attention of the wxwidgets developers so
>
> they can fix that regression before their next official release to
>
> avoid making life difficult for PLplot wxwidgets users.  But if it
>
> turns out to be our problem, then please prepare the fix and use your
>
> best judgement (depending on, e.g., whether the fix is more or less
>
> intrusive than the fix you just made) whether to push it now or wait
>
> until after the release.
>
>
>
> 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

Re: [Plplot-devel] Using wxWidgets

[Phil Rosenberg]

Hello Laurent
If you grab the latest version of PLPlot from the git repo then you
should find that the API for wxWidgets is as it was and Pedro's
problems are now hopefully also fixed. There should be no need to
apply Pedro's patch.

If you find that your existing code does not work for any reason then
please let me know and I will ensure that this is fixed before the
next release.


All the best

Phil

On 27 December 2016 at 15:27, Laurent Berger
 wrote:
> Problem is my compiler said
>
> 3>c:\users\laurent.pc-laurent-visi\documents\visual studio
> 2013\wxopencv\wxopencvmain\courbeplplot.h(55): error C2059: syntax error
>
> Now syntax error I need two days to change my code. It was like this in
> previous version of plplot. I don't remember 5.xx.xx. I don't wan't to go
> back in my code. I will use 5.11.1
>
> yes
>
> but for the current (5.11.1) release compared to the new implemented
> examples,
> the effect is the same
>
> previously the way to start the demo was
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>
> and now is
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>
> and because wxPLplotwindow is a child of a wxFrame,
> the visible effect is exactly the same, a frame window that shows a
> plot.
>
> -Pedro
>
>
> Le 27/12/2016 à 16:11, Pedro Vicente a écrit :
>
> Laurent
>
> I have installed last version of plplot and last patch (from pedro).
> Can
> you confirm me that wxPLplotwindow is now a non template  class?
>
> yes, that is correct.
>
> -Pedro
>
>
> On 2016-12-27 10:04, Laurent Berger wrote:
>
> Hi,
>
> I have installed last version of plplot and last patch (from pedro).
> Can
> you confirm me that wxPLplotwindow is now a non template  class?
>
> thanks for yours answers
>
>
>
>
> --
> 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
>
>
>
> --
> 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
>

--
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

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

[Phil Rosenberg]

Just to add that I've just tested on my Ubuntu 16.04 system logging on
remotely using Cygwin ssh and X11 server and n my work CentOS system
logging on directly. Everything seems fine! Hopefully you will both
get the same results Pedro and Alan.

Phil

On 4 January 2017 at 14:26, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> Hi All
>
> Right I'm back with sensible access to all my systems and back into my
> usual routine.
>
> So, here goes
>
> On 28 December 2016 at 05:00, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> One small caveat is that I think you can only instantiate the template with
>> a class that has this Create()
>> signature
>>
>> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
>> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>>
>> which is of course , wxFrames, the current use.
>> Probably dialogs too, but maybe not things like buttons and other GUI
>> elements.
>> But I assume that the vast majority of users, if not all, draws the plot in
>> "regular" windows?.
>
> You are indeed correct about this. The other very major category that
> I think doesn't have this signature is wxPanels and we absolutely must
> maintain compatibility for this class. In fact it is more important
> for this class than any other, because you could create always create
> a wxPanel and put it as the only element of a wxFrame, wxDialog,
> wxPage etc
>
> So what I have done is modify the example so that we now generate two
> wxFrames with identical plots, but in slightly different ways.
>
> In one I have used the wxPlDemoFrame and moved most of the
> initialisation code into its constructor and then this frame is set up
> to capture idle events. When it captures idle events it checks
> everything is ready and calls Plot() (setting a flag so this only
> happens once).
>
> In the other I show how a frame can be created without using
> inheritance, with the caveat that Show() must be called and we must
> then wait for the wxEVT_CREATE event to be processed before we do any
> plotting.
>
> If I have this right then these methods should be totally general and
> should allow any of the constructors for any of the different wxWindow
> derived classes to be used. Which is good.
>
> However, you are very correct Pedro that mostly people are likely to
> want to derive from classes such as wxFrame, wxDialog and wxPanel. I
> think it makes sense to create those classes for our users so that
> they can use those in as few lines of code as possible. So what I
> would propose is that for this release we attempt to not add or remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?
>
> So I have just committed the changes I mentioned above. Pedro and
> Alan, if you have time to test them on your Linux systems that would
> be good. I've tested on my Windows system and I'm about to do so on my
> Linux system too.
>
> Phil

--
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

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

[Phil Rosenberg]

Hi All

Right I'm back with sensible access to all my systems and back into my
usual routine.

So, here goes

On 28 December 2016 at 05:00, Pedro Vicente
 wrote:
> One small caveat is that I think you can only instantiate the template with
> a class that has this Create()
> signature
>
> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>
> which is of course , wxFrames, the current use.
> Probably dialogs too, but maybe not things like buttons and other GUI
> elements.
> But I assume that the vast majority of users, if not all, draws the plot in
> "regular" windows?.

You are indeed correct about this. The other very major category that
I think doesn't have this signature is wxPanels and we absolutely must
maintain compatibility for this class. In fact it is more important
for this class than any other, because you could create always create
a wxPanel and put it as the only element of a wxFrame, wxDialog,
wxPage etc

So what I have done is modify the example so that we now generate two
wxFrames with identical plots, but in slightly different ways.

In one I have used the wxPlDemoFrame and moved most of the
initialisation code into its constructor and then this frame is set up
to capture idle events. When it captures idle events it checks
everything is ready and calls Plot() (setting a flag so this only
happens once).

In the other I show how a frame can be created without using
inheritance, with the caveat that Show() must be called and we must
then wait for the wxEVT_CREATE event to be processed before we do any
plotting.

If I have this right then these methods should be totally general and
should allow any of the constructors for any of the different wxWindow
derived classes to be used. Which is good.

However, you are very correct Pedro that mostly people are likely to
want to derive from classes such as wxFrame, wxDialog and wxPanel. I
think it makes sense to create those classes for our users so that
they can use those in as few lines of code as possible. So what I
would propose is that for this release we attempt to not add or remove
anything from the API and just stick with an example that  works with
what we've got. Then after this release we can add non-template
classes for wxFrame, wxDialog and wxPanel which can be used really
easily by our users and we have time to test them and make sure the
API for their use is stable before the next release.

Does that seem sensible?

So I have just committed the changes I mentioned above. Pedro and
Alan, if you have time to test them on your Linux systems that would
be good. I've tested on my Windows system and I'm about to do so on my
Linux system too.

Phil

--
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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

On 19 December 2016 at 17:47, Pedro Vicente
 wrote:
> Hi Phil
>
>> Pedro can you please check if this works on your systems?
>
>
> ok, I'll try it when the patch is pushed to the master .
>
> Alan
>
> I assume you are going to push the patch?
> I get some compiling errors on the current master, please see my last post

It would be good for you to test the patch before it gets pushed to
master so we don't contaminate master with useless changes that just
get undone next commit. To do so create a new branch from master, then
apply the patch
git checkout master
git checkout -b myTestBranch
git apply path/to/patch.patch


If master is currently not working then try checking out a previous
commit as follows
git checkout master
git log
#select a working commit hash one or two back
git checkout 
git checkout -b myTestBranch
git apply path/to/patch.patch

>
> a new idea:
>
> what about if we just override the Create() function of wxPLplotwindow ?

Unfortunately we can't override the create function because we need to
call the base class create function. We can't call the base class
create function inside our own create function because the parameters
that need to be passed in will differ depending upon whether you use a
wxFrame, wxPanel or any other wxWindow as the template class that we
inherit from. In fact this is why we are using the create event in the
first place, otherwise we would just sort everything in the
constructor.

I'm pretty confident that the patch I sent will fix things if the
issue is just that the create event is delayed. If you are having
trouble getting it to apply, then I'll commit it to master. But I
guess we need to wait for Alan to fix the logging issues first.

I'm about to leave work and head home. If he hasn't fixed them by the
time I open my laptop this evening then I'll have a look at fixing the
issue myself.

Phil

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Phil Rosenberg]

Hi Alan
Could you just confirm to me what command you are using to test the timings?

Phil

On 19 December 2016 at 17:33, Pedro Vicente
 wrote:
> Hi Alan
>
> I just did a git pull of the master branch with these changes and I get
> compiling errors
> if I don't add
>
> -DPLPLOT_WX_NANOSEC=ON
>
>
> I did
>
> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
> -DBUILD_TEST:BOOL=ON
> make VERBOSE=1 test_wxPLplotDemo
>
> and result is
>
>
> In file included from
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.h:28,
>  from
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:41:
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets_comms.h:35:30: error:
> wxPLplot_nanosec.h: No such file or directory
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp: In function
> ‘void plD_init_wxwidgets(PLStream*)’:
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:148: error:
> ‘PLPLOT_wxLogDebug’ was not declared in this scope
>
>
> and the same with
>
> -DPLPLOT_WX_DEBUG_OUTPUT=ON
>
> if I add
>
> -DPLPLOT_WX_NANOSEC=ON
>
> the build succeds and the output is
>
>
> 12:29:29: Debug: nanosecs since epoch = 21778268382005471:
> wxPLplotwindow::wxPLplotwindow
> 12:29:29: Debug: nanosecs since epoch = 21778268383178783: frame->Create
> 12:29:29: Debug: nanosecs since epoch = 21778268393882737:
> wxPLplotwindow::Show
> 12:29:29: Debug: nanosecs since epoch = 21778268393941866:
> wxPLplotwindow::CreateStream
> 12:29:29: Debug: nanosecs since epoch = 21778268401739575:
> plD_init_wxwidgets(): enter
> 12:29:29: Debug: nanosecs since epoch = 21778268401812999: wxPLDevice():
> enter
> 12:29:29: Debug: nanosecs since epoch = 21778268401896369: wxPLDevice(): gc
> done
> 12:29:29: Debug: nanosecs since epoch = 21778268402036165: wxPLDevice():
> m_interactiveTextGcdc done
> 12:29:29: Debug: nanosecs since epoch = 21778268402095492: wxPLDevice():
> SetDC done
> 12:29:29: Debug: nanosecs since epoch = 21778268402127174: wxPLDevice():
> leave
> 12:29:29: Debug: nanosecs since epoch = 21778268402165801:
> plD_init_wxwidgets(): leave
> 12:29:29: Debug: nanosecs since epoch = 21778268406212150: Plot()
> 12:29:29: Debug: nanosecs since epoch = 21778268498272214:
> wxPLplotwindow::OnCreate
> 12:29:29: Debug: nanosecs since epoch = 21778268498387763:
> wxPLplotwindow::CreateStream
>
>
>
>
>
>
> On 2016-12-19 01:22, Alan W. Irwin wrote:
>>
>> I have recently (commit 3c4e6be) implemented a new way for users to
>> optionally obtain wxwidgets debug output.
>>
>> The principal change is you must use the CMake option
>> -DPLPLOT_WX_DEBUG_OUTPUT=ON to get any debug output at all.  There is
>> also now an experimental option -DPLPLOT_WX_NANOSEC=ON which you might
>> want to try if your like high-resolution time stamps (but it might
>> cause build errors on some Linux systems and virtually all other
>> systems, so you must experiment with it to see whether it will work on
>> any given system). If you want to insert more debugging output into
>> our wxwidgets-related code under the control of the above two CMake
>> options, please use the correct macro which is
>>
>> PLPLOT_wxLogDebug("some string");
>>
>> That boils down to
>>
>> wxLogDebug("some string");
>>
>> if -DPLPLOT_WX_DEBUG_OUTPUT=ON and PLPLOT_WX_NANOSEC is either not
>> specified or set to its default value using -DPLPLOT_WX_NANOSEC=OFF.
>> The above macro use further boils down to
>>
>> ;
>>
>> if PLPLOT_WX_DEBUG_OUTPUT is either not specified or set to its
>> default value using -DPLPLOT_WX_DEBUG_OUTPUT=OFF.
>>
>> For more details (especially what the nanosec time stamp looks like on
>> systems that support it), see the above commit message.
>>
>> Note, that I plan after the release to implement a CMake test so it
>> can figure out PLPLOT_WX_NANOSEC automatically, i.e., only set that to
>> ON when relevant test code can be built.  However, for now I have
>> taken an extremely simplistic approach "try it and see using the
>> experimental option -DPLPLOT_WX_NANOSEC=ON" for generating the
>> nanonsec time step.
>>
>> 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
>> __
>
>
> --
> Pedro Vicente
> pedro.vice...@space-research.org
> http://www.space-research.org/

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

No worries :-)

Attached is a patch which I hope should fix things. It is the simplest
possible fix as far as I can tell. It does have a while loop with no
counter, but unless there is some rather fatal bug in wxWidgets it
should never turn into an infinite loop. Alan if you prefer I will add
a counter to ensure things can't go crazy. I have also added some
extra checks to wxPLplotwindow just in case the create event ends up
arriving after the first paint event or something - I don't know if
this can happen but the docs aren't clear so it does no harm to
include the checks.

I always have to check how to create patches with git. I followed the
instructions at
https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/.
The appropriate apply commands are listed there too.

Pedro can you please check if this works on your systems?

Phil

PS - Pedro I just realised from your email address we are in the same
line of work. I work at the Institute for Climate and Atmospheric
Science at University of Leeds. Small world!

On 19 December 2016 at 12:51, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2016-12-19 11:31-0000 Phil Rosenberg wrote:
>
>> I'm  just generating a test fix. I will send a patch round once it's
>> done. If it works then I'll tidy it up. However you appear to have
>> bumped up the minimum CMake version so I need to reinstall CMake -
>> turns out the latest Windows version requires a manual uninstall
>> first. I'm sure you're not deliberately making my life hard Alan ;-)
>> :-D :-D
>
>
> Sorry about that.  I far prefer to make your life easy.  :-)
>
>
> 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
> __


wxCreatePatch.patch
Description: Binary data
--
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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

I'm  just generating a test fix. I will send a patch round once it's
done. If it works then I'll tidy it up. However you appear to have
bumped up the minimum CMake version so I need to reinstall CMake -
turns out the latest Windows version requires a manual uninstall
first. I'm sure you're not deliberately making my life hard Alan ;-)
:-D :-D

Phil

On 19 December 2016 at 09:31, Alan W. Irwin  wrote:
> On 2016-12-19 00:30-0800 Alan W. Irwin wrote:
>
>> Anyhow, good luck with implementing this readiness check anyway you
>> like, and I look forward to your commit to that effect which can go
>> right on top of master tip (which should simplify your life). Then we can
>> ask
>> Pedro to drop his (now hopefully redundant) fix to test your solution
>> really works for all the platforms he has access to.
>
>
> Or better yet to take the load off of you some more (say if you don't
> have a Linux machine readily available to test your change) you could
> send me your tentative patch for your readiness check, and I could try
> it here.
>
>
> 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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

Hi Pedro
Ah, I had assumed that the OnCreate event was not being triggered at
all. I now understand what is happening. Or at least I think I do ;-)
Actually now you have pointed out the issue I am surprised the code
works on any platform.

The error is in the wxplplotdemo code, not in the wxplplotwindow. In
the demo we must simply wait for the OnCreate message to arrive and be
processed before we grab the stream in Plot(). We may be able to do
that with
while(!m_created)
   wxYield();

Could you try the above instead of your overloaded Show() fix please?
You can check out an older version of Plplot by using
git checkout 3a6a49a572e7aa518a5b8a6bbecd9ef1f812
which will have your debug code in, but not your Show() fix.

Unfortunately, although your fix does work for the example as it is
written, it will not work in general. This is because there is no
requirement to call Show() immediately after window creation.

I am sorry that I have not been able to go through this in huge detail
with you as fast as I would have liked. I have rather a lot on at work
and I'm sure you understand I have to give that priority.

Phil


On 16 December 2016 at 18:01, Pedro Vicente
<pedro.vice...@space-research.org> wrote:
> Hi Phil, Alan
>
> I tried evtCreateExample.cpp and I get the good expected result.
> This just means that for this simple example the OnCreate event is
> triggered.
>
> To note that on my bad results of the PLplot demo, the OnCreate event is
> *also* triggered.
> the problem is that is triggered after the plot was made
>
>
> 11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
> 11:09:13: Debug: frame->Create
> 11:09:13: Debug: pls NULL
> 11:09:13: Debug: wxPLplotwindow::OnCreate
>
> I am not that familiar with the wxWidgets internals but it seems events are
> put in a queue.
>
> http://docs.wxwidgets.org/3.1/overview_events.html
>
> it could be that the event is not processed in the expected order or delayed
> for some reason.
> this could be a good question for the wxWidgets support list.
>
> -Pedro
>
>
>
> On 2016-12-15 21:11, Alan W. Irwin wrote:
>>
>> On 2016-12-16 01:05- Phil Rosenberg wrote:
>>
>>> Hmm - well another theory down in smoke.
>>>
>>> Attached is an absolute minimum example of the use of wxEVT_CREATE. On
>>> Windows I get the expected behaviour of a popup dialog appearing
>>> before the frame saying "OnCreate called."
>>>
>>> Could you try it on one of your Linux machines? I'm afraid it's way
>>> past my bedtime here in the UK, so I'll have to continue tomorrow.
>>
>>
>> @Pedro: You should do this test as well since your Linux platforms
>> are the ones where
>> (so far at least) issues are showing up.  But for what it is worth, I
>> did the following
>>
>> irwin@raven> g++ $(wx-config --cppflags --libs) evtCreateExample.cpp
>>
>> to successfully (no errors/warnings) build Phil's test application.
>>
>> Then I ran it with
>>
>> irwin@raven> ./a.out
>>
>> and a popup window came up (apparently as a subGUI of a grey GUI blank
>> called "My Frame") with the "OnCreate Called" message displayed (which
>> I understand was the expected result when everything is working
>> properly).
>>
>> I hope that experiment helps you guys to gain some insight in what the
>> heck is going on for wxwidgets-gtk+ on Linux.
>>
>> 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
>> __
>
>
> --
> Pedro Vicente
> pedro.vice...@space-research.org
> http://www.space-research.org/

--
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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

Hmm - well another theory down in smoke.

Attached is an absolute minimum example of the use of wxEVT_CREATE. On
Windows I get the expected behaviour of a popup dialog appearing
before the frame saying "OnCreate called."

Could you try it on one of your Linux machines? I'm afraid it's way
past my bedtime here in the UK, so I'll have to continue tomorrow.

Phil



On 16 December 2016 at 00:56, Pedro Vicente
<pedro.vice...@space-research.org> wrote:
> Alan
>
> All my linux failures were on 3 different "real" machines (CentOS with
> personal wxwidgets 3.1 build, 2 ubuntus 14.04 16.4 from packages)
>
> the 4th linux failure was on a debian I installed on VirtualBox.
> So, it's not a VirtualBox issue.
> -Pedro
>
>
> - Original Message - From: "Alan W. Irwin"
> <ir...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
> Sent: Thursday, December 15, 2016 7:05 PM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> On 2016-12-15 17:19-0500 Pedro Vicente wrote:
>>
>>> Hi Phil
>>>
>>>
>>>>> I can't help feeling that there is something that we are missing here.
>>>>> Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>>>> something different between the two systems.
>>>
>>>
>>> it seems so.
>>> the only way to be sure is that on your side to install a completely new
>>> Ubuntu, or Debian on VirtualBox, and then do
>>>
>>> sudo apt-get install libwxgtk3.0-dev
>>>
>>> VirtualBox can be installed on Windows or Mac (this is called the host
>>> system).
>>> I am running it on my Windows machine and I have three linux installed on
>>> it , ubuntu, centos, debian
>>
>>
>> @ Phil and Pedro:
>>
>> I am beginning to wonder whether something that is being done
>> differently but legitimately by VirtualBox is highlighting some subtle
>> bug we have in the Linux wxwidgets code that doesn't happen to show any
>> symptoms for the non-VirtualBox'd case.
>>
>> @Phil:
>>
>> I am just going to go ahead and merge Pedro's patch (once he gets it
>> to me in "git format-patch" form) to SF master since it apparently
>> solves his "VirtualBox" issue (if we can call it that) without messing
>> up the Linux success we have on non-VirtualBox'ed Linux.  But if you
>> have any qualms about his changes, feel free to either contact me
>> immediately (if you are not sleeping now) or ask me to revert my merge
>> of his work tomorrow.
>>
>> 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
>> __
>>
>
#include 

class myFrame : public wxFrame
{
public:
	myFrame();
	~myFrame();
private:
	void OnCreate(wxWindowCreateEvent& event);
	//DECLARE_EVENT_TABLE();
};

class MyApp : public wxApp
{
public:
	virtual bool OnInit();
};

IMPLEMENT_APP(MyApp);

bool MyApp::OnInit()
{
	myFrame* frame = new myFrame();
	frame->Create(NULL, wxID_ANY, "My Frame");
	frame->Show();
	return true;
}

//BEGIN_EVENT_TABLE(mainFrame, wxFrame)
//END_EVENT_TABLE()

myFrame::myFrame()
{
	Connect(wxEVT_CREATE, wxWindowCreateEventHandler(myFrame::OnCreate));
}

void myFrame::OnCreate(wxWindowCreateEvent& event)
{
	wxMessageBox( "OnCreate called" );
}

myFrame::~myFrame()
{
}--
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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

Unfortunately I don't think I have enough space to install virtualbox.
I presume I need a few 10s of GB for an Ubuntu install?

I have also just tried on the Bash on Ubuntu on Windows (still trying
to decide if I like this or Cygwin best. Anyway...). Again everything
works fine on this (I'm using Xming for my X server).

Is there something different with the X server or something in a
VirtualBox install?

I suspect that you are correct Alan and this is a subtle VitualBox
thing. We should create a minimum working example of a wxFrame using
the two stage creation totally independent of plplot and see if this
works. If it doesn't then we know this is a VirtualBox/wxWidgets bug.
If it does then we can start adding complexity to find where it
breaks.

On 16 December 2016 at 00:05, Alan W. Irwin  wrote:
> On 2016-12-15 17:19-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>>
 I can't help feeling that there is something that we are missing here.
 Given both I and Pedro have tested on Ubuntu 14.04 there must be
 something different between the two systems.
>>
>>
>> it seems so.
>> the only way to be sure is that on your side to install a completely new
>> Ubuntu, or Debian on VirtualBox, and then do
>>
>> sudo apt-get install libwxgtk3.0-dev
>>
>> VirtualBox can be installed on Windows or Mac (this is called the host
>> system).
>> I am running it on my Windows machine and I have three linux installed on
>> it , ubuntu, centos, debian
>
>
> @ Phil and Pedro:
>
> I am beginning to wonder whether something that is being done
> differently but legitimately by VirtualBox is highlighting some subtle
> bug we have in the Linux wxwidgets code that doesn't happen to show any
> symptoms for the non-VirtualBox'd case.
>
> @Phil:
>
> I am just going to go ahead and merge Pedro's patch (once he gets it
> to me in "git format-patch" form) to SF master since it apparently
> solves his "VirtualBox" issue (if we can call it that) without messing
> up the Linux success we have on non-VirtualBox'ed Linux.  But if you
> have any qualms about his changes, feel free to either contact me
> immediately (if you are not sleeping now) or ask me to revert my merge
> of his work tomorrow.
>
>
> 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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

[Phil Rosenberg]

Hi Pedro, Alan
I'm still unable to reproduce the problem on my Ubuntu 14.04 system
with wxWidgets 3.0. Very strange. I have tried a totally fresh build
directory and static and dynamic builds.

I had forgotten to test on my work CentOS PC and although I know it is
powered on I can't ssh into it. I'm not sure why. I will test it when
I get in tomorrow.

I can't help feeling that there is something that we are missing here.
Given both I and Pedro have tested on Ubuntu 14.04 there must be
something different between the two systems.

Phil

On 15 December 2016 at 15:22, Pedro Vicente
 wrote:
> Hi Alan
>
> I installed the latest from the debian site, here
>
> https://www.debian.org/distrib/
>
> it's not surprising that I got the same results in ubuntu because I used the
> same package
>
> sudo apt-get install libwxgtk3.0-dev
>
>
>
>
> On 2016-12-15 04:32, Alan W. Irwin wrote:
>>
>> On 2016-12-15 01:11-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>> I just installed the latest debian on VirtualBox, and I get the same
>>> errors.
>>> the results are attached, same thing that I did for ubuntu.
>>
>>
>> Hi Pedro:
>>
>> Just for the record, what version of Debian?
>>
>> Currently Jessie = stable (a largely frozen release from two years
>> ago), Stretch = testing (a rolling release not as stable as stable),
>> and Sid = unstable (another rolling release not as stable as testing).
>> Stretch has turned or will turn soon into a frozen distribution
>> similar to Jessie but two years more modern and be designated stable
>> likely sometime in 2017.  Jessie will be redesignated as oldstable at
>> that Debian release epoch, and Sid is always going to be unstable.
>> :-)
>>
>> So if you installed Jessie, I would be officially amazed you cannot
>> replicate my good results there.  But if Stretch or Sid, then those
>> are quite different, and all bets are off.
>>
>>> it seems that something on your debian is preventing this error,
>>> but you should be able to verify this by just installing a new debian (or
>>> any linux , it seems) on VirtualBox.
>>
>>
>> Half my computer memory fried itself a year or so ago so my computer
>> (already 9 years old but with ASUS motherboard, Intel CPU's, new
>> disks, and new power supply still doing pretty well) is a little short
>> of memory. Thus, I don't plan to look at VirtualBox at the moment, but
>> when (if?) one of my motherboard, CPU's, or remaining RAM die so that
>> I really do have to replace all three, I intend to buy a huge amount
>> of memory for the new system so I can play with VirtualBox with ease.
>>
>> 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
>> __
>
>
> --
> Pedro Vicente
> pedro.vice...@space-research.org
> http://www.space-research.org/

--
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

[Plplot-devel] plbuffer bug

[Phil Rosenberg]

Hi All
I've just posted a bug to the bug tracker regarding  the buffer.

I just wanted to send an email out to say that I don't particularly
intend to fix it before the freeze as I don't think there is time. But
I wanted to stick it on the tracker so it didn't get forgotten.

The problem is that text is written and read in "device native"
encoding (i.e. Unicode or ascii) so if a buffer is copied from a
Unicode device to an ascii one then the plreplot call will hit a
problem with buffer reading and call plexit. The solution would be to
always write Unicode or to add a flag to indicate the encoding in the
buffer. If anyone has a preference then let me know.

Phil

--
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

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

[Phil Rosenberg]

Hmm
And the fact that the wx libraries that were found have the suffix u,
suggests they were built with Unicode support. Perhaps the compile
issue you had was because plplot was not built with the Unicode flag
on. As I said instructions are on the wiki to do this for a visual
studio build at
https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/,
but I don't know how one would do it in MSYS. Perhaps setting the same
flags would do it.

Phil

On 11 December 2016 at 10:23, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> On 2016-12-10 01:11-0000 Phil Rosenberg wrote:
>
>> I'm sorry Laurent, but I think I am the main Windows user on the list
>> and I have absolutely no experience with MSys.
>>
>> However, I believe we have now returned to the CMake default wxWidgets
>> find module. Alan, can you comment on this and whether this looks like
>> a bug in that module or a bug in our build system?
>
>
> @ Phil and Laurent:
>
> Yes, we are using the absolutely latest official CMake wxWidgets find
> module that is heavily maintained by the CMake developers.  So I doubt
> there are any obvious bugs in that find module.
>
> @Laurent:
>
> My apologies for not answering sooner but I was otherwise occupied with
> other issues currently being discussed on the PLplot devel list.
>
> The short explanation of the message you were getting is that our build
> system gets a list of libraries from the official find module.  Some of
> those are actual locations, and some are in the -L...-l... form.  So we
> transform the latter to actual location by looking for the library
> using the find_library command, and for some reason some of those
> could not be found.  The cure for this is to identify the libraries
> that were not found from comparing the old and transformed lists, then
> installing the relevant libraries or adjust environment variables
> such as PATH and/or CMAKE_LIBRARY_PATH to help CMake find the
> relevant libraries.
>
> I must say, however, that the comparison of the two lists given to you
> is a far less than optimal way to find what libraries could not be
> found so I plan in the next few days to update that part of our build
> system to make this WARNING message a lot clearer.
>
> For now, though, you are stuck with correlating the following two
> lists (i.e., search for a NOTFOUND result on the second list and find
> from its position what -l form it corresponded to in the orignal list)
> to find what libraries are missing.
>
>>> cmake_link_flags WARNING: (original link flags) =
>>>
>>> -L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32
>>>
>>> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS =
>>>
>>> -Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;F:/mingw-w64/Strawberry/c/lib/libz.a;C:/Windows/System32/rpcrt4.dll;C:/Windows/System32/oleaut32.dll;C:/Windows/System32/ole32.dll;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;C:/Windows/System32/winmm.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/shlwapi.dll;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;C:/Windows/System32/advapi32.dll;C:/Windows/System32/version.dll;C:/Windows/System32/wsock32.dll;C:/Windows/System32/gdi32.dll
>
>
> To make the explanation simpler, let me break down both lists at the
> semicolons:
>
> That means original =
>
>
> -L/f/lib/wxWidgets-3.1.0/lib;
> ;
> ;
> -Wl,--subsystem,windows;
> -mwindows;
> /f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;
> /f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;
> -lwxregexu-3.1;
> -lwxexpat-3.1;
> -lwxtiff-3.1;
> -lwxjpeg-3.1;
> -lwxpng-3.1;
> -lz;
> -lrpcrt4;
> -loleaut32;
> -lole32;
> -luuid;
> -lwinspool;
> -lwinmm;
> -lshell32;
> -lshlwapi;
> -lcomctl32;
> -lcomdlg32;
> -ladvapi32;
> -lversion;
> -lwsock32;
> -lgdi32
>
> Transformed = -Wl,--subsystem,windows;
> -mwindows;
> /f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;
> /f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;
> _library_pathname-NOTFOUND;
> _library_pathname-NOTFOUND;
> _library_pathname-NOTFOUND;
> _library_pathname-NOTFOUND;
> _library_pathname-NOTFOUND;
> F:/mingw-w64/Strawberry/c/lib/libz.a;
> C:/Windows/S

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Phil Rosenberg]

Hi Pedro
I have included the devel list on this email, so the thread will get
documented on the mailing list.

It is very strange that the OnCreate function is not being called. If
you are calling Create then you should be generating a create event.
Am I correct in saying that you are getting this segfault with the
unchanged demo app?

This location really is the best (and maybe only) place this
initialisation should be done. It cannot be included in the
constructor, because the generic nature of the template specification
means the code in the constructor does not know which type of wxWindow
we are inheriting from so cannot pass the correct parameters to the
constructor. By the time OnPaint is called it is really too late,
because we would like to already have the plot initialised and ready
to draw and it would be a real pain for you in your code if you had to
somehow wait for the first paint or resize event.

I do have access to a CentOS machine at work, although I think I have
only got access to wxWidgets 2.8 on that system. I will check. I may
be able to build 3.1 from source. I presume you are using 3.1.0 as
released in February, rather than the head of the master branch?

On 10 December 2016 at 07:52, Pedro Vicente
<pedro.vice...@space-research.org> wrote:
> Hi Phil
>
> My idea for a fix is to move the stream initialization that is now  on
>
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
> {
> if ( !m_created )
>
> either to the OnSize or onPaint events
>
> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>
> and also in the plot call do this
>
> template< class WXWINDOW >
> void Plot( wxPLplotwindow *plotwindow )
> {
>wxPLplotstream* pls = plotwindow->GetStream();
>
>if (pls == NULL)
>{
>  return;
>}
>
>
> Like this , in this sequence
>
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>frame->SetIcon( wxIcon( graph ) );
>frame->Show();
>Plot( frame );
>
>
> first we go to
> Plot( frame );
>
> but the stream is NULL because
> :OnCreate
> was not called, but the function returns, avoiding the seg fault
>
> then the window gets a paint or size event, and the stream initialization
> code is called
> at this time I have a PLplot empty black window
>
> but because
> Plot( frame );
> was only called at start, it is not called again, so there is no draw
>
> any ideas here ?
>
> of course making the Plot() call in another app function should work
>
>
> If you could replicate this issue, that would be great.
> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>
>
>
>
>
> - Original Message - From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Saturday, December 10, 2016 12:59 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, the issue seems to be the same that I have been reporting
>
>
> In the wxPLplotDemo.cpp code you have these callling functions
>
>
> wxPLplotwindow *frame = new wxPlDemoFrame();
> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>
>
> that make 2 calls to the PLplot library, or the wxWidgets driver of it
> all these calls are in the header file wxPLplotwindow.h
>
> first the constructor is called
>
> template
> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
> clientSize )
>: m_created( false ), m_initialSize( clientSize )
>
>
> then this call OnCreate() is called, like you mentioned
> and the !m_created bool makes the initialization of the stream happen
>
> the problem is  that this function id *NOT* called on my linux build (it is
> on the Windows build)
> so therefore later
> wxPLplotstream* pls = plotwindow->GetStream();
>
> this is NULL, so therefore it seg faults on the plot calls
>
> //! This is called when the widow is created i.e. after WXWINDOW::Create
> // has been called. We note that this has been called to avoid attempting
> // to redraw a plot on a window that hasn't been created yet.
> template
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
> {
> if ( !m_created )
>
> so, one quick try is to put the code of
>
> void wxPLplotwindow::OnCreate
> that is not called on the constructor maybe ?
>
> -Pedro
>
> - Original Message - From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Friday, December 09, 2016 11:57 PM
> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, resuming the last thread about wxWidgets, what I did was to build and
> run wxPLplotDemo.cpp from PLpplot 5

[Plplot-devel] Too late for bug fix changes

[Phil Rosenberg]

Hi Alan
I have recently discovered a couple of bugs in the wxWidgets driver.

One is rather a feature of wxWidgets instead of a bug. It turns out
that when constructing a font with size 70 pt you actually get the
default system font size. I found this when doing an animated plot
today with points that shrank with time. I got a weird jump in size
when they got to 7 pt.
This cause is that in wxWidgets there is a constant used to say you
want the default system size, but instead of using a sensible value
like -1 for this constant it is set to be 70. Unfortunately the wx
devs have said they will not fix this as that constant is too deeply
ingrained in the code to change it safely. There is a workaround
though. And I've added that to my local copy.

I also found a bug in the device code. There is a positional error
with text that occurs when the style changes midway along a line (eg
through use of #u or #d). Again I have fixed this in my local copy.

There is also a positional error which occurs when a style change
occurs midway through a line and that line has been rotated. Basically
the start position of the differently styled chunk of text appears to
need rotating if you see what I mean. I think this just requires a
minor change to fix, but I haven't done it yet. Hopefully tomorrow.

There are also the map issues that were reported on here a few weeks ago.

I just wanted to check if it is too late to submit these. Fixes now?

Phil

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake

[Phil Rosenberg]

Hi Pedro
I'm sorry but I'm not sure I understand the point at which you get the segfault.

However, I think you are trying to call GetStream, before the stream
has been created. The stream requires the window's device context at
the point of creation, in order for the device context to exist the
window must have been "Create"d. Often this is done by the
constructor, but in this case to maintain generality the default
wxWindow constructor is called which takes no parameters and does not
create the window. An explicit call to wxSomeWindowType::Create is
required - only once that has happened does the device context exist
allowing the stream to be created.

It would actually be very easy to have something like

class myPlFrame :public wxPlWindow
{
};

then have
myPlFrame::myPlFrame(/*All the variables needed to initialise a wxFrame*/)
{
Create(/*The varibles from above*/);
}

Then you can call GetStream immediately after construction.

On 9 December 2016 at 03:27, Pedro Vicente
 wrote:
> Alan, Thanks
> Phil (I am CC you here, because this is a wxdriver issue;
> not saying that is a bug in the wxdriver, just a code error I have in my use
> of it )
>
> The issue was not lack of -g, but just a code issue
>
> I am following almost verbatim the demo wxPLplotDemo.cpp
>
> what happens in my code is that
>
> pls is NULL
>
> here
>
> void Plot(wxPLplotwindow *plotwindow)
> {
>  wxPLplotstream* pls = plotwindow->GetStream();
>
> so all pls-> calls seg fault
>
>
> what happens is that this function is *not* called
>
>
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
> {
>if ( !m_created )
>
>
> and it should have been in these calls
>
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>  frame->Create(NULL, wxID_ANY, wxT("wxPLplotDemo"));
>  frame->Show();
>  Plot(frame);
>
>
> This only happens in Linux, on Windows all is fine
>
>
> so, I'll keep on debugging to see what is happening
>
>
> by the way, since I am here, I have 2 small requests:
>
> 1) the wxdriver compilation has a couple of compiler warnings, would it be
> possible to eliminate them ?
> 2) would it be possible to keep in the upcoming version the old deprecated
> wxdriver code that is not templated ?
> I find templated code difficult to follow and debug, and here there is no
> benefit in using it , because all my plots are in wxFrame
>
> these are the warnings
>
>
> M:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(181): warning C4100: 'event':
> unreferenced formal parameter (compiling source file wx_explorer_star.cpp)
>  M:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(182): note: while compiling
> class template member function 'void
> wx_PLplotwindow::OnCreate(wxWindowCreateEvent &)' (compiling
> source file wx_explorer_star.cpp)
>  wx_explorer_star.cpp(860): note: see reference to class template
> instantiation 'wx_PLplotwindow' being compiled
> m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4701:
> potentially uninitialized local variable 'drawDc' used
> m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4703:
> potentially uninitialized local pointer variable 'drawDc' used
>
> for the first you can use the
> WXUNUSED
> macro
>
> like in
> void wxFrameClient::OnQuit(wxCommandEvent& WXUNUSED(eve))
>
> the others seem that you should see
>
> m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4701:
> potentially uninitialized local variable 'drawDc' used
> m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4703:
> potentially uninitialized local pointer variable 'drawDc' used
>
>
> it says that the variables are not initialized and are potencially used
>
>
> -Pedro
>
> - Original Message - From: "Alan W. Irwin"
> 
> To: "Pedro Vicente" 
> Cc: 
> Sent: Thursday, December 08, 2016 1:59 PM
> Subject: Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake
>
>
>> On 2016-12-08 01:52-0500 Pedro Vicente wrote:
>>
>>>
>>> Hi Alan
>>>
>>> I have a wxWidgets application that I developed for Windows and Linux
>>> that uses PLplot .
>>>
>>> I started having a segfault on the *Linux* only version.
>>>
>>> Debugging in Windows is a breeze with Visual Studio.
>>>
>>> For Linux I was able to make a QtCreator project to debug (yes, Qt
>>> debugging wxWidgets !)
>>>
>>> However when I try to step into the PLplot code, there is no step into,
>>> because probably debugging symbols were not built
>>>
>>> I used the following cmake call
>>>
>>> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
>>> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF  -DENABLE_tk:BOOL=OFF
>>> -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1
>>> -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON
>>> -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0
>>> 

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

[Phil Rosenberg]

I'm sorry Laurent, but I think I am the main Windows user on the list
and I have absolutely no experience with MSys.

However, I believe we have now returned to the CMake default wxWidgets
find module. Alan, can you comment on this and whether this looks like
a bug in that module or a bug in our build system?

On 8 December 2016 at 16:37, Laurent Berger
 wrote:
> Hi,
>
> I want to buil plplot in static using MSYS makefiles on windows 10.
>
> In cmake GUI i have got an error that I cannot understand. wxWidgets is
> found but there is cmake_link_flags WARNING.
>
> Any help would be appreciate.
>
> CMake version = 3.7.0-rc2
>
> CMAKE_SYSTEM_NAME = Windows
>
> SH_EXECUTABLE = C:/Windows/System32/bash.exe
>
> Looking for gdi32 header and library
>
> Looking for gdi32 header and library - found
>
> wxWidgets_FOUND : TRUE
>
> wxWidgets_INCLUDE_DIRS :
> F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include
>
> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
>
> wxWidgets_LIBRARIES :
> -L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32
>
> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
>
> wxWidgets_USE_FILE : UsewxWidgets
>
> cmake_link_flags WARNING: (original link flags) =
> -L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32
>
> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS =
> -Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;F:/mingw-w64/Strawberry/c/lib/libz.a;C:/Windows/System32/rpcrt4.dll;C:/Windows/System32/oleaut32.dll;C:/Windows/System32/ole32.dll;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;C:/Windows/System32/winmm.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/shlwapi.dll;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;C:/Windows/System32/advapi32.dll;C:/Windows/System32/version.dll;C:/Windows/System32/wsock32.dll;C:/Windows/System32/gdi32.dll
>
> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set to
> nothing to signal the failure of cmake_link_flags for the original link
> flags printed out above.
>
> WARNING: wxWidgets or its libraries not found so setting all wxwidgets
> devices to OFF.
>
> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Deprecated wxWidgets error

[Phil Rosenberg]

Hi Pedro
As Alan said, we can't have both working together. Well, I suppose we
could, but the effort required would be large and time is finite. If
you are interested in the usage differences then:

The new wx backend discarded use of AGG and freetype as wxWidgets now
has much better support for antialiased graphics and text. This also
massively simplifies support.

For calling from a wxWidgets application the wxPlplotwindow class is
now template, meaning it can inherit from any wxWindow - so as well as
having a plplot panel, you can have anything from a plplot frame to a
plplot button should you wish.

For calling wxWidgets from a console application all the rendering is
performed in a separate utility which has commands sent from the
console application. This removes some problems we had with large
amounts of almost duplicated, but subtly code, plus possible threading
issues. Unfortunately there at performance issues that I haven't been
able to get to the bottom of yet.

Lastly, some of the less well used features of Plplot are not yet
supported, like maybe changing the fill algorithm. But certainly all
the well used things are there.

So basically, unless you really want to use AGG or FreeType, then I
don't see much need to use the deprecated version. I certainly won't
be going back and fixing any bugs in the deprecated version. If,
however, there is some feature that is still missing from the new
version then let me know and I'll try to prioritise.

Phil

On 9 December 2016 at 21:45, Alan W. Irwin  wrote:
> On 2016-12-09 15:39-0500 Pedro Vicente wrote:
>
>> so, it seems that the cmake option is really needed
>> -DOLD_WXWIDGETS=ON
>>
>> I only found out this by reading the script
>
> Reading the script is an excellent idea so I encourage you to keep doing
> that.  However, we also document such changes in our release notes.
> In this case you won't find that documentation in README.release
> because OLD_WXWIDGETS was introduced in a previous release.  So
> instead you have to look in the cumulated old release notes,
> OLD-README.release for the relevant documentation of
> -DOLD_WXWIDGETS=ON.
>
> [...]
>
>> I have a request, would it be possible to have the "deprecated"
>> wxWidgets code and the templated one at the same time?
>
> No.  If you want access to both for comparisons, use separate build
> trees (and install trees).  Also, -DOLD_WXWIDGETS=ON is deprecated
> because it is an emergency measure which gives you access to the old
> frozen wxwidgets code. There is no further support for
> -DOLD_WXWIDGETS=ON beyond that because that old wxwidgets code was not
> Phil's responsibility and there are lots of known issues with it. So
> Phil is focussing exclusively on development of the new wxwidgets.
> Thus, if you find some features you like with -DOLD_WXWIDGETS=ON, then
> ideally you should make changes to your local _new_ wxwidgets to add
> that feature and send patches (ideally generated by "git
> format-patch") to this list for Phil to evaluate.  N.B. it is a
> virtual certainty your patch will be rejected if it contains fixes for
> multiple issues.  So instead each of your individual patches should
> focus on just one logical issue at a time.  And sometimes we do reject
> ideas such as yours above to have both old and new wxwidgets in the
> same build tree.  But so long as your patches are focussed on one
> thing at a time (and not necessarily limited to just the new
> wxwidgets) and otherwise acceptable, then such development help with
> PLplot would be much appreciated.  (Note, we recommend "git
> format-patch" for generating patches because that gives you full
> credit for your work in the git log.)
>
> 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
> __
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Developer Access Program for Intel Xeon Phi Processors

Re: [Plplot-devel] The wxwidgets device driver speed/idle time

[Phil Rosenberg]

Hi Alan
It's on my list - I will do it as soon as I can :-). I actually think
I had a similar system like this set up - although I think I used
named semaphores. I would have to go back to the code to check.

Phil

On 19 November 2016 at 07:39, Alan W. Irwin  wrote:
> Hi Phil:
>
> I got tired of speculating about more efficient Linux IPC methods so I
> implemented (as of commit e166866) the "Unnamed semaphores example"
> paradigm outlined starting on page 73 of
> . (I
> discussed this possibility in earlier versions of this thread.)
> This test project is described in cmake/test_linux_ipc/README.  Follow
> the directions there to test it on your own Linux systems.
>
> My tests show this method is quite efficient for transferring data
> between processes on POSIX-compliant systems.  The transfer process is
> under complete control of unnamed semaphores that reside in the shared
> memory so coordinating required data transfer between two applications
> is completely straightforward, and there is very little idle time
> required during these transfers.
>
> The IPC-relevant routines that are called in this test project are
> shm_open, ftruncate, mmap, sem_init, sem_wait, sem_post, and
> shm_unlink, and according to the Linux man pages, all of these
> functions are provided by platforms that are compliant with POSIX.1-2001.
>
> So on the present evidence from this test project I think this method
> looks extremely promising for efficiently transferring data both ways
> between -dev wxwidgets and wxPLViewer for POSIX-compliant systems.
>
> If after trying the test of the method documented in
> cmake/test_linux_ipc/README you agree with this assessment, would you
> be willing to have a go at the required wxwidgets and wxPLViewer
> source code changes to see if that essentially eliminates the
> large idle times we have now on Linux?
>
>
> 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
> __

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change thedefault blackbackground

[Phil Rosenberg]

Hi Pedro
Glad you have things working. I believe Alan is close to having a new
release of Plplot so I'm not sure if now is a suitable time to
introduce new features, but I will add overloads of the Create
function to my to do list for early in the next release cycle.

Regarding the old version. There are very significant behind the
scenes changes to help with code management. The old device is no
longer being actively worked on. The driver for putting things in a
template is that it means that you can have a plplot window based on
any kind of wxWindow. Of course most often we create a wxPanel, but
the example uses a wxFrame as does your code and if you really wanted
you could create a wxPLplotwindow or if someone in the
future generated a wxAcceleratedGraphicsWindow that used OpenGL then I
guess that could be rendered to as well - or at least it wouldn't mean
an API change to make use of it.

Phil

On 9 October 2016 at 06:19, Pedro Vicente
<pedro.vice...@space-research.org> wrote:
> Hi Phil
>
>> Traditionally colour 0 has always been the background colour, so
>> plscol0 passing in colour 0 is the same as plscolbg. You should use
>> plcol(1) or upwards for rendering.
>
>
> ok, I understand now, it seems it was just me trying to redefine color index
> 0 2 times , and there is no need to
>
> this code worked for me (white background with color 0, black plot with
> color 1)
>
> bool wxAppPlot::OnInit()
> {
>  wx_PLplotwindow *frame = new wx_PLplotwindow();
>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>wxDefaultPosition,
>wxSize(900, 700));
>  frame->Show();
>
>  wx_PLplotstream* pls = frame->GetStream();
>  pls->init();
>
>  pls->adv(0);
>  pls->scol0(0, 255, 255, 255);
>  pls->clear();
>  pls->scol0(1, 0, 0, 0);
>
>  //render
>
>  plot_window(frame);
>  return true;
> }
>
> Note here that I am using my modified version "wx_PLplotstream" that does
> not call
> init();
>
> but I am calling init(); right at start , so this is the same I think of
> using the regular class "wxPLplotstream"
>
> so, my confusion came because I was convinced that to modify the background,
> this had to be done *before* calling
> init();
>
> but it seems we don't have to do it that way, is that right ?
>
> the documenation says that it is needed
>
> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/color.html
>
> "There are a number of options for changing the default red on black colors.
> The user may set the index 0 background color using the command-line bg
> parameter or by calling plscolbg (or plscol0 with a 0 index) before plinit.
> During the course of the plot, the user can change the foreground color as
> often as desired using plcol0 to select the index of the desired color. "
>
> or is just this sequence of calls that makes it not necessary to do it
> before init() ?
>
> pls->adv(0);
>  pls->scol0(0, 255, 255, 255);
>  pls->clear();
>  pls->scol0(1, 0, 0, 0);
>
>
>> I don't think I can or should remove the plinit call in
>> wxPLstream::Create because I think that has been there a long time and
>> would break other users' existing code.
>
>
> ok, understood, that makes sense , yes
>
>> However I could overload the
>> Create function so that it accepts some extra initialisation variables
>> such as background colour.
>
>
>
> that would be a must have if the only way to change the background was to do
> it before init()
> but since it seems that is not needed so not really a must have
>
> but maybe there are other things that can only be done before  init()
>
> by the way, I have a small request , is that possible to keep the
> "deprecated" wxWidgets classes around?
>
> it seems the only difference is that new wxWidgets is the use of templates
> as in
>
> template< class WXWINDOW >
> void plot_window(wx_PLplotwindow *plotwindow);
>
> my experience with templates is that they make the code more difficult to
> track and find bugs
>
> Maybe merge the "deprecated" wxWidgets and the new one just into one file or
> class and give the option to use either one (don't know
> if this makes sense)
>
>
>
> -Pedro
>
>
>
> - Original Message - From: "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>
> Cc: <plplot-gene...@lists.sourceforge.net>;
> <plplot-devel@lists.sourceforge.net>
> Sent: Friday, October 07, 2016 7:51 AM
>
> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
> thedefault blackbackground
>

Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change thedefault blackbackground

[Phil Rosenberg]

Hi Pedro
Traditionally colour 0 has always been the background colour, so
plscol0 passing in colour 0 is the same as plscolbg. You should use
plcol(1) or upwards for rendering. In some ways it is up to you how
you do that. You can either set up you pallet at the beginning using
plscol0 or plscsol0a then use plcol0(1), plcol0(2) etc, or you can
just always use plscol0(1), but use repeated calls to plscol0 or
plscol0a to keep changing colour 1.

Do you happen to call plenv() after setting colour 0 to black again? I
have a feeling that plenv() may clear the page again. But I'm not
sure. If you are still haing problems using colours 1 and above for
drawing then let us know and I'll have a further look.

I don't think I can or should remove the plinit call in
wxPLstream::Create because I think that has been there a long time and
would break other users' existing code. However I could overload the
Create function so that it accepts some extra initialisation variables
such as background colour.

Phil

On 6 October 2016 at 16:41, Pedro Vicente
<pedro.vice...@space-research.org> wrote:
> Phil
>
>
> I believe there is stiil an issue with this solution
>
> my sample worked because I had
>
> plcol0(8);
>
> that does the plot in brown color
>
> if I try to plot in black color (on white bacground now) by doing
>
> plcol0(0);
>
> then I have no plot, since color 0 is now white
>
> is there a way with this solution to define color 0 as black for the plot?
>
> I tried to call
>
> plscol0(0, 0, 0, 0);
>
> as
>
> wxPLplotstream* pls = plotwindow->GetStream();
>  pls->adv(0);
>  pls->scolbg(255, 255, 255);
>  pls->clear();
>  plscol0(0, 0, 0, 0);
>
> but like this I have the default red on black again
>
>
> for now, the way I was able to have the black on white background was to
> replicate all the code
> of
> wxPLplotwindow
> wxPLplotwindow
>
> into new classes , giving them another name, commenting the init() call on
> them and then
> doing this code (note that the classes are renamed to wx_PLplotwindow and
> wx_PLplotstream)
>
>
>
>
> bool wxAppPlot::OnInit()
> {
>  wx_PLplotwindow *frame = new wx_PLplotwindow();
>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>wxDefaultPosition,
>wxSize(900, 700));
>  frame->Show();
>
>  //set background color (0) to white RGB(255,255,255)
>  //must be called before plinit()
>  plscolbg(255, 255, 255);
>
>  wx_PLplotstream* pls = frame->GetStream();
>  pls->init();
>
>  //change color (0) to black RGB(0, 0, 0)
>  //must be called after plinit()
>  plscol0(0, 0, 0, 0);
>
>  Plot(frame);
>  return true;
> }
>
> /
> //Plot
> /
>
> template< class WXWINDOW >
> void Plot(wx_PLplotwindow *plotwindow)
> {
>  wx_PLplotstream* pls = plotwindow->GetStream();
>
>  //render
>  const int NSIZE = 101;
>  PLFLT x[NSIZE], y[NSIZE];
>  PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>
>  for (int i = 0; i < NSIZE; i++)
>  {
>    x[i] = i;
>y[i] = 5;
>  }
>
>  plschr(0, 1.0);
>  plcol0(0);
>  plenv(xmin, xmax, ymin, ymax, 0, 0);
>  pllab("x", "y", "Label");
>  plpoin(NSIZE, x, y, 46);
>
>  plotwindow->RenewPlot();
> }
>
>
>
>
> - Original Message - From: "Pedro Vicente"
> <pedro.vice...@space-research.org>
> To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
> Cc: <plplot-gene...@lists.sourceforge.net>;
> <plplot-devel@lists.sourceforge.net>
> Sent: Thursday, October 06, 2016 10:44 AM
>
> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
> thedefault blackbackground
>
>
>> Hi Phil, Alan
>>
>> This solution worked for me, thanks
>>
>>
>>> The easiest way to do this at the moment is something like
>>>
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>> pls->adv( 0 );
>>> pls->scolbg(255, 255, 255);
>>> pls->clear();
>>> //rest of your plotting code
>>
>>
>>
>>
>>> I'm very open to better ways
>>> to do this if you have suggestions.
>>
>>
>> The only suggestion I have is the one I sent on my previous mail, that
>> was *not* to have
>>
>> wxPLplotstream::Create
>>
>> call
>>
>> init()
>>
>> and let the user do that on his application.
>>
>>
>> By looking at the samples, I bel

Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change the default blackbackground

[Phil Rosenberg]

Hi Pedro
The easiest way to do this at the moment is something like

wxPLplotstream* pls = plotwindow->GetStream();
pls->adv( 0 );
pls->scolbg(255, 255, 255);
pls->clear();
//rest of your plotting code

If you have multiple subpages then you will need to do this on each
page. Also if your subpages don't cover all the windows then you can
call the SetBackgroundColour method of wxPLplotwindow and this will
clear the whole window to the given colour initially.

Hope that helps. If not then let me know. I'm very open to better ways
to do this if you have suggestions.

Phil


On 6 October 2016 at 06:00, Pedro Vicente
 wrote:
>
> so, there are at least 2 solutions for this :
> 1) the quick is just to modify the PLplot source code , in the call to
>
> void wxPLplotstream::Create
>
> comment the call to
>
> //init();
>
> then in our app code , do the init() call after Create() . as
>
> ~~~
> bool wxAppPlot::OnInit()
> {
>   wxPLplotwindow *frame = new wxPLplotwindow();
>   frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
> wxDefaultPosition,
> wxSize(900, 700));
>   frame->Show();
>
>   //set background color (0) to white RGB(255,255,255)
>   //must be called before plinit()
>   plscolbg(255, 255, 255);
>
>   wxPLplotstream* pls = frame->GetStream();
>   pls->init();
>
>   //change color (0) to black RGB(0, 0, 0)
>   //must be called after plinit()
>   plscol0(0, 0, 0, 0);
>
>   Plot(frame);
>   return true;
> }
> ~~~
>
>
> since it seems the only way to modiy the background color is to do the above
> sequence
> this is a change that I recommend to be included in the libray, since I
> believe the other drivers require a call to init() too, but not the
> wxWidgets driver.
>
> 2) not modifying the source code. In this case , I think it should be
> possible to derive 2 classes ,
> a) one from wxPLplotwindow
> b) other from wxPLplotwindow
>
> then do everything in those classes as now except the call to init()
>
>
> but if the developers could do option 1) that probably would be the best
> thanks
>
>
> -Pedro
>
>
>
>
> - Original Message -
> From: Pedro Vicente
> To: plplot-gene...@lists.sourceforge.net
> Sent: Wednesday, October 05, 2016 6:42 PM
> Subject: [Plplot-general] wxWidgets driver -- change the default
> blackbackground
>
> Hi
>
>
> I am trying to change the default black background color using the wxWidgets
> driver
>
> If using the SVG driver this can be done as explained here
>
> https://sourceforge.net/p/plplot/mailman/message/2817799/
>
> the trick being calling
>
> plscolbg()
>
> before
>
> plinit();
>
> like the  sample code below marked "SVG Driver" does
>
>
> However for the wxWidegts driver , it seems we do not do a call to
>
> plinit();
>
> but rather this is done inside the C++ stream initialization
>
> From the wxWidgets PLplot sample below
>
> the
>
> plinit();
>
> is made inside
>
>
>
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>
>
> so I don't find a way to call the plscolbg() function before
>
>
> How can this be accomplished ?
>
>
>
>
> I also tried to modify the default colors of the default palette
>
> cmap0_default.pal
>
> 16
> #00
>
> so that the first is white
>
> this does work *but* only after the window is redrawn (it first shows the
> default red on black);
> this seems like a bug to me
>
>
> Also, what's the call to increase the font size?
> On the wxWidgets driver the font looks tiny
>
> Thanks !
>
>
> Sample code wxWidgets
>
>
>
> bool
>
> wxAppPlot::OnInit()
>
> {
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>
> frame->Create(
>
> NULL, wxID_ANY, wxT("wxPLplot"));
>
> frame->Show();
>
> Plot(frame);
>
> return true;
>
> }
>
> /
>
> //Plot
>
> /
>
> template
>
> < class WXWINDOW >
>
> void
>
> Plot(wxPLplotwindow *plotwindow)
>
> {
>
> wxPLplotstream* pls = plotwindow->GetStream();
>
> //render
>
> plotwindow->RenewPlot();
>
> }
>
>
>
>
> Sample code SVG driver
>
> void
>
> atms_dwell_granu_t::plot()
>
> {
>
> //set SVG device and output file name
>
> plsdev("svg");
>
> plsfnam("atms_dwell_granu.svg");
>
> //set background color (0) to white RGB(255,255,255)
>
> //must be called before plinit()
>
> plscolbg(255, 255, 255);
>
> //initialize plplot
>
> plinit();
>
> //change color (0) to black RGB(0, 0, 0)
>
> //must be called after plinit()
>
> plscol0(0, 0, 0, 0);
>
> /
>
> //render
>
> /
>
> PLFLT xmin, xmax, ymin, ymax;
>
> PLFLT *x, *y;
>
> const int NSIZE = iOrbit_all;
>
> xmin = 0;
>
> xmax = NSIZE;
>
> ymin = -1.0;
>
> ymax = 6.0;
>
> x =
>
> new PLFLT[NSIZE];
>
> y =
>
> new PLFLT[NSIZE];
>
> plcol0(0);
>
> 

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil Rosenberg]

Hi All
I have modified my the example that exposes the bug so that it works for
svg. Please find attached.

Phil

On 17 September 2016 at 21:57, Phil Rosenberg <p.d.rosenb...@gmail.com>
wrote:

> Hi Arjen
> I'm just emailing to say that I have now got plplot to compile with
> wxWidgets support on Cygwin and I also find that it doesn't function. I
> will look into it once I get time.
>
> On 16 September 2016 at 15:32, Arjen Markus <arjen.mar...@deltares.nl>
> wrote:
>
>> Hi Phil,
>>
>>
>>
>> As a package, definitely.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>
>>
>> *From:* Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
>> *Sent:* Friday, September 16, 2016 4:25 PM
>> *To:* Arjen Markus; Alan W. Irwin
>>
>> *Cc:* plplot-devel@lists.sourceforge.net
>> *Subject:* RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>
>>
>>
>> Hi Arjen
>>
>> I'm just trying to reproduce your Cygwin problems, but I can't get plplot
>> to build with wxWidgets on. Do you know if you installed wxWidgets as a
>> package or from source?
>>
>>
>>
>> Sent from my Windows 10 phone
>>
>>
>>
>> *From: *Arjen Markus <arjen.mar...@deltares.nl>
>> *Sent: *16 September 2016 08:08
>> *To: *Alan W. Irwin <ir...@beluga.phys.uvic.ca>; Phil Rosenberg
>> <p.d.rosenb...@gmail.com>
>> *Cc: *plplot-devel@lists.sourceforge.net
>> *Subject: *RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>
>>
>>
>> Hi Alan, Phil,
>>
>>
>>
>> I tried Phil’s example on Cygwin – PLplot as built on my installation
>> does have a wxWidgets driver – but unfortunately that fails to run:
>>
>>
>>
>> *** PLPLOT ERROR, ABORTING OPERATION ***
>>
>> unknown error in plD_init_wxwidgets., aborting operation
>>
>>
>>
>> *** PLPLOT ERROR, ABORTING OPERATION ***
>>
>> unknown error in plD_bop_wxwidgets., aborting operation
>>
>>
>>
>> *** PLPLOT ERROR, ABORTING OPERATION ***
>>
>> unknown error in plD_line_wxwidgets., aborting operation
>>
>> …
>>
>> I then tried it with other drivers, but none demonstrated the sort of
>> problem Phil mentions (I did not quite expect that to happen, but it never
>> hurts to try).
>>
>> Regards,
>>
>> Arjen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Arjen Markus*
>> Sr. Adviseur/Onderzoeker
>>
>> T
>>
>> +31(0)88335 8559
>>
>> E
>>
>> arjen.mar...@deltares.nl
>>
>>
>>
>>
>>
>> [image: Logo] <http://www.deltares.com/>
>>
>> * www.deltares.com* <http://www.deltares.com/>
>>
>> Postbus 177
>> 2600 MH Delft
>>
>>
>> <http://www.twitter.com/deltares>
>>
>> <http://www.linkedin.com/company/217430>
>>
>> <https://www.facebook.com/pages/Deltares/154189334634001>
>>
>>
>> Please consider the environment before printing this email
>>
>>
>>
>> > -Original Message-
>> > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca
>> <ir...@beluga.phys.uvic.ca>]
>> > Sent: Tuesday, September 13, 2016 11:59 PM
>> > To: Phil Rosenberg
>> > Cc: Arjen Markus; plplot-devel@lists.sourceforge.net
>> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
>> >
>> > On 2016-09-13 10:44+0100 Phil Rosenberg wrote:
>> >
>> > > On 13 September 2016 at 03:27, Alan W. Irwin <
>> ir...@beluga.phys.uvic.ca>
>> > wrote:
>> > >> There is a substantial testing requirement for fill changes. The
>> > >> reason for that is we have had years of mostly good user experience
>> > >> with the present fill algorithm so I feel it is important that
>> > >> anybody that changes the fill algorithm in any further way needs to
>> > >> demonstrate with substantial testing that their change does not
>> > >> introduce fill regressions.
>> > >>
>> > >> I have alluded previously to automated fill regression testing (for
>> > >> all our standard examples that directly or indirectly use fill and
>> > >> all our file devices).  The core of the idea is to compare old and
>> > >> updated plot file results using imagemagick image differences.  Do
>> > &