plplot-devel — Technical discussion about PLplot development

[Plplot-devel] My work on the new Fortran binding is completed other than testing

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

My recent (commit 9d436ac) implementation of Fortran (as opposed to C)
callbacks for plcont, plshade, plshades, plimagefr, and plvect
completes virtually all of what I had planned for the new Fortran
binding, and here is what remains for me to do.

* Test the routines that have Fortran callback arguments (those
mentioned above plus the plmap* routines, plmeridians, plslabelfunc,
and plstransform) with every variant of such callbacks to make sure
there are no typographical errors in our Fortran binding concerning
support of all types of callbacks.  These tests will be implemented
as optional variants of our Fortran examples.

* Respond to any issues those tests turn up.

That is it!

Therefore, if you have an interest in Fortran or just want to help out
in general with PLplot testing, please review the Fortran platforms
you have access to in mental preparation for responding to the call
for widespread testing of our new Fortran binding I plan to make after
the above two items are completed (probably within a day or so).

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] Fortran callback progress

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

Hi Alan,



I hope that will do the trick :). The nuisance in not so much in adapting the file, its format is pretty simple, but making sure it is complete. By the looks of it your script will indeed keep it up-to-date. More later after testing.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, February 17, 2016 12:51 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Fortran callback progress
>
> On 2016-02-15 19:30-0800 Alan W. Irwin wrote:
>
> > N.B. a quick check that ifort can build the present compactly styled
> > library would be appreciated if you are not completely caught up
> > finishing other things before your holiday.
>
> Hi Arjen:
>
> To make such ifort tests more convenient for you I have implemented (commit
> 4fe0797) a (unix-only) target, "check_ifort_definitions_file"
> which I have used to automatically update plplotf95_ifort.def consistent with the
> latest changes to the fortran binding implementation that I have recently committed.
> And I plan to continue using this target for my further planned changes to the
> Fortran binding.
>
> In other words, if there are no issues with this target's implementation, then running
> this target each time the Fortran binding is changed means you should no longer
> have to hand-edit plplotf95_ifort.def.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

[Plplot-devel] Dropped remaining use of pltr0f from our Fortran binding

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

Hi Arjen:

I have been looking at how we use pltr0(f) in both our old and new
Fortran bindings, where pltr0f differs from pltr0 by an offset of 1 in
the index transformation.

The pltr0f callback was used for PLCON07 and PLVEC07 (plcont and plvec
signatures without callback-related arguments (i.e., no trailing xg,
yg, tr, or callback arguments), but these overloaded versions of
plcont and plvect were not actually tested in our examples and were
not documented.  If anybody ever actually used that signature for the
old binding I believe they would find that offset of 1 on what, after
all, is the value of a C index is problematic since it means that the
Fortran plot results would be shifted by 1 unit from the corresponding
C results.

Since I view that offset of 1 used by pltr0f as problematic, I decided
to implement our plcont signature without callback-related arguments
using pltr0 rather than pltr0f some while ago, and I have now (commit
55a6de0) done the same for our plvect signature without
callback-related arguments.  The result is we no longer have use for
plplot_private_pltr0f so I have removed that routine from the
plplot_private_exposed module as of the same commit.

As part of that same commit, I have documented the backwards
incompatibilities for these particular plcont and plvect signatures in
README.release. However, I have also noted this is "for the record"
documentation because these signatures were unlikely to be used by
anybody since they were not documented or used in any of our examples.

To complete this story concerning signatures for the case of no callback-related
arguments, in our new Fortran binding we internally use a NULL C
callback for the case where the Fortran signatures of plshade,
plshades, and plimagefr have no callback-related arguments. To me this
approach (lack of Fortran arguments maps to NULL callback) just makes
sense philosophically.  Furthermore, the NULL C callback is a signal
to the C versions of plshade, plshades, and plimagefr to map the index
ranges of the results to the xmin, xmax, ymin, and ymax arguments of
those routines without bothering with using a callback to do this
mapping. (The plcont and plvect C routines have no xmin, xmax, ymin,
and ymax arguments so a NULL callback is not allowed for those two
cases.)

I have confirmed that our old Fortran binding also used a NULL C
callback for plshade and plshades (see PLSHADE07, and PLSHADES07), but
that binding used pltr0 rather than NULL for the plimagefr (see
PLIMAGEFR07) case.  In retrospect I think that was a mistake for our
old binding (although that mistake made no difference for our examples
because pltr0 applies an identity transformation to the index range of
x and y, and the xmin, xmax, ymin, and ymax arguments happen to
correspond to their index ranges in example 20 where this signature is
used).  As of commit 0258c58 I have documented this backwards
incompatibility in README.release.

Please let me know if you have any strong objections to the approach
I have taken for the case where the signatures of plcont, plshade,
plshades, plimagefr, and plvect have no callback-related arguments.

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] Can the rasterization be improved/parameterized?

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

It looks like the gcc driver is not using antialiasing, nor subpixel accuracy.

Jim-does gcc use GDI or GDI+? GDI has graphics acceleration, but no antialiasing, whereas GDI+ has no graphics accelleration, but can do antialiasing and can do subpixel accuracy. These are the two APIs used by the wxWidgets on Windows for wxMemoryDC and wxGraphicsContext, so I assume gcc uses one of them?

-----Original Message-----
From: "Greg Jung" <gv...@gm...>
Sent: ‎17/‎02/‎2016 07:53
To: "plp...@li..." <plp...@li...>
Subject: [Plplot-devel] Can the rasterization be improved/parameterized?

I am comparing what is done in windows using the wincairo driver and
the normal wingdi/wingcc methods, the diagonal line from Cairo looks
quite straight but the gdi-drawn line is jagged.  




The top-stacked plot uses wincairo while the bottom plot uses the wingdi (which is wingcc
with better lettering and re-scaling).  Each plot is the same, drawing diagonals through 
points (each major tic is 20), about 65 in the top graph.
 
  Does the jagged diagonal arise from an efficiency method that can be parameterized 
to not be so fast, but look better?


Thanks,
Greg

[Plplot-devel] Can the rasterization be improved/parameterized?

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

I am comparing what is done in windows using the wincairo driver and
the normal wingdi/wingcc methods, the diagonal line from Cairo looks
quite straight but the gdi-drawn line is jagged.

[image: Inline image 1]
The top-stacked plot uses wincairo while the bottom plot uses the wingdi
(which is wingcc
with better lettering and re-scaling).  Each plot is the same, drawing
diagonals through
points (each major tic is 20), about 65 in the top graph.

  Does the jagged diagonal arise from an efficiency method that can be
parameterized
to not be so fast, but look better?

Thanks,
Greg

Re: [Plplot-devel] Fortran callback progress

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

On 2016-02-15 19:30-0800 Alan W. Irwin wrote:

> N.B. a quick check that ifort can build the present compactly styled
> library would be appreciated if you are not completely caught up
> finishing other things before your holiday.

Hi Arjen:

To make such ifort tests more convenient for you I have implemented
(commit 4fe0797) a (unix-only) target, "check_ifort_definitions_file"
which I have used to automatically update plplotf95_ifort.def
consistent with the latest changes to the fortran binding
implementation that I have recently committed.  And I plan to
continue using this target for my further planned changes to
the Fortran binding.

