plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Python, anyone?

[Greg J. <gv...@gm...>]

>
> This looks a lot like this issue in a different project:
> https://github.com/Homebrew/homebrew/issues/41464
>
> Which seems to be that sip generates for qt5 but the build uses qt4.
> Unfortunately I have not seen a solution and I also can't find anything
> on the PyQt list about this problem.

Yes I think thats exactly the issue, Cygwin builds fine with the same
inputs but the sip output files
are compatible with the qt4 headers.  There's probably a qt4/qt5 switch
needed in the configure-ng.py
module so it can replicate what the configure.py version would do.
  Rather than mess around with qt5 in msys2 I'll install qt5 alongside qt4
in cygwin64 and see if
that will work for python-qt5.

Regards,
Greg

On Fri, Sep 4, 2015 at 6:26 AM, Hazen Babcock <hba...@ma...> wrote:

>
> > Im working on MSYS2 which brings in all of the latest-and-greatest,
> > ground-breaking compatibility-crushing versions, of which python is of
> > course the worst offender.
> >
> > I'm trying to get the PyQT4 binding to work in MSYS2.  All of the
> > prerequisites
> > are ready and I've patched the plplot/cmake scripting to accept the PYQT
> > generated via configure-ng.py (as distinct from configure.py)
> >
> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig
> > The cygwin64 distribution has the up-to-date sip modules, but built with
> > configure.py;
> > it flies through the pyqt4 bindings without error.
> >
> > The problem I'm getting is that the generated .cpp files do not compile
> > just to demonstrate, the first error:
> >
> >> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void
> >> sipQtExtWidget::disconnectNotify(const QMetaMethod&)':
> >> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for
> >> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)'
> >>           QtExtWidget::disconnectNotify(a0);
> >>                                           ^
> >> In file included from
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0,
> >>                   from
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46,
> >>                   from
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49,
> >>                   from
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1,
> >>                   from
> >>
> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13,
> >>                   from
> >>
> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7:
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:
> >> candidate: virtual void QObject::disconnectNotify(const char*)
> >>       virtual void disconnectNotify(const char *signal);
> >>                    ^
> >> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:   no
> >> known conversion for argument 1 from 'const QMetaMethod' to 'const
> char*'
> >
> > ===============
> > Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is
> > different:
> >
> > void sipQtExtWidget::disconnectNotify(const char*a0)
> > {
> >      sip_gilstate_t sipGILState;
> >      PyObject *sipMeth;
> >
> >      sipMeth =
> >
> sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify);
> >
> >      if (!sipMeth)
> >      {
> >          QtExtWidget::disconnectNotify(a0);
> >          return;
> >      }
> >    And it compiles without error.
> > ===============
> >
> >    So who's fault is it? is there a switch to be thrown in the qt
> > configuration so that the headers are compatible with the
> > different code generation?
>
> This looks a lot like this issue in a different project:
> https://github.com/Homebrew/homebrew/issues/41464
>
> Which seems to be that sip generates for qt5 but the build uses qt4.
> Unfortunately I have not seen a solution and I also can't find anything
> on the PyQt list about this problem.
>
> Perhaps it is possible to tell sip which version of qt to use?
>
> Does MSYS2 come with both Qt4 and Qt5? Maybe if you hide qt5 sip will do
> the right thing?
>
> -Hazen
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Python, anyone?

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

On 2015-09-04 09:26-0400 Hazen Babcock wrote:

>
>> Im working on MSYS2 which brings in all of the latest-and-greatest,
>> ground-breaking compatibility-crushing versions, of which python is of
>> course the worst offender.
>>
>> I'm trying to get the PyQT4 binding to work in MSYS2.  All of the
>> prerequisites
>> are ready and I've patched the plplot/cmake scripting to accept the PYQT
>> generated via configure-ng.py (as distinct from configure.py)
>> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig
>> The cygwin64 distribution has the up-to-date sip modules, but built with
>> configure.py;
>> it flies through the pyqt4 bindings without error.
>>
>> The problem I'm getting is that the generated .cpp files do not compile
>> just to demonstrate, the first error:
>>
>>> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void
>>> sipQtExtWidget::disconnectNotify(const QMetaMethod&)':
>>> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for
>>> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)'
>>>           QtExtWidget::disconnectNotify(a0);
>>>                                           ^
>>> In file included from
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0,
>>>                   from
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46,
>>>                   from
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49,
>>>                   from
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1,
>>>                   from
>>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13,
>>>                   from
>>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7:
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:
>>> candidate: virtual void QObject::disconnectNotify(const char*)
>>>       virtual void disconnectNotify(const char *signal);
>>>                    ^
>>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:   no
>>> known conversion for argument 1 from 'const QMetaMethod' to 'const char*'
>>
>> ===============
>> Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is
>> different:
>>
>> void sipQtExtWidget::disconnectNotify(const char*a0)
>> {
>>      sip_gilstate_t sipGILState;
>>      PyObject *sipMeth;
>>
>>      sipMeth =
>> sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify);
>>
>>      if (!sipMeth)
>>      {
>>          QtExtWidget::disconnectNotify(a0);
>>          return;
>>      }
>>    And it compiles without error.
>> ===============
>>
>>    So who's fault is it? is there a switch to be thrown in the qt
>> configuration so that the headers are compatible with the
>> different code generation?
>
> This looks a lot like this issue in a different project:
> https://github.com/Homebrew/homebrew/issues/41464
>
> Which seems to be that sip generates for qt5 but the build uses qt4.
> Unfortunately I have not seen a solution and I also can't find anything
> on the PyQt list about this problem.
>
> Perhaps it is possible to tell sip which version of qt to use?
>
> Does MSYS2 come with both Qt4 and Qt5? Maybe if you hide qt5 sip will do
> the right thing?

To Hazen, Arjen, and Greg:

To answer Hazen's question, from
<http://sourceforge.net/p/msys2/wiki/Packages/> there are both
pyqt4-related and pyqt5-related packages available for
MinGW-w64/MSYS2.  And similarly for qt4 and qt5. Furthermore, in the
past Greg has told me that the qt4-related packages conflict with the
qt5-related packages so you have to choose one or the other but not
both.  Indeed, the cmake package depends on qt5 so Greg built his own
version of CMake that did not have that dependency so he could
consistently use qt4-related MinGW-w64/MSYS2 packages for his recent
successful comprehensive test on that platform (with pyqt4 necessarily
disabled due to issues like above).  I also notice there
is just one sip package on this platform.  My guess is that Hazen nailed
it, and that package probably only generates qt5-compatible code.
So if Greg continues with qt4-only approach, he may just have to always
disable pyqt4 or else build his own MinGW-w64/MSYS2 sip package that
is configured to generate QT4 code rather than Qt5 code.

@Greg: another alternative to the above pure qt4 approach is to try a
pure qt5 approach, i.e., uninstall all qt4-related (and pyqt4-related)
packages and install the qt5-related packages instead. An immediate
side benefit for you _and the rest of our MSYS2 users_ is this
approach makes it possible to use the MinGW-w64/MSYS2 packaged version
of CMake rather than having to build CMake.  If you decide to explore
this possibility, it will be necessary for you to use the
-DPLPLOT_USE_QT5=ON cmake option for the PLplot build system. When I
try that approach on Linux with epa_built Qt5, I get good results so
there is a good chance you will not have any issues with that approach
on MinGW-w64/MSYS2.

The big caveat for -DPLPLOT_USE_QT5=ON is it automatically disables
pyqt4 for obvious reasons which is why the above is just a first step
toward supporting a pyqt5 binding for PLplot.  Creating that binding
is obviously cutting-edge stuff, and will likely require a lot of work
to get right.

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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

On 2015-09-04 09:58+0100 Phil Rosenberg wrote:

> Hi Alan
> To be clear - Plplot built fine for me with VS 2015 even with snprintf
> not being found.

Note the PL_HAVE_SNPRINTF and _PL_HAVE_SNPRINTF preprocessor logic in
include/plplotP.h.  So that build was using a last-resort unsafe
alternative for snprintf.  Therefore, it is good that my fix now does
allow our build system to find and use the safe system version of
snprintf for VS2015 from what you said below.

