plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] setlocale

[Phil R. <p.d...@gm...>]

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 <p.d...@gm...>
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
>

Re: [Plplot-devel] setlocale

[Phil R. <p.d...@gm...>]

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 <p.d...@gm...>
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] setlocale

[Phil R. <p.d...@gm...>]

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

Re: [Plplot-devel] bug in notpointinpolygon

[Phil R. <p.d...@gm...>]

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 <p.d...@gm...>
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 <p.d...@gm...>
> 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, 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
>>
>

Re: [Plplot-devel] bug in notpointinpolygon

[Arjen M. <Arj...@de...>]

Hi Phil,

Thanks for analysing this. In the past I have seen awkward fills as well. The code is rather tricky and it seems you have uncovered yet another case where things may go wrong. The test suite should be able to capture if anything breaks with your change. So, if that is not the case, then go ahead merging it, I’d say.

Regards,

Arjen

From: Phil Rosenberg <p.d...@gm...>
Sent: donderdag 11 mei 2023 22:42
To: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] bug in notpointinpolygon

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment.

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 <p.d...@gm...<mailto:p.d...@gm...>> 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, 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
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.

Re: [Plplot-devel] bug in notpointinpolygon

[Phil R. <p.d...@gm...>]

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 <p.d...@gm...>
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, 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] bug in notpointinpolygon

[Phil R. <p.d...@gm...>]

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

Re: [Plplot-devel] buffer growth

[Jim D. <ji...@di...>]

It's been awhile for me (and I apologize).  As the original author of the memory buffer implementation I think your approach is the smart way to do it on current computers.  When I implemented it originally, I did try an exponential approach and it crushed my computer at the time so opted for memory efficiency rather than performance.  Memory sizes and virtual memory managers in OSes have improved since that time.

If we want to offer support for low memory situations, perhaps an if block that selects the memory allocation method, at lines 1644 to 1656 we have

if (_GROW_LINEAR == grow_strategy) {
   lines 1644...1656
}  else {
   an exponential strategy that sets plbuf_buffer_size
}

some where near the beginning we have

static const enum { _GROW_LINEAR, _GROW_EXPONENTIAL } grow_strategy = [some 
define that is set by cmake with a default of _GROW_EXPONENTIAL];

I recommend against using an #ifdef block because it is not a good practice with modern compilers.  The compiler should optimize out the conditional statement because the grow_strategy variable is defined as const.

Jim

> On May 4, 2023, at 12:35 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> 
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] buffer growth

[Phil R. <p.d...@gm...>]

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

Re: [Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows system

[Arjen M. <Arj...@de...>]

Hi,

Thanks for this patch. I will apply it. Is GCLP_HCURSOR also available under 32-bits?

Regards,

Arjen

-----Original Message-----
From: Biswapriyo Nath <nat...@gm...>
Sent: 28 March 2023 08:06
To: plp...@li...
Subject: [Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows system

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


This replaces GCL_HCURSOR with GCLP_HCURSOR because the previous one is undefined in 64-bit Windows SDK and in mingw-w64 toolchain. Hence, fixes the following compiler error.

plplot/drivers/wingdi.c: In function 'CrossHairCursor':
plplot/drivers/wingdi.c:201:33: error: 'GCL_HCURSOR' undeclared (first use in this function); did you mean 'GCLP_HCURSOR'?
  201 |     SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
      |                                 ^~~~~~~~~~~
      |                                 GCLP_HCURSOR

Signed-off-by: Biswapriyo Nath <nat...@gm...>
---
 drivers/wingdi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/wingdi.c b/drivers/wingdi.c index b81778a..6731ff6 100644
--- a/drivers/wingdi.c
+++ b/drivers/wingdi.c
@@ -198,7 +198,7 @@ CrossHairCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;

     cursor = LoadCursor( NULL, IDC_CROSS );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     return SetCursor( cursor );
 }

@@ -208,7 +208,7 @@ NormalCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;

     cursor = LoadCursor( NULL, IDC_ARROW );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     SetCursor( cursor );
 }

@@ -218,7 +218,7 @@ BusyCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;

     cursor = LoadCursor( NULL, IDC_WAIT );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     SetCursor( cursor );
 }

--
2.40.0



_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7C%7Cc3a0fe55c1354907a80d08db2f529dde%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638155804121464716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pr0ioI2caWsjjXuw2YtowMrZ7QoX120llWaeWcOYtw4%3D&reserved=0
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.

