plplot-general — PLplot user discussion group

Re: [Plplot-general] plplot (fwd)

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

Thanks very much for that fix, Hugh.  I have just put it into the CVS
version of plplot.  For those of you with xwin/solaris troubles (including
those who have reported some solaris troubles with yplot), please test the
cvs version of plplot to see if the troubles go away.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Thu, 22 Nov 2001, H C Pumphrey wrote:

>
> Hi plplot people:
>
> I think I found a bug in plplot which causes the xwin driver to die when
> called from Fortran on Solaris 8.
>
> The bug is in this bit of xwin.c
>
> /* Window title */
>
>     if (plsc->plwindow){    /* jc: allow -plwindow to specify wm
> decoration name*/
>       sprintf(header, "%s", plsc->plwindow);
>     }
>     else
>       sprintf(header, "%s", plsc->program); /* jc: else program name*/
>
> Now, when called from fortran, plsc->program is NULL at this point. In
> Xfree86 on my Linux box, this just causes the window to have (null) as a
> title, but on Slowaris, it causes a segfault. Yuk. One fix is as follows:
>
> /* Window title */
>
>     if (plsc->plwindow){    /* jc: allow -plwindow to specify wm
> decoration name*/
>       sprintf(header, "%s", plsc->plwindow);
>     }
>     else if( plsc->program){
>       sprintf(header, "%s", plsc->program); /* jc: else program name*/
>     }
>     else
>       sprintf(header,"%s","Plplot");
>
> Enjoy!
>
> Hugh
>
> P.S. I am wondering if this is the cause of some of the X weirdness on
> Solaris reported by others.....

[Plplot-general] C++ interface and windows redraw

[Victor M. <vm...@ma...>]

  I've been using plplot for some weeks. Since I prefer C++, I'm using
that interface, but I noticed I couldn't easily ask for the postscript
driver and then specify the output file name so that my program does not
expect an answer from the keyboard. The problem seemed to be that plstream
constructors call plinit(), so when, after the plstream object is created,
I intended to set the filename, I got a segfault. My program was:

#include "plstream.h"
int main(){
  plstream pls(1,1,"psc");
  pls.sfnam("tres.ps");
}

I decided to add a constructor to the plstream class, so that something
like plstream pls(1,1,"psc","tres.ps") works, and consequently
automatically opens an output file. I had to recompile the libraries, but
it worked. If someone knows of a better or easier solution, or if someone
thinks this is a good feature to include in future versions, I'd be glad
to know.


Second. I noticed that if I create two plstream objects, and the second
window is put over the first one in my screen, the first one is erased, so
I cannot see both windows simultaneously (that's why I had to worry about
writing files, by the way). Is that a common problem with the xwin driver,
or there's something in my distribution I could change to fix this?

  Thanks for any comment,
					Victor Munoz

[Plplot-general] plplot (fwd)

[H C P. <hc...@me...>]

Hi plplot people:

I think I found a bug in plplot which causes the xwin driver to die when
called from Fortran on Solaris 8. 

The bug is in this bit of xwin.c

/* Window title */

    if (plsc->plwindow){    /* jc: allow -plwindow to specify wm
decoration name*/
      sprintf(header, "%s", plsc->plwindow);
    }
    else 
      sprintf(header, "%s", plsc->program); /* jc: else program name*/

Now, when called from fortran, plsc->program is NULL at this point. In
Xfree86 on my Linux box, this just causes the window to have (null) as a
title, but on Slowaris, it causes a segfault. Yuk. One fix is as follows:

/* Window title */

    if (plsc->plwindow){    /* jc: allow -plwindow to specify wm
decoration name*/
      sprintf(header, "%s", plsc->plwindow);
    }
    else if( plsc->program){
      sprintf(header, "%s", plsc->program); /* jc: else program name*/
    }
    else
      sprintf(header,"%s","Plplot");

Enjoy! 

Hugh

P.S. I am wondering if this is the cause of some of the X weirdness on
Solaris reported by others.....



============S=u=p=p=o=r=t===D=e=b=i=a=n===http://www.debian.org============
Dr. Hugh C. Pumphrey             | Tel. 0131-650-6026,Fax:0131-650-5780
Institute for Meteorology        | Replace 0131 with +44-131 if outside UK
The University of Edinburgh      | Email hc...@me...
EDINBURGH EH9 3JZ, Scotland      | URL: http://www.met.ed.ac.uk/~hcp
============S=u=p=p=o=r=t==g=9=5==http://g95.sourceforge.net/==============

Re: [Plplot-general] strange bug in yplot

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

That's a strange one, Valerij.  All the driver details for yplot are just
handled by plplot so I don't understand why you get the segfault in one
situation (yorick front end = yplot), but not for the C front end to plplot.
This problem does not happen under Linux, and unfortunately I cannot proceed
further because I don't have access to solaris with X.  (The SF compile farm
solaris machine I have access to doesn't have X.)

If you wanted to investigate this further, I would try some variations on
the theme such as gcc rather than native solaris compiler (or vice versa
if these results were with gcc.)  Also, I would try the latest version of
plplot from CVS rather than 5.0.4.

Meanwhile, I will file this under bugs to be investigated if/when I get
access to solaris + X.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Tue, 20 Nov 2001, Valerij Pipin wrote:

> Hi everybody,
>
> Thanks o lot for yplot maintainers!
> Sometimes I use yplot on Sun workstations (SunOS-5.7).
> I found that all cdemos of plplot are able to make output on xwin, however
>  I'm not able the same with yplot. After batching some file I have
> "Enter device number or keyword: 1
> ERROR (plinit) Segmentation violation interrupt (SIGSEGV)
>   LINE: 61  FILE: /home/vpip/yorick/share/yorick/1.5/i0/yplot.i
> yorick: quitting on error in batch mode"
>
> Actually it is not a big problem because output to other devices, e.g., ps or plm
> works well.
>
> So, this message just for information
>
> I,ve already tested yplot-1.1.1 on RH6.0&7.1, here. Resutls are exelent. Particularily, for
> the first time, I tried pvfield for 2D vector field in meridional plan of spherical shell
> and  found that quality is the same as commercial IDL gives.
>
> Thanks,
> Valerij
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