I also saw your additional note on the bug tracker.  I hope Thorsten's
and your further experience with VS2015 turns up no further issues so
we can close bug 179.

> The only issue on my PC was with including other
> static libraries built with previous VS versions and statically linked
> to the runtime. So shapelib was built expecting to find snprintf in
> the runtime library. Whether or not CMake finds the new inline version
> of snprintf in the VS 2015 runtime is irrelevant. The function
> definition is not in that runtime library so it can't be found to link
> against the instance in shapelib.
>
> The solution there is to rebuild all static libraries used by plplot
> using the same VS version. Alternatively I think using dlls instead or
> dynamically linking to the runtime might fix the problem.
>
> Anyway I tested and CMake does now find snprintf, but x00.exe will not
> link because my shapelib was built with VS 2012. This doesn't mean
> that your change is incorrect. It just means I need to rebuild
> shapelib with VS2015 too.

OK, and good luck with your consistent VS2015 builds going forward.

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] Python, anyone?

[Hazen B. <hba...@ma...>]

> Im working on MSYS2 which brings in all of the latest-and-greatest,
> ground-breaking compatibility-crushing versions, of which python is of
> course the worst offender.
>
> I'm trying to get the PyQT4 binding to work in MSYS2.  All of the
> prerequisites
> are ready and I've patched the plplot/cmake scripting to accept the PYQT
> generated via configure-ng.py (as distinct from configure.py)
> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig
> The cygwin64 distribution has the up-to-date sip modules, but built with
> configure.py;
> it flies through the pyqt4 bindings without error.
>
> The problem I'm getting is that the generated .cpp files do not compile
> just to demonstrate, the first error:
>
>> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void
>> sipQtExtWidget::disconnectNotify(const QMetaMethod&)':
>> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for
>> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)'
>>           QtExtWidget::disconnectNotify(a0);
>>                                           ^
>> In file included from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0,
>>                   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46,
>>                   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49,
>>                   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1,
>>                   from
>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13,
>>                   from
>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7:
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:
>> candidate: virtual void QObject::disconnectNotify(const char*)
>>       virtual void disconnectNotify(const char *signal);
>>                    ^
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:   no
>> known conversion for argument 1 from 'const QMetaMethod' to 'const char*'
>
> ===============
> Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is
> different:
>
> void sipQtExtWidget::disconnectNotify(const char*a0)
> {
>      sip_gilstate_t sipGILState;
>      PyObject *sipMeth;
>
>      sipMeth =
> sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify);
>
>      if (!sipMeth)
>      {
>          QtExtWidget::disconnectNotify(a0);
>          return;
>      }
>    And it compiles without error.
> ===============
>
>    So who's fault is it? is there a switch to be thrown in the qt
> configuration so that the headers are compatible with the
> different code generation?

This looks a lot like this issue in a different project:
https://github.com/Homebrew/homebrew/issues/41464

Which seems to be that sip generates for qt5 but the build uses qt4. 
Unfortunately I have not seen a solution and I also can't find anything 
on the PyQt list about this problem.

Perhaps it is possible to tell sip which version of qt to use?

Does MSYS2 come with both Qt4 and Qt5? Maybe if you hide qt5 sip will do 
the right thing?

-Hazen

Re: [Plplot-devel] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

Hi Alan
To be clear - Plplot built fine for me with VS 2015 even with snprintf
not being found. The only issue on my PC was with including other
static libraries built with previous VS versions and statically linked
to the runtime. So shapelib was built expecting to find snprintf in
the runtime library. Whether or not CMake finds the new inline version
of snprintf in the VS 2015 runtime is irrelevant. The function
definition is not in that runtime library so it can't be found to link
against the instance in shapelib.

The solution there is to rebuild all static libraries used by plplot
using the same VS version. Alternatively I think using dlls instead or
dynamically linking to the runtime might fix the problem.

Anyway I tested and CMake does now find snprintf, but x00.exe will not
link because my shapelib was built with VS 2012. This doesn't mean
that your change is incorrect. It just means I need to rebuild
shapelib with VS2015 too.

Phil

On 4 September 2015 at 00:56, Alan W. Irwin <ir...@be...> wrote:
> On 2015-09-03 22:06+0100 Phil Rosenberg wrote:
>
>> [...] Note that both snprintf and _snprintf are listed as not found by
>> cmake. But this isn't a blanket loss of the check_function_exists()
>> function. isnan and isfinite are both found and I presume they use
>> check_function_exists()?
>>
>> I then reread your email and found you provided a rather shorter test.
>> I dumped this in a cmakelists.txt file and this could not find
>> snprintf either
>>
>>
>> I figured we can't be the only people having this issue so I googled
>> it and found this page
>>
>> http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=15659&graph=relation
>>
>> It seems that snprintf and a number of other io related functions are
>> now defined inline in stdio.h. This explains my linker errors above
>> when shapelib was included - snprintf was not found because it is no
>> longer in the library. The answer apparently is to use
>> CheckSymbolExists instead.
>>
>> The following works correctly
>>
>> cmake_minimum_required(VERSION 2.8.9)
>> project(test_check C)
>> include(CheckSymbolExists)
>> check_symbol_exists(snprintf stdio.h PL_HAVE_SNPRINTF)
>> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")
>
>
>> So this is really nothing to do with the new "Universal" nature of the
>> CRT, it's just that the new CRT has inlined those particular
>> functions.
>
>
> Hi Phil:
>
> Thanks very much for the above investigation.
>
>>
>> Alan I will leave you to integrate this how you see fit as I wouldn't
>> know where to start.
>>
>
> It turns out we use check_function_exists a lot of places in our build
> system, but I don't think any of those have to do with io-related
> functions other than the checks for snprintf and _snprintf.  So I have
> only changed those two instances (see commit id ac0f09f) to use the
> check_symbol_exists form that you found above works for you (and
> which also works for me on Linux).
>
> To finish off this topic, please test this latest version of PLplot
> for your Visual Studio 2015 platform and assuming that the PLplot
> build shows no other check_function_exists failures, then please close
> the bug report appropriately.
>
>
> 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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

Hi Phil:

On 2015-09-03 22:52+0100 Phil Rosenberg wrote:

> Hi Alan
> Did you see my subsequent email?

Yes, and responded to it as well.

We did have some crossed e-mail, but I think we are in synch now.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

On 2015-09-03 22:06+0100 Phil Rosenberg wrote:

> [...] Note that both snprintf and _snprintf are listed as not found by
> cmake. But this isn't a blanket loss of the check_function_exists()
> function. isnan and isfinite are both found and I presume they use
> check_function_exists()?
>
> I then reread your email and found you provided a rather shorter test.
> I dumped this in a cmakelists.txt file and this could not find
> snprintf either
>
>
> I figured we can't be the only people having this issue so I googled
> it and found this page
> http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=15659&graph=relation
>
> It seems that snprintf and a number of other io related functions are
> now defined inline in stdio.h. This explains my linker errors above
> when shapelib was included - snprintf was not found because it is no
> longer in the library. The answer apparently is to use
> CheckSymbolExists instead.
>
> The following works correctly
>
> cmake_minimum_required(VERSION 2.8.9)
> project(test_check C)
> include(CheckSymbolExists)
> check_symbol_exists(snprintf stdio.h PL_HAVE_SNPRINTF)
> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")

> So this is really nothing to do with the new "Universal" nature of the
> CRT, it's just that the new CRT has inlined those particular
> functions.

Hi Phil:

Thanks very much for the above investigation.

>
> Alan I will leave you to integrate this how you see fit as I wouldn't
> know where to start.
>

It turns out we use check_function_exists a lot of places in our build
system, but I don't think any of those have to do with io-related
functions other than the checks for snprintf and _snprintf.  So I have
only changed those two instances (see commit id ac0f09f) to use the
check_symbol_exists form that you found above works for you (and
which also works for me on Linux).

To finish off this topic, please test this latest version of PLplot
for your Visual Studio 2015 platform and assuming that the PLplot
build shows no other check_function_exists failures, then please close
the bug report appropriately.

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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

Hi Alan
Did you see my subsequent email?

Phil

