plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Poor RC1 test results on Debian woody

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

On Wed, 16 Apr 2003, Joao Cardoso wrote:

> On Tuesday 15 April 2003 22:03, Alan W. Irwin wrote:
> ...
>
> |  *** There was one nasty RC1 failure for the combination of octave and png
> |  device.
> |
> |  Opened p16.png.01
> |
> |  *** PLPLOT WARNING ***
> |  plsfam: Must be called before plinit.
> |
> |  *** PLPLOT WARNING ***
> |  plsdev: Must be called before plinit.
> |  Plplot library version: 5.2.1.rc1
> |
> |  followed by a whole bunch of garbage output.
>
> The problem you report happened  with me once. I couldn't reproduce it
> afterwards.
>
> If you do:
>
> octave:1> figure(1,"png","po.png");
> Opened po.png
> octave:2> p16
> octave:3> closefig
>
> everything is OK. That is exactly what test_octave.sh does.

I can reproduce the above with no errors and po.png seems to display okay
with kview.  However, that simple test ignores the familying option that is
imposed via $options in test_octave.sh, and also doesn't try any other plots
first.

If I modify the above test for familying and trying other plots first
a bug results for p16 on my system but not for any other case.

Specifically, to reproduce the bug I must do the following:

octave -p "/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/lib/plplot5.2.1.rc1/examples/octave//:"
GNU Octave, version 2.1.35 (i386-pc-linux-gnu).
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type warranty'.

*** This is a development version of Octave.  Development releases
*** are provided for people who want to help test, debug, and improve
*** Octave.
***
*** If you want a stable, well-tested version of Octave, you should be
*** using one of the stable releases (when this development release
*** was made, the latest stable version was 2.0.16).

octave:1> plsetopt("fam", "yes")
warning: It is recommended that you set 'automatic_replot=1'
          in your ~/.octaverc file.
	  warning: in /usr/local/plplot_at/share/plplot_octave/figure.m near
line 59, column 7:

>>> warning ("It is recommended that you set 'automatic_replot=1' \n\t  in
your ~/.octaverc file.");


ans =
octave:2> figure(1,"png","po.png");
Opened po.png.1
octave:3> p1
octave:4> p7
Opened po.png.2
Opened po.png.3
octave:5> p16
octave:6> p16
octave:7> p7
Opened po.png.4
Opened po.png.5
octave:8> p1
Opened po.png.6

Notice, that p7 produces two pages every time, and p1 produces one page, but
p16 (with no error message in this case) produces no pages in familying
mode.  If I do p16 alone after plsetopt and figure, a good result is produced.

Joao, from your other good script results you probably won't be able to
reproduce this bug on your system, but could you double check please using
exactly the above octave commands in the order given?  Note I am using
octave 2.1.35.  Also, I suspect my above plsetopt call is a little clumsy (I
am not sure whether the "yes" is necessary), but it seems to get the job
done for p7 (and p16 if done alone).

Rafael, please try the same test.  (I am scared to predict the outcome except
that it will probably be different from both Joao's results and mine....;-))

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software package
(plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Poor RC1 test results on Debian woody

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

On Wed, 16 Apr 2003, Joao Cardoso wrote:

> On Wednesday 16 April 2003 02:59, Alan W. Irwin wrote:
> |  On Tue, 15 Apr 2003, Rafael Laboissiere wrote:
> |  > * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]:
> ...
>
> |  Because of the two messages about plinit, I think there is an ordering
> | problem in p16 which has been recently introduced.  Joao, can you replicate
> | this bug or has familying disappeared in your environment as well?
>
> Opened p1.png.01
> Opened p2.png.01
> Opened p3.png.01
> Opened p4.png.01
> Opened p5.png.01
> Opened p6.png.01
> Opened p7.png.01
> Opened p7.png.02
> Opened p8.png.01
> Opened p8.png.02
> Opened p9.png.01
> Opened p13.png.01
> Opened p15.png.01
> Opened p15.png.02
> Opened p16.png.01
> Opened p21.png.01

Thanks very much for that additional information.  Both familying and p16
are obviously working for Joao, but since he cannot reproduce either bug for
RC1, it makes it much tougher to figure out how to get familying working for
Rafael's environment, and p16 for my environment.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software package
(plplot.org).

__________________________

Linux-powered Science
__________________________

[Plplot-devel] Two issues

[Joao C. <jc...@fe...>]

Hi,

1-Currently the colored surface plots color scale themself using the maximum 
and minimum of the function z value, and ignoring the z axis values set by 
plw3d().

I think this is incorrect and can be observed in the interactive octave p14 
example -- as the amplitude of the function increases or decreases, the color 
of its peaks/valleys are always the same.
I can easily change this so that the maximum/minimum color of the function is 
a direct function of the z axis value. Shall I? Is there a code freeze?

2-It is very likely that some users won't get the xwin driver working. In the 
last release it happened for at least two or three of them and I tried to 
investigate it, but only one user has fully cooperate.

The common solution is to tell those users to define USE_DEFAULT_VISUAL in 
xwin.c.
It seems that all those users are using X terminals that support 
*simultaneously* 8 bit Pseudo Color and 16/24 bits True Color visuals (one of 
them also had Static Color). I couldn't reproduce the problem, because XFree 
can't use simultaneously both kind of visuals. Even if using Xnest.
So, the question is: shouldn't we define USE_DEFAULT_VISUAL in xwin.c? It 
seems to make no difference in my system. And in yours?

Maurice, you was the one still using 8 bit Pseudo Color visuals a couple of 
years ago. What do you think of this issue?

Joao

Re: [Plplot-devel] Poor RC1 test results on Debian woody

[Joao C. <jc...@fe...>]

On Wednesday 16 April 2003 02:59, Alan W. Irwin wrote:
|  On Tue, 15 Apr 2003, Rafael Laboissiere wrote:
|  > * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]:
...

|  Because of the two messages about plinit, I think there is an ordering
| problem in p16 which has been recently introduced.  Joao, can you replicate
| this bug or has familying disappeared in your environment as well?

Opened p1.png.01
Opened p2.png.01
Opened p3.png.01
Opened p4.png.01
Opened p5.png.01
Opened p6.png.01
Opened p7.png.01
Opened p7.png.02
Opened p8.png.01
Opened p8.png.02
Opened p9.png.01
Opened p13.png.01
Opened p15.png.01
Opened p15.png.02
Opened p16.png.01
Opened p21.png.01

Joao

Re: [Plplot-devel] Poor RC1 test results on Debian woody

[Joao C. <jc...@fe...>]

On Tuesday 15 April 2003 22:03, Alan W. Irwin wrote:
...

|  *** There was one nasty RC1 failure for the combination of octave and png
|  device.
|
|  Opened p16.png.01
|
|  *** PLPLOT WARNING ***
|  plsfam: Must be called before plinit.
|
|  *** PLPLOT WARNING ***
|  plsdev: Must be called before plinit.
|  Plplot library version: 5.2.1.rc1
|
|  followed by a whole bunch of garbage output.

The problem you report happened  with me once. I couldn't reproduce it 
afterwards.

If you do:

octave:1> figure(1,"png","po.png");
Opened po.png
octave:2> p16
octave:3> closefig

everything is OK. That is exactly what test_octave.sh does.
Thus the problem must be somewhere else, either in test_octave.sh or 
plplot-test.sh, but I can't find where (and the other examples work fine).

The above test was done with octave-2.1.36, running octave in bindings/octave, 
and as a regular user, with the installed plplot, setting first

LOADPATH="/usr/local/test/share/plplot_octave//:/usr/local/test/lib/plplot5.2.1.rc1/examples/octave//:"

|  Warnings.
|
|  I did notice some warnings along the way.  configure still outputs the
|  following:
|
|  configure: WARNING: itclDecls.h: present but cannot be compiled
|  configure: WARNING: itclDecls.h: check for missing prerequisite headers?
|  configure: WARNING: itclDecls.h: proceeding with the preprocessor's result
|  configure: WARNING:     ## ------------------------------------ ##
|  configure: WARNING:     ## Report this to bug...@gn.... ##
|  configure: WARNING:     ## ------------------------------------ ##

Interestingly this WARNING does not occurs with RH-8.0. But occurs with 
suse-8.1. Since I can remember.

|  * /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35
|  -I/usr/include/octave-2.1.35/
|  octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I.
|  plplot_octave.cc
|   -o plplot_octave.o
|   In file included from /usr/include/octave-2.1.35/octave/oct.h:31,
|                    from plplot_octave.cc:11:
|  		  /usr/include/octave-2.1.35/octave/config.h:148: warning:
|  HAVE_ISINF' redefined
|  ../../config.h:36: warning: this is the location of the previous
| definition /usr/include/octave-2.1.35/octave/config.h:151: warning:
| HAVE_ISNAN' redefined ../../config.h:39: warning: this is the location of
| the previous definition /usr/include/octave-2.1.35/octave/config.h:288:
| warning: HAVE_FINITE' redefined
|  ../../config.h:24: warning: this is the location of the previous
| definition /usr/include/octave-2.1.35/octave/config.h:474: warning:
| HAVE_USLEEP' redefined
|  ../../config.h:101: warning: this is the location of the previous
| definition

I had already reported this one, and said that it was unavoidable and 
harmless. Octave configure.h, that is used when compiling any user octave 
function, also defines HAVE_ISINF etc, and thus the clash.

Joao

Re: [Plplot-devel] Poor RC1 test results on Debian woody

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

On Tue, 15 Apr 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]:
>
> > *** Simple wish and tclsh tests following the directions in README.tcld=
emos
> > and README.tkdemos don't work in RC1 because there is a problem for
> > bindings/*/pkgIndex.tcl.in.  Those scripts assume the library suffix is=
 the
> > same as VERSION (true at the time I introduced those scripts, but not a=
ny
> > longer).  To solve this I have introduced LIBRARY_VERSION =3D numerical
> > suffix of the library in configure.ac which must be adjusted to be
> > consistent with SOVERSION. Rafael, can you find an automatic way of kee=
ping
> > LIBRARY_VERSION consistent with SOVERSION?  That's important because
> > otherwise we have a tcl/tk maintenance issue that will come back to hau=
nt
> > us every time SOVERSION is changed.  I did look for any variable that w=
as
> > already set to the numerical library suffix, but I couldn't find any.
>
> I dislike this solution for two reason reason.  the first, as you mention
> above, is the maintenance burden that it introduces.  The second (and mor=
e
> important) reason is that your assumption of library suffix generation do=
es
> not work cross-platform.  If I remember correctly, in HPUX (for instance)
> when SOVERSION=3D8:0:3, then the library would be something like
> libplplot.sl.8.3.  There are other system with even more exotic rule and =
the
> assumption that it will be libplplot.5.3.0 is far from being the rule.

I also agree with your second point (as you will see from my configure.ac
notes).  However, this is just a quick fix to at least get plplot to work
under wish and tclsh for Linux, and the quick fix might even work for some
unices such as solaris.  We obviously need a more fundamental solution here=
,
but that needs a tcl/tk expert to step in.

The simple problem being solved here is that wish and tclsh need to know th=
e
_complete_ PLplot library names so they can load them.  Maurice, I wonder i=
f
you could use the libtool results $prefix/lib/lib*.la to find the complete
library names that wish and tclsh need?  For example, the libplplotd versio=
n
of this file installed on my system has the following line:

library_names=3D'libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and

similarly for libplplottcltkd

library_names=3D'libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcl=
tkd.so'

If solaris lib*.la files have something similar, Maurice or Geoffry might b=
e
able to come up with a good cross-platform way to deal with this issue in
pkgIndex.tcl(.in) using the tcl equivalent of grep and cut to obtain the
first library name mentioned in the list.  Because Maurice is going on
vacation, this might be worth delaying the release for a few days.

>
> > Rafael and Joao, what are your results for
> > ./plplot-test.sh --device=3Dpng
> > ( or ./plplot-test.sh --front-end=3Doctave --device=3Dpng) for RC1.
>
> $ ./plplot-test.sh --front-end=3Doctave --device=3Dpng
> [removed warnings about automatic_replot]Opened p1.png
> Opened p2.png
> Opened p3.png
> Opened p4.png
> Opened p5.png
> Opened p6.png
> Opened p7.png
> Opened p8.png
> Opened p9.png
> Opened p13.png
> Opened p15.png
> Opened p16.png
> Plplot library version: 5.2.0.cvs.20030415
> Opened x01o.png
> [removed mouse click message]
> Opened x02o.png
> Opened x03o.png
> Opened x04o.png
> Opened x05o.png
> Opened x06o.png
> Opened x07o.png
> Opened x08o.png
> Opened x09o.png
> Opened x10o.png
> Opened x11o.png
> Opened x12o.png
> Opened x13o.png
> Opened x15o.png
> Opened x16o.png
> Opened x18o.png

Well, I certainly do _not_ get those results on Debian woody.  It appears w=
e
have now found two bugs.  The result you have above is completely incorrect
because there is no familying.  I have no idea why this bug shows up for
your system.  Does this occur just for octave?  Could you give the
=2E/plplot-test.sh --front-end=3Dc --device=3Dpng results as well?  There s=
hould
be many pages for most of the x examples, yet it appears you only have one.
If the lack of familying persists for the C front end for device=3Dpng, the=
n
please have a look at the plplot-test.sh script to see what is going on. If
it only occurs for octave, then somehow octave is not getting the familying
parameter passed to it correctly on your Debian testing version platform,
while that works fine on Debian woody.  Very strange indeed!

Here is the complete Debian woody result.  It _does_ have the proper
familying (note the different style of file names and the multiple pages fo=
r
some examples), but it also dies horribly during p16 (Rafael would probably
see this as well if familying were being correctly turned on for his case).

=2E/plplot-test.sh --front-end=3Doctave --device=3Dpng
warning: It is recommended that you set 'automatic_replot=3D1'
          in your ~/.octaverc file.
warning: in /usr/local/plplot_at/share/plplot_octave/figure.m near line 59,=
 column 7:

>>> warning ("It is recommended that you set 'automatic_replot=3D1' \n\t  i=
n your ~/.octaverc file.");


Opened p1.png.01
Opened p2.png.01
Opened p3.png.01
Opened p4.png.01
Opened p5.png.01
Opened p6.png.01
Opened p7.png.01
Opened p7.png.02
Opened p8.png.01
Opened p8.png.02
Opened p9.png.01
Opened p13.png.01
Opened p15.png.01
Opened p15.png.02
Opened p16.png.01

*** PLPLOT WARNING ***
plsfam: Must be called before plinit.

*** PLPLOT WARNING ***
plsdev: Must be called before plinit.
Plplot library version: 5.2.1.rc1
(AWI comment added.  I think the above two warning messages are the key to =
the
p16 problem).
Plotting Options:
 < 1> xwin       X-Window (Xlib)
 < 2> tk         Tcl/TK Window
 < 3> xterm      Xterm Window
 < 4> tekt       Tektronix Terminal (4010)
 < 5> tek4107t   Tektronix Terminal (4105/4107)
 < 6> mskermit   MS-Kermit emulator
 < 7> versaterm  Versaterm vt100/tek emulator
 < 8> vlt        VLT vt100/tek emulator
 < 9> conex      Conex vt320/tek emulator
 <10> dg300      DG300 Terminal
 <11> plmeta     PLplot Native Meta-File
 <12> tekf       Tektronix File (4010)
 <13> tek4107f   Tektronix File (4105/4107)
 <14> ps         PostScript File (monochrome)
 <15> psc        PostScript File (color)
 <16> xfig       Fig file
 <17> ljiip      LaserJet IIp/deskjet compressed graphics
 <18> ljii       LaserJet II Bitmap File (150 dpi)
 <19> hp7470     HP 7470 Plotter File (HPGL Cartridge, Small Plotter)
 <20> hp7580     HP 7580 Plotter File (Large Plotter)
 <21> lj_hpgl    HP Laserjet III, HPGL emulation mode
 <22> imp        Impress File
 <23> pbm        PDB (PPM) Driver
 <24> png        PNG file
 <25> jpeg       JPEG file
 <26> pstex      Combined Postscript/LaTeX files
 <27> null       Null device
 <28> ntk        New tk driver
 <29> cgm        CGM file
 <30> mem        User-supplied memory device
 <31> tkwin      New tk driver

Enter device number or keyword:
Invalid device: =AC=E1=FF=BF=D3&=CB@=D0=C67

This message is repeated many times before....

*** PLPLOT ERROR ***
plSelectDev: Too many tries.
Program aborted
Invalid device: =AC=E1=FF=BF=D3&=CB@=D0=C6

Because of the two messages about plinit, I think there is an ordering prob=
lem
in p16 which has been recently introduced.  Joao, can you replicate this
bug or has familying disappeared in your environment as well?

> It seems that most of the problems that you found are quite minor or even
> negligeable for now (besides that LIBRARY_VERSION bizareness).  I think t=
hat
> we are pretty close to a "quality release".

Well, I hope you are right.  Certainly, I think only modest changes are
required to get to a quality release.  But "the devil is in the details".

The biggest problem known at this time is the bizarre lack of familying on
Rafael's Debian platform. That really kills all png results for at least
octave (if not the other front ends as well depending on the results of
Rafael's additional familying tests.) There is also what I hope is a minor
ordering issue with p16 for octave.

Rafael, I now think you should hold off on RC2 until at least these two
issues are resolved, and furthermore we may want to delay the final release
by a few days depending on what Maurice says about the wish/tclsh library
finding problem.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software packag=
e
(plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] xwin problem

[Rafael L. <lab...@ps...>]

* Sebastian Kuzminsky <se...@he...> [2003-04-15 15:09]:

> GDB tells me... nothing.
> 
> [...]

Thanks for the additional info, but I can not see where is the problem.  I
am puzzled, sorry.
 
-- 
Rafael

Re: [Plplot-devel] xwin problem

[Sebastian K. <se...@he...>]

"Alan W. Irwin" <ir...@be...> wrote:
] On Mon, 14 Apr 2003, Sebastian Kuzminsky wrote:
] 
] > [...]Allocated 16 colors in cmap0.
] > CreatePixmap: creating pixmap: width = 1200, height = 900, depth = 24
] > fnt: 1
] > <hangs here>
] >
] >
] >
] >
] > When i run the same app on this same machine, but displaying over the
] > net to another box, it works.
] 
] I wonder if the hang is due to some authentication problem, waiting for some
] resource (colours?), or some other issue with your X server on the hanging
] machine?  If you run PLplot apps on another machine and display results on the
] machine that hangs for a local Plplot app, do you still get the hang?


Yes it still breaks.  I no longer think it's a hang, though.  plinit()
returns, it doesnt hang like i had reported.




]                                                                        How
] about if you run any other X app (e.g., xterm) on another machine and
] display it on the hanging machine?


All other X apps work fine, in all combinations of "run on local
(breaking) machine or remote" and "display on local (breaking) machine
or remote".




] You might also want to try -dev tk and -dev ntk to see how they display
] on your hanging machine.  Those devices are also X based, but presumably
] they use X in a different way than -dev xwin so they may work better (or
] work worse with a better error message) than -dev xwin.


"-dev tk" and "-dev ntk" both work like a champ.  Far as i can tell,
it's just xwin that's hosed.




--
Sebastian

Re: [Plplot-devel] xwin problem

[Sebastian K. <se...@he...>]

Rafael Laboissiere <lab...@ps...> wrote:
] * Sebastian Kuzminsky <se...@he...> [2003-04-15 13:26]:
] 
] > Rafael Laboissiere <lab...@ps...> wrote:
] > ] That is very strange, since the pacakge in SF was built in a Debian testing
] > ] (sarge) system.  It should work at least in your Sarge/Sid hybrid.  I need
] > ] more informations in order to understand where the problme comes from.
] >
] > What additional information can i give you?
] 
] What does gdb tells you?


GDB tells me... nothing.


The version of libplplotd.so.5 in the debian package i'm using is compiled
without debugging information, so i cant step into it.  When i step over
it, it asks for a display driver, i tell it xwin, it pops open a window,
destroys it right away, and returns.


Here's an strace of just the plinit() call (i put printfs immediately
before and after the plinit() call to show entry and exit):


6278  write(1, "calling plinit\n", 15)  = 15
6278  write(1, "\nPlotting Options:\n", 19) = 19
6278  write(1, " < 1> xwin       X-Window (Xlib)"..., 33) = 33
6278  write(1, " < 2> gnome      Gnome Canvas\n", 30) = 30
6278  write(1, " < 3> xterm      Xterm Window\n", 30) = 30
6278  write(1, " < 4> tekt       Tektronix Termi"..., 43) = 43
6278  write(1, " < 5> tek4107t   Tektronix Termi"..., 48) = 48
6278  write(1, " < 6> mskermit   MS-Kermit emula"..., 36) = 36
6278  write(1, " < 7> versaterm  Versaterm vt100"..., 46) = 46
6278  write(1, " < 8> vlt        VLT vt100/tek e"..., 40) = 40
6278  write(1, " < 9> conex      Conex vt320/tek"..., 42) = 42
6278  write(1, " <10> dg300      DG300 Terminal\n", 32) = 32
6278  write(1, " <11> plmeta     PLplot Native M"..., 41) = 41
6278  write(1, " <12> tekf       Tektronix File "..., 39) = 39
6278  write(1, " <13> tek4107f   Tektronix File "..., 44) = 44
6278  write(1, " <14> ps         PostScript File"..., 46) = 46
6278  write(1, " <15> psc        PostScript File"..., 41) = 41
6278  write(1, " <16> xfig       Fig file\n", 26) = 26
6278  write(1, " <17> ljiip      LaserJet IIp/de"..., 58) = 58
6278  write(1, " <18> ljii       LaserJet II Bit"..., 51) = 51
6278  write(1, " <19> hp7470     HP 7470 Plotter"..., 70) = 70
6278  write(1, " <20> hp7580     HP 7580 Plotter"..., 54) = 54
6278  write(1, " <21> lj_hpgl    HP Laserjet III"..., 54) = 54
6278  write(1, " <22> imp        Impress File\n", 30) = 30
6278  write(1, " <23> pbm        PDB (PPM) Drive"..., 34) = 34
6278  write(1, " <24> png        PNG file\n", 26) = 26
6278  write(1, " <25> jpeg       JPEG file\n", 27) = 27
6278  write(1, " <26> pstex      Combined Postsc"..., 49) = 49
6278  write(1, " <27> null       Null device\n", 29) = 29
6278  write(1, " <28> mem        User-supplied m"..., 45) = 45
6278  write(1, "\n", 1)                 = 1
6278  fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
6278  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000
6278  write(1, "Enter device number or keyword: ", 32) = 32
6278  read(0, "1\n", 1024)              = 2
6278  open("/usr/lib/plplot5.2.0.cvs.20030403/data/../driversd/xwin.la", O_RDONLY) = 3
6278  fstat64(3, {st_mode=S_IFREG|0644, st_size=847, ...}) = 0
6278  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
6278  read(3, "# xwin.la - a libtool library fi"..., 4096) = 847
6278  read(3, "", 4096)                 = 0
6278  close(3)                          = 0
6278  munmap(0x40014000, 4096)          = 0
6278  open("/usr/lib/plplot5.2.0.cvs.20030403/data/../driversd/xwin.so", O_RDONLY) = 3
6278  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\31\0\000"..., 1024) = 1024
6278  fstat64(3, {st_mode=S_IFREG|0644, st_size=28644, ...}) = 0
6278  old_mmap(NULL, 35284, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4023e000
6278  mprotect(0x40245000, 6612, PROT_NONE) = 0
6278  old_mmap(0x40245000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x6000) = 0x40245000
6278  old_mmap(0x40246000, 2516, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40246000
6278  close(3)                          = 0
6278  open("/etc/ld.so.cache", O_RDONLY) = 3
6278  fstat64(3, {st_mode=S_IFREG|0644, st_size=29365, ...}) = 0
6278  old_mmap(NULL, 29365, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40247000
6278  close(3)                          = 0
6278  open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3
6278  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\22\1"..., 1024) = 1024
6278  fstat64(3, {st_mode=S_IFREG|0644, st_size=760260, ...}) = 0
6278  brk(0)                            = 0x804c000
6278  brk(0x804d000)                    = 0x804d000
6278  old_mmap(NULL, 761340, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4024f000
6278  mprotect(0x40306000, 11772, PROT_NONE) = 0
6278  old_mmap(0x40306000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb7000) = 0x40306000
6278  close(3)                          = 0
6278  munmap(0x40247000, 29365)         = 0
6278  brk(0)                            = 0x804d000
6278  brk(0x804e000)                    = 0x804e000
6278  uname({sys="Linux", node="dub", ...}) = 0
6278  socket(PF_UNIX, SOCK_STREAM, 0)   = 3
6278  uname({sys="Linux", node="dub", ...}) = 0
6278  uname({sys="Linux", node="dub", ...}) = 0
6278  connect(3, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19) = 0
6278  uname({sys="Linux", node="dub", ...}) = 0
6278  fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
6278  access("/home/seb/.Xauthority", R_OK) = 0
6278  open("/home/seb/.Xauthority", O_RDONLY) = 4
6278  fstat64(4, {st_mode=S_IFREG|0600, st_size=469, ...}) = 0
6278  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
6278  read(4, "\0\0\0\4\n\1\1{\0\0010\0\22MIT-MAGIC-COOKIE-1\0"..., 4096) = 469
6278  read(4, "", 4096)                 = 0
6278  close(4)                          = 0
6278  munmap(0x40014000, 4096)          = 0
6278  brk(0)                            = 0x804e000
6278  brk(0x804f000)                    = 0x804f000
6278  writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\321<\274\273I\0055\310\347\355\27\351\0\r=.", 16}], 4) = 48
6278  fcntl64(3, F_GETFL)               = 0x2 (flags O_RDWR)
6278  fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
6278  read(3, "\1\0\v\0\0\0@\0", 8)     = 8
6278  read(3, "(ke\2\0\0\340\1\377\377\37\0\0\1\0\0\30\0\377\377\1\7\0"..., 256) = 256
6278  write(3, "7\0\5\0\0\0\340\0016\0\0\0\10\0\0\0\377\377\377\0b\0\5"..., 64) = 64
6278  read(3, "\1\203\2\0\0\0\0\0\1\202\0\0\0\0\0\0\0\0\0\0\30\0\0\0\0"..., 32) = 32
6278  read(3, "\1\10\3\0\355\3\0\0\37\0\0\0\0\0\0\0\262\17\0\0\0\0\0\0"..., 32) = 32
6278  brk(0)                            = 0x804f000
6278  brk(0x8050000)                    = 0x8050000
6278  readv(3, [{"*BorderColor:\tred\n*Font:\tfixed\n*"..., 4018}, {"\0\0", 2}], 2) = 4020
6278  write(3, "\202\0\1\0", 4)         = 4
6278  read(3, "\1\203\4\0\0\0\0\0\377\377\17\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 32) = 32
6278  writev(3, [{"b\0\5\0\t\0\340\1", 8}, {"XKEYBOARD", 9}, {"\0\0\0", 3}], 3) = 20
6278  read(3, "\1\203\5\0\0\0\0\0\1\224n\256\0\0\0\0\1\0\0\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "\224\0\2\0\1\0\0\0", 8) = 8
6278  read(3, "\1\1\6\0\0\0\0\0\1\0\0\0\0\211\243\10\0\20\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "T\0\4\0 \0\0\0\0\0\0\0\0\0\0\0", 16) = 16
6278  read(3, "\1\203\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "T\0\4\0 \0\0\0\377\377\377\377\377\377\0\0", 16) = 16
6278  read(3, "\1\203\10\0\0\0\0\0\377\377\377\377\377\377\0\0\377\377"..., 32) = 32
6278  write(3, "\16\0\2\0006\0\0\0", 8) = 8
6278  read(3, "\1\30\t\0\0\0\0\0006\0\0\0\0\0\0\0@\6\260\4\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "\1\30\10\0\1\0\340\0016\0\0\0\250\364\0\0\260\4\204\3\5"..., 212) = 212
6278  read(3, "\1\203\16\0\0\0\0\0\377\377\0\0\0\0\0\0\0\0\377\0\0\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\377\377\377\377\0\0\0\0", 16) = 16
6278  read(3, "\1\203\17\0\0\0\0\0\377\377\377\377\0\0\0\0\0\377\377\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\0\0\377\377\0\0\0\0", 16) = 16
6278  read(3, "\1\203\20\0\0\0\0\0\0\0\377\377\0\0\0\0\0\377\0\0\0\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\177\177\377\377\324\324\0\0", 16) = 16
6278  read(3, "\1\203\21\0\0\0\0\0\177\177\377\377\324\324\0\0\324\377"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\377\377\300\300\313\313\0\0", 16) = 16
6278  read(3, "\1\203\22\0\0\0\0\0\377\377\300\300\313\313\0\0\313\300"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\365\365\336\336\263\263\0\0", 16) = 16
6278  read(3, "\1\203\23\0\0\0\0\0\365\365\336\336\263\263\0\0\263\336"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\276\276\276\276\276\276\0\0", 16) = 16
6278  read(3, "\1\203\24\0\0\0\0\0\276\276\276\276\276\276\0\0\276\276"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\245\245****\0\0", 16) = 16
6278  read(3, "\1\203\25\0\0\0\0\0\245\245****\0\0**\245\0\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\0\0\0\0\377\377\0\0", 16) = 16
6278  read(3, "\1\203\26\0\0\0\0\0\0\0\0\0\377\377\0\0\377\0\0\0\0\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\212\212++\342\342\0\0", 16) = 16
6278  read(3, "\1\203\27\0\0\0\0\0\212\212++\342\342\0\0\342+\212\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\0\0\377\377\377\377\0\0", 16) = 16
6278  read(3, "\1\203\30\0\0\0\0\0\0\0\377\377\377\377\0\0\377\377\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0@@\340\340\320\320\0\0", 16) = 16
6278  read(3, "\1\203\31\0\0\0\0\0@@\340\340\320\320\0\0\320\340@\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\377\377\0\0\377\377\0\0", 16) = 16
6278  read(3, "\1\203\32\0\0\0\0\0\377\377\0\0\377\377\0\0\377\0\377\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\372\372\200\200rr\0\0", 16) = 16
6278  read(3, "\1\203\33\0\0\0\0\0\372\372\200\200rr\0\0r\200\372\0\0"..., 32) = 32
6278  write(3, "T\30\4\0 \0\0\0\377\377\377\377\377\377\0\0", 16) = 16
6278  read(3, "\1\203\34\0\0\0\0\0\377\377\377\377\377\377\0\0\377\377"..., 32) = 32
6278  write(3, "\2\30\4\0\1\0\340\1\0 \0\0 \0\0\0007\4\4\0\2\0\340\1\1"..., 68) = 68
6278  read(3, "\1\30 \0\0\0\0\0006\0\0\0\250\364\0\0\260\4\204\3\5\0\0"..., 32) = 32
6278  write(3, "5\30\4\0\4\0\340\1\1\0\340\1\260\4\204\3+\4\1\0", 20) = 20
6278  read(3, "\1\2\"\0\0\0\0\0&\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
6278  ioctl(3, FIONREAD, [0])           = 0
6278  write(3, "\2\30\4\0\1\0\340\1\2\0\0\0\0\0\0\0\2\4\4\0\1\0\340\1\0"..., 56) = 56
6278  read(3, "\26\0&\0\1\0\340\1\1\0\340\1\n\0\300\0\250\364\0\0\260"..., 32) = 32
6278  ioctl(3, FIONREAD, [32])          = 0
6278  read(3, "\26\0&\0\1\0\340\1\1\0\340\1\n\0\300\0\250\364\0\0\260"..., 32) = 32
6278  ioctl(3, FIONREAD, [64])          = 0
6278  read(3, "\25\370&\0\1\0\340\1\1\0\340\1\255\5\300\0\5\0\26\0\0\0"..., 64) = 64
6278  ioctl(3, FIONREAD, [128])         = 0
6278  read(3, "\226\361&\0\1\0\340\1\1\0\340\1\255\5\300\0\r\0\36\0\260"..., 128) = 128
6278  ioctl(3, FIONREAD, [0])           = 0
6278  write(3, "=\0\4\0\1\0\340\1\0\0\0\0\0\0\0\0008\4\4\0\2\0\340\1\10"..., 56) = 56
6278  read(3, 0xbffff558, 32)           = -1 EAGAIN (Resource temporarily unavailable)
6278  select(4, [3], NULL, NULL, NULL)  = 1 (in [3])
6278  read(3, "\1\2*\0\0\0\0\0&\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
6278  stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
6278  gettimeofday({1050440387, 962663}, NULL) = 0
6278  getpid()                          = 6278
6278  open("/tmp/tmpf1qZX1Z", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
6278  rmdir("/tmp/tmpf1qZX1Z")          = -1 ENOTDIR (Not a directory)
6278  unlink("/tmp/tmpf1qZX1Z")         = 0
6278  fcntl64(4, F_GETFL)               = 0x2 (flags O_RDWR)
6278  fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
6278  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
6278  _llseek(4, 0, [0], SEEK_CUR)      = 0
6278  write(1, "fnt: 1\n", 7)           = 7
6278  open("plxtnd5.fnt", O_RDONLY)     = -1 ENOENT (No such file or directory)
6278  open("/usr/lib/plplot5.2.0.cvs.20030403/data/plxtnd5.fnt", O_RDONLY) = 5
6278  fstat64(5, {st_mode=S_IFREG|0644, st_size=58808, ...}) = 0
6278  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
6278  read(5, "\260\4I\3\203\3M\3O\3H\3N\3I\3J\3\354\10\351\10\337\2K"..., 4096) = 4096
6278  brk(0)                            = 0x8050000
6278  brk(0x8052000)                    = 0x8052000
6278  read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
6278  brk(0)                            = 0x8052000
6278  brk(0x805e000)                    = 0x805e000
6278  read(5, "\375\374@\0\3\5\3\374@\0\375\1\3\1@@\374\5\373\6\0\5\376"..., 49152) = 49152
6278  read(5, "\373\370@\0\375\v\375\f\374\f\374\v\375\t\377\10\1\10\3"..., 4096) = 1464
6278  close(5)                          = 0
6278  munmap(0x40015000, 4096)          = 0
6278  write(1, "plinit returns\n", 15)  = 15




--
Sebastian

Re: [Plplot-devel] Poor RC1 test results on Debian woody

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-04-15 14:03]:

> *** Simple wish and tclsh tests following the directions in README.tcldemos
> and README.tkdemos don't work in RC1 because there is a problem for
> bindings/*/pkgIndex.tcl.in.  Those scripts assume the library suffix is the
> same as VERSION (true at the time I introduced those scripts, but not any
> longer).  To solve this I have introduced LIBRARY_VERSION = numerical
> suffix of the library in configure.ac which must be adjusted to be
> consistent with SOVERSION. Rafael, can you find an automatic way of keeping
> LIBRARY_VERSION consistent with SOVERSION?  That's important because
> otherwise we have a tcl/tk maintenance issue that will come back to haunt
> us every time SOVERSION is changed.  I did look for any variable that was
> already set to the numerical library suffix, but I couldn't find any.