[Plplot-general] strange bug in yplot

[Valerij P. <vp...@ii...>]

Hi everybody,

Thanks o lot for yplot maintainers!
Sometimes I use yplot on Sun workstations (SunOS-5.7).
I found that all cdemos of plplot are able to make output on xwin, however
 I'm not able the same with yplot. After batching some file I have 
"Enter device number or keyword: 1
ERROR (plinit) Segmentation violation interrupt (SIGSEGV)
  LINE: 61  FILE: /home/vpip/yorick/share/yorick/1.5/i0/yplot.i
yorick: quitting on error in batch mode"

Actually it is not a big problem because output to other devices, e.g., ps or plm 
works well. 

So, this message just for information

I,ve already tested yplot-1.1.1 on RH6.0&7.1, here. Resutls are exelent. Particularily, for
the first time, I tried pvfield for 2D vector field in meridional plan of spherical shell
and  found that quality is the same as commercial IDL gives.

Thanks,
Valerij

[Plplot-general] yplot-1.1.1 released

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

yplot-1.1.1 has been released as a tarball at
http://sourceforge.net/project/showfiles.php?group_id=15416.

Since the previous release (1.1.0), I have introduced some changes to make
yplot build on solaris and also work with yorick-1.5 (1.1.0 only works with
yorick-1.4).  So the majority of yplot users (all 200 of you as judged from
the downloads) have no need to upgrade.  However, those who want to try to
build it on solaris and/or with yorick-1.5 should use the new version.

The testing of these changes has been minimal.  I have two good solaris build
reports (one my own), and two good reports of a build with yorick-1.5 (one
for RedHat 7.2, and one, my own, with Debian woody).

For some background, yplot is a well-documented yorick front-end to plplot
that is extremely easy to learn and also extremely powerful. For historical
reasons yplot has been developed as a separate project from all the other
front-ends to plplot which are part of the plplot package so that is why
it has its own web site (yplot.sf.net) and its own project page
(sf.net/projects/yplot).  However, to keep plplot front-end discussion all
in one place, the plplot general list is used for yplot announcements
and discussion.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-general] VTK?

[Cliff Y <smu...@ya...>]

As long as I'm in newbie question mode, here's another
one:  how easy/hard would it be to have plplot use
something like the VTK toolkit to generate it's
output?  I don't know if the examples on the plplot
website are current, but they leave a little to be
desired in some cases from the visual appeal
standpoint. 

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

Re: [Plplot-general] Vector Field Plots?

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

On Mon, 12 Nov 2001, Cliff Y wrote:

> Hi.  Are there routines in PLPLOT for 2D and 3D vector
> fields?  If not, is this feature planned?
>
> Thanks,
> CY

The yorick front-end (which for historical reasons is a separate project,
see yplot.sf.net), and the octave front-end have separate implementations of
2D vector field plots. There has been some discussion of making vector field
plot functionality part of the core API of plplot, but that hasn't happened
(yet).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-general] Vector Field Plots?

[Cliff Y <smu...@ya...>]

Hi.  Are there routines in PLPLOT for 2D and 3D vector
fields?  If not, is this feature planned?

Thanks,
CY

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

[Plplot-general] Re: Plplot 5.0.4-5 pn RedHat 7.2

[Daniel T. <te...@fo...>]

Hi Alan,


> (2) Get to the bottom of why plplot is not finding one or both of the
> python headers or the numpy headers.  It essentially looks for Python.h and
> arrayobject.h.  Are those both somewhere on your system? If not, there might
> be development versions of the python and numeric packages you still have to
> install.  If they are both there, you probably have to modify plplot
> configuration a little by setting environment variables to help configure
> for plplot find the headers.  The relevant variables are PYTHON_INC_DIR and
> PYTHON_NUM_DIR.  I haven't tried this but try setting these environment
> variables respectively to the directories where Python.h and arrayobject.h
> are located.  This should occur just before the configure step in the spec
> file. With this change to the spec file, I think configure will go ahead and
> configure python and numpy properly. Give it a try, and let me know whether
> it works.  (If it doesn't work, let me know all the messages that you get
> from configure.  If those are okay for python, then you are probably
> generating plmodule.so OK, and you may simply have to change the directory
> in the specfile file list which identifies where plmodule.so is installed.)

It worked. That was it. It is built now with Python2 and Numeric
20.2.1...
Thanks for your help


		Daniel
-- 
***********************************************************************
Daniel TOURDE                             E-mail : dan...@fo...
                                             Tel : +46 (0)8-55 50 43 44
                                        Cellular :  +46 (0)70-849 93 40
   FOI, Swedish Defence Research Agency; Aeronautics Division - FFA
       Dept. of Wind Energy and Aviation Environmental Research
SE-172 90 Stockholm, Sweden                     Fax : +46 (0)8-25 34 81
***********************************************************************

Re: [Fwd: Re: [Plplot-general] X protocol errors]

[<jca...@in...>]