On 3 September 2015 at 22:20, Alan W. Irwin <ir...@be...> wrote:
> On 2015-09-03 21:04+0100 Phil Rosenberg wrote:
>
>> Hi  Alan
>> Yes I have it installed, but haven't really tried it much yet (I was
>> lured into playing with its new ability to us it to debug on a Linux
>> machine using GDB via ssh) I will try a PLPlot build now and see what
>> happens.
>>
>> I have just read the link you provided. It is a useful mov they are
>> making. I personally always use static linking to the runtime so that
>> if I give an exe to someone else it will "just work" and there is no
>> need for them to install a visual studio runtime (which must be the
>> correct VS version). The move to including the runtime as part of the
>> OS is more like the way I think Linux works, and there everyone builds
>> using dynamic linking to the runtime with generally good result.
>>
>> I don't really understand what the implication is for snprintf or
>> check_function_exists(). Why would having the CRT as part of the OS,
>> rather than as an installed component make any difference? Is this a
>> CMAke bug rather than a PLPlot bug?
>
>
> Hi Phil:
>
> I don't think we need to be concerned about bugs in
> check_function_exists() since it is really simple; it creates source
> code with a call to the required function, and checks that source code
> can be built and linked using the CMAKE_REQUIRED_* variables set by
> our build system.
>
> Normally, we don't set those CMAKE_REQUIRED_* variables at all, and
> check_function_exists(snprintf PL_HAVE_SNPRINTF) (or the alternative
> check_function_exists(_snprintf _PL_HAVE_SNPRINTF) just works without
> issues.  However, from the bug report it appears that is not the case
> for VC14 and above.  So the first step is to verify the problem on
> that platform, i.e., with
>
> cmake_minimum_required(VERSION 2.8.9)
> project(test_check C)
> message(STATUS "CMake version = ${CMAKE_VERSION}")
> message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")
> include(CheckFunctionExists)
> check_function_exists(snprintf PL_HAVE_SNPRINTF)
> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")
> check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
> message(STATUS "_PL_HAVE_SNPRINTF = ${_PL_HAVE_SNPRINTF}")
>
> Note the extra message commands for figuring out details of your test
> platform and the extra two commands for testing the function _snprintf
> compared to what I recommended before.  If both PL_HAVE_SNPRINTF and
> _PL_HAVE_SNPRINTF are false you will have verified the problem, and we
> can take it from there by figuring out what CMAKE_REQUIRED_* variables
> need to be set so that one or both of PL_HAVE_SNPRINTF and
> _PL_HAVE_SNPRINTF are true.
>
>
> 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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

On 2015-09-03 21:04+0100 Phil Rosenberg wrote:

> Hi  Alan
> Yes I have it installed, but haven't really tried it much yet (I was
> lured into playing with its new ability to us it to debug on a Linux
> machine using GDB via ssh) I will try a PLPlot build now and see what
> happens.
>
> I have just read the link you provided. It is a useful mov they are
> making. I personally always use static linking to the runtime so that
> if I give an exe to someone else it will "just work" and there is no
> need for them to install a visual studio runtime (which must be the
> correct VS version). The move to including the runtime as part of the
> OS is more like the way I think Linux works, and there everyone builds
> using dynamic linking to the runtime with generally good result.
>
> I don't really understand what the implication is for snprintf or
> check_function_exists(). Why would having the CRT as part of the OS,
> rather than as an installed component make any difference? Is this a
> CMAke bug rather than a PLPlot bug?

Hi Phil:

I don't think we need to be concerned about bugs in
check_function_exists() since it is really simple; it creates source
code with a call to the required function, and checks that source code
can be built and linked using the CMAKE_REQUIRED_* variables set by
our build system.

Normally, we don't set those CMAKE_REQUIRED_* variables at all, and
check_function_exists(snprintf PL_HAVE_SNPRINTF) (or the alternative
check_function_exists(_snprintf _PL_HAVE_SNPRINTF) just works without
issues.  However, from the bug report it appears that is not the case
for VC14 and above.  So the first step is to verify the problem on
that platform, i.e., with

cmake_minimum_required(VERSION 2.8.9)
project(test_check C)
message(STATUS "CMake version = ${CMAKE_VERSION}")
message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")
include(CheckFunctionExists)
check_function_exists(snprintf PL_HAVE_SNPRINTF)
message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")
check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
message(STATUS "_PL_HAVE_SNPRINTF = ${_PL_HAVE_SNPRINTF}")

Note the extra message commands for figuring out details of your test
platform and the extra two commands for testing the function _snprintf
compared to what I recommended before.  If both PL_HAVE_SNPRINTF and
_PL_HAVE_SNPRINTF are false you will have verified the problem, and we
can take it from there by figuring out what CMAKE_REQUIRED_* variables
need to be set so that one or both of PL_HAVE_SNPRINTF and
_PL_HAVE_SNPRINTF are true.

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] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

Hi Alan
Here are the tests I have performed.
First I simply changed the generator to Visual Studio 14 Win64, then
in the resulting solution I tried to build example 0.

This resulted in many version mismatch errors with wxWidgets, because
wxWidgets was built with VS 2012. I rebuild with
-DENABLE_wxwidgets=OFF.
I then got two linking errors related to shapelib:

12>shapelib.lib(safileio.obj) : error LNK2019: unresolved external
symbol __iob_func referenced in function SADError

12>shapelib.lib(shpopen.obj) : error LNK2019: unresolved external
symbol _snprintf referenced in function SHPReadObject

Again shapelib was built using Visual Studio 2012. So I added
-DHAVE_SHAPELIB=OFF

Now x00.exe builds fine.

Note that both snprintf and _snprintf are listed as not found by
cmake. But this isn't a blanket loss of the check_function_exists()
function. isnan and isfinite are both found and I presume they use
check_function_exists()?

I then reread your email and found you provided a rather shorter test.
I dumped this in a cmakelists.txt file and this could not find
snprintf either


I figured we can't be the only people having this issue so I googled
it and found this page
http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=15659&graph=relation

It seems that snprintf and a number of other io related functions are
now defined inline in stdio.h. This explains my linker errors above
when shapelib was included - snprintf was not found because it is no
longer in the library. The answer apparently is to use
CheckSymbolExists instead.

The following works correctly

cmake_minimum_required(VERSION 2.8.9)
project(test_check C)
include(CheckSymbolExists)
check_symbol_exists(snprintf stdio.h PL_HAVE_SNPRINTF)
message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")


So this is really nothing to do with the new "Universal" nature of the
CRT, it's just that the new CRT has inlined those particular
functions.

Alan I will leave you to integrate this how you see fit as I wouldn't
know where to start.

Phil