Re: [Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows system

[Biswapriyo N. <nat...@gm...>]

> Is GCLP_HCURSOR also available under 32-bits?

Yes, GCLP_HCURSOR is available for any architecture. Basically,
GCL_HCURSOR is undefined for 64-bit architectures like the following
in the winbase.h file in Windows SDK.

```
#ifdef _WIN64
#undef GCL_HCURSOR
#endif
```

[Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows system

[Biswapriyo N. <nat...@gm...>]

This replaces GCL_HCURSOR with GCLP_HCURSOR because the previous one
is undefined in 64-bit Windows SDK and in mingw-w64 toolchain. Hence,
fixes the following compiler error.

plplot/drivers/wingdi.c: In function 'CrossHairCursor':
plplot/drivers/wingdi.c:201:33: error: 'GCL_HCURSOR' undeclared (first use in this function); did you mean 'GCLP_HCURSOR'?
  201 |     SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
      |                                 ^~~~~~~~~~~
      |                                 GCLP_HCURSOR

Signed-off-by: Biswapriyo Nath <nat...@gm...>
---
 drivers/wingdi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/wingdi.c b/drivers/wingdi.c
index b81778a..6731ff6 100644
--- a/drivers/wingdi.c
+++ b/drivers/wingdi.c
@@ -198,7 +198,7 @@ CrossHairCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;
 
     cursor = LoadCursor( NULL, IDC_CROSS );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     return SetCursor( cursor );
 }
 
@@ -208,7 +208,7 @@ NormalCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;
 
     cursor = LoadCursor( NULL, IDC_ARROW );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     SetCursor( cursor );
 }
 
@@ -218,7 +218,7 @@ BusyCursor( struct wingdi_Dev * dev )
     HCURSOR cursor;
 
     cursor = LoadCursor( NULL, IDC_WAIT );
-    SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+    SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
     SetCursor( cursor );
 }
 
-- 
2.40.0

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen M. <Arj...@de...>]

Hi Rafael,

Quick update:
I just checked: Cygwin does not seem to have updates for these two packages. I will have to look at some other platforms.

Regards,

Arjen

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 05 January 2023 10:36
To: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


* Arjen Markus <Arj...@de...> [2022-12-29 13:32]:

> I am currently trying to incorporate the patches you sent, but I am running into a problem with Octave. Here is the start of a whole series of error messages:
>
>  [ 16%] Swig compile plplot_octave.i for octave  [ 16%] Built target
> plplot_octave_swig_compilation  [ 17%] Building CXX object
> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.
> cxx.o
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31: error: 'oct_mach_info' has not been declared
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                               ^~~~~~~~~~~~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59: error: expected ',' or '...' before 'fmt'
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                                                           ^~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function 'octave_value_list octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const octave_value_list&)':
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94: error: invalid new-expression of abstract class type 'octave_swig_bound_func'
>  1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new octave_swig_bound_func(func, args))
>       |                                                                                              ^
>  /
>
> I have no idea how to solve this, so I am hoping you or somebody else familiar with Octave and SWIG can give me a few pointers, or better still, a patch to solve this.
>
> For your information:
>
>  - SWIG: version 4.0.2
>  - Octave: version 6.4.0
>  - I am building this under Cygwin with all the packages updated to the current versions.

It works for me with these versions:

  - SWIG 4.1.0
  - Octave 7.3.0

Could you please test with them?

> By the way, under Cygwin I do not seem to have a useable Ada compiler,
> so I cannot test the changes that you and Nicolas suggested. But to
> keep them in line with the rest, I have now implemented the building
> of the static library as:
>
>  if(ENABLE_ada_static)
>    set(ADA_lib_type "STATIC")
>  else(ENABLE_ada_static)
>    set(ADA_lib_type "")
>  endif(ENABLE_ada_static)
>
>  # target_link_libraries used in special way below so avoid using it inside configure_library_build.
>  configure_library_build(plplotada ${ADA_lib_type}
> "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
>
> so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command line you will get the static library. So, there will be  either a static or a dynamic (shared) library.
>
> I have not checked in these changes yet, but this is what I intend to do.

The ideal situation would be to allow users to enable both static and dynamic, if they wish so.  Is this what you are intending to do?

Best,

Rafael


_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7C%7Ca00a15b047b147e6c14608daef0055b2%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638085081986053924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N2g8cx3xw2q%2FlhWKsiJQsk%2BHE4XiwuUHGpl52te3D5M%3D&reserved=0
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.

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen M. <Arj...@de...>]

