plplot-devel — Technical discussion about PLplot development

[Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

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

Hi Arjen:

I am addressing you because you are our primary Windows platform
expert, but I would be happy to hear from others here as well
(including Alaric) with some knowledge of that platform.

What would be your advice concerning replacing our use of the WIN32
and __WIN32__ macros in our source code?

Basically, Alaric (see his bug report below) has found a platform where the _WIN32 macro is #defined
but not WIN32, and the stackoverflow discussion he referenced appears to
say the two macros ordinarily have the same meaning but the underscored
one is a bit safer to use because there is a convention it should not be
changed by anyone other than the compiler vendor.

Note, however, that Alaric's bug report does not cover the entire
problem in our code because we also make use of the __WIN32__ macro.
Another stackoverflow discussion concerning that macro referenced
<https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system>.

My conclusion from reading the "Windows, Cygwin (non-POSIX), and
MinGW" section of that article is the safest course for supporting all
Windows compilers is for us to replace all use of the WIN32 and
__WIN32__ macros in our C and C++ code with use of the _WIN32 macro
instead.  Do you agree?

If so, I would be willing to take responsibility for
the actual code change since Linux has excellent facilities (find and
sed) for automatic mass-editing of code.

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
__________________________

---------- Forwarded message ----------
Date: Mon, 09 Oct 2017 15:52:10 +0000
From: Alaric Senat <ala...@us...>
Reply-To: Ticket 189 <18...@bu...>
To: Ticket 189 <18...@bu...>
Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32




---

** [bugs:#189] Using WIN32 Macro instead of _WIN32**

**Status:** open
**Group:**
**Created:** Mon Oct 09, 2017 03:52 PM UTC by Alaric Senat
**Last Updated:** Mon Oct 09, 2017 03:52 PM UTC
**Owner:** nobody


Hello,

This ticket is just about a little detail and its not exactly a bug.
Me and my team are cross-compiling for windows, and we noticed that you are often using the WIN32 macro in your source files to check the current compilator platform.
We needed to switch these macros to \_WIN32 because in our case, we are compiling with the *-std=c++14* flag and is disable WIN32 cause it's not in the standard.
To my mind, It would be a bit safer if those WIN32 were switched to \_WIN32 in a further version of PlPlot!

Here is a nice topic on that point : https://stackoverflow.com/questions/662084/whats-the-difference-between-the-win32-and-win32-defines-in-c/662543#662543

Regards,
Alaric Senat


---

Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/plplot/bugs/189/>



To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

[Plplot-devel] ocaml bindings follow-up

[Philippe S. <phi...@st...>]

Alan,

I've made a mistake in my previous email on this topic, it's by reverting your
two commits, 893625c and 84760038, and doing a quick and dirty hack about the apple cpp issue
that plplot plcairo ocaml cairo2 based works fine now. It's on a mac air running os x 10.11.6 and
macports aged of one month approx. cairo lib is version 1.14.10

The archive of the caml mailing list is here:
https://sympa.inria.fr/sympa/arc/caml-list



Regards


--
Philippe STRAUSS

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

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

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 08 October 2017 19:15
To: Phil Rosenberg
Cc: PLplot development list


On 2017-10-08 12:54+0100 Phil Rosenberg wrote:

> On 7 October 2017 at 02:14, Alan W. Irwin <ir...@be...> 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.

My own gut feeling is there is some general issue with the way events
are set up that is cause of these issues, but the bug is only exposed
on some platforms (similar to the Linux OnCreate delay bug that you
fixed in January this year just before the release of 5.12.0.)

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

I was unaware until reading your above remark there was a difference
between Linux and Windows event capture.  However, given that is the
case is it possible you still need to make an adjustment for that
difference in order to solve Linux issues 1 and 2 as well?


This is something specific to keyboard events.

At the moment I am working on the slave plot issue – basically forcing the core code to wait until page advance occurs in the viewer. Once this is done I will look into this locate 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
__________________________

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

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

On 2017-10-08 12:54+0100 Phil Rosenberg wrote:

> On 7 October 2017 at 02:14, Alan W. Irwin <ir...@be...> 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.

My own gut feeling is there is some general issue with the way events
are set up that is cause of these issues, but the bug is only exposed
on some platforms (similar to the Linux OnCreate delay bug that you
fixed in January this year just before the release of 5.12.0.)

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

I was unaware until reading your above remark there was a difference
between Linux and Windows event capture.  However, given that is the
case is it possible you still need to make an adjustment for that
difference in order to solve Linux issues 1 and 2 as well?

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
__________________________

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

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

On 7 October 2017 at 02:14, Alan W. Irwin <ir...@be...> 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
> __________________________

[Plplot-devel] non-IPC3 interactive issues with example 20

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

Hi Phil:

In the same spirit of getting interactive non-IPC3 to work properly as
a model of what should be done for the IPC3 case, please fix the
following non-IPC3 issue that shows up for example 20 for the
current master HEAD:

The plot page display is out of sync (due to screwed up
processing of events?).  Page 1 is displayed no matter
how much I hit the enter key to move on to the next
page, but if I select a region (something that should
happen after the second page is displayed), the second
page is displayed rather than the third, and so forth.

Until this situation is resolved, I cannot tell if this
is the only interactive issue for this example or whether
there are more.  For the record, the
way this example is supposed to work is as follows:

# Move to examples subdirectory where image of Chloe resides.
cd examples

# Run example 20
c/x20c -dev wxwidgets

1. First "sombrero" page displayed.

2. After user hits enter key, the entirety of the "Chloe" page
should be displayed with instructions to select a region using
the mouse.

3. After the user selects a region (by drag and drop with mouse 1
and clicking with mouse 2 to terminate that selection), that selected
region is displayed at the original (small) scale.

4. After the user hits the enter key, the next page is displayed
which should contain the selected region of the Chloe image at
large scale.

5. After the user hits the enter key, the next page is displayed
of the full Chloe image at reduced dynamic range.

6. After the user hits the enter key, the next page is displayed
of the full Chloe image with distorted geometry.

7. After the user hits the enter key, wxPLViewer quits.

I hope this description of the way the interactive steps of this
example should work will help you to sort out all non-IPC3 problems
for this example so I can use that corrected non-IPC3 model to figure
out what to do in the IPC3 case.

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
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] non-IPC3 interactive issues with example 14

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

Hi Phil:

In the same spirit of getting interactive non-IPC3 to work properly as
a model of what should be done for the IPC3 case, please fix the
following non-IPC3 issues that show up for example 14 for the
current master HEAD:

1. Slave GUI is blank (i.e., does not show any plot).

I am pretty sure this issue is likely caused by the same issue
(screwed up processing of events?) that is causing non-IPC3 display
issues for example 1 in locate mode.

2. Slave GUI finishes and disappears even with no action taken
by the user.

I recently analyzed the cause of this situation in detail.  For all
other interactive devices core coincides with viewer so when the
viewer pauses at page end waiting for the user to hit the enter key
the core automatically pauses as well.  And that assumption is
fundamental to the way that example 14 works.  So to cure this issue
you have to implement the same scenario for the wxwidgets device so
that when the (separate) master viewer pauses at page end, the master
core must be forced to pause as well.

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
__________________________

Re: [Plplot-devel] ocaml and antialiased gtk embedding (cairo)

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

On 2017-10-07 13:57-0000 Philippe STRAUSS wrote:

> finally there! I've reversed the two commits of hez and the cairo2
based plplot runs fine.

Hi Phillipe:

You dropped the plplot-devel mailing list address from your post
(likely because you just used reply rather than reply-all), but I
added it back because I want this discussion to be available there.

I am glad you got something to work, but please clarify your
description above of exactly what it was you got to work.  For
example, reversing the two last commits from Hez and also my two small
commits that disabled plcairo should allow plcairo to support "cairo"
rather than "cairo2".  Leaving Hez's commits as is, but just reversing
my two commits should allow plcairo to support "cairo2" rather than
"cairo".

Whichever of "cairo" or "cairo2" you got to work, could you also try
the alternative to see if that works as well?

> to be honest, i could not reply myself to the
cairo vs cairo2 ocaml bindings debate, so I've asked on the ocaml
mailing list.

Could you give me a URL of the mailing-list archive that contains the
full thread of this discussion?  I would like to see the original
question you asked, and any additional responses (possibly in the
future) beyond the one you quoted.

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] Issues with locate mode for the non-IPC3 case

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

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.

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

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
__________________________

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

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