On 3 September 2015 at 21:04, Phil Rosenberg <p.d...@gm...> wrote:
> Hi  Alan
> Yes I have it installed, but haven't really tried it much yet (I was
> lured into playing with its new ability to us it to debug on a Linux
> machine using GDB via ssh) I will try a PLPlot build now and see what
> happens.
>
> I have just read the link you provided. It is a useful mov they are
> making. I personally always use static linking to the runtime so that
> if I give an exe to someone else it will "just work" and there is no
> need for them to install a visual studio runtime (which must be the
> correct VS version). The move to including the runtime as part of the
> OS is more like the way I think Linux works, and there everyone builds
> using dynamic linking to the runtime with generally good result.
>
> I don't really understand what the implication is for snprintf or
> check_function_exists(). Why would having the CRT as part of the OS,
> rather than as an installed component make any difference? Is this a
> CMAke bug rather than a PLPlot bug?
>
> Phil
>
> On 3 September 2015 at 18:46, Alan W. Irwin <ir...@be...> wrote:
>> To Phil, Jim, and Greg:
>>
>> Do any of you have access to VC14 (a.k.a Visual Studio 2015)?  If so
>> I need your Windows expertise for dealing with the bug report below
>> which is likely the tip of the iceberg for a whole bunch of
>> troubles with Windows linking for that platform.  For example,
>> I looked up Universal CRT, and found
>> <http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx>
>> which appears to say that linking should be different for VC14 and
>> beyond.  But if that is the case, the proper cure for this issue
>> is to set one or more of
>>
>> CMAKE_REQUIRED_FLAGS = string of compile command line flags
>> CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
>> CMAKE_REQUIRED_INCLUDES = list of include directories
>> CMAKE_REQUIRED_LIBRARIES = list of libraries to link
>>
>> appropriately before _all_ calls to check_* CMake functions such as
>> the particular use of check_function_exists below.  But I need your
>> advice on what the values of the above variables should be for VC14
>> and beyond.
>>
>> To explore what is possible I recommend using some variant (with
>> some of the above variables set) of the following test cmake
>> mini-project.
>>
>> cmake_minimum_required(VERSION 2.8.9)
>> project(test_check C)
>> include(CheckFunctionExists)
>> check_function_exists(snprintf PL_HAVE_SNPRINTF)
>> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")
>>
>> This project gives good results, i.e.,
>>
>> -- The C compiler identification is GNU 4.7.2
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Looking for snprintf
>> -- Looking for snprintf - found
>> -- PL_HAVE_SNPRINTF = 1
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/irwin/test_cmake2/build_dir
>>
>> for me on Linux, and my question for you boils down to what values
>> need to be assigned to the above variables so this mini-project also
>> works (i.e., yields PL_HAVE_SNPRINTF = 1) on VC14 for the latest CMake
>> version you have access to?
>>
>> By the way, our handling of the CMAKE_REQUIRED_* variables for the
>> check_* CMake functions that we use is currently a mess, and I am in
>> the process of fixing that.  If your run of the above test for VC14
>> shows no CMAKE_DEFINED_* variables have to be set, then my fix will be
>> the only required change.  However, if CMAKE_DEFINED_* variables do
>> have to be set in order for the above test to work, my fix will put me
>> in a good position to use that information.
>>
>> 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: Thu, 03 Sep 2015 12:07:41 +0000
>> From: Torsten Martinsen <bul...@us...>
>> Reply-To: Ticket 179 <17...@bu...>
>> To: Ticket 179 <17...@bu...>
>> Subject: [plplot:bugs] #179 Detection of snprintf fails with VC14
>>
>>
>>
>>
>> ---
>>
>> ** [bugs:#179] Detection of snprintf fails with VC14**
>>
>> **Status:** open
>> **Group:**
>> **Labels:** vc14
>> **Created:** Thu Sep 03, 2015 12:07 PM UTC by Torsten Martinsen
>> **Last Updated:** Thu Sep 03, 2015 12:07 PM UTC
>> **Owner:** nobody
>>
>>
>> Due to the Universal CRT introduced in VC14 (aka Visual Studio 2015),
>> check_function_exists() no longer works for detecting the presence of
>> snprintf(). This leads to a linker error when using the library.
>>
>> This patch fixed it for me:
>> ~~~~
>> diff --git a/cmake/modules/plplot.cmake b/cmake/modules/plplot.cmake
>> index 90aac62..7fea410 100644
>> --- a/cmake/modules/plplot.cmake
>> +++ b/cmake/modules/plplot.cmake
>> @@ -347,7 +347,11 @@ if(PL__HAVE_ISINF)
>>  endif(PL__HAVE_ISINF)
>>
>>
>> -check_function_exists(snprintf PL_HAVE_SNPRINTF)
>> +if(MSVC_VERSION EQUAL 1900)
>> +  set(PL_HAVE_SNPRINTF 1)
>> +else(MSVC_VERSION EQUAL 1900)
>> +  check_function_exists(snprintf PL_HAVE_SNPRINTF)
>> +endif(MSVC_VERSION EQUAL 1900)
>>  if(NOT PL_HAVE_SNPRINTF)
>>    check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
>>    set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function
>> _sprintf")
>> ~~~~
>>
>>
>> ---
>>
>> Sent from sourceforge.net because you indicated interest in
>> <https://sourceforge.net/p/plplot/bugs/179/>
>>
>>
>>
>> To unsubscribe from further messages, please visit
>> <https://sourceforge.net/auth/subscriptions/>

Re: [Plplot-devel] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

Hi  Alan
Yes I have it installed, but haven't really tried it much yet (I was
lured into playing with its new ability to us it to debug on a Linux
machine using GDB via ssh) I will try a PLPlot build now and see what
happens.

I have just read the link you provided. It is a useful mov they are
making. I personally always use static linking to the runtime so that
if I give an exe to someone else it will "just work" and there is no
need for them to install a visual studio runtime (which must be the
correct VS version). The move to including the runtime as part of the
OS is more like the way I think Linux works, and there everyone builds
using dynamic linking to the runtime with generally good result.

I don't really understand what the implication is for snprintf or
check_function_exists(). Why would having the CRT as part of the OS,
rather than as an installed component make any difference? Is this a
CMAke bug rather than a PLPlot bug?

Phil

On 3 September 2015 at 18:46, Alan W. Irwin <ir...@be...> wrote:
> To Phil, Jim, and Greg:
>
> Do any of you have access to VC14 (a.k.a Visual Studio 2015)?  If so
> I need your Windows expertise for dealing with the bug report below
> which is likely the tip of the iceberg for a whole bunch of
> troubles with Windows linking for that platform.  For example,
> I looked up Universal CRT, and found
> <http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx>
> which appears to say that linking should be different for VC14 and
> beyond.  But if that is the case, the proper cure for this issue
> is to set one or more of
>
> CMAKE_REQUIRED_FLAGS = string of compile command line flags
> CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
> CMAKE_REQUIRED_INCLUDES = list of include directories
> CMAKE_REQUIRED_LIBRARIES = list of libraries to link
>
> appropriately before _all_ calls to check_* CMake functions such as
> the particular use of check_function_exists below.  But I need your
> advice on what the values of the above variables should be for VC14
> and beyond.
>
> To explore what is possible I recommend using some variant (with
> some of the above variables set) of the following test cmake
> mini-project.
>
> cmake_minimum_required(VERSION 2.8.9)
> project(test_check C)
> include(CheckFunctionExists)
> check_function_exists(snprintf PL_HAVE_SNPRINTF)
> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")
>
> This project gives good results, i.e.,
>
> -- The C compiler identification is GNU 4.7.2
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Looking for snprintf
> -- Looking for snprintf - found
> -- PL_HAVE_SNPRINTF = 1
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/irwin/test_cmake2/build_dir
>
> for me on Linux, and my question for you boils down to what values
> need to be assigned to the above variables so this mini-project also
> works (i.e., yields PL_HAVE_SNPRINTF = 1) on VC14 for the latest CMake
> version you have access to?
>
> By the way, our handling of the CMAKE_REQUIRED_* variables for the
> check_* CMake functions that we use is currently a mess, and I am in
> the process of fixing that.  If your run of the above test for VC14
> shows no CMAKE_DEFINED_* variables have to be set, then my fix will be
> the only required change.  However, if CMAKE_DEFINED_* variables do
> have to be set in order for the above test to work, my fix will put me
> in a good position to use that information.
>
> 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: Thu, 03 Sep 2015 12:07:41 +0000
> From: Torsten Martinsen <bul...@us...>
> Reply-To: Ticket 179 <17...@bu...>
> To: Ticket 179 <17...@bu...>
> Subject: [plplot:bugs] #179 Detection of snprintf fails with VC14
>
>
>
>
> ---
>
> ** [bugs:#179] Detection of snprintf fails with VC14**
>
> **Status:** open
> **Group:**
> **Labels:** vc14
> **Created:** Thu Sep 03, 2015 12:07 PM UTC by Torsten Martinsen
> **Last Updated:** Thu Sep 03, 2015 12:07 PM UTC
> **Owner:** nobody
>
>
> Due to the Universal CRT introduced in VC14 (aka Visual Studio 2015),
> check_function_exists() no longer works for detecting the presence of
> snprintf(). This leads to a linker error when using the library.
>
> This patch fixed it for me:
> ~~~~
> diff --git a/cmake/modules/plplot.cmake b/cmake/modules/plplot.cmake
> index 90aac62..7fea410 100644
> --- a/cmake/modules/plplot.cmake
> +++ b/cmake/modules/plplot.cmake
> @@ -347,7 +347,11 @@ if(PL__HAVE_ISINF)
>  endif(PL__HAVE_ISINF)
>
>
> -check_function_exists(snprintf PL_HAVE_SNPRINTF)
> +if(MSVC_VERSION EQUAL 1900)
> +  set(PL_HAVE_SNPRINTF 1)
> +else(MSVC_VERSION EQUAL 1900)
> +  check_function_exists(snprintf PL_HAVE_SNPRINTF)
> +endif(MSVC_VERSION EQUAL 1900)
>  if(NOT PL_HAVE_SNPRINTF)
>    check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
>    set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function
> _sprintf")
> ~~~~
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/plplot/bugs/179/>
>
>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>

[Plplot-devel] Python, anyone?

[Greg J. <gv...@gm...>]

Im working on MSYS2 which brings in all of the latest-and-greatest,
ground-breaking compatibility-crushing versions, of which python is of
course the worst offender.

I'm trying to get the PyQT4 binding to work in MSYS2.  All of the
prerequisites
are ready and I've patched the plplot/cmake scripting to accept the PYQT
generated via configure-ng.py (as distinct from configure.py)
http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig
The cygwin64 distribution has the up-to-date sip modules, but built with
configure.py;
it flies through the pyqt4 bindings without error.

The problem I'm getting is that the generated .cpp files do not compile
just to demonstrate, the first error:

> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void
> sipQtExtWidget::disconnectNotify(const QMetaMethod&)':
> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for
> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)'
>          QtExtWidget::disconnectNotify(a0);
>                                          ^
> In file included from
> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0,
>                  from
> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46,
>                  from
> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49,
>                  from
> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1,
>                  from
> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13,
>                  from
> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7:
> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:
> candidate: virtual void QObject::disconnectNotify(const char*)
>      virtual void disconnectNotify(const char *signal);
>                   ^
> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:   no
> known conversion for argument 1 from 'const QMetaMethod' to 'const char*'