I dislike this solution for two reason reason.  the first, as you mention
above, is the maintenance burden that it introduces.  The second (and more
important) reason is that your assumption of library suffix generation does
not work cross-platform.  If I remember correctly, in HPUX (for instance)
when SOVERSION=8:0:3, then the library would be something like
libplplot.sl.8.3.  There are other system with even more exotic rule and the
assumption that it will be libplplot.5.3.0 is far from being the rule.

> Rafael and Joao, what are your results for
> ./plplot-test.sh --device=png
> ( or ./plplot-test.sh --front-end=octave --device=png) for RC1.

$ ./plplot-test.sh --front-end=octave --device=png
[removed warnings about automatic_replot]Opened p1.png
Opened p2.png
Opened p3.png
Opened p4.png
Opened p5.png
Opened p6.png
Opened p7.png
Opened p8.png
Opened p9.png
Opened p13.png
Opened p15.png
Opened p16.png
Plplot library version: 5.2.0.cvs.20030415
Opened x01o.png
[removed mouse click message]
Opened x02o.png
Opened x03o.png
Opened x04o.png
Opened x05o.png
Opened x06o.png
Opened x07o.png
Opened x08o.png
Opened x09o.png
Opened x10o.png
Opened x11o.png
Opened x12o.png
Opened x13o.png
Opened x15o.png
Opened x16o.png
Opened x18o.png