On Wednesday 07 November 2001 18:04, Roberto Hernandez wrote:
|  > Dear all,
|  >
|  > Since I've starting using KDE as my window manager on my SUN
|  > Ultra Sparc running Solaris 8 it has been necessary to run my X
|  > server such that it defaults to using 24 bit TrueColour.  The
|  > downside of this is that plrender now produces a whole slew of X
|  > protocol errors:
|  >
|  > plrender -dev xwin -nopixmap hagis.pl
|  >
|  > X protocol error: error=3D8 request=3D1 minor=3D0
|  > X protocol error: error=3D3 request=3D18 minor=3D0
|  > X protocol error: error=3D3 request=3D18 minor=3D0
|  > X protocol error: error=3D3 request=3D18 minor=3D0
|  > X protocol error: error=3D3 request=3D2 minor=3D0
|  > X protocol error: error=3D9 request=3D55 minor=3D0
|  > X protocol error: error=3D9 request=3D55 minor=3D0
|  > X protocol error: error=3D9 request=3D14 minor=3D0
|  > X protocol error: error=3D3 request=3D2 minor=3D0
|  > X protocol error: error=3D3 request=3D2 minor=3D0
|  > X protocol error: error=3D3 request=3D12 minor=3D0
|  > X protocol error: error=3D3 request=3D8 minor=3D0
|  >
|  > Does anyone know how to cure these?

In the beginning, :), the xwin driver used 8 bits read/write=20
colormaps, and when using a 16 bits truecolor Xserver, it failed to=20
allocate colors, generating a X protocol error, as it tried to store=20
colors in what was a read-only colormap.
I have thus added a X error handler, that intercepted the error,=20
ignoring that particular protocol error, but that did not solve the=20
real problem. The problem was meanwhile solved, but the the error=20
handler was left. Until recently, when I removed it from cvs. Thus,=20
in the current CVS plplot version, the above message does not appear=20
anymore. Instead, the standard X error message will be printed.

I have not tried a 24 or 32 bits Xserver, I use a 16 bits one, and I=20
don't have such error messages. Could you (all) please see if the=20
error persists on a 16 bits Xserver?

Joao

PS: to developers, see xwin.c, cvs version 1.71, 1.74 and 1.77.

|  >
|  > Note also that if I don't include the -nopixmap option then I
|  > also get the error message:
|  >
|  > Error in XCreatePixmap: BadDrawable (invalid Pixmap or Window
|  > parameter).
|  >
|  > Many thanks in advance for any help anyone can offer me,
|
| I get these errors as well.
|
| My system is "uname -a" :
|
| Linux ether.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
| unknown
|
| I am running RedHat 7.1 w/ XFree86 4.0.3 in 16bpp
|
| My solution has been to ignore the messages. But now I thought it
| would help to know this isn't exclusive of a Solaris system.
|
| Regards,
|
| Roberto
|
|
|
| _______________________________________________
| Plplot-general mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] Re: Plplot 5.0.4-5 pn RedHat 7.2

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

I am going to put this on the list because others may be interested as well.

I don't have access to RH 7.2.  My guess is the configure part of your build
is not finding one of python or numpy header files.  The build then
continues fine but excludes plmodule.so as it should.  Finally, at the end
since plmodule.so is on the list of files to be installed rpm complains that
it wasn't built and quits.

If my guess is correct there are two solutions to the problem.

(1) If you don't care about python, simply comment out the plmodule.so
file list line from the spec file.

(2) Get to the bottom of why plplot is not finding one or both of the
python headers or the numpy headers.  It essentially looks for Python.h and
arrayobject.h.  Are those both somewhere on your system? If not, there might
be development versions of the python and numeric packages you still have to
install.  If they are both there, you probably have to modify plplot
configuration a little by setting environment variables to help configure
for plplot find the headers.  The relevant variables are PYTHON_INC_DIR and
PYTHON_NUM_DIR.  I haven't tried this but try setting these environment
variables respectively to the directories where Python.h and arrayobject.h
are located.  This should occur just before the configure step in the spec
file. With this change to the spec file, I think configure will go ahead and
configure python and numpy properly. Give it a try, and let me know whether
it works.  (If it doesn't work, let me know all the messages that you get
from configure.  If those are okay for python, then you are probably
generating plmodule.so OK, and you may simply have to change the directory
in the specfile file list which identifies where plmodule.so is installed.)

BTW, if you want to look deeper at what is going on, look at cf/sysloc.in.
(look for Python and arrayobject within that file).  That is where I got the
information about PYTHON_INC_DIR and PYTHON_NUM_DIR.  There is a list there
of possible directories to search (if PYTHON_INC_DIR is not defined). It is
an ongoing issue with us that that directory list has to be updated every
time there is a new version of python or numpy.  The CVS version of
cf/sysloc.in (which will eventually be part of the next stable release of
plplot) has a more extended list of directories to search.  But I think
setting PYTHON_INC_DIR and PYTHON_NUM_DIR is probably the easiest thing for
you to do for now.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 7 Nov 2001, Daniel Tourde wrote:

> Hi!
>
> I am trying to build Plplot 5.0.4-5 on a RedHat 7.2 machines from the
> .src.rpm file
> I installed yorick 1.5 and Numpy 20.2.1. It is based on python2.1
> (python2)
>
> The compilations goes apparently fine but I get this message, preventing
> the construction of the binary
>
> Processing files: plplot-5.0.4-5
> error: File not found:
> /tmp/software/redhat_install_area/plplot/usr/lib/python1.5/site-packages/plmodule.so
> PreReq: /bin/sh /bin/sh /bin/sh
> Requires(interp): /bin/sh /bin/sh /bin/sh
> Requires(post): /bin/sh
> Requires(preun): /bin/sh
> Requires(postun): /bin/sh
> Requires: python >= 1.5.2-30 python-numpy >= 15.3
>
>
> RPM build errors:
>     File not found:
> /tmp/software/redhat_install_area/plplot/usr/lib/python1.5/site-packages/plmodule.so
>
> Having not used python-numpy 15.3 but Numpy 20.2.1, I understand it...
> Do you have a patch or a way to go thru this?
> I tried to see if plmodule.so has been installed somewhere else but it
> is nowhere.
>
>
> Thanks in advance for any answer
>
> 		Daniel
> --
> ***********************************************************************
> Daniel TOURDE                             E-mail : dan...@fo...
>                                              Tel : +46 (0)8-55 50 43 44
>                                         Cellular :  +46 (0)70-849 93 40
>    FOI, Swedish Defence Research Agency; Aeronautics Division - FFA
>        Dept. of Wind Energy and Aviation Environmental Research
> SE-172 90 Stockholm, Sweden                     Fax : +46 (0)8-25 34 81
> ***********************************************************************
>