On 2017-10-06 23:30+0100 Phil Rosenberg wrote:

> Hi Alan
> Try it now. Fingers crossed :-)

Your commit (3fe27f0) got rid of this run-time invalid bitmap issue on
Linux.  Thanks!  And now on to more wxwidgets testing for me.

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
__________________________

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

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

Hi Alan
Try it now. Fingers crossed :-)

On 6 October 2017 at 20:44, Alan W. Irwin <ir...@be...> 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
> __________________________

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

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

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
__________________________

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

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

On 2017-10-06 11:00+0100 Phil Rosenberg wrote:

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

The present library finding has "just worked" for a long time for a
large variety of Windows users on many different Windows platforms so
I am somewhat reluctant to change it.  On the other hand, I guess it
is possible if you don't need it, then nobody needs it, but I am not
at all sure about that.  So before making any decisions here, I think
we need to collect more information.  For example, I would like you to
try 3.9.4 (see other thread concerning CMake versions) to see if this
particular problem persists (and also to determine whether CMake-3.9.4
satisfies all PLplot build-system needs for your Windows SDK version.)

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] CMake version discussion

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

On 2017-10-06 11:00+0100 Phil Rosenberg wrote:

> I [...] 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

Brad King refers in that discussion to the target version, but I
am not sure exactly what he means by that.  But what is clear from
that discussion is Brad felt the early SDK policy for Windows 10 was
wrong, and they instead adopted the same policy as is used for
Mac OS X and their SDK's which I assume is a rational one without
the need for forced CMake (or SDK) upgrades.  The implementation
of that fundamental change in policy was done by commit
<https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7e>
where the new policy is summarized as