===============
Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is
different:

void sipQtExtWidget::disconnectNotify(const char*a0)
{
    sip_gilstate_t sipGILState;
    PyObject *sipMeth;

    sipMeth =
sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify);

    if (!sipMeth)
    {
        QtExtWidget::disconnectNotify(a0);
        return;
    }
  And it compiles without error.
===============

  So who's fault is it? is there a switch to be thrown in the qt
configuration so that the headers are compatible with the
different code generation?

Regards,
Greg

[Plplot-devel] [plplot:bugs] #179 Detection of snprintf fails with VC14 (fwd)

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

To Phil, Jim, and Greg:

Do any of you have access to VC14 (a.k.a Visual Studio 2015)?  If so
I need your Windows expertise for dealing with the bug report below
which is likely the tip of the iceberg for a whole bunch of
troubles with Windows linking for that platform.  For example,
I looked up Universal CRT, and found
<http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx>
which appears to say that linking should be different for VC14 and
beyond.  But if that is the case, the proper cure for this issue
is to set one or more of

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LIBRARIES = list of libraries to link

appropriately before _all_ calls to check_* CMake functions such as
the particular use of check_function_exists below.  But I need your
advice on what the values of the above variables should be for VC14
and beyond.

To explore what is possible I recommend using some variant (with
some of the above variables set) of the following test cmake
mini-project.

cmake_minimum_required(VERSION 2.8.9)
project(test_check C)
include(CheckFunctionExists)
check_function_exists(snprintf PL_HAVE_SNPRINTF)
message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}")

This project gives good results, i.e.,

-- The C compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Looking for snprintf
-- Looking for snprintf - found
-- PL_HAVE_SNPRINTF = 1
-- Configuring done
-- Generating done
-- Build files have been written to: /home/irwin/test_cmake2/build_dir

for me on Linux, and my question for you boils down to what values
need to be assigned to the above variables so this mini-project also
works (i.e., yields PL_HAVE_SNPRINTF = 1) on VC14 for the latest CMake
version you have access to?

By the way, our handling of the CMAKE_REQUIRED_* variables for the
check_* CMake functions that we use is currently a mess, and I am in
the process of fixing that.  If your run of the above test for VC14
shows no CMAKE_DEFINED_* variables have to be set, then my fix will be
the only required change.  However, if CMAKE_DEFINED_* variables do
have to be set in order for the above test to work, my fix will put me
in a good position to use that information.

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: Thu, 03 Sep 2015 12:07:41 +0000
From: Torsten Martinsen <bul...@us...>
Reply-To: Ticket 179 <17...@bu...>
To: Ticket 179 <17...@bu...>
Subject: [plplot:bugs] #179 Detection of snprintf fails with VC14




---

** [bugs:#179] Detection of snprintf fails with VC14**

**Status:** open
**Group:**
**Labels:** vc14
**Created:** Thu Sep 03, 2015 12:07 PM UTC by Torsten Martinsen
**Last Updated:** Thu Sep 03, 2015 12:07 PM UTC
**Owner:** nobody


Due to the Universal CRT introduced in VC14 (aka Visual Studio 2015), check_function_exists() no longer works for detecting the presence of snprintf(). This leads to a linker error when using the library.

This patch fixed it for me:
~~~~
diff --git a/cmake/modules/plplot.cmake b/cmake/modules/plplot.cmake
index 90aac62..7fea410 100644
--- a/cmake/modules/plplot.cmake
+++ b/cmake/modules/plplot.cmake
@@ -347,7 +347,11 @@ if(PL__HAVE_ISINF)
  endif(PL__HAVE_ISINF)


-check_function_exists(snprintf PL_HAVE_SNPRINTF)
+if(MSVC_VERSION EQUAL 1900)
+  set(PL_HAVE_SNPRINTF 1)
+else(MSVC_VERSION EQUAL 1900)
+  check_function_exists(snprintf PL_HAVE_SNPRINTF)
+endif(MSVC_VERSION EQUAL 1900)
  if(NOT PL_HAVE_SNPRINTF)
    check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
    set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function _sprintf")
~~~~


---

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



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

Re: [Plplot-devel] Patch for wingcc.c

[Greg J. <gv...@gm...>]

Subject: [PATCH] Change window behavior to maintain keyboard focus at the
 console window. When window is created, there is no expected keyboard input
 and so no need to be a foregrouind window, but we do want it to show
 completely so  "BringWindowToTop" replaces "SetForeGroundWindow".
Otherwise
 it is difficult/(impossible?) for the user to regain forground status in
the
 console window without a user mouse click.


> Jim> There is a change in input focus behavior with this patch that we
> should consider.  Prior to this patch, the input focus would switch to the
> PLplot window and now the window is brought to the top but the input focus
> stays with the parent window.  This behavior is also different from the
> xwin driver.  The other twist is that the behavior is different between
> wingcc on cygwin (input focus stays with parent) and wingcc on msvc (input
> focus shifts to the PLplot window) for some reason that I cannot discern.


Jim> I think the input focus staying with the parent is a good idea in
> general, but it does change the behavior.  It is not a big deal for me if
> we change the input focus behavior or stay with the original behavior.  At
> the very least, I would like to keep the ability and make it a driver
> option (and extend to the other drivers).


Alan> Then bring up the focus topic on the mailing list for further

discussion about what we should do for all interactive devices.


  Background on this: when I first found the GDL program, this focus issue
was the first on my list of "easy" fixes, and a vital fix.
My usage of IDL (which GDL emulates closely) consisted of slinging around
data variables, plotting them visually, etc, over and
over again.  So keeping the keyboard focus at the console window was
important to productivity.  In the windows GDL version
I tried several different tactics to get the behavior but changing the
wingcc driver was the only good fix.  The X version of
GDL  uses Xlib calls to reset focus after a window is created,  but I found
the behavior is not guaranteed especially with the "fancy"
windows managers - I had to de-tune the KDE plasma window manager to get
cooperation (XFCE doesn't interfere).

On Mon, Aug 31, 2015 at 10:05 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-08-30 22:38-0400 Jim Dishaw wrote:
>
>
>> On Aug 29, 2015, at 5:20 PM, Alan W. Irwin <ir...@be...>
>>> wrote:
>>>
>>> To Greg and Jim:
>>>
>>> @Greg: Thanks for this suggested commit that you have formatted with "git
>>> format-patch".
>>>
>>> @Jim: I cannot test wingcc in any way so I will leave it strictly to
>>> you to evaluate Greg's commit, but in case you mostly or completely
>>> like it, and you are wondering how to handle it with git, apply his
>>> commit on a local topic branch using the "git am" command, and then
>>> amend that commit (if necessary) using the "git commit --amend"
>>> command (e.g., to modify the commit message so there is a topic line
>>> in the commit message), then invoke the usual git commands to push
>>> Greg's (modified) commit to master.
>>>
>>>
>> I looked at the patch and it worked fine in both the cygwin and MSVC
>> environments.
>>
>
> There is a change in input focus behavior with this patch that we
>>
> should consider.  Prior to this patch, the input focus would switch to
> the PLplot window and now the window is brought to the top but the
> input focus stays with the parent window.  This behavior is also
> different from the xwin driver.  The other twist is that the behavior
> is different between wingcc on cygwin (input focus stays with parent)
> and wingcc on msvc (input focus shifts to the PLplot window) for some
> reason that I cannot discern.
>
> I think the input focus staying with the parent is a good idea in
>>
> general, but it does change the behavior.  It is not a big deal for me
> if we change the input focus behavior or stay with the original
> behavior.  At the very least, I would like to keep the ability and
> make it a driver option (and extend to the other drivers).
>
> I will hold off on committing until we come to a decision.
>>
>
> Hi Jim:
>
> It sounds to me from what you have said that the change in focus
> behaviour should be done in a separate later commit (if at all). So I
> suggest you amend the commit to drop the change in focus behaviour
> (and change the commit message accordingly), and push that simplified
> amended commit to master.
>
> Then bring up the focus topic on the mailing list for further
> discussion about what we should do for all interactive devices.
>
>
> 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] More on dpi, length default values

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

On 2015-08-28 09:58+0100 Phil Rosenberg wrote:

> Hi Alan
> I have just noticed there is a value PL_NOTSET. This is documented in
> plsdidev as a value to pass in when you do not wish to set a value. I
> wondered if this might be usefully used in plspage. It would be much
> better than passing in 0 or using zero to represent unset particularly
> for the location. Currently in plspage it is impossible to set the
> location (xoff, yoff) to (0,0) or to tell if the location is supposed
> to be zero or if it is just unset.
>
> Of course the upshot is that this is an API change that will probably
> break all the drivers and some user code. Also the value of PL_NOTSET
> of -42 is not ideal as it would be perfectly legal to have a position
> of -42. Something like MIN_PLINT would be better.

Hi Phil:

The current 0. for [xy]upi and 0 for [xy]length to signal those values
are unset should remain unchanged since those values are invalid for
upi and length.  However, I agree that using 0 to signal [xy]offset is
unset is far from ideal since that is not an invalid value and there
is a similar objection to using PL_NOTSET for this purpose.

> This is really just a mention, I'm not saying we should do it as the
> cost is pretty high. But something to think about.

The minimum possible PLINT is definitely an invalid offset value so
I think your idea to use MIN_PLINT to signal [xy]offset is unset is a good
one so long as you continue to use 0. for [xy]upi and 0 for [xy]length
to signal those values are unset.  Furthermore, I don't feel the cost
of this backwards incompatible API change is very high since my guess
is few users bother with getting/setting [xy]offset. So I think this
change is fine if accompanied by the necessary documentation changes
for plspage and plgpage, and an announcement in README.release
concerning this (minor) backwards-incompatible change in our API.

Thus, if nobody else objects, I suggest you search through our entire
source tree for mentions of [xy]offset, plgpage, and plspage, and make
this global MIN_PLINT change accordingly.

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] More on dpi, length default values

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