In other words, if there are no issues with this target's
implementation, then running this target each time the Fortran binding
is changed means you should no longer have to hand-edit
plplotf95_ifort.def.

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] Fortran callback progress

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, February 16, 2016 4:30 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Fortran callback progress
>
> On 2016-02-15 02:59-0800 Alan W. Irwin wrote:
>
> [...]
> > Actually, plmap, plmapline,
> > plmapfill, etc., have the same near-duplicate messy code style issues
> > so I am trying to figure out how to fix those issues first before I
> > tackle implementing real fortran callbacks for plcont, plshade,
> > plshades, plimage and plvect.
>
> Hi Arjen:
>
> As of commit 971cb37 I did discover a way to implement the two precision flavours
> of plmap, plmapline, etc. (and also plmeridians) in
> included_plplot_real_interfaces.f90 for a 50 per cent saving in code (and also likely
> a considerable improvement in developer understanding
> 20 years from now).
>
> The only caveat with this new "compact" style is you get the following two gfortran
> build warnings
>
> Warning: Symbol 'plmapformf2c' at (1) is marked PRIVATE but has been given the
> binding label 'plplot_double_plmapformf2c'
>
> and
>
> Warning: Symbol 'plmapformf2c' at (1) is marked PRIVATE but has been given the
> binding label 'plplot_single_plmapformf2c'
>
>
> When I looked up that build warning it appears to be regarded by certain legitimate-
> sounding users as a gfortran bug (see
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>).  And I also liked the
> argument presented in one of those reports that there are two kinds of privacy in
> this case which are Fortran module privacy and overall privacy, and you may well
> want to keep parts of a module private from other modules (as I do in this case to
> avoid the plmapformf2c name clash) while there are still associated public results
> from this module code (i.e., the public symbols plplot_double_plmapformf2c and
> plplot_single_plmapformf2c exist in the library).  So although the gfortran
> developers have not responded to this good argument (yet) one hopes they will do
> so in the long run to get rid of this warning message that says essentially that
> overall privacy has been violated.  After all, that is a pretty spurious warning since
> essentially the same thing happens without a warning message for the names
> (which are also module-private but not overall
> private) of our module procedures.
>
> In any case the result at run-time (as you can see from my commit
> message) is perfect so I am going to ignore the above two warnings and assume no
> other compiler will have any issue with a private C binding.
>
> N.B. a quick check that ifort can build the present compactly styled library would be
> appreciated if you are not completely caught up finishing other things before your
> holiday.
>
> I intend to follow up the current good results for the compact style with (i)
> implementing with a similar compact style real Fortran callbacks for plcont, plshade,
> plshades, plimage, and plvector, (ii) testing all those real callbacks, and (iii)
> updating bindings/f95/plplotf95_ifort.def. (I noticed that file is rather incomplete at
> the moment, e.g., no single-precision version of any of the plmap* routines, but it
> should be straightforward to update it using the results from
>
> nm --defined-only bindings/f95/libplplotf95.so
>
> and the existing symbol patterns in that file.)
>
> Those three topics should finally finish off my Fortran plans for this release cycle,
> although I still have a lot of non-Fortran topics on my agenda for this release cycle
> so the forthcoming release date is still not settled.
>
Great, I have seen this warning message myself too, but I think it is over cautious. I am positive Intel Fortran will accept the new code too, but I will try it out.

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-devel] Fortran callback progress

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

On 2016-02-15 02:59-0800 Alan W. Irwin wrote:

[...]
> Actually, plmap, plmapline,
> plmapfill, etc., have the same near-duplicate messy code style issues
> so I am trying to figure out how to fix those issues first before I
> tackle implementing real fortran callbacks for plcont, plshade,
> plshades, plimage and plvect.

Hi Arjen:

As of commit 971cb37 I did discover a way to implement the two
precision flavours of plmap, plmapline, etc. (and also plmeridians) in
included_plplot_real_interfaces.f90 for a 50 per cent saving in code
(and also likely a considerable improvement in developer understanding
20 years from now).

The only caveat with this new "compact" style is you get the following two
gfortran build warnings

Warning: Symbol 'plmapformf2c' at (1) is marked PRIVATE but has been
given the binding label 'plplot_double_plmapformf2c'

and

Warning: Symbol 'plmapformf2c' at (1) is marked PRIVATE but has been
given the binding label 'plplot_single_plmapformf2c'


When I looked up that build warning it appears to be regarded by
certain legitimate-sounding users as a gfortran bug (see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>).  And I also
liked the argument presented in one of those reports that there are
two kinds of privacy in this case which are Fortran module privacy and
overall privacy, and you may well want to keep parts of a module
private from other modules (as I do in this case to avoid the
plmapformf2c name clash) while there are still associated public
results from this module code (i.e., the public symbols
plplot_double_plmapformf2c and plplot_single_plmapformf2c exist in the
library).  So although the gfortran developers have not responded to
this good argument (yet) one hopes they will do so in the long run to
get rid of this warning message that says essentially that overall
privacy has been violated.  After all, that is a pretty spurious
warning since essentially the same thing happens without a warning
message for the names (which are also module-private but not overall
private) of our module procedures.

In any case the result at run-time (as you can see from my commit
message) is perfect so I am going to ignore the above two warnings and
assume no other compiler will have any issue with a private C binding.

N.B. a quick check that ifort can build the present compactly styled
library would be appreciated if you are not completely caught up
finishing other things before your holiday.

I intend to follow up the current good results for the compact style
with (i) implementing with a similar compact style real Fortran
callbacks for plcont, plshade, plshades, plimage, and plvector, (ii)
testing all those real callbacks, and (iii) updating
bindings/f95/plplotf95_ifort.def. (I noticed that file is rather
incomplete at the moment, e.g., no single-precision version of any of
the plmap* routines, but it should be straightforward to update it
using the results from

nm --defined-only bindings/f95/libplplotf95.so

and the existing symbol patterns in that file.)

Those three topics should finally finish off my Fortran plans for this
release cycle, although I still have a lot of non-Fortran topics on my
agenda for this release cycle so the forthcoming release date is
still not settled.

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] CMake-3.5.x works flawlessly on Linux so far

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, February 15, 2016 12:00 PM
> Hi Arjen:
>
> So there are really two mysteries here: (1) how did your fix (no symbols visible in
> libplplottcltk) not cause a bad linking issue on Windows like it does on Linux, and (2)
> how can my similar fix (the plplotLibDir symbol not visible in libplplottcltk) not work
> on Windows? Oh well, humbled again.  :-)

I think the problem is that we are dealing with two different concepts: visibility under Linux and items that are to be imported/exported under Windows. Exporting an item (function or data) from a DLL under Windows is a bit similar to visibility under Linux, but importing is something that needs to be done explicitly under Windows - at least when data are concerned. That does not make it easier to solve the issue of course, sigh.

>
> There is no use spoiling your holiday trying to finish too much just beforehand so I
> suggest you ignore this issue and the remaining Tcl example issues until after your
> holiday is done.
>
> In any case it is also going to take me a while to finish up implementing real Fortran
> callbacks for plcont, plshade, plshades, plimage and plvect. I know how to do that
> with a lot of nearly duplicated single and double precision code in plplot.f90, but I
> dislike that messy and error-prone style so I am trying to figure out how to
> implement it instead with half the code in included_plplot_real_interfaces.f90.
> Actually, plmap, plmapline, plmapfill, etc., have the same near-duplicate messy
> code style issues so I am trying to figure out how to fix those issues first before I
> tackle implementing real fortran callbacks for plcont, plshade, plshades, plimage
> and plvect.
>
That is clear - after my holiday I should be able to spare some time again to see if we can find a solution together, if that will still be necessary by then.

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.

Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far

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