Select "a Windows 10 SDK if one exists.  Use the
SDK for the exact version if is available.  Otherwise use the latest
version of the SDK available because that will have at least the APIs
expected for the target version."

Does that policy (implemented in the run-up to CMake 3.4.0) appear
like a rational one to you?

> I
> know in the past Alan has mentioned the need to not upgrade due to a
> bug in a release.

I have said a lot of things in the past concerning CMake versions
because early versions of CMake-3.x.y truly sucked.  But my experience
with CMake versions between 3.6.2 and 3.9.x is much better.  My
attitude now concerning CMake versions is summarized in "1.1 CMake
version compatibility" which you can find for the recent 5.13.0
release in README.cumulated_release.

In sum, due to our extensive comprehensive testing of various CMake
versions, I feel most/all versions of CMake between 3.6.2 (our minimum
allowed version) and CMake 3.9.x should be fine.

Of course, the caveat to that summary is we have not comprehensively
tested PLplot for Windows SDK's, and there is still a lot of on-going
bug fixing for the various Windows SDK's by the CMake developers so I
think, in general, you would be better off using 3.9.4 than your
current 3.7.1.  Anyhow, why not try 3.9.4 and see? If it does not
satisfy your personal needs, then you can always move back to 3.7.1.
But the bigger issue as PLplot developers is we need to know about any
problems you might have with 3.9.4 and your particular Windows SDK so
we can make the appropriate bug reports to CMake to get the issue
fixed to protect _all_ our users in your situation.

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
__________________________

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

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

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...@be...> wrote:
> On 2017-10-05 09:10+0100 Phil Rosenberg wrote:
>
>> On 5 October 2017 at 04:10, Alan W. Irwin <ir...@be...>
>> 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
> __________________________

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

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

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!

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
__________________________

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

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

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 <ir...@be...> 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
> __________________________

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

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

On 2017-10-05 09:10+0100 Phil Rosenberg wrote:

> On 5 October 2017 at 04:10, Alan W. Irwin <ir...@be...> 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
__________________________

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

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

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
__________________________

[Plplot-devel] ocaml: OS X cpp peculiarity

[Philippe S. <phi...@ya...>]

Hello plplot devs,
building ocaml bindings use an ocaml specific IDL named camlidl. This tool as a first pass invoke cpp for enabling the use of macro in the source .idl file.
apple cpp and gnu cpp differs at least on the following:
-----------8<----------#define QUOTEME(x) #x#define RAW_ML(x) quote(mlmli, QUOTEME(x));
RAW_ML("raw ml")------------8<----------
gives, using gnu cpp:
# 1 "test2.idl"# 1 "<built-in>"# 1 "<command-line>"# 1 "test2.idl"


quote(mlmli, "\"raw ml\"");
... and using apple cpp
# 1 "test2.idl"# 1 "<built-in>" 1# 1 "<built-in>" 3# 328 "<built-in>" 3# 1 "<command line>" 1# 1 "<built-in>" 2# 1 "test2.idl" 2