Hi Alan
I have just noticed there is a value PL_NOTSET. This is documented in
plsdidev as a value to pass in when you do not wish to set a value. I
wondered if this might be usefully used in plspage. It would be much
better than passing in 0 or using zero to represent unset particularly
for the location. Currently in plspage it is impossible to set the
location (xoff, yoff) to (0,0) or to tell if the location is supposed
to be zero or if it is just unset.

Of course the upshot is that this is an API change that will probably
break all the drivers and some user code. Also the value of PL_NOTSET
of -42 is not ideal as it would be perfectly legal to have a position
of -42. Something like MIN_PLINT would be better.

This is really just a mention, I'm not saying we should do it as the
cost is pretty high. But something to think about.

Phil

On 25 August 2015 at 20:06, Alan W. Irwin <ir...@be...> wrote:
> On 2015-08-25 08:15+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>>
>>> Instead of multiplying the MM values by 72/25.4 within drivers like
>>> svg whose length units are pts, I intend instead to simply #define
>>> PLPLOT_DEFAULT_PTPI, PLPLOT_DEFAULT_WIDTH_PT, and
>>> PLPLOT_DEFAULT_HEIGHT_PT in plplotP.h and use those values in pt devices.
>>
>>
>> Works for me, I have no strong feelings here.
>>
>>>
>>> It is also becoming pretty clear to me that plsc->xdpi and plsc->ydpi
>>> are misnomers since dots per inch normally would refer to pixels only.
>>> Thus, I will probably change those to plsc->xupi and plsc->yupi where
>>> "upi" stands for units per inch where units could be pixels, pts, mm,
>>> or whatever length unit is appropriate to the device.
>>
>>
>> In the documentation it says that dpi will only be used by raster
>> drivers and drivers which use real world units will ignore the dpi
>> measurements. I don't know if svg or ps or pdf drivers actually use
>> the dpi value at all, but given that statement in the docs then
>> leaving it as dpi or using ppi might be a better description.
>> In the API these variables are called xp and yp, which are not very
>> descriptive This is somewhere it might be worth making a change, where
>> I would suggest changing them to dpi or ppi.
>
>
> Hi Phil:
>
> Actually, that remark about dpi being ignored by "real-world" drivers
> is something you included in your recent changes to the plspage
> documentation which was probably based on an earlier e-mail remark by
> me.  I am not sure this is actually true at the moment for our
> "real-world" drivers, but I certainly believe it is a worthwhile goal
> for them since changing the number of mm per inch or pts per inch
> should do very little other than to cause mass confusion.
>
> At the same time, though, I see nothing wrong with real-world devices
> calling plspage with the units per inch that they use so that
> plsc->xupi and plsc->yupi will reflect that in case those values are
> of some use to the user. Therefore, I am still leaning strongly toward
> the above rename from dpi to upi.
>
> Also, I plan to change
>
> PLPLOT_DEFAULT_MMPI ==> PLPLOT_MMPI
> PLPLOT_DEFAULT_PTPI ==> PLPLOT_PTPI
>
> (i.e., drop DEFAULT from the name) since there is nothing "default"
> about these values).  But I will retain the
>
> PLPLOT_DEFAULT_PIXPI
>
> name since that really is a default value that is only adopted if the
> user does not select some other value.
>
> Finally, I have to say that making all devices follow the same set of
> rules for getting and setting upi and length values (with
> well-established variations for each general kind of device length
> unit) is long overdue, and we are still very early in the stages of
> the whole process.  So our current ideas about what the rules should
> be are mostly theoretical and will likely require revision as we gain
> practical experience with this change for more and more of our
> devices.
>
>
> 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] Rotated text

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

Hi Phil:

On 2015-08-26 14:46+0100 Phil Rosenberg wrote:

> Having looked at this a bit I think the 3d text routines ignore
> whatever device units per mm have been set and must work in device
> units only.  Whereas standard rotated text honours the mm dimensions of
> the device. It wouldn't surprise me if there was a good reason for
> this, but I can't quite work it out.

Sounds like a clear bug since text is in real-world units and device
length units could be pixels.

>
> To make the two compatible I have made the driver claim to be square
> in both device units and mm and then the driver corrects for this in
> its text render routine. It's a bit of a fudge, but it does the job.

That is good you found a workaround for the above bug that solved so
many wxwidgets bugs, but I hope you will be able to immediately build
on the insight gained with that workaround by going ahead and fixing
the above fundamental bug (which should allow you to drop the
workaround that claims the device is square).

Also, please commit a file called drivers/README.coordinates
summarizing the knowledge you have gained so far on the various PLplot
coordinates. I think we are all pretty much lost on the topic of our
coordinates so stating what we do know _and why_ may help us all to
regain the expertise in this area that we should have to determine
whether something like the above peculiar result is a bug or not.