On 2016-02-15 07:52-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Sunday, February 14, 2016 10:01 PM
>> To: Arjen Markus
>> Cc: PLplot development list
>> Subject: Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>>
>> On 2016-02-11 12:40-0800 Alan W. Irwin wrote:
>>
>>>
>>> Hi Arjen:
>>>
>>> Could you check if this is really a CMake-3.4.3 issue?  That is if you
>>> run the exact same test with CMake-3.3.2 does that solve it? Or does
>>> that linker error persist for both cases presumably due to a long-term
>>> MSVC visibility issue for the combination of libplplottcltk and libplplot?
>>>
>>> The reason I suspect the latter case is the only way I can see that
>>> the CMake version affects our visibility implementation is if there is
>>> an an unlikely CMake regression in the way that include/pldll.h(.in)
>>> is configured or an unlikely regression in the way that CMake emits
>>> the plplot_EXPORTS macro when compiling libplplot and the
>>> plplottcltk_EXPORTS when compiling libplplottcltk.  Furthermore, the
>>> linker only gave an error message for one symbol, plplotLibDir.  That
>>> is, visibility seems OK for everything but plplotLibDir.  Also
>>>
>>> software@raven> find . -type f |grep -v .git |xargs grep -l
>>> plplotLibDir
>>>
>>> tells me that symbol only occurs in
>>>
>>> ./bindings/tcl/tclAPI.c
>>> ./src/plctrl.c
>>>
>>> in our source code.  If I understand the purpose of plplotLibDir
>>> correctly, it allows libtcltk to get plLibOpenPdfstrm within libplplot
>>> to open a particular file.
>>>
>>> Anyhow, the visibility of plplotLibDir is implemented in an extremely
>>> unique way in _both_ the above files, and it appears to me the use of
>>> different _forms_ of visibility macros (i.e., PLDLLIMPEXP_TCLTK_DATA
>>> in the former case and PLDLLIMPEXP in the latter case) is problematic
>>> as well.
>
>
> Hm, I hadn't seen this message. See below for the current result.
>
>>
>> Hi Arjen:
>>
>> Your recent (commit b94370e) fix for the above issue cannot be correct since it
>> blocks all symbols from being exported from libplplottcltk which makes that library
>> useless.  So, for example, the result on Linux with
>>
>> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>>
> ...
>
>>
>> i.e., no symbols relevant to PLplot are available from that library as the direct result
>> of your change.  This problem in turn generates build errors such as
>>
>
> This is not what I see on "bare" Windows. There the pltcl shell runs fine with the changes I made. Very annoying!
>
>> [...]
>> [100%] Linking C executable pltcl
>> CMakeFiles/pltcl.dir/pltcl.c.o: In function `AppInit':
>> pltcl.c:(.text+0x14a): undefined reference to `Pltcl_Init'
>> collect2: error: ld returned 1 exit status
>> bindings/tcl/CMakeFiles/pltcl.dir/build.make:99: recipe for target 'bindings/tcl/pltcl'
>> failed
>> make[3]: *** [bindings/tcl/pltcl] Error 1
>> CMakeFiles/Makefile2:2069: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/all'
>> failed
>> make[2]: *** [bindings/tcl/CMakeFiles/pltcl.dir/all] Error 2
>> CMakeFiles/Makefile2:2081: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/rule'
>> failed
>> make[1]: *** [bindings/tcl/CMakeFiles/pltcl.dir/rule] Error 2
>> Makefile:845: recipe for target 'pltcl' failed
>> make: *** [pltcl] Error 2
>>
>> I am virtually positive you will be able to confirm build issues with pltcl for MSVC as
>> well for the same reason (no symbols exported from libplplottcltk).
>>
>> Such build issues interfere with those trying to follow the master branch so I have
>> reverted your change as a temporary emergency measure (commit ca170c0).
>>
>> However, I think the only problem with your commit may be that you used too large
>> a hammer (i.e., disabled all symbol visibility) to disable the visibility of the
>> plplotLibDir symbol within libplplottcltk.
>>
>> Therefore, in a follow up commit (bbff8af) I tried disabling just the visibility of the
>> plplotLibDir symbol within libplplottcltk.  That change causes no build issues on
>> Linux.  Does that also fix the build issue on MSVC?
>>
>> Note my tests of bbff8af discovered a recently introduced matrix size issue with
>> plpat for example 15 under Tcl, and when I locally disabled plpat to get by that error
>> then there was an additional such issue (I have forgotten for which command) for
>> example 18.  (By the way, unlike what you intended these were actual errors
>> concerning matrix size incompatibility rather than just warnings.) My Tcl abilities are
>> not sufficient for solving these matrix size issues so I rely on you to do that. Note to
>> find all such issues you must systematically exercise every Tcl example on MSVC
>> by hand or else build the test_pltcl_standard_examples target on Cygwin,
>> MinGW/MSYS, MinGW-w64/MSYS2, or Linux.
>>
>
>
>
> I will deal with the examples later - I discovered a flaw in example x01.tcl - a mismatch between the declared size (101) and the actually used size (100) that popped when I removed the (almost) superfluous size argument.
>
>
>
> With the current source code as per your visibility change for plplotLibDir I get this again:
>
>
> [ 13%] Linking C shared library ..\..\dll\plplottcltk.dll
>
>   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp
>
> tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir ..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals
>
> LINK Pass 1 failed. with 1120
>
> NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
>
>
> I will have to carefully unravel this mystery, but I am not sure that I will have time to complete that task before the end of the week (that is: before my holiday).

Hi Arjen:

So there are really two mysteries here: (1) how did your fix (no
symbols visible in libplplottcltk) not cause a bad linking issue on
Windows like it does on Linux, and (2) how can my similar fix (the
plplotLibDir symbol not visible in libplplottcltk) not work on
Windows? Oh well, humbled again.  :-)

There is no use spoiling your holiday trying to finish too much just
beforehand so I suggest you ignore this issue and the remaining Tcl
example issues until after your holiday is done.

In any case it is also going to take me a while to finish up
implementing real Fortran callbacks for plcont, plshade, plshades,
plimage and plvect. I know how to do that with a lot of nearly
duplicated single and double precision code in plplot.f90, but I
dislike that messy and error-prone style so I am trying to figure out
how to implement it instead with half the code in
included_plplot_real_interfaces.f90. Actually, plmap, plmapline,
plmapfill, etc., have the same near-duplicate messy code style issues
so I am trying to figure out how to fix those issues first before I
tackle implementing real fortran callbacks for plcont, plshade,
plshades, plimage and plvect.

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] CMake-3.5.x works flawlessly on Linux so far

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, February 14, 2016 10:01 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>
> On 2016-02-11 12:40-0800 Alan W. Irwin wrote:
>
> >
> > Hi Arjen:
> >
> > Could you check if this is really a CMake-3.4.3 issue?  That is if you
> > run the exact same test with CMake-3.3.2 does that solve it? Or does
> > that linker error persist for both cases presumably due to a long-term
> > MSVC visibility issue for the combination of libplplottcltk and libplplot?
> >
> > The reason I suspect the latter case is the only way I can see that
> > the CMake version affects our visibility implementation is if there is
> > an an unlikely CMake regression in the way that include/pldll.h(.in)
> > is configured or an unlikely regression in the way that CMake emits
> > the plplot_EXPORTS macro when compiling libplplot and the
> > plplottcltk_EXPORTS when compiling libplplottcltk.  Furthermore, the
> > linker only gave an error message for one symbol, plplotLibDir.  That
> > is, visibility seems OK for everything but plplotLibDir.  Also
> >
> > software@raven> find . -type f |grep -v .git |xargs grep -l
> > plplotLibDir
> >
> > tells me that symbol only occurs in
> >
> > ./bindings/tcl/tclAPI.c
> > ./src/plctrl.c
> >
> > in our source code.  If I understand the purpose of plplotLibDir
> > correctly, it allows libtcltk to get plLibOpenPdfstrm within libplplot
> > to open a particular file.
> >
> > Anyhow, the visibility of plplotLibDir is implemented in an extremely
> > unique way in _both_ the above files, and it appears to me the use of
> > different _forms_ of visibility macros (i.e., PLDLLIMPEXP_TCLTK_DATA
> > in the former case and PLDLLIMPEXP in the latter case) is problematic
> > as well.


Hm, I hadn't seen this message. See below for the current result.

>
> Hi Arjen:
>
> Your recent (commit b94370e) fix for the above issue cannot be correct since it
> blocks all symbols from being exported from libplplottcltk which makes that library
> useless.  So, for example, the result on Linux with
>
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>
...

>
> i.e., no symbols relevant to PLplot are available from that library as the direct result
> of your change.  This problem in turn generates build errors such as
>

This is not what I see on "bare" Windows. There the pltcl shell runs fine with the changes I made. Very annoying!