I have more luck with MinGW-w64/MSYS2: SWIG 4.1.1 and Octave 7.3.0. I will try those then.

Regards,

Arjen

-----Original Message-----
From: Arjen Markus
Sent: 10 January 2023 15:44
To: Rafael Laboissière <ra...@la...>; PLplot development list <plp...@li...>
Subject: RE: [Plplot-devel] Deprecated operator in the Octave binding

Hi Rafael,

Quick update:
I just checked: Cygwin does not seem to have updates for these two packages. I will have to look at some other platforms.

Regards,

Arjen

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 05 January 2023 10:36
To: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


* Arjen Markus <Arj...@de...> [2022-12-29 13:32]:

> I am currently trying to incorporate the patches you sent, but I am running into a problem with Octave. Here is the start of a whole series of error messages:
>
>  [ 16%] Swig compile plplot_octave.i for octave  [ 16%] Built target
> plplot_octave_swig_compilation  [ 17%] Building CXX object
> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.
> cxx.o
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31: error: 'oct_mach_info' has not been declared
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                               ^~~~~~~~~~~~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59: error: expected ',' or '...' before 'fmt'
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                                                           ^~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function 'octave_value_list octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const octave_value_list&)':
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94: error: invalid new-expression of abstract class type 'octave_swig_bound_func'
>  1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new octave_swig_bound_func(func, args))
>       |                                                                                              ^
>  /
>
> I have no idea how to solve this, so I am hoping you or somebody else familiar with Octave and SWIG can give me a few pointers, or better still, a patch to solve this.
>
> For your information:
>
>  - SWIG: version 4.0.2
>  - Octave: version 6.4.0
>  - I am building this under Cygwin with all the packages updated to the current versions.

It works for me with these versions:

  - SWIG 4.1.0
  - Octave 7.3.0

Could you please test with them?

> By the way, under Cygwin I do not seem to have a useable Ada compiler,
> so I cannot test the changes that you and Nicolas suggested. But to
> keep them in line with the rest, I have now implemented the building
> of the static library as:
>
>  if(ENABLE_ada_static)
>    set(ADA_lib_type "STATIC")
>  else(ENABLE_ada_static)
>    set(ADA_lib_type "")
>  endif(ENABLE_ada_static)
>
>  # target_link_libraries used in special way below so avoid using it inside configure_library_build.
>  configure_library_build(plplotada ${ADA_lib_type}
> "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
>
> so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command line you will get the static library. So, there will be  either a static or a dynamic (shared) library.
>
> I have not checked in these changes yet, but this is what I intend to do.

The ideal situation would be to allow users to enable both static and dynamic, if they wish so.  Is this what you are intending to do?

Best,

Rafael


_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7C%7Ca00a15b047b147e6c14608daef0055b2%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638085081986053924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N2g8cx3xw2q%2FlhWKsiJQsk%2BHE4XiwuUHGpl52te3D5M%3D&reserved=0
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.

Re: [Plplot-devel] Run Octave non-interactive tests with the --no-gui option

[Arjen M. <Arj...@de...>]

Hi Rafael,

Thanks for this update. I will try and test the Octave and SWIG versions you mentioned today or within the next few days. (I am currently limited to Windows-based environments - Cygwin and MinGW, as well as basic Windows - so I may not have access to these versions. But wewill see.)

Regards,

Arjen

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 07 January 2023 21:43
To: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] Run Octave non-interactive tests with the --no-gui option

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


* Rafael Laboissière <ra...@la...> [2023-01-05 16:22]:

> When running the non-interactive tests for the Octave binding, it is
> preferable to run them with the --no-gui option of octave. This allows
> headless systems (without access to an X server) to run the tests.
> This is the case for the autobuilders of Debian. BTW, I am currently
> applying the patch attached to this message to the Debian package for
> PLplot and you might be interested in applying it to the PLplot source
> as well.

Please, consider the improved version of the patch attached to this message. Besides the --no-gui option, it also passes option --no-window-system to Octave, what is the appropriate for running the tests on headless systems.

Best,

Rafael Laboissière
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.

Re: [Plplot-devel] Run Octave non-interactive tests with the --no-gui option

[Rafael L. <ra...@la...>]

* Rafael Laboissière <ra...@la...> [2023-01-05 16:22]:

> When running the non-interactive tests for the Octave binding, it is 
> preferable to run them with the --no-gui option of octave. This allows 
> headless systems (without access to an X server) to run the tests. 
> This is the case for the autobuilders of Debian. BTW, I am currently 
> applying the patch attached to this message to the Debian package for 
> PLplot and you might be interested in applying it to the PLplot source 
> as well.