> In the future we should probably either make the two consistent or
> remove the ability to set different device units per mm in the x and y
> directions.

I believe we should continue to support the ability to have different
pixels/inch in X and Y dimensions since underlying libraries like X
also support that even though presumably a device with different
pixels per inch in X and Y is fairly rare.

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] Rotated text

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

On 2015-08-26 11:02+0100 Phil Rosenberg wrote:

> Hi All
> I think I have found some inconsistencies in  the plplot rotated text
> text routines.
>
> I am trying to get the 3d text correct in the wxWidgets driver in x28.
> It dawned on my that the driver reports the size in device units as
> the maximum int in both directions - i.e. square. So I applied a
> correction to the rotation and shear to account for the actual aspect
> ration and suddenly all the 3d text looked perfect. Even better when
> the aspect ratio changed, the text also changed to match giving
> perfect resizable windows. I was very pleased.
>
> The I tested example 4 and found that the in plot text was no longer
> parallel with the line. I was less pleased.
>
> Tracing through c_plptex I realised that the device units per mm have
> been set bythe driver to reflect the actual aspect ratio. So xpmm is
> 156.1 and ypmm is 221.6.
>
> I therefore think that the 3d text and the standard rotated text are
> calculated in different unit spaces. One in mm which honours the
> aspect ratio and one in device units which assumes a square.
>
> I'm not sure what to do about this. Does anyone know any other drivers
> which report sizes in this way or am I being an idiot for trying to do
> this - (if I am then we should replace xpmm and ypmm with a single
> dupmm to stop it happening to anyone else). I actually rather like the
> fact that by telling plplot the page is square I can get the text to
> adjust to aspect ratio changes, but it will probably break the replot
> function if it uses a different driver that doesn't do this.
>
> I could try to make the 3d and standard rotated text consistent, but
> I'm not sure which is "right".
>
> Any suggestions would be very welcome right now before I start making
> decisions based on wxWidgets requirements.

It makes no sense that pixels per inch in each dimension is the same
(assuming you are using the default value of 90 for these data) yet
xpmm and ypmm are different.  That sounds like a fundamental bug to
me.  Of course, it is also possible that fundamental bug has been
papered over for many devices so fixing it might require a lot of
device fixing as well.  But a fundamental fix in this area might do
wonders for a number of coordinate-related bugs that are floating
around out there such as the problem with weird results for -ori x,
where x is not an integer; the fact that the octave "p" examples don't
work unless the device is square; and the difference in gradient
results at angles other than n*PI/2 between gradients from external
libraries and software fallback gradients.

So to me it sound like what we really need is clear documentation of
all the different coordinate systems used by PLplot and our devices
before we do anything else, and then a bug search for parts of PLplot
that do not follow that documentation.

Are you game for starting such documentation based on what you have
discovered in the past few days?  For now, simple ascii text
in drivers/README.coordinates would do, but eventually such
documentation should be part of our DocBook documentation.

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] Rotated text

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

 Hi All
Having looked at this a bit I think the 3d text routines ignore
whatever device units per mm have been set and must work in device
units only. Whereas standard rotated text honours the mm dimensions of
the device. It wouldn't surprise me if there was a good reason for
this, but I can't quite work it out.

To make the two compatible I have made the driver claim to be square
in both device units and mm and then the driver corrects for this in
its text render routine. It's a bit of a fudge, but it does the job.
In the future we should probably either make the two consistent or
remove the ability to set different device units per mm in the x and y
directions.

Alan - you'll be glad to know that this fixes three of the bugs on the
list regarding text rendering. So progress!

Phil


On 26 August 2015 at 11:02, Phil Rosenberg <p.d...@gm...> wrote:
> Hi All
> I think I have found some inconsistencies in  the plplot rotated text
> text routines.
>
> I am trying to get the 3d text correct in the wxWidgets driver in x28.
> It dawned on my that the driver reports the size in device units as
> the maximum int in both directions - i.e. square. So I applied a
> correction to the rotation and shear to account for the actual aspect
> ration and suddenly all the 3d text looked perfect. Even better when
> the aspect ratio changed, the text also changed to match giving
> perfect resizable windows. I was very pleased.
>
> The I tested example 4 and found that the in plot text was no longer
> parallel with the line. I was less pleased.
>
> Tracing through c_plptex I realised that the device units per mm have
> been set bythe driver to reflect the actual aspect ratio. So xpmm is
> 156.1 and ypmm is 221.6.
>
> I therefore think that the 3d text and the standard rotated text are
> calculated in different unit spaces. One in mm which honours the
> aspect ratio and one in device units which assumes a square.
>
> I'm not sure what to do about this. Does anyone know any other drivers
> which report sizes in this way or am I being an idiot for trying to do
> this - (if I am then we should replace xpmm and ypmm with a single
> dupmm to stop it happening to anyone else). I actually rather like the
> fact that by telling plplot the page is square I can get the text to
> adjust to aspect ratio changes, but it will probably break the replot
> function if it uses a different driver that doesn't do this.
>
> I could try to make the 3d and standard rotated text consistent, but
> I'm not sure which is "right".
>
> Any suggestions would be very welcome right now before I start making
> decisions based on wxWidgets requirements.
>
> Phil

[Plplot-devel] Rotated text

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

Hi All
I think I have found some inconsistencies in  the plplot rotated text
text routines.

I am trying to get the 3d text correct in the wxWidgets driver in x28.
It dawned on my that the driver reports the size in device units as
the maximum int in both directions - i.e. square. So I applied a
correction to the rotation and shear to account for the actual aspect
ration and suddenly all the 3d text looked perfect. Even better when
the aspect ratio changed, the text also changed to match giving
perfect resizable windows. I was very pleased.

The I tested example 4 and found that the in plot text was no longer
parallel with the line. I was less pleased.

Tracing through c_plptex I realised that the device units per mm have
been set bythe driver to reflect the actual aspect ratio. So xpmm is
156.1 and ypmm is 221.6.

I therefore think that the 3d text and the standard rotated text are
calculated in different unit spaces. One in mm which honours the
aspect ratio and one in device units which assumes a square.

I'm not sure what to do about this. Does anyone know any other drivers
which report sizes in this way or am I being an idiot for trying to do
this - (if I am then we should replace xpmm and ypmm with a single
dupmm to stop it happening to anyone else). I actually rather like the
fact that by telling plplot the page is square I can get the text to
adjust to aspect ratio changes, but it will probably break the replot
function if it uses a different driver that doesn't do this.

I could try to make the 3d and standard rotated text consistent, but
I'm not sure which is "right".

Any suggestions would be very welcome right now before I start making
decisions based on wxWidgets requirements.

Phil

Re: [Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

On 2015-08-25 11:10+0100 Phil Rosenberg wrote:

> Hi Alan
> It seems that this character is a BOM -
> https://en.wikipedia.org/wiki/Byte_order_mark. I think it is there so
> that if a system with different endianness tries to read the file it
> will see that character as FFFE instead of FEFF and knows to swap the
> byte order. However given that the file was (auto detected to be?)
> UTF8, I'm not sure why this was added. UTF8 has a different BOM which
> isn't really needed.
>
> There is a setting to turn the BOM off on my editor so I have done so
> and resaved the file. In git status -v I could see that the first line
> had changed, however the new and old lines looked Identical. I guess
> this is because my console is rendering the BOM as a utf16 character -
> it's representation being a zero width nonbreaking space.
>
> If you could confirm it is gone then that would be great.

Hi Phil (and others here who use Windows editors):

Now that you have identified that character as a BOM added by your
windows editor, I looked that up with google, and it appears that is a
character that is allowed but definitely not required by the UTF-8
standard. Since not all software recognizes such BOM characters for
best results it is good to remove BOM characters from UTF-8 files.

Also, from google searching I found a method (using the file command
on POSIX systems) to detect whether your editor had added a BOM to any
other file in our source tree:

Here is the overall check for that before fetching your change:

software@raven> pwd
/home/software/plplot/HEAD/plplot.git
software@raven> (find . -type f |grep -v .git |xargs file) |grep BOM
./doc/docbook/src/api.xml:    HTML document, UTF-8 Unicode (with BOM) text

So that file was the only one in our source tree that contained a BOM,
and after fetching your change here are the git diff results:

software@raven> git diff 246eea0..68c0256
diff --git a/doc/docbook/src/api.xml b/doc/docbook/src/api.xml
index 706aece..f31a0cc 100644
--- a/doc/docbook/src/api.xml
+++ b/doc/docbook/src/api.xml
@@ -1,4 +1,4 @@
-<U+FEFF><!-- -*-  mode: nxml -*- -->
+<!-- -*-  mode: nxml -*- -->
  <!--
      api.xml: "The Common API for PLplot" chapter

which confirms your commit removed that BOM.  I also retried the above
find command, and this time it reported (as expected) no BOM results.

Therefore, we now have a BOM-free source tree again.  Thanks for this
cleanup!

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] More on dpi, length default values

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

