plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Results of the comprehensive test on Cygwin

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

Hi Alan,



Please find the results of the comprehensive test on Cygwin using the latest version. It fails in the static build, using the installed examples, but the other configurations seem fine. So we are making progress. What is going wrong with the installed examples is, however, a mystery to me.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, May 18, 2015 9:58 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Spurious warnings on Cygwin should now be gone
>
> On 2015-05-18 06:56-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> > With the latest version the [Cygwin] warnings are indeed gone:
>
> Hi Arjen:
>
> It was good to hear that issue (and other more subtle/dangerous issues for which
> that spurious warning message was just one symptom) has finally been put to rest
> by the latest startup procedure.
>
> We are slowly but steadily getting there on the Cygwin platform, and I am most
> encouraged by that progress.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure
> Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

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

On 2015-05-18 06:56-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> With the latest version the [Cygwin] warnings are indeed gone:

Hi Arjen:

It was good to hear that issue (and other more subtle/dangerous
issues for which that spurious warning message was just one symptom)
has finally been put to rest by the latest startup procedure.

We are slowly but steadily getting there on the Cygwin platform, and
I am most encouraged by that progress.

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] Fedora plplot patches

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

Hi Hez:

Can you evaluate Patch7 below that removes the -custom option
from our ocamlc build commands?

@Orion and Andrew: the rest of this response is addressed to you
as our respective Fedora and Debian packagers.

On 2015-04-25 12:42-0600 Orion Poplawski wrote:

> On 04/25/2015 11:05 AM, Alan W. Irwin wrote:
>> While we are at it, are there any other general issues like this one
>> (i.e., issues likely to affect all distros) addressed by the Fedora
>> downstream patches which we should be aware of upstream?
>
> There are two other issues currently addressed downstream, which I'm pretty 
> sure I've raised here before.  The ocaml one relatively recently, not sure 
> about the multiarch one.
>
> Patch2:         plplot-multiarch.patch
>
> This allows for the "core" plplot package to be "multiarch" - exactly the 
> same content for 32-bit and 64-bit builds.  Otherwise the PKG_CONFIG_ENV and 
> RPATH variables have /usr/lib or /usr/lib64 in them.  I know this patch isn't 
> acceptable upstream as it is, but if you found a way to address it, that 
> would be great.

Patch2a: PKG_CONFIG_ENV

I have now (commit id 2b4e397) implemented a user-configurable location called
CMAKE_INSTALL_PKG_CONFIG_DIR where the PLplot *.pc files are
installed.  The default value for this cached variable is

$prefix/share/pkgconfig

which is apparently what Debian wheezy uses for multiarch *.pc files.

@Andrew: can you confirm that location for modern Debian?

@Orion: If that default location is not right for the Fedora multiarch
needs, try setting CMAKE_INSTALL_PKG_CONFIG_DIR on the cmake command
line.

Patch2b: RPATH

Use -DUSE_RPATH=OFF.  This should make all rpath results empty and the
RPATH part of Patch2 redundant.

@Orion:
In sum, with commit id 2b4e397 and the long-implemented USE_RPATH there
should no longer be any need for Patch2.  Please confirm that.

>
> # Don't use -custom with ocamlc
> Patch7:         plplot-ocaml.patch

I have left that patch attached because I don't have any OCaml expertise
to make an informed decision about whether to accept that upstream.
Our OCaml go-to guy here was Hezekiah M. Carty so I have CC'd him in
hopes that he will make the decision.

@ Andrew:
However, Hez has not been in contact for quite a while now so if he
doesn't respond would you be willing to make the decision (since I
believe your OCaml expertise no matter how small is still greater
than my own.  :-) ).

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] Spurious warnings on Cygwin should now be gone

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

Hi Alan,



With the latest version the warnings are indeed gone:

-- CMake version = 3.1.2

-- CMAKE_SYSTEM_NAME = CYGWIN

-- SH_EXECUTABLE = /usr/bin/bash.exe

-- Checking whether system has ANSI C header files

-- ANSI C header files - found

-- SWIG_VERSION = 2.0.12

-- WARNING: Perl module XML::DOM not found

-- Looking for pkg-config - found

-- X11_FOUND = 1

...