> [...]
> [100%] Linking C executable pltcl
> CMakeFiles/pltcl.dir/pltcl.c.o: In function `AppInit':
> pltcl.c:(.text+0x14a): undefined reference to `Pltcl_Init'
> collect2: error: ld returned 1 exit status
> bindings/tcl/CMakeFiles/pltcl.dir/build.make:99: recipe for target 'bindings/tcl/pltcl'
> failed
> make[3]: *** [bindings/tcl/pltcl] Error 1
> CMakeFiles/Makefile2:2069: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/all'
> failed
> make[2]: *** [bindings/tcl/CMakeFiles/pltcl.dir/all] Error 2
> CMakeFiles/Makefile2:2081: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/rule'
> failed
> make[1]: *** [bindings/tcl/CMakeFiles/pltcl.dir/rule] Error 2
> Makefile:845: recipe for target 'pltcl' failed
> make: *** [pltcl] Error 2
>
> I am virtually positive you will be able to confirm build issues with pltcl for MSVC as
> well for the same reason (no symbols exported from libplplottcltk).
>
> Such build issues interfere with those trying to follow the master branch so I have
> reverted your change as a temporary emergency measure (commit ca170c0).
>
> However, I think the only problem with your commit may be that you used too large
> a hammer (i.e., disabled all symbol visibility) to disable the visibility of the
> plplotLibDir symbol within libplplottcltk.
>
> Therefore, in a follow up commit (bbff8af) I tried disabling just the visibility of the
> plplotLibDir symbol within libplplottcltk.  That change causes no build issues on
> Linux.  Does that also fix the build issue on MSVC?
>
> Note my tests of bbff8af discovered a recently introduced matrix size issue with
> plpat for example 15 under Tcl, and when I locally disabled plpat to get by that error
> then there was an additional such issue (I have forgotten for which command) for
> example 18.  (By the way, unlike what you intended these were actual errors
> concerning matrix size incompatibility rather than just warnings.) My Tcl abilities are
> not sufficient for solving these matrix size issues so I rely on you to do that. Note to
> find all such issues you must systematically exercise every Tcl example on MSVC
> by hand or else build the test_pltcl_standard_examples target on Cygwin,
> MinGW/MSYS, MinGW-w64/MSYS2, or Linux.
>



I will deal with the examples later - I discovered a flaw in example x01.tcl - a mismatch between the declared size (101) and the actually used size (100) that popped when I removed the (almost) superfluous size argument.



With the current source code as per your visibility change for plplotLibDir I get this again:


[ 13%] Linking C shared library ..\..\dll\plplottcltk.dll

   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp

tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir ..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals

LINK Pass 1 failed. with 1120

NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.



I will have to carefully unravel this mystery, but I am not sure that I will have time to complete that task before the end of the week (that is: before my holiday).



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.

Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far

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

On 2016-02-11 12:40-0800 Alan W. Irwin wrote:

> On 2016-02-11 13:51-0000 Arjen Markus wrote:
>
>> Hi Alan,
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Sent: Thursday, February 11, 2016 10:39 AM
>>> To: PLplot development list
>>> Subject: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>>>
>>> A bad efficiency regression in CMake-3.5.0-rc1 and a whole host of other 3.5 issues
>>> got fixed for CMake-3.5.0-rc2 so I decided to test that CMake version by doing a
>>> complete comprehensive PLplot test (except the interactive part was dropped so I
>>> wouldn't have to babysit the test).
>>>
>>> That noninteractive comprehensive PLplot test of CMake-3.5.0-rc2 worked
>>> flawlessly on Linux just like CMake versions 3.3.2 and 3.4.3 did before this test. So
>>> I urge you all to try 3.4.3 now (especially on non-Linux platforms since as noted
>>> yesterday a bump to that minimum version for those platforms is imminent [i.e.,
>>> soon after both Cygwin and MinGW-w64/MSYS2 provide that version of cmake])
>>> and also try 3.5.0 as soon as that finalized version is released.  And please share
>>> those good or bad results for your various platforms with this list to give us all a
>>> better idea of the reliability of the various CMake versions on various platforms.
>>>
>>
>>
>> I have now Cmake 3.4.3 for Windows (should be useable under MingW as well as bare Windows), but after correcting the plplotf95_ifort.def file I ran into a problem with Tcl:
>>
>> tclAPI.c
>>
>> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(792) : warning C4996: '_getcwd': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _getcwd. See online help for details.
>>
>>        C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\direct.h(59) : see declaration of '_getcwd'
>>
>> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(3783) : warning C4101: 'argc' : unreferenced local variable
>>
>> [ 13%] Linking C shared library ..\..\dll\plplottcltk.dll
>>
>>   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp
>>
>> tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir
>>
>> ..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals
>>
>> LINK Pass 1 failed. with 1120
>>
>> NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'
>>
>> Stop.
>>
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>>
>> Stop.
>>
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>>
>> Stop.
>>
>> The problem is not the message about _getcwd(), but the linkage of plplotLibDir. I haven't analysed the problem in sufficient detail to really understand what is going and why it worked before, but my current guess - and that is a guess, no more - is that the macros that are defined cause the relevant macro PLDLLIMPEXP_TCLTK_DATA( type ) to be defined as "export" instead of "import".
>>
>> More to follow.
>
> Hi Arjen:
>
> Could you check if this is really a CMake-3.4.3 issue?  That is if you
> run the exact same test with CMake-3.3.2 does that solve it? Or does
> that linker error persist for both cases presumably due to a long-term
> MSVC visibility issue for the combination of libplplottcltk and libplplot?
>
> The reason I suspect the latter case is the only way I can see that
> the CMake version affects our visibility implementation is if there is
> an an unlikely CMake regression in the way that include/pldll.h(.in)
> is configured or an unlikely regression in the way that CMake emits
> the plplot_EXPORTS macro when compiling libplplot and the
> plplottcltk_EXPORTS when compiling libplplottcltk.  Furthermore, the
> linker only gave an error message for one symbol, plplotLibDir.  That
> is, visibility seems OK for everything but plplotLibDir.  Also
>
> software@raven> find . -type f |grep -v .git |xargs grep -l plplotLibDir
>
> tells me that symbol only occurs in
>
> ./bindings/tcl/tclAPI.c
> ./src/plctrl.c
>
> in our source code.  If I understand the purpose of plplotLibDir
> correctly, it allows libtcltk to get plLibOpenPdfstrm within libplplot
> to open a particular file.
>
> Anyhow, the visibility of plplotLibDir is implemented in an extremely
> unique way in _both_ the above files, and it appears to me the use of
> different _forms_ of visibility macros (i.e., PLDLLIMPEXP_TCLTK_DATA
> in the former case and PLDLLIMPEXP in the latter case) is problematic
> as well.

Hi Arjen:

Your recent (commit b94370e) fix for the above issue cannot be correct
since it blocks all symbols from being exported from libplplottcltk
which makes that library useless.  So, for example, the result on
Linux with

CFLAGS=-O3 -fvisibility=hidden -Wuninitialized

is

software@raven> nm --defined-only --extern-only bindings/tcl/libplplottcltk.so
0000000000234d34 B __bss_start
0000000000234d34 D _edata
0000000000236480 B _end
00000000000290f4 T _fini
0000000000007730 T _init

i.e., no symbols relevant to PLplot are available from that
library as the direct result of your change.  This problem in turn generates build errors such as

[...]
[100%] Linking C executable pltcl
CMakeFiles/pltcl.dir/pltcl.c.o: In function `AppInit':
pltcl.c:(.text+0x14a): undefined reference to `Pltcl_Init'
collect2: error: ld returned 1 exit status
bindings/tcl/CMakeFiles/pltcl.dir/build.make:99: recipe for target 'bindings/tcl/pltcl' failed
make[3]: *** [bindings/tcl/pltcl] Error 1
CMakeFiles/Makefile2:2069: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/all' failed
make[2]: *** [bindings/tcl/CMakeFiles/pltcl.dir/all] Error 2
CMakeFiles/Makefile2:2081: recipe for target 'bindings/tcl/CMakeFiles/pltcl.dir/rule' failed
make[1]: *** [bindings/tcl/CMakeFiles/pltcl.dir/rule] Error 2
Makefile:845: recipe for target 'pltcl' failed
make: *** [pltcl] Error 2

I am virtually positive you will be able to confirm build issues with
pltcl for MSVC as well for the same reason (no symbols exported from
libplplottcltk).

Such build issues interfere with those trying to follow the master
branch so I have reverted your change as a temporary emergency
measure (commit ca170c0).

However, I think the only problem with your commit may be that you
used too large a hammer (i.e., disabled all symbol visibility) to disable
the visibility of the plplotLibDir symbol within libplplottcltk.

Therefore, in a follow up commit (bbff8af) I tried disabling just the
visibility of the plplotLibDir symbol within libplplottcltk.  That
change causes no build issues on Linux.  Does that also fix the
build issue on MSVC?

Note my tests of bbff8af discovered a recently introduced matrix size
issue with plpat for example 15 under Tcl, and when I locally disabled
plpat to get by that error then there was an additional such issue (I
have forgotten for which command) for example 18.  (By the way, unlike
what you intended these were actual errors concerning matrix size
incompatibility rather than just warnings.) My Tcl abilities are not
sufficient for solving these matrix size issues so I rely on you to do
that. Note to find all such issues you must systematically exercise
every Tcl example on MSVC by hand or else build the
test_pltcl_standard_examples target on Cygwin, MinGW/MSYS,
MinGW-w64/MSYS2, or Linux.

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] CMake-3.5.x works flawlessly on Linux so far

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