quote(mlmli, #"raw ml");

which trigger the following build error:
[ 47%] Built target plplotScanning dependencies of target plplotcxx[ 48%] Building CXX object bindings/c++/CMakeFiles/plplotcxx.dir/plstream.cc.o[ 50%] Linking CXX shared library libplplotcxx.dylib[ 50%] Built target plplotcxxScanning dependencies of target target_lib_plplot_stubs[ 51%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, plplot_core_stubs.c, plplot_core.hFile plplot_core.idl, line 330, column 13: Illegal character #make[2]: *** [bindings/ocaml/plplot_core.idl] Error 2make[2]: *** Deleting file `bindings/ocaml/plplot_core.idl'make[1]: *** [bindings/ocaml/CMakeFiles/target_lib_plplot_stubs.dir/all] Error 2make: *** [all] Error 2
building ocaml binding on OS X require first, a gnu cpp onboard, and second, a mean to detect it.


Regards
--Philippe STRAUSS

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

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

On 5 October 2017 at 04:10, Alan W. Irwin <ir...@be...> 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 <alternate name for gdi32> HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   if(GDI32_LIBRARY)
>       find_library(COMDLG32_LIBRARY NAMES comdlg32 <alternate name for
> 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
> __________________________

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

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

Hi Alan,



My system is Windows 7 and I do not have easy access to a Windows 10 machine with a suitable development environment. Perhaps there are release notes at MSDN that can shed some light on the matter?



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, October 05, 2017 5:10 AM
> To: Phil Rosenberg; Jim Dishaw; Arjen Markus; PLplot development list
> Subject: Re: wingcc and wingdi build bugs
>
> 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.
>
> 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 <alternate name for gdi32> HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>    if(GDI32_LIBRARY)
>        find_library(COMDLG32_LIBRARY NAMES comdlg32 <alternate name for
> 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
> __________________________

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] wingcc and wingdi build bugs

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

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.

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 <alternate name for gdi32> HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
   if(GDI32_LIBRARY)
       find_library(COMDLG32_LIBRARY NAMES comdlg32 <alternate name for 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
__________________________

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

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

> On Oct 4, 2017, at 3:26 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> To Phil, Jim, and Arjen:
> 
>> On 2017-10-04 12:11+0100 Phil Rosenberg wrote:
>> 
>> 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 never looked into why
>> as I don't use them.
> 
> But all members of the PLplot development team should be concerned if
> wingcc (a workhorse interactive device that has been around a long
> time and which presumably builds on most Windows platforms) does not
> build on your particular Windows platform.  Because other users also
> have that same platform, and they may need access to wingcc (and
> wingdi).  So please follow up with a complete bug report here
> (preferably) or on the bug tracker including all relevant information
> about your Windows platform and the exact build error.  And similarly
> for the wingdi case (although that has not been around as long as
> wingcc it is based on it so it may have a common build problem on your
> particular Windows platform).  Arjen or Jim (both with a lot
> of Windows experience) might be able to quickly resolve the issue
> you are encountering.
> 
> You might also want to look at
> https://sourceforge.net/p/plplot/support-requests/44/
> (which is in the support-request category, but it is really
> a bug report).  That user was having trouble building wingdi
> on "Cygwin 64 (CYGWIN_NT-10.0) on Winows 10 (64-bit)".  But for
> that same platform he built wingcc with no issues.
> 
> @Jim:
> 
> You obviously had a lot of discussion with this user concerning his
> wingdi build bug including sending him patches to try, but it seemed
> to trail off at the end with nothing resolved with regard to the
> wingdi build bug on his platform.  What needs to be done to get this
> issue resolved?
> 

He was able to get the release to build according to his last message. I still need to work on the wingdi build for the environments that do not have the newer windows api calls. I need to spinup a VM running an older version of Windows to test. 

As for the big, that has to do with the pause mechanism and I have been waiting for the wxwidgets driver to stabilize. I’m going to make wingdi have the same behavior as wxwidgets relative to the pause. 

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

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

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

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. I am on
Windows 10 64 bit.

Phil

On 4 October 2017 at 20:26, Alan W. Irwin <ir...@be...> wrote:
> To Phil, Jim, and Arjen:
>
> On 2017-10-04 12:11+0100 Phil Rosenberg wrote:
>
>> 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 never looked into why
>> as I don't use them.
>
>
> But all members of the PLplot development team should be concerned if
> wingcc (a workhorse interactive device that has been around a long
> time and which presumably builds on most Windows platforms) does not
> build on your particular Windows platform.  Because other users also
> have that same platform, and they may need access to wingcc (and
> wingdi).  So please follow up with a complete bug report here
> (preferably) or on the bug tracker including all relevant information
> about your Windows platform and the exact build error.  And similarly
> for the wingdi case (although that has not been around as long as
> wingcc it is based on it so it may have a common build problem on your
> particular Windows platform).  Arjen or Jim (both with a lot
> of Windows experience) might be able to quickly resolve the issue
> you are encountering.
>
> You might also want to look at
> https://sourceforge.net/p/plplot/support-requests/44/
> (which is in the support-request category, but it is really
> a bug report).  That user was having trouble building wingdi
> on "Cygwin 64 (CYGWIN_NT-10.0) on Winows 10 (64-bit)".  But for
> that same platform he built wingcc with no issues.
>
> @Jim:
>
> You obviously had a lot of discussion with this user concerning his
> wingdi build bug including sending him patches to try, but it seemed
> to trail off at the end with nothing resolved with regard to the
> wingdi build bug on his platform.  What needs to be done to get this
> issue resolved?
>
> 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
> __________________________