And the build completes without any errors. Now the comprehensive tests ...

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, May 15, 2015 11:04 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Spurious warnings on Cygwin should now be gone
>
> On 2015-05-15 13:45-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> > With this minimal CMakeLists.txt file:
> >
> >
> >
> > function(plplot_cmake_minimum_required)
> >
> >  cmake_minimum_required(${ARGV})
> >
> > endfunction(plplot_cmake_minimum_required)
> >
> >
> >
> > plplot_cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
> >
> >
> >
> > I get the following output:
> >
> > -- The C compiler identification is GNU 4.9.2
> > -- The CXX compiler identification is GNU 4.9.2 CMake Warning at
> > /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):
> >  CMake no longer defines WIN32 on Cygwin!
> >
> >  (1) If you are just trying to build this project, ignore this warning
> > or  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your
> > environment or in  the CMake cache.  If later configuration or build
> > errors occur then this  project may have been written under the assumption that
> Cygwin is WIN32.
> >  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.
> >
> >  (2) If you are developing this project, add the line
> >
> >    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is
> > required
> >
> >  at the top of your top-level CMakeLists.txt file or set the minimum
> > required version of CMake to 2.8.4 or higher.  Then teach your project
> > to  build on Cygwin without WIN32.
> > Call Stack (most recent call first):
> >
> > /usr/share/cmake-3.1.2/Modules/CMakeSystemSpecificInformation.cmake:36
> > (include)
> >
> >
> >
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++.exe
> > -- Check for working CXX compiler: /usr/bin/c++.exe -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /cygdrive/d/tmp/cmake
> >
> > Whereas calling cmake_minimum_required directly does not produce the message.
>
> Thanks for those key test results which I reported to the CMake list (a continuation of
> the thread with the subject line "Chicken and egg problem with
> cmake_minimum_required(...), project(...), and CMAKE_SYSTEM_NAME") I did get
> a clarification there from Brad King, that calling cmake_minimum_required from
> inside a function is problematic.
>
> I have accordingly (commit id cb528a2) updated our build system so that the function
> approach is no longer used to enforce uniform policy.  Instead, I now simply call
> cmake_policy(VERSION 3.0.2) after every cmake_minimum_required() call to
> enforce uniform policy.
>
> The new startup logic is considerably simplified from the previous version, follows
> everything Brad King has recommended, and works fine on Linux.  So I am virtually
> positive it will work fine on Cygwin with no spurious messages.  Therefore, I don't
> think you need to specifically test this change.  Instead, I think you can put off
> (implicitly) testing it until the next Cygwin test I will be requesting when I finish up a
> possible fix for the Fortran problems you have encountered for the traditional build on
> Cygwin.
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure
> Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

Re: [Plplot-devel] A possible design of our new Fortran binding

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

Hi Alan, James,



I am not entirely sure that it is possible to eliminate all intermediate C code, for instance because of storing pointers to callback functions and NULL arguments, but using the iso_c_binding features it will at the very least be possible to let the linker detect missing interfaces: the problem with plbtime and others was that there was a C wrapper, callable from Fortran but no Fortran interface definition. In the new set-up none of the C wrapper code that may still be required will have the name mangling done on the C side - which means the linker will detect any mismatch.



As for James's observations:

Ad 1) I have not noticed anything like that up to now

Ad 2) As far as I know variadic interfaces are indeed impossible (there may be something about that in the so-called technical reports for the Fortran 2015-or-so standard), but luckily PLplot has none.



I should be able to demonstrate the interface set-up I have in mind in a few days, using x00f as an example.



Regards,



Arjen





From: James Tappin [mailto:jt...@gm...]
Sent: Sunday, May 17, 2015 8:42 PM
To: Alan W. Irwin
Cc: Arjen Markus; PLplot development list
Subject: Re: [Plplot-devel] A possible design of our new Fortran binding

If I understand correctly, then this is pretty much what we do in gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib, cairo and the other dependencies) headers to make a set of Fortran interface definitions.
There are only a couple of significant issues that need to be considered (and one I think does not apply to plplot).
1) The compile times can be long, unless a suitable "only" clause is used.
2) Variadic interfaces are not handled (I don't think there is a way to call a C variadic function from Fortran at all).
James

On 17 May 2015 at 17:59, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> wrote:
On 2015-05-17 07:38-0000 Arjen Markus wrote:

> My new bindings would not have prevented this [argument kind error], as it was an omission, not an incorrect implementation.

Hi Arjen:

This is an important point that I think needs more discussion because
the new Fortran binding for ephcom very much prevents such issues from
happening.

There I completely dropped all C code and C headers that helped define
the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
iso_c_binding module to write the interface virtually entirely in
Fortran (except for the few cases where iso_c_binding did not have
some argument processing feature that I had to write from scratch in
C).  So if I had omitted something from the Fortran interface.f90
file, there was no leftover C infrastructure that would silently
generate a f77 fallback.  Instead, the omission would be immediately
detected when I attempted to use the missing function.

I am pretty sure it should be possible (since argument transformations
from single to double or double to single is the only extra
requirement) to do the same thing for our new Fortran interface.  To
make that specific, I think our first goal should be to write an
interface.f90 file that contains complete information to handle single
or double precision versions of x00f.f90 with no C code required at
all to define the interface.

If you agree, then once that first goal is achieved (again with
plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
to expand the interface (using a C layer where necessary for
processing special kinds of arguments) to handle standard examples
that include use of more complicated PLplot arguments.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>).

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

Linux-powered Science
__________________________

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Plplot-devel mailing list
Plp...@li...<mailto:Plp...@li...>
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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] Request for comprehensive test of traditional install tree on Cygwin

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