On 2016-02-11 13:51-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Thursday, February 11, 2016 10:39 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>>
>> A bad efficiency regression in CMake-3.5.0-rc1 and a whole host of other 3.5 issues
>> got fixed for CMake-3.5.0-rc2 so I decided to test that CMake version by doing a
>> complete comprehensive PLplot test (except the interactive part was dropped so I
>> wouldn't have to babysit the test).
>>
>> That noninteractive comprehensive PLplot test of CMake-3.5.0-rc2 worked
>> flawlessly on Linux just like CMake versions 3.3.2 and 3.4.3 did before this test. So
>> I urge you all to try 3.4.3 now (especially on non-Linux platforms since as noted
>> yesterday a bump to that minimum version for those platforms is imminent [i.e.,
>> soon after both Cygwin and MinGW-w64/MSYS2 provide that version of cmake])
>> and also try 3.5.0 as soon as that finalized version is released.  And please share
>> those good or bad results for your various platforms with this list to give us all a
>> better idea of the reliability of the various CMake versions on various platforms.
>>
>
>
> I have now Cmake 3.4.3 for Windows (should be useable under MingW as well as bare Windows), but after correcting the plplotf95_ifort.def file I ran into a problem with Tcl:
>
> tclAPI.c
>
> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(792) : warning C4996: '_getcwd': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _getcwd. See online help for details.
>
>        C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\direct.h(59) : see declaration of '_getcwd'
>
> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(3783) : warning C4101: 'argc' : unreferenced local variable
>
> [ 13%] Linking C shared library ..\..\dll\plplottcltk.dll
>
>   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp
>
> tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir
>
> ..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals
>
> LINK Pass 1 failed. with 1120
>
> NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> The problem is not the message about _getcwd(), but the linkage of plplotLibDir. I haven't analysed the problem in sufficient detail to really understand what is going and why it worked before, but my current guess - and that is a guess, no more - is that the macros that are defined cause the relevant macro PLDLLIMPEXP_TCLTK_DATA( type ) to be defined as "export" instead of "import".
>
> More to follow.

Hi Arjen:

Could you check if this is really a CMake-3.4.3 issue?  That is if you
run the exact same test with CMake-3.3.2 does that solve it? Or does
that linker error persist for both cases presumably due to a long-term
MSVC visibility issue for the combination of libplplottcltk and libplplot?

The reason I suspect the latter case is the only way I can see that
the CMake version affects our visibility implementation is if there is
an an unlikely CMake regression in the way that include/pldll.h(.in)
is configured or an unlikely regression in the way that CMake emits
the plplot_EXPORTS macro when compiling libplplot and the
plplottcltk_EXPORTS when compiling libplplottcltk.  Furthermore, the
linker only gave an error message for one symbol, plplotLibDir.  That
is, visibility seems OK for everything but plplotLibDir.  Also

software@raven> find . -type f |grep -v .git |xargs grep -l plplotLibDir

tells me that symbol only occurs in

./bindings/tcl/tclAPI.c
./src/plctrl.c

in our source code.  If I understand the purpose of plplotLibDir
correctly, it allows libtcltk to get plLibOpenPdfstrm within libplplot
to open a particular file.

Anyhow, the visibility of plplotLibDir is implemented in an extremely
unique way in _both_ the above files, and it appears to me the use of
different _forms_ of visibility macros (i.e., PLDLLIMPEXP_TCLTK_DATA
in the former case and PLDLLIMPEXP in the latter case) is problematic
as well.

Linux tests of visibility that are normally made as part of my routine
testing on that platform are less demanding than the equivalent MSVC
tests. So if it turns out this is a long-term MSVC visibility issue
between libplottcltk and libplplot, I would carefully review the
plplotLibDir visibility implementation in the above two files to see
what might be problematic with it for the MSVC case.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, February 11, 2016 10:39 AM
> To: PLplot development list
> Subject: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>
> A bad efficiency regression in CMake-3.5.0-rc1 and a whole host of other 3.5 issues
> got fixed for CMake-3.5.0-rc2 so I decided to test that CMake version by doing a
> complete comprehensive PLplot test (except the interactive part was dropped so I
> wouldn't have to babysit the test).
>
> That noninteractive comprehensive PLplot test of CMake-3.5.0-rc2 worked
> flawlessly on Linux just like CMake versions 3.3.2 and 3.4.3 did before this test. So
> I urge you all to try 3.4.3 now (especially on non-Linux platforms since as noted
> yesterday a bump to that minimum version for those platforms is imminent [i.e.,
> soon after both Cygwin and MinGW-w64/MSYS2 provide that version of cmake])
> and also try 3.5.0 as soon as that finalized version is released.  And please share
> those good or bad results for your various platforms with this list to give us all a
> better idea of the reliability of the various CMake versions on various platforms.
>


I have now Cmake 3.4.3 for Windows (should be useable under MingW as well as bare Windows), but after correcting the plplotf95_ifort.def file I ran into a problem with Tcl:

tclAPI.c

D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(792) : warning C4996: '_getcwd': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _getcwd. See online help for details.

        C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\direct.h(59) : see declaration of '_getcwd'

D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(3783) : warning C4101: 'argc' : unreferenced local variable

[ 13%] Linking C shared library ..\..\dll\plplottcltk.dll

   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp

tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir

..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals

LINK Pass 1 failed. with 1120

NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

The problem is not the message about _getcwd(), but the linkage of plplotLibDir. I haven't analysed the problem in sufficient detail to really understand what is going and why it worked before, but my current guess - and that is a guess, no more - is that the macros that are defined cause the relevant macro PLDLLIMPEXP_TCLTK_DATA( type ) to be defined as "export" instead of "import".

More to follow.

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-devel] CMake-3.5.x works flawlessly on Linux so far

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

A bad efficiency regression in CMake-3.5.0-rc1 and a whole host of
other 3.5 issues got fixed for CMake-3.5.0-rc2 so I decided to test that
CMake version by doing a complete comprehensive PLplot test (except
the interactive part was dropped so I wouldn't have to babysit the test).

That noninteractive comprehensive PLplot test of CMake-3.5.0-rc2
worked flawlessly on Linux just like CMake versions 3.3.2 and 3.4.3
did before this test. So I urge you all to try 3.4.3 now (especially
on non-Linux platforms since as
noted yesterday a bump to that minimum version for those platforms
is imminent [i.e., soon after both Cygwin and MinGW-w64/MSYS2 provide
that version of cmake]) and also try 3.5.0 as soon as that finalized
version is released.  And please share those good or bad results for
your various platforms with this list to give us all a better idea of
the reliability of the various CMake versions on various platforms.

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] CMake minimum version has just been bumped

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

After thinking about this issue some more I have decided to adopt
for the short term a minimum CMake version of 3.0.2 for Linux, and
3.3.2 for all other platforms. See
<http://sourceforge.net/p/plplot/plplot/ci/3ece747fbb1d1da888abff7a9b486834a538e719>
for the rules of thumb for Linux and non-Linux platforms which lead me
to this choice.

N.B. According to those rules of thumb I will be bumping the minimum
version for the non-Linux platform case from 3.3.2 to 3.4.3 fairly
soon after both Cygwin and MinGW-w64 provide that latter version.

Thus, that next bump will likely occur within a few weeks since the
time between released matured versions of CMake (e.g., 3.3.2 to 3.4.3)
is typically 3 months and both Cygwin and MinGW-w64 (both of which
provide rolling releases) provided CMake-3.3.2 in late October.

Given that 3.4.3 is flawless from the perspective of PLplot on Linux
and given that I will likely want to bump (on non-Linux platforms)
from 3.3.2 to 3.4.3 fairly soon, I would appreciate it if everyone
gives 3.4.3 a try here to make sure it works as well or better for
them than 3.3.2 on the platforms you have access to.

The principal reason I am forcing the pace on keeping close to the
latest matured minor release of CMake-3 is my judgement that major
CMake release series is already mature on Linux and finally beginning
to mature on non-Linux platforms.  What I mean by that latter
statement is each matured minor release in that major series (e.g.,
3.3.2 and 3.4.3) is actually a significant improvement over previous
matured minor releases for non-Linux platforms. I base this judgement
on the large amount of effort I see on the cmake-devel list that is
devoted to maintaining and improving the various non-Linux platforms.
Thus, in my view keeping close to the latest matured minor release
should significantly help our users on non-Linux platforms and keep
build-system issues encountered by such users _a lot_ simpler for me
to diagnose since if they use 3.3.2 it reduces the chance that the
issue is due to CMake, and that chance is likely to be reduced still
more as they progress to 3.4.3, 3.5.<matured>, 3.6.<matured>, etc.
However, this is just an informed guess, and if any of you find that
3.4.3 is actually worse than 3.3.2 on any of the platforms of interest
to you, please let me know in a hurry.

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] Am I using eop() or abusing it?

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