[Fwd: Re: [Plplot-general] X protocol errors]

[Roberto H. <ro...@ad...>]

 > Dear all,
 >
 > Since I've starting using KDE as my window manager on my SUN Ultra
 > Sparc running Solaris 8 it has been necessary to run my X server such
 > that it defaults to using 24 bit TrueColour.  The downside of this is
 > that plrender now produces a whole slew of X protocol errors:
 >
 > plrender -dev xwin -nopixmap hagis.pl
 >
 > X protocol error: error=8 request=1 minor=0
 > X protocol error: error=3 request=18 minor=0
 > X protocol error: error=3 request=18 minor=0
 > X protocol error: error=3 request=18 minor=0
 > X protocol error: error=3 request=2 minor=0
 > X protocol error: error=9 request=55 minor=0
 > X protocol error: error=9 request=55 minor=0
 > X protocol error: error=9 request=14 minor=0
 > X protocol error: error=3 request=2 minor=0
 > X protocol error: error=3 request=2 minor=0
 > X protocol error: error=3 request=12 minor=0
 > X protocol error: error=3 request=8 minor=0
 >
 > Does anyone know how to cure these?
 >
 > Note also that if I don't include the -nopixmap option then I also get
 > the error message:
 >
 > Error in XCreatePixmap: BadDrawable (invalid Pixmap or Window parameter).
 >
 > Many thanks in advance for any help anyone can offer me,
 >

I get these errors as well.

My system is "uname -a" :

Linux ether.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown

I am running RedHat 7.1 w/ XFree86 4.0.3 in 16bpp

My solution has been to ignore the messages. But now I thought it would
help to know this isn't exclusive of a Solaris system.

Regards,

Roberto

Re: [Plplot-general] X protocol errors

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

On 7 Nov 2001, Simon Pinches TOK wrote:

> I should point out that if I leave the default colour depth as 8 bits
> then plrender works fine.  It is only if I change it to 24 bits (and
> thereby persuade KDE to render everything in 24 bit colour) that
> plrender has problems.  Interestingly, all other applications seem to
> work just fine.

You have emphasized plrender, but I suspect this is actually a bug triggered
by using the xwin driver. (Try "cd tmp; make x01c; ./x01c -dev xwin" to
confirm this.) This is just a guess, but I suspect the xwin driver is
exercising X harder or in a different way than other applications, and that
is triggering a bug in the Sun X server at 24-bits that does not occur for
XFree86 at any supported resolution and that also does not occur in the Sun
X server at 8 bits.

If that guess is right, I don't think there is much more you or we can do.
Such is life with Sun software.  (OOPs, my prejudice is showing....;-))

Alan

Re: [Plplot-general] X protocol errors

[Simon P. T. <sim...@ip...>]

Thanks for your helpful reply.

"Alan W. Irwin" <ir...@be...> writes:

> I cannot confirm this error on my Debian woody i686 system with KDE-2.2.1
> and XFree86-4.1.0.  My system has a Matrox video card, and by default I use
> 24-bit colour. plrender works fine with no protocol errors whether or not
> you specify the -nopixmap option.  I am using the latest cvs version of
> plplot, but I am fairly sure there should also be no problem in 5.0.4
> because I don't remember any such bug fixes since 5.0.4. What version of
> plplot are you using?

I'm using version 5.0.4 and have no problems on my SuSE i686 system
with KDE 2.2.1.  However on my Sun, unless I set the default colour
depth to 24 bits KDE is only rendered in 8 bits.

> If you are using 5.0.4 (or later cvs) I suspect there should be no problem
> on the plplot side.  In this case, you might simply have a 24-bit colour
> problem with your particular X server. If you are using XFree86, they have a
> pretty good track record of fixing bugs, and I would recommend getting the
> latest version.  OTOH, if you are using some proprietary X server, you you
> may have to stick with 16-bit or something smaller.  (I haven't tried it,
> but I would be quite surprised if KDE demanded you use 24-bit colour.)

It doesn't demand it, but it looks a lot better with it :-)

> Another possibility is to try 32-bit colour (which I understand is really
> 24-bits + 8 unused bits, but 4 bytes is inherently less complicated for an X
> driver to use than a 3-byte format.)

32-bit colour isn't supported by my Xsun X server.

I should point out that if I leave the default colour depth as 8 bits
then plrender works fine.  It is only if I change it to 24 bits (and
thereby persuade KDE to render everything in 24 bit colour) that
plrender has problems.  Interestingly, all other applications seem to
work just fine.

I guess I have to choose between having a nice 24-bit colour window
manager and having to view postscript output produced with plrender,
or having an 8 bit window manager and being able to render plplot meta
files directly to the screen (which is a lot faster.)
-- 
Simon Pinches

-----------------------------------------------------------------------
Dr. S. D. Pinches                 Max-Planck-Institut fuer Plasmaphysik 
Tel: +49 89 3299-1329		  Boltzmannstrasse 2                    
Fax: +49 89 3299-2580		  D-85748 Garching-bei-Muenchen
Email: Sim...@ip...   Germany
-----------------------------------------------------------------------