Please, consider the improved version of the patch attached to this 
message. Besides the --no-gui option, it also passes option 
--no-window-system to Octave, what is the appropriate for running the 
tests on headless systems.

Best,

Rafael Laboissière

[Plplot-devel] Run Octave non-interactive tests with the --no-gui option

[Rafael L. <ra...@la...>]

Dear PLplot developers,

When running the non-interactive tests for the Octave binding, it is 
preferable to run them with the --no-gui option of octave. This allows 
headless systems (without access to an X server) to run the tests. This 
is the case for the autobuilders of Debian. BTW, I am currently applying 
the patch attached to this message to the Debian package for PLplot and 
you might be interested in applying it to the PLplot source as well.

Best,

Rafael Laboissière

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Rafael L. <ra...@la...>]

* Arjen Markus <Arj...@de...> [2022-12-29 13:32]:

> I am currently trying to incorporate the patches you sent, but I am running into a problem with Octave. Here is the start of a whole series of error messages:
>
>  [ 16%] Swig compile plplot_octave.i for octave
>  [ 16%] Built target plplot_octave_swig_compilation
>  [ 17%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31: error: ‘oct_mach_info’ has not been declared
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                               ^~~~~~~~~~~~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59: error: expected ‘,’ or ‘...’ before ‘fmt’
>  1768 |                               oct_mach_info::float_format fmt) {
>       |                                                           ^~~
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function ‘octave_value_list octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const octave_value_list&)’:
>  /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94: error: invalid new-expression of abstract class type ‘octave_swig_bound_func’
>  1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new octave_swig_bound_func(func, args))
>       |                                                                                              ^
>  /
>
> I have no idea how to solve this, so I am hoping you or somebody else familiar with Octave and SWIG can give me a few pointers, or better still, a patch to solve this.
>
> For your information:
>
>  - SWIG: version 4.0.2
>  - Octave: version 6.4.0
>  - I am building this under Cygwin with all the packages updated to the current versions.

It works for me with these versions:

  - SWIG 4.1.0
  - Octave 7.3.0

Could you please test with them?

> By the way, under Cygwin I do not seem to have a useable Ada compiler, 
> so I cannot test the changes that you and Nicolas suggested. But to 
> keep them in line with the rest, I have now implemented the building of 
> the static library as:
>
>  if(ENABLE_ada_static)
>    set(ADA_lib_type "STATIC")
>  else(ENABLE_ada_static)
>    set(ADA_lib_type "")
>  endif(ENABLE_ada_static)
>
>  # target_link_libraries used in special way below so avoid using it inside configure_library_build.
>  configure_library_build(plplotada ${ADA_lib_type} "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
>
> so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command line you will get the static library. So, there will be  either a static or a dynamic (shared) library.
>
> I have not checked in these changes yet, but this is what I intend to do.

The ideal situation would be to allow users to enable both static and 
dynamic, if they wish so.  Is this what you are intending to do?

Best,

Rafael

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen M. <Arj...@de...>]

Hi Rafael,

I am currently trying to incorporate the patches you sent, but I am running into a problem with Octave. Here is the start of a whole series of error messages:

[ 16%] Swig compile plplot_octave.i for octave
[ 16%] Built target plplot_octave_swig_compilation
[ 17%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31: error: ‘oct_mach_info’ has not been declared
 1768 |                               oct_mach_info::float_format fmt) {
      |                               ^~~~~~~~~~~~~
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59: error: expected ‘,’ or ‘...’ before ‘fmt’
 1768 |                               oct_mach_info::float_format fmt) {
      |                                                           ^~~
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function ‘octave_value_list octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const octave_value_list&)’:
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94: error: invalid new-expression of abstract class type ‘octave_swig_bound_func’
 1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new octave_swig_bound_func(func, args))
      |                                                                                              ^
/

I have no idea how to solve this, so I am hoping you or somebody else familiar with Octave and SWIG can give me a few pointers, or better still, a patch to solve this.

For your information:
- SWIG: version 4.0.2
- Octave: version 6.4.0
- I am building this under Cygwin with all the packages updated to the current versions.

By the way, under Cygwin I do not seem to have a useable Ada compiler, so I cannot test the changes that you and Nicolas suggested. But to keep them in line with the rest, I have now implemented the building of the static library as:


  if(ENABLE_ada_static)
    set(ADA_lib_type "STATIC")
  else(ENABLE_ada_static)
    set(ADA_lib_type "")
  endif(ENABLE_ada_static)

  # target_link_libraries used in special way below so avoid using it inside configure_library_build.
  configure_library_build(plplotada ${ADA_lib_type} "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")