Thanks for the update. I will see if I can fix it. It appears that the message handling loop is not handling some of the messages because it is in the wrong state. I haven't tested the case with rapid window creation. 

On Feb 8, 2016, at 3:11 PM, Greg Jung <gv...@gm...> wrote:

>> The new wingdi has a much more robust handling of redraws and resizes, primarily because it closely follows the Windows API documentation. I remember that the wingcc driver was not very smart about creating the bitmap and I had to crack open the documentation on how to do it the “right” (where “right” is relative to the Windows API and not PLplot’s state).  What I think is happening in the wingdi driver is that the additional draws are triggering a new bitmap independent of the EOP call.
> I compared the two w.r.t. their bitmap creation/storage and it looks the same.  
> Anyway, I inserted the eop() call instead into the ->Update() call which was
> doing nothing in the win case, so I limited the side-effects to that driver.
> 
> In the wingdi case I was getting failures to display in the case where multiple plots/multiple 
> windows were created in rapid succession.  The plots appeared when the window was moved or re-sized,
> but I generally got only a single plot of six nominal plots (axes, titles, and a line).  With the 
> eop() call inserted, now, that defect goes away! The only side effect is the rgb+plot test
> that needed the plP_bop() removal from rdbuff_bop to work, needs a move or resize before it shows
>  correctly (same side-effect for wingcc). 
>  Given the hackish nature of the RGB implementation, I can live with that.
> <image.png>
> (I moved and resized the plot on the left to unveil the RGB picture portion.  The right side
> window is as-plotted: 5 sub-plots do not show before re-sizing)
> 
> <image.png>
>  The wingdi driver ran the "testfocus" test without error - all plots were displayed without
> mouse interference. This due to insertion of ->eop() call in ->Update(), which is called after
> each GDL plot routine.  Without the ->eop(), only one plot would show until the window
> was moved.
> 
>> On Sun, Feb 7, 2016 at 8:22 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>>> On Feb 7, 2016, at 1:44 AM, Greg Jung <gv...@gm...> wrote:
>>> 
>>> GDL has had a problem in its use of the wingcc driver in that,
>>> plotting additions to a basic PLOT call do not stick to the plot
>>>  when it is moved or resized.  I've found that when I stick another
>>> eop() call after each of these plot calls, the problem is "solved"
>>> for this driver https://sourceforge.net/p/gnudatalanguage/bugs/689/#b1d7
>>> because each eop() in wingcc induces another copy of the screen to the 
>>>  bitmap used for refresh.
>>> 
>>>   Jim's new wingdi driver doesn't have this issue although I can't see why not.
>> 
>> What is happening is that plplot is generating the bitmap used for redraws before your GDL additions to the window.  The second EOP call is forcing the creation of a new bitmap, which has the GDL additions.
>> 
>> The new wingdi has a much more robust handling of redraws and resizes, primarily because it closely follows the Windows API documentation. I remember that the wingcc driver was not very smart about creating the bitmap and I had to crack open the documentation on how to do it the “right” (where “right” is relative to the Windows API and not PLplot’s state).  What I think is happening in the wingdi driver is that the additional draws are triggering a new bitmap independent of the EOP call.
>> 
>>> According to the plplot-5.10 doc, eop() would close a plot file begun when bop()
>>> is called.  Currently rdbuf_eop() is a no-op although there is an EOP code put 
>>> into the plot buffer.
>> 
>> A lot of the EOP handling happens outside of the rdbuf_eop(), which is why that function is a no-op.
>> 
>>> 
>>> My happy answer would be that a second eop() without bop() indicates a re-open, "append" to the ongoing plot buffer (or file).  Is that consistent with current usage?
>> 
>> For an interactive driver like wingcc and xwin, I think the primary problem is that you would lose everything after the first EOP when the buffer is replayed.  That can happen in the wingcc driver in a WM_PAINT message if plplot is waiting for input and there is not a valid bitmap for a redraw.  You may be fortunate that the second EOP is creating a valid bitmap, thus avoiding the buffer playback.
>> 
>>> Thanks, 
>>> Greg
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] Am I using eop() or abusing it?

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

>
> The new wingdi has a much more robust handling of redraws and resizes,
> primarily because it closely follows the Windows API documentation. I
> remember that the wingcc driver was not very smart about creating the
> bitmap and I had to crack open the documentation on how to do it the
> “right” (where “right” is relative to the Windows API and not PLplot’s
> state).  What I think is happening in the wingdi driver is that the
> additional draws are triggering a new bitmap independent of the EOP call.
>
> I compared the two w.r.t. their bitmap creation/storage and it looks the
same.
Anyway, I inserted the eop() call instead into the ->Update() call which was
doing nothing in the win case, so I limited the side-effects to that driver.

In the wingdi case I was getting failures to display in the case where
multiple plots/multiple
windows were created in rapid succession.  The plots appeared when the
window was moved or re-sized,
but I generally got only a single plot of six nominal plots (axes, titles,
and a line).  With the
eop() call inserted, now, that defect goes away! The only side effect is
the rgb+plot test
that needed the plP_bop() removal from rdbuff_bop to work, needs a move or
resize before it shows
 correctly (same side-effect for wingcc).
 Given the hackish nature of the RGB implementation, I can live with that.
[image: Inline image 1]
(I moved and resized the plot on the left to unveil the RGB picture
portion.  The right side
window is as-plotted: 5 sub-plots do not show before re-sizing)

[image: Inline image 3]
 The wingdi driver ran the "testfocus" test without error - all plots were
displayed without
mouse interference. This due to insertion of ->eop() call in ->Update(),
which is called after
each GDL plot routine.  Without the ->eop(), only one plot would show until
the window
was moved.

On Sun, Feb 7, 2016 at 8:22 PM, Jim Dishaw <ji...@di...> wrote:

>
> On Feb 7, 2016, at 1:44 AM, Greg Jung <gv...@gm...> wrote:
>
> GDL has had a problem in its use of the wingcc driver in that,
> plotting additions to a basic PLOT call do not stick to the plot
>  when it is moved or resized.  I've found that when I stick another
> eop() call after each of these plot calls, the problem is "solved"
> for this driver https://sourceforge.net/p/gnudatalanguage/bugs/689/#b1d7
> because each eop() in wingcc induces another copy of the screen to the
>  bitmap used for refresh.
>
>   Jim's new wingdi driver doesn't have this issue although I can't see why
> not.
>
>
> What is happening is that plplot is generating the bitmap used for redraws
> before your GDL additions to the window.  The second EOP call is forcing
> the creation of a new bitmap, which has the GDL additions.
>
> The new wingdi has a much more robust handling of redraws and resizes,
> primarily because it closely follows the Windows API documentation. I
> remember that the wingcc driver was not very smart about creating the
> bitmap and I had to crack open the documentation on how to do it the
> “right” (where “right” is relative to the Windows API and not PLplot’s
> state).  What I think is happening in the wingdi driver is that the
> additional draws are triggering a new bitmap independent of the EOP call.
>
> According to the plplot-5.10 doc, eop() would close a plot file begun when
> bop()
> is called.  Currently rdbuf_eop() is a no-op although there is an EOP code
> put
> into the plot buffer.
>
>
> A lot of the EOP handling happens outside of the rdbuf_eop(), which is why
> that function is a no-op.
>
>
> My happy answer would be that a second eop() without bop() indicates a
> re-open, "append" to the ongoing plot buffer (or file).  Is that consistent
> with current usage?
>
>
> For an interactive driver like wingcc and xwin, I think the primary
> problem is that you would lose everything after the first EOP when the
> buffer is replayed.  That can happen in the wingcc driver in a WM_PAINT
> message if plplot is waiting for input and there is not a valid bitmap for
> a redraw.  You may be fortunate that the second EOP is creating a valid
> bitmap, thus avoiding the buffer playback.
>
> Thanks,
> Greg
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
>

Re: [Plplot-devel] Uniformly coloured semitransparent backgrounds

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

On 2016-02-08 10:44-0000 Phil Rosenberg wrote:

> The wxWidgets drivers certainly does as you say - it's response to
> plclear is to simply draw a rectangle of the appropriate colour. If
> that colour was transparent then I think we end up drawing over some
> default window background which I think is black, but I'm not sure -
> perhaps it depends on the window type, and it may even be unassigned
> memory.
>
> I can go with the idea of transparent windows - I have just checked
> and wxWidgets does have the capability to do transparent windows - we
> will see how well tested that code is I guess.
>
> Would you be interested in writing an example (prefereably multipaged)
> Alan? Perhaps this could just be one of the existing examples with a
> transparent background or a flag for transparent backgrounds. I will
> then try and get the wxWidgets driver to do as it should for that
> example.

I suggest example 9 because I know that that already works (see below). All
you have to do is use the command line -bg option which is documented
(using the -h command-line option) as

-bg color            Background color (FF0000=opaque red, 0000FF_0.1=blue with alpha of 0.1)


So I tried

examples/c/x08c -dev pdfqt -bg FF0000_0.0 -fam -o test.pdf

I got the expected result (transparent background as indicated by a
checkerboard pattern for the ImageMagick display programme) for all 5
pages of that example, i.e., test.pdf.[1-5].  In other words, transparent
backgrounds are working properly for the qt file devices.

On the other hand, if I run

examples/c/x09c -dev qtwidget -bg FF0000_0.0

I do not get the expected result; each page had an opaque red
background inserted rather than the specified transparent one.  So I
expect something special is being done to ignore background
transparency in that particular qt device that is not done for the
corresponding qt file devices.  I am tied up with something else at
the moment, but I will attempt to fix that in the next week or so if
you don't beat me to it.

Once you implement the alpha channel properly for wxwidgets
backgrounds, then

examples/c/x09c -dev wxwidgets -bg FF0000_0.0

should show all the pages stacked on top of each other for our current
"stack of pages" interactive model (which you have advocated changing
to an individual page model which I think is a good idea). But for the
present interactive model if you specify some intermediate alpha like

examples/c/x09c -dev wxwidgets -bg FF0000_0.2

then if the alpha channel is implemented properly for wxwidgets
backgrounds, there should be "interesting" successive fading caused by
each additional semitransparent layer as you look down through the
stack of pages that will be displayed.

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] Uniformly coloured semitransparent backgrounds

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

> I do agree that just as with the IM display GUI, there would be
> external factors (such as bad compositing for your desktop display)
> that might or might not allow this to work, but sometimes it does work
> (i.e., the user can get a cool effect where they create an interactive
> plot on a semitransparent background where they could see through the
> plot to some details from the underlying desktop). This already
> happens for the display of file devices (at least those which conform
> to the above model).  So if users have this desire, I don't think our
> library should get in the way just in case the user has external
> factors that allow this to work.  And I don't think there is much
> downside to this approach; that is "not working due to external
> factors" here means that the background is opaque or a checkerboard
> rather than the plot does not work at all.
>

> So I now think the interactive model should be that there is a canvas
> provided which could be an opaque rectangle of a given color, an
> image, text, or even (I argue above) the current desktop display.
> Anyhow, our library should not care a bit about the nature of that
> canvas and for each interactive page it should simply start with that
> canvas, lay down a semitransparent background, and then render the
> rest of the plot commands for the page.
>
> My impression is that currently our interactive device drivers don't
> follow this model at all for multiple pages and instead simply render
> a background (on the incorrect assumption it is always opaque) to
> overlay previous pages.  So moving from this model to the one above is
> going to be a significant amount of work for each device driver, but I
> think such work would be extremely worthwhile if we come to consensus
> that the above interactive model is what we want.
>

The wxWidgets drivers certainly does as you say - it's response to
plclear is to simply draw a rectangle of the appropriate colour. If
that colour was transparent then I think we end up drawing over some
default window background which I think is black, but I'm not sure -
perhaps it depends on the window type, and it may even be unassigned
memory.

I can go with the idea of transparent windows - I have just checked
and wxWidgets does have the capability to do transparent windows - we
will see how well tested that code is I guess.

Would you be interested in writing an example (prefereably multipaged)
Alan? Perhaps this could just be one of the existing examples with a
transparent background or a flag for transparent backgrounds. I will
then try and get the wxWidgets driver to do as it should for that
example.

[Plplot-devel] The wingdi driver

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

Greg’s email about the additional EOP call made me think that it might be time to offer the wingdi driver for beta testing.  What would be the best way to do that?

Re: [Plplot-devel] Am I using eop() or abusing it?

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

> On Feb 7, 2016, at 1:44 AM, Greg Jung <gv...@gm...> wrote:
> 
> GDL has had a problem in its use of the wingcc driver in that,
> plotting additions to a basic PLOT call do not stick to the plot
>  when it is moved or resized.  I've found that when I stick another
> eop() call after each of these plot calls, the problem is "solved"
> for this driver https://sourceforge.net/p/gnudatalanguage/bugs/689/#b1d7 <https://sourceforge.net/p/gnudatalanguage/bugs/689/#b1d7>
> because each eop() in wingcc induces another copy of the screen to the 
>  bitmap used for refresh.
> 
>   Jim's new wingdi driver doesn't have this issue although I can't see why not.
> 

What is happening is that plplot is generating the bitmap used for redraws before your GDL additions to the window.  The second EOP call is forcing the creation of a new bitmap, which has the GDL additions.

The new wingdi has a much more robust handling of redraws and resizes, primarily because it closely follows the Windows API documentation. I remember that the wingcc driver was not very smart about creating the bitmap and I had to crack open the documentation on how to do it the “right” (where “right” is relative to the Windows API and not PLplot’s state).  What I think is happening in the wingdi driver is that the additional draws are triggering a new bitmap independent of the EOP call.