> On Tue, 6 Nov 2001, Simon Pinches TOK wrote:
> 
> > Dear all,
> >
> > Since I've starting using KDE as my window manager on my SUN Ultra
> > Sparc running Solaris 8 it has been necessary to run my X server such
> > that it defaults to using 24 bit TrueColour.  The downside of this is
> > that plrender now produces a whole slew of X protocol errors:
> >
> > plrender -dev xwin -nopixmap hagis.pl
> >
> > X protocol error: error=8 request=1 minor=0
> > X protocol error: error=3 request=18 minor=0
> > X protocol error: error=3 request=18 minor=0
> > X protocol error: error=3 request=18 minor=0
> > X protocol error: error=3 request=2 minor=0
> > X protocol error: error=9 request=55 minor=0
> > X protocol error: error=9 request=55 minor=0
> > X protocol error: error=9 request=14 minor=0
> > X protocol error: error=3 request=2 minor=0
> > X protocol error: error=3 request=2 minor=0
> > X protocol error: error=3 request=12 minor=0
> > X protocol error: error=3 request=8 minor=0
> >
> > Does anyone know how to cure these?
> >
> > Note also that if I don't include the -nopixmap option then I also get
> > the error message:
> >
> > Error in XCreatePixmap: BadDrawable (invalid Pixmap or Window parameter).
> >
> > Many thanks in advance for any help anyone can offer me,
> > --
> > Simon Pinches

Re: [Plplot-general] X protocol errors

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

I cannot confirm this error on my Debian woody i686 system with KDE-2.2.1
and XFree86-4.1.0.  My system has a Matrox video card, and by default I use
24-bit colour. plrender works fine with no protocol errors whether or not
you specify the -nopixmap option.  I am using the latest cvs version of
plplot, but I am fairly sure there should also be no problem in 5.0.4
because I don't remember any such bug fixes since 5.0.4. What version of
plplot are you using?

If you are using 5.0.4 (or later cvs) I suspect there should be no problem
on the plplot side.  In this case, you might simply have a 24-bit colour
problem with your particular X server. If you are using XFree86, they have a
pretty good track record of fixing bugs, and I would recommend getting the
latest version.  OTOH, if you are using some proprietary X server, you you
may have to stick with 16-bit or something smaller.  (I haven't tried it,
but I would be quite surprised if KDE demanded you use 24-bit colour.)
Another possibility is to try 32-bit colour (which I understand is really
24-bits + 8 unused bits, but 4 bytes is inherently less complicated for an X
driver to use than a 3-byte format.)

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Tue, 6 Nov 2001, Simon Pinches TOK wrote:

> Dear all,
>
> Since I've starting using KDE as my window manager on my SUN Ultra
> Sparc running Solaris 8 it has been necessary to run my X server such
> that it defaults to using 24 bit TrueColour.  The downside of this is
> that plrender now produces a whole slew of X protocol errors:
>
> plrender -dev xwin -nopixmap hagis.pl
>
> X protocol error: error=8 request=1 minor=0
> X protocol error: error=3 request=18 minor=0
> X protocol error: error=3 request=18 minor=0
> X protocol error: error=3 request=18 minor=0
> X protocol error: error=3 request=2 minor=0
> X protocol error: error=9 request=55 minor=0
> X protocol error: error=9 request=55 minor=0
> X protocol error: error=9 request=14 minor=0
> X protocol error: error=3 request=2 minor=0
> X protocol error: error=3 request=2 minor=0
> X protocol error: error=3 request=12 minor=0
> X protocol error: error=3 request=8 minor=0
>
> Does anyone know how to cure these?
>
> Note also that if I don't include the -nopixmap option then I also get
> the error message:
>
> Error in XCreatePixmap: BadDrawable (invalid Pixmap or Window parameter).
>
> Many thanks in advance for any help anyone can offer me,
> --
> Simon Pinches
>
> -----------------------------------------------------------------------
> Dr. S. D. Pinches                 Max-Planck-Institut fuer Plasmaphysik
> Tel: +49 89 3299-1329		  Boltzmannstrasse 2
> Fax: +49 89 3299-2580		  D-85748 Garching-bei-Muenchen
> Email: Sim...@ip...   Germany
> -----------------------------------------------------------------------
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

Re: [Plplot-general] Some installation problems

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

On Tue, 6 Nov 2001, Victor Munoz wrote:
>
>   I'm working with a Debian potato Linux distribution, and instead of
> dowloading the distribution's release 4.99j, which a friend of mine
> (who's much more expert than me in Linux) told me had compilation
> problems. Anyway, he gave me the 5.0.4 tar file, which worked for him
> without much difficulty.

That is correct.  5.0.4 is the version we support.  4.99j is from many
years ago with a large number of bugs which have been fixed in 5.0.4.

> I followed the installation steps (configure,
> make, make install), and when I tried to compile the demos (make x01c, for
> instance), I had no xwin terminal listed, though I could save the output
> as postscript, for instance. The command line I gave to configure was
>
> configure --with-double --enable-xwin --enable-octave --enable-gnome

X and octave are found by default so you don't need those options. The
default prefix is /usr/local/plplot according to ./configure --help, but I
always specify it so I haven't actually tested that default.  gnome does
have to be specified because it is experimental. So on my potato system
(which was actually a test bed for the 5.0.4 release) I used

./configure --prefix=/usr/local/plplot --with-double --enable-gnome

and the config summary showed it set everything to "yes" (see next comment).

>
> However, as I said, the config summary stated "enable_xwin:  no",
> "enable_octave:  no" and "enable_gnome: no".

You cannot force these options.  The config summary shows "yes" only if you
have specified yes (or it is the default) *AND* you have installed the
"devel" versions of all the relevant packages. For example, to compile
anything against the XFree86 library, you need both the xlibs and xlibs-dev
packages installed on your system.  Presumably, at the time you tried this
you didn't have those.  Thus, the configure could not find the relevant
X files so it rightly turned off X (and therefore lots of other things that
depend on X).

>
> I tried deleting installed files and starting again, or
> copying the already configured files which worked so fine for my friend,
> but it did not work. Eventually, my friend told me not to try
> --enable-octave and --enable-gnome, because he had the same problem I had,
> that somehow the "yes" turned out to be a "no". He also suggested to
> install the Debian distribution's plplot version to have octave support,
> because this did work well, and I did.

Was that the 5.0.2 version available for potato from our web site?
Instructions about how to obtain those versions for potato=stable are given
on http://plplot.sourceforge.net/resources/index.html.  That version is not
bad, but there are still some bugs in it that have been fixed in 5.0.4, and
also the debian 5.0.2 package does not include octave.  The debian package
for 5.0.4 (including octave) is being held up because, Rafael, a member of
our core team and also the official Debian packager has been busy for
several months with his new job.  Thus, for now, until he can find time to
officially package 5.0.4, I would recommend for all Debian users the 5.0.4
tarball approach that you have used.

>
> We don't know what happened with all these trials, but the fact is that
> the next time I untared the 5.0.4 files to try again, and I typed
>
>  configure --with-double
>
> xwin appeared among the enabled options in the config summary! This was
> not the only weird thing, because the prefix had been changed to /usr,
> instead of /usr/local/plplot. All my previous trials had the
> /usr/local/plplot prefix, so I don't know. My friend's configured version
> (which I also tried to install as I said) had the /usr prefix, but I
> couldn't guess why this could affect later installations (I logged out in
> case some environment variable was somehow set, but the prefix still was
> /usr). So I ended up saying
>
>  configure --with-double --prefix=/usr/local/plplot
>
> and everything worked fine.