On 2015-05-13 07:27-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Please find the result of the comprehensive test in the attachment. From a quick inspection of the report I see that there are various issues:
>
> -        The Fortran examples are not properly built because of the name of the libraries:
>
> x00
>
> /usr/bin/cc x01c.c -o x01c.exe -Wl,-rpath -Wl,"/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib:/usr/local/lib" -I/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/include/plplot -L/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib -L/usr/local/lib -lplplot -lltdl.dll -ldl -lshp -lfreetype.dll -lcsirocsa -lqsastime
>
> /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lplplotf95-12.0.0
>
> /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lplplotf95c-12.0.0
>
>
>
>
>
> -        There is an issue with gtk when compiling the C++ examples
>
> -        At some point the compiler cannot find the header file plplot.h
>
> As test runs pretty fast, I only excluded the interactive parts.

Hi Arjen:

Thanks very much for that extremely useful report which I have had to
delay responding to until now because of the other PLplot issues I was
working on.

My latest two commits (417eeb1 and d0464ad) attempt to address the two
issues above.  See the commit messages for the details.  One of the
fixes is just an educated guess (removing some problematic traditional
build logic for Cygwin that has been around since 2007 and which I
believe is the source of the above "cannot find -lplplotf95-12.0.0"
issue) so these fixes definitely need comprehensive testing by you on
Cygwin whenever you get a chance.

Note also that since your comprehensive test above I have made a large
number of intrusive changes to PLplot to address some of Orion's
Fedora concerns and also to do a fairly massive cleanup.  These
changes have all been comprehensively tested on my Debian Wheezy
platform, but please continue your previous policy of not limiting
your comprehensive tests (except for dropping the interactive part for
now) on Cygwin to allow testing of all these changes on that platform
as well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] A possible design of our new Fortran binding

[James T. <jt...@gm...>]

If I understand correctly, then this is pretty much what we do in
gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib,
cairo and the other dependencies) headers to make a set of Fortran
interface definitions.

There are only a couple of significant issues that need to be considered
(and one I think does not apply to plplot).
1) The compile times can be long, unless a suitable "only" clause is used.
2) Variadic interfaces are not handled (I don't think there is a way to
call a C variadic function from Fortran at all).

James


On 17 May 2015 at 17:59, Alan W. Irwin <ir...@be...> wrote:

> On 2015-05-17 07:38-0000 Arjen Markus wrote:
>
> > My new bindings would not have prevented this [argument kind error], as
> it was an omission, not an incorrect implementation.
>
> Hi Arjen:
>
> This is an important point that I think needs more discussion because
> the new Fortran binding for ephcom very much prevents such issues from
> happening.
>
> There I completely dropped all C code and C headers that helped define
> the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
> sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
> iso_c_binding module to write the interface virtually entirely in
> Fortran (except for the few cases where iso_c_binding did not have
> some argument processing feature that I had to write from scratch in
> C).  So if I had omitted something from the Fortran interface.f90
> file, there was no leftover C infrastructure that would silently
> generate a f77 fallback.  Instead, the omission would be immediately
> detected when I attempted to use the missing function.
>
> I am pretty sure it should be possible (since argument transformations
> from single to double or double to single is the only extra
> requirement) to do the same thing for our new Fortran interface.  To
> make that specific, I think our first goal should be to write an
> interface.f90 file that contains complete information to handle single
> or double precision versions of x00f.f90 with no C code required at
> all to define the interface.
>
> If you agree, then once that first goal is achieved (again with
> plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
> to expand the interface (using a C layer where necessary for
> processing special kinds of arguments) to handle standard examples
> that include use of more complicated PLplot 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
> __________________________
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] A possible design of our new Fortran binding

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

On 2015-05-17 07:38-0000 Arjen Markus wrote:

> My new bindings would not have prevented this [argument kind error], as it was an omission, not an incorrect implementation.

Hi Arjen:

This is an important point that I think needs more discussion because
the new Fortran binding for ephcom very much prevents such issues from
happening.

There I completely dropped all C code and C headers that helped define
the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
iso_c_binding module to write the interface virtually entirely in
Fortran (except for the few cases where iso_c_binding did not have
some argument processing feature that I had to write from scratch in
C).  So if I had omitted something from the Fortran interface.f90
file, there was no leftover C infrastructure that would silently
generate a f77 fallback.  Instead, the omission would be immediately
detected when I attempted to use the missing function.

I am pretty sure it should be possible (since argument transformations
from single to double or double to single is the only extra
requirement) to do the same thing for our new Fortran interface.  To
make that specific, I think our first goal should be to write an
interface.f90 file that contains complete information to handle single
or double precision versions of x00f.f90 with no C code required at
all to define the interface.

If you agree, then once that first goal is achieved (again with
plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
to expand the interface (using a C layer where necessary for
processing special kinds of arguments) to handle standard examples
that include use of more complicated PLplot 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] Incorrect pkg-config link flags with plplot 5.11.0

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

Hi Orion:

In the last month or so you brought a number of linking issues for
the traditional build system to my attention.  I believe
commit id = 6a5bad5 should fix those.

Would you please run your traditional build tests on Fedora again to
check that?

Once you confirm all is well (i.e., no overlinking or underlinking)
with the traditional build for this change, then I plan to deal with
some of the other issues you brought up that did not involve the
traditional build system.

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] floating point exception in example 29

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]


> > Ah, that is clear: there is no interface definition for plctime. So
> the compiler was using the traditional F77 rules and could not check the correctness
> of the types. I will fix this.
>
> Hi Arjen:
>
> Are you proposing to do this fix for current Fortran binding? If so, I honestly don't
> think it is worth your time since (a) nobody has complained about some of these f77
> characteristics of the current binding and (b) I assume that binding is soon going to
> be replaced with your new Fortran binding.  I assume the fundamental design of your
> new Fortran binding will automatically check type correctness of all arguments so
> there is no chance of such an error occurring with it.

No, you misunderstood me. I should have been clearer: the PLPLOT module did not include the subroutine plctime, plbtime and plconfigtime. This means that the compiler has no clue as to what arguments are required and simply accepts whatever you pass (which is the way FORTRAN 77 worked and what the compiler is obliged to do). I added interfaces to the module, so that now it does check the types. It would be nice if in fact the compiler would warn about such unknown routines.

My new bindings would not have prevented this, as it was an omission, not an incorrect implementation.

>
> Which reminds me, what is the status of your topic branch for your new Fortran
> binding? The reason I ask is the next opportunity (just after the forthcoming 5.11.1
> will be released) to merge large topics to master is fast approaching, and my
> understanding is there is still some more work you have to do to mature that topic
> sufficiently so that it is suitable for merging with master.
>
Alas, no progress here, as I have been rather busy with many things.

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] floating point exception in example 29

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

On 2015-05-15 10:19-0000 Arjen Markus wrote:

> Hi Alan, Hazen,
>
>
>> From: Arjen Markus [mailto:Arj...@de...]
>> Sent: Friday, May 15, 2015 12:15 PM
>> To: Alan W. Irwin; Hazen Babcock
>> Cc: PLplot development list
>> Subject: Re: [Plplot-devel] floating point exception in example 29
>>
>> Hi Alan, Hazen,
>>
>> Actually, this should have been caught by the compiler.
>

> Ah, that is clear: there is no interface definition for plctime. So
the compiler was using the traditional F77 rules and could not check
the correctness of the argument types. I will fix this.

Hi Arjen:

Are you proposing to do this fix for current Fortran binding? If so, I
honestly don't think it is worth your time since (a) nobody has
complained about some of these f77 characteristics of the current
binding and (b) I assume that binding is soon going to be replaced
with your new Fortran binding.  I assume the fundamental design of
your new Fortran binding will automatically check type correctness of
all arguments so there is no chance of such an error occurring with
it.

Which reminds me, what is the status of your topic branch for your new
Fortran binding? The reason I ask is the next opportunity (just after
the forthcoming 5.11.1 will be released) to merge large topics to
master is fast approaching, and my understanding is there is still
some more work you have to do to mature that topic sufficiently
so that it is suitable for merging with master.

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] Spurious warnings on Cygwin should now be gone

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

On 2015-05-15 13:45-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> With this minimal CMakeLists.txt file:
>
>
>
> function(plplot_cmake_minimum_required)
>
>  cmake_minimum_required(${ARGV})
>
> endfunction(plplot_cmake_minimum_required)
>
>
>
> plplot_cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
>
>
>
> I get the following output:
>
> -- The C compiler identification is GNU 4.9.2
> -- The CXX compiler identification is GNU 4.9.2
> CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):
>  CMake no longer defines WIN32 on Cygwin!
>
>  (1) If you are just trying to build this project, ignore this warning or
>  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
>  the CMake cache.  If later configuration or build errors occur then this
>  project may have been written under the assumption that Cygwin is WIN32.
>  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.
>
>  (2) If you are developing this project, add the line
>
>    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required
>
>  at the top of your top-level CMakeLists.txt file or set the minimum
>  required version of CMake to 2.8.4 or higher.  Then teach your project to
>  build on Cygwin without WIN32.
> Call Stack (most recent call first):
>  /usr/share/cmake-3.1.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)
>
>
>
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++.exe
> -- Check for working CXX compiler: /usr/bin/c++.exe -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /cygdrive/d/tmp/cmake
>
> Whereas calling cmake_minimum_required directly does not produce the message.

Thanks for those key test results which I reported to the CMake list
(a continuation of the thread with the subject line "Chicken and egg problem with
cmake_minimum_required(...), project(...), and CMAKE_SYSTEM_NAME")
I did get a clarification there from Brad King, that
calling cmake_minimum_required from inside a function is problematic.

I have accordingly (commit id cb528a2) updated our build system so
that the function approach is no longer used to enforce uniform
policy.  Instead, I now simply call cmake_policy(VERSION 3.0.2) after
every cmake_minimum_required() call to enforce uniform policy.

The new startup logic is considerably simplified from the previous
version, follows everything Brad King has recommended, and works fine
on Linux.  So I am virtually positive it will work fine on Cygwin with
no spurious messages.  Therefore, I don't think you need to
specifically test this change.  Instead, I think you can put off
(implicitly) testing it until the next Cygwin test I will be
requesting when I finish up a possible fix for the Fortran problems
you have encountered for the traditional build on Cygwin.

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] Spurious warnings on Cygwin should now be gone

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

Hi Alan,



With this minimal CMakeLists.txt file:



function(plplot_cmake_minimum_required)

  cmake_minimum_required(${ARGV})

endfunction(plplot_cmake_minimum_required)



plplot_cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)



I get the following output:

-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.1.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)



-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /cygdrive/d/tmp/cmake

Whereas calling cmake_minimum_required directly does not produce the message.

When I checked this statement however, I found it is possible to reduce the CmakeLists.txt file even further:

cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)

with nothing else, that is, not followed by project(), will print the same messages. I think that this is why cmake_minimum_required() in a function does produce the messages.

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] floating point exception in example 29

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

Hi Alan, Hazen,


> From: Arjen Markus [mailto:Arj...@de...]
> Sent: Friday, May 15, 2015 12:15 PM
> To: Alan W. Irwin; Hazen Babcock
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] floating point exception in example 29
>
> Hi Alan, Hazen,
>
> Actually, this should have been caught by the compiler.

Ah, that is clear: there is no interface definition for plctime. So the compiler was using the traditional F77 rules and could not check the correctness of the argument types. I will fix this.

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] floating point exception in example 29

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

Hi Alan, Hazen,



-----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, May 14, 2015 2:19 AM
>
> Hi Hazen:
>
> It turned out to be a fortran argument issue in Fortran example 29, where 0. had to
> be replaced by 0._plflt (see commit id=a0e51cd).

Actually, this should have been caught by the compiler.

>
> @Arjen:
> This issue illustrates how tricky it is to use our current fortran bindings and should be
> a big motivation for you to finish up your rewrite of those bindings so our Fortran
> user's don't have to worry about using the _plflt suffix on all floating-point arguments.
>
Indeed, on the other hand, see my remark above. I will have a look at this.

> @Hazen: Solving this plctime argument issue solved the floating point exception (as
> you suggested it would) for fortran example 29 so I think the only floating-point
> issues currently left are for examples
> 21 and 33.
>
Any chance they are caused by something similar?

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] Using Window's raw API for shapes and text

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

Alan, <br><br>That makes sense to me.  I can see how the configure/build time checks make sense to affect which support to attempt compile-in.  E.g. if one were building with an older compiler on an XP host, you wouldn't want to try to link in Direct2D support.  OTOH, what I actually had in mind was runtime detection to use the most effective version available on the target platform.<br><br>Thanks,<br><br>Aaron.<br><br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ir...@be...<br>To: he...@co...,ji...@di...<br>Cc: Plp...@li...<br>Sent: 2015-05-14 15:00:20 GMT<br>Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text<br><br>On 2015-05-14 15:51-0000 he...@co... wrote:<br><br>> Alan,<br>> <br>> One potential downside of the newer Direct2D/DirectWrite APIs is that they aren't supported on Windows XP. I know I have users of my<br>> application still using XP. I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.<br>><br><br>Hi Aaron:<br><br>Since Windows XP is an important requirement for you, then it appears<br>(again from my rather superficial google searching) that to render<br>unicode text with raw Windows API you must use GDI in combination with<br>the predecessor to DirectWrite which is Uniscribe<br><http://en.wikipedia.org/wiki/Uniscribe>.<br><br>Jim's later post in this thread said he would start with GDI so I<br>expect once he replaces the plfreetype approach for rendering unicode<br>text with raw Windows API for doing the same task he will be moving to<br>GDI/Uniscribe (if his reference to "GDI" did not actually<br>already mean GDI/Uniscribe).  And I am pretty sure from my reading that<br>GDI/Uniscribe is supported for Windows XP and all later Microsoft<br>versions.<br><br>> If the case for using Direct2D/DirectWrite is compelling enough, maybe they could be supported in addition to GDI and only used if the<br>> detected OS is > WinXP?<br><br>I think this is a good idea once it is confirmed that the GDI/Uniscribe<br>approach works fine. From my reading the advantages of<br>Direct2D/DirectWrite are considerable (e.g., vector graphics rather<br>than bitmapped).  And it should be straightforward to provide<br>CMake code to test whether Direct2D/DirectWrite is available, and<br>if so, provide the user the option to use Direct2D/DirectWrite<br>rather than GDI/Uniscribe.<br><br>But with regard to Jim's enhanced version of drivers/wingcc.c it<br>it seems to me the implementation order should be<br><br>1. GDI/plfreetype.  This approach will give the wrong glyph<br>order for the Arabic, Hebrew, and Hindi "peace" words<br>in example 24 and may have trouble finding the appropriate<br>fonts for all those languages, i.e., certain glyphs will<br>be missing.<br><br>2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype<br>API with Uniscribe API).  Once implemented, the GDI/Uniscribe<br>combination should be tested by running example 24 and confirming that<br>it produces correct results (i.e., all Peace words present and having<br>the correct glyph order (i.e., as demonstrated at<br><http://plplot.sourceforge.net/examples.php?demo=24>.<br><br>3. Add the additional possibility (depending on a macro set by the<br>CMake logic referred to above) of using the Direct2D/DirectWrite API<br>instead of the GDI/Uniscribe API.  (Again with a check that example 24<br>works properly.)<br><br>Note, we want to get rid of all use of plfreetype so if Jim's<br>reference to his driver already using GDI actually referred to<br>GDI/Uniscribe, then he should ignore 1 and start with the example 24<br>test recommended in 2. above.<br><br>Alan<br>__________________________<br>Alan W. Irwin<br><br>Astronomical research affiliation with Department of Physics and Astronomy,<br>University of Victoria (astrowww.phys.uvic.ca).<br><br>Programming affiliations with the FreeEOS equation-of-state<br>implementation for stellar interiors (freeeos.sf.net); the Time<br>Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br>software package (plplot.sf.net); the libLASi project<br>(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br>and the Linux Brochure Project (lbproject.sf.net).<br>__________________________<br><br>Linux-powered Science<br>__________________________<br>

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

On 2015-05-14 15:51-0000 he...@co... wrote:

> Alan,
> 
> One potential downside of the newer Direct2D/DirectWrite APIs is that they aren't supported on Windows XP. I know I have users of my
> application still using XP. I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.
>

Hi Aaron:

Since Windows XP is an important requirement for you, then it appears
(again from my rather superficial google searching) that to render
unicode text with raw Windows API you must use GDI in combination with
the predecessor to DirectWrite which is Uniscribe
<http://en.wikipedia.org/wiki/Uniscribe>.

Jim's later post in this thread said he would start with GDI so I
expect once he replaces the plfreetype approach for rendering unicode
text with raw Windows API for doing the same task he will be moving to
GDI/Uniscribe (if his reference to "GDI" did not actually
already mean GDI/Uniscribe).  And I am pretty sure from my reading that
GDI/Uniscribe is supported for Windows XP and all later Microsoft
versions.

> If the case for using Direct2D/DirectWrite is compelling enough, maybe they could be supported in addition to GDI and only used if the
> detected OS is > WinXP?

I think this is a good idea once it is confirmed that the GDI/Uniscribe
approach works fine. From my reading the advantages of
Direct2D/DirectWrite are considerable (e.g., vector graphics rather
than bitmapped).  And it should be straightforward to provide
CMake code to test whether Direct2D/DirectWrite is available, and
if so, provide the user the option to use Direct2D/DirectWrite
rather than GDI/Uniscribe.

But with regard to Jim's enhanced version of drivers/wingcc.c it
it seems to me the implementation order should be

1. GDI/plfreetype.  This approach will give the wrong glyph
order for the Arabic, Hebrew, and Hindi "peace" words
in example 24 and may have trouble finding the appropriate
fonts for all those languages, i.e., certain glyphs will
be missing.

2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype
API with Uniscribe API).  Once implemented, the GDI/Uniscribe
combination should be tested by running example 24 and confirming that
it produces correct results (i.e., all Peace words present and having
the correct glyph order (i.e., as demonstrated at
<http://plplot.sourceforge.net/examples.php?demo=24>.

3. Add the additional possibility (depending on a macro set by the
CMake logic referred to above) of using the Direct2D/DirectWrite API
instead of the GDI/Uniscribe API.  (Again with a check that example 24
works properly.)

Note, we want to get rid of all use of plfreetype so if Jim's
reference to his driver already using GDI actually referred to
GDI/Uniscribe, then he should ignore 1 and start with the example 24
test recommended in 2. above.

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] Using Window's raw API for shapes and text

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

On 2015-05-14 11:57-0400 Jim Dishaw wrote:

> The code that I currently have uses GDI, so we can start from there.

Sounds good.

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] Using Window's raw API for shapes and text

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

The code that I currently have uses GDI, so we can start from there. 



> On May 14, 2015, at 11:51 AM, he...@co... wrote:
> 
> Alan,
> 
> One potential downside of the newer Direct2D/DirectWrite APIs is that they aren't supported on Windows XP. I know I have users of my application still using XP. I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.
> 
> If the case for using Direct2D/DirectWrite is compelling enough, maybe they could be supported in addition to GDI and only used if the detected OS is > WinXP?
> 
> Thanks,
> 
> Aaron.
> 
> Sent from XFINITY Connect Mobile App
> -----Original Message-----
> 
> From: ir...@be...
> To: he...@co...
> Cc: Plp...@li...
> Sent: 2015-05-13 23:11:24 GMT
> Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text
> 
> On 2015-05-13 21:44-0500 Aaron Hexamer wrote:
> 
> > Would it be developed using the GDI? If so, then maybe wingdi?
> 
> Hi Aaron:
> 
> To respond to your first question even though I am not
> that familiar with Windows, I did look up the article at
> , and it
> appears that is an old API that has been replaced with the Direct2D
> API.
> I then followed up with some google
> searching to find
> 
> which implies you can use gdi for graphics and DirectWrite for text or
> Direct2D for graphics and DirectWrite for text. Furthermore,
> says one of the features is
> 
> "Comprehensive support for Unicode, with over 20 scripts providing
> layout and rendering of every language supported in Windows."
> 
> So that superficially sounds like exactly what we want to use (in
> combination with either GDI or Direct2D), but remember my Windows
> knowledge is quite limited and this research just took me a few
> minutes of google searching so if our Windows developers have a
> different preference for the Windows API that is used to render
> unicode text, then we should adopt that preference.
> 
> @Aaron: I do think your general idea of the win+API name is better
> than winwidgets. So I would be happy to use wingdi or windirect2d
> depending on the decision about which one is used in conjunction with
> DirectWrite.
> 
> @Jim, Arjen, and Phil:
> 
> As our most active Windows developers please chime in about what
> Windows API you think we should use to render unicode text, and the
> name you would like to see for what is currently called the wingcc
> device driver.
> 
> 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
> __________________________
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

Alan,<br><br>One potential downside of the newer Direct2D/DirectWrite APIs is that they aren't supported on Windows XP.  I know I have users of my application still using XP.  I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.<br><br>If the case for using Direct2D/DirectWrite is compelling enough, maybe they could be supported in addition to GDI and only used if the detected OS is > WinXP?<br><br>Thanks,<br><br>Aaron.<br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ir...@be...<br>To: he...@co...<br>Cc: Plp...@li...<br>Sent: 2015-05-13 23:11:24 GMT<br>Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text<br><br>On 2015-05-13 21:44-0500 Aaron Hexamer wrote:<br><br>> Would it be developed using the GDI?  If so, then maybe wingdi?<br><br>Hi Aaron:<br><br>To respond to your first question even though I am not<br>that familiar with Windows, I did look up the article at<br><http://en.wikipedia.org/wiki/Graphics_Device_Interface>, and it<br>appears that is an old API that has been replaced with the Direct2D<br><http://en.wikipedia.org/wiki/Direct2D> API.<br>I then followed up with some google<br>searching to find<br><https://msdn.microsoft.com/en-us/library/windows/desktop/ff729481(v=vs.85).aspx><br>which implies you can use gdi for graphics and DirectWrite for text or<br>Direct2D for graphics and DirectWrite for text.  Furthermore,<br><http://en.wikipedia.org/wiki/DirectWrite> says one of the features is<br><br>"Comprehensive support for Unicode, with over 20 scripts providing<br>layout and rendering of every language supported in Windows."<br><br>So that superficially sounds like exactly what we want to use (in<br>combination with either GDI or Direct2D), but remember my Windows<br>knowledge is quite limited and this research just took me a few<br>minutes of google searching so if our Windows developers have a<br>different preference for the Windows API that is used to render<br>unicode text, then we should adopt that preference.<br><br>@Aaron: I do think your general idea of the win+API name is better<br>than winwidgets. So I would be happy to use wingdi or windirect2d<br>depending on the decision about which one is used in conjunction with<br>DirectWrite.<br><br>@Jim, Arjen, and Phil:<br><br>As our most active Windows developers please chime in about what<br>Windows API you think we should use to render unicode text, and the<br>name you would like to see for what is currently called the wingcc<br>device driver.<br><br>Alan<br>__________________________<br>Alan W. Irwin<br><br>Astronomical research affiliation with Department of Physics and Astronomy,<br>University of Victoria (astrowww.phys.uvic.ca).<br><br>Programming affiliations with the FreeEOS equation-of-state<br>implementation for stellar interiors (freeeos.sf.net); the Time<br>Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br>software package (plplot.sf.net); the libLASi project<br>(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br>and the Linux Brochure Project (lbproject.sf.net).<br>__________________________<br><br>Linux-powered Science<br>__________________________<br>

Re: [Plplot-devel] FPE in plfill.c

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

On 05/14/2015 11:42 AM, Hazen Babcock wrote:
> On 05/13/2015 05:50 PM, Alan W. Irwin wrote:
>>
>> Hi Hazen:
>>
>> I have reviewed plfill.c, and the returned intersection from
>> notcrossed is only used when status is zero.  So I have (commit ID =
>> b916d4b) considerably simplified noncrossed to do the PLINT
>> transformation of the intersection and return those values _only_ when
>> status = 0.
>>
>> This change solved all fpe problem for examples 25 and 30, but there
>> are remaining fpe issues for fortran examples 21 and 33.  The logic in
>> noncrossed is pretty bullet-proof now so my prediction is those
>> remaining fpe issues are completely independent of notcrossed or else
>> there is a non-initialized variable somewhere in fortran examples 21
>> and 33. But I look forward to your definitive conclusion concerning
>> those remaining fpe issues.
>
> The issue in example 21 seems to be in the qhull library. I will look
> into building a qhull with debug flag to try and track this one down.
>
> The remaining issue in example 33 is that we are multiplying -2.0e-200
> times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of
> src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than
> what can be represented using floating point numbers. I changed the
> login in pldrawcn() to do the sign determination without doing this
> multiplication. I've just pushed this fix.

Hm, got the signs backwards, hopefully it is correct now.

-Hazen

Re: [Plplot-devel] FPE in plfill.c

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

On 05/13/2015 05:50 PM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> I have reviewed plfill.c, and the returned intersection from
> notcrossed is only used when status is zero.  So I have (commit ID =
> b916d4b) considerably simplified noncrossed to do the PLINT
> transformation of the intersection and return those values _only_ when
> status = 0.
>
> This change solved all fpe problem for examples 25 and 30, but there
> are remaining fpe issues for fortran examples 21 and 33.  The logic in
> noncrossed is pretty bullet-proof now so my prediction is those
> remaining fpe issues are completely independent of notcrossed or else
> there is a non-initialized variable somewhere in fortran examples 21
> and 33. But I look forward to your definitive conclusion concerning
> those remaining fpe issues.

The issue in example 21 seems to be in the qhull library. I will look 
into building a qhull with debug flag to try and track this one down.

The remaining issue in example 33 is that we are multiplying -2.0e-200 
times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of 
src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than 
what can be represented using floating point numbers. I changed the 
login in pldrawcn() to do the sign determination without doing this 
multiplication. I've just pushed this fix.

-Hazen

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

On 2015-05-13 21:44-0500 Aaron Hexamer wrote:

> Would it be developed using the GDI?  If so, then maybe wingdi?

Hi Aaron:

To respond to your first question even though I am not
that familiar with Windows, I did look up the article at
<http://en.wikipedia.org/wiki/Graphics_Device_Interface>, and it
appears that is an old API that has been replaced with the Direct2D
<http://en.wikipedia.org/wiki/Direct2D> API.
I then followed up with some google
searching to find
<https://msdn.microsoft.com/en-us/library/windows/desktop/ff729481(v=vs.85).aspx>
which implies you can use gdi for graphics and DirectWrite for text or
Direct2D for graphics and DirectWrite for text.  Furthermore,
<http://en.wikipedia.org/wiki/DirectWrite> says one of the features is

"Comprehensive support for Unicode, with over 20 scripts providing
layout and rendering of every language supported in Windows."

So that superficially sounds like exactly what we want to use (in
combination with either GDI or Direct2D), but remember my Windows
knowledge is quite limited and this research just took me a few
minutes of google searching so if our Windows developers have a
different preference for the Windows API that is used to render
unicode text, then we should adopt that preference.

@Aaron: I do think your general idea of the win+API name is better
than winwidgets. So I would be happy to use wingdi or windirect2d
depending on the decision about which one is used in conjunction with
DirectWrite.

@Jim, Arjen, and Phil:

As our most active Windows developers please chime in about what
Windows API you think we should use to render unicode text, and the
name you would like to see for what is currently called the wingcc
device driver.

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] Using Window's raw API for shapes and text

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

Would it be developed using the GDI?  If so, then maybe wingdi?

-----Original Message-----
From: Alan W. Irwin [mailto:ir...@be...] 
Sent: Wednesday, May 13, 2015 9:33 PM
To: Jim Dishaw
Cc: Aaron Hexamer; PLplot development list
Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text

On 2015-05-13 20:56-0400 Jim Dishaw wrote:

>> On May 13, 2015, at 8:43 PM, Alan W. Irwin <ir...@be...>
wrote:
[...] But clearly the wingcc name is
>> now a misnomer.  Of course, you don't want to break backwards 
>> compatibility on this name now unless there is a really good reason, 
>> but one possible good reason is if someone could think up a really 
>> compelling name for this device driver that we all immediately like.
>
> How about mswin.

I don't particularly like that name because it emphasizes Microsoft.
That company clearly is in complete charge of the Windows platform, but
there are at least open enough about the specifications of that platform
that it is possible for others (such as the Wine developers) to implement a
Windows platform as well.  For example, the wingcc driver works fine on the
Wine version of Windows according to my tests.

Before I posed my question, I was thinking of just "win", but I think that
is so bland it is almost meaningless.  Another possibility is iwin (where
the i stands for interactive), but again too bland.

Just free-associating here, but how about something like winwidget to follow
(roughly) the naming scheme for both our wxwidgets and our qtwidget devices?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

On 2015-05-13 20:56-0400 Jim Dishaw wrote:

>> On May 13, 2015, at 8:43 PM, Alan W. Irwin <ir...@be...> wrote:
[...] But clearly the wingcc name is
>> now a misnomer.  Of course, you don't want to break backwards
>> compatibility on this name now unless there is a really good reason,
>> but one possible good reason is if someone could think up a really
>> compelling name for this device driver that we all immediately like.
>
> How about mswin.

I don't particularly like that name because it emphasizes Microsoft.
That company clearly is in complete charge of the Windows platform,
but there are at least open enough about the specifications of that
platform that it is possible for others (such as the Wine developers)
to implement a Windows platform as well.  For example, the wingcc
driver works fine on the Wine version of Windows according to my
tests.

Before I posed my question, I was thinking of just "win", but I think
that is so bland it is almost meaningless.  Another possibility
is iwin (where the i stands for interactive), but again too bland.

Just free-associating here, but how about something like winwidget
to follow (roughly) the naming scheme for both our wxwidgets
and our qtwidget devices?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________