> According to the plplot-5.10 doc, eop() would close a plot file begun when bop()
> is called.  Currently rdbuf_eop() is a no-op although there is an EOP code put 
> into the plot buffer.

A lot of the EOP handling happens outside of the rdbuf_eop(), which is why that function is a no-op.

> 
> My happy answer would be that a second eop() without bop() indicates a re-open, "append" to the ongoing plot buffer (or file).  Is that consistent with current usage?

For an interactive driver like wingcc and xwin, I think the primary problem is that you would lose everything after the first EOP when the buffer is replayed.  That can happen in the wingcc driver in a WM_PAINT message if plplot is waiting for input and there is not a valid bitmap for a redraw.  You may be fortunate that the second EOP is creating a valid bitmap, thus avoiding the buffer playback.

> Thanks, 
> Greg
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake minimum version has just been bumped

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

On 2016-02-07 12:29-0800 Greg Jung wrote:

> The platform where bugs are appearing is MSVC because of the new OS.

Hi Greg:

There were clearly some MSVC bugs in immature versions of both 3.3 and
3.4 so that is why I avoid such immature versions when setting the
minimum version.  So the current choices are just 3.3.2 or 3.4.3. My
further impression from following both the cmake and cmake-devel lists
is that MSVC works better for 3.4.3 than it does for 3.3.2, i.e., over
time the MSVC support is greatly improving, but I obviously don't have
any hands-on MSVC experience in that regard.

> I'm pretty sure 3.4.3, without modifications, will break in plplot
> comprehensive
> on my 'puter when it picks up a windows' pythonlib from the registry.

I am virtually positive there is a way around the issue of finding your
desired Python version with vanilla CMake even on Windows platforms.
For example,
$install_prefix/share/cmake-3.4/Modules/FindPythonLibs.cmake
says:

# If you'd like to specify the installation of Python to use, you should
# modify the following cache variables:
#
# ::
#
#   PYTHON_LIBRARY             - path to the python library
#   PYTHON_INCLUDE_DIR         - path to where Python.h is found

i.e., use the cmake command-line options
-DPYTHON_LIBRARY:PATH=whatever -DPYTHON_INCLUDE_DIR:PATH=whichever

So I would strongly advise you to use that solution as opposed
to hacking CMake itself to make your life with regard to cmake
upgrades much easier.

>
> I have already given 3.4.3 a pretty
>>
>> good thrashing on Linux so I expect there is an excellent chance it
>> will be reliable for all your various platform needs as well.
>
> Of course, Linux is the worst test because it is most likely to be
> compliant,
> the most tested and consistent.   The minority case uses are where issues
> are more likely to arise.

That is a very good point.  And I am also concerned with Mac OS X
users as well who will be affected by this change. So I now realize I
got ahead of myself and before doing the bump I should have encouraged
all here to test 3.4.3 on platforms of interest to them.

Thus, I am currently leaning toward reverting this change for say the
next 3 months while users do such testing.

I would also like to hear from other MSVC users and also Mac OS X
users about what ideal schedule they would like to see for bumping the
minimum version, e.g., once each CMake minor version matures (i.e.,
cmake-3.4.3, cmake-3.5.last, cmake-3.6.last, ...) or once every other
CMake minor version matures (cmake-3.4.3, cmake-3.6.last,
cmake-3.8.last, ...)?

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] CMake minimum version has just been bumped

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

Hi all,
Alan>

> Anyhow, I don't think we are asking too much of our MSVC users (and
> users of other platforms without a coherent free software
> distribution) to download or build CMake every 3 months or so as
> 3.3.z, 3.4.z, etc., mature. Note, I am not asking you to do that for
> your Linux and Cygwin platforms, and I could add MinGW-w64/MSYS2 to
> the list of platforms where 3.0.2 is the minimum version as well if
> you think that is desirable.
>

The platform where bugs are appearing is MSVC because of the new OS.
MSYS2, rabid advocates of bleeding edge, only has 3.4.1 to-date for mingw,
3.2.3 for the posix cmake (which includes a lot of patching of .cmake files
as
well as a special runtime).

> Alan:

> So my question for you is do you really think it is going to be that
> onerous for you to move from 3.3.2 to 3.4.3 just for MSVC and
> classical MinGW/MSYS? After all, ...


I'm pretty sure 3.4.3, without modifications, will break in plplot
comprehensive
on my 'puter when it picks up a windows' pythonlib from the registry.
So I would have to fix 3.4 again, re-make the directory links, etc.
 It may not be onerous but If its not relevant I'd rather not tinker with
it.

I have already given 3.4.3 a pretty
>
> good thrashing on Linux so I expect there is an excellent chance it
> will be reliable for all your various platform needs as well.

Of course, Linux is the worst test because it is most likely to be
compliant,
the most tested and consistent.   The minority case uses are where issues
are more likely to arise.

On Sun, Feb 7, 2016 at 3:41 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2016-02-06 23:09-0800 Greg Jung wrote:
>
> I'd like to make a pitch for maintaining a lower general cmake minimum
>
>

>
>>
> Finally, note that if you convince me to go with the second latest
> mature version (i.e., 3.3.2 now rather than 3.4.3) it will give you a
> 3-month break, but then after that, keeping up with second latest
> mature version will still require you to build/download CMake every 3
> months or so.  So why not go with latest mature rather than second
> latest if they are essentially going to be the same trouble for you?
>
> When I upgrade I'll want to go to a version well ahead of the minimum.

Regards,
Greg

Re: [Plplot-devel] Uniformly coloured semitransparent backgrounds

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

On 2016-02-07 13:25-0000 Phil Rosenberg wrote:

> There is plenty of cool stuff there, but remembering that plplot is
a library and not an application our job should be to enable
transparency and allow the user to do that cool stuff - but that might
form the basis of a demo.

Agreed.

> For file output, it should just be like a
transparent/semitransparent rectangle was drawn over the page as the
first render object.

Agreed, but I believe that is the current model in any case, i.e., it
is a bug if a file device does not follow that model.

> For drivers where the user provides the canvas, things should be
just as for file output. This would allow users to draw over existing
items - I'm thinking, e.g. A report program that includes text and
provides this dc to plplot to draw plots on too.

Agreed.

> For interactive drivers where the user does not provide the canvas I
am not sure what to do. In this case I think the most appropriate
thing is to ignore transparency. I don't think making the window
transparent is appropriate as it will just generate lots of driver and
platform dependant inconsistencies.

I do agree that just as with the IM display GUI, there would be
external factors (such as bad compositing for your desktop display)
that might or might not allow this to work, but sometimes it does work
(i.e., the user can get a cool effect where they create an interactive
plot on a semitransparent background where they could see through the
plot to some details from the underlying desktop). This already
happens for the display of file devices (at least those which conform
to the above model).  So if users have this desire, I don't think our
library should get in the way just in case the user has external
factors that allow this to work.  And I don't think there is much
downside to this approach; that is "not working due to external
factors" here means that the background is opaque or a checkerboard
rather than the plot does not work at all.

> Regarding page clears. I feel that a new page is a new page and
should not show previous pages in the background. Presumably this is
dealt with by new files or document pages in many cases. If users want
to simulate this effect they can do so themselves using plclear calls
with semitransparent background colours.

You are right.  So never mind on that idea of mine of overlaying pages
together with semintransparent background between.

So I now think the interactive model should be that there is a canvas
provided which could be an opaque rectangle of a given color, an
image, text, or even (I argue above) the current desktop display.
Anyhow, our library should not care a bit about the nature of that
canvas and for each interactive page it should simply start with that
canvas, lay down a semitransparent background, and then render the
rest of the plot commands for the page.

My impression is that currently our interactive device drivers don't
follow this model at all for multiple pages and instead simply render
a background (on the incorrect assumption it is always opaque) to
overlay previous pages.  So moving from this model to the one above is
going to be a significant amount of work for each device driver, but I
think such work would be extremely worthwhile if we come to consensus
that the above interactive model is what we want.

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
__________________________