> * /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35
> -I/usr/include/octave-2.1.35/
> octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I.
> plplot_octave.cc
>  -o plplot_octave.o
>  In file included from /usr/include/octave-2.1.35/octave/oct.h:31,
>                   from plplot_octave.cc:11:
> 		  /usr/include/octave-2.1.35/octave/config.h:148: warning:
> HAVE_ISINF' redefined
> ../../config.h:36: warning: this is the location of the previous definition
> /usr/include/octave-2.1.35/octave/config.h:151: warning: HAVE_ISNAN' redefined
> ../../config.h:39: warning: this is the location of the previous definition
> /usr/include/octave-2.1.35/octave/config.h:288: warning: HAVE_FINITE'
> redefined
> ../../config.h:24: warning: this is the location of the previous definition
> /usr/include/octave-2.1.35/octave/config.h:474: warning: HAVE_USLEEP'
> redefined
> ../../config.h:101: warning: this is the location of the previous definition
> 
> Rafael or Joao may want to deal with these warnings before the release.

Joao and I agreed that these are totally harmless warnings.  As Maurice uses
to say, they are just irritating.  In sum, I am not going to fix this before
the release.

> That (and a quick check of RC2 for the above issues) is about all the
> testing I have time for before the release so again, somebody else is going
> to have to step forward if you want a quality release.

