plplot-general — PLplot user discussion group

[Plplot-general] Plotting from multithreaded environment

[Sergei N. <vo...@ra...>]

Hi!

I am writing a program that periodically pulls data over a serial line. It has to
process and plot them. The plotting is done into a GDK_PIXMAP. In order to pull
data periodically I start a separate gdk thread with g_timeout_add_seconds().
What I find however is that all plplot commands that are given from inside this
separate thread seem to be getting ignored. Is there any explanation and/or
example on plotting in multithreaded environments? It doesn't seem right to
reinitialize everything every time a thread in executed.

Thanks a lot in advance,

-- Sergei

[Plplot-general] All Windows and Mac git users should update their git software to beat a just-revealed security issue

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

See <https://github.com/blog/1938-git-client-vulnerability-announced>
for details from the github point of view, but I am pretty sure it is
not that different from the SF point of view since this is a git
client issue and not a git server issue.

To me this vulnerability seems pretty low-risk for the PLplot git
repository at SF since it requires an attacker (unless they already
own the computer used by the PLplot core team member) to be able to
first beat the SourceForge security that keeps anyone but the PLplot
core team from pushing code to our SF repository.  And "security by
obscurity" is a huge factor as well.  Nevertheless, if you are using a
Mac OS X or Windows git client to access any git repository including
the PLplot one, it does appear to be a good idea as a matter of due
diligence to reinstall git as soon as the place where you downloaded
your git client announces they have made a version available that
fixes this vulnerability.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Customized axes

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

On 2014-12-09 22:16+0300 Sergei Naumov wrote:

> Hi!
>
> I just started to use PLplot (I need to embed plots into GTK application) and
> could find a clear explanation how to customize axes instead of the default
> PLENV. I also could find any explanation of working with world coordinates 
> that
> seem to be needed to draw axes. Can anyone point to a good example code that 
> uses
> this functionality?

Hi Sergei:

We try to exercise most of our API in our standard examples.  So look
in

examples/<language>/x*

for good example code in the language of your choice.

And to answer your specific question, I am not that familiar with use
of custom axes, but

examples/c/x19c.c

does have a comment:

// A custom axis labeling function for longitudes and latitudes.

so you might want to look at standard example 19 in the language of
your choice to start.

Thanks for your interest in PLplot, and good luck with using it further.

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
__________________________

[Plplot-general] Customized axes

[Sergei N. <vo...@ra...>]

Hi!

I just started to use PLplot (I need to embed plots into GTK application) and
could find a clear explanation how to customize axes instead of the default
PLENV. I also could find any explanation of working with world coordinates that
seem to be needed to draw axes. Can anyone point to a good example code that uses
this functionality?

Thank you in advance,

-- Sergei

Re: [Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

Thanks again, Alan, Arjen, Steven for taking the time to
provide so much information.

I think I will put what I have in the next version of the Fortran
Tools, since it *does work* and then definitely have a look
at MinGW/MSYS and the Dependency walker.

The other new thing I will include is Glade. It is a nice GUI
for building GUIs, but, unfortunately, has no reference manual,
just a couple of tutorials. The Plplot manual is so nice, by
comparison.

On Sat, Nov 29, 2014 at 5:23 AM, Schwartz, Steven J <
s.s...@im...> wrote:

> Dear All,
>
> Walt Brainerd wrote on 2014-11-29:
> ----------------
>
> > Yes, it appears that this is a little complicated.
> > I build static, but linking an application was missing a bunch of stuff.
>
> I don't have much direct or exhaustive experience here, and my gut agrees
> with Alan's advice that the more static stuff the better. We ship binary
> distributions of our QSAS application, which uses our own build of plplot
> (and only one driver, our original Qt widget driver, from which the modern
> plplot qt drivers were spawned). QSAS can't be 100% static because part of
> the architecture involves user-built and dynamically loaded plug-ins. So in
> practice we build essentially 100% shareable code and then bundle all the
> necessary dll's into a /lib folder. I've been meaning to test building a
> simple plplot application against those libs, but the small extra effort of
> forcing it to be built within a proper qt application has been enough to
> put it on the back burner.
>
> Our experience is that shipped Windows binaries tend to work pretty well
> across different versions of Windows platforms. We don't use CMake, but a
> simple bespoke build script under MSYS/Mingw (I've been meaning to try
> MSYS2). Bundling up QSAS for distribution means identifying all the library
> dependencies, and I've recently discovered "Dependency Walker" to provide a
> full view of the dll's needed. Most of these are system libraries that seem
> to be maintained and distributed with Windows despite the advancing
> operating systems. Then there are the qt libs, some other 3rd party ones,
> and a few from mingw (libstdc++, libgcc..., libwinpthread..., etc which are
> quickly identified in Dependency Walker's hierarchical view of the libs
> required at launch. I think it will also query individual dll's to locate
> their dependencies and also profile the run of an application to pick up,
> e.g., dynamic loading post-launch.
>
> Anyway, Windows seems to be remarkably robust to running binaries from
> other versions. This is in stark contrast to linux and macintosh, both of
> which are much fussier and temperamental. I am not a fan of Microsoft - far
> from it - but this aspect is fairly impressive.
>
> I suspect ( = I have no evidence or expertise ) that this works better if
> the binary is built on an old version of Windows and then shipped to newer
> ones than vice versa, as Windows tries hard to be backwardly compatible. No
> one could really expect them to be forward compatible.
>
> Finally, I have followed your discussion about font and map files. We
> "solve" this problem by putting them in the same directory as our main
> executable and have our batch startup script always run from within that
> directory. I think plplot will look in the current working directory to
> find them. I'll experiment with the PLPLOT_LIB approach, as it's a bit
> tidier.
>
> Best wishes
> Steve
> --------------------------------------------------------------------
> Steven J Schwartz                  Phone:  +44 (0)207 594 7660
> Professor of Space Physics         Fax:    +44 (0)207 594 7772
> Director, Imperial Space Lab       www.imperial.ac.uk/spacelab
> The Blackett Laboratory            Email:  s.s...@im...
> Imperial College London            Office: Huxley 6M67A
> London SW7 2AZ, UK                 Web:    www.sp.ph.ic.ac.uk/~sjs
> --------------------------------------------------------------------
>
>
>


-- 
Walt Brainerd

Re: [Plplot-general] Plplot on Mingw

[Schwartz, S. J <s.s...@im...>]

Dear All,

Walt Brainerd wrote on 2014-11-29:
----------------

> Yes, it appears that this is a little complicated.
> I build static, but linking an application was missing a bunch of stuff.

I don't have much direct or exhaustive experience here, and my gut agrees with Alan's advice that the more static stuff the better. We ship binary distributions of our QSAS application, which uses our own build of plplot (and only one driver, our original Qt widget driver, from which the modern plplot qt drivers were spawned). QSAS can't be 100% static because part of the architecture involves user-built and dynamically loaded plug-ins. So in practice we build essentially 100% shareable code and then bundle all the necessary dll's into a /lib folder. I've been meaning to test building a simple plplot application against those libs, but the small extra effort of forcing it to be built within a proper qt application has been enough to put it on the back burner.

Our experience is that shipped Windows binaries tend to work pretty well across different versions of Windows platforms. We don't use CMake, but a simple bespoke build script under MSYS/Mingw (I've been meaning to try MSYS2). Bundling up QSAS for distribution means identifying all the library dependencies, and I've recently discovered "Dependency Walker" to provide a full view of the dll's needed. Most of these are system libraries that seem to be maintained and distributed with Windows despite the advancing operating systems. Then there are the qt libs, some other 3rd party ones, and a few from mingw (libstdc++, libgcc..., libwinpthread..., etc which are quickly identified in Dependency Walker's hierarchical view of the libs required at launch. I think it will also query individual dll's to locate their dependencies and also profile the run of an application to pick up, e.g., dynamic loading post-launch.

Anyway, Windows seems to be remarkably robust to running binaries from other versions. This is in stark contrast to linux and macintosh, both of which are much fussier and temperamental. I am not a fan of Microsoft - far from it - but this aspect is fairly impressive.

I suspect ( = I have no evidence or expertise ) that this works better if the binary is built on an old version of Windows and then shipped to newer ones than vice versa, as Windows tries hard to be backwardly compatible. No one could really expect them to be forward compatible.

Finally, I have followed your discussion about font and map files. We "solve" this problem by putting them in the same directory as our main executable and have our batch startup script always run from within that directory. I think plplot will look in the current working directory to find them. I'll experiment with the PLPLOT_LIB approach, as it's a bit tidier.

Best wishes
Steve
--------------------------------------------------------------------
Steven J Schwartz                  Phone:  +44 (0)207 594 7660
Professor of Space Physics         Fax:    +44 (0)207 594 7772
Director, Imperial Space Lab       www.imperial.ac.uk/spacelab
The Blackett Laboratory            Email:  s.s...@im...
Imperial College London            Office: Huxley 6M67A
London SW7 2AZ, UK                 Web:    www.sp.ph.ic.ac.uk/~sjs
--------------------------------------------------------------------

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-28 19:05-0700 Walt Brainerd wrote:

> Yes, it appears that this is a little complicated.
> I build static, but linking an application was missing
> a bunch of stuff.
>
> One more (last?) question:
>
> Do you have an idea why I get only the 6 drivers, when
> I get more building on Cygwin?
>
> I am happy with what I have, so thanks again for all the
> advice.

Many of our device drivers depend on external libraries:

qt depends on libQt4 (or libQt5)

cairo depends on the pango/cairo subset of the GTK+ stack of libraries

wxwidgets depends on the wxwidgets external library.

But MinGW/MSYS doesn't have any of those (so those device
drivers get turned off on that platform) while Cygwin does.

If you are game for some more experiments you might want to try
MinGW-w64/MSYS2 (both of which projects are completely independent of
MinGW and MSYS).  To put this in context, MinGW/MSYS is a fork of an
ancient and bug-riddent version of Cygwin, while MinGW-w64/MSYS2 is a
recent variant of the latest Cygwin but without its baggage, e.g., the
native Windows runtime is used.  So MinGW-w64/MSYS2 has the simplicity
of MinGW/MSYS without the bugs and with many more free software
libraries supported because the package building software for Cygwin
can easily be modified to build MinGW-w64/MSYS2 versions of the
packages as well.

Warning.... As you can tell I am very enthused about the
MinGW-w64/MSYS2 possibility for PLplot, but I cannot try it myself
(Wine bugs get in the way just like they do with modern Cygwin), and
our core developers with access to the Microsoft version of Windows
haven't had a chance yet to evaluate it because there is a lot to do
for the Windows platforms they are already working on.  So
MinGW-w64/MSYS2 might work like a dream for you with access to all the
same devices that are accessible on Cygwin or it might not because
none of our core developers have tried it yet.  But I think it would
definitely be worth your while to give it a quick try just to see how
far you get.

If you have further interest in this possibility, you can find how to
install MinGW-w64/MSYS2 at https://sourceforge.net/p/msys2/wiki/Home/.
Like MinGW/MSYS the Windows native runtime is used so I suggest you
use the native Windows CMake version you can download from Kitware (as
opposed to the Cygwin version of CMake) and also the "MSYS Makefiles"
generator to build PLplot.

> I found Inkscape, which will convert to some
> more formats.

Yeah, that should work for the limited device drivers available with
MinGW/MSYS, but, of course, best results are obtained with native
PLplot rather than converted PLplot results which is why I suggest you
give MinGW-w64/MSYS2 a quick try just in case it works right out of
the box.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

Yes, it appears that this is a little complicated.
I build static, but linking an application was missing
a bunch of stuff.

One more (last?) question:

Do you have an idea why I get only the 6 drivers, when
I get more building on Cygwin?

I am happy with what I have, so thanks again for all the
advice. I found Inkscape, which will convert to some
more formats.

On Fri, Nov 28, 2014 at 2:40 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-11-28 13:02-0700 Walt Brainerd wrote:
>
>  SUCCESS!
>>
>
> Good!
> [...]
>
>> Another question: if I (or you) provide this install directory as a
>> Windows binary distribution, how many systems do you think it
>> would work on?
>>
>
> Good question!
>
> To avoid dependency hell (which is likely the fundamental constraint
> on how many different Windows platforms a binary distribution of
> PLplot would work on) you would want to (1) build and install PLplot
> with internal static libraries that are (2) linked to static versions
> of external libraries, and likely (3) using a static run-time as well
> (although I am not sure on that point, and "real" Windows users should
> chime in here).  (1) is already implemented; you simply specify
> -DBUILD_SHARED_LIBS=OFF as a cmake command-line option.  I think (2)
> and (3) are possible with our CMake-based build system, but no PLplot
> developer has yet investigated what CMake options are required (or
> what other steps you have to do) to implement these features.  If you
> are interested further, I would be willing to ask about these issues
> on the CMake list.
>
> Once you know how to deal with issue (2) and possibly (3), then cmake
> provides fairly sophisticated facilities to create binary
> distributions from the contents of the install tree.
>
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-28 13:02-0700 Walt Brainerd wrote:

> SUCCESS!

Good!
[...]
> Another question: if I (or you) provide this install directory as a
> Windows binary distribution, how many systems do you think it
> would work on?

Good question!

To avoid dependency hell (which is likely the fundamental constraint
on how many different Windows platforms a binary distribution of
PLplot would work on) you would want to (1) build and install PLplot
with internal static libraries that are (2) linked to static versions
of external libraries, and likely (3) using a static run-time as well
(although I am not sure on that point, and "real" Windows users should
chime in here).  (1) is already implemented; you simply specify
-DBUILD_SHARED_LIBS=OFF as a cmake command-line option.  I think (2)
and (3) are possible with our CMake-based build system, but no PLplot
developer has yet investigated what CMake options are required (or
what other steps you have to do) to implement these features.  If you
are interested further, I would be willing to ask about these issues
on the CMake list.

Once you know how to deal with issue (2) and possibly (3), then cmake
provides fairly sophisticated facilities to create binary
distributions from the contents of the install tree.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-28 12:12-0700 Walt Brainerd wrote:

> [...]Then I tried copying the entire install directory to a different location
> (if they are to become part of the Fortran Tools, they need to run
> in an arbitrary location, so people can install them in different places).

Hi Walt:

It appears to me you have pin-pointed the issue; PLplot needs access
to Hershey font files, color map files, and the directory where the
drivers are located.  For example 19 to work it also needs access to
map files. All those data are installed in certain hard-coded
locations in the install tree.  So if you attempt to copy the install
directory to a different location, for example, and the original
installation is lost or inaccessible (say on a different computer),
PLplot won't be able to find the data it needs without all the
workarounds that Arjen mentioned.

CMake does support DESTDIR (see
<http://www.gnu.org/software/automake/manual/html_node/DESTDIR.html for
a discussion of that concept), and that might be some partial help to
you.  For example,

make DESTDIR=<staging directory> install

allows you to collect the installation files in a different "staging"
prefix location then their final location as specified by the CMake
cached variable CMAKE_INSTALL_PREFIX.  This is very helpful for
package managers.  And it also might be a help to you where you appear
to need additional install locations.  However, note that the
hard-coded locations referred to above all use the install prefix
specified by CMAKE_INSTALL_PREFIX (for obvious reasons since that is
the only install prefix known at build time) so if you used DESTDIR to
install PLplot with a lot of different install prefixes, those would
only work if you used the workarounds suggested by Arjen to help
PLplot find what it needed in the location specified by DESTDIR (as
opposed to the hard-coded locations with the CMAKE_INSTALL_PREFIX that
it already knows about).

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

SUCCESS!

The critical environment variable is PLPLOT_LIB, not that ENV thingie.

I found it in the excellent documentation. I know--that is cheating,
but I should have tried that again before pestering you guys.

Another question: if I (or you) provide this install directory as a
Windows binary distribution, how many systems do you think it
would work on?

Let's hope this continues to work :=). And thanks again for the help.

On Fri, Nov 28, 2014 at 3:26 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-11-28 08:30-0000 Arjen Markus wrote:
>
>  Hi Walt,
>>
>>
>>
>> I have encountered such messages myself - they are due to the PLplot
>> start up routines not being able to find the dynamic drivers (indeed they
>> reside in the DLLs in the "drivers" directory). Within the build tree, it
>> is easy enough for the routines to find them, but outside you may need to
>> set the environment variable PLPLOT_DRV_DIR.
>>
>>
>>
>> A further problem you would encounter is the location of the fonts and
>> some other files. For this set the environment variable PLPLOT_LIB_ENV to
>> the directory containing the .fnt and .al files. (Note that default values
>> are used that correspond to the installation prefix, but if there is some
>> discrepancy, then these environment variables will help out).
>>
>>
>>
>> A small caveat: I have not actually tried all of this just now (I scanned
>> the source code for the correct names), but in the not-so-distant past I
>> had to resort to this method, so I am confident it works. If not, let me
>> know and I will dive into it. Having done it before means I should be able
>> to find it quickly.
>>
>
> Hi Arjen and Walt:
>
> @Arjen: Just to clarify, I haven't tried extensive testing of the
> "MinGW Makefiles" generator case, and I know there are continuing
> PLplot problems with blanks in pathnames.  So for either of those
> cases, the above historical workarounds (or some other workaround)
> might be needed for Windows.  And also for 5.10.0, the "MSYS
> Makefiles" case with no blanks in pathnames passed some limited build
> tree tests but not install-tree tests.
>
> However, I just double-checked and for the git master branch (at least
> for commit id 3e817e8 on that branch that came after the release of
> 5.10.0,see details at the bottom of
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>), I finally
> got all comprehensive testing to work without issues for the the "MSYS
> Makefiles" case with no blanks in pathnames case.
>
> @Walt: I rarely do comprehensive testing on my Wine platform because
> it is an incredibly slow version of Windows (comprehensive tests take
> a couple of days of cpu time rather than a couple of hours). However,
> I don't anticipate that we have introduced any Windows build or test
> issue on the master branch since the last time I did that
> comprehensive test. Therefore, I suggest you use the latest git master
> branch version of PLplot and the "MinGW MSYS" generator with no blanks
> in any pathname to see if you can replicate the good Windows result I
> had for that case for an earlier master branch version.
>
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

As before, it seems I am making progress, but am stuck again.
First I moved cmake to a location with no spaces in its path name
and rebuilt plplot. All good as before.

Leaving the install files where  they were built, everything works with
the driversd and the bin directory in my PATH and PLPLOT_DRV_DIR
set to the driversd directory. PLPLOT_LIB_ENV doesn't seem to be
needed as you thought (A), but the DRV one did (if I got all the
combinations straight).

Then I tried copying the entire install directory to a different location
(if they are to become part of the Fortran Tools, they need to run
in an arbitrary location, so people can install them in different places).

I got the following, so it is apparently not finding the *.fnt *.map *pal
files.
Note below that PLPLOT_LIB_ENV is set.

===============
C:\walt\Software\Plplot\TEST_FT>a

Plotting Options:
 < 1> wingcc     Win32 (GCC)
 < 2> ps         PostScript File (monochrome)
 < 3> psc        PostScript File (color)
 < 4> xfig       Fig file
 < 5> null       Null device
 < 6> mem        User-supplied memory device
 < 7> svg        Scalable Vector Graphics (SVG 1.1)

Enter device number or keyword: 1

*** PLPLOT WARNING ***
Unable to open cmap0 file cmap0_default.pal


*** PLPLOT WARNING ***
Unable to open cmap0 file cmap0_default.pal


*** PLPLOT WARNING ***
Unable to open cmap1 .pal file cmap1_default.pal


*** PLPLOT ERROR, IMMEDIATE EXIT ***
Unable to either (1) open/find or (2) allocate memory for the font file
Program aborted

C:\walt\Software\Plplot\TEST_FT>echo %PATH%
C:\FortranTools\plplot\lib\plplot5.10.0\driversd;C:\FortranTools\plplot\bin;C:\x
xxwalt\Software\Gfortran\mingw64\bin;C:\ProgramData\Oracle\Java\javapath;C:\Fort
ranTools\bin;C:\FortranTools\gfortran\bin;C:\FortranTools\gtk\bin;C\FortranTools
\gnuplot\binary;C:\FortranTools\plplot\bin;C:\cygwin\bin;C:\Program Files
(x86)\
Intel\iCLS Client\;c:\Program Files\Intel\iCLS
Client\;C:\windows\system32;C:\wi
ndows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Pr
ogram Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Int
el\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\Intel\Intel(
R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R)
Manage
ment Engine Components\IPT;C:\Program
Files\Hewlett-Packard\SimplePass\;C:\Progr
am Files (x86)\Windows Live\Shared;C:\walt\Software\Cmake\bin

C:\walt\Software\Plplot\TEST_FT>dir
C:\FortranTools\plplot\share\plplot5.10.0
 Volume in drive C is Windows
 Volume Serial Number is DECB-58EB

 Directory of C:\FortranTools\plplot\share\plplot5.10.0

11/28/2014  11:14 AM    <DIR>          .
11/28/2014  11:14 AM    <DIR>          ..
03/11/2003  03:49 AM            57,192 cglobe.map
06/01/2011  01:50 PM               131 cmap0_alternate.pal
06/01/2011  01:50 PM               195 cmap0_black_on_white.pal
06/01/2011  01:50 PM               131 cmap0_default.pal
06/01/2011  01:50 PM               195 cmap0_white_bg.pal
06/01/2011  01:50 PM                51 cmap1_blue_red.pal
06/01/2011  01:50 PM               220 cmap1_blue_yellow.pal
06/01/2011  01:50 PM                80 cmap1_default.pal
06/01/2011  01:50 PM                69 cmap1_gray.pal
06/01/2011  01:50 PM                51 cmap1_highfreq.pal
06/01/2011  01:50 PM               105 cmap1_lowfreq.pal
06/01/2011  01:50 PM               426 cmap1_radar.pal
11/28/2014  11:14 AM    <DIR>          examples
03/11/2003  03:49 AM            33,602 globe.map
04/10/2010  10:05 PM             6,414 plstnd5.fnt
04/10/2010  10:05 PM            58,818 plxtnd5.fnt
03/11/2003  03:49 AM            44,530 usa.map
03/11/2003  03:49 AM            76,720 usaglobe.map
              17 File(s)        278,930 bytes
               3 Dir(s)  857,254,592,512 bytes free

C:\walt\Software\Plplot\TEST_FT>echo %PLPLOT_LIB_ENV%
C:\FortranTools\plplot\share\plplot5.10.0
======================================

I will try the latest trunk and MSYS if I can, but it looks like this
is working if I can tell it how to find these files.

Thanks again to both of you.

On Fri, Nov 28, 2014 at 3:26 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-11-28 08:30-0000 Arjen Markus wrote:
>
>  Hi Walt,
>>
>>
>>
>> I have encountered such messages myself - they are due to the PLplot
>> start up routines not being able to find the dynamic drivers (indeed they
>> reside in the DLLs in the "drivers" directory). Within the build tree, it
>> is easy enough for the routines to find them, but outside you may need to
>> set the environment variable PLPLOT_DRV_DIR.
>>
>>
>>
>> A further problem you would encounter is the location of the fonts and
>> some other files. For this set the environment variable PLPLOT_LIB_ENV to
>> the directory containing the .fnt and .al files. (Note that default values
>> are used that correspond to the installation prefix, but if there is some
>> discrepancy, then these environment variables will help out).
>>
>>
>>
>> A small caveat: I have not actually tried all of this just now (I scanned
>> the source code for the correct names), but in the not-so-distant past I
>> had to resort to this method, so I am confident it works. If not, let me
>> know and I will dive into it. Having done it before means I should be able
>> to find it quickly.
>>
>
> Hi Arjen and Walt:
>
> @Arjen: Just to clarify, I haven't tried extensive testing of the
> "MinGW Makefiles" generator case, and I know there are continuing
> PLplot problems with blanks in pathnames.  So for either of those
> cases, the above historical workarounds (or some other workaround)
> might be needed for Windows.  And also for 5.10.0, the "MSYS
> Makefiles" case with no blanks in pathnames passed some limited build
> tree tests but not install-tree tests.
>
> However, I just double-checked and for the git master branch (at least
> for commit id 3e817e8 on that branch that came after the release of
> 5.10.0,see details at the bottom of
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>), I finally
> got all comprehensive testing to work without issues for the the "MSYS
> Makefiles" case with no blanks in pathnames case.
>
> @Walt: I rarely do comprehensive testing on my Wine platform because
> it is an incredibly slow version of Windows (comprehensive tests take
> a couple of days of cpu time rather than a couple of hours). However,
> I don't anticipate that we have introduced any Windows build or test
> issue on the master branch since the last time I did that
> comprehensive test. Therefore, I suggest you use the latest git master
> branch version of PLplot and the "MinGW MSYS" generator with no blanks
> in any pathname to see if you can replicate the good Windows result I
> had for that case for an earlier master branch version.
>
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-28 08:30-0000 Arjen Markus wrote:

> Hi Walt,
>
>
>
> I have encountered such messages myself - they are due to the PLplot start up routines not being able to find the dynamic drivers (indeed they reside in the DLLs in the "drivers" directory). Within the build tree, it is easy enough for the routines to find them, but outside you may need to set the environment variable PLPLOT_DRV_DIR.
>
>
>
> A further problem you would encounter is the location of the fonts and some other files. For this set the environment variable PLPLOT_LIB_ENV to the directory containing the .fnt and .al files. (Note that default values are used that correspond to the installation prefix, but if there is some discrepancy, then these environment variables will help out).
>
>
>
> A small caveat: I have not actually tried all of this just now (I scanned the source code for the correct names), but in the not-so-distant past I had to resort to this method, so I am confident it works. If not, let me know and I will dive into it. Having done it before means I should be able to find it quickly.

Hi Arjen and Walt:

@Arjen: Just to clarify, I haven't tried extensive testing of the
"MinGW Makefiles" generator case, and I know there are continuing
PLplot problems with blanks in pathnames.  So for either of those
cases, the above historical workarounds (or some other workaround)
might be needed for Windows.  And also for 5.10.0, the "MSYS
Makefiles" case with no blanks in pathnames passed some limited build
tree tests but not install-tree tests.

However, I just double-checked and for the git master branch (at least
for commit id 3e817e8 on that branch that came after the release of
5.10.0,see details at the bottom of
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>), I finally
got all comprehensive testing to work without issues for the the "MSYS
Makefiles" case with no blanks in pathnames case.

@Walt: I rarely do comprehensive testing on my Wine platform because
it is an incredibly slow version of Windows (comprehensive tests take
a couple of days of cpu time rather than a couple of hours). However,
I don't anticipate that we have introduced any Windows build or test
issue on the master branch since the last time I did that
comprehensive test. Therefore, I suggest you use the latest git master
branch version of PLplot and the "MinGW MSYS" generator with no blanks
in any pathname to see if you can replicate the good Windows result I
had for that case for an earlier master branch version.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Plplot on Mingw

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

Hi Walt,



I am resending this message, as I got some mysterious error message from my mail client - not sure it did what it was supposed to do, so you may receive this twice.

Regards,

Arjen

From: Arjen Markus
Sent: Friday, November 28, 2014 9:30 AM
To: Walt Brainerd
Cc: plplot_general
Subject: RE: [Plplot-general] Plplot on Mingw


Hi Walt,



I have encountered such messages myself - they are due to the PLplot start up routines not being able to find the dynamic drivers (indeed they reside in the DLLs in the "drivers" directory). Within the build tree, it is easy enough for the routines to find them, but outside you may need to set the environment variable PLPLOT_DRV_DIR.



A further problem you would encounter is the location of the fonts and some other files. For this set the environment variable PLPLOT_LIB_ENV to the directory containing the .fnt and .al files. (Note that default values are used that correspond to the installation prefix, but if there is some discrepancy, then these environment variables will help out).



A small caveat: I have not actually tried all of this just now (I scanned the source code for the correct names), but in the not-so-distant past I had to resort to this method, so I am confident it works. If not, let me know and I will dive into it. Having done it before means I should be able to find it quickly.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, November 28, 2014 3:44 AM
> To: Walt Brainerd
> Cc: plplot_general
> Subject: Re: [Plplot-general] Plplot on Mingw
>
> On 2014-11-27 14:30-0700 Walt Brainerd wrote:
>
> > Thanks for your usual very helpful reply.
> > I guess Canada has a different Thanksgiving Day than the US, so you
> > are tending to work as usual.
> >
> > I did most of what you said. My message was already wordy so I left
> > out that I did the build with "install" as the prefix.
> > As you saw from before, I moved all the dll and library files into one
> > directory with the f90 file for the test--and it worked.
> > That is a real puzzle. Now it doesn't. Obviously something must have
> > changed, but I can't figure out what.
> >
> > But based on your suggestions, this time I compiled the Fortran by
> > using -I to find the .mod files and explicitly linked the *.a files in
> > install/lib. It links fine. Just for completeness, here is the command
> > I used to compile.
> >
> > C:\walt\Software\Plplot\TEST_FT>type compile.bat gfortran -c
> > -I../BUILD/install/lib/fortran/modules/plplot ft_x00f.f90 gfortran *.o
> > ../BUILD/install/lib/*.a
> >
> > I have both the ...\install and the ...\install\bin directories in my
> > PATH. I still get
> >
> > *** PLPLOT ERROR, ABORTING OPERATION ***
> > plInitDispatchTable: Could not open drivers directory, aborting
> > operation
> >
> > C:\walt\Software\Plplot>echo %PATH%
> > C:\walt\Software\Plplot\BUILD\install\bin;
> > C:\walt\Software\Plplot\BUILD\install;
> > C:\walt\Software\Gfortran\mingw64\bin;C:\Program Files
> > (x86)\Cmake\bin;C:\Progra  . . .
> >
> > Is it looking for the "driversd" directory? I think it is where it
> > should be at ...\install\lib\plplot5.10.0\driversd and contains 6 dlls
> > (I still am not getting all the drivers I got with Cygwin). I even
> > tried putting the driversd directory in my path--no deal.
>
> Hi Walt:
>
> There are two possibilities I can think of.
>
> 1. PLplot does not work very well if there are blanks in path names (such as
> C:\Program Files above).  We have made some progress on such issues in the last
> year, but I suspect there are a lot more of these issues to be found and fixed so until
> we get that completely straightened out PLplot users should work around the
> problem by avoiding all paths with blanks in the name.
>
> 2. The "MinGW Makefiles" is not as well tested as the "MSYS Makefiles"
> generator so you might want to try the latter.
>
> Other than those two possibilities, I am pretty much out of ideas.
> This stuff just works fine on MinGW/MSYS on my Wine version of Windows (with the
> "MSYS Makefiles" generator and no blanks in any path names), but outside of
> automatic and extremely comprehensive PLplot testing scripts working fine on that
> platform (including accessing all installed devices without issues), I have very little
> other experience with Windows 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
> __________________________
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate!
> Instantly Supercharge Your Business Reports and Dashboards with Interactivity,
> Sharing, Native Excel Exports, App Integration & more Get technology previously
> reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...<mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-general

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

Re: [Plplot-general] Plplot on Mingw

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

Hi Walt,



I have encountered such messages myself - they are due to the PLplot start up routines not being able to find the dynamic drivers (indeed they reside in the DLLs in the "drivers" directory). Within the build tree, it is easy enough for the routines to find them, but outside you may need to set the environment variable PLPLOT_DRV_DIR.



A further problem you would encounter is the location of the fonts and some other files. For this set the environment variable PLPLOT_LIB_ENV to the directory containing the .fnt and .al files. (Note that default values are used that correspond to the installation prefix, but if there is some discrepancy, then these environment variables will help out).



A small caveat: I have not actually tried all of this just now (I scanned the source code for the correct names), but in the not-so-distant past I had to resort to this method, so I am confident it works. If not, let me know and I will dive into it. Having done it before means I should be able to find it quickly.



Regards,



Arjen




> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, November 28, 2014 3:44 AM
> To: Walt Brainerd
> Cc: plplot_general
> Subject: Re: [Plplot-general] Plplot on Mingw
>
> On 2014-11-27 14:30-0700 Walt Brainerd wrote:
>
> > Thanks for your usual very helpful reply.
> > I guess Canada has a different Thanksgiving Day than the US, so you
> > are tending to work as usual.
> >
> > I did most of what you said. My message was already wordy so I left
> > out that I did the build with "install" as the prefix.
> > As you saw from before, I moved all the dll and library files into one
> > directory with the f90 file for the test--and it worked.
> > That is a real puzzle. Now it doesn't. Obviously something must have
> > changed, but I can't figure out what.
> >
> > But based on your suggestions, this time I compiled the Fortran by
> > using -I to find the .mod files and explicitly linked the *.a files in
> > install/lib. It links fine. Just for completeness, here is the command
> > I used to compile.
> >
> > C:\walt\Software\Plplot\TEST_FT>type compile.bat gfortran -c
> > -I../BUILD/install/lib/fortran/modules/plplot ft_x00f.f90 gfortran *.o
> > ../BUILD/install/lib/*.a
> >
> > I have both the ...\install and the ...\install\bin directories in my
> > PATH. I still get
> >
> > *** PLPLOT ERROR, ABORTING OPERATION ***
> > plInitDispatchTable: Could not open drivers directory, aborting
> > operation
> >
> > C:\walt\Software\Plplot>echo %PATH%
> > C:\walt\Software\Plplot\BUILD\install\bin;
> > C:\walt\Software\Plplot\BUILD\install;
> > C:\walt\Software\Gfortran\mingw64\bin;C:\Program Files
> > (x86)\Cmake\bin;C:\Progra  . . .
> >
> > Is it looking for the "driversd" directory? I think it is where it
> > should be at ...\install\lib\plplot5.10.0\driversd and contains 6 dlls
> > (I still am not getting all the drivers I got with Cygwin). I even
> > tried putting the driversd directory in my path--no deal.
>
> Hi Walt:
>
> There are two possibilities I can think of.
>
> 1. PLplot does not work very well if there are blanks in path names (such as
> C:\Program Files above).  We have made some progress on such issues in the last
> year, but I suspect there are a lot more of these issues to be found and fixed so until
> we get that completely straightened out PLplot users should work around the
> problem by avoiding all paths with blanks in the name.
>
> 2. The "MinGW Makefiles" is not as well tested as the "MSYS Makefiles"
> generator so you might want to try the latter.
>
> Other than those two possibilities, I am pretty much out of ideas.
> This stuff just works fine on MinGW/MSYS on my Wine version of Windows (with the
> "MSYS Makefiles" generator and no blanks in any path names), but outside of
> automatic and extremely comprehensive PLplot testing scripts working fine on that
> platform (including accessing all installed devices without issues), I have very little
> other experience with Windows 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
> __________________________
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate!
> Instantly Supercharge Your Business Reports and Dashboards with Interactivity,
> Sharing, Native Excel Exports, App Integration & more Get technology previously
> reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

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

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-27 14:30-0700 Walt Brainerd wrote:

> Thanks for your usual very helpful reply.
> I guess Canada has a different Thanksgiving Day than the US,
> so you are tending to work as usual.
>
> I did most of what you said. My message was already wordy
> so I left out that I did the build with "install" as the prefix.
> As you saw from before, I moved all the dll and library files
> into one directory with the f90 file for the test--and it worked.
> That is a real puzzle. Now it doesn't. Obviously something
> must have changed, but I can't figure out what.
>
> But based on your suggestions, this time I compiled the Fortran
> by using -I to find the .mod files and explicitly linked the *.a files
> in install/lib. It links fine. Just for completeness, here is the
> command I used to compile.
>
> C:\walt\Software\Plplot\TEST_FT>type compile.bat
> gfortran -c -I../BUILD/install/lib/fortran/modules/plplot ft_x00f.f90
> gfortran *.o ../BUILD/install/lib/*.a
>
> I have both the ...\install and the ...\install\bin directories in
> my PATH. I still get
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> plInitDispatchTable: Could not open drivers directory, aborting operation
>
> C:\walt\Software\Plplot>echo %PATH%
> C:\walt\Software\Plplot\BUILD\install\bin;
> C:\walt\Software\Plplot\BUILD\install;
> C:\walt\Software\Gfortran\mingw64\bin;C:\Program Files
> (x86)\Cmake\bin;C:\Progra  . . .
>
> Is it looking for the "driversd" directory? I think it is where it should be
> at ...\install\lib\plplot5.10.0\driversd and contains 6 dlls (I still am not
> getting all the drivers I got with Cygwin). I even tried putting the
> driversd directory in my path--no deal.

Hi Walt:

There are two possibilities I can think of.

1. PLplot does not work very well if there are blanks in path names
(such as C:\Program Files above).  We have made some progress on such
issues in the last year, but I suspect there are a lot more of these
issues to be found and fixed so until we get that completely
straightened out PLplot users should work around the problem by
avoiding all paths with blanks in the name.

2. The "MinGW Makefiles" is not as well tested as the "MSYS Makefiles"
generator so you might want to try the latter.

Other than those two possibilities, I am pretty much out of ideas.
This stuff just works fine on MinGW/MSYS on my Wine version of Windows
(with the "MSYS Makefiles" generator and no blanks in any path names),
but outside of automatic and extremely comprehensive PLplot testing
scripts working fine on that platform (including accessing all
installed devices without issues), I have very little other experience
with Windows 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-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

Thanks for your usual very helpful reply.
I guess Canada has a different Thanksgiving Day than the US,
so you are tending to work as usual.

I did most of what you said. My message was already wordy
so I left out that I did the build with "install" as the prefix.
As you saw from before, I moved all the dll and library files
into one directory with the f90 file for the test--and it worked.
That is a real puzzle. Now it doesn't. Obviously something
must have changed, but I can't figure out what.

But based on your suggestions, this time I compiled the Fortran
by using -I to find the .mod files and explicitly linked the *.a files
in install/lib. It links fine. Just for completeness, here is the
command I used to compile.

C:\walt\Software\Plplot\TEST_FT>type compile.bat
gfortran -c -I../BUILD/install/lib/fortran/modules/plplot ft_x00f.f90
gfortran *.o ../BUILD/install/lib/*.a

I have both the ...\install and the ...\install\bin directories in
my PATH. I still get

*** PLPLOT ERROR, ABORTING OPERATION ***
plInitDispatchTable: Could not open drivers directory, aborting operation

C:\walt\Software\Plplot>echo %PATH%
C:\walt\Software\Plplot\BUILD\install\bin;
C:\walt\Software\Plplot\BUILD\install;
C:\walt\Software\Gfortran\mingw64\bin;C:\Program Files
(x86)\Cmake\bin;C:\Progra  . . .

Is it looking for the "driversd" directory? I think it is where it should be
at ...\install\lib\plplot5.10.0\driversd and contains 6 dlls (I still am not
getting all the drivers I got with Cygwin). I even tried putting the
driversd directory in my path--no deal.

It still somehow needs info about the location of some drivers ???

On Thu, Nov 27, 2014 at 1:17 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-11-27 12:20-0700 Walt Brainerd wrote:
>
>  I have again decided to try to build and run Plplot.
>>
>> I am running Windows 8
>>
>> I got it to work fine using Cygwin.
>>
>> I tried many many combinations of Mingw configurations
>> (TDM 32 seems to work, but I want to run 64). Finally, I
>> got one to build and the compile and run a Fortran example.
>>
>> I messed around trying to put the compiler and plplot files
>> in the place I want them permanently, then went back to the
>> test directory and the executable didn't work any more. I get
>> the following: [...]
>>
>
> Hi Walt:
>
> The build tree is a really messy and disorganized place with all sorts
> of stuff there that is relevant to builds but not users needs.
> Therefore, virtually all software packages (including PLplot) are
> organized so that it is possible to copy the user essentials from a
> wide variety of locations in the build tree (chosen with the needs of
> building software in mind rather than the needs of the user) to known
> logical locations (chosen with the needs of the user in mind) in a
> completely separate area called the install tree.
>
> With PLplot (and most other software) you do this essential install
> step by configuring an install prefix with cmake, and once that cmake
> command finishes (preferably starting with an empty build tree) by
> running "make install".
>
> My suggestion is to run "make install" instead of trying to replicate
> most of what it does by hand.  After doing that, please take a look at
> the locations of everything in the install tree; I think you will find
> it quite convenient for your needs.
>
> For example, once PLplot is installed, you should set
> compile options and link options when building _your own code_
> so the compiler finds the PLplot headers in the install tree, and
> the linker finds the PLplot libraries in the install tree.
>
> Afterward, when the run-time loader runs your programme it will need
> to know the location of the PLplot libraries.  On Windows that is
> simply done by putting <prefix>/bin on your PATH (where <prefix> is
> the install prefix you chose when you ran the "cmake" command). That
> should be all you need to do since the PLplot core library alreadys
> knows the installed location of everything else (e.g., driver
> location, map files, fonts, etc.) in the install tree.
>
> In sum, start with "make install", and if the above suggestions do not
> give you sufficient guidance about how to build your own code against
> installed PLplot, then ask more questions here.
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Plplot on Mingw

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

On 2014-11-27 12:20-0700 Walt Brainerd wrote:

> I have again decided to try to build and run Plplot.
>
> I am running Windows 8
>
> I got it to work fine using Cygwin.
>
> I tried many many combinations of Mingw configurations
> (TDM 32 seems to work, but I want to run 64). Finally, I
> got one to build and the compile and run a Fortran example.
>
> I messed around trying to put the compiler and plplot files
> in the place I want them permanently, then went back to the
> test directory and the executable didn't work any more. I get
> the following: [...]

Hi Walt:

The build tree is a really messy and disorganized place with all sorts
of stuff there that is relevant to builds but not users needs.
Therefore, virtually all software packages (including PLplot) are
organized so that it is possible to copy the user essentials from a
wide variety of locations in the build tree (chosen with the needs of
building software in mind rather than the needs of the user) to known
logical locations (chosen with the needs of the user in mind) in a
completely separate area called the install tree.

With PLplot (and most other software) you do this essential install
step by configuring an install prefix with cmake, and once that cmake
command finishes (preferably starting with an empty build tree) by
running "make install".

My suggestion is to run "make install" instead of trying to replicate
most of what it does by hand.  After doing that, please take a look at
the locations of everything in the install tree; I think you will find
it quite convenient for your needs.

For example, once PLplot is installed, you should set
compile options and link options when building _your own code_
so the compiler finds the PLplot headers in the install tree, and
the linker finds the PLplot libraries in the install tree.

Afterward, when the run-time loader runs your programme it will need
to know the location of the PLplot libraries.  On Windows that is
simply done by putting <prefix>/bin on your PATH (where <prefix> is
the install prefix you chose when you ran the "cmake" command). That
should be all you need to do since the PLplot core library alreadys
knows the installed location of everything else (e.g., driver
location, map files, fonts, etc.) in the install tree.

In sum, start with "make install", and if the above suggestions do not
give you sufficient guidance about how to build your own code against
installed PLplot, then ask more questions here.

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
__________________________

[Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

program ft_x00f

! This is a modified version of x00f.f90
! which was written by Alan Irwin

   use plplot
   implicit none

   integer, parameter :: NSIZE = 100

   real(kind=plflt), dimension(0:NSIZE) :: x, y

   real(kind=plflt) :: xmin =   0.0_plflt, &
                       xmax =   1.0_plflt, &
                       ymin =   0.0_plflt, &
                       ymax = 100.0_plflt
   integer :: i

   ! Prepare data to be plotted.
   ! x = .00, .01, .02, ..., .99, 1.00
   x = [(i, i=0,NSIZE)] / real(NSIZE)
   y = ymax * x**2

   ! Parse and process command line arguments.
   call plparseopts( PL_PARSE_FULL )

   ! Initialize plplot
   call plinit( )

   ! Create a labelled box to hold the plot.
   call plenv( xmin, xmax, ymin, ymax, just=0, axis=0 )
   call pllab( "x", "y=100 x#u2#d", &
               "Simple PLplot demo of a 2D line plot" )

   ! Plot the data that was prepared above.
   call plline( x, y )

   ! Close Pl+plot library
   call plend( )

end program ft_x00f

Re: [Plplot-general] Question compiling examples with gfortan

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

Hello Greg,

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

>
> My guess is that is an error message from the run-time loader.  One way to avoid this
> issue is to set rpath.  See <prefix>/share/plplot5.10.0/examples/f95/Makefile for an
> example of how our traditional build system (based on make and pkg-config) handles
> this issue.  Another possibility is to set the environment variable LD_LIBRARY_PATH
> to help the run-time loader find the installed version of libplplotf95d.so.11 that you
> just built on your system (if that is what you did, see first question).
>


This type of messages is indeed an indication that the loader can not find the shared objects. (You are actually lucky that you get such a clear message, as on Windows quite often the program simply stops immediately and one has to guess the cause :().



Anyway, the errors you reported earlier about the compiler not finding a specific routine for the generic name plshades could be due to an error in the type (and kind and dimension) of one of the arguments. You have been able to solve the error, but just for future reference, keep this in mind.



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-general] Question compiling examples with gfortan

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

On 2014-11-18 23:03-0600 Struct Engr wrote:

> I have installed Plplot-5.10.0 as noted in my previous email.

Please clarify that statement; did you install a binary version from
the Ubuntu package or did you build and install PLplot from source?


> I found the
> following command

where?

> to compile with and the error meesages regarding plshades
> did not appear:
>
> gfortran -o main main.f90
> `PKG_CONFIG_PATH=/home/greg/plplot/install_directory/lib/pkgconfig
> pkg-config --cflags --libs plplotd-f95`

The reason why I ask "where" is if this is from our wiki I would like
to correct it since it is incomplete (it omits setting rpath
information).

>
> It appears to have worked (execcutable file main created) and no error
> messages.  However when I try to run the program with the following command:
>
> ./main
>
> I get the following error message:
>
> ./main: error while loading shared libraries: libplplotf95d.so.11: cannot
> open shared object file: No such file or directory

My guess is that is an error message from the run-time loader.  One
way to avoid this issue is to set rpath.  See
<prefix>/share/plplot5.10.0/examples/f95/Makefile for an example of
how our traditional build system (based on make and pkg-config)
handles this issue.  Another possibility is to set the environment
variable LD_LIBRARY_PATH to help the run-time loader find the
installed version of libplplotf95d.so.11 that you just built on your
system (if that is what you did, see first question).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-general] Question compiling examples with gfortan

[Struct E. <str...@gm...>]

I have installed Plplot-5.10.0 as noted in my previous email.  I found the
following command to compile with and the error meesages regarding plshades
did not appear:

gfortran -o main main.f90
`PKG_CONFIG_PATH=/home/greg/plplot/install_directory/lib/pkgconfig
pkg-config --cflags --libs plplotd-f95`

It appears to have worked (execcutable file main created) and no error
messages.  However when I try to run the program with the following command:

./main

I get the following error message:

./main: error while loading shared libraries: libplplotf95d.so.11: cannot
open shared object file: No such file or directory

Any help to resolve this would be appreciated.

Thanks

On Tue, Nov 18, 2014 at 2:32 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2014-11-17 22:46-0600 Struct Engr wrote:
>
>  I have installed plplot on Ubuntu 12.04 for use with gfortran (f95).  I
>> was
>> able to compile and run plplot example 1 in fortran.  My goal is to use
>> plplot for color contour plots.  But when I run the following contours
>> example:
>>
>> plshades demo, using color fill
>>
>> I get the following errors:
>>
>> ||=== Build: Debug in Test PLplot (compiler: GNU Fortran Compiler) ===|
>> /home/greg/Test PLplot/main.f90|133|/home/greg/Test PLplot/main.f90 133
>> .127:|
>> ||Error: There is no specific subroutine for the generic 'plshades'  |
>> /home/greg/Test PLplot/main.f90|181|/home/greg/Test PLplot/main.f90 181
>> .51:|
>> ||Error: There is no specific subroutine for the generic 'plshades'  |
>> /home/greg/Test PLplot/main.f90|229|/home/greg/Test PLplot/main.f90 229
>> .60:|
>> ||Error: There is no specific subroutine for the generic 'plshades'  |
>> /home/greg/Test PLplot/main.f90|278|/home/greg/Test PLplot/main.f90 278
>> .60:|
>> ||Error: There is no specific subroutine for the generic 'plshades'  |
>> /home/greg/Test PLplot/main.f90|343|/home/greg/Test PLplot/main.f90 343
>> .60:|
>> ||Error: There is no specific subroutine for the generic 'plshades'  |
>> ||=== Build failed: 5 error(s), 0 warning(s) (0 minute(s), 0 second(s))
>> ===|
>>
>>
>> I do not know why it finds other plplot subroutines but not plshades.  I
>> have installed PLplot-5.10.0 using cmake.  Is it possible plshades is
>> missing from the library?
>>
>> Help would be appreciated.
>>
>
> Hi Greg:
>
> In case, that Ubuntu binary version is broken in some way, I suggest
> you follow the directions in our Wiki
> <https://sourceforge.net/p/plplot/wiki/Home/> for downloading 5.10.0
> and building and testing that version of PLplot.
>
> Note, if there is anything in that Wiki that needs clarification,
> please bring it to our attention here so we can fix it.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>

Re: [Plplot-general] Question compiling examples with gfortan

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

On 2014-11-17 22:46-0600 Struct Engr wrote:

> I have installed plplot on Ubuntu 12.04 for use with gfortran (f95).  I was
> able to compile and run plplot example 1 in fortran.  My goal is to use
> plplot for color contour plots.  But when I run the following contours
> example:
>
> plshades demo, using color fill
>
> I get the following errors:
>
> ||=== Build: Debug in Test PLplot (compiler: GNU Fortran Compiler) ===|
> /home/greg/Test PLplot/main.f90|133|/home/greg/Test PLplot/main.f90 133
> .127:|
> ||Error: There is no specific subroutine for the generic 'plshades'  |
> /home/greg/Test PLplot/main.f90|181|/home/greg/Test PLplot/main.f90 181
> .51:|
> ||Error: There is no specific subroutine for the generic 'plshades'  |
> /home/greg/Test PLplot/main.f90|229|/home/greg/Test PLplot/main.f90 229
> .60:|
> ||Error: There is no specific subroutine for the generic 'plshades'  |
> /home/greg/Test PLplot/main.f90|278|/home/greg/Test PLplot/main.f90 278
> .60:|
> ||Error: There is no specific subroutine for the generic 'plshades'  |
> /home/greg/Test PLplot/main.f90|343|/home/greg/Test PLplot/main.f90 343
> .60:|
> ||Error: There is no specific subroutine for the generic 'plshades'  |
> ||=== Build failed: 5 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|
>
>
> I do not know why it finds other plplot subroutines but not plshades.  I
> have installed PLplot-5.10.0 using cmake.  Is it possible plshades is
> missing from the library?
>
> Help would be appreciated.

Hi Greg:

In case, that Ubuntu binary version is broken in some way, I suggest
you follow the directions in our Wiki
<https://sourceforge.net/p/plplot/wiki/Home/> for downloading 5.10.0
and building and testing that version of PLplot.

Note, if there is anything in that Wiki that needs clarification,
please bring it to our attention here so we can fix it.

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
__________________________

[Plplot-general] Question compiling examples with gfortan

[Struct E. <str...@gm...>]

I have installed plplot on Ubuntu 12.04 for use with gfortran (f95).  I was
able to compile and run plplot example 1 in fortran.  My goal is to use
plplot for color contour plots.  But when I run the following contours
example:

plshades demo, using color fill

I get the following errors:

||=== Build: Debug in Test PLplot (compiler: GNU Fortran Compiler) ===|
/home/greg/Test PLplot/main.f90|133|/home/greg/Test PLplot/main.f90 133
.127:|
||Error: There is no specific subroutine for the generic 'plshades'  |
/home/greg/Test PLplot/main.f90|181|/home/greg/Test PLplot/main.f90 181
.51:|
||Error: There is no specific subroutine for the generic 'plshades'  |
/home/greg/Test PLplot/main.f90|229|/home/greg/Test PLplot/main.f90 229
.60:|
||Error: There is no specific subroutine for the generic 'plshades'  |
/home/greg/Test PLplot/main.f90|278|/home/greg/Test PLplot/main.f90 278
.60:|
||Error: There is no specific subroutine for the generic 'plshades'  |
/home/greg/Test PLplot/main.f90|343|/home/greg/Test PLplot/main.f90 343
.60:|
||Error: There is no specific subroutine for the generic 'plshades'  |
||=== Build failed: 5 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|


I do not know why it finds other plplot subroutines but not plshades.  I
have installed PLplot-5.10.0 using cmake.  Is it possible plshades is
missing from the library?

Help would be appreciated.

Thanks,
Greg

Re: [Plplot-general] How do I rotate tick labels for an axis using plplot?

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

On 2014-11-01 03:48-0400 Jamil Egdemir wrote:

> Looking through the PLPlot [documentation][3] I found reference to
> [plslabelfunc][4] but I'm not sure how to use this to achieve my goal.

Hi Jamil:

I have never used plslabelfunc myself, but standard example 19 might
be of some help to you since that does use plslabelfunc.

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
__________________________