plplot-general — PLplot user discussion group

Re: [Plplot-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

On 2017-05-19 07:53+0200 Thomas Gläßle wrote:

>
> Alan W. Irwin wrote on 05/19/2017 03:11 AM:
>> Yet from your report no such "auto"-related targets seem to be
>> available for
>> the CMake version on MinGW-w64/MSYS2.
>>
>> Just to confirm that conclusion, what are your results for
>>
>> make help |grep -i auto
>>
>> executed in the top directory of your build tree?
>
> Empty results.
>
> When grepping the whole directory there are matches, some of them
> autogen related. See attached `grep_auto.out` file.

Hi Thomas:

Thanks for this report.  Figuring this out is going to be fairly time
consuming so I don't ask that of you and instead the following notes
are for a PLplot developer with access to MinGW-w64/MSYS2 that might
want to take on this issue.

@Developers:

I had an extremely quick look at the grep_auto.out results, and it
does appear the Makefiles generated by CMake do have many of the
correct rules in place for moc to generate the required source code.
So the CMake bug appears to be that some key component of those rules
is missing on this platform, but figuring out exactly what is wrong
(say by doing detailed comparisons between the equivalent Linux and
MinGW-w64/MSYS2 results) is going to take a lot of work.  To simplify
that work, you should do such a comparison only for the simplest
possible test project example.  Right now we do have a fairly simple
test project implemented at cmake/test_automoc/CMakeLists.txt, but
that project was implemented to compare various ways of using moc with
CMake so it needs to be simplified even more ( i.e., to reduce it to
just one example of automoc at work following the style that I finally
adopted in bindings/qt_gui/CMakeLists.txt).

> I had a few bugs with gcc and other tools on this platform, so this
> could be a possibility..
> On the other hand I could (and still can) successfully build plplot
> 5.9.9 - meaning that I can successfully make this version of plplot and
> also link another program with the generated libraries. (Sorry, I
> realize I should have pointed this out earlier.. but somehow I forgot).

@Thomas:

Yes, using the CMake automoc capability (that apparently is failing
for you on the MinGW-w64/MSYS2 platform but which works fine on the
Linux platform) was implemented first for 5.12.0.  Before that we used
a brute force technique to generate the moc files which had problems
of its own that were solved by using the CMake capability.  So I would
far prefer to continue to use the CMake capability but find out what
is wrong with it just for MinGW-w64/MSYS2.

> I'm already on cmake 3.8.1 in the msys.

Yes, but presumably that is a patched version, and it would be
interesting to see if an unpatched version (that you built yourself)
did not have this issue.  In other words, such an experiment would be
part of finding out what is the source of this issue which (1) could be
some problem with the patches applied by the MinGW-w64/MSYS2 packagers
or (2) could be some problem with unpatched CMake automoc capability on
this platform that the CMake developers did not anticipate.

I got your later e-mail that it would be a while before you could try
this experiment, but that is fine since our own developer will likely
be trying this experiment instead.

Anyhow, you sure found an "interesting" problem.... :-)

>
>> Another
>> possibility is to try Qt5 instead.  You do that by (1) installing the
>> Qt5 development libraries and (2) convince our build system (which
>> prefers Qt4 by default) to use those libraries by using the
>> -DPLPLOT_USE_QT5=ON cmake option.
>
> I will have to check up on that. However, I will be away for one week
> with no access to my windows desktop - so expect nothing in the next few
> days. (I have the whole build tree with me if you need more info).

I think that is an extreme long shot that the Qt development packages
might be at fault rather than CMake itself so let us just forget that
possibility for now.

>
>> A final possibility is to give up on
>> our qt devices altogether on this platform (at least for now) by
>> disabling all of them (using the cmake option
>> -DDEFAULT_NO_QT_DEVICES=ON).
>
> Which devices can you suggest instead? I used Qt because it was the
> first one I got working on the older plplot.

Given the automoc trouble with qt on this platform, I would recommend
the cairo device driver which implements both noninteractive and
interactive devices that typically are of the same high quality as the
equivalent qt devices.  One issue is there will be a lot to install
starting with pkg-config.  But keep following up any WARNINGs
in cmake.out corresponding to "cairo" or "pango"
in cmake.out by installing the relevant MinGW-64/MSYS2 packages
and you should be OK.  Note that cairo and pango are a subset of
GTK+, so see the name of the relevant GTK+ package you
should install in
<https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/>.
Furthermore, if you spot any issues with that list of package
names, please let me know so we can fix it.

An additional potential "cairo" issue on this platform is the
interactive xcairo device will not work because there is no X on this
platform.  We have implemented an interactive device called wincairo
which is a replacement for xcairo that is designed to work on Windows.
So ideally that device will provide you interactive capability.
However, I should warn you that device is not well tested yet so we
would all be most interested in how well it works for you.

> Installed a few of packages and silenced many of the WARNINGs, however
> still the same error occurs.

As expected since the two issues are unlikely to be related.

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

Hi Thomas, Alan,



For what it is worth, yesterday I had success building the Qt4 device on MinGW-w64/MSYS2 using the "native" version of CMake (that reports the version as 3.6.2). I have attached the combined CMake/make output.



Regards,

Arjen