so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command line you will get the static library. So, there will be  either a static or a dynamic (shared) library.

I have not checked in these changes yet, but this is what I intend to do.

Regards,

Arjen


-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 26 December 2022 19:38
To: PLplot development list <plp...@li...>
Subject: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Dear PLplot developers,

SWIG support for Octave 6.0 was broken, but this has been fixed in release 4.1. I am therefore planning to reintroduce the plplot-octave package in Debian.

When compiling the package against Octave 7, several warnings regarding operators .- and .+ are issued, like this one:

     warning: the '.-' operator was deprecated in version 7 and will not be allowed in a future version of Octave; please use '-' instead;

Please, find attached to this message a patch that fixes the problem.

Best,

Rafael Laboissière
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] Deprecated operator in the Octave binding

[Rafael L. <ra...@la...>]

Dear PLplot developers,

SWIG support for Octave 6.0 was broken, but this has been fixed in 
release 4.1. I am therefore planning to reintroduce the plplot-octave 
package in Debian.

When compiling the package against Octave 7, several warnings 
regarding operators .- and .+ are issued, like this one:

     warning: the '.-' operator was deprecated in version 7 and will not be allowed in a future version of Octave; please use '-' instead;

Please, find attached to this message a patch that fixes the problem.

Best,

Rafael Laboissière

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen M. <Arj...@de...>]

Hi Nicolas,

Thanks for this information. The original patch had some Debian-specific environment variables, so I started to wonder about the relation to the Debian platform. I will have a closer look at this.

Regards,

Arjen

-----Original Message-----
From: Nicolas Boulenguez <ni...@de...>
Sent: 19 December 2022 11:55
To: Arjen Markus <Arj...@de...>
Cc: Rafael Laboissière <ra...@la...>; PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Hello.

These suggestions are not specific to Debian or Ada.

The most common kind of libraries is shared/relocatable (.so/dll/...), but some people may want a static library (.a/.o/...) or more exotic choices (static-pic for example).

Currently, plplotada builds a shared library.  This is good.

CMake seems able to also build a static library.  As far as I understand Rafael's commit, adding the following line into bindings/ada/CMakeLists.txt tells CMake to build *both* the shared and static library.

  configure_library_build(plplotada_static STATIC "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")

Debian is happy with this, but this is probably not a satisfying default.  I suggest to make the static library an opt-in option.

