PLplot

On 2007-09-04 14:32-0400 Salazar, German P21322 wrote:

> Well, I am back, although I have now changed the topic title to "replot".
>
> Like I said before, my ultimate objective is to have a single ps document where, say, pages 1 and 3 are in landscape and page 2 in portrait; that, I can already do with a small script if I have the two original files, one with all pages in landscape and another with all pages in portrait...then, I can pick and choose what pages I want in the final document.
>
> Here is the thing:
> I have managed to plot in landscape (no surprise there, that is the default).
> I have managed to plot in portrait, for real; the one option that does it is command line argument -portrait, and not plsdiori.
> I have also managed to do both things above in a single run by opening two streams, one left alone (landscape) and another set to protrait.  This way I end up with I what need.
>
> So, basically, I am done.
>
> The thing is that I see a couple of C examples with the plreplot() command and I thought that was a lot more elegant than having to open two streams at the begining, keep switching/plotting to both streams at all times, and closing both streams at the end. Just doing everything once and saving a copy of it at the end seems simpler, if I can change from landscape to portrait right before the replot...except that I couldn't get there, since plreplot() will not work for me from Fortran...curiously enough, there are two C examples that use plreplot() but none in Fortran...does this mean something, i.e., plreplot does not work from fortran?
>
> Here is the message:
>
> *** PLPLOT WARNING ***
> plreplot: plot buffer not available

I got this to work, but only under special circumstances for both the C and
Fortran 77 version of our examples.

Here is the fortran patch for example 1.
****************
--- x01f.f_original     2007-09-04 12:01:35.000000000 -0700
+++ x01f.f      2007-09-04 12:36:20.000000000 -0700
@@ -28,6 +28,7 @@
        integer digmax
        integer PL_PARSE_FULL
        parameter(PL_PARSE_FULL = 1)
+      integer cur_strm, new_strm
  C      some fortran compilers demand typing of intrinsic lnblnk, and
  C      although this is not demanded on g77 it also works there.
        integer lnblnk
@@ -72,6 +73,19 @@

        call plot2()
        call plot3()
+      ! Test whether can work with streams and plreplot from fortran.
+      call plgstrm(cur_strm)!      /*get current stream */
+      call plmkstrm(new_strm)!   /* create a new one */ 
+ 
+      call plsfnam("test_stream.ps")!       /* file name */
+      call plsdev("psc")!         /* device type */
+
+      call plcpstrm(cur_strm, 0)! /* copy old stream parameters to new stream */
+      call plreplot()!      /* do the save by replaying the plot buffer */
+      call plend1()!              /* finish the device */
+
+      call plsstrm(cur_strm)!     /* return to previous stream */
+
  C      Don't forget to call PLEND to finish off!

        call plend()
****************

Ordinarily, I would like to make this patch part of the fortran version of
example 1, but plMergeOpts (which allows parsing of extra command-line
options for any given application) is not part of the Fortran interface so
there is no easy way to parse the -save option for example 1 in fortran.
Instead, I have used a fixed name (test_stream.ps) here, which of course
would not be suitable in general.  Nevertheless, this patch is a good test
that plgstrm, plmkstrm, plsfnam, plsdev, plcpstrm, and plreplot are all
implemented correctly in Fortran (77) to call the appropriate C library
routines with the appropriate arguments since I got identical results with
this patch to the equivalent C routine using the command-line option

"-save test_stream.ps"

Now a comment on the "special circumstances" referred to above.

If you run

./x01c -save test_stream.ps -dev <device>

with <device> set to either psc or xcairo you get the

*** PLPLOT WARNING ***
plreplot: plot buffer not available

warning referred to by German above.  However, if you specify the xwin or tk
devices you do produce a good plot in test_stream.ps.  I assume what is
going on is xwin and tk set up a plot buffer and the other devices do not.

Another issue for -dev xwin and -dev tk is that after they create a good
test_stream.ps file both the C and patched Fortran example 1 produces a
segfault.