It seems that most of the problems that you found are quite minor or even
negligeable for now (besides that LIBRARY_VERSION bizareness).  I think that
we are pretty close to a "quality release".

-- 
Rafael

Re: [Plplot-devel] xwin problem

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

On Mon, 14 Apr 2003, Sebastian Kuzminsky wrote:

> [...]Allocated 16 colors in cmap0.
> CreatePixmap: creating pixmap: width = 1200, height = 900, depth = 24
> fnt: 1
> <hangs here>
>
>
>
>
> When i run the same app on this same machine, but displaying over the
> net to another box, it works.

I wonder if the hang is due to some authentication problem, waiting for some
resource (colours?), or some other issue with your X server on the hanging
machine?  If you run PLplot apps on another machine and display results on the
machine that hangs for a local Plplot app, do you still get the hang?  How
about if you run any other X app (e.g., xterm) on another machine and
display it on the hanging machine?

You might also want to try -dev tk and -dev ntk to see how they display
on your hanging machine.  Those devices are also X based, but presumably
they use X in a different way than -dev xwin so they may work better (or
work worse with a better error message) than -dev xwin.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software package
(plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Poor RC1 test results on Debian woody

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > I did notice some warnings along the way.  configure still outputs the
 > following:
 > 
 > configure: WARNING: itclDecls.h: present but cannot be compiled
 > configure: WARNING: itclDecls.h: check for missing prerequisite headers?
 > configure: WARNING: itclDecls.h: proceeding with the preprocessor's result
 > configure: WARNING:     ## ------------------------------------ ##
 > configure: WARNING:     ## Report this to bug...@gn.... ##
 > configure: WARNING:     ## ------------------------------------ ##

AFAIK this is harmless.  Just irritating. :)

 > This is a symptom of the poor state of our unix/linux tcl/tk configuration.
 > I wanted to replace that configuration, but I didn't feel right attempting
 > that since I am no tcl/tk expert.  I noticed, however, that the tclConfig.sh
 > that comes with tcl8.3 is deprecated and it is not immediately obvious how
 > to use it with autotools. Its suggested replacement, tcl.m4 is supposed to
 > fit in with autotools, but it needs an m4/autoconf expert to look at it to
 > see if it is consistent with the current generation of autotools.  (I
 > suspect it is not from all the name clashes I see.) Whether that is a post
 > or pre-release issue really depends on how well our current tcl/tk
 > configuration works cross-platform. Maurice and Geoffrey, does the current
 > tcl/tk configuration work okay on all Linux/Unix platforms accessible to
 > you?