if(enable_ADA_STATIC)
  # Also build the static library
  configure_library_build(plplotada_static STATIC "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
endif(enable_ADA_STATIC)

The ideal would be to allow any combination through an explicit configure option for each library kind.  I do not know how easy it would be, and this is not useful to Debian right now.

By the way, does this trivial change not fix the renaming issue?

  configure_library_build(plplotada STATIC "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
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.

Re: [Plplot-devel] Build a static version of libplplotada

[Rafael L. <ra...@la...>]

Hi Arjen,

I do not think that the patch is specific to Debian.  I will let Nicolas 
give a more precise explanation of the situation.

Best,

Rafael

* Arjen Markus <Arj...@de...> [2022-12-18 15:04]:

> Hi Rafael,
>
> I am looking into the patches and suggestions you sent. This is specific to Debian, you say, so the new code is to be run on Debian only. What would be an appropriate check that we are running on this platform? (I have no experience with building the Ada package or  with Ada at all, nor  have I access to a Debian platform.)
>
> Regards,
>
> Arjen
>
> -----Original Message----- 
> From: Rafael Laboissière <ra...@la...> 
> Sent: 08 December 2022 12:10 
> To: PLplot development list <plp...@li...> 
> Cc: Nicolas Boulenguez <ni...@de...> 
> Subject: [Plplot-devel] Build a static version of libplplotada
>
> Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.
>
>
> Dear PLplot developers,
>
> We are currently applying the patch attached below when building the Debian package for PLplot. It allows the creation of a static version of libplplotada, what is recommended to meet the Ada standards in Debian.
>
> This solution is not ideal, because the new target libplplotada_static.a is created and later, in debian/rules, the following is needed in target execute_after_dh_auto_install (see [1]):
>
>        mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
>           debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a
>
> My knowledge of CMake is too scarce and I could not figure out how to avoid the renaming above.
>
> According to Nicolas Boulenguez, this change could be accompanied by a new configuration option :
>
>     shared_library  *yes/no
>     static_library  yes/*no
>
> This schema could allow one to add a static-pic in the future.
>
> Best,
>
> Rafael Laboissière
>
>  [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fscience-team%2Fplplot%2F-%2Fcommit%2F82895090f80180bd1d085e03fb09056e31138e92&amp;data=05%7C01%7C%7C46d0b47393524d4aaadd08dad90e4c70%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C638060952705369812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=c2%2FlFMScn3wHgzmnAChlQSrKoN4%2FnqWuGSn2i100x6c%3D&amp;reserved=0
> 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.
>

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen M. <Arj...@de...>]

Hi Rafael,

I am looking into the patches and suggestions you sent. This is specific to Debian, you say, so the new code is to be run on Debian only. What would be an appropriate check that we are running on this platform? (I have no experience with building the Ada package or  with Ada at all, nor  have I access to a Debian platform.)

Regards,

Arjen

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 08 December 2022 12:10
To: PLplot development list <plp...@li...>
Cc: Nicolas Boulenguez <ni...@de...>
Subject: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Dear PLplot developers,

We are currently applying the patch attached below when building the Debian package for PLplot. It allows the creation of a static version of libplplotada, what is recommended to meet the Ada standards in Debian.

This solution is not ideal, because the new target libplplotada_static.a is created and later, in debian/rules, the following is needed in target execute_after_dh_auto_install (see [1]):

        mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
           debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a

My knowledge of CMake is too scarce and I could not figure out how to avoid the renaming above.

According to Nicolas Boulenguez, this change could be accompanied by a new configuration option :

     shared_library  *yes/no
     static_library  yes/*no

This schema could allow one to add a static-pic in the future.

Best,

Rafael Laboissière

  [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fscience-team%2Fplplot%2F-%2Fcommit%2F82895090f80180bd1d085e03fb09056e31138e92&amp;data=05%7C01%7C%7C46d0b47393524d4aaadd08dad90e4c70%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C638060952705369812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=c2%2FlFMScn3wHgzmnAChlQSrKoN4%2FnqWuGSn2i100x6c%3D&amp;reserved=0
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.

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen M. <Arj...@de...>]

Hi Rafael,

Thanks for the patches. I will try and apply them in the coming few days. I have not seen any other replies and was away myself, so my reply is a trifle late.

Regards,

Arjen

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 08 December 2022 12:10
To: PLplot development list <plp...@li...>
Cc: Nicolas Boulenguez <ni...@de...>
Subject: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Dear PLplot developers,

We are currently applying the patch attached below when building the Debian package for PLplot. It allows the creation of a static version of libplplotada, what is recommended to meet the Ada standards in Debian.

This solution is not ideal, because the new target libplplotada_static.a is created and later, in debian/rules, the following is needed in target execute_after_dh_auto_install (see [1]):

        mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
           debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a

My knowledge of CMake is too scarce and I could not figure out how to avoid the renaming above.

According to Nicolas Boulenguez, this change could be accompanied by a new configuration option :

     shared_library  *yes/no
     static_library  yes/*no

This schema could allow one to add a static-pic in the future.

Best,

Rafael Laboissière

  [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fscience-team%2Fplplot%2F-%2Fcommit%2F82895090f80180bd1d085e03fb09056e31138e92&amp;data=05%7C01%7C%7C46d0b47393524d4aaadd08dad90e4c70%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C638060952705369812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=c2%2FlFMScn3wHgzmnAChlQSrKoN4%2FnqWuGSn2i100x6c%3D&amp;reserved=0
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] Build a static version of libplplotada

[Rafael L. <ra...@la...>]

Dear PLplot developers,

We are currently applying the patch attached below when building the 
Debian package for PLplot. It allows the creation of a static version of 
libplplotada, what is recommended to meet the Ada standards in Debian.

This solution is not ideal, because the new target libplplotada_static.a 
is created and later, in debian/rules, the following is needed in target 
execute_after_dh_auto_install (see [1]):

        mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
           debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a

My knowledge of CMake is too scarce and I could not figure out how to 
avoid the renaming above.

According to Nicolas Boulenguez, this change could be accompanied by a 
new configuration option :

     shared_library  *yes/no
     static_library  yes/*no

This schema could allow one to add a static-pic in the future.

Best,

Rafael Laboissière

  [1] https://salsa.debian.org/science-team/plplot/-/commit/82895090f80180bd1d085e03fb09056e31138e92