See comments above.  At some time in your trials you must have installed
xlibs-dev.  Also, I am quite concerned that you now have bits and pieces of
different versions of plplot scattered all over your system.  Make sure you
remove all debian packages having to do with plplot.  They are either
extremely dated (4.99j) or somewhat dated (5.0.2), and you don't want those
bits and pieces interfering with your good 5.0.4 version installed in
/usr/local/plplot.  Also, you apparently did an install with prefix /usr
(via your friend's configuration file) which will add more possible bits and
pieces that have to be removed from /usr.

>   At least with compiling and viewing the demos in my screen, because I
> had to spent some hours to have a personal example work, until I found the
> correct combination of compiler options which works.  I finally used the
> following Makefile to compile and link a prueba.cpp C++ program:
>
> prueba.o: prueba.cpp
> 	g++ -c -O -I. -I/usr/local/plplot/include prueba.cpp
>
> prueba: prueba.o
> 	g++ -Wall -L/usr/X11R6/lib  prueba.o -lplcxxd -lplplotd -o prueba
> -lX11 -ldl -lm -lg++ -Wl,-rpath -Wl,/usr/local/plplot/lib

To find out exactly what compile and linker options to use that are suitable
for your system use /usr/local/plplot/bin/plplot-config.  On my system (now
Debian woody rather than potato) I get the following results (although yours
may be different, use plplot-config to find out.)

/usr/local/plplot/bin/plplot-config --libs --with-c++
-L/usr/local/plplot/lib -Llib -lplplotd -ltclmatrixd -litk3.1 -ltk8.3
-litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -lgd -lpng -ljpeg -lz -ldl -lm
-lg2c -Wl,-rpath,/usr/local/plplot/lib -lplcxxd

/usr/local/plplot/bin/plplot-config --cflags
-I/usr/local/plplot/include -I. -I/usr/include/tcl8.3
-I/usr/include/tcl8.3/itcl-private/generic -I/usr/X11R6/include

In fact I run plplot-config directly in my Makefiles so there is never
any uncertainty.


>
>  The last option -Wl,/usr/local/plplot/lib was unavoidable if I wanted the
> executable file prueba to find the libplplotd.so.5 file (without it, the
> program compiled and linked, but could not execute because it didn't file
> this shared object). This was unexpected, because my friend did not need
> such line to compile his programs, which is partly why it took so long for
> me to realize how to make it.

You seemed to have found the correct rpath solution (note plplot-config also
gives this).  However, another option is to set LD_LIBRARY_PATH at run time
to point to /usr/local/plplot/lib.

>
>   That's about all I think.  Thanks for your patience, and regards,
>
> 					Victor Munoz
> 					Dept. of Physics
> 					U. of Chile
>

I congratulate you on your persistence! It seems you got everything to work
for 5.0.4 (with the possible exception of getting rid of the bits and pieces
from your many different tries).  If configure is not giving you all the
options you want, it is usually because it cannot find something (required
devel package not installed on the system or you have a package installed in
a non-standard place where configure needs special help to find that place.)

I hope my comments have helped you to understand what was going on during
your many different kinds of plplot installation attempts.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-general] X protocol errors

[Simon P. T. <sim...@ip...>]

Dear all,

Since I've starting using KDE as my window manager on my SUN Ultra
Sparc running Solaris 8 it has been necessary to run my X server such
that it defaults to using 24 bit TrueColour.  The downside of this is
that plrender now produces a whole slew of X protocol errors:

plrender -dev xwin -nopixmap hagis.pl

X protocol error: error=8 request=1 minor=0
X protocol error: error=3 request=18 minor=0
X protocol error: error=3 request=18 minor=0
X protocol error: error=3 request=18 minor=0
X protocol error: error=3 request=2 minor=0
X protocol error: error=9 request=55 minor=0
X protocol error: error=9 request=55 minor=0
X protocol error: error=9 request=14 minor=0
X protocol error: error=3 request=2 minor=0
X protocol error: error=3 request=2 minor=0
X protocol error: error=3 request=12 minor=0
X protocol error: error=3 request=8 minor=0

Does anyone know how to cure these?

Note also that if I don't include the -nopixmap option then I also get
the error message:

Error in XCreatePixmap: BadDrawable (invalid Pixmap or Window parameter).