I believe so.  Sorry I've been MIA as of late, but have been swampt.  In
addition I will be taking a much needed vacation from tomorrow until Sunday.
I *will* try to give the latest RC at least a cursory check on both RH7.3
and Solaris.

As for the tcl config problems, I will look into it but it will take some
time.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] Poor RC1 test results on Debian woody

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

I was just able to find some time to test RC1 on my Debian woody system.
Sadly, it does not give a well-tested impression.  I was really relying on
the rest of you to do some extensive checks for tcl/tk and octave, but it
appears those have not been done in even a superficial manner.  For a number
of good reasons I really am scaling back my testing role to superficial
checks that anybody can do on their own system, and somebody else here has
to take up the slack if we are going to have a quality product.

That said, I have fixed the obvious stuff.  If in addition, Rafael or Joao
can fix the p16 octave example (and anything else that shows up for a
complete octave test), then I think Rafael should go ahead with RC2 early
tomorrow (Wednesday).

Here is what I did:

./configure --prefix=/usr/local/plplot_at --enable-java --disable-static
--with-prebuiltdoc >& configure.out

make; make install

A superficial check of the various kinds of installed documentation went well.

plplot-test.sh built psc and plmeta files with no obvious problems (other than
an obvious pladv ordering bug in x21c which I have just fixed).

I was able to do some minimal tcl/tk testing as well (although Maurice and
Geoffrey should be responsible for most of that testing).