On 2015-08-25 08:15+0100 Phil Rosenberg wrote:

> Hi Alan
>
>> Instead of multiplying the MM values by 72/25.4 within drivers like
>> svg whose length units are pts, I intend instead to simply #define
>> PLPLOT_DEFAULT_PTPI, PLPLOT_DEFAULT_WIDTH_PT, and
>> PLPLOT_DEFAULT_HEIGHT_PT in plplotP.h and use those values in pt devices.
>
> Works for me, I have no strong feelings here.
>
>>
>> It is also becoming pretty clear to me that plsc->xdpi and plsc->ydpi
>> are misnomers since dots per inch normally would refer to pixels only.
>> Thus, I will probably change those to plsc->xupi and plsc->yupi where
>> "upi" stands for units per inch where units could be pixels, pts, mm,
>> or whatever length unit is appropriate to the device.
>
> In the documentation it says that dpi will only be used by raster
> drivers and drivers which use real world units will ignore the dpi
> measurements. I don't know if svg or ps or pdf drivers actually use
> the dpi value at all, but given that statement in the docs then
> leaving it as dpi or using ppi might be a better description.
> In the API these variables are called xp and yp, which are not very
> descriptive This is somewhere it might be worth making a change, where
> I would suggest changing them to dpi or ppi.

Hi Phil:

Actually, that remark about dpi being ignored by "real-world" drivers
is something you included in your recent changes to the plspage
documentation which was probably based on an earlier e-mail remark by
me.  I am not sure this is actually true at the moment for our
"real-world" drivers, but I certainly believe it is a worthwhile goal
for them since changing the number of mm per inch or pts per inch
should do very little other than to cause mass confusion.

At the same time, though, I see nothing wrong with real-world devices
calling plspage with the units per inch that they use so that
plsc->xupi and plsc->yupi will reflect that in case those values are
of some use to the user. Therefore, I am still leaning strongly toward
the above rename from dpi to upi.

Also, I plan to change

PLPLOT_DEFAULT_MMPI ==> PLPLOT_MMPI
PLPLOT_DEFAULT_PTPI ==> PLPLOT_PTPI

(i.e., drop DEFAULT from the name) since there is nothing "default"
about these values).  But I will retain the

PLPLOT_DEFAULT_PIXPI

name since that really is a default value that is only adopted if the
user does not select some other value.

Finally, I have to say that making all devices follow the same set of
rules for getting and setting upi and length values (with
well-established variations for each general kind of device length
unit) is long overdue, and we are still very early in the stages of
the whole process.  So our current ideas about what the rules should
be are mostly theoretical and will likely require revision as we gain
practical experience with this change for more and more of our
devices.

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] More on dpi, length default values

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

Hi Alan

> Instead of multiplying the MM values by 72/25.4 within drivers like
> svg whose length units are pts, I intend instead to simply #define
> PLPLOT_DEFAULT_PTPI, PLPLOT_DEFAULT_WIDTH_PT, and
> PLPLOT_DEFAULT_HEIGHT_PT in plplotP.h and use those values in pt devices.

Works for me, I have no strong feelings here.

>
> It is also becoming pretty clear to me that plsc->xdpi and plsc->ydpi
> are misnomers since dots per inch normally would refer to pixels only.
> Thus, I will probably change those to plsc->xupi and plsc->yupi where
> "upi" stands for units per inch where units could be pixels, pts, mm,
> or whatever length unit is appropriate to the device.

In the documentation it says that dpi will only be used by raster
drivers and drivers which use real world units will ignore the dpi
measurements. I don't know if svg or ps or pdf drivers actually use
the dpi value at all, but given that statement in the docs then
leaving it as dpi or using ppi might be a better description.
In the API these variables are called xp and yp, which are not very
descriptive This is somewhere it might be worth making a change, where
I would suggest changing them to dpi or ppi.

Phil

[Plplot-devel] More on dpi, length default values

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

To Jim and Phil:

This is just to help keep you guys informed about where I am headed with
regard to default "dpi" (probably that should be called "upi", see
below) and length values.

I am just about ready to tackle this topic for our svg device driver
today.  The length units for SVG files could be essentially anything,
but for our svg device we have chosen to use pts (where 1 pt = 1/72
inch), and that proves to be the length unit that is used for the
svgqt and svgcairo results as well.

Right now in plplotP.h we define

// Devices with real world units for sizes.
// Define constants with mm units which can be scaled to any real-world unit desired.
#define PLPLOT_DEFAULT_MMPI         25.4
//Use A4 (297mm x 210 mm) size as the default for drivers which use
"real world" page sizes
#define PLPLOT_DEFAULT_WIDTH_MM     297.
#define PLPLOT_DEFAULT_HEIGHT_MM    210.

// Devices with pixel units for sizes.
// Adopt this value as reasonable approximation for typical LCD
monitors.
#define PLPLOT_DEFAULT_PIXPI    90.
// These pixel dimensions correspond to A5 (210mm x 148mm) size if
actual pixels per inch was
// PLPLOT_DEFAULT_PIXPI.  That is,
// PLPLOT_DEFAULT_WIDTH_PIX ~ 210 * PLPLOT_DEFAULT_PIXPI/25.4
// PLPLOT_DEFAULT_HEIGHT_PIX ~ 148 * PLPLOT_DEFAULT_PIXPI/25.4
#define PLPLOT_DEFAULT_WIDTH_PIX     744
#define PLPLOT_DEFAULT_HEIGHT_PIX    524

Instead of multiplying the MM values by 72/25.4 within drivers like
svg whose length units are pts, I intend instead to simply #define
PLPLOT_DEFAULT_PTPI, PLPLOT_DEFAULT_WIDTH_PT, and
PLPLOT_DEFAULT_HEIGHT_PT in plplotP.h and use those values in pt devices.

It is also becoming pretty clear to me that plsc->xdpi and plsc->ydpi
are misnomers since dots per inch normally would refer to pixels only.
Thus, I will probably change those to plsc->xupi and plsc->yupi where
"upi" stands for units per inch where units could be pixels, pts, mm,
or whatever length unit is appropriate to the device.

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] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

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

On 2015-08-24 09:59-0000 Arjen Markus wrote:

> Hi Alan, Greg,
>
>
>
> Some more information - no solution though:
>
> -        Commenting out all calls to pplimage and plimagefr to avoid the "calls" to f2c (that is a macro, not a function) so that only plimagefr2 was left made no difference to the segmentation fault.
>
> -        Printing the allocated pointers in f2c revealed that the failure occurs at i = 122 for ygg, so in the middle of the procedure with no clue as to the cause.

Hi Arjen:

It sounds like you are trying to debug what happens in
bindings/octave/plplot_octaveOCTAVE_wrap.cxx.  Could you please send
that swig-generated file to me (without your edited changes) so I
could compare with what is generated by swig here?  I presume they
will be the same, but it would be good to double check that.

Since the error you have investigated at this detailed level seems to
occur right in the middle of an array, I think it would be worth your while to
try debugging at the higher (octave) level instead.  That is modify
examples/octave/x20c.m to

1. Find the exact octave command that is causing the issue, and
2. Dump out all arguments of that command including the detailed
contents of every vector and array into a file.
3. Send that file and your modified x20c.m here so I can
try the same experiment here to see if there are any differences.

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
__________________________