Many thanks in advance for any help anyone can offer me,
-- 
Simon Pinches

-----------------------------------------------------------------------
Dr. S. D. Pinches                 Max-Planck-Institut fuer Plasmaphysik 
Tel: +49 89 3299-1329		  Boltzmannstrasse 2                    
Fax: +49 89 3299-2580		  D-85748 Garching-bei-Muenchen
Email: Sim...@ip...   Germany
-----------------------------------------------------------------------

Re: [Plplot-general] Some installation problems

[Rafael L. <ra...@ic...>]

* Victor Munoz <vm...@ma...> [2001-11-06 10:27]:

> I'm working with a Debian potato Linux distribution, and instead of
> dowloading the distribution's release 4.99j, which a friend of mine
> (who's much more expert than me in Linux) told me had compilation
> problems. 

If you are using Debian, you should either grab the 5.0.2 packages for
potato in http://plplot.sourceforge.net/resources/debian/, or add the
following lines to your /etc/apt/sources.list file:

    deb http://plplot.sourceforge.net/resources/debian ./
    deb-src http://plplot.sourceforge.net/resources/debian ./

and use apt-get install.

The Debian packages are lagging behind the latest released version, but
5.0.2 should work okay for you.

-- 
Rafael Laboissiere

[Plplot-general] Some installation problems

[Victor M. <vm...@ma...>]

 I posted this message to Maurice LeBrun originally, and he suggested me
to send it to a Plplot mailing list instead. Here it is, in case someone
knows how to fix this in future releases (something seemed to happen when 
configuring the Makefile, there may be a problem with some script), if
necessary. Regards,

						Victor

---------- Forwarded message ----------
Date: Tue, 30 Oct 2001 16:01:08 -0300 (CLST)
From: Victor Munoz <vm...@ma...>
To: Dr. Maurice LeBrun <mj...@di...>
Subject: PLplot new user


  Hello, I just wanted to drop you a (not so short) note about PLplot,
which I've been just begun using this week. It's a really nice library and
I hope it will help solve my problems, but I wanted to tell you a few
things about some difficulties installing it. If you have the patience to
read this or want to forward it to someone who might know better about
these details it would be fine.

  Specifically, I think I faced some unexpected problems with the
configuration step, since some options I asked in the command line
disappeared from the final Makefile. This prevented me from compiling the
C demos as I explain below.
  And second, when the previous problem was solved, I spent some time
trying to compile my own test C++ code, since the executable file could
not find the shared objects. Maybe I missed some part of the
documentation, I don't know, but it would be nice if a better
documentation about this final step would be available.

  Above all, thanks for this wonderful software. Now the details:


  I'm working with a Debian potato Linux distribution, and instead of
dowloading the distribution's release 4.99j, which a friend of mine
(who's much more expert than me in Linux) told me had compilation
problems. Anyway, he gave me the 5.0.4 tar file, which worked for him
without much difficulty. I followed the installation steps (configure,
make, make install), and when I tried to compile the demos (make x01c, for
instance), I had no xwin terminal listed, though I could save the output
as postscript, for instance. The command line I gave to configure was

configure --with-double --enable-xwin --enable-octave --enable-gnome

However, as I said, the config summary stated "enable_xwin:  no",
"enable_octave:  no" and "enable_gnome: no".

I tried deleting installed files and starting again, or
copying the already configured files which worked so fine for my friend,
but it did not work. Eventually, my friend told me not to try
--enable-octave and --enable-gnome, because he had the same problem I had,
that somehow the "yes" turned out to be a "no". He also suggested to
install the Debian distribution's plplot version to have octave support,
because this did work well, and I did.

We don't know what happened with all these trials, but the fact is that
the next time I untared the 5.0.4 files to try again, and I typed

 configure --with-double 

xwin appeared among the enabled options in the config summary! This was
not the only weird thing, because the prefix had been changed to /usr,
instead of /usr/local/plplot. All my previous trials had the
/usr/local/plplot prefix, so I don't know. My friend's configured version
(which I also tried to install as I said) had the /usr prefix, but I
couldn't guess why this could affect later installations (I logged out in
case some environment variable was somehow set, but the prefix still was
/usr). So I ended up saying

 configure --with-double --prefix=/usr/local/plplot 

and everything worked fine. 
  At least with compiling and viewing the demos in my screen, because I
had to spent some hours to have a personal example work, until I found the
correct combination of compiler options which works.  I finally used the
following Makefile to compile and link a prueba.cpp C++ program:

prueba.o: prueba.cpp
	g++ -c -O -I. -I/usr/local/plplot/include prueba.cpp

prueba: prueba.o
	g++ -Wall -L/usr/X11R6/lib  prueba.o -lplcxxd -lplplotd -o prueba
-lX11 -ldl -lm -lg++ -Wl,-rpath -Wl,/usr/local/plplot/lib

 The last option -Wl,/usr/local/plplot/lib was unavoidable if I wanted the
executable file prueba to find the libplplotd.so.5 file (without it, the
program compiled and linked, but could not execute because it didn't file
this shared object). This was unexpected, because my friend did not need
such line to compile his programs, which is partly why it took so long for
me to realize how to make it. 
 
  That's about all I think.  Thanks for your patience, and regards,

					Victor Munoz
					Dept. of Physics
					U. of Chile

Re: [Plplot-general] Building Octave with Plplot

[Roberto H. <ro...@ad...>]

You need to install Octave (make sure you install it with shared libraries)
and then build PLplot with --enable-octave.

If you untar the source for PLplot the INSTALL file in the bindings/octave
directory explains what you need to do to get everything up and running. You
will also need to download "matwrap", the link is in the instructions.

Regards,

Roberto

----- Original Message -----
From: "John Gerard Malecki" <jo...@ar...>
To: "plplot_general" <plp...@li...>
Sent: Saturday, October 20, 2001 9:31 PM
Subject: [Plplot-general] Building Octave with Plplot


| Hi,
|
| I need to rebuild octave and I remember hearing that there is plplot
| support.  I grabbed 2.1.34, the bleeding edge release, but have not
| yet figured out if there is a configuration option for this.  (There
| seems to be --enable-plplot but it doesn't seem to work for me.)
|
| Can anyone give me some hints on how to build plplot version of
| octave?
|
| -thanks
|
| _______________________________________________
| Plplot-general mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-general
|

[Plplot-general] Building Octave with Plplot

[John G. M. <jo...@ar...>]

Hi,

I need to rebuild octave and I remember hearing that there is plplot
support.  I grabbed 2.1.34, the bleeding edge release, but have not
yet figured out if there is a configuration option for this.  (There
seems to be --enable-plplot but it doesn't seem to work for me.)

Can anyone give me some hints on how to build plplot version of
octave?

-thanks

Re: [Plplot-general] compiling yplot on the SunOS

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

Valerij:

yplot was designed exclusively for Linux, and that problem and several
others are caused because you are trying it on a non-Linux system.  Keeping
that cautionary statement in mind, at another user's request I made a number
of changes so it would work on solaris.  This work has not been officially
released, and this user chose not to give me feedback so it is in a state of
"works for me" for one solaris environment without any further testing.

If you have further interest you will have to get this version from CVS.
(For anonymous access to the yplot CVS follow the directions at
http://sourceforge.net/cvs/?group_id=15416, and also read the cvs man page
and run info cvs to find out how to request a certain date.) I finalized it
30 August, and there was a period of CVS inactivity afterward so if you ask
for the CVS version of date 1 September 2001 (or any time in September), I
believe you will get the right version.  Note I am actively working on yplot
CVS at the moment to get it to work with yorick-1.5, but I am right in the
middle of it so CVS HEAD probably won't work for you (but a 1 September date
will).

Note, other things you have to do on Solaris are to use gcc to compile
plplot-5.0.4. and the native solaris compiler to compile yorick-1.4.  (The
native solaris compiler does not work on plplot-5.0.4 [we allowed too many
gcc-specific statements into that version], and the gcc option is
misconfigured [IIRC] for yorick-1.4).

Finally, look carefully through the yplot INSTALL file to see what
environment variables you can set to help yplot find your yorick-1.4 and
plplot-5.0.4 installation directories.

Please let me know how it goes.  If you encounter problems, I would be
willing to help you with advice from what I can remember of my one solaris
experience, but you are mostly going to have to dig things out for yourself
because Sun never makes it easy.  Also, you are only the 3rd person to try
this.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Fri, 19 Oct 2001, V.V.Pipin wrote:

>
> Hello,
> I'm trying to build yplot on the SunO and after
> "make -f Makefile.build"
> I have:
> cc -DSTDC_HEADERS=1 -DPAD_ARRAY=1  `/home/vpip/share/bin/plplot-config
> --cflags`  -I/home/vpip/share/lib/yorick/1.4/h  -DDOUBLE  -c  pplot.c
> cc -DSTDC_HEADERS=1 -DPAD_ARRAY=1  `/home/vpip/share/bin/plplot-config
> --cflags`  -I/home/vpip/share/lib/yorick/1.4/h  -DDOUBLE  -c  read.c
> "read.c", line 139: warning: statement not reached
> sh: test: argument expected
> *** Error code 1
> make: Fatal error: Command failed for target `yplot'
>
> Evidently this mistake results from the string in file Makefile.build:
>         @if test -e Makefile; then echo \
>         "Nameclash! must get rid of Makefile so this can work"; false ; fi
>
> If anybody has an idea how to overcome this please let me now.
>
> Thanks a lot in advance, Valerij
>
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

[Plplot-general] compiling yplot on the SunOS

[V.V.Pipin <vp...@ii...>]

Hello,
I'm trying to build yplot on the SunO and after
"make -f Makefile.build"
I have:
cc -DSTDC_HEADERS=1 -DPAD_ARRAY=1  `/home/vpip/share/bin/plplot-config
--cflags`  -I/home/vpip/share/lib/yorick/1.4/h  -DDOUBLE  -c  pplot.c
cc -DSTDC_HEADERS=1 -DPAD_ARRAY=1  `/home/vpip/share/bin/plplot-config
--cflags`  -I/home/vpip/share/lib/yorick/1.4/h  -DDOUBLE  -c  read.c
"read.c", line 139: warning: statement not reached
sh: test: argument expected
*** Error code 1
make: Fatal error: Command failed for target `yplot'

Evidently this mistake results from the string in file Makefile.build:
        @if test -e Makefile; then echo \
        "Nameclash! must get rid of Makefile so this can work"; false ; fi

If anybody has an idea how to overcome this please let me now.

Thanks a lot in advance, Valerij

Re: [Plplot-general] Problem with colormap in Tk driver

[Vince D. <vi...@sa...>]

On Wed, 10 Oct 2001, Maurice LeBrun wrote:

> Roberto Hernandez writes:
>  > Hello everyone,
>  > 
>  > I'm having a small problem when using the Tk driver. When I select Plot --> 
>  > Options --> Palette 0 (or 1) from the plot menu I get the following error 
>  > message: Error: bad window path name "". The a new toplevel window pops up, 
>  > but it's blank.
>  > ...
> 
> These are very old utilities and haven't worked at all in a long time.
> I was planning to rewrite them in iTcl one of these days.
> 
>  > I get the feeling that the problem lies in the fact that I built PLplot 
>  > without the ITCL bindings. Am I right? Is ITCL necessary for choosing 
>  > different palettes?
> 
> Will be, eventually.

I believe I fixed these palettes in the 'tea' branch in cvs.

Vince.