> -----Original Message-----
> From: Thomas Gläßle [mailto:t_g...@gm...]
> Sent: Friday, May 19, 2017 7:54 AM
> To: Alan W. Irwin
> Cc: plp...@li...
> Subject: Re: [Plplot-general] [msys2, qt] no rule to make target
> moc_compilation.cpp
>
>
> Alan W. Irwin wrote on 05/19/2017 03:11 AM:
> > Yet from your report no such "auto"-related targets seem to be
> > available for the CMake version on MinGW-w64/MSYS2.
> >
> > Just to confirm that conclusion, what are your results for
> >
> > make help |grep -i auto
> >
> > executed in the top directory of your build tree?
>
> Empty results.
>
> When grepping the whole directory there are matches, some of them autogen
> related. See attached `grep_auto.out` file.
>
>
> > If your results are empty there, then my best guess is you are a
> > victim of some bug in the MinGW-w64/MSYS2 version of CMake-3.8.1 or
> > Qt4.  But that guess does need to be investigated further by one of
> > our developers, and if that guess is confirmed, they will need to
> > prepare a bug report for the developers of that platform, and those
> > developers will have to respond.
>
> I had a few bugs with gcc and other tools on this platform, so this could be a
> possibility..
> On the other hand I could (and still can) successfully build plplot
> 5.9.9 - meaning that I can successfully make this version of plplot and also link
> another program with the generated libraries. (Sorry, I realize I should have pointed
> this out earlier.. but somehow I forgot).
>
> > So I am pretty sure this issue is going to take a long time to
> > resolve.  One workaround might be to build cmake-3.8.1 yourself (from
> > unpatched Kitware source) on MinGW-w64/MSYS2 to see if that version
> > does any better than the current version that you are using that has
> > been packaged (presumably with patches) for the platform.
>
> I'm already on cmake 3.8.1 in the msys.
>
> > Another
> > possibility is to try Qt5 instead.  You do that by (1) installing the
> > Qt5 development libraries and (2) convince our build system (which
> > prefers Qt4 by default) to use those libraries by using the
> > -DPLPLOT_USE_QT5=ON cmake option.
>
> I will have to check up on that. However, I will be away for one week with no access
> to my windows desktop - so expect nothing in the next few days. (I have the whole
> build tree with me if you need more info).
>
> > A final possibility is to give up on
> > our qt devices altogether on this platform (at least for now) by
> > disabling all of them (using the cmake option
> > -DDEFAULT_NO_QT_DEVICES=ON).
>
> Which devices can you suggest instead? I used Qt because it was the first one I
> got working on the older plplot.
>
> > Finally, to introduce a different but related topic, there are lots of
> > warning messages in your current cmake.out file concerning missing
> > executables (e.g., swig and pkg-config) or libraries (e.g., shapelib).
> > None of these warnings seem relevant to the above issue. Nevertheless,
> > as a result of such issues, our build system adjusts by dropping many
> > components of PLplot.  Many of these warnings are easy to address by
> > installing the relevant MinGW-w64/MSYS2 package, and I strongly
> > encourage you to do that since the result will be a much more complete
> > and powerful PLplot similar to what Greg Jung was able to successfully
> > test a while ago.
>
> Installed a few of packages and silenced many of the WARNINGs, however still the
> same error occurs.
>
>
> Best, Thomas

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

> Alan W. Irwin wrote on 05/19/2017 03:11 AM:
>> So I am pretty sure this issue is going to take a long time to
>> resolve.  One workaround might be to build cmake-3.8.1 yourself (from
>> unpatched Kitware source) on MinGW-w64/MSYS2 to see if that version
>> does any better than the current version that you are using that has
>> been packaged (presumably with patches) for the platform. 
> I'm already on cmake 3.8.1 in the msys.

(I can try building the unpatched version in about a week.)