*** Simple wish and tclsh tests following the directions in README.tcldemos
and README.tkdemos don't work in RC1 because there is a problem for
bindings/*/pkgIndex.tcl.in.  Those scripts assume the library suffix is the
same as VERSION (true at the time I introduced those scripts, but not any
longer).  To solve this I have introduced LIBRARY_VERSION = numerical suffix
of the library in configure.ac which must be adjusted to be consistent with
SOVERSION. Rafael, can you find an automatic way of keeping LIBRARY_VERSION
consistent with SOVERSION?  That's important because otherwise we have a
tcl/tk maintenance issue that will come back to haunt us every time
SOVERSION is changed.  I did look for any variable that was already set to
the numerical library suffix, but I couldn't find any.

*** There was one nasty RC1 failure for the combination of octave and png
device.

Opened p16.png.01

*** PLPLOT WARNING ***
plsfam: Must be called before plinit.

*** PLPLOT WARNING ***
plsdev: Must be called before plinit.
Plplot library version: 5.2.1.rc1

followed by a whole bunch of garbage output.

This should have easily been found with even superficial octave testing unless
there is some platform difference between me on the one hand and Joao and
Rafael on the other.
Rafael and Joao, what are your results for
./plplot-test.sh --device=png
( or ./plplot-test.sh --front-end=octave --device=png) for RC1.

If they verify this problem I suspect it is due to some recent change to p16
that does something out of order since that example worked before for me
with png.

Warnings.

I did notice some warnings along the way.  configure still outputs the
following:

configure: WARNING: itclDecls.h: present but cannot be compiled
configure: WARNING: itclDecls.h: check for missing prerequisite headers?
configure: WARNING: itclDecls.h: proceeding with the preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug...@gn.... ##
configure: WARNING:     ## ------------------------------------ ##

This is a symptom of the poor state of our unix/linux tcl/tk configuration.
I wanted to replace that configuration, but I didn't feel right attempting
that since I am no tcl/tk expert.  I noticed, however, that the tclConfig.sh
that comes with tcl8.3 is deprecated and it is not immediately obvious how
to use it with autotools. Its suggested replacement, tcl.m4 is supposed to
fit in with autotools, but it needs an m4/autoconf expert to look at it to
see if it is consistent with the current generation of autotools.  (I
suspect it is not from all the name clashes I see.) Whether that is a post
or pre-release issue really depends on how well our current tcl/tk
configuration works cross-platform. Maurice and Geoffrey, does the current
tcl/tk configuration work okay on all Linux/Unix platforms accessible to
you?

Here are some compiler warnings that I noticed:

* plplotcmodule_double.c:684: warning: PySequence_Fast_GET_ITEM' redefined
//usr/include/python2.1/abstract.h:902: warning: this is the location of the
previous definition

I believe this is a swig issue that we have no control over (except to try
later swig versions post-release and send in bug reports to swig if the
issue is still there).

* /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35
-I/usr/include/octave-2.1.35/
octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I.
plplot_octave.cc
 -o plplot_octave.o
 In file included from /usr/include/octave-2.1.35/octave/oct.h:31,
                  from plplot_octave.cc:11:
		  /usr/include/octave-2.1.35/octave/config.h:148: warning:
HAVE_ISINF' redefined
../../config.h:36: warning: this is the location of the previous definition
/usr/include/octave-2.1.35/octave/config.h:151: warning: HAVE_ISNAN' redefined
../../config.h:39: warning: this is the location of the previous definition
/usr/include/octave-2.1.35/octave/config.h:288: warning: HAVE_FINITE'
redefined
../../config.h:24: warning: this is the location of the previous definition
/usr/include/octave-2.1.35/octave/config.h:474: warning: HAVE_USLEEP'
redefined
../../config.h:101: warning: this is the location of the previous definition

Rafael or Joao may want to deal with these warnings before the release.

* Whole host of tk-x-plat/plplotter.c warnings.  IIRC, Vince said those
disappear if you use a version of tcl that is later than 8.3.
Alternatively, these symptoms may be a result of our iffy tcl/tk
configuration.

That (and a quick check of RC2 for the above issues) is about all the
testing I have time for before the release so again, somebody else is going
to have to step forward if you want a quality release.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software package
(plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] xwin problem

[Rafael L. <lab...@ps...>]

* Sebastian Kuzminsky <se...@he...> [2003-04-15 13:26]:

> Rafael Laboissiere <lab...@ps...> wrote:
> ] That is very strange, since the pacakge in SF was built in a Debian testing
> ] (sarge) system.  It should work at least in your Sarge/Sid hybrid.  I need
> ] more informations in order to understand where the problme comes from.
>
> What additional information can i give you?

What does gdb tells you?

-- 
Rafael

Re: [Plplot-devel] xwin problem

[Sebastian K. <se...@he...>]

Rafael Laboissiere <lab...@ps...> wrote:
] * Sebastian Kuzminsky <se...@he...> [2003-04-14 23:50]:
] 
] > Hi folks, i'm new to plplot but it seems like a great product.  On most
] > of the machines i work with it works great, but two have problems with
] > the xwin driver.  When i call plinit() it creates a window, immediately
] > destroys it, then hangs.  One machine is running Debian Woody (XF86
] > 4.1.0, glibc 2.2.5) and the other's running a Sarge/Sid hybrid (XF 4.2.1,
] > glibc 2.3.1).  The Gnome driver works fine on both.  I'm using the plplot
] > .debs from sourceforge: 5.2.0.cvs.20030403-1.
] 
] That is very strange, since the pacakge in SF was built in a Debian testing
] (sarge) system.  It should work at least in your Sarge/Sid hybrid.  I need
] more informations in order to understand where the problme comes from.


What additional information can i give you?




] > Here's the output from "./x07c -verbose -debug -dev xwin":
] 
] Is this the original x07c.c or did you change it?


It's what came with the debian package, i haven't changed it.  MD5 sum is:

ec8e9cc2b8e684eac203873d1acaca13  x07c.c




--
Sebastian

Re: [Plplot-devel] Noticed a few minor issues with the examples on our web site.

[<jc...@fe...>]

On Monday 14 April 2003 19:05, Jo=E3o Cardoso wrote:
| On Monday 14 April 2003 16:17, Alan W. Irwin wrote:
| | Joao, there are some minor issues with the examples part of the web
| | site that you may want to address before the release.  I noticed
| | that the commentary at
| | http://plplot.sourceforge.net/examples/index.html needs to be
| | changed, and you probably will also want to include example 21 (and
| | perhaps screenshots of the interactive examples 14 and 17 as well).
|
| I will do that.
| I just put it in my non-solid-state agenda (so I have an excuse, kind
| of oops, forgot to... :)
|
| Joao

I made changes to add the x21 example,  but my connection to=20
login.sf.net is painfully slow. I start applying the changes but...=20
it's too slow. Please finish it.

The htdocs_plot_examples.tgz that you find there is current. Somehow=20
"cvs export" created CVS entries in the htdocs directory? Please fix=20
it.

Thanks,
Joao

Re: [Plplot-devel] PLplot RC1 (fwd)

[<jc...@fe...>]

On Monday 14 April 2003 19:35, Jo=E3o Cardoso wrote:
| On Monday 14 April 2003 16:17, Rafael Laboissiere wrote:
=2E..
| | > c) in example 20 when selecting the first point the crosshair has
| | > two additional lines added, they start at the left edge of the
| | > lena picture approx. at 25% and 50% of the height. The line
| | > starting at 50 % goes to the coordinates (40% of xmax, y) and the
| | > other one to (x, 50% of ymax)
| |
| | I cannot replicate this neither.
|
| Neither me.
| Joao

Well, after all I can. If the first mouse selection is done with the=20
middle button, which is normally used to extend an already existing=20
selection, funny things happen.
But I think this is a minor issue.

Thanks for reporting it anyway,

Joao

[Plplot-devel] Re: Some RC1 tarball problems

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

On Tue, 15 Apr 2003, Rafael Laboissiere wrote:

> To Alan: time for a RC2 tarball?

The changes since RC1 have been pretty minimal, but I would prefer our users
test a version as close as possible to what final will be so I think RC2 is
a good idea.  However, let's wait until tomorrow morning, (Wednesday, which
will nicely split the test week).  Also, I will get my first chance to build
and install RC1 on my own machine today.

To the other developers here.  It sounds like today is the last chance to
test RC1 and get any necessary changes into RC2.  Also, even if your test is
completely successful please let us know about it!  I want to be able to
brag about those successes on Saturday for the official announcement.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliation with the PLplot scientific plotting software package
(plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot RC1 (fwd)

[<jc...@fe...>]

On Tuesday 15 April 2003 08:58, Volker Naulin wrote:
| On Mon, 14 Apr 2003, Jo=E3o Cardoso wrote:
| > On Monday 14 April 2003 16:17, Rafael Laboissiere wrote:
=2E..

| > The problem must be the one I said, a non-existing Qhull library in
| > the system; in that case a warning message should be printed and
| > the second and third plot should be flat. To reproduce, configure
| > with --without-qhull.
| >
| > Volker, can you please check that in the config.summary file is a
| > line that says:
| >    with_qhull:     no
|
| Hej,
|
| yes, it does say so. My fault not to look at the terminal
| output....does give a warning message. However, I noticed that qhull
| is not available as a RPM (using rpmfind), nor part of any linux
| distribution...would it make sense to distribute it with plplot?

As Qhull it has its own page (inacessible for me most of the time)
http://www.geom.umn.edu, with a working mirror at=20
http://www.thesa.com/software/qhull/ and sources at
http://savannah.nongnu.org/download/qhull/qhull-new.pkg/2002.1/qhull2002.1.=
tgz

I don't think we should include it in PLplot. We could however provide=20
the its sources in our download page.

The sources, at savannah.nongnu.org, are only 470K.

 Compiling for Unix

  The gzip file, qhull.tgz, contains documentation and source files for
  qhull and rbox. =20
 =20
  To unpack the gzip file
  - tar zxf qhull.tgz
  - cd qhull
 =20
  Compiling with the Debian Make:[R. Laboissiere]
  - cd src
  - ./Make-config.sh
  - cd ..
  - configure
  - make


Thanks,
Joao

Re: [Plplot-devel] Re: PLplot RC1 (fwd)

[<jc...@fe...>]

On Monday 14 April 2003 18:14, Alan W. Irwin wrote:
| ---------- Forwarded message ----------
| Date: Mon, 14 Apr 2003 16:58:39 +0200 (CEST)
| From: Volker Naulin <vol...@ri...>
| To: Alan W. Irwin <ir...@be...>
| Cc: Volker Naulin <vol...@ri...>
| Subject: Re: PLplot RC1
|
| On Mon, 14 Apr 2003, Alan W. Irwin wrote:
|
| Hello,
|
| sorry, the platform is intel p4 running Mandrake 9.0 and Mandrake
| 9.1.
|
| There is one additional point:
| In the plot of the world map (example 19) there is a very large
| equator drawn (about 5% of the heigth of the map)......

I confirm this. Fixed.

Thanks,
Joao

Re: [Plplot-devel] xwin problem

[Rafael L. <lab...@ps...>]

* Sebastian Kuzminsky <se...@he...> [2003-04-14 23:50]:

> Hi folks, i'm new to plplot but it seems like a great product.  On most
> of the machines i work with it works great, but two have problems with
> the xwin driver.  When i call plinit() it creates a window, immediately
> destroys it, then hangs.  One machine is running Debian Woody (XF86
> 4.1.0, glibc 2.2.5) and the other's running a Sarge/Sid hybrid (XF 4.2.1,
> glibc 2.3.1).  The Gnome driver works fine on both.  I'm using the plplot
> .debs from sourceforge: 5.2.0.cvs.20030403-1.

That is very strange, since the pacakge in SF was built in a Debian testing
(sarge) system.  It should work at least in your Sarge/Sid hybrid.  I need
more informations in order to understand where the problme comes from.

> Here's the output from "./x07c -verbose -debug -dev xwin":
>
> [...]

Is this the original x07c.c or did you change it?

-- 
Rafael

Re: [Plplot-devel] PLplot RC1 (fwd)

[Volker N. <vol...@ri...>]

On Mon, 14 Apr 2003, Jo=E3o Cardoso wrote:

> On Monday 14 April 2003 16:17, Rafael Laboissiere wrote:
> | Hi,
> |
> | Alan Irwin forwarded your message to us, thanks for the bug reports.
> | I am replying to your msg below, with Cc: to plplot-devel.  I hope
> | you do not mind it.
> |
> | * Volker Naulin <vol...@ri...> [2003-04-14 07:21]:
> | > b) in example 21 Delauny and natural neighbours give something
> | > strange, mostly flat
> |
> | This does not happen for me.  How different are your results from
> | this:
> |
> |     http://people.debian.org/~rafael/griddata.ps
>
> The problem must be the one I said, a non-existing Qhull library in the
> system; in that case a warning message should be printed and the second
> and third plot should be flat. To reproduce, configure with
> --without-qhull.
>
> Volker, can you please check that in the config.summary file is a line
> that says:
>    with_qhull:     no

Hej,

yes, it does say so. My fault not to look at the terminal output....does
give a warning message. However, I noticed that qhull is not available as
a RPM (using rpmfind), nor part of any linux distribution...would it make
sense to distribute it with plplot?


>
> | > c) in example 20 when selecting the first point the crosshair has
> | > two additional lines added, they start at the left edge of the lena
> | > picture approx. at 25% and 50% of the height. The line starting at
> | > 50 % goes to the coordinates (40% of xmax, y) and the other one to
> | > (x, 50% of ymax)
> |
> | I cannot replicate this neither.
>
> Neither me.

Well, so I here include the results of  configure on a Mandrake 9.0 with
recent updates:


Configure results:

command:=09./configure --prefix=3D/usr/local
system:=09=09i686-pc-linux-gnu
have_x:=09=09yes
prefix:=09=09/usr/local
CC:=09=09gcc
CXX:=09=09g++
LIB_TAG:=09d
devices:=09 dg300 png jpeg hp7470 hp7580 lj_hpgl imp ljii ljiip mem ntk nul=
l pbm plmeta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt cone=
x tek4010f tek4107f tk xfig xwin

Available device drivers:
static:
dynamic:=09 dg300.la gd.la hpgl.la impress.la ljii.la ljiip.la mem.la ntk.l=
a null.la pbm.la plmeta.la ps.la pstex.la tek.la tk.la xfig.la xwin.la

Compilation options:
with_debug:=09no=09=09with_opt:=09yes
with_warn:=09no=09=09with_profile:=09no

Library options:
enable_shared:=09yes=09=09enable_static:=09yes
with_rpath:=09yes=09=09with_double:=09yes

Optional libraries:
with_qhull:=09no=09=09with_csa:=09yes
with_freetype:=09yes=09=09with_pthreads:=09no


Language Bindings:
enable_tcl:=09yes=09=09enable_itcl:=09yes
enable_cxx:=09yes=09=09enable_f77:=09no
enable_java:=09no=09=09enable_python:=09no
enable_octave:=09no




All the best
Volker

*****************************************************************
Dr. Volker Naulin                          Senior Scientist
Risoe National Laboratory
Optics and Fluid Dynamics
P.O. Box 49=09=09=09           Phone: +45 46 77 45 38
DK-4000 Roskilde, Denmark                  FAX:   +45 46 77 45 65
*****************************************************************

[Plplot-devel] xwin problem

[Sebastian K. <se...@he...>]

Hi folks, i'm new to plplot but it seems like a great product.  On most
of the machines i work with it works great, but two have problems with
the xwin driver.  When i call plinit() it creates a window, immediately
destroys it, then hangs.  One machine is running Debian Woody (XF86
4.1.0, glibc 2.2.5) and the other's running a Sarge/Sid hybrid (XF 4.2.1,
glibc 2.3.1).  The Gnome driver works fine on both.  I'm using the plplot
.debs from sourceforge: 5.2.0.cvs.20030403-1.


Here's the output from "./x07c -verbose -debug -dev xwin":

plLoadDriver: Device not loaded!
plLoadDriver: tag=xw, drvidx=15
plGetDrvDir: Trying to read env var PLPLOT_DRV_DIR
plGetDrvDir: Will use drivers dir: /usr/lib/plplot5.2.0.cvs.20030403/data/../driversd
plLoadDriver: Trying to load xwin on /usr/lib/plplot5.2.0.cvs.20030403/data/../driversd/xwin
XVisual class == TrueColor
xwd->rw_cmap = 0
Downgrading to r/o cmap.
Attempting to allocate r/o colors in cmap0.
i=1, r=1, pixel=16711680
i=2, r=1, pixel=16776960
i=3, r=1, pixel=65280
i=4, r=1, pixel=8388564
i=5, r=1, pixel=16761035
i=6, r=1, pixel=16113331
i=7, r=1, pixel=12500670
i=8, r=1, pixel=10824234
i=9, r=1, pixel=255
i=10, r=1, pixel=9055202
i=11, r=1, pixel=65535
i=12, r=1, pixel=4251856
i=13, r=1, pixel=16711935
i=14, r=1, pixel=16416882
i=15, r=1, pixel=16777215
Allocated 16 colors in cmap0.
CreatePixmap: creating pixmap: width = 1200, height = 900, depth = 24
fnt: 1
<hangs here>




When i run the same app on this same machine, but displaying over the
net to another box, it works.  Here's that output:

plLoadDriver: Device not loaded!
plLoadDriver: tag=xw, drvidx=15
plGetDrvDir: Trying to read env var PLPLOT_DRV_DIR
plGetDrvDir: Will use drivers dir: /usr/lib/plplot5.2.0.cvs.20030403/data/../driversd
plLoadDriver: Trying to load xwin on /usr/lib/plplot5.2.0.cvs.20030403/data/../driversd/xwin
XVisual class == TrueColor
xwd->rw_cmap = 0
Downgrading to r/o cmap.
Attempting to allocate r/o colors in cmap0.
i=1, r=1, pixel=16711680
i=2, r=1, pixel=16776960
i=3, r=1, pixel=65280
i=4, r=1, pixel=8388564
i=5, r=1, pixel=16761035
i=6, r=1, pixel=16113331
i=7, r=1, pixel=12500670
i=8, r=1, pixel=10824234
i=9, r=1, pixel=255
i=10, r=1, pixel=9055202
i=11, r=1, pixel=65535
i=12, r=1, pixel=4251856
i=13, r=1, pixel=16711935
i=14, r=1, pixel=16416882
i=15, r=1, pixel=16777215
Allocated 16 colors in cmap0.
CreatePixmap: creating pixmap: width = 768, height = 576, depth = 24
fnt: 1
<^C, normal termination>




Hm, those are identical except for the image size, so it's probably not
very useful.  What more information can i provide for you?  An ltrace
or strace perhaps?




--
Sebastian

Re: [Plplot-devel] PLplot RC1 (fwd)

[<jc...@fe...>]

On Monday 14 April 2003 16:17, Rafael Laboissiere wrote:
| Hi,
|
| Alan Irwin forwarded your message to us, thanks for the bug reports.
| I am replying to your msg below, with Cc: to plplot-devel.  I hope
| you do not mind it.
|
| * Volker Naulin <vol...@ri...> [2003-04-14 07:21]:
| > b) in example 21 Delauny and natural neighbours give something
| > strange, mostly flat
|
| This does not happen for me.  How different are your results from
| this:
|
|     http://people.debian.org/~rafael/griddata.ps

The problem must be the one I said, a non-existing Qhull library in the 
system; in that case a warning message should be printed and the second 
and third plot should be flat. To reproduce, configure with  
--without-qhull.

Volker, can you please check that in the config.summary file is a line 
that says:
   with_qhull:     no

| > c) in example 20 when selecting the first point the crosshair has
| > two additional lines added, they start at the left edge of the lena
| > picture approx. at 25% and 50% of the height. The line starting at
| > 50 % goes to the coordinates (40% of xmax, y) and the other one to
| > (x, 50% of ymax)
|
| I cannot replicate this neither.

Neither me.
Joao

Re: [Plplot-devel] Noticed a few minor issues with the examples on our web site.

[<jc...@fe...>]

On Monday 14 April 2003 16:17, Alan W. Irwin wrote:
| Joao, there are some minor issues with the examples part of the web
| site that you may want to address before the release.  I noticed that
| the commentary at http://plplot.sourceforge.net/examples/index.html
| needs to be changed, and you probably will also want to include
| example 21 (and perhaps screenshots of the interactive examples 14
| and 17 as well).

I will do that.
I just put it in my non-solid-state agenda (so I have an excuse, kind of 
oops, forgot to... :)

Joao

|
| Alan
| __________________________
| Alan W. Irwin
| email: ir...@be...
| phone: 250-727-2902
|
| Astronomical research affiliation with Department of Physics and
| Astronomy, University of Victoria (astrowww.phys.uvic.ca).
|
| Programming affiliation with the PLplot scientific plotting software
| package (plplot.org).
|
| __________________________
|
| Linux-powered Science
| __________________________
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Welcome to geek heaven.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel