Re: [Plplot-devel] Convenient submission of dashboards has now been enabled

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, December 01, 2016 2:15 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Convenient submission of dashboards has now been
> enabled
>
> On 2016-11-30 13:57- Arjen Markus wrote:
>
> > By the looks of the first part of the output it has done the trick
> indeed :). No compiler errors or warnings according to ctest.
>
> Hi Arjen:
>
> I was very happy to see your clean dashboard (aside from some spurious warning
> counts for the configuration stage) at
> .
>
> I did take a quick look at the cmake output that is published there.
> In particular, these notices are all OFF for your Cygwin platform while mine 
> are ON
> on Linux:
>
> ENABLE_ada:OFF
> ENABLE_d:OFF
> ENABLE_java:OFF
> ENABLE_ocaml:OFF
> ENABLE_octave:OFF
> ___
> ENABLE_pyqt4:OFF
> ENABLE_tk:OFF
> ENABLE_itk:OFF
>
> The ones above the line we have discussed before. You have been forced to set
> ENABLE_ada:OFF due to our own problem with Ada language support on Windows.
> The D, Java, and OCaml issues are due to missing software on Cygwin, i.e., the
> gdc.exe D compiler, some Java environment (e.g., gcj.exe, gij,exe, and other 
> java
> friends), camlidl.exe (the rest of ocaml support is available), and 
> octave.exe.  I
> suggest you make appropriate packaging requests on the Cygwin mailing list to 
> see
> if anybody is willing to do thatrequired packaging work.
>
> I am pretty sure you have dealt with the ones below the line before, i.e., 
> those are
> regressions from your previous results from running 
> scripts/comprehensive_test.sh.
>
The tk and itk components were not enabled by CMake because there was no X 
server running. I am not sure about the PyQt4 component. But when I tried to do 
it via the comprehensive test script, I got compilation errors - see the 
attached tarball.

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.


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

Re: [Plplot-devel] Python3

[Alan W. Irwin]

On 2016-11-30 20:59-0500 Hazen Babcock wrote:

>
>
> On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
>> It is good to hear it is likely going to be even easier than I thought.  I
>> guess that -py3 flag is needed for more complex Python bindings than ours.
>
> Spoke too soon I guess. It appears that swig detects which version of Python 
> you are using and creates a binding that only works with that version. So if 
> you create the bindings in a Python3 environment they will not work with 
> Python2 and vice versa.

Hi Hazen:

I suggest the proper thing for me to do here (post-release since you
are not quite ready yet to merge your Python 3 work, and I am pretty
busy myself) is to have the build system look preferentially for
support for Python 3 + consistent numpy for that Python version, and
if that is not found fall back to looking for Python 2 + consistent
numpy for that version.  But the user has the option to skip the look
for that first preference if they so desire. So the approach would be
similar to the way the build system looks first for Qt4, then Qt5
with the user option to skip the look for Qt4
except in the Python case the first preference order should likely be the
newer Python (which I assume is completely stable), then the older (as
opposed to the Qt case where the preference order is old, then new for
the reasons I have discussed).

>
>> I have looked at the naming conventions used in practice for
>> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
>> of inserting a "module" suffix on the basename of the shared object
>> has mostly (but not completely) fallen out of favour.  So it is fine
>> with me if you drop the module part of the shared object name as well.
>
> I just changed the output target from _plplotcmodule to _plplotc. Maybe this 
> will have some downstream consequences?

I don't believe this is a concern. That doubly raw C module should be
effectively private, i.e., it should only be imported by the swig-generated
plplotc.py module (which we already designate as the raw module).  That in turn 
is
imported by the hand-crafted module plplot.py which is the one
that users would prefer to import. So I don't think there will be any
downstream consequences other than in the lists of filenames that are
part of creating a software package (i.e. an rpm or deb) for PLplot,
but packagers typically have access to packaging tools to automatically
deal with changed filenames that are installed so I don't think even
that is going to be a downstream issue.

>> make test_python_psc
>
> ..
>
>> Then, you can run that example individually
>> (_in the build tree_) as follows:
>> 
>> examples/python/x00 -dev psc -o test.psc
>
> Thank you, this was very helpful.

You are welcome.

>
> The Python bindings are now compatible with Python3 as well as Python2, as 
> judged by running the (basic?) tests, i.e.
>
> $ make
> $ ctest

Good news, indeed!

>
> New questions:
> (1) How does one run the tests that compare the example output files to each 
> other so that I can verify that the output is still the same?

ctest does that already with its examples_compare test (which depends
on the various tests named examples_ which run our standard
set of  examples using -dev psc).  I think you need the
--extra-verbose option to see the results of that test on stdout, but
I also believe even without that option you can see the results of that
test in the Testing hierarchy of directories.

> (2) There appear to be at least two versions of each Python example. Maybe we 
> could get rid of one set? i.e. the xNN.py set and not the xwNN.py set that 
> are actually tested?

You ask interesting questions!  The situation concerning the largely
unmaintained xNN.py set and the well-maintained 
and xwNN.py set is summarized in examples/python/README.pythondemos.
At the time when I wrote that, I was hoping that Geoffrey Furnish (who
was the author of the plplot_widgets module and the pytkdemo example
that used that module + Tkinter + our own Tcl/Tk plframe GUI) would
consolidate the two sets of examples, i.e., by teaching the
well-maintained xwNN.py set how to be run from pytkdemo.

Well, Geoffrey dropped out of PLplot development soon after and there
it rested until you asked your question above.  :-)

To start to answer your question I have just implemented a test of
pytkdemo (see commit cb2a2c6) which is the test_pytkdemo target, and
that target build and resulting GUI appear to work fine subject to
some bugs in the xNN.py set of examples (see lack of maintenance
comment above).  Also, to look further at the consolidation question I
looked carefully at x10 + xw10.py (the combination used to run that
example for the pure python case versus x10.py, and it turns out the
only real difference is the namespace one which is straightforward to
deal with.

So I tried the appropriate namespace changes for x10 and xw10.py, and
the result is xw10.py can be called directly from pytkdemo, and the
combination of x