Re: [Plplot-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

Alan W. Irwin wrote on 05/19/2017 03:11 AM:
> Yet from your report no such "auto"-related targets seem to be
> available for
> the CMake version on MinGW-w64/MSYS2.
>
> Just to confirm that conclusion, what are your results for
>
> make help |grep -i auto
>
> executed in the top directory of your build tree?

Empty results.

When grepping the whole directory there are matches, some of them
autogen related. See attached `grep_auto.out` file.


> If your results are empty there, then my best guess is you are a
> victim of some bug in the MinGW-w64/MSYS2 version of CMake-3.8.1 or
> Qt4.  But that guess does need to be investigated further by one of
> our developers, and if that guess is confirmed, they will need to
> prepare a bug report for the developers of that platform, and those
> developers will have to respond.

I had a few bugs with gcc and other tools on this platform, so this
could be a possibility..
On the other hand I could (and still can) successfully build plplot
5.9.9 - meaning that I can successfully make this version of plplot and
also link another program with the generated libraries. (Sorry, I
realize I should have pointed this out earlier.. but somehow I forgot).

> So I am pretty sure this issue is going to take a long time to
> resolve.  One workaround might be to build cmake-3.8.1 yourself (from
> unpatched Kitware source) on MinGW-w64/MSYS2 to see if that version
> does any better than the current version that you are using that has
> been packaged (presumably with patches) for the platform. 

I'm already on cmake 3.8.1 in the msys.

> Another
> possibility is to try Qt5 instead.  You do that by (1) installing the
> Qt5 development libraries and (2) convince our build system (which
> prefers Qt4 by default) to use those libraries by using the
> -DPLPLOT_USE_QT5=ON cmake option.

I will have to check up on that. However, I will be away for one week
with no access to my windows desktop - so expect nothing in the next few
days. (I have the whole build tree with me if you need more info).

> A final possibility is to give up on
> our qt devices altogether on this platform (at least for now) by
> disabling all of them (using the cmake option
> -DDEFAULT_NO_QT_DEVICES=ON).

Which devices can you suggest instead? I used Qt because it was the
first one I got working on the older plplot.

> Finally, to introduce a different but related topic, there are lots of
> warning messages in your current cmake.out file concerning missing
> executables (e.g., swig and pkg-config) or libraries (e.g., shapelib).
> None of these warnings seem relevant to the above issue. Nevertheless,
> as a result of such issues, our build system adjusts by
> dropping many components of PLplot.  Many of these warnings are easy
> to address by installing the relevant MinGW-w64/MSYS2 package, and I
> strongly encourage you to do that since the result will be a much more
> complete and powerful PLplot similar to what Greg Jung was able to
> successfully test a while ago.

Installed a few of packages and silenced many of the WARNINGs, however
still the same error occurs.


Best, Thomas

Re: [Plplot-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

On 2017-05-18 23:27+0200 Thomas Gläßle wrote:

> Hi Alan,
>
> thanks for your help. Unfortunately, still the same problem. In short:
>
> `make plplotqt_autogen` complains that there is no rule to make the
> target.(I'm assuming you meant plplotqt_autogen, at least that's the one
> that creates moc_compilation.cpp on my linux)

I confirm for CMake-3.8.1, the automoc-related target is called
plplotqt_autogen.  For CMake-3.7.2 it is called plplotqt_automoc
which is the source of confusion about this.

But regardless of which CMake version I use or whether I use
plplot-5.12.0 or the latest git master branch version of
PLplot, in all cases on the Linux platform the "auto"-related
target is always automatically built to generate the required
moc code before the plplotqt target is built.

Yet from your report no such "auto"-related targets seem to be available for
the CMake version on MinGW-w64/MSYS2.

Just to confirm that conclusion, what are your results for

make help |grep -i auto

executed in the top directory of your build tree?

For CMake-3.8.1 on Linux the results of that test are

software@raven> make help |grep -i auto
... plplotqt_autogen
... qt_example_autogen

If your results are empty there, then my best guess is you are a
victim of some bug in the MinGW-w64/MSYS2 version of CMake-3.8.1 or
Qt4.  But that guess does need to be investigated further by one of
our developers, and if that guess is confirmed, they will need to
prepare a bug report for the developers of that platform, and those
developers will have to respond.

So I am pretty sure this issue is going to take a long time to
resolve.  One workaround might be to build cmake-3.8.1 yourself (from
unpatched Kitware source) on MinGW-w64/MSYS2 to see if that version
does any better than the current version that you are using that has
been packaged (presumably with patches) for the platform.  Another
possibility is to try Qt5 instead.  You do that by (1) installing the
Qt5 development libraries and (2) convince our build system (which
prefers Qt4 by default) to use those libraries by using the
-DPLPLOT_USE_QT5=ON cmake option. A final possibility is to give up on
our qt devices altogether on this platform (at least for now) by
disabling all of them (using the cmake option
-DDEFAULT_NO_QT_DEVICES=ON).

Finally, to introduce a different but related topic, there are lots of
warning messages in your current cmake.out file concerning missing
executables (e.g., swig and pkg-config) or libraries (e.g., shapelib).
None of these warnings seem relevant to the above issue. 
Nevertheless, as a result of such issues, our build system adjusts by
dropping many components of PLplot.  Many of these warnings are easy
to address by installing the relevant MinGW-w64/MSYS2 package, and I
strongly encourage you to do that since the result will be a much more
complete and powerful PLplot similar to what Greg Jung was able to
successfully test a while ago.

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

Hi Alan,

thanks for your help. Unfortunately, still the same problem. In short:

`make plplotqt_autogen` complains that there is no rule to make the
target.(I'm assuming you meant plplotqt_autogen, at least that's the one
that creates moc_compilation.cpp on my linux)

The log files are attached. The terminal session is as follows

    thomas@valhalla MINGW64 /c/Users/thomas/Downloads/plplot-5.12.0
    $ rm -rf build && mkdir build && cd build
    $ cmake .. -G 'MSYS Makefiles' -DCMAKE_VERBOSE_MAKEFILE=ON >& cmake.out
    $ make VERBOSE=1 >& make.out
    $ make VERBOSE=1 plplotqt_automoc >& plplotqt_automoc.out
    $ make VERBOSE=1 plplotqt_autogen >& plplotqt_autogen.out
    $ make VERBOSE=1 plplotqt >& plplotqt.out

Same errors when using `Unix Makefiles`.

Best, Thomas


PS:

+ freshly extracted plplot 5.12.0
+ newly installed + upgraded MSYS2 x86_64
+ mingw-w64-x86_64-{cmake,qt4,base-devel,gcc,gcc-fortran}


Alan W. Irwin wrote on 05/18/2017 10:45 PM:
> On 2017-05-18 08:41+0200 Thomas Gläßle wrote:
>
>> Hi Alan,
>>
>> thanks for your response.
>>
>> Unfortunately, the default configuration fails with the same error (see
>> attached files).
>
> Hi Thomas:
>
> Thanks for your bug report with all the useful file results to help me
> diagnose the issue.  I don't see any obvious Qt-related issues
> with your cmake.out result, and it appears to me from your make.out
> file there is some Qt issue with dependencies in the automoc generated
> files. But that is a puzzling result since there is no such issue on
> the Linux platform.
>
> For example, I just did the following test on that platform starting
> from a freshly configured (with CMake-3.8.1 to match your result as
> closely as possible) build tree.
>
> software@raven> make VERBOSE=1 plplotqt >& plplotqt.out
> software@raven> grep Built plplotqt.out
> [  0%] Built target plplotqt_automoc
> [ 12%] Built target plhershey-unicode-gen
> [ 12%] Built target plhershey-unicode.h_built
> [ 12%] Built target csirocsa
> [ 25%] Built target csironn
> [ 25%] Built target deltaT-gen
> [ 37%] Built target deltaT.h_built
> [ 37%] Built target tai-utc-gen
> [ 37%] Built target tai-utc.h_built
> [ 50%] Built target qsastime
> [100%] Built target plplot
> [100%] Built target plplotqt
>
> Notice that the plplotqt_automoc target is automatically built before
> the plplotqt
> target, but there is no sign of that happening in your own make.out
> file.
>
> Just to confirm that conclusion, would you follow the
> above test there starting from a freshly configured build tree?
> And if you confirm that plplotqt_automoc is not built in your case
> (which should lead to the same error you found before), could
> you try imposing the build of the plplotqt_automoc target beforehand,
> i.e.,
>
> make VERBOSE=1 plplotqt_automoc >& plplotqt_automoc
>
> before
>
> make VERBOSE=1 plplotqt >& plplotqt.out
>
> to see if that works around that dependency issue?
>
> Of course, it is difficult to debug such issues at second hand from a
> different platform so I am hoping PLplot developers here with access
> to the platform will try the above test for themselves to (a) confirm
> the issue, and (b) dig deeper into why it exists just on that
> platform.
>
> 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-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

On 2017-05-18 08:41+0200 Thomas Gläßle wrote:

> Hi Alan,
>
> thanks for your response.
>
> Unfortunately, the default configuration fails with the same error (see
> attached files).

Hi Thomas:

Thanks for your bug report with all the useful file results to help me
diagnose the issue.  I don't see any obvious Qt-related issues
with your cmake.out result, and it appears to me from your make.out
file there is some Qt issue with dependencies in the automoc generated
files. But that is a puzzling result since there is no such issue on
the Linux platform.

For example, I just did the following test on that platform starting
from a freshly configured (with CMake-3.8.1 to match your result as
closely as possible) build tree.

software@raven> make VERBOSE=1 plplotqt >& plplotqt.out
software@raven> grep Built plplotqt.out
[  0%] Built target plplotqt_automoc
[ 12%] Built target plhershey-unicode-gen
[ 12%] Built target plhershey-unicode.h_built
[ 12%] Built target csirocsa
[ 25%] Built target csironn
[ 25%] Built target deltaT-gen
[ 37%] Built target deltaT.h_built
[ 37%] Built target tai-utc-gen
[ 37%] Built target tai-utc.h_built
[ 50%] Built target qsastime
[100%] Built target plplot
[100%] Built target plplotqt

Notice that the plplotqt_automoc target is automatically built before the plplotqt
target, but there is no sign of that happening in your own make.out
file.

Just to confirm that conclusion, would you follow the
above test there starting from a freshly configured build tree?
And if you confirm that plplotqt_automoc is not built in your case
(which should lead to the same error you found before), could
you try imposing the build of the plplotqt_automoc target beforehand,
i.e.,

make VERBOSE=1 plplotqt_automoc >& plplotqt_automoc

before

make VERBOSE=1 plplotqt >& plplotqt.out

to see if that works around that dependency issue?

Of course, it is difficult to debug such issues at second hand from a
different platform so I am hoping PLplot developers here with access
to the platform will try the above test for themselves to (a) confirm
the issue, and (b) dig deeper into why it exists just on that
platform.

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

Hi Alan,

thanks for your response.

Unfortunately, the default configuration fails with the same error (see
attached files).

Sorry, that I was unclear about this: When I saw failure in the defaults
I started dropping devices to single out the one that seemed to cause
the issue. It could still be that I'm missing something that needs to be
installed before I can use it, but I'm not sure what.

I can give you the output files and tests when just disabling Qt later
(I don't have access to a windows throughout the day).

Best, Thomas

Alan W. Irwin wrote on 05/18/2017 06:04 AM:
> On 2017-05-18 01:00+0200 Thomas Gläßle wrote:
>
>> Dear plplot community/devs,
>>
>>
>> I'm trying to build plplot with the qt driver on msys2. From a freshly
>> unpacked plplot-5.12.0 folder, I run the following commands in the msys2
>> mingw64 shell:
>>
>>    pacman -S mingw-w64-x86_64-qt4
>>
>>    mkdir build && cd build
>>
>>    cmake .. -G 'MSYS Makefiles' -DDEFAULT_NO_BINDINGS=ON
>> -DDEFAULT_NO_DEVICES=ON -DENABLE_qt=ON -DPLD_qtwidget=ON >& cmake.out
>
> Hi Thomas:
>
> There is obviously a very large number of different combinations of
> CMake options that are possible to use with our build system, and
> because of that "combinatorial" issue, lots of those combinations
> (such as what you chose above) are completely untested, and thus may
> have issues.  For example, the above combination disables C++, but our
> qt device driver is written in that language so I am not sure our
> build system can handle that combination.  Therefore, as a first step
> I advise you to drop all specific options and instead just choose the
> default options (the particular combination of options which are best
> tested). You do that (again starting with an empty build tree as you
> did above) by simply running
>
> cmake .. -G 'MSYS Makefiles' >& cmake.out
>
> If the resulting cmake.out shows any showstopping errors, then disable
> the relevant components, but do not disable working components such as
> C++ (at least in your early PLplot testing on this platform).
>
> To expound a broader view for all Windows users here, I believe the
> MinGW-w64/MSYS2 platform is potentially our most important Windows
> platform because it gives access to so many useful free software
> libraries in native Windows form that are all ABI compatible and which
> also add a lot of power (such as the number of different qt devices)
> to PLplot.  And some time ago one of our users (Greg Jung) did have
> fairly complete success with this platform (including our qt device
> driver). So I welcome all user interest in this platform, and I have
> also long been encouraging our developers with access to Windows to
> test PLplot on this platform for themselves (even though I
> don't have access to Windows myself).
>
> The current status is some limited testing (i.e., excluding qt) has
> been done on that platform by at least one of our developers but none
> of our developers has yet attempted the near-complete testing done by
> Greg.  However, from recent discussions, I have hopes that "largely
> untested by developers" status will change soon for this platform
> so that we can unreservedly recommend it to our Windows users.
>
> 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-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

On 2017-05-18 01:43+0200 Thomas Gläßle wrote:

> Yes, with the following flags, plplot builds successfully:
>
>    cmake .. -G 'MSYS Makefiles' -DENABLE_qt=OFF
>    make

Hi Thomas:

That is encouraging news you reported to Jim.  What happens if you
drop that last option, i.e., use default options for all bindings and
device drivers (as I just recommended in my previous post)?

I would also advise specifying the -DBUILD_TEST=ON option (to allow
you to run-time test your results in the build tree).

Then afterward run some overall run-time test targets such as

make test_c_qtwidget

(which tests that particular interactive qt device for a subset of our C examples)

make test_c_svgqt

(which tests that particular noninteractive qt device for all our C
examples)

and

make test_noninteractive

(which tests all bindings for all our 33 standard examples written in
each of our supported languages for the psc device, and which also
tests our C examples for _all_ our noninteractive devices).

N.B. all the above test targets should be convenient to use because
our build system is implemented in such a way that all prerequisites
(such as libplplot) should be automatically built before any of such
test targets.

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

On 2017-05-18 01:00+0200 Thomas Gläßle wrote:

> Dear plplot community/devs,
>
>
> I'm trying to build plplot with the qt driver on msys2. From a freshly
> unpacked plplot-5.12.0 folder, I run the following commands in the msys2
> mingw64 shell:
>
>    pacman -S mingw-w64-x86_64-qt4
>
>    mkdir build && cd build
>
>    cmake .. -G 'MSYS Makefiles' -DDEFAULT_NO_BINDINGS=ON
> -DDEFAULT_NO_DEVICES=ON -DENABLE_qt=ON -DPLD_qtwidget=ON >& cmake.out

Hi Thomas:

There is obviously a very large number of different combinations of
CMake options that are possible to use with our build system, and
because of that "combinatorial" issue, lots of those combinations
(such as what you chose above) are completely untested, and thus may
have issues.  For example, the above combination disables C++, but our
qt device driver is written in that language so I am not sure our
build system can handle that combination.  Therefore, as a first step
I advise you to drop all specific options and instead just choose the
default options (the particular combination of options which are best
tested). You do that (again starting with an empty build tree as you
did above) by simply running

cmake .. -G 'MSYS Makefiles' >& cmake.out

If the resulting cmake.out shows any showstopping errors, then disable
the relevant components, but do not disable working components such as
C++ (at least in your early PLplot testing on this platform).

To expound a broader view for all Windows users here, I believe the
MinGW-w64/MSYS2 platform is potentially our most important Windows
platform because it gives access to so many useful free software
libraries in native Windows form that are all ABI compatible and which
also add a lot of power (such as the number of different qt devices)
to PLplot.  And some time ago one of our users (Greg Jung) did have
fairly complete success with this platform (including our qt device
driver). So I welcome all user interest in this platform, and I have
also long been encouraging our developers with access to Windows to
test PLplot on this platform for themselves (even though I
don't have access to Windows myself).

The current status is some limited testing (i.e., excluding qt) has
been done on that platform by at least one of our developers but none
of our developers has yet attempted the near-complete testing done by
Greg.  However, from recent discussions, I have hopes that "largely
untested by developers" status will change soon for this platform
so that we can unreservedly recommend it to our Windows users.

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-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

Yes, with the following flags, plplot builds successfully:

    cmake .. -G 'MSYS Makefiles' -DENABLE_qt=OFF
    make



Jim Dishaw wrote on 05/18/2017 01:31 AM:
> Are you able to build plplot with just the default drivers (no QT)?
>
>> On May 17, 2017, at 6:00 PM, Thomas Gläßle <t_g...@gm...> wrote:
>>
>> Dear plplot community/devs,
>>
>>
>> I'm trying to build plplot with the qt driver on msys2. From a freshly
>> unpacked plplot-5.12.0 folder, I run the following commands in the msys2
>> mingw64 shell:
>>
>>    pacman -S mingw-w64-x86_64-qt4
>>
>>    mkdir build && cd build
>>
>>    cmake .. -G 'MSYS Makefiles' -DDEFAULT_NO_BINDINGS=ON
>> -DDEFAULT_NO_DEVICES=ON -DENABLE_qt=ON -DPLD_qtwidget=ON >& cmake.out
>>
>>    make VERBOSE=1 >& make.out
>>
>>    printenv >& printenv.out
>>
>> The `make` step errors and complains about
>>
>>    make[2]: *** No rule to make target
>> 'bindings/qt_gui/plplotqt_autogen/moc_compilation.cpp', needed by
>> 'bindings/qt_gui/CMakeFiles/plplotqt.dir/plplotqt_autogen/moc_compilation.cpp.obj'. 
>> Stop.
>>
>>
>> Same error occurs when using `-G 'Unix Makefiles'`.
>>
>> Any ideas what I might be doing wrong?
>>
>>
>> Best regards, and thanks for your time,
>> Thomas
>> <cmake.out>
>> <CMakeCache.txt>
>> <cmake_install.cmake>
>> <make.out>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-general mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

Re: [Plplot-general] [msys2, qt] no rule to make target moc_compilation.cpp

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

Are you able to build plplot with just the default drivers (no QT)?

> On May 17, 2017, at 6:00 PM, Thomas Gläßle <t_g...@gm...> wrote:
> 
> Dear plplot community/devs,
> 
> 
> I'm trying to build plplot with the qt driver on msys2. From a freshly
> unpacked plplot-5.12.0 folder, I run the following commands in the msys2
> mingw64 shell:
> 
>    pacman -S mingw-w64-x86_64-qt4
> 
>    mkdir build && cd build
> 
>    cmake .. -G 'MSYS Makefiles' -DDEFAULT_NO_BINDINGS=ON
> -DDEFAULT_NO_DEVICES=ON -DENABLE_qt=ON -DPLD_qtwidget=ON >& cmake.out
> 
>    make VERBOSE=1 >& make.out
> 
>    printenv >& printenv.out
> 
> The `make` step errors and complains about
> 
>    make[2]: *** No rule to make target
> 'bindings/qt_gui/plplotqt_autogen/moc_compilation.cpp', needed by
> 'bindings/qt_gui/CMakeFiles/plplotqt.dir/plplotqt_autogen/moc_compilation.cpp.obj'. 
> Stop.
> 
> 
> Same error occurs when using `-G 'Unix Makefiles'`.
> 
> Any ideas what I might be doing wrong?
> 
> 
> Best regards, and thanks for your time,
> Thomas
> <cmake.out>
> <CMakeCache.txt>
> <cmake_install.cmake>
> <make.out>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] [msys2, qt] no rule to make target moc_compilation.cpp

[Thomas G. <t_g...@gm...>]

Dear plplot community/devs,


I'm trying to build plplot with the qt driver on msys2. From a freshly
unpacked plplot-5.12.0 folder, I run the following commands in the msys2
mingw64 shell:

    pacman -S mingw-w64-x86_64-qt4

    mkdir build && cd build

    cmake .. -G 'MSYS Makefiles' -DDEFAULT_NO_BINDINGS=ON
-DDEFAULT_NO_DEVICES=ON -DENABLE_qt=ON -DPLD_qtwidget=ON >& cmake.out

    make VERBOSE=1 >& make.out

    printenv >& printenv.out

The `make` step errors and complains about

    make[2]: *** No rule to make target
'bindings/qt_gui/plplotqt_autogen/moc_compilation.cpp', needed by
'bindings/qt_gui/CMakeFiles/plplotqt.dir/plplotqt_autogen/moc_compilation.cpp.obj'. 
Stop.


Same error occurs when using `-G 'Unix Makefiles'`.

Any ideas what I might be doing wrong?


Best regards, and thanks for your time,
Thomas

[Plplot-general] Install PlPlot 5.12.0

[Barbieri L. (RSE) <Luc...@rs...>]

Dear PlPlot developers,
                I'm a new user of your library. I write you because I have some trouble to install it.
I have tried different configuration and a try to follow the instruction without success.
The problem arise always when I try to compile the library with the inclusion of wxWidgets.
Until now I try with the last stable version of wxWidgets (3.0.3) and the development version (3.1.0).
The platform Is Win 7 64 bit version. The compiler is TDM-GCC (GCC version 5.1) 32 bit version ( I tried also the 64 bit version).
CMake version 3.7.1 (and 3.8.1) both 32 a 64 bit version.

The wxWidgets are compiled with MONOLITHIC=0 SHARED=1 UNICODE=1 BUILD=debug/release without a problem.

The CMAKE configuration output is attached. Substantially I have used the default configuration and I have changed only the destination path.

I chose to use as Output MinGW Makefiles.

When I try to compile with make command I have some warning and an error.

The only manner to built successfully is to exclude the wxWidgets platform or alternatively check OLD_WXWIDGETS flags in CMake configuration.

In this case when I try to include the deprecated library I have many trouble in my wxWidgets application. (I can't insert wxPLPlot in my main frame even copy the demo project that is located inside the PLPlot packages)



Can you give me any hint?



Thanks in advance.



Best regards,

     Luca Barbieri




[RSE_logo]

Luca Barbieri
RSE S.p.A. - Ricerca sul Sistema Energetico
Via R. Rubattino 54
Milano
telefono +39 02 3992.5279
fax +39 02 3992 5557
e-mail luc...@rs...<mailto:luc...@rs...>




RSE SpA ha adottato il Modello Organizzativo ai sensi del D.Lgs.231/2001, in forza del quale l'assunzione di obbligazioni da parte della Società avviene con firma di un procuratore, munito di idonei poteri.
RSE adopts a Compliance Programme under the Italian Law (D.Lgs.231/2001). According to this RSE Compliance Programme, any commitment of RSE is taken by the signature of one Representative granted by a proper Power of Attorney. Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne e' vietata la diffusione in qualsiasi modo o forma. Qualora Lei non fosse la persona destinataria del presente messaggio, La invitiamo a non diffonderlo e ad eliminarlo, dandone gentilmente comunicazione al mittente. The information included in this e-mail and any attachments are confidential and may also be privileged. If you are not the correct recipient, you are kindly requested to notify the sender immediately, to cancel it and not to disclose the contents to any other person.

[Plplot-general] [ANNOUNCEMENT] The minumum version of CMake we accept on Linux is now bumped from 3.0.2 to 3.6.2

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

I prefer to support only recent CMake versions and latest CMake
policies to keep the PLplot build system as simple and as bug free as
possible.  For this reason I have recently bumped (see
<https://sourceforge.net/p/plplot/plplot/ci/f0610cdf5879ce2d7727f8d865d4523ebc501c78/>)
the minimum version of CMake we accept on Linux to 3.6.2, and and we may 
similarly
bump that version and also the minimum version we accept on non-Linux
platforms to 3.7.2 later on this year.

This current bump will only affect Linux users of our current git
version (and also our next release) on the relatively small number of
Linux distributions that do not yet provide CMake-3.6.2 or later.  So
the number of affected users should be relatively small and decreasing
because Linux distributions generally do a good job of keeping up with
the latest CMake versions.  However, if you are one of these users
that is temporarily affected by this issue, you will have to build the
latest CMake (currently 3.8.0 which builds PLplot without
difficulties) before building the git version of PLplot.  So the
purpose of this announcement is to warn users about this uncommon
possibility.

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-general] log plot and labels

[Andrzej S. <sty...@o2...>]

> Try the plaxes() call (see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/plaxes.html) to get the tick marks that you want.  I would try to fix your code, but I don’t have a build
> environment setup with the new Fortran bindings—sorry.

Hello, I was trying this but I do not understand how it works.

Would you write any small example with my data as example? The RMS error in 'rms' variable was put.  
It not must be done with new fortran. It can be in an old, I change then to my needs. 

I was trying with these below, but nothing changed on generated plot:
call plaxes(0d0, 0d0, "lbcnst", 0d0, 0, "lbcnstv", 0.01d0, 10)
call plaxes(0d0, 0d0, "lbcnst", 0d0, 0, "lbcnstv", 0.0001d0, 1000)
call plaxes(0d0, 0d0, "lbcnst", 0d0, 0, "lbcnstv", 10.0d0, 1000)
call plaxes(0d0, 0d0, "lbcnst", 0d0, 0, "lbcnstv", 10000.0d0, 3)

I do not understand these parameters:
ytick (PLFLT, input)
    World coordinate interval between major ticks on the y axis. If it is set to zero, 
    PLplot automatically generates a suitable tick interval. 
nysub (PLINT, input)
    Number of subintervals between major y axis ticks for minor ticks. If it is set to zero, 
    PLplot automatically generates a suitable minor tick interval. 

Would you like or someone on the list explain by very, very simple example how these parameters works, i.e. 
how I can calculate it? For example I need 5 major ticks on the y axis as in the file "test_matlab.pdf".

In general it not must be in log scale, simply how these should be calculated to get for example "n" major 
ticks on given axis?

Thank you in advance.

Re: [Plplot-general] log plot and labels

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

> On Apr 10, 2017, at 4:07 PM, Andrzej Styczen <sty...@o2...> wrote:
> 
> Hello,
> 
> I wanted to ask you for help. I prepare a test program to plot in log scale.
> I also prepare such plot in Matlab, where on the left side I put label in more 
> detail than in PLplot test program. Is there any possibility to make such plot 
> in PLplot as in Matlab, i.e. making more labels on axis Y in log plot?
> 
> Have look on file "plplot_test.pdf" and "matlab_test.pdf" and my source code.
> 
> For any suggestions or corrections in my program I will be grateful.
> 

Try the plaxes() call (see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/plaxes.html) to get the tick marks that you want.  I would try to fix your code, but I don’t have a build environment setup with the new Fortran bindings—sorry.

[Plplot-general] log plot and labels

[Andrzej S. <sty...@o2...>]

Hello,

I wanted to ask you for help. I prepare a test program to plot in log scale.
I also prepare such plot in Matlab, where on the left side I put label in more 
detail than in PLplot test program. Is there any possibility to make such plot 
in PLplot as in Matlab, i.e. making more labels on axis Y in log plot?

Have look on file "plplot_test.pdf" and "matlab_test.pdf" and my source code.

For any suggestions or corrections in my program I will be grateful.

I do it in PLplot 5.12.0 and gfortran from gcc-6.3.0.

Thank you in advance.

Andrzej

Re: [Plplot-general] Smart labels?

[AARON H. <he...@co...>]

-----Original Message-----

From: ir...@be...
To: he...@co...
Cc: plp...@li...
Sent: 2017-03-30 12:54:45 PM 
Subject: Re: [Plplot-general] Smart labels?

On 2017-03-27 21:38-0500 AARON HEXAMER wrote:

> For lack of a better term ... I'm looking for a feature that could
place a text label in the viewport closest to a desired coordinate,
but without intersecting any plotted data nor being clipped by the
viewport bounds?  AFAICT, there is no API that does this.  I suppose
its probably non-trivial.  I'm wondering though if there is some
feature that could test for intersection/clipping before updating the
plot so I could provide an iterative method of placement.  Any
thoughts?

Hi Aaron:

I am sorry, but as far as I know we don't have such an API or a way to
test for intersection of a graphical element with any (previous)
graphical element.

Thank you for confirming.  If I want to keep exploring this route I might try Boost::geometry.

> To understand the problem I'm trying to solve, see this post where
the GM and PM labels get clipped
(https://www.picotech.com/support/topic14311-120.html#p78941).  I
suppose I could also let the user configure label placement, but only
if there's no other practical way to automate it.

I took a look at that plot, and the fundamental issue is you are
trying to label two points with extremely long labels that get clipped
at the viewport boundary because the two points are close to the RHS
of the plot.  I suggest instead you mark those two points with
distinct single-glyph symbols (using plstring), and then use a legend
(the pllegend API for PLplot, see
<http://plplot.sourceforge.net/examples.php?demo=04> for an example)
to give additional details for each symbol.  In my opinion that method
is the ideal way to present all the information you plot now.

I agree with that opinion.  It's precisely what I was thinking.

Thanks for your interest in PLplot.

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-general] Smart labels?

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

On 2017-03-27 21:38-0500 AARON HEXAMER wrote:

> For lack of a better term ... I'm looking for a feature that could
place a text label in the viewport closest to a desired coordinate,
but without intersecting any plotted data nor being clipped by the
viewport bounds?  AFAICT, there is no API that does this.  I suppose
its probably non-trivial.  I'm wondering though if there is some
feature that could test for intersection/clipping before updating the
plot so I could provide an iterative method of placement.  Any
thoughts?

Hi Aaron:

I am sorry, but as far as I know we don't have such an API or a way to
test for intersection of a graphical element with any (previous)
graphical element.

> To understand the problem I'm trying to solve, see this post where
the GM and PM labels get clipped
(https://www.picotech.com/support/topic14311-120.html#p78941).  I
suppose I could also let the user configure label placement, but only
if there's no other practical way to automate it.

I took a look at that plot, and the fundamental issue is you are
trying to label two points with extremely long labels that get clipped
at the viewport boundary because the two points are close to the RHS
of the plot.  I suggest instead you mark those two points with
distinct single-glyph symbols (using plstring), and then use a legend
(the pllegend API for PLplot, see
<http://plplot.sourceforge.net/examples.php?demo=04> for an example)
to give additional details for each symbol.  In my opinion that method
is the ideal way to present all the information you plot now.

Thanks for your interest in PLplot.

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-general] PLPLOT & Getting It To Work with Silverfrost FTN95 Fortran

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> However, it would be nice to get these anticipated good results confirmed for the
> eight compilers we have no results for yet, and also it would be good to get
> confirmation of our own good results for gfortran, Intel, and NAG.  So I urge anyone
> here with access to any of those 11 compilers to give them a try with PLplot-5.12.0
> and let us know the results.
>

I just saw a new version of the Oracle Developer Studio announced on the comp.lang.fortran newsgroup. That may be a good opportunity to try this compiler suite to build PLplot.

Regards,

Arjen

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

[Plplot-general] Smart labels?

[AARON H. <he...@co...>]

For lack of a better term ... I'm looking for a feature that could place a text label in the viewport closest to a desired coordinate, but without intersecting any plotted data nor being clipped by the viewport bounds?  AFAICT, there is no API that does this.  I suppose its probably non-trivial.  I'm wondering though if there is some feature that could test for intersection/clipping before updating the plot so I could provide an iterative method of placement.  Any thoughts?

To understand the problem I'm trying to solve, see this post where the GM and PM labels get clipped (https://www.picotech.com/support/topic14311-120.html#p78941).  I suppose I could also let the user configure label placement, but only if there's no other practical way to automate it.

Thanks,

Aaron

Re: [Plplot-general] PLPLOT & Getting It To Work with Silverfrost FTN95 Fortran

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

On 2017-03-22 07:55-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, March 21, 2017 8:00 PM
[...]
>> Our experience is the PLplot Fortran binding and examples work fine with the NAG
>> fortran compiler (nagfor), Intel Fortran compiler (ifort) and the Fortran compiler
>> (gfortran) that is part of the gcc suite of compilers. But has anybody here tried other
>> well-known Fortan compilers such as those from Absoft or the Portland Group?  My
>> understanding is CMake supports both the Absoft and Portland Group Fortran
>> compilers so the question really boils down to whether those compilers have the
>> necessary support for Fortran 2003.
>>

>>> AM: I am pretty sure they do. The standards' support for a number
of compilers is regularly compared by Ian Chivers and Jane
Sleightholme for the ACM Fortran Forum and the 11 compilers they list
all have full support for the F2003 C-Fortran interoperability [....]

Hi Arjen:

I followed up by looking carefully at the part of the table in
<http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>
corresponding to C interoperability for the 11 Fortran compilers that
are covered in the report (i.e., Absoft, Cray, g95, gfortran, HP, IBM,
Intel, NAG, Oracle, PGI, and Path scale).  Those first 10 have a "Y"
(yes) for all C interoperability features while Path scale has a "Y"
for all features other than "Interoperability of global data" where it
has a "N" (no).  So from your perfect results (no build warnings or
errors, no run-time errors, and perfect PostScript difference results)
for a compiler (NAG) that is notorious for being standards compliant,
my and your good results for gfortran and ifort (Intel), and from the
results from this report it appears there is a good chance that
Absoft, Cray, g95, HP, IBM, Oracle, and PGI will also produce good
results for our new Fortran binding for PLplot.  And the Path scale
Fortran compiler might also produce good results depending on whether
or not our Fortran binding uses the "Interoperability of global data"
feature.

However, it would be nice to get these anticipated good results
confirmed for the eight compilers we have no results for yet, and also
it would be good to get confirmation of our own good results for gfortran,
Intel, and NAG.  So I urge anyone here with access to any of those 11
compilers to give them a try with PLplot-5.12.0 and let us know the
results.

Also, getting back to the original Silverfrost Fortran topic, I think
it is telling that that vendor hasn't bothered to register with the
authors of the above well-known report despite a general invitation
(at the start of that report) for any Fortran compiler vendor to
participate.

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-general] PLPLOT & Getting It To Work with Silverfrost FTN95 Fortran

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

Hi everyone,

I forgot to add the link to the Fortran comparison page I mentioned. Here it is:
http://www.fortranplus.co.uk/fortran-information/

Regards,

Arjen

> -----Original Message-----
> From: Arjen Markus [mailto:Arj...@de...]
> >
> >>AM: I am pretty sure they do. The standards' support for a number of compilers
> is regularly compared by Ian Chivers and Jane Sleightholme for the ACM Fortran
> Forum and the 11 compilers they list all have full support for the F2003 C-Fortran
> interoperability, with even the further enhancements in one of the technical reports
> for many of them. Unfortunately Silverfrost FTN95 is not one of the 11 compilers.
>

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-general] PLPLOT & Getting It To Work with Silverfrost FTN95 Fortran

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

Hi Alan,

See my comments below

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, March 21, 2017 8:00 PM
> To: Arjen Markus
> Cc: John AUSTIN; plp...@li...
> Subject: Re: [Plplot-general] PLPLOT & Getting It To Work with Silverfrost FTN95
> Fortran
>
> Hi Arjen and John:
>
> On 2017-03-21 09:58-0000 Arjen Markus wrote:
>
> > Hi John,
> >
> > Well, a quick search revealed:
> >
> > -        CMake does not support Silverfrost out-of-the-box, at least I could not find
> a module for it
> > -        Silverfrost FTN95 is limited to Fortran 95, so it will not support the current
> binding
>
> @Arjen:
>
> For the record do you have a reference for that second result?  I looked for that
> myself last night but could not find the definitive statement about what versions of
> Fortran were supported by FTN95.


>>AM: I concluded this from this page - http://www.silverfrost.com/12/ftn95/ftn95_feature_details.aspx.
There is no mention of any of the standards since Fortran 95 (F2003, F2008 and the upcoming F2015). The documentation on language features is pretty limited but there is also no hint of anything beyond F95.


>
> @John:
>
> Arjen has nicely summarized above the two hurdles to overcome before you could
> use FTN95 (or any other Fortran compiler) to build the PLplot Fortran bindings.
> One is CMake support for FTN95 and the other is FTN95 support for Fortran 2003.
> Both of these are the responsibility of Silverfrost so I suggest you contact them to
> see what they say about their plans in these areas.  Meanwhile, I suggest you try a
> better supported Fortran compiler such as ifort which _we know_ works fine to build
> the Fortran binding of PLplot.
>
> @Everybody here:
>
> Our experience is the PLplot Fortran binding and examples work fine with the NAG
> fortran compiler (nagfor), Intel Fortran compiler (ifort) and the Fortran compiler
> (gfortran) that is part of the gcc suite of compilers. But has anybody here tried other
> well-known Fortan compilers such as those from Absoft or the Portland Group?  My
> understanding is CMake supports both the Absoft and Portland Group Fortran
> compilers so the question really boils down to whether those compilers have the
> necessary support for Fortran 2003.
>
>>AM: I am pretty sure they do. The standards' support for a number of compilers is regularly compared by Ian Chivers and Jane Sleightholme for the ACM Fortran Forum and the 11 compilers they list all have full support for the F2003 C-Fortran interoperability, with even the further enhancements in one of the technical reports for many of them. Unfortunately Silverfrost FTN95 is not one of the 11 compilers.

Regards,

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