German, obviously the current limitations of the plreplot capability are so
severe that it is not useful to your needs, but I thought I should make some
general comments about what is wrong in case some developers got moved to
deal with one of the following issues that came up from my investigation:

(1) Implement plmergeopts for fortran.

(2) plot buffer capability expanded to more devices

(3) Deal with the above segfault.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan:

Thanks for such a complete report.

I guess there are too many tricks to make plreplot work from =
Fortran...tricks that will eventually trip somebody over at some point; =
not to mention that, like I said before, I am going =
multi-platform...Solaris, Linux, Windows...so the xwin thing may not fly =
to good there. Also, I mentioned earlier that we couldn't make the =
plplot installation befriend Active State's tcl installation, which =
leaves tk out of the picture, too.  I was already refered to some =
instructions, but I have no re-visited that link.

I will stick with dual streams, since it works without any tricks.

Thanks, again.

Germ=E1n
=20

-----Original Message-----
From: Alan W. Irwin [mailto:irwin@...
Sent: Tuesday, September 04, 2007 4:15 PM
To: Salazar, German P21322
Cc: plplot-general@...
Subject: Re: [Plplot-general] replot: buffer not available (thread =
started as "post processing with plrender")

On 2007-09-04 14:32-0400 Salazar, German P21322 wrote:

> Well, I am back, although I have now changed the topic title to =
"replot".
>
> Like I said before, my ultimate objective is to have a single ps =
document where, say, pages 1 and 3 are in landscape and page 2 in =
portrait; that, I can already do with a small script if I have the two =
original files, one with all pages in landscape and another with all =
pages in portrait...then, I can pick and choose what pages I want in the =
final document.
>
> Here is the thing:
> I have managed to plot in landscape (no surprise there, that is the =
default).
> I have managed to plot in portrait, for real; the one option that does =
it is command line argument -portrait, and not plsdiori.
> I have also managed to do both things above in a single run by opening =
two streams, one left alone (landscape) and another set to protrait.  =
This way I end up with I what need.
>
> So, basically, I am done.
>
> The thing is that I see a couple of C examples with the plreplot() =
command and I thought that was a lot more elegant than having to open =
two streams at the begining, keep switching/plotting to both streams at =
all times, and closing both streams at the end. Just doing everything =
once and saving a copy of it at the end seems simpler, if I can change =
from landscape to portrait right before the replot...except that I =
couldn't get there, since plreplot() will not work for me from =
Fortran...curiously enough, there are two C examples that use plreplot() =
but none in Fortran...does this mean something, i.e., plreplot does not =
work from fortran?
>
> Here is the message:
>
> *** PLPLOT WARNING ***
> plreplot: plot buffer not available

I got this to work, but only under special circumstances for both the C =
and
Fortran 77 version of our examples.

Here is the fortran patch for example 1.
****************
--- x01f.f_original     2007-09-04 12:01:35.000000000 -0700
+++ x01f.f      2007-09-04 12:36:20.000000000 -0700
@@ -28,6 +28,7 @@
        integer digmax
        integer PL_PARSE_FULL
        parameter(PL_PARSE_FULL =3D 1)
+      integer cur_strm, new_strm
  C      some fortran compilers demand typing of intrinsic lnblnk, and
  C      although this is not demanded on g77 it also works there.
        integer lnblnk
@@ -72,6 +73,19 @@

        call plot2()
        call plot3()
+      ! Test whether can work with streams and plreplot from fortran.
+      call plgstrm(cur_strm)!      /*get current stream */
+      call plmkstrm(new_strm)!   /* create a new one */=20
+=20
+      call plsfnam("test_stream.ps")!       /* file name */
+      call plsdev("psc")!         /* device type */
+
+      call plcpstrm(cur_strm, 0)! /* copy old stream parameters to new =
stream */
+      call plreplot()!      /* do the save by replaying the plot buffer =
*/
+      call plend1()!              /* finish the device */
+
+      call plsstrm(cur_strm)!     /* return to previous stream */
+
  C      Don't forget to call PLEND to finish off!

        call plend()
****************

Ordinarily, I would like to make this patch part of the fortran version =
of
example 1, but plMergeOpts (which allows parsing of extra command-line
options for any given application) is not part of the Fortran interface =
so
there is no easy way to parse the -save option for example 1 in fortran.
Instead, I have used a fixed name (test_stream.ps) here, which of course
would not be suitable in general.  Nevertheless, this patch is a good =
test
that plgstrm, plmkstrm, plsfnam, plsdev, plcpstrm, and plreplot are all
implemented correctly in Fortran (77) to call the appropriate C library
routines with the appropriate arguments since I got identical results =
with
this patch to the equivalent C routine using the command-line option

"-save test_stream.ps"

Now a comment on the "special circumstances" referred to above.

If you run

./x01c -save test_stream.ps -dev <device>

with <device> set to either psc or xcairo you get the

*** PLPLOT WARNING ***
plreplot: plot buffer not available

warning referred to by German above.  However, if you specify the xwin =
or tk
devices you do produce a good plot in test_stream.ps.  I assume what is
going on is xwin and tk set up a plot buffer and the other devices do =
not.

Another issue for -dev xwin and -dev tk is that after they create a good
test_stream.ps file both the C and patched Fortran example 1 produces a
segfault.

German, obviously the current limitations of the plreplot capability are =
so
severe that it is not useful to your needs, but I thought I should make =
some
general comments about what is wrong in case some developers got moved =
to
deal with one of the following issues that came up from my =
investigation:

(1) Implement plmergeopts for fortran.

(2) plot buffer capability expanded to more devices

(3) Deal with the above segfault.

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); PLplot scientific plotting =
software
package (plplot.org); 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
__________________________

=20
Well, we went ahead and installed the latest and greatest plplot.
Before, we had only included a couple of drivers (ps and psc) and a
couple of bindings (C and Fortran).  This time, though, we enabled as
many drivers as we could (X, pdf, etc) and several language bindings
(C++, tcl/tk, etc.)...now, the one compilation process that I was
following before does not work anymore...I am getting a long list of
"undefined reference" messages:

/usw/ude/Linux/lib/libplplotd.a(tk.o)(.text+0x2850): In function
`link_init':
: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usw/ude/Linux/lib/libplplotd.a(gd.o)(.text+0xa22): In function
`plD_line_png':
: undefined reference to `gdImageLine'
/usw/ude/Linux/lib/libplplotd.a(gd.o)(.text+0xbe0): In function
`fill_polygon':
: undefined reference to `gdImageFilledPolygon'
/usw/ude/Linux/lib/libplplotd.a(gd.o)(.text+0xc3e): In function
`setcmap':
: undefined reference to `gdImageColorDeallocate'
.
.
.
/usw/ude/Linux/lib/libplplotd.a(pdf.o)(.text+0x2d4): In function
`plD_init_pdf':
: undefined reference to `HPDF_Free'
/usw/ude/Linux/lib/libplplotd.a(pdf.o)(.text+0x31e): In function
`plD_bop_pdf':
: undefined reference to `HPDF_AddPage'
/usw/ude/Linux/lib/libplplotd.a(pdf.o)(.text+0x340): In function
`plD_bop_pdf':
: undefined reference to `HPDF_Page_SetSize'
/usw/ude/Linux/lib/libplplotd.a(pdf.o)(.text+0x369): In function
`plD_bop_pdf':
: undefined reference to `HPDF_Page_Concat'
.
.
.
/usw/ude/Linux/lib/libplplotd.a(tk.o)(.text+0x12fd): In function
`tk_di':
: undefined reference to `Tcl_SetVar'
/usw/ude/Linux/lib/libplplotd.a(tk.o)(.text+0x1380): In function
`tk_di':
: undefined reference to `Tcl_SetVar'
/usw/ude/Linux/lib/libplplotd.a(tk.o)(.text+0x13c2): In function
`tk_di':
: undefined reference to `Tcl_SetVar'
/usw/ude/Linux/lib/libplplotd.a(tk.o)(.text+0x1404): In function
`tk_di':

...and the list goes on.

Questions:=20

Why is it trying to use all these drivers if I am only using "psc" from
Fortran?
Is it possible that plplotd.a was not properly randomized and somehow
when I link it, I link the entire file?

Pointers would be much appreciated.

German

On 2007-09-06 15:12-0400 Salazar, German P21322 wrote:

> : undefined reference to `gdImageLine'
> /usw/ude/Linux/lib/libplplotd.a(gd.o)(.text+0xbe0): In function
> `fill_polygon':
>
> ...and the list goes on.
>
> Questions:
>
> Why is it trying to use all these drivers if I am only using "psc" from
> Fortran?
> Is it possible that plplotd.a was not properly randomized and somehow
> when I link it, I link the entire file?
>
> Pointers would be much appreciated.

Please give details of what you did, i.e., cmake command-line options and
full cmake output at minimum.  Also, identify your platform and be specific
about the "compile process" you are using.

In the absence of those details, I can only guess what the issue is.  It
appears from above that you have done a static library build for PLplot
which is a non-default configuration which we don't test very much.  So you
may have inadvertently found some external build issue for that case.  But
please give the details requested above so I can replicate the static build
issue here and fix it.

If you did not specifically go out of your way to specify a static library
build, then cmake probably found something missing on your system that
forced that.  To avoid that result, pay close attention to any warnings you
get from cmake concerning shared libraries and address the issue so you can
build shared libraries for PLplot.  Shared libraries are our most thoroughly
tested configuration.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Well, yes, as a matter of fact, we built plplot to generate static =
libraries; and I am also compiling a program to staticly link those =
libraries.

As far as platform and the like info goes, right now I am in Linux; but =
I will be doing the same thing for Solaris and Windows.

I am using the gcc and g95 compilers in all three platforms.

While we are using cmake to compile plplot, I am NOT using it to compile =
my own fortran program that uses plplot.

After taking a look at one of the files used by plplot, it seems as if =
plplot links in all the drivers all the time...so, I started to include =
some, too (as hinted by the messages), until all the "undefined =
reference" messages disappeared.  Here is what I ended up with:

	g95 -I/usw/ude/Linux/include \
	    -L/usw/ude/Linux/lib    \
	    -r8 -Bstatic -s -ffixed-line-length-132 -ftrace=3Dfull \
	    -o  try  try.f   \
	    -lplplotf77d -lplplotf77cd -lplplotd \
	    -lgd \
	    -ltcl8.4 \
	    -ltk8.4 \
	    -lhpdf \
	    -lm   \
	    -lcsirocsa

Directory /usw/ude/Linux is where we install our third party software, =
like plplot.

Basically, the libraries that I thought I should not need but had to add =
anyway are:
	    -lgd \
	    -ltcl8.4 \
	    -ltk8.4 \
	    -lhpdf \

Who knows, eventually, I may have to add other things like the ones that =
show up in the files used by plplot: png, z, jpeg, xwin, X11, Xext, SM =
and ICE...I think I will know when, except for SM and ICE...what is =
that?

So, that's that, and if that's the way plplot works, fine; it does not =
seem ideal, but now I know.

So, it looks like I am in business.

Thanks for the feedback.

Germ=E1n=20


=20

-----Original Message-----
From: Alan W. Irwin [mailto:irwin@...
Sent: Thursday, September 06, 2007 4:18 PM
To: Salazar, German P21322
Cc: plplot-general@...
Subject: Re: [Plplot-general] Compiling a program: undefined reference

On 2007-09-06 15:12-0400 Salazar, German P21322 wrote:

> : undefined reference to `gdImageLine'
> /usw/ude/Linux/lib/libplplotd.a(gd.o)(.text+0xbe0): In function
> `fill_polygon':
>
> ...and the list goes on.
>
> Questions:
>
> Why is it trying to use all these drivers if I am only using "psc" =
from
> Fortran?
> Is it possible that plplotd.a was not properly randomized and somehow
> when I link it, I link the entire file?
>
> Pointers would be much appreciated.

Please give details of what you did, i.e., cmake command-line options =
and
full cmake output at minimum.  Also, identify your platform and be =
specific
about the "compile process" you are using.

In the absence of those details, I can only guess what the issue is.  It
appears from above that you have done a static library build for PLplot
which is a non-default configuration which we don't test very much.  So =
you
may have inadvertently found some external build issue for that case.  =
But
please give the details requested above so I can replicate the static =
build
issue here and fix it.

If you did not specifically go out of your way to specify a static =
library
build, then cmake probably found something missing on your system that
forced that.  To avoid that result, pay close attention to any warnings =
you
get from cmake concerning shared libraries and address the issue so you =
can
build shared libraries for PLplot.  Shared libraries are our most =
thoroughly
tested configuration.

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); PLplot scientific plotting =
software
package (plplot.org); 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
__________________________

On 2007-09-07 01:09-0400 Salazar, German P21322 wrote:

>
> Well, yes, as a matter of fact, we built plplot to generate static libraries; and I am also compiling a program to staticly link those libraries.
>
> As far as platform and the like info goes, right now I am in Linux; but I will be doing the same thing for Solaris and Windows.
>
> I am using the gcc and g95 compilers in all three platforms.
>
> While we are using cmake to compile plplot, I am NOT using it to compile my own fortran program that uses plplot.
>
> After taking a look at one of the files used by plplot, it seems as if plplot links in all the drivers all the time...so, I started to include some, too (as hinted by the messages), until all the "undefined reference" messages disappeared.  Here is what I ended up with:
>
> 	g95 -I/usw/ude/Linux/include \
> 	    -L/usw/ude/Linux/lib    \
> 	    -r8 -Bstatic -s -ffixed-line-length-132 -ftrace=full \
> 	    -o  try  try.f   \
> 	    -lplplotf77d -lplplotf77cd -lplplotd \
> 	    -lgd \
> 	    -ltcl8.4 \
> 	    -ltk8.4 \
> 	    -lhpdf \
> 	    -lm   \
> 	    -lcsirocsa
>
> Directory /usw/ude/Linux is where we install our third party software, like plplot.
>
> Basically, the libraries that I thought I should not need but had to add anyway are:
> 	    -lgd \
> 	    -ltcl8.4 \
> 	    -ltk8.4 \
> 	    -lhpdf \
>
> Who knows, eventually, I may have to add other things like the ones that show up in the files used by plplot: png, z, jpeg, xwin, X11, Xext, SM and ICE...I think I will know when, except for SM and ICE...what is that?
>
> So, that's that, and if that's the way plplot works, fine; it does not seem ideal, but now I know.
>
> So, it looks like I am in business.

That's good to hear.

Nevertheless, instead of being so specific above with your link flags, have
you tried using pkg-config instead just like our compilation of the
installed examples does?  pkg-config is a very popular application on Linux
(also buildable on Unix) which conveniently delivers all the compile and
link flags required to build applications that use given packages such as
PLplot.  (cmake will warn you if you don't have pkg-config installed.)
pkg-config is just a convenient small application that is completely
independent of CMake.

I had thought all along that perhaps you might have found a bug in how we
configured pkg-config for the static libraries case, but now it turns out
you have not been using pkg-config to build your applications. In any case,
I would be most interested in your (static-build) results for running make
in the _installed_ $prefix/share/plplot5.7.4/examples directory.  That make
command should run pkg-config appropriately to build the examples, and you
should be able to follow that convenient cookbook when building your own
applications 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________